1 / 21

Model-Checking of Component-Based Real-Time Embedded Software Based on CORBA Event Service

Model-Checking of Component-Based Real-Time Embedded Software Based on CORBA Event Service. Yuanfang Zhang for Seminar CSE7216. Presentation based on Zonghua Gu and Kang G. Shin, Model-Checking of Component-Based Real-time Embedded Software Based on CORBA Event Service ,

edita
Download Presentation

Model-Checking of Component-Based Real-Time Embedded Software Based on CORBA Event Service

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Model-Checking of Component-Based Real-Time Embedded Software Based on CORBA Event Service Yuanfang Zhang for Seminar CSE7216 Presentation based on Zonghua Gu and Kang G. Shin, Model-Checking of Component-Based Real-time Embedded Software Based on CORBA Event Service, Proceedings of 8th IEEE International Symposium on Object-oriented Real-time distributed Computin (ISORC'05)

  2. Outline • Problem • Verification of component-based real-time embedded software based on CORBA Event Service • Example: Avionics Mission Computing (AMC) • Finite State Processes (FSP) • Formalize specification of software components and system architecture • Labeled Transition System Analyzer (LTSA) • Exhaustively exploring the system state space to prove certain system properties • Scalability improvement • State space explosion

  3. AMC • Event Triggers • Publish/Subscribe • Method Invocations • Receptacle/Facet • Control-push/data pull (data push)

  4. FSP - event prefix If x is an event and P a process then (x-> P) describes a process that initially synchronizes with the event x and then behaves exactly as described by P. ONESHOT = (once -> STOP). ONESHOT state machine (terminating process) Convention: events begin with lowercase letters PROCESSES begin with uppercase letters

  5. FSP - recursion Repetitive behaviour uses recursion: SWITCH = OFF, OFF = (on -> ON), ON = (off-> OFF). Substituting to get a more succinct definition: SWITCH = OFF, OFF = (on ->(off->OFF)). And again: SWITCH = (on->off->SWITCH).

  6. FSP - choice If x and y are events then (x-> P | y-> Q) describes a process which initially engages in either of the events x or y. After the first event has occurred, the subsequent behavior is described by P if the first event was x and Q if the first action was y. FSP model of a drinks machine : DRINKS = (red->coffee->DRINKS |blue->tea->DRINKS ).

  7. FSP – Composition Process • Primitive processes can be composed to form a composition process with the operator | | • If processes in a composition have a common shared event, all processes must synchronize on the shared event at the same step MAKER = (make -> done ->MAKER) USER = (ready -> use ->USER) | | MAKER_USER = (aMaker:MAKER | | aUser:USER) /{aMaker.done / aUser.ready} MAKER = (make -> ready ->MAKER) USER = (ready -> use ->USER) | | MAKER_USER = (MAKER | | USER)

  8. Modeling AMC with FSP ClosedEDComponent ClosedEDComp = (inEvt -> issueGDCall ->receiveGDReply -> outEvt -> ClosedEDComp | receiveGDCall -> issueGDReply ->ClosedEDComp). OpenEDComponent OpenEDComp = (inEvt -> issueGDCall ->receiveGDReply -> outEvt -> OpenEDComp | receiveGDCall -> issueGDReply ->OpenEDComp | receiveSDCall -> issueGDCall -> receiveGDReply -> issueSDReply -> outEvt -> OpenEDComp • DeviceComponent • DeviceComp = (inEvt -> outEvt -> DeviceComp • | receiveGDCall -> issueGDReply -> DeviceComp). • DisplayComponent • DisplayComp = (inEvt -> issueGDCall -> receiveGDReply -> display ->DisplayComp).

  9. FSP – Component Interactions (1) • Control-Push / Data-Pull • Synchronous: pairwise interactions between components happen instantaneously without the delays introduced by the middleware

  10. FSP – Component Interactions (2) • Input Event Correlation • AND synchronization / OR synchronization

  11. FSP – Component Interactions (3) • Real-Time Issues • A global event tick is shared among all the timers • Schedulable (add an explicit synchronization between the timer and the terminal events) Both 2 display components have been triggered before next 20hz timeout

  12. FSP – an example application

  13. Verify System Properties • Safety • Deadlock freedom • Circular dependency • Multiple input events with AND synchronization, but not all of them are available • Event reachability • Sequencing constrains • Liveness • progress

  14. Deadlock Freedom LTSA:

  15. Event reachability & Sequencing constrains

  16. Progress Property • The action will be executed infinitely often in any infinite execution of a system progress P1 = {navDisplay.display}

  17. Scalability • Lack of scalability due to state-space explosion • Out-of-memory • Exploit domain-specific constraints • Omit the synchronization action • Compose and check the system hierachically • Can not check for end-to-end sequencing contraints that span multiple groups and involves internal events from these groups

  18. Exploit domain-specific constraints • Reduce the call-return two-way synchronization into a one-way synchronization

  19. Both Display components are required to be triggered before the next 1Hz timeout

  20. Performance Evaluation • 3 components to 50 components • Seconds or at most a few minutes • Hundreds of thousands of components • No model checker can scale up to this size • Rely on designer’s manual work to separate and model-check them individually

More Related