Cadena An Integrated Development Analysis and Verification Environment

Cadena: An Integrated Development, Analysis, and Verification Environment for Component-based Systems SAn. To. S Laboratory, Kansas State University, USA http: //www. cis. ksu. edu/cadena John Hatcliff William Deng Support US US Matt Dwyer Georg Jung Venkatesh Ranganath Army Research Office (ARO) National Science Foundation (NSF) National Aeronautics and Space Agency (NASA) Department of Defense Advanced Research Projects Agency (DARPA) Rockwell-Collins ATC Honeywell Technology Center and NASA Langley Sun Microsystems Intel

Distributed Components Java C++ C Network C Java C++

Distributed Components Java C++ Event Service C Transaction Service Middleware (e. g. CORBA) Naming Service C Synchronization Service Java C++

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

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

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

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

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

Avionics Mission Control Systems n n Mission-control software for Boeing military aircraft Boeing’s Bold Stroke Avionics Middleware n n Provided with an Open Experimental Platform (OEP) from Boeing n n …built on top of ACE/TAO RT CORBA 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… n n n 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

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

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

Larger Configuration …moving up to 1000+ components

Example System

Example System Basic components seen earlier

Example System Navigation Steering Subsystem

Example System Tactical Steering Subsystem

Example System on/off Display Control on/off

Outline 4. Modal Behavior 1. Component Interface 2. Component Connections 3. Dependence Information

Component IDL CORBA 3 CCM IDL Modal. SP Components

Component IDL CORBA 3 CCM IDL Modal. SP Components

Component IDL output data port (facet) CORBA 3 CCM IDL Modal. SP Components

Component IDL input data port (receptacle) CORBA 3 CCM IDL Modal. SP Components

Component IDL output event port (event source) CORBA 3 CCM IDL Modal. SP Components

Component IDL input event port (event sink) CORBA 3 CCM IDL Modal. SP Components

Component IDL mode attribute CORBA 3 CCM IDL Modal. SP Components

Outline 2. Component Connections

Three Synchronized Views Scenario Description Graphical View Spreadsheet View Textual View Single Internal Representation

Textual View

Textual View

Textual View …allocate Air. Frame component instance

Textual View …connect event ports and facet/receptacles

Graphical View

Graphical View …design-level analyses modebase views

Spreadsheet View …ports for component type …port types RT Attributes …distribution sites …port connections …rate group Synthesized automatically Summary: Incremental, iterative scenario construction with multiple forms of visualization, analyses, and automated “design advice”.

Outline See the paper! 3. Dependence Information

Outline 4. Modal Behavior

Towards a Complete Model Configuration Info Transition System Specs System Components ? RT CORBA Event Channel

Middleware/Service Semantics n Weak CCM and Event Services Specs (OMG) n n n Looked at implemented semantics of existing ORBs and Event Services n n n Informal : English and examples Intentionally under-specified to allow implementor freedom ACE/TAO, FACET, Open. CCM, … Developed a family of semantic models that captured their behavior Implemented these models as Bogor extensions n model modules are reused each time we reason about a system

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

Modeling Middleware (Queues) … … … Extend model checker types extension Queue for edu. ksu. cis. cadena. bogor. ext. Queue { typedef type<'a>; Polymorphic extension expdef int size<'a>(Queue. type<'a>); expdef int capacity<'a>(Queue. type<'a>); expdef boolean is. Full<'a>(Queue. type<'a>); expdef boolean is. Empty<'a>(Queue. type<'a>); expdef Queue. type<'a> create<'a>(int); actiondef enqueue<'a>(Queue. type<'a>, 'a); expdef 'a get. Front<'a>(Queue. type<'a>); actiondef dequeue<'a>(Queue. type<'a>); expdef boolean contains. Pair<'a>(Queue. type<'a>, 'a); } Data in state space, operations implemented as Java code

Modeling of Connections instance of connect to at. Rate connect to Air. Frame BMLazy. Active on l 2 { data. Available GPS. data. Current 20 data. In GPS. data. Out Modeled very directly in BOGOR CAD. connect. Event(GPS, “data. Current", Air. Frame, "in. Data. Available", 20, false);

Modeling Middleware (Scheduling) Typically model checkers use nondeterministic scheduling Thread Pool … 60 Hz 20 Hz … … 5 Hz 1 Hz … • i. e. , choose from set of enabled transitions in a state … • set of all such schedules contains all real schedules 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

Preliminary Results (Full Search) System Basic 1 rate, 3 components, 2 events per hyper-period ND Priority Lazily-Timed 20, . 12 s 12, . 11 s 14, . 11 s 120 k, 5 m 100, . 38 s 33, . 19 s 3 M+, ? 9. 1 k, 8. 6 s 900, 1. 3 s 13 M+, ? 740 k, 29 m 4 k, 8. 6 s 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

Conclusions n n Static analysis and model-checking techniques for a particular class of CCM systems Building off of previous work… n n n Lots of other tools for reasoning about embedded system designs… n n model-checking: JPF, d. Spin pub-sub reasoning: Garlan, Allen, Dingel Meta. H, 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

Project Web Site http: //www. cis. ksu. edu/cadena

Component Behavior component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; enum Modes (enabled, disabled); Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } … mode declaration using CORBA IDL

Component Behavior component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; enum Modes (enabled, disabled); Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } … behavior for events on data. In. Ready port

Component Behavior component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; enum Modes (enabled, disabled); Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } … behavior mode cases

Component Behavior component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; enum Modes (enabled, disabled); Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } … data flow specification

Component Behavior component BMModal { uses Read. Data data. In; consumes Data. Available in. Data. Available; publishes Data. Available out. Data. Available; provides Read. Data data. Out; provides Change. Mode mode. Change; enum Modes (enabled, disabled); Modes m; behavior { handles data. In. Ready (Data. Available e) { case m of enabled { data. Out: : data <- data. In. get. Data(); push {} data. Out. Ready; } disabled {} } … publish event