modeling and analyzing real-time corba and supervision & control framework and applications

25
Modeling and Analyzing Real-Time CORBA and Supervision & Control Framework and Applications Fernando Marotta, Angelo Morzenti, Dino Mandrioli Dipartimento di Elettronica Politecnico di Milano, Milano, Italia

Upload: karina-baldwin

Post on 31-Dec-2015

33 views

Category:

Documents


2 download

DESCRIPTION

Modeling and Analyzing Real-Time CORBA and Supervision & Control Framework and Applications. Fernando Marotta, Angelo Morzenti, Dino Mandrioli Dipartimento di Elettronica Politecnico di Milano, Milano, Italia. Supervisor & Control Systems. Examples: plant control systems - PowerPoint PPT Presentation

TRANSCRIPT

Modeling and Analyzing Real-Time CORBA and Supervision & Control Framework and

Applications

Fernando Marotta, Angelo Morzenti, Dino Mandrioli

Dipartimento di Elettronica

Politecnico di Milano, Milano, Italia

Supervisor & Control Systems

• Examples:

– plant control systems

– traffic management systems

– energy distribution systems

• Often

– Distributed • Built on top of CORBA

– Critical • Need high dependability and predictability

– CORBA 3 with quality of standard for Real-Time (RT-CORBA)

• Our purpose: define

– formal framework for developing S&C applications

– Design / Verification methodology

• The idea:

– Formalize RT-CORBA

Application requirements

High-Level Design

– Proof of correctness similar to that for programs based on • Language Semantics

• I/O assertions

• Program code

• Formalization in TRIO

– A quantitative linear temporal logic with OO constructs

• Work result of ESPRIT Project OpenDREAMS

• Talk deals (mainly via examples) with

– Formalization of RT-CORBA

– Real-Time Event Service

(an OpenDREAMS implementation of CORBA Event Service)

– A (toy) S&C application

– Outline of a correctness proof

RT-CORBA model

• Based on “CORBA Priority”

– Platform independent Priority Schema

– based Rate Monotonic Theory• Scheduling policies

Client Server

SchedulingService

RT_CORBA::Priority Servants

ROA (RT-POA)

RT-ORB

IIOP (GIOP/TCP) – ESIOP – (other IOPs)

Clients

• All schedulable entities inherit from a common ancestor “Thread” class

end_and_ready

activate

Ready to ContinueReady to Start

suspend

init

end

ready

Idle

Active

Ready

• TRIO Model of timing features of threads

totalTime total CPU time consumed by thread

actualTime CPU time consumed in current slice

achievedTime CPU time consumed in previous slicesfsmState(Active) t(actualTime = t LastTime(Becomes(fsmState(Active)), t))

(fsmState(Active) totalTime = achievedTime) (fsmState(Active)

totalTime=achievedTime+actualTime).

RT-CORBA model

• Example of a simple description of periodic thread

– ready Lastedei(fsmState(Idle), Period)

– end fsmState(Active) (totalTime ExTime)

ORB model: model all computational objects

• All threads are heirs of a common Thread class

• ORB thread classes: CORE Thread + ROA Thread

– but queues are passive data objects – not schedulable

• CORBA Object Thread also issue ORB calls

Thread

ROA ThreadCORBA Object

ThreadCORE Thread

ProxySupplier

ProxyConsumer

CORBA Object Thread class

• State diagram of Thread class enriched with new state– Through inheritance

end_and_ready

server_res

server_call

Waiting Server

activate

Ready to ContinueReady to Start

suspend

init

end

ready

activate

Idle

Active

msg_data(msg)

Ready

Structure of a generic ORB configuration

• Modeled as a TRIO specification of a Rate Monotonic Scheduler

– Lines: predicates shared among specification modules

– “sets” of threads depicted as “rows” of modules• Accessed via array notation

ORB_Side_RMS

thread[treadDomain]: Thread

thread[core_domain]: CORE_Thread

thread[roa_domain]: ROA_Thread

thread[app_domain]: CORBA_Object_Thread

...(other implementation clauses)

thread[n].activate

thread[n].suspend

thread[n].init

Example axioms in the Rate Monotonic Scheduler model

• Nec&suff condition for activating thread n

– it is the highest priority “ready to run” thread Sda

thread[n].activate thread[n].fsmState(ReadyToRun) m(mn thread[m].fsmState (ReadyToRun)

thread[n].priority<thread[m].priority)

• Nec&suff condition for suspending thread n

