modeling and analyzing real-time corba and supervision & control framework and applications
Post on 31-Dec-2015
33 Views
Preview:
DESCRIPTION
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
top related