1. Journée Informatique Embarquée Du Matériel au Logiciel PolyORB a schizophrenic middleware Laurent Pautet, ENST Fabrice Kordon, LIP6/SRC Jérôme Hugues, ENST Khaled Barbaria, ENST Thomas Vergnaud, ENST

2. 2Journée Informatique Embarquée Laurent Pautet Distribution middleware for DRE systems  Distribution middleware becomes a COTS  Reduce cost, suppress tedious and error-prone work  DRE systems must abide to industry requirements  Domains: avionics, space, transport  Families: reliability, determinism, integrity  Middleware is versatile by essence  Many settings are available: protocols, QoS & security policies Various facilities: DOC, RPC, MP, (D)SM Standards: CORBA, DSA, JMS Extensions: RT-*, fault tolerance, etc  Target Resources & semantics: concurrency, scheduling, buffers,.. Concern #1: How to ensure correctness, using COTS ?

3. 3Journée Informatique Embarquée Laurent Pautet “Middleware engineering crisis”  Middleware for DRE is a moving target  Configurability: tuning middleware components  Genericity: deriving new repartition functions from existing ones  Non-functional needs: QoS, timeliness, fault-tolerance, determinism  Many successful stories in using middleware for mission-critical apps.  UIC, Armada,..: Too precise, not a COTS, yet efficient  TAO-family: adaptative, but too difficult to derive properties  CosMIC, TURTLE-P: CASE tools, distance to the actual code ?  Revisit COTS Middleware  Clearer view of middleware internals  “HOWTO” guide to adapt middleware  Avoid “minefields” COTS middleware

4. 4Journée Informatique Embarquée Laurent Pautet Building a generic, configurable and verifiable middleware  Reorganize middleware functionalities to reduce components coupling  like an OS on top of a micro-kernel  Define generic building blocks describing middleware interactions  Addressing, Binding, Representation, Protocol, Transport, Activation, Execution  Let interaction between building blocks be independent from any specific distribution model  Common behavioral contract => ease modeling  Propose one implementation for each generic building block  Enable code reuse  Properties  Generic services propose a coarse grain parameterization  Configuration is fine grain customization of blocks implementations

5. 5Journée Informatique Embarquée Laurent Pautet PolyORB: schizophrenic middleware  Schizophrenia: simultaneous support for multiple personalities in one middleware instance  Neutral core: common middleware components  CORBA (RT, FT), MOMA, DSA, SOAP, GIOP, MIOP personalities  Adaptability for specific needs: many distribution features  Clear design that reduces code complexity and ease prototyping  Strong engineering: Ravenscar, Ada Coding Style, compiler checks Neutral Core Layer Middleware functions Application personalities CORBA (DOC)MOMA (MOM) AWS (WEB) DSA (RPC) GIOPSOAP DIOP (UDP) MIOP (multicast) Protocol personalities

6. 6Journée Informatique Embarquée Laurent Pautet Schizophrenic middleware architecture  PolyORB genericity => canonical view of a middleware (PIM-like model)  Seven functions coordinated by the « µBroker »  Can be reduced to canonical components: dictionary, queues, filters,..  Neutral wrt middleware behavior  µBroker at the core of the middleware behavior  Allocates task to handle I/Os, requests  Schedule tasks, dispatch requests  Manages middleware state Network

7. 7Journée Informatique Embarquée Laurent Pautet Using the Schizophrenic architecture  Personality: 3 to 20 KSLOCs  «clients» of the Neutral Core  Extend or use the Core to match specific semantics  High code reuse (up to 75%)  Neutral Core: 30 KSLOCs  Library of helper routines  7 key fonctions, well-known patterns Automata, filters, dictionaries,..  “µBroker” heart of the middlware  Schedule the services Resource allocation Access to I/O Job scheduling Many availble policies  Control MW’s behavior Interactions Behavior neutral To be extended To model

8. 8Journée Informatique Embarquée Laurent Pautet Formal analysis, an example configuration leader/followers  Architecture clearly separates concerns, enables modeling  Use of Petri Nets: s tructural properties & temporal logic  symmetries, liveness, bounds, LTL formula..  MW Model components => library of PN models to build  Properties  P0: symmetry, P1: no deadlock  P2: consistency, P3: fairness Combinatorial explosion expected and solved using the CPN-AMI tools ;) Source & Event Mgt FIFO Follower Threads Leader Thread  T: # threads  S: # sources  B: size of the FIFO

