1 / 15

Building a Generic, Verifiable Middleware for DRE Systems

This article explores the challenges of using COTS middleware for Distributed Real-Time Embedded (DRE) systems and proposes a solution for building a generic, configurable, and verifiable middleware. It discusses the reorganization of middleware functionalities, the use of generic building blocks, and the implementation of a schizophrenic middleware architecture using PolyORB.

kharmon
Download Presentation

Building a Generic, Verifiable Middleware for DRE Systems

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related