analyzing component-based designs: the cadena environment santos laboratory, kansas state...

Analyzing Component-based Designs:

The Cadena Environment

http://www.cis.ksu.edu/cadena

SAnToS 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

Students

William DengGeorg JungAdam Childs

RobbyVenkatesh Ranganath

Distributed Components

Network


Middleware (e.g. CORBA)

Java

C++

C++

C

Java

C

InterfaceDefinition Language (IDL) specifications for remote methods

Automatically generated proxies



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


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

AvionicsMission Control

Systems

Analysis & Verification of

AvionicsMission Control

Systems

Boeing Bold Stroke Platform

Radar

Weapons

Nav Sensors

WeaponManagement

Data Links

Many Computers

Many Computers

Multiple BusesMultiple Buses

Constrained Tactical LinksConstrained

Tactical Links

O(106) Lines of Code

O(106) Lines of CodeHard & Soft

Real-TimeHard & Soft Real-Time

Periodic & Aperiodic

Periodic & Aperiodic

Multiple Safety Criticalities

Multiple Safety Criticalities

Information Security

Information Security

Focus Domain

MissionComputer

VehicleMgmt

COTSCOTS

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 event

Bi call the getData() method of A to fetch the data

dataAvailable

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

44

5

6

Input

Output

Larger Configuration

…moving up to 1000+ components

Development Process

Component Development

Component Development

Common Components

Platform-specificComponents

Component IntegrationComponent Integration

Connect components, assign priorities, locking schemes, distribute

Analysis & Functional Testing

Analysis & Functional Testing

Debuggers, call-graph analyzers, scheduling tools

Real Board Testing 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

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

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!

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 Language

RT Aspect SpecsState

TransitionsSystem

Configuration

Eclipse Plug-In

High-level Specification

Language

Cadena

Next…

Cadena functionality and capabilities…

Example System

Example SystemBasic components seen earlier

Basic components seen earlier

Example SystemNavigation Steering Subsystem

Navigation Steering Subsystem

Example System

Tactical Steering Subsystem

Tactical Steering Subsystem

Example System

Display Control

Display Control

on/off

on/off

Outline

2. Component Connections


3. Dependence Information


4. Modal Behavior

4. Modal Behavior

1. Component Interface

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 portinput 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 portoutput event port

Component Ports


interface ReadData {any get_data();}


CORBA 3CCM IDL

provide interface to clients(facet)

provide interface to clients(facet)

Outline



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

create instance of LazyActive component

called AirFrame



instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut


connect event INPUT port of current component

to event OUTPUT port of GPS component

connect event INPUT port of current component

to event OUTPUT port of GPS component