9. 9Journée Informatique Embarquée Laurent Pautet Towards real-time middleware (1/2)  Well-known design patterns and algorithms for building real time middleware: hash tables, events demux., Ravenscar compliant …  Stringent coding guidelines to avoid performance dispersion  O(1) algorithms whenever possible  Implementation of RT-CORBA  Static scheduling, RTCOSScheduling  TDMA-based or Token-based real-time protocols on ethernet  Combine elements to build precisely real-time middleware  Careful selection of each element RTCORBA RTPOA GIOPTDMA Neutral Core Perfect Hash Lanes QoS Perfect Hash Ravenscar RTS Leader/Followers Event Chk. Policy

10. 10Journée Informatique Embarquée Laurent Pautet Towards real-time middleware (2/2)  Good performances on Solaris  Performance measures exhibit good dispersion properties  Under evaluation on  ORK RTK (Ravenscar)  MaRTE OS (Minimum POSIX)  RTEMS  Architecture enables precise scheduling analysis  Feasible to derive schedulabity conditions  Memory footprint < 500KB  Reduced capabilities  Fit in embedded systems

11. 11Journée Informatique Embarquée Laurent Pautet Proof-Based Real-Time COTS Middleware Heterogeneous yet complementary results: 1. Schizophrenic architecture  Clear definition of middleware internals  Enforce separation of concerns  Support for many distribution mechanisms 2. Formal Modeling & verification  One to one mapping between elementary models and code  Verified components and configurations  Modeling work can be adapted to other formalisms 3. Performance and metrics  Implementation is compliant with real-time engineering practice  Deterministic components  Promising performance  Increasing support for Real-Time Kernels 1+2+3 => Proof-Based Real Time Middleware

12. 12Journée Informatique Embarquée Laurent Pautet PolyORB modelling using ADL  Rationale  Deploy distributed system and define logical nodes  Configure each logical node  Configure and instanciate PolyORB components on each logical node  Associate components with their behavioural models  Have a clear understanding of PolyORB architecture  ADL for specific domains  Distributed systems  Real-Time Systems  Embedded Systems  AADL = Architecture Analysis and Design Language (SAE)  MetaH : a first proposal from SAE  COTRE (AirBus, …)  ASSERT (ESA, …)

13. 13Journée Informatique Embarquée Laurent Pautet Principles of AADL  AADL Description = set of components  Each component has an interface (component type) and none, one or several implementations (component implementation)  3 categories of components: Software : data, process, thread subprogram Execution platform : memory, processor, bus, device System : container, structure of the architecture  Components communicate through ports, described in the interfaces  Ports are connected using connections  Properties can be associated with the elements of a description  Standard properties (defined in the AADL standard) Execution time Source code for behavioural descriptions …  Property sets For user-defined properties

14. 14Journée Informatique Embarquée Laurent Pautet Modelling experience AADL Technologies  Modelling PolyORB  AADL provides a common & unified notation  Architectural description (software components)  Behavioural description (associated source code)  Middleware & global system configuration (properties)  Models for neutral core layer ( “µBroker”), application et protocol personalities  Tools required for multiple needs  Architecture consistency, schedulability analysis, simulation and verification, …  node configuration, system deployment, code generation, component assembly, …  Few AADL technologies : OSATE (SAE), …  Ocarina  Deploy the distributed system  Configure each logical node  Generate a PolyORB instance  Need for light and “decentralized” tools  Ease the extension of AADL Generic AADL models of PolyORB ● Source code ● Templates ● Formal descriptions Configured middleware Deployment information in AADL Deployment tools Ocarina lib. AADL models of PolyORB instances Configuration & generation tools Ocarina lib.

15. 15Journée Informatique Embarquée Laurent Pautet Conclusion & future work  Schizophrenic middleware: enable PBSE Real-Time middleware  Configurability and extreme genericity  Clear design that enable modeling with Petri Nets, contemplate AADL  Verification of its key properties using novel algorithms Fights combinatorial explosion  Interesting real-time properties  Member of the ObjectWeb Consortium http://polyorb.objectweb.org  COTS supported http://libre.act-europe.fr  Perspectives  PolyORB serve as a foundation for CASE tools  Next: Combine tools and modeling techniques to foster analysis of the architecture and derive schedulability conditions, ease deployment, etc  Using the Ocarina AADL toolsuite http://eve.enst.fr