www-verimag.imag.fr/~async/BIP/bip.html

1. Component-based Construction of Heterogeneous Real-time Systems in BIPA. Basu Joseph Sifakis, S. Bliudze and M. BozgaVERIMAG LaboratoryModel Engineering of Complex Systems (MECS)Dagstuhl 10 - 13 Aug 2008 http://www-verimag.imag.fr/~async/BIP/bip.html

2. Motivation & Objectives Provide a framework for describing and analyzing coordination between components in terms of well-founded concepts: • expressive enough to directly encompass heterogeneity: • interaction (rendezvous and broadcast). • execution (synchronous and asynchronous). • use a minimalset of constructs and principles. • treat interaction and system architecture as first class entities: • can be composed and analyzed. • independent to the behavior of the components. • provide automated support for component integration and generation of glue code meeting given requirements

3. Overview • BIP: Basic Concepts • Modeling Interactions • Modeling Priorities • Implementation • Applications • Conclusion 3

4. BIP: Basic Concepts • Modeling Interactions • Modeling Priorities • Implementation • Applications • Conclusion 4

5. PR1 PR2 IN1 IN2 PR1  PR2 PR12 IN1  IN2 IN12 BIP: Basic Concepts Layered component model Priorities (Memoryless Controller) Interactions (Structured Connectors) B E H A V I O R Composition (incremental description) ||

6. s i r1 i1 r2 i2 r3 i3 s i3 i i1 r1 r3 r2 i2 Sender Receiver1 Receiver2 Receiver3 BIP: Basic Concepts Priorities:  Interactions: sr1r2r3, i, i1, i2, i3 Rendezvous

7. s i r1 i1 r2 i2 r3 i3 s i3 i i1 r1 r3 r2 i2 Sender Receiver1 Receiver2 Receiver3 BIP: Basic Concepts Priorities: x  xy Interactions: s, sr1, sr2, sr3, sr1r2, sr2r3, sr1r3, sr1r2r3, i, i1, i2, i3 Broadcast

8. s i r1 i1 r2 i2 r3 i3 s i3 i i1 r1 r3 r2 i2 Sender Receiver1 Receiver2 Receiver3 BIP: Basic Concepts Priorities: s  sr1r2r3 Interactions: s, sr1r2r3, i, i1, i2, i3 Atomic Broadcast

9. BIP: Basic Concepts – Behavior Modeling • An atomic component has: • A set of ports P • A set of control locations S • A set of variables V • A set of transitions of the form • p is a port • gpis a guard, boolean expression on V • fpis a function on V (block of code) p g p fp s1 s2 s1 get, 0<x y:=f(x) put get put y x s2

10. p gp fp s1 s2 BIP: Basic Concepts – Behavior Modeling • p: a port through which interaction is sought • gp: a pre-condition for interaction through p • fp : a computation (local state transformation) • Semantics: interaction followed by computation • A transition is enabled if gp is true and some interaction involving p is possible • The execution of the enabled transition involves the execution of an interaction involving p followed by the execution of fp

11. BIP: Basic Concepts • Modeling Interactions • Modeling Priorities • Implementation • Applications • Conclusion 11

12. Interaction Modeling: Connectors • A connectoris a set of portswhich can be involved in an interaction • Port attributes (trigger , synchron ) are usedto model rendezvous and broadcast. • An interactionof a connector is a set of ports such that: either it contains some trigger or it is maximal. { tick1tick2tick3 } tick1 tick2 tick3 out1 in2 in3 { out1, out1in2, out1in3, out1in2in3 }

13. cl1cl2 cl1 cl2 cl1 cl2 outin out in out in in1outin2 out in1 outin1 in1in2 outin2 in1 in2 out in2 Interaction Modeling: Connectors

14. rec1 rec2 send a b c d a b c a b c  Interaction Modeling: Hierarchical Connectors Atomic Broadcast: { send, sendrec1rec2} Causal chain: {a, ab, abc, abcd}

15. Interaction Modeling: Data Transfer CN: BUS={send,rec1,rec2} send: true  skip send rec1: x<y  x:=y-x, y:=y+x send rec2: x<z  x:=z-x, z:=z+x send rec1 rec2: x<z+y  x:=y+z-x, y:=y+x, z:=z+x send x rec1 y rec2 z Maximal progress: execute a maximal enabled interaction

