1. Supporting Model-driven Development of Component-based Embedded Systems with Cadena http://cadena.projects.cis.ksu.edu SAnToS Laboratory, Kansas State University, USA Matt Dwyer John Hatcliff Gurdip Singh Principal Investigators Support US National Science Foundation (NSF) US National Aeronautics and Space Agency (NASA) US Department of Defense Advanced Research Projects Agency (DARPA) US Army Research Office (ARO) Rockwell-Collins ATC Honeywell Technology Center and NASA Langley Sun Microsystems Intel Students William Deng Georg Jung Adam Childs Robby Venkatesh Ranganath

2. Distributed Components Network JavaC++C JavaC

3. Distributed Components Middleware (e.g. CORBA) Event ServiceTransaction Service Naming ServiceSynchronization Service JavaC++ C JavaC

4. Checking CCM Systems Middleware (e.g. CORBA) Event Service Transaction Service Naming ServiceSynchronization Service JavaC++ C JavaC Modern Software SystemsIssues These systems are huge! Extensive use of OO patterns & software layering What are appropriate abstractions for formal reasoning? How can we help developers write them? Useful properties? How must conventional model-checking engines be extended?

5. Cadena – CCM Development Integrated Development Environment CCM Interface Definition Language RT Aspect Specs State Transitions System Configuration Eclipse Plug-In High-level Specification Language Cadena High-level specification of abstract component behavior Visualization and design-level reasoning Code generation functions (via OpenCCM) produces code amenable to conformance checking and certification Configuration and Deployment information

