Journée Informatique Embarquée Du Matériel au Logiciel PolyORB a schizophrenic middleware

Journée Informatique EmbarquéeDu Matériel au Logiciel

PolyORBa schizophrenic middleware

Laurent Pautet, ENST Fabrice Kordon, LIP6/SRCJérôme Hugues, ENST

Khaled Barbaria, ENST

Thomas Vergnaud, ENST

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

policiesVarious facilities: DOC, RPC, MP, (D)SMStandards: CORBA, DSA, JMSExtensions: RT-*, fault tolerance, etc

Target Resources & semantics: concurrency, scheduling, buffers, ..

Concern #1: How to ensure correctness, using COTS ?


“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


Building a generic, configurable and verifiable middleware

Reorganize middleware functionalities to reduce components coupling

like an OS on top of a micro-kernelDefine generic building blocks describing middleware

interactions Addressing, Binding, Representation, Protocol, Transport,

Activation, ExecutionLet 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


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 Middlewarefunctions

Application personalitiesCORBA (DOC) MOMA (MOM)

AWS (WEB)

DSA (RPC)

GIOP SOAP

DIOP (UDP)

MIOP (multicast)Protocolpersonalities


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


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 neutralTo be extended

To model


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 ;)

D1

ScheduleTaskE_Work

ThreadsScheduleTaskE_Idle

D4

WaitForAnotherTaskToAbortBlocking

NOPEP

SourcesAbourtToModifySrc

ORB_Lock1

cIdleTasksnull2

WillPerformWork

NoCheck

Threads

IsMonitoring

1

cIsMonitoring

NoMonitoring

NeedMonitoring

Try_Check_Sources_EThreads

Try_Check_Sources_BThreads

Perform_Work_EThreads

RunBThreads

LeaveCSPW

ThreadsRunE

Run

NotifyEventJobCompleted

NotifyEventJobCompletedBThreads

NotifyEventJobCompletedE

Threads

EnterCSPW

LeaveIdle[t=t2]

GoPerformWork

GoCheckSource GoIdle

ThreadsIdle

<2>,<3>

DummyOR1

DummyOR2

ModifiedSrcSources

Check_Sources_EThreads

Check_Sources_BThreads

<1>

NotifyEventEndOfCheckSourcesEThreads

NotifyEventEndOfCheckSourcesBThreads

ThreadsThreadsThreadsThreadsnyo

Threads

EnterCSTCS

ThreadsProcessingEvt

LeaveCSTCS

cSources

10

CreatedJobsD6

D4

Threads

AvailableJobId

Jobs<Jobs.all>

DummyIS

ThreadsNotifyEventSourceAddedE

LeaveCSIS

EnterCSIS

Insert_Source_EThreads

Insert_Source_BD4

Class Jobs is 1 ..3 ; Sources is 1 ..3 ; Threads is 1 ..3 ; Domain D1 is <Threads, Jobs>; D4 is <Threads, Sources>; D6 is <Jobs, Sources>; Var j in Jobs; j1 , j2 , j3 , j4 , j5 , j6 , j7 , j8 , j9 , j10 in Jobs; s in Sources; s2 in Sources; ms1 , ms2, ms3 , ms4 , ms5 , ms6 , ms7, ms8 , ms9 , ms10 in Sources; t in Threads; t2 in Threads;

ThreadsNotifyEventSourceAddedB

NotifyEventSourceAdded

IsEvt

[s=s2]

NoSigAbort

1

SourcesSources

<Sources.all>

IsAbort

SigAbort

Abort_Check_Sources_BThreads

NopAbort

Abort_Check_Sources_EThreadsDataOnSrc

Sources<Sources.all>

SetSigAbort

CanInjectEvent1

ScheduleTaskBThreads

ScheduleTaskE_CheckThreads

Jobsf3

FetchJobBThreads

mo3mo2

1mo1

FetchJobED1

Jobsf2

Jobsf1

mi3mi21mi1

DisablePollingBD4

DisablePollingED4

WaitforBlockedTasks

