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
Service
Client
Clients
Server
RT_CORBA::
Priority
Servants
ROA (RT-POA)
• Scheduling policies
RT-ORB
IIOP (GIOP/TCP) – ESIOP – (other IOPs)
• All schedulable entities inherit from a common ancestor “Thread” class
Ready
ready
Ready to Continue
Ready to Start
activate
init
Active
end_and_ready
suspend
Idle
end
• 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 slices
fsmState(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
CORE Thread
ROA Thread
CORBA Object
Thread
Proxy
Consumer
Proxy
Supplier
CORBA Object Thread class
• State diagram of Thread class enriched with new state
– Through inheritance
Ready
ready
Ready to Continue
Ready to Start
server_res
suspend
activate
Active
msg_data(msg)
end_and_ready
activate
init
end
Idle
server_call
Waiting Server
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[n].activate
thread[core_domain]: CORE_Thread
thread[n].suspend
thread[roa_domain]: ROA_Thread
thread[n].init
thread[app_domain]: CORBA_Object_Thread
...
(other implementation clauses)
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(mn  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(mn  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 channel
NB: arrows represent predicates shared among specification modules,
not actual connections (communication is mediated by the ORB)
EventService
CPush1
Consumer1
Supplier1
SPush1
Notification
Channel
CPush2
Consumer2
SPush2
Supplier2
CPush3
Consumer3
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
Proxy
Supplier
Event
Queue
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(tperiod  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
P
C
SO
Fin
Fout
T
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 system
1. 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
FlowNetwork
Flowin
CFin
SFin
SFout
Notification
Channel
Flow
CFout
Flowout
• A “Safety” property: a malfunctioning in one sensor
detected within T seconds
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 Lemmas
1.
message dispatching bound by Tm seconds
mMsg (2ROA_time(m) + CORE_time(m) < Tm
2.
3.
4.
time between two executions of “Flowin” and “Flowout” threads
bound by Tfin and Tfout
Flow object activated at most Tf seconds after Flowin and
Flowout pushed their messages
A suitable combination of above time bound <= T
Tfin + Tfout + WCET(Flow) +
+ 2(2Tm + 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