16. BIP: Basic Concepts • Modeling Interactions • Modeling Priorities • Implementation • Applications • Conclusion 16

17. Priorities • Priorities are a powerful tool for restricting non-determinism • they allow straightforward modeling of urgency andscheduling policies for real-time systems. • run to completion and synchronous execution can be modeled by assigning priorities to threads. • they can advantageously replace (static) restriction of process algebras.

18. Priorities: Priorities as Controllers A controller restricts the non determinism of system S to enforce a property P Controller for P interaction state Interactions system S • Results [Goessler&Sifakis, FMCO2003] : • Restrictions induced by controllers enforcing deadlock-free state invariants can be described by dynamic priorities • Conversely, for any restriction induced by dynamic priorities there exists a controller enforcing a deadlock-free control invariant

19. a1 a2 start(t1) start(t2) Priorities: FIFO policy PR : t1 t2  b1b2 t2<t1  b2b1 Interactions: a1, a2, b1, b2, f1, f2 a2 a1 idle1 idle2 b2 b1 f2 f1 ready1 ready2 b1 b2 f1 f2  exec1 exec2

20. a1 a2 start(t1) start(t2) f2 f1 t2 D2 t1 D1 Priorities: EDF policy PR: D1-t1 D2- t2  b2b1 D2-t2< D1-t1  b1b2 Interactions: a1, a2, b1, b2, f1, f2 a2 a1 idle1 idle2 b2 b1 f2 f1 ready1 ready2 b1 b2  exec1 exec2

21. BIP: Basic Concepts • Modeling Interactions • Modeling Priorities • Implementation: • BIP Language • BIP Engine • Centralized • Distributed • Symbolic • Applications • Conclusion 21

22. emf structural analysis model transformations deadlock detection invariant generation static composition timed vs untimed eclipse BIP C Code BIP C++ Code centralized/distributed execution, guided/exhaustive simulation centralized execution (on bare machines) BIP/Linux Engine BIP/Think Platform The BIP tool-chain FXML AADL, NesC, Lustre HRC(SPEEDS), Graphical BIP Program BIP MetaModel compiler BIP Model code generation

23. BIP Engine: Centralized Interaction model Priorities Execution Engine Platform

24. BIP Engine: Centralized Execution of atomic components busy Notify involved atoms Wait all atoms Launch atom threads execute stable init Execute chosen interaction Compute feasible interactions choose ready Choose non-deterministic Filter priorities filter Execution of Engine

25. Automatic translation Preserving equivalence BIP Engine: Distributed Programmimg/Modeling Global States, Multiparty Interactions Distributed Impl. Partial States, Message passing (Point-to-point) 2 steps: • Partial state model (busy states, separate interaction and computation) • Replace multiparty interactions by communication protocols Ref: “Distributed Semantics and Implementation for Systems with Interaction and Priority”, A. Basu, P. Bidinger, M. Bozga and Joseph Sifakis, FORTE 2008

26. BIP Engine: Symbolic • Symbolic implementation of execution model of BIP. • Performance of enumerative evaluation of connectors: • no. of interactions exponential to no. of ports in a connector (worst case) • Boolean representation of behavior fB (ports, states, guards) and connectors fC (ports, guards), as BDD, created once. • Interaction: given global state q, valuation a of ports, (a,q) ╞ fB fC q • Comparison: • Enumerative ~ no. of connectors • Boolean ~ no. of components (q computed on each step) • Limitations: no guards in behavior, connectors (ongoing work); performance restricted to particular type of applications. Ref: “The Algebra of Connectors – Structuring Interaction in BIP” S. Bliudze, J. Sifakis, EmSoft 2007

27. BIP: Basic Concepts • Modeling Interactions • Modeling Priorities • Implementation • Applications • Conclusion 27

28. tick x:=0 tick x++ x=10 x<10 PR: red_guards tick  all_other_interactions tick tick tick tick Timed Components timeout p

29. Applications • Benchmarks: • Software Componentization • Modeling mixed hw/sw systems

