Using Separation of Concerns for Embedded Systems Design α=90 Ethan Jackson and Janos Sztipanovits EmSoft 05, Jersey City, New Jersey September 19, 2005
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 nonorthogonal; 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.
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.
Often these concerns are claimed to be orthogonal As an example, we will apply the orthogonal concern assumption to the behavioral design aspect. obj name Transform T 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 s1 s2 obj name Transform T Periodically: read inputs; take t time; write outputs This works as expected
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 o 3 o 2 o 1 obj Transform T o 3 err err o 1 n 3 n 2 n 1 name Problem: NULL value has semantics of absence at behavioral level, and this conflicts with semantics of absence at interaction level. o 3 o 2 o 1 obj n 3 n 2 n 1 name TObj TName Merge o 4 o 3 o 2 o 1 T Transform
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. Scheduler: dynamic priority rules Interaction Model: Connectors + Interactions B E H A V I O R 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
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 (EMSOFT 04) (September 2004).
Orthogonal Concerns is a Simplifying Assumption The essential design aspects for embedded system specification are not orthogonal. 1. non-trivially interact as defined in their formal semantics 2. non-trivially interact during simulation 3. 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 In reality Specification = B I S In the specification tool
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 Generative overlap: Changes to one concern actively cause changes to another concern B Component = ( B I ) S 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.
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 nonorthogonal concerns within the meta-programmable tool GME (Poster Session)
Reformulating the SR Semantics After trying several approaches, a controls approach showed the most promise. Controller Plant Primitive Behaviors 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 A controller restricts the plant through controllable actions to produce deadlockfree deterministic behavior, and provides a timeline for events. A correctly specified system is boundedmemory, deadlock-free, and deterministic assuming zero logical time for computation (SR).
The Plant Dynamics A plant is similar to an SDF system with rate 1 for all operators, specifically: 1. 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.
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.
Controllable Actions The plant exposes some controllable actions that affect its execution. Action Produced By Description RunStart Controller Starts a run of the dataflow graph RunEnded Plant Indicates run has completed Clear Controller Resets system to initial state. Defined before a RunStart and after a RunEnded Peek/Values Controller/Plant Indicates controller wants to observe input vector. Defined before a RunStart and after a RunEnd. Remove Controller Removes a dataflow operator from the graph. Defined before a RunStart and after a RunEnded. *A controller is valid if it produces a defined sequence of control inputs that do not put the graph in an illegal configuration.
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. Example Controller Tests derived from input assignments Example Plant Applications of Controller Controllers can require data dependent tests, for example:
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 φ(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.
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, don t care. Join of lattice defines correctness for merging
Example Behavioral Concern Data Interaction Concern Simulation of the specification with and without the controller Timed Control Concern
Bringing It Together - Implementing the tool We have implemented a specification tool using the meta-programmable tool framework GME. Approximation algorithms for causality (deadlockfreedom) loops, approximation for non-determinism Approximation for Component Composition Generative mode topology Monochronous interactions (encoded in semilattices) Operator Library Must instantiate operator Checks for unbounded memory
MIC Concepts 1. A metamodel (UML Class Diagram) defines model structure 2. Modeling aspects partition structure into modeling views 3. Cross-aspect interactions like type instantiation and referencing permits aspects to interact. 4. Built in constraint engine automatically checks simple constraints 5. A generative engine builds portions of the model in one aspect when changes occur in another aspect. 6. An approximation engine checks for approximate causality violations and non-deterministic behavior Aspect Reference Type instance Generatively implied op
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.
Thank You Questions? Please come see demo during poster session