automated extraction of transition systems from component-model architectures

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

SAnToS Laboratory, Kansas State University, USA

Matt Hoosier

Automated Extraction of Transition Systems from Component-model Architectures

Extracting Transition Systems from Component Models 2

Overview

Distributed mission-critical software is starting a trend toward component-based middleware

Some initial tools (one from KSU) have come along to help the design of such distributed real-time event-driven (DRE) software

I describe the work to automate model checker verification (more realistically, “bug finding”) of these mission-critical applications


Outline

Component architectures Cadena design and analysis tool for

component architectures Bogor model checking framework Model checking Cadena projects

High-level approaches Translation strategies

Evaluation vs. manually constructed models

Future work


Component OrganizationA software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

Szyperski, Component Software

A software component is a unit of composition with contractually specified interfaces and explicit context dependencies only. A software component can be deployed independently and is subject to composition by third parties.

Szyperski, Component Software


Component OrganizationAll communication with outside is through typed

“ports” Interface ports

Aggregation of operations on an object Synchronous semantics just like any other OO method

call Event ports

Notification messages Asynchronous semantics (“fire and forget”)





call Event ports


Interface portsRequired interface

Required interface

“Receptacle”

Provided interface

Provided interface

“Facet”





call Event ports


Event portsSubscriber

Subscriber

“Sink”

PublisherPublisher

“Source”


Embedded Components

Real-time distributed component model very similar to the CORBA Component Model

Computation driven by a set of regular system interrupts (timeouts)

All components are passive; a threadpool with event-dispatching threads provides all the CPU time.

Boeing’s Prism Avionics Middleware


Prism Development Methodologies

Little abstract design Natural language requirements often used

directly to inspire C++ code UML is often relegated to documentation, when

kept in sync Engineers want to reason about high-level

“mode” transitions Overall long-run control flow is hard to analyze

manually Formal verification tools would be useful here.

Open Experimental Program was established to solicit new tools to help in the design process. One was developed at KSU…


Cadena

<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>

<CONFIGURATION_PASS> <HOME> <…> <COMPONENT> <ID> <…></ID> <EVENT_SUPPLIER> <…events this component supplies…> </EVENT_SUPPLIER> </COMPONENT> </HOME></CONFIGURATION_PASS>

Java/C++ Component Code

Prism XML Configurator Info

Model Checking

Analysis and QoSAspect Synthesis

Integrated Development Environment

CCM Interface Definition Language

Product Line Customization

sState Transitions

System Configuration

Eclipse Plug-In

High-level Specification

Language

Cadena


Behavioral Specification

The component is the unit of specification, so we’ll examine one of the more interesting ones.

The component is the unit of specification, so we’ll examine one of the more interesting ones.


component BMModal {

provides ChangeMode modeChange; provides ReadData dataOut; uses ReadData dataIn; publishes DataAvailable outDataAvailable; consumes DataAvailable inDataAvailable;

mode bmModalMode of common.OnOffMode init common.OnOffMode.enabled;

behavior {

string buf;

handle inDataAvailable(DataAvailable e) { case bmModalMode of { common.OnOffMode.enabled: buf := dataIn.data; push new DataAvailable {} on outDataAvailable; common.OnOffMode.disabled: }

}…

}

};



component BMModal {



behavior {

string buf;


}…

}

};

Structure Specification

CORBA Interface Definition Language (IDL): Structural Definitions

CORBA Interface Definition Language (IDL): Structural Definitions


component BMModal {



behavior {

string buf;


}…

}

};

Structure: Event Sources

Event source portEvent source port


component BMModal {



behavior {

string buf;


}…

}

};

Structure: Event Sinks

Event sink portEvent sink port


component BMModal {



behavior {

string buf;


}…

}

};

Structure: Interface Consumers

Remote interface clientRemote interface client


component BMModal {



behavior {

string buf;


}…

}

};

Structure: Interface Providers

Interfaces accessible to others remotely (servers)