30. Software Componentization Componentization of the functional layer of an autonomous robot

31. Modeling Functional Level of a Robot • Functional Level: modules developed using GenoM, provides services and posters. • Centralized execution control: R2C, safety constraints and rules. Source: AMAES project (LAAS, LIAFA, Verimag)

32. Componentization of the functional level • Functional Level ::= Module+ • Module ::= Service+ . Control Task . Poster+ • Service ::= Execution Task . Activity • Control Task ::= Timer . Scheduler Activity Source: AMAES project (LAAS, LIAFA, Verimag)

33. BIP model of a ‘Service’ GenoM BIP Source: AMAES project (LAAS, LIAFA, Verimag)

34. BIP model of a ‘Module’ GenoM BIP Source: AMAES project (LAAS, LIAFA, Verimag)

35. BIP model of the NDD module Source: AMAES project (LAAS, LIAFA, Verimag)

36. Remarks • BIP specification along with the Engine generates the controller of the functional layer. • Guarantees the functional properties specified in the BIP specification. (e.g., guards in connectors) • Generated code integrated and tested in the real robotic framework. Ref: “Incremental Component-Based Construction and Verification of a Robotic System”, A. Basu, M. Gallien, C. Lesire, T. Nguyen, S. Bensalem, F. Ingrand and J. Sifakis, ECAI 2008

37. Modeling mixed hw/sw systems Modeling and Verification of Networked Systems - A Case Study on TinyOS based Networks

38. Motivation • Wireless Sensor Networks : Complex systems, rich dynamics. • Design involves composition of hw & sw components: different methodology, tools. • Simulation environments: ad hoc integration of application code to specific platform. • Effect of specific component feature on global behavior: limited understanding. • Componentized model : enhanced analysis, early error detection

39. Componentization • Network = Nodes+ .Radio-Channels • Node = nesC appln. TinyOS • nesC appln = Command* . Event* . Task* • TinyOS = Task-Sch. Evnt-Sch . h/w comp+ • h/w comp = Timer | Sensor | Radio-Ctrl

40. Componentization Application nesC Program Platform TinyOS

41. A nesC Module in BIP call ret sig ack post beg IDLE fin id t ID EXE call pre ret SUSP res post ack sig beg fin pre res

42. beg fin sig pre res eCount res [eCount=0] sig IDLE ACCEPT e BUSY2 fin [stack¹f] id:=stack.pop eCount-- pre stack.push(id) fin [stack=f] eCount-- sig stack beg fin post beg eCount++ res [eCount>0] BUSY1 PREEM PT id id post fifo.push(t) fifo fin t BUSY FREE beg [fifo¹f] fifo.pop post fifo.push(t) A TinyOS Schedulers in BIP Event Scheduler Task Scheduler

43. Global System Architecture Command handler Tasks handler Event handler User application pre1 beg1 beg1 res1 pre1 pre1 res1 fin1 res1 fin1 resi prei prei resi begi fini prei begi resi fini Preempt Resume EFinish1 TBegin EFinishi TFinish1 EBegin TFinishi Signal1 sig1 Platform res pre beg fin fin beg Timer/ Sensor sig Task Scheduler sigi Signali Event Scheduler

44. Remarks • A general methodology for building global models of heterogeneous systems. • Obtained by composition of execution platform model and application s/w model. • Global model: enhanced analysis (verification by state-space exploration) • Platform model needs right level of granularity to capture events whose properties are to be verified. • Can be adapted to other languages/platforms. Ref: “Using BIP for Modeling and Verification of Networked Systems – A Case Study on TinyOS-based Networks”, A. Basu, L. Mounier, M. Poulhies, J. Pulou and J. Sifakis, NCA 2007

45. Conclusions • Clear separation between behavior and architecture • Architecture = interaction + priority • Minimal set of constructs and principles • Correctness-by-construction techniques for deadlock-freedom and liveness, based on sufficient conditions on architecture • Expressiveness results • BIP is as expressive as the most general glue • Separation between interaction and priority for enhanced analysis and system construction methodology • Applications • Software componentization • Modeling mixed HW / SW systems e.g. motes

46. Thank you!