Using Separation of Concerns for Embedded Systems Design

1
Using Separation of Concerns for Embedded Systems
Design
a90
Ethan Jackson and Janos Sztipanovits EmSoft 05,
Jersey City, New Jersey September 19, 2005
2
Part I Outline
Introduction Discuss major design aspects for
specifying embedded systems
Claim The design aspects essential to system
specification strongly interact, i.e. they are
not orthogonal concerns
Hypothesis Specification tools should view these
design aspects as non-orthogonal this should
produce more accurate system specifications
Challenge Can specification tools handle the
additional complexity introduced by assuming
non-orthogonal concerns?
Results Model integrated computing (MIC) already
provides constructs for implementing such
specification systems. We show an example system
for the SR MoC.
3
Aspects of Embedded System Specification
An embedded system specification is commonly
partitioned into design aspects, where each
design aspect 1. quantifiably affects the system
dynamics 2. cross-cuts the system 3. has
behavioral invariants
Behavioral, Computational Concern A set of
stateless, n-ary mappings
Interaction Model, Architectural Concern
Point-to-point communication buffers of finite
length. Blocking read, non-blocking write.
Time Model, Scheduler, Coordination Concern
Executes operators which takes a fixed time t,
when their data dependencies are met.
4
Often these concerns are claimed to be orthogonal
As an example, we will apply the orthogonal
concern assumption to the behavioral design
aspect.
Use-cases are Transform(o, NULL) and
Transform(NULL, n).
In a time-triggered language like Giotto this
behavior works as expected.
Sensors periodically sample environment and write
results
obj
s1
T
Transform
s2
name
Periodically read inputs take t time write
outputs
This works as expected
5
But this assumption can cause wrong designs
Designer knows this specification of the
transform operation, and applies orthogonal
concerns when using this operation.
Behavioral Specification If there is an object,
apply to the object. Otherwise, if there is a
name apply to the object with that name.
Under the SR interaction model this assumption
leads to an incorrect system
o3 o2 o1
o3 err err o1
n3 n2 n1
Problem NULL value has semantics of absence at
behavioral level, and this conflicts with
semantics of absence at interaction level.
o3 o2 o1
TObj
Merge
obj
o4 o3 o2 o1
T
n3 n2 n1
TName
name
Transform
6
Non-orthogonal concerns Formal Semantics
In the formal semantics each design aspect is a
mathematical model, and the system dynamics
result from the formal composition of these
models.
These layers interact in non-trivial ways.
Example of component layering
Parts of component layering
Example of interaction model
Graphics taken from GÖSSLER, G., AND SIFAKIS, J.
Composition for component-based modeling. In
Proceedings of FMCO02 (November 2002), vol. 2852,
LNCS, pp. 443-466
7
Non-orthogonal concerns Simulation
In simulation the total dynamics results from
complex interactions between concerns. Similar
results hold for analysis.
Ptolemy Director and actors interact
Graphics taken from E. LEE, S. NEUENDORFFER, AND
M. J. WIRTHLIN Actor-oriented design of embedded
hardware and software systems. Journal of
Circuits, Systems, and Computers 12, 3 (2003),
231-260.
Metropolis Processes and Quantity Managers
interact
Graphics taken from G. YANG, Y. WATANABE, F.
BALARIN, AND A. SANGIOVANNI-VINCENTELLI
Separation of Concerns Overhead in modeling and
efficient simulation techniques. In Fourth ACM
International Conference on Embedded Software
(EMSOFT04) (September 2004).
8
Orthogonal Concerns is a Simplifying Assumption

• The essential design aspects for embedded system
  specification are not
• orthogonal.
• non-trivially interact as defined in their formal
  semantics
• non-trivially interact during simulation
• non-trivially interact during analysis

Claim Designers of specification tools use the
notion of orthogonal concerns to simplify the
design of the specification tool.
Component B ? I ? S
Specification
B I S
? ?
In reality
In the specification tool
9
More accurate specifications
Hypothesis Non-orthogonal concerns at the
specification level would mean a tool that
reflects in the specification, how parts of the
specification interact. Such an approach would
lead to more accurate specifications
Constraint-based overlap Changes to one concern
imply checkable constraints on other concerns
I
S
Generative overlap Changes to one concern
actively cause changes to another concern
B
Key observation The formal semantics directly
affects the specification tool. We want a
semantics that induces reasonable overlap Avoid
a exponential-time constraints avoid fixed-point
generative overlap.
Component ( B ? I ) ? S
10
Part II Outline
Goal A non-orthogonal specification tool for
synchronous reactive (SR) systems.
Reformulate the semantics Need a formulation
that induces explicit and manageable overlap
between concerns. WARNING May not look like SR
in the beginning.
Define the overlap Characterize the
constraint-based and generative overlap
Apply MIC Concepts from MIC can be used to
create a specification tool
Demo SMOLES2 Modeling Environment implements
non-orthogonal concerns within the
meta-programmable tool GME (Poster Session)
11
Reformulating the SR Semantics
After trying several approaches, a controls
approach showed the most promise.
Primitive behaviors are stateless n-ary mappings
that consume all n inputs to produce all m outputs
A plant is an untimed non-deterministic,
dead-lock prone dataflow system with
bounded-memory
Controller
A controller restricts the plant through
controllable actions to produce deadlock-free
deterministic behavior, and provides a timeline
for events.
Plant
Primitive Behaviors
A correctly specified system is bounded-memory,
deadlock-free, and deterministic assuming zero
logical time for computation (SR).
12
The Plant Dynamics
A plant is similar to an SDF system with rate 1
for all operators, specifically