Interfaces accessible to others remotely (servers)


component BMModal {



behavior {

string buf;


}…

}

};


Cadena Component Property Specification (CPS)Cadena Component Property Specification (CPS)


component BMModal {



behavior {

string buf;


}…

}

};

Behavior: Mode Variables

Behavior-control variablesBehavior-control variables

Like finite state control in an automaton

Like finite state control in an automaton

Small, bounded domainsSmall, bounded domains

enum OnOffMode {enabled, disabled};


Behavior: Handler Methods

Handler method for event sinkHandler method for event sink

The event itself. Can carry payload (not used here).

The event itself. Can carry payload (not used here).

component BMModal {



behavior {

string buf;


}…

}

};


Behavior: Modal Control

I/O Port Dependencies

Differ

I/O Port Dependencies

Differ

Modal Control Flow

Modal Control Flow

component BMModal {



behavior {

string buf;


}…

}

};


Behavior: Dataflow

Tracks inflow/outflow of values, but not computation

Tracks inflow/outflow of values, but not computation

component BMModal {



behavior {

string buf;


}…

}

};


component BMModal {



behavior {

string buf;


}…

}

};

Behavior: Event Propagation

Emit event through source port

Emit event through source port


Event Correlation

Something introduced in Cadena to allow detection and reaction to complex patterns of events

Reduce network bandwidth

Keep components simple

An

A3A2

…

A1 +B


Event Correlation: Example

DataAvailable correlation And ( DataAvailable e1, DataAvailable e2) e1 + e2 { case true: push new DataAvailable {}; }

When a component only cares if each of two others has new data

When a component only cares if each of two others has new data

Correlator becomes a bona fide type: And

Correlator becomes a bona fide type: And

Two event sink ports, and one (implicit) event source port

Two event sink ports, and one (implicit) event source port


Prism Middleware Implementation

Each middleware has its own method of achieving the abstraction of inter-component connections.

Each middleware has its own method of achieving the abstraction of inter-component connections.

Taken from “A Correlation Framework for the CORBA Component Model” [FASE ’04]



Abstractly…Abstractly…

produceproduce

consumeconsume




Event channel

produceproduce

In reality…In reality…

ProxyConsumer …

consumerreferences

consumerreferences

proxyproxy

timer/thread pool

ProxySupplier

filteringnetwork

filteringnetwork

… … … …

threadingthreading

proxyproxy

queuingqueuing

dispatchdispatch

multiplexingmultiplexing

consumeconsume



My Contributions Implement front end of CPS language

Lexing, Parsing, Semantic Checking [with Jung, Greenwald] Implement event correlation language

Front end again Simulated implementation (re-used in model

checking backend) Automate the creation of checkable models

from Cadena specification artifacts Compiler from CPS Bogor input language Generate OO structures to mimic component layout Map CADL configuration Bogor input language

API calls to initialize “embedded system”


On the model checker used…

Before diving into details about the translation, we give some general information about the model checker used.

Before diving into details about the translation, we give some general information about the model checker used.


Bogor Model Checker

Verified

CounterExample

.bir

.config

Lexer

Parser

Type Checking

SemanticAnalyses

Front-end

IExpEvaluator ITransformer ISearcher

IActionTaker IBacktrackIF IStateMgr

IValueFactory ISchedulingStg IStateFactory

Model Checking Components

Developed at Kansas State University [Robby]

Actually, a framework with swappable modules

… as opposed to SPIN


Bogor Modeling Language: BIR

Used as the intermediate language for the Bandera Tool Set for model-checking Java programs

Guarded command language when <condition> do <command>

Native support for a variety of object-oriented language features dynamically created objects and

threads, exceptions, methods, inheritance, etc.

BIR = Bandera Intermediate Representation


BIR Example:2 Dining Philosophers

left

leftright

right

Taken from the Bogor Tutorial [ETAPS ’04]


