Automated extraction of transition systems from component model architectures
This presentation is the property of its rightful owner.
Sponsored Links
1 / 76

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


  • 86 Views
  • Uploaded on
  • Presentation posted in: General

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

Download Presentation

Automated Extraction of Transition Systems from Component-model Architectures

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

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

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

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

“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

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

  • 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

  • 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

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

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

  • 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

  • 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

  • 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

  • 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

  • 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

  • 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

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

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

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

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

  • 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

  • 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

+

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

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

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

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

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

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

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

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

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

  • 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

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

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

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

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?

  • 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

  • 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

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

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

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

  • 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

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

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

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

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

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

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: Abstract 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: Abstract 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:Event 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:Control 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

  • 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


Automated extraction of transition systems from component model architectures

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

Extracting Transition Systems from Component Models


Time priority scheduling

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

Extracting Transition Systems from Component Models


Time overruns

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.

Extracting Transition Systems from Component Models


Putting it all together

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

Extracting Transition Systems from Component Models


Model checking in cadena

Model Checking in Cadena

Extracting Transition Systems from Component Models


Model checking in cadena1

Model Checking in Cadena

Extracting Transition Systems from Component Models


Experimental results

Experimental Results

61x blowup

Automatically compiled

Hand-fashioned

Extracting Transition Systems from Component Models


Experimental results1

Experimental Results

26x blowup

Automatically compiled

Hand-fashioned

Extracting Transition Systems from Component Models


Experimental results2

Experimental Results

3.5x blowup

Automatically compiled

Hand-fashioned

Extracting Transition Systems from Component Models


Experimental results3

Experimental Results

0.91x blowup

Automatically compiled

Hand-fashioned

Extracting Transition Systems from Component Models


Evaluation

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

Extracting Transition Systems from Component Models


Evaluation1

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)

Extracting Transition Systems from Component Models


Evaluation2

Evaluation

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

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

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


  • Login