Automated extraction of transition systems from component model architectures
Download
1 / 76

Automated Extraction of Transition Systems from Component-model Architectures - PowerPoint PPT Presentation


  • 117 Views
  • Uploaded on

Automated Extraction of Transition Systems from Component-model Architectures. Matt Hoosier. SAnToS Laboratory, Kansas State University, USA. http://cadena.projects.cis.ksu.edu. Overview. Distributed mission-critical software is starting a trend toward component-based middleware

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about ' Automated Extraction of Transition Systems from Component-model Architectures' - valiant


An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
Automated extraction of transition systems from component model architectures

Automated Extraction of Transition Systems from Component-model Architectures

Matt Hoosier

SAnToS Laboratory, Kansas State University, USA

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


Overview
Overview Component-model Architectures

  • 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

Extracting Transition Systems from Component Models


Outline
Outline Component-model Architectures

  • 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

Extracting Transition Systems from Component Models


Component organization
Component Organization Component-model Architectures

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

Extracting Transition Systems from Component Models


Component organization1
Component Organization Component-model Architectures

All 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”)

Extracting Transition Systems from Component Models


Component organization2
Component Organization Component-model Architectures

“Receptacle”

“Facet”

Required interface

Provided interface

Interface ports

All 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”)

Extracting Transition Systems from Component Models


Component organization3
Component Organization Component-model Architectures

Publisher

Subscriber

Event ports

“Source”

“Sink”

All 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”)

Extracting Transition Systems from Component Models


Embedded components
Embedded Components Component-model Architectures

  • 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

Extracting Transition Systems from Component Models


Prism development methodologies
Prism Development Methodologies Component-model Architectures

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

Extracting Transition Systems from Component Models


Cadena
Cadena Component-model Architectures

Cadena

CCM Interface Definition Language

Java/C++ Component Code

Product Line Customizations

Model Checking

State Transitions

System Configuration

<CONFIGURATION_PASS>

<HOME> <…>

<COMPONENT>

<ID> <…></ID>

<EVENT_SUPPLIER>

<…events this component supplies…>

</EVENT_SUPPLIER>

</COMPONENT>

</HOME>

</CONFIGURATION_PASS>

High-level Specification Language

Eclipse Plug-In

Prism XML Configurator Info

Integrated Development Environment

Analysis and QoS

Aspect Synthesis

Extracting Transition Systems from Component Models


Behavioral specification
Behavioral Specification Component-model Architectures

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

Extracting Transition Systems from Component Models


Behavioral specification1
Behavioral Specification Component-model Architectures

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

Extracting Transition Systems from Component Models


Structure specification
Structure Specification Component-model Architectures

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

CORBA Interface Definition Language (IDL): Structural Definitions

Extracting Transition Systems from Component Models


Structure event sources
Structure: Event Sources Component-model Architectures

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

Event source port

Extracting Transition Systems from Component Models


Structure event sinks
Structure: Event Sinks Component-model Architectures

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

Event sink port

Extracting Transition Systems from Component Models


Structure interface consumers
Structure: Interface Consumers Component-model Architectures

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

Remote interface client

Extracting Transition Systems from Component Models


Structure interface providers
Structure: Interface Providers Component-model Architectures

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

Interfaces accessible to others remotely (servers)

Extracting Transition Systems from Component Models


Behavioral specification2
Behavioral Specification Component-model Architectures

Cadena Component Property Specification (CPS)

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

Extracting Transition Systems from Component Models


Behavior mode variables
Behavior: Mode Variables Component-model Architectures

enum OnOffMode {enabled, disabled};

Small, bounded domains

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

Behavior-control variables

Like finite state control in an automaton

Extracting Transition Systems from Component Models


Behavior handler methods
Behavior: Handler Methods Component-model Architectures

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

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

Handler method for event sink

Extracting Transition Systems from Component Models


Behavior modal control
Behavior: Modal Control Component-model Architectures

I/O Port Dependencies Differ

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

Modal Control Flow

Extracting Transition Systems from Component Models


Behavior dataflow
Behavior: Dataflow Component-model Architectures

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

Tracks inflow/outflow of values, but not computation

Extracting Transition Systems from Component Models