WaitCompleted

NOPDP

BlockedTasks

1

cPollingAbort

10

PollingAbort

cBlockedTasks

9

EnablePollingBThreads

EnablePollingEThreads

Threads

TryAllocateOneTaskBThreads

TryAllocateOneTaskEThreads

Threads

QueueJobBD1

QueueJobE

Threads

NotifyEventJobQueuedB D1

NotifyEventJobQueuedEThreads

IdleTasksThreads

<2>,<3>

AwakeTasksThreads

JobCntnullcJobCnt

10

Threads

Jobsf4

Jobsf5

mi4

mo4

mi5

mo5

<t>

<t,j>

<j>

<t,j>

<t>

<j>

<t>

<t,j>

<j>

<t,j>

<t>

<j>

<t>

5

<t,ms1>+<t,ms2>+<t,ms3>+<t,ms4>+<t,ms5>

<ms1>+<ms2>+<ms3>+<ms4>+<ms5>

5

<t>

<t>

10

5*<t>

<t>

<t>

<t,s>

<t,s>

<t,s>

<t>

<t>

<j>

<j,s>

<t>

<t>

1010

<t2>

<t2>

<t2>

<t>

<t,j>

<t>

<t>

<t>

<t,j>

<t,j>

<t>

<t><t><t>

<t>

<t,j><t,j><t,j>

<t,j>

10

10

<t,s>

10

10

<t>

<t>

10<t,s>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t,j>

<t><j>

<j>

<t><t>

<t,j><t,j>

<j><j>

<j><j>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<s2>

<s>

<t><t>

<t><t>

<s>

<t>

<t>

<t>

<t,s>

<t>

<t>

10101010

<t>

<t>

<t>

<t>

4*<t>3*<t>2*<t><t>

<t><t><t><t>

<t><t><t><t>

<t>

6789

<t,s>

<t><t><t><t>

2 3 4

<t> <t> <t> <t>

<t,ms1>+<t,ms2>+<t,ms3>+<t,ms4><t,ms1>+<t,ms2>+<t,ms3><t,ms1>+<t,ms2><t,ms1>

<j>

<j,s>

<t>

<t>

<t>

<t>

<t>

<s>

<s>

<s>

<ms1>

<ms1>+<ms2><ms1>+<ms2>+<ms3><ms1>+<ms2>+<ms3>+<ms4>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

<t>

4

4

<s>

<s>

<t>

<t>

<t>

<t>

<t>

<t>

10

10

<s>

<t,s>

<t,s>

<t,s>

<t,s>

<t,s>

<t,s>

210

10

<t>

<t>

<t,j>

<t,j>

9

Source & Event Mgt

FIFO

Follower ThreadsLeader

Thread

T: # threadsS: # sourcesB: size of the FIFO


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 toavoid performance dispersion

O(1) algorithmswhenever possible

Implementation of RT-CORBA Static scheduling,

RTCOSScheduling TDMA-based or Token-based

real-time protocols on ethernet

Combine elements to buildprecisely real-time middleware

Careful selectionof each element

RTCORBA

RTPOA

GIOP

TDMA

Neutral Core

Perfect Hash

Lanes

QoS

Perfect Hash

Ravenscar RTS

Leader/Followers

Event Chk. Policy


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

Dispersion of RPC duration around mean value

0

100

200

300

400

500

600

700

800

900

<0,75

0,75

-0,8

0

0,80

-0,8

5

0,85

-0,9

0

0,90

-0,9

5

0,95

-0,9

8

0,98

-1

1,00

-1,0

2

1,02

-1,0

5

1,05

-1,1

0

1,10

-1,1

5

1,15

-1,2

0

1,20

-1,2

5

>1,25

Dispersion

# o

f m

easu

res

Solaris/distributed/ST

Solaris/local/MT

Solaris/distributed/MT


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


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, …)


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


Modelling experienceAADL 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.


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

Documents

Journée Informatique Embarquée Du Matériel au Logiciel PolyORB a schizophrenic middleware