system TwoDiningPhilosophers { record Fork { boolean isHeld; }

main thread MAIN() { Fork fork1; Fork fork2; loc loc0: do { // create forks fork1 := new Fork; fork2 := new Fork; // start philosophers start Phil(fork1, fork2); start Phil(fork2, fork1); } return; }

thread Phil(Fork left, Fork right) { loc loc0: // take left fork when !left.isHeld do { left.isHeld := true; } goto loc1;

loc loc1: // take right fork when !right.isHeld do { right.isHeld := true; } goto loc2;

loc loc2: // put right fork do { right.isHeld := false; } goto loc3;

loc loc3: // put left fork do { left.isHeld := false; } goto loc0; }}









Uses a record to model forksUses a record to model forks









Thread declarationsThread declarations









Local variable declarationsLocal variable declarations









Control locationsControl locations



Guarded transformations





…aka “guarded transitions”, “guarded commands”

When conditionis trueWhen conditionis true

Trivially trueguardsTrivially trueguards

Execute thesestatement(s)atomically

Execute thesestatement(s)atomically



Modeling Approach

Use Bogor model checker Extend Bogor input language with

primitives specific to DRE software Build translator to map CPS

specifications into Bogor input language constructs

Exploit knowledge of runtime scheduling policies to reduce interleavings

Integrate whole thing into Cadena for instant model checking


Publish/Subscribe Primitives

extension CAD for SystemModule { // declaration of abstract types typedef Event; typedef Component; // constructors expdef CAD.Component createComponent(string); expdef CAD.Event createEvent<'a>('a);

// manipulation of subscriber lists actiondef addSubscriberList(CAD.Component, string); actiondef addSubscriber<'a>(CAD.Component, string, 'a); expdef 'a[] getSubscribers<'a>(CAD.Component, string);}

record Subscriber { EventHandlerType handlerFunction; string portName; }

function fireEventFromComponent( CAD.Component sourceComp, string port, CAD.Event event) {}

Add abstract types (like channels in

SPIN)

Add abstract types (like channels in

SPIN)

}

Populate/query subscriber lists

Populate/query subscriber lists

}Unit of

subscribershipUnit of

subscribership

Event multiplexing and queuing

Event multiplexing and queuing


Publish/Subscribe Primitives: Event Correlators

extension Correlator for CorrelatorModule { // abstract type for correlator; encapsulates acceptor automaton typedef type;

// Constructor: builds complete automaton from spec. string expdef Correlator.type create(string);

// Handle incoming event and dump a newly allocated ‘evtType // into the list for each compound event triggered actiondef handleEvent<'evtType>( Correlator.type, string, List.type<'evtType>);

// subscriber list maintenance actiondef addSubscriber<'a>(Correlator.type, 'a); expdef 'a[] getSubscribers<'a>(Correlator.type);}

// allow correlators to be consumers of component eventsrecord CorrelatorSubscriber extends Subscriber { … }

// analagous to event multiplexing and queuing from componentsfunction fireEventFromCorrelator(Correlator.type cor, CAD.Event e) { … }


Interface Port Primitives

extension CAD for SystemModule { // abstract type for provided (server) port typedef Port; // constructors expdef CAD.Port createPort();

// attach server ports to components actiondef registerPort(CAD.Component, CAD.Port, string); expdef CAD.Port getPort(CAD.Component, string);

// put BIR function pseudo-references into ports (for named methods) actiondef setPortMethodHandler<'a>(CAD.Port, string, 'a); expdef 'a getPortMethodHandler<'a>(CAD.Port, string);

// make client <-> server connections actiondef connectPorts( Pair.type<CAD.Component, string>, Pair.type<CAD.Component, string> ); expdef Pair.type<CAD.Component, string> getProvider( Pair.type<CAD.Component, string>);}


Using the primitives

CAD.ComponentGPS

CAD.ComponentAirFrame

function {|common.BMDevice.dataOut.data<get>()|}(…) returns string { … }

CAD.Port

“dataOut”

…

server ports

“data<get>”

…

methods

“dataIn”

< , “dataOut”>

…

client port connections


Why BIR Extensions?

Avoid slowdown of interpreting “uninteresting” procedures in BIR.

Only relevant parts of configuration go into state vector (sometimes none).

Atomicity of actiondef operations means no intermediate states to be stored.

Extension API’s based loosely on work presented in “Model Checking Middleware-based Event-driven Real-time Embedded Software” [FMCO ’02]


Remote Method Indirection

When a client calls a method on some receptacle interface, this must be mapped to the correct BIR function for the facet on the end of the connection E.g, dataOut.data<get> is implemented

by two completely separate functions on BMDevice and BMClosedED components

Client must know which to call!


Solution: Require all facet methods that

implement a particular interface method (ReadData.data<get>) to be enumerated as a BIR virtual function

Wrap client receptacle call in BIR function that looks up remote method host component and function name (prev. slide), then do BIR invoke virtual

Example (next slide)…




enum {|common.ReadData.data<get>()|} { {|common.BMClosedED.dataOut.data<get>()|}, {|common.BMDevice.dataOut.data<get>()|} }virtual {|common.ReadData.data<get>()|} on {|common.ReadData.data<get>()|} { {|common.BMClosedED.dataOut.data<get>()|} -> {|common.BMClosedED.dataOut.data<get>()|} {|common.BMDevice.dataOut.data<get>()|} -> {|common.BMDevice.dataOut.data<get>()|} }

function {|common.ReadData.data<get><invoke>()|}( CAD.Component consumer, string portName, string methodName) returns string{ // CAD extension API calls to resolve remote facet component … // handlerFunction is vtable key, provider is CAD.Component result := invoke virtual {|common.ReadData.data<get>()|}( handlerFunction, provider) return result;}

Generate a set of enumerated values, virtual table, and “lookup” function for each interface method used anywhere in a facet

Generate a set of enumerated values, virtual table, and “lookup” function for each interface method used anywhere in a facet


Value Storage Persistent simple variables (modes, buffers) must be stored We add an internal key-value table indexed by variable name inside

each CAD.Component Only the keys and values are exposed in Bogor’s state vector; avoids

lots of data structure overhead

extension CAD for SystemModule {

expdef boolean hasAttribute(CAD.Component, string); expdef 'a getAttribute<'a>(CAD.Component, string); actiondef setAttribute<'a>(CAD.Component, string, 'a);

}

Mode variable appears asr-value: use getAttribute()

Mode variable appears asr-value: use getAttribute()

Mode variable appears asl-value: use setAttribute()

Mode variable appears asl-value: use setAttribute()


Constants

CPS is purposely abstract. It allows only enumerated type constants (no int or other scalars).

All CCM enumerated types are visible to CPS, plus private domains of mode variables. E.g., IDL:

enum OnOffMode { enabled, disabled };

CPS:mode amEnabled of { enabled, disabled } init enabled;

Generates…


Constants: Implementation

// from IDL enumerationenum {|common.OnOffMode|} { {|enabled|}, {|disabled|} }

// from mode variable domainenum {|common.SomeComponentName.modeVariableName|} { {|enabled|}, {|disabled|} }

Like CORBA, BIR enumerated types are never assignment-compatible. Semantics preserved.

Like CORBA, BIR enumerated types are never assignment-compatible. Semantics preserved.


Receptacle Method Calls

x := dataIn.data;

CPS: Getting return value of accessor for dataIn.data

BIR:string temp1;…loc locHere: // make temp1 hold value of dataIn.data do { temp1 := invoke {|ReadData.data<get><invoke>|}( {|this|}, "dataIn", "data<get>") };

Use wrapper function from a few slides ago to facilitate call to remote object method

Use wrapper function from a few slides ago to facilitate call to remote object method


CPS Expression Nesting

CPS allows arbitrarily nested expressions:port1.setValues( port2.calculateData(), port3.readSensor());

Naïve implementation in BIR:…loc locHere: do { invoke {|Interface1.setValues()<invoke>|} ( {|this|}, "port1", "setValues", invoke {|Interface2.calculateData()<invoke>|}( {|this|}, "port2", "calculateData"), invoke {|Interface3.readSensor()<invoke>|}( {|this|}, "port3", "readSensor") ) } goto locThere;

Illegal! invoke must be the sole command appearing in a transition

Illegal! invoke must be the sole command appearing in a transition

Function calls imply P.C. change, which mandates a new thread control point

Function calls imply P.C. change, which mandates a new thread control point


CPS Expression Nesting

port1.setValues( port3.readSensor());

Correct BIR:string temp1;…loc locHere0: do { temp1 := invoke {|Interface3.readSensor()<invoke>|} ( {|this|}, "port3", "readSensor") } goto locHere1;loc locHere1: do { invoke {|Interface1.setValues()<invoke>|} ( {|this|}, "port1", "setValues", temp1) } goto locThere;

Shorter to fit on slide

CPS:

Workaround: recursively pre-evaluate all nested expressions before evaluating top exp.

Workaround: recursively pre-evaluate all nested expressions before evaluating top exp.

Same trick that compilers for stack-based machines use.

Same trick that compilers for stack-based machines use.


CPS Statements: Assignment

writeData.data := <e>;

CPS:

Updating IDL attribute on ReadWriteData interface

BIR:string temp1;…loc locHere0: do { temp1 := <last step of recursively evaluating e> } goto locHere1;loc locHere1: do { invoke {|ReadWriteData.data<set>|} ( {|this|}, "writeData", "data<set>", temp1) } goto locThere;

When LHS is an attribute, use mutator method

When LHS is an attribute, use mutator method


CPS Statements: Assignment

amEnabled := common.OnOffMode.enabled;

CPS: Updating value of mode variable inside component

BIR:string temp1;…loc locHere0: do { temp1 := {|common.OnOffMode|}.{|enabled|}; } goto locHere1;loc locHere1: do { CAD.setAttribute<{|common.OnOffMode|}>( {|this|}, "amEnabled", temp1); } goto locThere;

When LHS is a simple value, use storage directly on component

When LHS is a simple value, use storage directly on component


CPS Statements: Abstract Assignment

Abstract assignment preserves dataflow, but turns off all value tracing

Often used to signify omitted numerical computation

LHS gets all possible values in domain (if bounded like enum’s) or default value if unbounded (e.g., string)

boolean dataOk;dataOk :- dataIn.data;

CPS:dataIn.data is somehow used to calculate the value of dataOk


CPS Statements: Abstract Assignment

boolean dataOk;dataOk :- dataIn.data;

CPS:

BIR:string temp1;…loc locHere0: do { temp1 := <last step in recursively evaluating dataIn.data>; } goto locHere1;loc locHere1: do { CAD.setAttribute<boolean>( {|this|}, "dataOk", true); } goto locThere;

do { CAD.setAttribute<boolean>( {|this|}, "dataOk", true); } goto locThere;…

Nondeterministically assign all values to dataOk

Nondeterministically assign all values to dataOk


CPS Statements:Event Propagation

push new DataAvailable {} on outDataAvailable;

CPS: Emit an event on the outDataAvailable port

BIR:… loc locHere: invisible invoke fireEventFromComponent( {|this|}, "outDataAvailable" CAD.createEvent<{|EventType|}>( {|EventType|}.{|common.DataAvailable|})) goto locThere;…

Use library function to multiplex event to subscriber list, handle cross-thread queuing

Use library function to multiplex event to subscriber list, handle cross-thread queuing


CPS Statements:Control flow

CPS: Branch on boolean condition

BIR:boolean temp1;…loc locHere0: do { temp1 := <last step of recursively evaluating e> } goto locHere1;loc locHere1: when temp1 do {} goto B1; when !temp1 do {} goto B2;

if (e) { B1; }else { B2; }

loc B1: … goto locJoin;loc B2: … goto locJoin;loc locJoin: …


CPS Statement Compiler

Implements all the techniques we’ve just seen

Coded with the Visitor pattern descends CPS syntax tree recursively produces tail list of BIR

commands for last n CPS statements


Time Many threads are running

Event dispatchers (20Hz, 10Hz, 1Hz) Periodic timeout simulators Global clock

Naïve consideration of all interleavings == intractable state space for small systems

Must leverage domain-specific DRE knowledge to throw out infeasible schedules


Time: Priority Scheduling

Observation: dispatcher threads are strictly priority-scheduled in Prism

The 20 Hz thread always beats out 5 Hz and 1 Hz for CPU (if it’s ready)

In the model: adapt Bogor’s scheduler to toss out any lower-priority event-dispatch threads when higher-priority dispatcher is enabled

Instantly reduces prior blowup exponential in number of total dispatcher control points to constant


Time: Overruns Periodic nature of triggering events

requires that each X-Hz job complete before the next X-Hz task arrives (via system timeout)

Engineers already have ways to analyze schedulability.

Observation: any interleaving that features a frame overrun is infeasible.

In the model: allow event dispatch threads to flush pending events before timeout injectors can run again.

Reduces system to almost deterministic.


Putting it all together Create a BIR implementation function for

each CPS method Pull in static content

Middleware ADT language extensions Event multiplexing, dispatching library

functions Create virtual dispatch infrastructure for

each interface/handler method Insert threads to simulate periodic timeout Build initialization thread that constructs

component structure from middleware ADT extensions


Model Checking in Cadena


Experimental Results

Hand-fashioned

Automatically compiled

61x blowup



Hand-fashioned


26x blowup



Hand-fashioned


3.5x blowup



Hand-fashioned


0.91x blowup


Evaluation

Indirection of middleware for receptacle calls Hand implementation used hard-coded

knowledge (e.g., CAD.getAttribute<string>(GPS, “data”))… no PC change

Automated implementation uses at least two invoke’s: one to call port look function, second to call method handler

Hurts badly on simple scenarios (BasicSP) The price of a system designed to handle

dynamic reconfiguration


Evaluation

Correlator primitives Hand implementation (ad-hoc) did it all

in BIR Implementation of correlator

specification does all acceptor work/event emission inside the atomic step of a BIR extension

Helps enormously on scenarios that lean heavily on event correlation (MediumSP: 8 EC’s)


Evaluation

The nesting problem (e.g., p1.foo(p2.bar())) Generated code is completely unraveled

(even constants are not inlined) An optimizer working on simple patterns

would probably work well here{|common.ModeDomain|} temp1, temp2;boolean temp3;… temp1 := invoke {|Interface.getMode()<invoke>|} ( {|this|}, “p1", “getMode")… temp2 := {|common.ModeDomain|}.{|good|};… temp3 := temp1 == temp2;…loc locHere1: when temp3 do {} goto thenBranch; when !temp3 do {} goto elseBranch;

if (p1.getMode() == ModeDomain.good) { …} else { …}

Inefficiency of compiled CPS expressions


Future Work Cut down CPS expression unraveling

Only out-line those things that actually imply a program counter change

Introduce parameterized regular expression specification language (CSL??) [Childs, Jayaraman] “for all instances c of BMLazyActive, all data

consumers refresh their data before utilizing cached data when c receives notice that its data is stale”

“when c publishes that it has updated data, at least one component retrieves the data before the next update”


Thanks (… for all the fish)

Dr. Andresen Many years of putting up with my

questions and crazy systems ideas Career advice, academic steering

Dr. Dwyer Dropping a satisfying M.S. project into

my lap Robby

Bootstrapping me into Bogor Lots of close work on updating API’s to

accommodate C2B

--Douglas Adams

automated extraction of transition systems from component-model architectures

Documents

objectsynchronous semantics

model checker verification

new tools

design process

cpu time

unit of composition

eventdispatching threads

analysis tool