Behavior event propagation
Behavior: Event Propagation Component-model Architectures

  • componentBMModal {

  • providesChangeModemodeChange;

  • providesReadDatadataOut;

  • usesReadDatadataIn;

  • publishesDataAvailableoutDataAvailable;

  • consumesDataAvailableinDataAvailable;

  • modebmModalModeofcommon.OnOffMode

  • initcommon.OnOffMode.enabled;

  • behavior {

  • stringbuf;

  • handleinDataAvailable(DataAvailablee) {

  • casebmModalModeof {

  • common.OnOffMode.enabled:

  • buf := dataIn.data;

  • pushnewDataAvailable {} onoutDataAvailable;

  • common.OnOffMode.disabled:

  • }

    • }

  • }

  • };

Emit event through source port

Extracting Transition Systems from Component Models


Event correlation
Event Correlation Component-model Architectures

+

An

A3

A2

A1

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

  • Reduce network bandwidth

  • Keep components simple

B

Extracting Transition Systems from Component Models


Event correlation example
Event Correlation: Example Component-model Architectures

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

Correlator becomes a bona fide type: And

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

DataAvailablecorrelation And (

DataAvailable e1,

DataAvailable e2)

e1 + e2

{

case true:

push new DataAvailable {};

}

Extracting Transition Systems from Component Models


Prism middleware implementation
Prism Middleware Implementation Component-model Architectures

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]

Extracting Transition Systems from Component Models


Prism middleware implementation1
Prism Middleware Implementation Component-model Architectures

Abstractly…

consume

produce

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

Extracting Transition Systems from Component Models


Prism middleware implementation2
Prism Middleware Implementation Component-model Architectures

Proxy

Supplier

Event channel

In reality…

proxy

dispatch

consume

threading

timer/

thread pool

queuing

filtering

network

multiplexing

produce

consumer

references

Proxy

Consumer

proxy

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

Extracting Transition Systems from Component Models


My contributions
My Contributions Component-model Architectures

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

Extracting Transition Systems from Component Models


On the model checker used
On the model checker used… Component-model Architectures

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

Extracting Transition Systems from Component Models


Bogor model checker
Bogor Model Checker Component-model Architectures

Front-end

Model Checking Components

Lexer

IStateMgr

IActionTaker

IBacktrackIF

.bir

Parser

ISearcher

IExpEvaluator

ITransformer

Type Checking

IStateFactory

IValueFactory

ISchedulingStg

.config

Semantic

Analyses

  • Developed at Kansas State University [Robby]

  • Actually, a framework with swappable modules

  • … as opposed to SPIN

Verified

Counter

Example

Extracting Transition Systems from Component Models


Bogor modeling language bir
Bogor Modeling Language: Component-model ArchitecturesBIR

BIR = Bandera Intermediate Representation

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

Extracting Transition Systems from Component Models


Bir example 2 dining philosophers
BIR Example: Component-model Architectures2 Dining Philosophers

right

left

right

left

Taken from the Bogor Tutorial [ETAPS ’04]

Extracting Transition Systems from Component Models


Bir example 2 dining philosophers1
BIR Example: Component-model Architectures2 Dining Philosophers

systemTwoDiningPhilosophers {

recordFork { booleanisHeld; }

mainthreadMAIN() {

Forkfork1;

Forkfork2;

locloc0:

do {

// create forks

fork1 := newFork;

fork2 := newFork;

// start philosophers

startPhil(fork1, fork2);

startPhil(fork2, fork1);

} return;

}

threadPhil(Forkleft, Forkright) {

locloc0: // take left fork

when !left.isHelddo {

left.isHeld := true;

} gotoloc1;

locloc1: // take right fork

when !right.isHelddo

{ right.isHeld := true; }

gotoloc2;

locloc2: // put right fork

do { right.isHeld := false; }

gotoloc3;

locloc3: // put left fork

do { left.isHeld := false; }

gotoloc0;

}

}

Extracting Transition Systems from Component Models


Bir example 2 dining philosophers2
BIR Example: Component-model Architectures2 Dining Philosophers

Uses a record to model forks

systemTwoDiningPhilosophers {

recordFork { booleanisHeld; }

mainthreadMAIN() {

Forkfork1;

Forkfork2;

locloc0:

do {

// create forks

fork1 := newFork;

fork2 := newFork;

// start philosophers

startPhil(fork1, fork2);

startPhil(fork2, fork1);

} return;

}

threadPhil(Forkleft, Forkright) {

locloc0: // take left fork

when !left.isHelddo {

left.isHeld := true;

} gotoloc1;

locloc1: // take right fork

when !right.isHelddo

{ right.isHeld := true; }

gotoloc2;

locloc2: // put right fork

do { right.isHeld := false; }

gotoloc3;

locloc3: // put left fork

do { left.isHeld := false; }

gotoloc0;

}

}

