Dealing with AADL End-to-end Flow Latency in UML MARTE

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
Motivation
Introduction
AADL
MARTE for AADL
Conclusion

• 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
AADL
Introduction
AADL
MARTE for AADL
Conclusion

• 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
MARTE
Introduction
AADL
MARTE for AADL
Conclusion

• OMG UML2 Profile for Modeling and Analysis of
  Real-Time and Embedded systems
• OMG Adopted Specification (ptc/07-08-04) gt 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
MARTE
Introduction
AADL
MARTE for AADL
Conclusion

• OMG UML2 Profile for Modeling and Analysis of
  Real-Time and Embedded systems
• OMG Adopted Specification (ptc/07-08-04) gt 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
Our contribution
Introduction
AADL
MARTE for AADL
Conclusion

• 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/delayed data
  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
An example in AADL
Introduction
AADL
MARTE for AADL
Conclusion
ExecutionPlatform Device (actuator)
Software Thread
ExecutionPlatform Device (sensor)
Event-data port (message-passing, queues)

• Mix of Execution Platform and Software
• Case-based definition of the underlying Model of
  Computation and Communication (MoCC)

Event port (queues)
Software Periodic Thread
Delayed communication ? immediate
Data port (no queue)
8
Delayed Communications
Introduction
AADL
MARTE for AADL
Conclusion
f1q1f f2q2f
T1
T2

• Latched communication classical in EDA

9
Immediate Communications
Introduction
AADL
MARTE for AADL
Conclusion
f1q1f f2q2f
T1
T2

• Instantaneous communications

10
Causality problems
Introduction
AADL
MARTE for AADL
Conclusion

• 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
A simple sketch hides a complex model
Introduction
AADL
MARTE for AADL
Conclusion

• Most of the model is hidden as text in AADL

12
Summary of Issues (and solutions)
Introduction
AADL
MARTE for AADL
Conclusion

• 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
UML and MARTE
Introduction
AADL
MARTE for AADL
Conclusion

• 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
UML and MARTE
Introduction
AADL
MARTE for AADL
Conclusion

• Software Resources (OS, middleware, )
• UML Composite Structure Diagrams

MARTE Library for AADL
15
UML and MARTE
Introduction
AADL
MARTE for AADL
Conclusion

• Execution platform
• Composite Structure Diagrams

MARTE Library for AADL
16
Allocation in MARTE
Introduction
AADL
MARTE for AADL
Conclusion
17
MoCCs with MARTE
Introduction
AADL
MARTE for AADL
Conclusion

• 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
MoCCs with MARTE
Introduction
AADL
MARTE for AADL
Conclusion

• 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
Clock Constraint Specification Language
Introduction
AADL
MARTE for AADL
Conclusion
20
Timing analysis results
Introduction
AADL
MARTE for AADL
Conclusion
UML Timing Diagrams
21
Conclusion
Introduction
AADL
MARTE for AADL
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