1. End-to-End Design of Embedded Real-Time Systems Kang G. Shin Real-Time Computing Laboratory EECS Department The University of Michigan Ann Arbor, MI 48019-2122 http://www.eecs.umich.edu/~kgshin

2. OutlineOutline Motivation Project Goal and Objectives Our Approach Technology Integration Conclusion

3. MotivationMotivation e2e rt design is an important but hard problem because rt constraints: –Often cut across component and process boundaries. –Are awkward to specify, and reason about with current modeling tools. –Are often only considered at later stages of system development.

4. Motivations, cont ’ d At early stages of system analysis and design, only coarse-grained e2e timing constraints are know. Often designer has to manually derive intermediate rt constraints using heuristics, and specify them in the model, instead of specifying e2e constraints directly. Need to make e2e constraints easier to specify, reason about and verify or validate.

5. Project Goal Develop methods for effective e2e design and implementation of embedded rt systems. –Current design notations (UML,Simulink/Stateflow) usually do not allow designer to effectively express and reason about e2e constraints. –The loose semantics of UML allow the designer to specify almost anything in the design diagrams, most likely serving as comments. –Want to enhance UML with e2e design syntax and semantics, and integrate e2e analysis and validation tools into the UML design process.

6. ObjectivesObjectives Enable the designer to express behavior and rt constraints at a higher level, closer to domain knowledge and further away from implementation details. Automate the usually tedious process of deriving intermediate behavior and rt constraints from e2e requirements. Provide formal semantics for e2e extensions to enable effective formal analysis and simulation.

7. Proposed Approach Define graphical and textual syntax. –Extension to UML notation with a meta- modeling tool (possibly DOME from Honeywell). –XML-based text file format. Define rigorous semantics using a formal language, such as ACSR. Develop algorithms for automatic derivation of intermediate timing constraints from e2e constraints.

8. Proposed Approach, cont ’ d Develop effective and integrated tools to reason about, and validate e2e behavior and rt constraints. –Analysis at e2e behavior level instead of the component behavior level. –(Semi)-automatic derivation of intermediate task constraints from e2e constraints, possibly with interactive user guidance. –Integration of an rt analysis tool with a UML tool. Methodology for component-based e2e design.

9. Proposed Design Flow e2e functional and timing requirements Detailed Design of Subtasks Rigorous e2e Decomposition Schedulability Analysis (RMA or ACSR) Distributed Executables Download to Target Application Components Formal Verification (model checking) WCET Analysis Application Components High-level Costumer Requirements Code Generator Application WCET

10. Formal Semantics UML is an informal design notation without formal semantics. In order to rigorously validate e2e constraints with automatic tool support, we need to formalize the semantics of our e2e extensions to UML. ACSR is a process algebra that can model resource and rt constraints, so we plan to use it as a basis for formalization. Other formal languages are not ruled out at this point.

11. End-to-End Behavior UML Sequence Diagram can be used to specify e2e behavior, but –it does not have formal semantics. –interactions between different e2e transactions due to sharing of intermediate components are not apparent. –analysis techniques, such as model checking, are usually performed on component behaviors, i.e., at a more detailed level than e2e behavior. –It does not fulfill our needs.

12. e2e RT Constraints A transaction can be decomposed into sub- transactions that cooperate to fulfill e2e functional and timing requirements. Formal representation of e2e rt constraints will enable automatic derivation of intermediate constraints while taking into account the interference between different e2e transactions. Schedulability analysis can be performed after detailed timing constraints have been determined.

13. Partial Specification e2e specifications can capture only partial information of the system, enabling rapid iterations of specification and analysis. Or different sub-systems can be specified with different level of detail.This is an important benefit. Need to develop algorithms for validating the equivalence between high-level e2e specs and detailed design.

14. Methodology Development e2e design techniques can be an integral part of the software process, bridging the gap between high-level analysis and detailed design. Methodology development is essential for technology transfer. E2e design techniques naturally encourages iterative styles of development.

15. Integration & Collaboration We will collaborate with U Penn team, and make our results an integral part of the advanced tool integration. The concept of e2e design can also be applied to other design methods besides UML.

16. Project Milestones Year 1: Extend UML with e2e behavior and rt spec notations. Develop XML-based concrete format. Explore use of bi-simulation checking and model checking for e2e behavior of UML. Year 2: Define a runtime execution model in UML to facilitate schedulability analysis and conduct case studies. Explore automatic derivation of intermediate constraints from e2e constraints. Develop an initial methodology for technology integration. Year 3: Integrate the runtime execution model and simulation into the code generator of the enhanced UML tool.

17. Project Milestones Year 4: Perform a medium-size case study to access the new analysis techniques. Complete integration of our techniques into HASTEN tool suite. Complete methodology development. Year 5: Assess the developed technology on a realistic, large-scale system. Refine the methodology and improve analysis techniques for large scale systems. Quantify improvements in terms of shortened development cycle and improved product quality