Extracting Transition Systems from Component Models


Bir example 2 dining philosophers3
BIR Example: Component-model Architectures2 Dining Philosophers

Thread declarations

systemTwoDiningPhilosophers {

recordFork { booleanisHeld; }

mainthreadMAIN() {

Forkfork1;

Forkfork2;

locloc0:

do {

// create forks

fork1 := newFork;

fork2 := newFork;

// start philosophers

startPhil(fork1, fork2);

startPhil(fork2, fork1);

} return;

}

threadPhil(Forkleft, Forkright) {

locloc0: // take left fork

when !left.isHelddo {

left.isHeld := true;

} gotoloc1;

locloc1: // take right fork

when !right.isHelddo

{ right.isHeld := true; }

gotoloc2;

locloc2: // put right fork

do { right.isHeld := false; }

gotoloc3;

locloc3: // put left fork

do { left.isHeld := false; }

gotoloc0;

}

}

Extracting Transition Systems from Component Models


Bir example 2 dining philosophers4
BIR Example: Component-model Architectures2 Dining Philosophers

threadPhil(Forkleft, Forkright) {

locloc0: // take left fork

when !left.isHelddo {

left.isHeld := true;

} gotoloc1;

locloc1: // take right fork

when !right.isHelddo

{ right.isHeld := true; }

gotoloc2;

locloc2: // put right fork

do { right.isHeld := false; }

gotoloc3;

locloc3: // put left fork

do { left.isHeld := false; }

gotoloc0;

}

}

Local variable declarations

systemTwoDiningPhilosophers {

recordFork { booleanisHeld; }

mainthreadMAIN() {

Forkfork1;

Forkfork2;

locloc0:

do {

// create forks

fork1 := newFork;

fork2 := newFork;

// start philosophers

startPhil(fork1, fork2);

startPhil(fork2, fork1);

} return;

}

Extracting Transition Systems from Component Models


Bir example 2 dining philosophers5
BIR Example: Component-model Architectures2 Dining Philosophers

threadPhil(Forkleft, Forkright) {

locloc0: // take left fork

when !left.isHelddo {

left.isHeld := true;

} gotoloc1;

locloc1: // take right fork

when !right.isHelddo

{ right.isHeld := true; }

gotoloc2;

locloc2: // put right fork

do { right.isHeld := false; }

gotoloc3;

locloc3: // put left fork

do { left.isHeld := false; }

gotoloc0;

}

}

Control locations

systemTwoDiningPhilosophers {

recordFork { booleanisHeld; }

mainthreadMAIN() {

Forkfork1;

Forkfork2;

locloc0:

do {

// create forks

fork1 := newFork;

fork2 := newFork;

// start philosophers

startPhil(fork1, fork2);

startPhil(fork2, fork1);

} return;

}

Extracting Transition Systems from Component Models


Bir example 2 dining philosophers6
BIR Example: Component-model Architectures2 Dining Philosophers

When condition

is true

Execute these

statement(s)

atomically

Trivially true

guards

…aka “guarded transitions”, “guarded commands”

Guarded transformations

threadPhil(Forkleft, Forkright) {

locloc0: // take left fork

when !left.isHelddo {

left.isHeld := true;

} gotoloc1;

locloc1: // take right fork

when !right.isHelddo

{ right.isHeld := true; }

gotoloc2;

locloc2: // put right fork

do { right.isHeld := false; }

gotoloc3;

locloc3: // put left fork

do { left.isHeld := false; }

gotoloc0;

}

}

Extracting Transition Systems from Component Models


Modeling approach
Modeling Approach Component-model Architectures

  • 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

Extracting Transition Systems from Component Models


Publish subscribe primitives
Publish/Subscribe Primitives Component-model Architectures

Add abstract types (like channels in SPIN)

extensionCADforSystemModule {

// declaration of abstract types

typedefEvent;

typedefComponent;

// constructors

expdefCAD.Component createComponent(string);

expdefCAD.EventcreateEvent<'a>('a);

// manipulation of subscriber lists

actiondefaddSubscriberList(CAD.Component, string);

actiondefaddSubscriber<'a>(CAD.Component, string, 'a);

expdef'a[] getSubscribers<'a>(CAD.Component, string);

}

recordSubscriber {

EventHandlerTypehandlerFunction;

stringportName;

}

functionfireEventFromComponent(

CAD.ComponentsourceComp, stringport, CAD.Eventevent) {}

Populate/query subscriber lists

}

