Building a Generic, Verifiable Middleware for DRE Systems

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

2. 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. “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. 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. PolyORB: schizophrenic middleware AWS (WEB) Application personalities CORBA (DOC) MOMA (MOM) DSA (RPC) Neutral Core Layer Middleware functions DIOP (UDP) Protocol personalities GIOP SOAP MIOP (multicast) • 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

6. 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. 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 To model Behavior neutral To be extended

8. Formal analysis, an exampleconfiguration leader/followers • Architecture clearly separates concerns, enables modeling • Use of Petri Nets: structural 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 ;) Follower Threads Source & Event Mgt Leader Thread FIFO • T: # threads • S: # sources • B: size of the FIFO

9. Towards real-time middleware (1/2) RTPOA RTCORBA Perfect Hash Lanes Perfect Hash Leader/Followers Ravenscar RTS Event Chk. Policy Neutral Core TDMA GIOP • Well-known design patterns and algorithms for building real time middleware: hash tables, events demux., Ravenscar compliant … • Stringent coding guidelines toavoid performance dispersion • O(1) algorithmswhenever possible • Implementation of RT-CORBA • Static scheduling,RTCOSScheduling • TDMA-based or Token-basedreal-time protocols on ethernet • Combine elements to buildprecisely real-time middleware • Careful selectionof each element QoS

10. 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. Proof-Based Real-Time COTS Middleware Heterogeneous yet complementary results: • Schizophrenic architecture • Clear definition of middleware internals • Enforce separation of concerns • Support for many distribution mechanisms • Formal Modeling & verification • One to one mapping between elementary models and code • Verified components and configurations • Modeling work can be adapted to other formalisms • 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. 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. 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. Modelling experienceAADL Technologies • Source code • Templates • Formal descriptions Generic AADL models of PolyORB Deployment information in AADL Configuration & generation tools Deployment tools Ocarina lib. Ocarina lib. AADL models of PolyORB instances Configured middleware • 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

15. 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