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

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

2. 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)

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

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

5. Based on “CORBA Priority” Platform independent Priority Schema based Rate Monotonic Theory Scheduling policies RT-CORBA model

6. All schedulable entities inherit from a common ancestor “Thread” class • 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).

7. RT-CORBA model • Example of a simple description of periodic thread • ready  Lastedei(fsmState(Idle), Period) • end  fsmState(Active)  (totalTime  ExTime)

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

9. CORBA Object Thread class • State diagram of Thread class enriched with new state • Through inheritance

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

11. Example axioms in the Rate Monotonic Scheduler model • Nec&suff condition for activating thread n • it is the highest priority “ready to run” threadSda 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)

12. Real-Time Event Service Model • Features • Only Push semantics, for performance • Quality of Service • Predictable event dispatching • Dispatch semantics • Acknowledgement • Logging • Expiring • Priority

13. 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)

14. 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 )

15. Notification Channel Architecture • Three kinds of objects • Proxy suppliers • Proxy consumers • Queues • Simplest possible configuration

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

17. 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) )

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

19. 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 • Values read by sensors on the field • Intermediate view (validity index) • Abstract view of the system state

20. A Supervision Application: a valve and pipe system • A “Safety” property: a malfunctioning in one sensor detected within T seconds

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

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

23. 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”

24. RT-CORBA Application Analysis • Proof outline: four Lemmas • message dispatching bound by Tm seconds mMsg (2ROA_time(m) + CORE_time(m) < Tm • 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

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