Unit of subscribership

}

Event multiplexing and queuing

Extracting Transition Systems from Component Models


Publish subscribe primitives event correlators
Publish/Subscribe Primitives: Event Correlators Component-model Architectures

extensionCorrelatorforCorrelatorModule {

// abstract type for correlator; encapsulates acceptor automaton

typedeftype;

// Constructor: builds complete automaton from spec. string

expdefCorrelator.typecreate(string);

// Handle incoming event and dump a newly allocated ‘evtType

// into the list for each compound event triggered

actiondefhandleEvent<'evtType>(

Correlator.type, string, List.type<'evtType>);

// subscriber list maintenance

actiondefaddSubscriber<'a>(Correlator.type, 'a);

expdef'a[] getSubscribers<'a>(Correlator.type);

}

// allow correlators to be consumers of component events

recordCorrelatorSubscriberextendsSubscriber { … }

// analagous to event multiplexing and queuing from components

functionfireEventFromCorrelator(Correlator.typecor, CAD.Evente) { … }

Extracting Transition Systems from Component Models


Interface port primitives
Interface Port Primitives Component-model Architectures

extensionCADforSystemModule {

// abstract type for provided (server) port

typedefPort;

// constructors

expdefCAD.PortcreatePort();

// attach server ports to components

actiondefregisterPort(CAD.Component, CAD.Port, string);

expdefCAD.PortgetPort(CAD.Component, string);

// put BIR function pseudo-references into ports (for named methods)

actiondefsetPortMethodHandler<'a>(CAD.Port, string, 'a);

expdef'agetPortMethodHandler<'a>(CAD.Port, string);

// make client <-> server connections

actiondefconnectPorts(

Pair.type<CAD.Component, string>,

Pair.type<CAD.Component, string> );

expdefPair.type<CAD.Component, string> getProvider(

Pair.type<CAD.Component, string>);

}

Extracting Transition Systems from Component Models


Using the primitives
Using the primitives Component-model Architectures

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

returnsstring { … }

CAD.ComponentGPS

CAD.ComponentAirFrame

server ports

client port connections

CAD.Port

methods

Extracting Transition Systems from Component Models


Why bir extensions
Why BIR Extensions? Component-model Architectures

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

Extracting Transition Systems from Component Models


Remote method indirection
Remote Method Indirection Component-model Architectures

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

Extracting Transition Systems from Component Models


Remote method indirection1
Remote Method Indirection Component-model Architectures

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

Extracting Transition Systems from Component Models


Remote method indirection2
Remote Method Indirection Component-model Architectures

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.Componentconsumer,

stringportName,

stringmethodName) returnsstring

{

// CAD extension API calls to resolve remote facet component

// handlerFunction is vtable key, provider is CAD.Component

result := invokevirtual{|common.ReadData.data<get>()|}(

handlerFunction, provider)

returnresult;

}

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

Extracting Transition Systems from Component Models


Value storage
Value Storage Component-model Architectures

extensionCADforSystemModule {

expdefbooleanhasAttribute(CAD.Component, string);

expdef'agetAttribute<'a>(CAD.Component, string);

actiondefsetAttribute<'a>(CAD.Component, string, 'a);

}

  • 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

Mode variable appears asr-value: use getAttribute()

Mode variable appears asl-value: use setAttribute()

Extracting Transition Systems from Component Models


Constants
Constants Component-model Architectures

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

Extracting Transition Systems from Component Models


Constants implementation
Constants: Implementation Component-model Architectures

// from IDL enumeration

enum{|common.OnOffMode|}

{

{|enabled|},

{|disabled|}

}

// from mode variable domain

enum{|common.SomeComponentName.modeVariableName|}

{

{|enabled|},

{|disabled|}

}

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

Extracting Transition Systems from Component Models


Receptacle method calls
Receptacle Method Calls Component-model Architectures

string temp1;

loc locHere:

// make temp1 hold value of dataIn.data

do {

temp1 := invoke{|ReadData.data<get><invoke>|}(

{|this|},

"dataIn",

"data<get>")

};

BIR:

Getting return value of accessor for dataIn.data

CPS:

x := dataIn.data;

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

Extracting Transition Systems from Component Models


Cps expression nesting
CPS Expression Nesting Component-model Architectures

CPS allows arbitrarily nested expressions:

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

port1.setValues( port2.calculateData(), port3.readSensor());

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;

Naïve implementation in BIR:

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

Extracting Transition Systems from Component Models