6. Leverage CORBA IDL Component Implementation Stubs & Skeletons IDL Compiler + dependencydefault == none; dependencies { inDataAvailable -> outDataAvailable; } behavior { if (mode==enabled) { push outDataAvailable; else … } Dependency Annotations Transition System Semantics Dependency Analysis and Model-checking Engine Model Builder

7. Incremental Specification port action dependencies Increasing Effort & Strength of Verification SpecificationsComponent Structure state-based dependencies …only in mode Y Y component transition semantics …state machines give abstract behavior refinement

8. Avionics Mission Control Systems Mission-control software for Boeing military aircraft Boeing’s Bold Stroke Avionics Middleware …built on top of ACE/TAO RT CORBA Provided with an Open Experimental Platform (OEP) from Boeing a sanitized version of the real system 100,000+ lines of C++ code (including RT CORBA middleware) 50+ page document that outline development process and describe challenge problems Must provide… tool-based solutions that can be applied by Boeing research team to realistic systems solutions that fit within current development process, code base, etc. metrics for that allow Boeing research team to evaluate tool performance and ease of use

9. Control-Push Data-Pull Component A computes some data that is to be read by one or more components B i Typical situation A B1B1 BkBk Run-time Actions A publishes a dataAvailable event B i call the getData() method of A to fetch the data dataAvailable getData() Depending on current state, component may not fetch data

10. Control-Push Data-Pull Structure 1. Logical GPS component receives a periodic event indicating that it should read the physical GPS device. 2. Logical GPS publishes DATA_AVAILABLE event 3. Airframe component fetches GPS data by calling GPS GetData method 4. Airframe updates its position data and publishes DATA_AVAILABLE event 5. NavDisplay component fetches AirFrame data by calling AirFrame GetData method 6. NavDisplay updates the physical display 1 2 3 4 4 5 6 Input Output

11. Larger Configuration …moving up to 1000+ components

12. Example System

13. Basic components seen earlier

14. Example System Navigation Steering Subsystem

15. Example System Tactical Steering Subsystem

16. Example System Display Control on/off

17. Demo Outline 2. Component Connections 3. Dependence Information 4. Modal Behavior 1. Component Interface 5. Light-weight Analysis

18. Status of Cadena Binary releases for the past 7 months http://cadena.projects.cis.ksu.edu ~100 unique download sites; ~20 industrial Source release in Dec. 2003 Using it in a course this semester Implements Multiple specification forms Multiple analyses Synthesis of code via integration with OpenCCM A demo …

19. Verification of Cadena Models Publish/subscribe infra-structure semantics Time-triggered event occurrence Method call semantics Event correlation semantics Component Glue Semantics

20. Middleware/Service Semantics Weak CCM and Event Services Specs (OMG) Informal : English and examples Intentionally under-specified to allow implementor freedom Look at implemented semantics of existing ORBs and Event Services ACE/TAO, FACET, OpenCCM, K-State Developed a family of semantic models that captured their behavior

21. Outline of Real System Event channel with internal thread pool … Thread Pool … 60Hz20Hz5Hz1Hz ……… … passive components publish correlation & filtering proxy consumer holds list of consumer references consumer refs dispatch queues for each rate group Threads run call-backs associated with event consumer ports dataAvailable abstract event flow …in reality

22. Appropriate Model Reasoning Boeing engineers want to reason about system/component modes at design time Sequences of mode transitions, mode invariants, … Ideal for model-checking because… component modes range over finite sets of values mode-transitions are triggered by event/data-port actions only tiny portion of system’s state space needs to be exposed Mode-related requirements can be naturally captured as safety properties e.g., frame-bounded response

23. System Observations Event channel with internal thread pool … Thread Pool … 60Hz20Hz5Hz1Hz ……… … invoke[m,c] publish[e,c] dispatch[e] publish correlation & filtering consumer refs accept[e,s] eof[r] getData c.m == v

24. Functional Properties Property II: If navSteering is enabled when 20Hz timeout occurs, then airFrame should fetch navSteering data [before end of frame] Property II: If navSteering is enabled when 20Hz timeout occurs, then airFrame should fetch navSteering data [before end of frame] Property I: System never reaches a state where TacticalSteering and NavSteering are both disabled Property I: System never reaches a state where TacticalSteering and NavSteering are both disabled

25. Event-based Specifications Many of properties of interest in this domain are event oriented Some require access to state information A state qualified event (written e + f ) defines the occurrence of an observable event, e, in a state that satisfies a given formula, f. For example, If component c1 is in mode A when component c2 produces event E, then component c3 will consume event F.*; publish[E, c2] + c1.mode = a; [- invoke[F handler, c3]]* No trace of form

26. Domain-Specific Model-Checking Bogor -- Extensible Modeling Language Core Modeling Language Threads, Objects, Methods, Exceptions, etc. + Extensions Sets Queues Tables RT CORBA Event Service API Abstraction Domain-specific Abstractions + Event Service Scheduling Quasi-cyclic Search Partial State Representation Bogor -- Customizable Checking Engine Modules Scheduling Strategy State-space Exploration State-space Representation Core Checker Modules Customized Checker Modules …existing modules…

27. Modelling Components and Glue Event channel with internal thread pool … Thread Pool … 60Hz20Hz5Hz1Hz ……… … correlation & filtering Components Connections Subscriber Lists Correlators Dispatch Queues Threads Scheduler Time-triggered Events

28. Modeling of Components function tacticalSteering_push_inDataAvailable(CAD.Event event){ Data d; loc loc0: live {} when tacticalSteeringMode do {} goto loc1; when !tacticalSteeringMode do {} return; loc loc1: live{d} when true do { d := CAD.getField (AirFrame, "ReadData.data"); } goto loc2; loc loc2: live{} when true do { CAD.setField (TacticalSteering, “dataOut.data", d); } goto loc3; loc loc3: live {} invoke pushOfProxy(TacticalSteering, “dataOutReady“) return; } handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } Structure follows component behavior spec and connection representation closely

29. Modeling Middleware (Threads) thread threadgroup5() { Pair.type pair; EventHandlerEnum handler; CAD.Event event; loc loc0: live { handler, event } when Queue.size >(Q5) > 0 do invisible { pair := Queue. getFront >(Q5); Queue.dequeue >(Q5); handler := Pair. first (pair); event := Pair.second (pair); } goto loc1; loc loc1: live {} invoke virtual f(handler, event) goto loc0; } … Thread Pool 60Hz20Hz5Hz1Hz Dispatch queue polling Retrieving (subscriber-ref, event) pairs from queue Retrieving (subscriber-ref, event) pairs from queue Retrieve address of event handler, then invoke handler

30. Modeling Middleware (Scheduling) … Thread Pool 60Hz20Hz5Hz1Hz ……… … Bold Stroke Systems are scheduled based on RMA run highest-priority (i.e., rate) enabled action many fewer schedules, contains all real schedules BOGOR allows encoding specific schedules Java plugin filters enabled actions in state exploration algorithm Typically model checkers use non- deterministic scheduling i.e., choose from set of enabled transitions in a state set of all such schedules contains all real schedules

31. Preliminary Results (Full Search) Basic 1 rate, 3 components, 2 events per hyper-period Multi-Rate 2 rates, 6 components, 6 events per hyper-period Modal 3 rates, 8 components, 125 events per hyper-period Medium 2 rates, 50 components, 820 events per hyper-period System ND Priority Lazily-Timed 20,.12s12,.11s14,.11s 120k, 5m100,.38s33,.19s 3M+, ?9.1k, 8.6s900, 1.3s 13M+, ?740k, 29m4k, 8.6s

32. Scaling to Real Systems We can already analyze systems that are within an order of magnitude of fielded mission-critical systems To go further there are several possible approaches Assume-guarantee decomposition Exploit structure of periodic systems to decompose model check

33. “Cyclic” Systems l1: y = 0; goto l2; l2: x = 0; goto l3; l3: true -> x = 2; goto l4; true -> x = 3; goto l4; l4: y = y + x; goto l5; l5: y>5 -> skip; goto end; y skip; goto l2; end: Many systems have a cyclic structure e.g., web-server, GUI, periodic real-time systems

34. (l1,0,0) (l3,0,0) (l2,0,0) (l2,3,5) (l5,3,5) (l4,3,2) (l3,0,4) (l2,2,4) (l5,2,4) (l4,2,2) (l5,3,7) (l4,3,4) (end,3,7) (l5,2,6) (l4,2,4) (end,2,6) (l4,3,3) (l5,3,6) (end,3,6) (l4,2,3) (l5,2,5) (l2,2,5) (l3,0,5) (l5,2,7) (l4,2,5) (end,2,7) (l5,3,8) (l4,3,5) (end,3,8) (l3,0,2) (l5,2,2) (l4,2,0) (l2,2,2) (l3,0,3) (l5,3,3) (l4,3,0) (l2,3,3)

35. Quasi-Cyclic Systems An equality predicate defines specific values for a subset of state variables e.g., pc = l3, x = 0 A system is quasi-cyclic if its traces are characterized by repeated visits of states that are start states; end states; or satisfy an equality predicate Each such state defines the start of a quasi- cyclic region

36. (l1,0,0) (l3,0,0) (l2,0,0) (l2,3,5) (l5,3,5) (l4,3,2) (l3,0,4) (l2,2,4) (l5,2,4) (l4,2,2) (l5,3,7) (l4,3,4) (end,3,7) (l5,2,6) (l4,2,4) (end,2,6) (l4,3,3) (l5,3,6) (end,3,6) (l4,2,3) (l5,2,5) (l2,2,5) (l3,0,5) (l5,2,7) (l4,2,5) (end,2,7) (l5,3,8) (l4,3,5) (end,3,8) (l3,0,2) (l5,2,2) (l4,2,0) (l2,2,2) (l3,0,3) (l5,3,3) (l4,3,0) (l2,3,3)

37. Predicate-bounded Search 3 9 8 7 7 8 Search each region independently max of 9 versus 37 states in full system Note that the sum here is >37 same state may appear in multiple regions Works well when reasonable fraction of state variables are cyclic Regions can be searched in parallel

38. Predicate for Cadena Dispatch threads are at their initial control point; Dispatch queues are empty; Correlation automata are in start state; Time thread is at its initial control point; Abstract time is 0; and All local variables have their initial values.

39. Scaling ModalSP # states

40. Conclusions Component IDL is a natural place to attach lightweight specs Spec forms are naturally incremental Dependence analyses are useful for property checking and as a precursor to other analyses Exploiting domain-specific information enables significant state-space reductions Flexible model checking support is essential for this Analysis-driven synthesis promises even greater benefits for developers http://cadena.projects.cis.ksu.edu

41. Related Work Building off of previous work… model-checking: JPF, dSpin, … pub-sub reasoning: Garlan, Allen, Dingel, … Lots of other tools for reasoning about embedded system designs… MetaH, Geodesic, Ptolemy,… We are currently working with middleware designers to design middleware that can be more naturally incorporated into model-driven architecture tools and analysis frameworks like Cadena

42. Verification of Cadena Models component BMModal { mode common.OnOffMode; dependencydefault == none; dependencies { case OnOffMode of { enabled: inDataAvailable -> dataIn.data[get], outDataAvailable; disabled: inDataAvailable ->; } BM_Modal TacticalSteering

43. Modeling of Connections CAD.connectEvent(GPS, “dataCurrent", AirFrame,"inDataAvailable", 20, false); instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut Modeled very directly in BOGOR

44. Extend model checker types Polymorphic extension Modeling Middleware (Queues) extension Queue for edu.ksu.cis.cadena.bogor.ext.Queue { typedef type ; expdef int size (Queue.type ); expdef int capacity (Queue.type ); expdef boolean isFull (Queue.type ); expdef boolean isEmpty (Queue.type ); expdef Queue.type create (int); actiondef enqueue (Queue.type, 'a); expdef 'a getFront (Queue.type ); actiondef dequeue (Queue.type ); expdef boolean containsPair (Queue.type,'a); } ……… Data in state space, operations implemented as Java code

45. Modeling of Environment Model time directly expensive (state space becomes acyclic) hard to get accurate timing info (platform specific) Boeing wasn’t very interested in time-properties other than schedulability Abstract time modeling strategies Timeouts can happen at any time Bound number of timeouts in hyper-period Bound relative number of timeouts in adjacent rate groups Approximate passage of time System behavior is driven by periodic time-triggered events

46. Modeling of Environment The maximum rate timeout count (tc) keeps track of the number of timeouts that have occurred during a hyper-period Assume a group of harmonic rates (R 1, …, R max ), where R max is the maximum rate Let p(R i ) be the normalized period of R i with respect to R max e.g., {5,10,20} => p(5) = 200ms/50ms, p(10) = 100ms/50ms, p(20) = 50ms/50ms For rate R i, timeouts are issued whenever tc % p(R i ) == 0 Increment tc between 0 and p(R 1 ) after every timeout of rate R 1 is issued

47. Relative Timeout Counts R 20 R 10 R 5 R 20 R 20, R 10 R 5, R 10, R 20 Assume that worst case execution time of R 20 work can be performed in the period of R 20 There is a pattern to the number of timeout counts in a frame e.g., in frame of R 10 there are two timeouts of R 20

48. Relative Timeout Counts Enforce only the relative # of timeouts for adjacent rates Timeout for R 10 is enabled after work for R 20 is complete proper number of timeouts for R 10 are performed R 20 R 10 R 20 R 20, R 10 Problem: Don’t know how long R 20 work takes?

49. Relative Timeout Counts Enforce only the relative # of timeouts for adjacent rates Timeout for R 10 is enabled after work for R 20 is complete proper number of timeouts for R 10 are performed R 20 R 10 R 20 R 20, R 10 Problem: Don’t know how long R 20 work takes? Next R 20 timeout could fall in the middle of R 10 work Must consider all interleavings of R 20 timeout and actions performed in R 10 work (or R 5 work, …)

50. Relative Timeout Counts R 20 R 10 R 10, R 20 R 20 R 10 R 10, R 20 R 20 R 10 R 10, R 20 R 20 R 2 R 10, R 20 R 20