Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems 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 Postdocs and Students Radu Iosif Hongjun Zheng Corina Pasareanu Georg Jung Robby Venkatesh Ranganath Oksana Tkachuk William Deng

Distributed Components Network

Distributed Components Middleware (e.g. CORBA) JavaC++ C JavaC Interface Definition Language (IDL) specifications for remote methods Automatically generated proxies

Distributed Components Middleware (e.g. CORBA) Event ServiceTransaction Service Naming ServiceSynchronization Service JavaC++ C JavaC Component Interface Definition Language (CCM IDL) substantial portion of code auto-generated

Checking CCM Systems Light-weight behavioral specifications Leverage abstractions that programmers already write Component IDL Scale static analysis techniques to handle remote connections Use emerging model-checking technology dedicated to OO structures and RT scheduling algorithms Middleware (e.g. CORBA) Event Service Transaction Service Naming ServiceSynchronization Service JavaC++ C JavaC Modern Software SystemsOur Themes These systems are huge! What are appropriate abstractions/specifications and how can we get programmers to write them?

Mission-control software for Boeing military aircraft, e.g., F-18 E/F, Harrier, UCAV Boeing’s Bold Stroke Avionics Middleware …built on top of ACE/TAO RT CORBA Our focus: developing a rigorous design process with formal design artifacts that can be automatically checked for common design flaws Analysis & Verification of Fighter Aircraft Mission Control Systems

Boeing Bold Stroke Platform Radar WeaponsNav Sensors Weapon Management Data Links Many Computers Multiple Buses Constrained Tactical Links O(10 6 ) Lines of Code Hard & Soft Real-Time Periodic & Aperiodic Multiple Safety Criticalities Information Security Focus Domain Mission Computer Vehicle Mgmt COTS

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

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 Input Output

Larger Configuration …moving up to components

System Design Aspects Declare rates/priorities for intermediate event handlers Implement mode semantics for changing subsystem behavior Off AirFrame Intermediate components correlate incoming data and produce higher-level info Inputs different rates Sensor1 Mode Switch 60Hz 20Hz 5Hz 1Hz Map components to onboard network nodes Outputs different rates Display 1Hz 20Hz Control

Development Process Component Development Common Components Platform-specific Components Component Integration Connect components, assign priorities, locking schemes, distribute Analysis & Functional Testing Debuggers, call-graph analyzers, scheduling tools Real Board Testing Test real-time aspects, frame-overruns, etc developers

Research Context 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) Provided with 150+ 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 Must propose solutions that fit within current development process, code base, etc. Must propose metrics for tool performance and ease of use evaluation by Boeing research team Must make significant progress in one year with regular evaluation milestones

Next… Short-comings in Bold Stroke development that we will attempt to address One could imagine doing a number of things. We first focused on items in Boeing’s “wish list”.

Lack of Modeling Informal natural language requirements C++ component library XML component connection information Process moves directly from informal textual requirements documents to C++ coding (!) No use of component-level (CCM) IDL for code generation Still resistance by “legacy developers” to higher-level descriptions (moving away from machine code has been difficult for some) development bypasses modeling

Unleveraged Artifacts Current design/model artifacts are used as informal documentation not connected to analysis/visualization tools not connected to “glue code” (deployment code) generation

Lack of Model Analysis 1. Forward & backward data and event dependencies 2. Dependency intersections 4. All components from a particular rate group 5. Cycle checks …15-20 others related to dependencies Boeing OEP Challenge Problems 3. Components with high data coupling …also mode-aware dependences

Lack of Model Analysis Boeing OEP Challenge Problems If component 1 is in mode A when component 2 produces event E, then component 3 will consume event F (Section ) A temporal property well-suited for model-checking!

No Unifying Mechanism C++ Component Code Bold Stroke XML Configurator Info ? High-level Specification Language Design Artifacts Analysis and QoS Aspect Synthesis Integrated Development Environment

Cadena Java/C++ Component Code Bold Stroke XML Configurator Info UML Design Artifacts Analysis and QoS Aspect Synthesis Integrated Development Environment CCM Interface Definition Language RT Aspect Specs State Transitions System Configuration Eclipse Plug-In High-level Specification Language Cadena

Next… Cadena functionality and capabilities…

Example System

Basic components seen earlier

Example System Navigation Steering Subsystem

Example System Tactical Steering Subsystem

Example System Display Control on/off

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