– there is is a “ready to run” thread with higher priority

thread[n].suspend thread[n]. fsmState (Active) thread[n]. end m(mn thread[m]. fsmState (ReadyToRun) thread[m].priority > thread[n].priority)

Real-Time Event Service Model

• Features

– Only Push semantics, for performance

– Quality of Service• Predictable event dispatching

• Dispatch semantics– Acknowledgement

– Logging

– Expiring

– Priority

Real-Time Event Service Model

• Communication between supplier and consumer mediated by Notification Channel

• Example: 2 suppliers, 3 consumers, 1 notification channelNB: arrows represent predicates shared among specification modules, not actual connections (communication is mediated by the ORB)

EventService

Notification Channel

Supplier1

Supplier2

Consumer1

Consumer2

Consumer3

SPush1

SPush2

CPush1

CPush2

CPush3

Real-Time Event Service Model

• Example: redefining (by inheritance) axiom for ready state in Consumer class

ready

Lastedei(fsmState(Idle), Period) t(Past(CPush1 fsmState(Idle),t)

Lasted(fsmState(Idle), t) )

(the object is ready to start iff it has some event to process )

Notification Channel Architecture

• Three kinds of objects

– Proxy suppliers

– Proxy consumers

– Queues

• Simplest possible configuration

Notification Channel

Proxy

Consumer

Event Queue

Proxy

Supplier

Notification Channel Architecture

• Example: formalization of semantics of Proxy Consumer

EventQueuePut(m) end EventQueueReady msgData(m)

messages are put in the queue

at the end of the processing of the consumer,

provided that the queue storing events is available

Schedulability of threads

• Conceptual framework chosen by OMG

– Rate Monotonic Theory

• Simplest possible case: two parameters

– Worst Case Execution Time (WCET)

– Period

• Example: axiom for activation of a Proxy Supplier object

event queue ready (first action by proxy supplier is a queue get)

and an interval >= scheduling period elapsed since last activation

activable (EventQueueReady t(tperiod LastTime(threadReadyState(ReadyToStart)activate,t) )

A Supervision Application: a valve and pipe system

• Flow measured by two sersors Fin and Fout

• Goal of the application: monitor flow and validate measurements

– by comparing the two flows in and out• They must be equal, up to an approximation

CP

TFin Fout

SO

SC

A Supervision Application: a valve and pipe system

• A general paradigm:

– S&C applications: acyclic network of application objects exchanging info through comm. channels

– Compute several views of the monitored system1. Values read by sensors on the field

2. Intermediate view (validity index)

3. Abstract view of the system state

A Supervision Application: a valve and pipe system

• A “Safety” property: a malfunctioning in one sensor detected within T seconds

FlowNetwork

Notification Channel

Flowin

Flowout

Flow

SFin

SFout

CFin

CFout

A Supervision Application: a valve and pipe system

• steps to obtain a model for the whole system – formalize ORB objects (obtain ORB(s) configuration)

– configure Event Service (event types, Notification Channels …)

– define application objects (scheduling parameters, priority, event type dispatched …)

– compose objects into a unique specification modeling the entire supervision system

A Supervision Application: a valve and pipe system

• Results for this example

– 1 CORE thread, 1 ROA thread • share the same message queue

– 1 Notification channel for all messages

– A single ORB, located on a LAN close to the field

– Objects closer to the field have higher priority• CORE thread > ROA thread > notification channel proxy-supplier >

notification channel proxy consumer > application objects

RT-CORBA Application Analysis

• Proof outline of safety property

“a malfunctioning in one sensor detected within T seconds”

• Reformulated as

“interval between two computations of the Flow object <= T”

RT-CORBA Application Analysis

• Proof outline: four Lemmas1. message dispatching bound by Tm seconds

mMsg (2ROA_time(m) + CORE_time(m) < Tm

2. time between two executions of “Flowin” and “Flowout” threads

bound by Tfin and Tfout

3. Flow object activated at most Tf seconds after Flowin and

Flowout pushed their messages

4. A suitable combination of above time bound <= T

Tfin + Tfout + WCET(Flow) +

+ 2(2Tm + WCET(proxy-supplier) + WCET(proxy-consumer)) T

Conclusions• Combine in a unique rigorous framework

– Requirements specifications– Analysis– Design– Verification

• Method applied in the domains of– Energy power plant – Air traffic management systems

• Currently (still) looking for ORB– CORBA compliant– Real Time– Public domain