Dealing with AADL End-to-end Flow Latency in UML MARTE AOSTE INRIA/I3S Sophia Antipolis, France

1. Dealing with AADL End-to-end Flow Latency in UML MARTE AOSTE INRIA/I3S Sophia Antipolis, France S-Y. Lee, F. Mallet, R. de Simone

2. Introduction AADL MARTE for AADL Conclusion Motivation • Allocation of heterogeneous applications on to heterogeneous execution platforms • The execution platform may be speculative (Y-chart) • May explore several platforms for a single application • Early analysis (end-to-end flow latency) requires • Combined models of the applications, execution platforms AND of the allocation • AADL and MARTE have this ability • MARTE is more general • Some specific AADL constructs require a special attention to find equivalences in MARTE

3. Introduction AADL MARTE for AADL Conclusion AADL • Architecture Analysis & Design Language • Avionics/Automotive standard from Society of Automotive Engineers. • Design & Analysis of performance-critical RT systems • Application/Software Components • Thread, Thread Group, Process, Subprogram • Execution Platform Components • Bus, Device, Processor, Memory • Binding • Bind Application onto Execution Platform

4. Introduction AADL MARTE for AADL Conclusion MARTE • OMG UML2 Profile for Modeling and Analysis of Real-Time and Embedded systems • OMG Adopted Specification (ptc/07-08-04) => FTF • Time • Define a Timed Causality Model for UML • Broad enough to cover several Models of Computation (exercise: Model AADL MoCC) • Allocation sub-profiles • Describe various possible allocations (and their costs)‏ • Time analysis needs to cope with communication costs and context switching costs, etc.

5. Introduction AADL MARTE for AADL Conclusion MARTE • OMG UML2 Profile for Modeling and Analysis of Real-Time and Embedded systems • OMG Adopted Specification (ptc/07-08-04) => FTF • Time • Define a Timed Causality Model for UML • Broad enough to cover several Models of Computation (exercise: Model AADL MoCC) • Allocation sub-profiles • Describe various possible allocations (and their costs)‏ • Time analysis needs to cope with communication costs and context switching costs, etc.

6. Introduction AADL MARTE for AADL Conclusion Our contribution • How to represent, in MARTE, AADL constructs amenable to end-to-end flow latency analysis ? • Address examples from Feiler & Hansson (Technical Note CMU/SEI-2007-TN-010, June 2007) • Previous contribution on immediate/delayeddata communications(Embedded Systems Specification and Design Languages, chapter 11, Springer, March 2008) • Today, focus on • How to mix data-driven and event-based communications • Lots of applications in automotive with protocols like FlexRay

7. Introduction AADL MARTE for AADL Conclusion An example in AADL Software Thread ExecutionPlatform Device (actuator) ExecutionPlatform Device (sensor) Event-data port (message-passing, queues) • Mix of Execution Platform andSoftware • Case-based definition of the underlyingModel of Computation and Communication (MoCC) Event port (queues) Software Periodic Thread Delayed communication  immediate Data port (no queue)

8. Introduction AADL MARTE for AADL Conclusion Delayed Communications f1=q1*f f2=q2*f • Latched communication: classical in EDA T1 T2

9. Introduction AADL MARTE for AADL Conclusion Immediate Communications f1=q1*f f2=q2*f • Instantaneous communications T1 T2

10. Introduction AADL MARTE for AADL Conclusion Causality problems • To be deterministic, one must • Perform clock computations • Define a schedule • Compute a Fix-point • How to deal with the causality problems ? • Synchronous languages !

11. Introduction AADL MARTE for AADL Conclusion A simple sketch hides a complex model • Most of the model is hidden as text in AADL

12. Introduction AADL MARTE for AADL Conclusion Summary of Issues (and solutions) • Mix of Execution Platform and Software • Separate them, use Allocation to associate costs • Case-based definition of the underlying Model of Computation and Communication (MoCC) • Make It Explicit • Do not deal with the causality problems • Use well-known solutions • … from synchronous languages • Most of the model is hidden as text • Make the time a first-class citizen

13. Introduction AADL MARTE for AADL Conclusion UML and MARTE • Application (pure causal/untimed relations) • UML Activity Diagrams • Different queuing policies (event, event-data, data) ? Without queues (data) With queues (event or event-data) and selection policy if needed(All Items?)

14. Introduction AADL MARTE for AADL Conclusion UML and MARTE • Software Resources (OS, middleware, …) • UML Composite Structure Diagrams MARTE Library for AADL

15. Introduction AADL MARTE for AADL Conclusion UML and MARTE • Execution platform • Composite Structure Diagrams MARTE Library for AADL

16. Introduction AADL MARTE for AADL Conclusion Allocation in MARTE

17. Introduction AADL MARTE for AADL Conclusion MoCCs with MARTE • Overall only two different kinds of communications in AADL • Dataflow Data ports + immediate periodic threads Event-data ports + Aperiodic threads t1.finish alternatesWith t2.start T1 T2

18. Introduction AADL MARTE for AADL Conclusion MoCCs with MARTE • Overall only two different kinds of communications in AADL • Sampled Data ports + immediate Periodic (oversampling) threads Data ports + Delayed + Periodic threads t2.start = t1.finish sampledTo ^t2 T1 T2

19. Introduction AADL MARTE for AADL Conclusion Clock Constraint Specification Language

20. Introduction AADL MARTE for AADL Conclusion Timing analysis results UML Timing Diagrams

21. Introduction AADL MARTE for AADL Conclusion Conclusion • MARTE is under finalization by FTF • MARTE annex A • Guidelines about AADL and East-ADL2 (AutoSAR) • MARTE as a language to support MoCC definition • Give a Timed Causality Model to UML • AADL may benefit from using MARTE as a front-end • Reuse all existing UML tools with support teams • MARTE may require some adaptations to ease the work of designers used to AADL