CCM Component Interfaces CCM Component Interfaces are based on a notion of ports Event ports – asynchronous event delivery consumes port – input (event sink) publishes port – output (event source) Interface ports – synchronous method calls provides port – provide interface to clients (facet) uses port – use interface of other component (receptacle)

Component Ports CORBA 3 CCM IDL input event port eventtype TimeOut {} eventtype DataAvailable {} interface ReadData { readonly attribute any data; } component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut }

Component Ports eventtype TimeOut {} eventtype DataAvailable {} interface ReadData { readonly attribute any data; } component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut } CORBA 3 CCM IDL output event port

Component Ports eventtype TimeOut {} eventtype DataAvailable {} interface ReadData { any get_data(); } component BMDevice { consumes TimeOut timeout publishes DataAvailable dataCurrent provides ReadData dataOut } CORBA 3 CCM IDL provide interface to clients (facet) provide interface to clients (facet)

Component Code Generation tacticalSteering : BM__ModalComponent Push() GetData() Push() GetData() Currently in Bold Stroke = 8-12 classes drawn by hand in Rational Rose, then code templates generated from this (component structure must be re-specified each time). Using CCM IDL Compiler component BMModal { consumes DataAvailable dataInReady; uses ReadData dataIn; publishes DataAvailable dataOutReady; provides ReadData dataOut; provides Toggle switch; } Completely auto-generated code templates + component logic User only fills in body of methods for event-handlers, interfaces

Outline 2. Component Connections

Component Connections Three ways in Cadena A textual language for allocating component instances and describing port connections A graphical representation of the same analogous to UML collaboration diagram useful for visualizing dependency information A form-based (spreadsheet-like) view useful for component integrator from pull-down menus pick ports to connect to pick QoS attributes (rates, locations, etc.)

Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … abstract distribution nodes

Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … rate group declaration

Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … create instance of LazyActive component called AirFrame

Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … connect event INPUT port of current component to event OUTPUT port of GPS component

Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … connect data INPUT port of current component to data OUTPUT port of GPS component

Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … create instance of DeviceComponent called GPS

Cadena Component Assembly system ModalSP { locations l1,l2,l3; rates 1,5,20,60; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut instance GPS of BMDevice on l2 { connect timeout to EventChannel.timeout20 } … connect event INPUT port of current component to event OUTPUT port of EventChannel

Cadena Component Assembly

Cadena Visualization

Code Generation Overview Component Code Generation component BMModal { consumes DataAvailable dataInReady; uses ReadData dataIn; publishes DataAvailable dataOutReady; provides ReadData dataOut; provides Toggle switch; } component BMModal { consumes DataAvailable dataInReady; uses ReadData dataIn; publishes DataAvailable dataOutReady; provides ReadData dataOut; provides Toggle switch; } … component BMModal { consumes DataAvailable dataInReady; uses ReadData dataIn; publishes DataAvailable dataOutReady; provides ReadData dataOut; provides Toggle switch; } BM.Device BM.LazyActive BM.Modal “Glue Code” Generation Execution gives allocation and deployment of component instances and connections (complete system) Glue Code

Outline 3. Dependence Information

Dependency Specifications Inter-component dependences are given by connection information (already seen) We now give notation for specifying intra- component dependencies An example of Meyer’s “something intelligent/useful” that a developer or manager might want to know In this case, component integrator leverages this info in a variety of ways to specify aspects such as rates/priorities, distribution, scheduling, etc. Used to visualize system behavior in different modes

outDataAvailable port action triggers call on set_data() dependencydefault == none; dependencies { dataWriteOut.set_data() -> outDataAvailable; } behavior {... } Light-weight Dependency Specs

triggers no other actions Light-weight Dependency Specs dependencydefault == all; dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } behavior {... }

in enabled mode, shows actions triggered by receipt of event on inDataAvailable port Light-weight Dependency Specs dependencydefault == all; dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } behavior {... }

