Cadena:An Integrated Environment for
Developing High-Assurance Component-based Systems
http://www.cis.ksu.edu/cadenaSAnToS Laboratory, Kansas State University, USA
Matt DwyerJohn HatcliffGurdip Singh
Principal Investigators
SupportUS 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 ATCHoneywell Technology Center and NASA Langley Sun MicrosystemsIntel
Postdocs and StudentsRadu IosifHongjun ZhengCorina PasareanuGeorg Jung
RobbyVenkatesh RanganathOksana TkachukWilliam Deng
Distributed Components
Network
Distributed Components
Middleware (e.g. CORBA)
Java
C++
C++
C
Java
C
InterfaceDefinition Language (IDL) specifications for remote methods
Automatically generated proxies
Distributed Components
Middleware (e.g. CORBA)Event Service Transaction Service
Naming Service Synchronization Service
Java
C++
C++
C
Java
C
ComponentInterface DefinitionLanguage(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 Service Synchronization Service
Java
C++
C++
C
Java
C
Modern Software Systems Our 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
Weapons
Nav Sensors
WeaponManagement
Data Links
Many Computers
Multiple Buses
Constrained Tactical Links
O(106) Lines of CodeHard & Soft
Real-Time
Periodic & Aperiodic
Multiple Safety Criticalities
Information Security
Focus Domain
MissionComputer
VehicleMgmt
COTS
Control-Push Data-Pull
Component A computes some data that is to be read by one or more components Bi
Typical situation
Run-time Actions
A
B1
Bk
A publishes a dataAvailable eventBi call the getData() method of A to fetch the data
dataAvailable
dataAvailable
getData()
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 event3. Airframe component fetches GPS data by calling GPS GetData method4. Airframe updates its position data and publishes DATA_AVAILABLE event5. NavDisplay component fetches AirFrame data by calling AirFrame GetData method6. NavDisplay updates the physical display
1
2
3
4 4
5
6
Input
Output
Larger Configuration
…moving up to 1000+ components
Development ProcessComponent Development
Common Components
Platform-specificComponents
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.
100+ 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
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
C++ component library
XML component connectioninformation
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 dependencies2. 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 AnalysisBoeing OEP Challenge Problems
If component 1 is in mode A when component 2 produces event E, then component 3 will consume event F
(Section 4.1.5.3.6)
A temporal property well-suited for model-checking!
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
No Unifying Mechanism
C++ Component Code
Bold Stroke XML Configurator Info
?High-level
Specification Language
Design Artifacts
Analysis and QoSAspect Synthesis
Integrated Development Environment
<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>
Cadena
Java/C++ Component Code
Bold Stroke XML Configurator Info
UML Design Artifacts
Analysis and QoSAspect Synthesis
Integrated Development Environment
CCM Interface Definition LanguageRT Aspect
SpecsState TransitionsSystem Configuration
Eclipse Plug-In
High-level Specification
Language
Cadena
Next…
Cadena functionality and capabilities…
Example System
Example SystemBasic components seen earlier
Example SystemNavigation Steering Subsystem
Example System
Tactical Steering Subsystem
Example System
Display Control
on/off
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 PortsCORBA 3CCM 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 3CCM 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 3CCM IDL
provide interface to clients(facet)
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 Assemblysystem 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 Assemblysystem 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 Assemblysystem 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 Assemblysystem 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 Assemblysystem 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 Assemblysystem 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 Assemblysystem 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 Generationcomponent 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 SynthesisDependency-driven rate assignment to event handlers
5Hz 5Hz
20Hz1Hz20Hz
20Hz
20Hz
20Hz
20Hz
Cadena User Interface
Outline4. 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 ViewCCM IDLModelLayerCheck mode behaviors, temporal properties, timing constraints
Code LayerCheck 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 Behaviorcomponent 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 Behaviorcomponent 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 Behaviorcomponent 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 Behaviorcomponent 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 Behaviorcomponent 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 Behaviorcomponent 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 Behaviorcomponent 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 SystemEvent channel with internal thread pool
…Thread Pool
…
60Hz 20Hz 5Hz 1Hz
… … ……
passive componen
ts
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 StrategyEvent channel with internal thread pool
…Thread Pool
…
60Hz 20Hz 5Hz 1Hz
… … ……
correlation & filtering
Modeling StrategyComponent Models Event Channel
ModelComponent Models
Connections thru dSpin References
DSpin Modeling of Componentsany 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 {} }
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
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
http://www.cis.ksu.edu/cadena