1. MARTE/CCSL, TimeSquare & K-Passa A design platform using MoCCs for embedded model-based engineering
C. André, J. Boucaron, A. Coadou, J. DeAntoni,
B. Ferrero, F. Mallet, R. de Simone
AOSTE Project INRIA/I3S
Sophia Antipolis, France

2. Context
Modeling environments for real-time embedded and distributed systems

3. Context
Modeling environments for real-time embedded and distributed systems
Conceptual diagrammatic representations
Structural
Components / interactions
Dynamics/Behavior

4. Context
Modeling environments for real-time embedded and distributed systems
Conceptual diagrammatic representations
Structural
Components / interactions
Dynamics/Behavior of individual components
State-based control flow
Activity-based data flow
Constrained programs with “same” expressivity

5. Context
Modeling environments for real-time embedded and distributed systems
Conceptual diagrammatic representations
Structural
Components / interactions
Dynamics/Behavior of individual components
State-based control flow
Activity-based data flow
Constrained programs with “same” expressivity
Dynamics/Behavior of system
results from combining component behaviors according to structure

6. Example of architecture modeling
Structure
Behavior

7. Example of architecture modeling
Structure
Behavior

8. Example of architecture modeling
Structure
Elaboration phase (SystemC)
Behavior
Simulation

9. Traditional component approach
Structure
Black-box + Interfaces (Ports, Data Types)
Behavioral abstraction
Messages + possibly period and performance requirements
What we find missing:
Detailed definition of timing and synchronization properties
Communication protocol requirements
This missing information is often deported elsewhere

10. Traditional component approach
Structure
Black-box + Interfaces (Ports, Data Types)
Behavioral abstraction
Messages + possibly period and performance requirements
What we find missing:
Detailed definition of timing and synchronization properties
Communication protocol requirements
This missing information is often deported elsewhere

11. Time & Semantics Logical functional time “physical” time
Functional: sequence of reaction steps
Multiple times (local / global)
Synchronization primitives → constraints between local activation times
Synthesis / Compilation
Process networks (SDF), synchronous reactive formalisms, statecharts
“physical” time
Extra functional
Single time (total order)
Timing constraints to be satisfied at execution
Simulation semantics possibly different from synthesis
UML, SystemC

12. Time & Semantics Logical functional time “physical” time
Functional: sequence of reaction steps
Multiple times (local / global)
Synchronization primitives → constraints between local activation times
Synthesis / Compilation
Process networks (SDF), synchronous reactive formalisms, statecharts
“physical” time
Extra functional
Single time (total order)
Timing constraints to be satisfied at execution
Simulation semantics possibly different from synthesis
UML, SystemC
HDLs

13. Semantics “physical” time Logical functional time Extra functional
Single time (total order)
Timing constraints to be satisfied at execution
Simulation semantics possibly different from synthesis
UML, SystemC
Logical functional time
Functional: sequence of reaction steps
Multiple times (local / global)
Synchronization primitives → constraints between local activation times
Synthesis / Compilation
Process networks (SDF), synchronous reactive formalisms, statecharts
Our choice

14. MARTE: Time model and CCSL
MARTE = Modeling and Analysis of Real-Time and Embedded systems
OMG UML profile (adopted June 2009)
Time subprofile (defined by us)
Rich but well-defined variety of time notions (logical/physical, discrete/dense, …)
Clocks can be explicitly attached to most UML model elements → timed semantics
Clock Constraint Specification Language (CCSL)
Various constraints on clocks (synchronous, asynchronous, mixed)
Precise formal semantics

15. Why CCSL?
Polychronous system modeling
Specification of sophisticated synchronizations
Notation to describe semantic relations between timed behaviors (illustrated below)
Means to define formally timed Models of Computations and Communications (MoCCs)
Akin to Tagged Systems (Lee & Sangiovanni-Vincentelli)

16. Why CCSL?
Means to define formally timed Models of Computations and Communications (MoCCs)
In the sequel, we translate a MoCC as UML models + CCSL specifications
The chosen MoCC is SDF (weighted event graphs) models

17. Synchronous DataFlow Nodes are called actors
SDF Meta-model
Nodes are called actors
Input/Output have a weight (Number of data samples consumed/produced)
Arcs have a delay
incoming
dest
src

18. Synchronous DataFlow SDF firing rules:
Actor enabling = each incoming arc carries at least weight tokens
Actor execution = atomic consumption/production of tokens by an enabled actor
i.e., consume weight tokens on each incoming arcs and produce weight tokens on each outgoing arc
Delay is an initial token load on an arc.
How can CCSL express this semantics?

19. SDF Example
Evolutions of the model A A B A A B
Static schedule: C C

20. How to model SDF graphs in UML ?
Is that compatible with the UML semantics ?
CCSL makes the semantics explicit …
… within the model

21. SDF semantics with CCSL (1/2)
Actor A
Token T
Input i
Output o
CCSL
Clock A;
Clock write, read;
Var delay:int;
Var weight:int;

22. SDF semantics with CCSL (2/2)

23. Example

24. TimeSquare

25. AOSTE’s Tools TimeSquare K-Passa Software environment dedicated to the
Specification of CCSL constraints
Resolution of CCSL constraints
Simulation and generation of trace model
Animation of UML models
Exploration of augmented timing diagrams
K-Passa
Computation of static schedules for specific MoCCs
Marked Graphs, Synchronous DataFlow, Latency-Insensitive Designs, K-periodical Routed Graphs
Analysis (deadlock freeness, safety)
Optimization (latency, throughput, interconnect buffer size)
Code generation (stand-alone simulator)

26. K-Passa

27. Tool download

28. Thank you All