• Fire Once An operator can fire at most once per
  run.
• 2. Eventually Fire An operator that can fire
  will eventually fire.
• 3. Write Once A connection can carry at most one
  token per run.
• 4. Consumption A token waiting on an input must
  be consumed during the run in which it was
  produced.
• 5. End A run ends after neither (2) nor (4) can
  occur.
• 6. Reset After a run ends, all unconsumed tokens
  are discarded.

13
Consistency Requirements
We only require that the dataflow graph use
bounded memory. There are two possible case that
could invalidate this property.
A dangling input could cause tokens to pile up,
leading to unbounded memory. This can be
prevented by requiring this simple constraint
A cycle that is fed by a schedulable operator
also causes a piling up of tokens, and violates
the consumption requirement. This can also be
prevented by requiring
These are two constraints because the checking
algorithms are quite different.
14
Controllable Actions
The plant exposes some controllable actions that
affect its execution.
A controller is valid if it produces a defined
sequence of control inputs that do not put the
graph in an illegal configuration.
15
The Controller Structure
A mode is a global configuration of the
computational system (in this case a dataflow
graph). A controller is a set of test-mode pairs
(t,m) where if t is true, then the controller
configures the system to mode m.
Tests derived from input assignments
Example Controller
Applications of Controller
Example Plant
Controllers can require data dependent tests, for
example
16
Inherited Consistency Requirements
A mode is structurally constrained so that it
produces control signals that are relevant to the
plant.
This constraint can be captured by the following
generative action
Whenever v added to d add a u to every mode
M and f(u) v
These generative actions are extended to all
modifications of the dataflow graph. Even with
this constraint a controller may place the
dataflow in an invalid configuration, so we
require this constraint.
17
Consistency Requirements
The controller should remove deadlocks and
non-determinism from the dataflow. We can check
these properties by checking the modes.
Modes with cycles of present operators allow
deadlock.
Modes with present operators writing to the same
edge allow non-determinism.
We extend these rules for different pieces of
control information by defining a semi-lattice
for each interaction context present, absent,
constant, dont care.
Join of lattice defines correctness for merging
18
Example
Behavioral Concern
Data Interaction Concern
Simulation of the specification with and without
the controller
Timed Control Concern
19
Bringing It Together - Implementing the tool
We have implemented a specification tool using
the meta-programmable tool framework GME.
Approximation algorithms for causality
(deadlock-freedom) loops, approximation for
non-determinism
Generative mode topology
Approximation for Component Composition
Data Interaction Concern
Timed Control Concern
Must instantiate operator
Operator Library
Monochronous interactions (encoded in
semi-lattices)
Checks for unbounded memory
20
MIC Concepts

• A metamodel (UML Class Diagram) defines model
  structure
• Modeling aspects partition structure into
  modeling views
• Cross-aspect interactions like type instantiation
  and referencing permits aspects to interact.
• Built in constraint engine automatically checks
  simple constraints
• A generative engine builds portions of the model
  in one aspect when changes occur in another
  aspect.
• An approximation engine checks for approximate
  causality violations and non-deterministic
  behavior

Aspect
Reference
Type instance
Generatively implied
op
21
Extensions, Conclusions, and Future Work
Hierarchical composition is an important modeling
feature and we have incorporated it into our
semantics/tools. Reformulating the semantics
has a trickle down effect on simulation and
analysis. We have constructed a simulator (as
described in the paper) and we are completing an
analysis engine that incorporates analysis
techniques from synchronous languages with
interface automata. In conclusion,
non-orthogonal aspects can be implemented with
current MIC techniques. Our future work will
generalize this methodology in several ways 1.
Extend methodology to other formal semantics 2.
Extend metamodeling language to facilitate
generative actions 3. Apply concepts to semantic
anchoring and semantic units.
22
Thank You
Questions? Please come see demo
during poster session