instance AirFrame of BMLazyActive on l2 { connect dataAvailable to GPS.dataCurrent atRate 20 connect dataIn to GPS.dataOut


connect data INPUT port of current component

to data OUTPUT port of GPS component

connect data INPUT port of current component

to data OUTPUT port of GPS component

Cadena Component Assembly

Cadena Visualization

Cadena User Interface

Outline



Dependency Specifications

Inter-component dependences are given by connection information (already seen)

We now give notation for specifying intra-component dependencies

Light-weight specification layer that provides significant benefit … 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

outDataAvailable

port action

triggers triggers call on set_data()

call on set_data()

dependencydefault == none;

dependencies { dataWriteOut.set_data() -> outDataAvailable; }

behavior { ... }

Light-weight Dependency Specs

triggers no other actions

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

in enabled mode, shows actions triggered by receipt of event on inDataAvailable port




behavior { ... }

in disabled mode, inDataAvailable triggers no

other port actions

in disabled mode, inDataAvailable triggers no

other port actions




behavior { ... }

Outline4. Modal Behavior

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 as safety properties e.g., frame-bounded response, invariants

Ultimate Modeling ViewCCM IDLModelLayer

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 portsinput ports

Component Behavior


enum Modes (enabled,disabled); Modes m;


output portsoutput ports

Component Behavior




mode declaration using CORBA IDL

mode declaration using CORBA IDL

Component Behavior




behavior for events on dataInReady port

behavior for events on dataInReady port

Component Behavior




behavior mode casesbehavior mode cases

Component Behavior




data flow specification

data flow specification

Component Behavior



behavior { handles dataInReady (DataAvailable e) { case m of enabled { dataOut::data <- dataIn.getData(); push {} dataOutReady; } disabled {} } … publish eventpublish event

Towards a Complete Model

We have transition semantics for intra-component behavior.

How should we model communication layer?

?

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

Outline of Real SystemEvent channel with internal thread pool

…Thread Pool

…

60Hz 20Hz 5Hz 1Hz

… … ……

passive componen

ts

passive componen

ts

proxy consumer holds list of consumer

references

proxy consumer holds list of consumer

references

dispatch queues for each rate

group

dispatch queues for each rate

group

publish

correlation & filtering

consumer refs

Threads run call-backs associated with event consumer ports

getData

Lots of details …

What events are users interested in reasoning about? publish, dispatch, timeouts, …

What state information? modes, dispatch queues, correlation

automata, … Minimize detail, but retain …

ability to express properties of interest correspondance with implementation

semantics

System ObservationsEvent channel with internal thread pool

…Thread Pool

…

60Hz 20Hz 5Hz 1Hz

… … ……

invoke[m,c]invoke[m,c]

publish[e,c]publish[e,c]

dispatch[e]dispatch[e]

publish


consumer refs

accept[e,s]accept[e,s]

eof[r]eof[r]

getData

c.m == vc.m == v

Modeling StrategyEvent channel with internal thread pool

…Thread Pool

…

60Hz 20Hz 5Hz 1Hz

… … ……


Modeling Strategy

Component Models Event ChannelModel

Component Models

EnvironmentModel

Connection Models

Model Checker Support Ability to define efficient building blocks

Sets, queues (with symmetry support) Flexible atomicity control Programmable scheduler Static data definition State compaction Flexibility in search strategies

Full-state space Bounded/heuristic search State-less search

BOGOR has all this and more …

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<Data>(AirFrame, "ReadData.data"); } goto loc2; loc loc2: live{} when true do { CAD.setField<Data>(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

Structure follows component behavior spec and connection representation closely

Modeling Middleware (Threads)

thread threadgroup5() { Pair.type<EventHandlerEnum, CAD.Event> pair; EventHandlerEnum handler; CAD.Event event;

loc loc0: live { handler, event } when Queue.size<Pair.type<EventHandlerEnum, CAD.Event>>(Q5) > 0 do invisible { pair := Queue. getFront<Pair.type<EventHandlerEnum, CAD.Event> >(Q5); Queue.dequeue<Pair.type<EventHandlerEnum, CAD.Event> >(Q5); handler := Pair. first<EventHandlerEnum, CAD.Event>(pair); event := Pair.second<EventHandlerEnum, CAD.Event>(pair); } goto loc1;

loc loc1: live {} invoke virtual f(handler, event) goto loc0;}

…Thread Pool

60Hz 20Hz 5Hz 1Hz Dispatch queue polling

Dispatch queue polling

Extend model checker types

Extend model checker types

Polymorphic extension

Polymorphic extension

Modeling Middleware (Queues)

extension Queue for edu.ksu.cis.cadena.bogor.ext.Queue { typedef type<'a>; expdef int size<'a>(Queue.type<'a>); expdef int capacity<'a>(Queue.type<'a>); expdef boolean isFull<'a>(Queue.type<'a>); expdef boolean isEmpty<'a>(Queue.type<'a>); expdef Queue.type<'a> create<'a>(int); actiondef enqueue<'a>(Queue.type<'a>, 'a); expdef 'a getFront<'a>(Queue.type<'a>); actiondef dequeue<'a>(Queue.type<'a>); expdef boolean

containsPair<'a>(Queue.type<'a>,'a);}

… … …

Data in state space, operations implemented as Java code

Data in state space, operations implemented as Java code

Modeling Middleware (Scheduling)

…Thread Pool

60Hz 20Hz 5Hz 1Hz

… … ……

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

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

Relative Timeout Counts

Enforce only the relative # of timeouts for adjacent rates

Timeout for Ri is enabled after

• work for Ri is complete

• proper number of timeouts for Ri-1 are performed

R1

R2

R1R1, R2

Problem: Don’t know how long R2 work takes?


Enforce only the relative # of timeouts for adjacent rates

Timeout for Ri is enabled after

• work for Ri is complete

• proper number of timeouts for Ri-1 are performed

R1

R2

R1, R2

Problem: Don’t know how long R2 work takes?

Next R1 timeout could fall in the middle of R2 work

R1

Must consider all interleavings of R1 timeout and actions performed in R2 work (or R3 work, …)


R1

R2

R1, R2

R1

R1

R2

R1, R2

R1

R1

R2

R1, R2

R1

R1

R2

R1, R2 R1

Modeling of Environment

Previous model does not relate component execution with passage of time

Assume we have worst-case execution bounds for event handlers

• e.g., from schedulability analysis

Keep track of intra-hyper-period time (ihp) normalized by duration of shortest action

Increment ihp by duration bounds for handlers as they are executed

One tricky issue …

Lazily-Timed Componentsihp

1 2

thandler

ihp 2

thandler

Handler duration fits in before next frame boundary:

Handler duration fits in before next frame boundary:

1. ihp += thandler

2. execute handler to completion

1. ihp += thandler

2. execute handler to completion

ihp

1

thandler-

Handler duration overruns next frame boundary:

Handler duration overruns next frame boundary:1. ihp +=

2. choose prefix of handler to execute

3. assign residual duration to handler suffix

1. ihp += 2. choose prefix of

handler to execute3. assign residual

duration to handler suffix

Preliminary Results (Full Search)

Basic1 rate, 3 components,

2 events per hyper-period

Multi-Rate2 rates, 6 components,


Modal3 rates, 8 components,


Medium2 rates, 50 components,


System ND Priority Lazily-Timed

20, .12s 12, .11s14, .11s

120k, 5m 100, .38s33, .19s

3M+, ? 9.1k, 8.6s 900, 1.3s

13M+, ? 740k, 29m 4k, 8.6s

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

Project Web Site

http://www.cis.ksu.edu/cadena

analyzing component-based designs: the cadena environment santos laboratory, kansas state...

Documents

position data

logical gps component

bold stroke development

lines of c code

rigorous design process

current development

gps getdata method4

physical gps device