Cps expression nesting1
CPS Expression Nesting Component-model Architectures

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;

Correct BIR:

CPS:

port1.setValues( port3.readSensor());

Shorter to fit on slide

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

Same trick that compilers for stack-based machines use.

Extracting Transition Systems from Component Models


Cps statements assignment
CPS Statements: Assignment Component-model Architectures

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;

BIR:

CPS:

Updating IDL attribute on ReadWriteData interface

writeData.data := <e>;

When LHS is an attribute, use mutator method

Extracting Transition Systems from Component Models


Cps statements assignment1
CPS Statements: Assignment Component-model Architectures

string temp1;

loc locHere0:

do {

temp1 := {|common.OnOffMode|}.{|enabled|};

} goto locHere1;

loc locHere1:

do {

CAD.setAttribute<{|common.OnOffMode|}>(

{|this|},

"amEnabled",

temp1);

} goto locThere;

BIR:

Updating value of mode variable inside component

CPS:

amEnabled := common.OnOffMode.enabled;

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

Extracting Transition Systems from Component Models


Cps statements abstract assignment
CPS Statements: Component-model ArchitecturesAbstract Assignment

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

CPS:

boolean dataOk;dataOk :- dataIn.data;

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

Extracting Transition Systems from Component Models


Cps statements abstract assignment1
CPS Statements: Component-model ArchitecturesAbstract Assignment

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;

BIR:

Nondeterministically assign all values to dataOk

CPS:

boolean dataOk;dataOk :- dataIn.data;

Extracting Transition Systems from Component Models


Cps statements event propagation
CPS Statements: Component-model ArchitecturesEvent Propagation

loc locHere:

invisibleinvokefireEventFromComponent(

{|this|},

"outDataAvailable"

CAD.createEvent<{|EventType|}>(

{|EventType|}.{|common.DataAvailable|}))

gotolocThere;

BIR:

Emit an event on the outDataAvailable port

CPS:

push new DataAvailable {} on outDataAvailable;

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

Extracting Transition Systems from Component Models


Cps statements control flow
CPS Statements: Component-model ArchitecturesControl flow

boolean temp1;

loc locHere0:

do {

temp1 :=

<last step of

recursively

evaluating e>

} goto locHere1;

loc locHere1:

when temp1 do {} gotoB1;

when !temp1 do {} gotoB2;

locB1:

goto locJoin;

locB2:

goto locJoin;

loc locJoin:

Branch on boolean condition

CPS:

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

BIR:

Extracting Transition Systems from Component Models


Cps statement compiler
CPS Statement Compiler Component-model Architectures

  • 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

Extracting Transition Systems from Component Models


Time Component-model Architectures

  • 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

Extracting Transition Systems from Component Models


Time priority scheduling
Time: Priority Scheduling Component-model Architectures

  • 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

Extracting Transition Systems from Component Models


Time overruns
Time: Overruns Component-model Architectures

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

Extracting Transition Systems from Component Models


Putting it all together
Putting it all together Component-model Architectures

  • 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

Extracting Transition Systems from Component Models


Model checking in cadena
Model Checking in Cadena Component-model Architectures

Extracting Transition Systems from Component Models


Model checking in cadena1
Model Checking in Cadena Component-model Architectures

Extracting Transition Systems from Component Models


Experimental results
Experimental Results Component-model Architectures

61x blowup

Automatically compiled

Hand-fashioned

Extracting Transition Systems from Component Models


Experimental results1
Experimental Results Component-model Architectures

26x blowup

Automatically compiled

Hand-fashioned

Extracting Transition Systems from Component Models


Experimental results2
Experimental Results Component-model Architectures

3.5x blowup

Automatically compiled

Hand-fashioned

Extracting Transition Systems from Component Models


Experimental results3
Experimental Results Component-model Architectures

0.91x blowup

Automatically compiled

Hand-fashioned

Extracting Transition Systems from Component Models


Evaluation
Evaluation Component-model Architectures

  • 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

Extracting Transition Systems from Component Models


Evaluation1
Evaluation Component-model Architectures

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

Extracting Transition Systems from Component Models


Evaluation2
Evaluation Component-model Architectures

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

  • 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

  • Inefficiency of compiled CPS expressions

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

Extracting Transition Systems from Component Models


Future work
Future Work Component-model Architectures

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

Extracting Transition Systems from Component Models


Thanks for all the fish
Thanks (… for all the fish) Component-model Architectures

--Douglas Adams

  • 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

Extracting Transition Systems from Component Models


ad