in disabled mode, inDataAvailable triggers no other port actions Light-weight Dependency Specs dependencydefault == all; dependencies { modeChange() ->; case modeChange.modeVar of { enabled: inDataAvailable -> dataIn.get_data(), outDataAvailable; disabled: inDataAvailable ->; } behavior {... }

Aspect Synthesis Dependency-driven rate assignment to event handlers 5Hz 20Hz 1Hz 20Hz

Cadena User Interface

Aspect Synthesis Synthesis of distribution information 5Hz 20Hz 1Hz 20Hz Look at coupling and traffic as indicated by rates Loc L3 Loc L1 Loc L2

Aspect Synthesis Automatic detection of optimization opportunties 5Hz 20Hz 1Hz 20Hz Asynchronous message delivery to synchronous method calls (must be co- located and run at same rate) Loc L3 Loc L1 Loc L2

Outline 4. Modal Behavior

Transition System Semantics Boeing engineers want to reason about system/component modes at design time Ideal for model-checking because… component modes are finite 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 in TL or tools like Bell Labs Timeline Editor

Ultimate Modeling View CCM IDL Model Layer Check mode behaviors, temporal properties, timing constraints Code Layer Check that implementations satisfy/refinement high-level specs – leverage the fact that code skeletons are automatically generated Generate code, fill- in skeletons, check for refinement We don’t do all of this yet!

Component Behavior component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange; enum Modes {enabled,disabled}; Modes m; behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … input ports

Component Behavior component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange; enum Modes (enabled,disabled); Modes m; behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … output ports

Component Behavior component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange; enum Modes (enabled,disabled); Modes m; behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … mode declaration using CORBA IDL

Component Behavior component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange; enum Modes (enabled,disabled); Modes m; behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … behavior for events on dataInReady port

Component Behavior component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange; enum Modes (enabled,disabled); Modes m; behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … behavior mode cases

Component Behavior component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange; enum Modes (enabled,disabled); Modes m; behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … data flow specification

Component Behavior component BMModal { uses ReadData dataIn; consumes DataAvailable inDataAvailable; publishes DataAvailable outDataAvailable; provides ReadData dataOut; provides ChangeMode modeChange; enum Modes (enabled,disabled); Modes m; behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … publish event

Towards a Complete Model We have transition semantics for intra-component behavior. How should we model communication layer? ?

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

Modeling with Direct OO Support dSpin model-checker supports references, dynamic allocation, garbage collection, heap symmetries built by Radu Iosif (KSU, now Verimag) Model generation strategy automatically generate component models hand-craft event-channel model (only once) Explicitly encode priorities/scheduling/thread- periods into transition system this dramatically reduces interleavings No modeling of RT/clocks for now still allows interesting functional properties as suggested by Boeing to be checked

Modeling Strategy Event channel with internal thread pool … Thread Pool … 60Hz20Hz5Hz1Hz ……… … correlation & filtering

Modeling Strategy Component Models Event Channel Model Component Models Connections thru dSpin References

DSpin Modeling of Components any NavSteering_internalData; mode NavSteering_componentState; ftype Ref_NavSteering_dataIn1_getData, Ref_NavSteering_dataIn2_getData; ftype Ref_NavSteering_update; function Fun_NavSteering_source1 (mtype t) { printf("NavSteering: source1 handler invoked.\n"); if :: NavSteering_componentState == enabled -> NavSteering_internalData = Ref_NavSteering_dataIn1_getData (); printf("NavSteering: publishing update.\n"); Ref_NavSteering_update (NavSteering_DataAvailable) :: else fi } Structure follows component behavior spec and connection representation closely 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 {} }

DSpin Modeling of Connections Ref_GPS_dataCurrent = Proxy_GPS_dataCurrent; GPS_dataCurrent_NumberSubscribers = 1; GPS_dataCurrent_SubscriberList = new functionField[1]; GPS_dataCurrent_SubscriberList[0].Entry = Fun_AirFrame_dataAvailable; instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut Modeled very directly in DSpin

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

Temporal Property Specs Trigger event …with condition Required event “Monitoring” automaton Timeline Editor from Bell Labs Timeline Editor from Bell Labs

Conclusions Could imagine providing a variety of forms of automated checking of lightweight specs for component-based systems Cadena provides currently provides a few – as requested by Boeing engineers Component IDL is a natural level for attaching lightweight specs Spec forms are naturally incremental Cadena continues the line of work by Garlan et. al. on model-checking pub/sub systems model-checkers that support OO structures directly make it much easier to model such systems basing model-checker scheduling on scheduling policy of actual system dramatically reduces state-space

Future Work… Focus on using static analysis techniques to check other properties escape/confinement analysis Building model-checking infrastructure dedicated to CORBA-like distributed systems flexible scheduling, flexible inclusion of dedicated models of middleware services (e.g., data service) Refinement checking checking that code conforms to component behavior specs (cf. Microsoft Research BEHAVE project) modify IDL code generation process to include “cookie-crumbs” that make it easier for analysis tools to check code conformance Case studies with Boeing and Rockwell-Collins

Project Web Site