Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems

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


Middleware (e.g. CORBA)

Java

C++

C++

C

Java

C

InterfaceDefinition Language (IDL) specifications for remote methods

Automatically generated proxies


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

http://www.altia.com/demos/f14/f14dsn.html

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!


No Unifying Mechanism

C++ Component Code

Bold Stroke XML Configurator Info

?High-level

Specification Language

Design Artifacts

Analysis and QoSAspect Synthesis

Integrated Development Environment


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


interface ReadData { readonly attribute any data;}


CORBA 3CCM IDL

output event port

Component Ports


interface ReadData {any get_data();}


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





rate group declaration





create instance of LazyActive component

called AirFrame





connect event INPUT port of current component

to event OUTPUT port of GPS component





connect data INPUT port of current component

to data OUTPUT port of GPS component





create instance of DeviceComponent called

GPS





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


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




behavior { ... }

in disabled mode, inDataAvailable triggers no

other port actions




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


enum Modes (enabled,disabled); Modes m;


output ports




mode declaration using CORBA IDL




behavior for events on dataInReady port




behavior mode cases




data flow specification



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;


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

Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems

Documents

Transcript of Cadena: An Integrated Environment for Developing High-Assurance Component-based Systems