reconciling the boeing pces oep with ccm component structure john hatcliff (slide maker and talk...

Reconciling the Boeing PCES OEP with CCM Component Structure

http://www.cis.ksu.edu/santos/KSU-CCM-Workshop

John Hatcliff (slide maker and talk giver)…many others contributed including Venkatesh Ranganath, Gurdip Singh, William Deng

KSU CCM Workshop --- Reconciling the Boeing OEP and CCM 2May 19, 2003

Why discuss these issues now… Meeting goal: move forward bringing Cadena and CIAO together

to address PCES goals. Ultimate aim is to support development of DRE systems

(including the Boeing OEP). Cadena and CIAO teams need to agree on…

common examples requires agreement on how to structure DRE systems in CCM

common intermediate formats (configuration, deployment, packing) requires agreement on how to augment conventional CCM artifacts to

include RT & QoS properties. So the desired outcome with these talks is

not only a convergence of ideas related to how to recast the Boeing OEP in CCM,

but resolution of a number of issues that will allow us to support development of realistic DRE systems in an environment that is general enough to support the Boeing OEP.

In other words, having these discussions will force us to talk about some relevant concrete issues that both groups will need to consider if we want to support realistic systems.


Real Reason to Talk…

We are not CORBA experts …but now we have a bunch in this

room. We have been struggling with how to

resolve some of these issues for 9+ months now …and we would like to get your

feedback, and bring some of these to conclusion.


Goals and anti-Goals Expose a list of issues that we need to be

addressed between Cadena/CIAO as we try to move to real systems.

Collect proposed solutions (if they are clear) to as many issues as possible.

Anti-Goal: spend a lot of time thrashing around try to agree on final solutions.

We don’t want to get bogged down trying to finalize a solutions without the input from the Boeing people

We will just try to collect some notes, dump them into the existing document summarizing these issues.

Continue to circulate and evolve this document with hope of convergence at a later date

…but lets try to make some progress in next two days on XML configuration issues since that is a primary connection point between Cadena and CIAO.


Claims OEP components are very (overly?) generic

very generic and dynamic checking of inputs classes with CCM philosophy and makes various types of formal checking by static analysis more difficult.

Many things are only captured dynamically instead of statically e.g., event types, communication topology makes various forms of automated analysis

much harder or impossible CCM-like port structure is not utilized

e.g., single generic dynamically typed event sink ports in OEP vs. multiple statically typed event sink ports in CCM.

Note: these are not knocks against the OEP designers – many of the issues below simply were not apparent in their context when the OEP was designed.

Note: these are not knocks against the OEP designers – many of the issues below simply were not apparent in their context when the OEP was designed.


Motivating Examplevoid BM__PushPullComponentImpl::Update (const UUEventSet& events){ UM__GUARD_EXTERNAL_REGION(GetExternalPushLock()); BM__ComponentInstrumentation::EventConsumer(GetId(), "Update", events);

unsigned int tempData1 = GetId().GetGroupId(); unsigned int tempData2 = GetId().GetItemId();

std::vector<BM__ClosedComponent*>::iterator devIter = devices_.begin(); std::vector<BM__ClosedComponent*>::iterator endIter = devices_.end();

for (; devIter != endIter; ++devIter) { BM__ClosedComponent* component = *devIter; const UUIdentifier& id = component->GetId();

if (idInEventSet(id, events)) { (see next slide) } } UM__GUARD_INTERNAL_REGION; data1_ = tempData1; data2_ = tempData2;}

Locking macros – components are “aspectized” on locking strategy

Locking macros – components are “aspectized” on locking strategy

Components are uniquely identified by (GroupId, ItemId ) pair

Components are uniquely identified by (GroupId, ItemId ) pair

Iterate over list of facet providers (note hard-coding of structure for BM_Closed)

Iterate over list of facet providers (note hard-coding of structure for BM_Closed)

Get “UUID” of from supplier

Get “UUID” of from supplier

Does this ID appear in events that were pushed?

Does this ID appear in events that were pushed?


Motivating Example (continued)

const BM__ClosedFunctionalFacet& facet = component->ProvideClosedFunctionalFacet(); tempData1 += facet.GetData1(); tempData2 += facet.GetData2();

When supplier ID matches with ID actually arriving in current event, get the associated component’s facet

When supplier ID matches with ID actually arriving in current event, get the associated component’s facet

Call facet method to fetch data.

Call facet method to fetch data.


Issue: Component IDs

Component instances in the OEP are uniquely identified by… (Name, Group_ID, Item_ID) triple

Group_ID and Item_ID are integers that are appended to provide a unique identifier within the entire configuration. The Group_ID and Item_ID are optional and are normally automatically generated. If the Group_ID is specified, an Item_ID must also be specified. The Name values provides a domain applicable human readable representation of this unique identifier (e.g., AirFrame or GPS).

Group_ID and Item_ID are integers that are appended to provide a unique identifier within the entire configuration. The Group_ID and Item_ID are optional and are normally automatically generated. If the Group_ID is specified, an Item_ID must also be specified. The Name values provides a domain applicable human readable representation of this unique identifier (e.g., AirFrame or GPS).from MOBIES OEP Configuration Interface (v. 2.3) –

Wendy Roll


Solution: Component IDs

Main point is to have a unique ID E.g., OpenCCM has all components

implement a “Named Component” interface Proposed solution:

all components should implement IDComponent interface which has a readonly string attribute id. This allows the component’s id to be set via the .cpf file.

interface IDComponent {readonly attribute string id;

};


Issue: Event Connections

multiple typed event source/sink ports

one “push method” for each sink port

CCM

T1

T2

T3

OEP

{e1,…, en}

single event sink port receiving a list of generic events

a single push method that dynamically de-multiplexes.


OEP Event Structure

Each event list contains events with a single event structure (record) consisting of… 32-bit integer field indicating event “kind”

e.g., “dataAvailable” 20+ different event “kinds” (per Wendy)

supplier id (source id) field 32-bit integer “payload” field

OEP

{e1,…, en}


Event Connections -- Assessment

event types (event “kinds”) are represented as 32-bit integers provide a degree of genericity, but… since event types are represented using this

“universal type” there is no static type-checking on events

more prone to errors than statically framework

OEP

{e1,…, en}

static event type (kind)-checking is problematic

static event type (kind)-checking is problematic


Event Connections -- AssessmentOEP

{e1,…, en}

dynamic de-multiplexing (branching on source_id’s and event type-tags) significantly complicates design-time formal reasoning

dynamic de-multiplexing (branching on source_id’s and event type-tags) significantly complicates design-time formal reasoning

T1

T2

T3

Example: Dependency specification & checking

OEPCCM

{e1,…, en}

?

dependencies between particular suppliers or event types and other component actions are tangled and more difficult to specify and check statically

dependencies between particular suppliers or event types and other component actions are tangled and more difficult to specify and check statically


Solution [1]: Event Types

Mimic OEP Generic Event Structure

eventtype GenericEvent {readonly attribute integer event_id;readonly attribute string source_id;readonly attribute any payload;

};

Mimic OEP Component Event Interface Structure

OEP

{e1,…, en}

CCM

Sequence(GenericEvent)

…CORBA Sequence type


Solution [1]: Assessment

Generic structure (list of generic events) allows variable number of connections

Generic event type allows “event polymorphism”

Pros (same as current Boeing structure)

Static event-type checking is lost (for all practical purposes) Static reasoning about intra-component event dependencies is

much more difficult. Programmers have to write more code (de-multiplexing, checking

of event-types and supplier IDs)

Cons (same as current Boeing structure)


Solution [2]: Event Types

CORBA event types capture OEP event type tags Payload is still present, but supplier ID has disappeared Language type-checking provides type-compatibility checking for port

connections. General design rule: declare one event sink for each component

supplying an event of a particular type. This allows suppliers to be identified by knowing the port at which an

event arrived In cases where supplier identification is necessary, we can no

longer handle a variable number of suppliers. However, we can still achieve polymorphism over event inputs

using event type inheritance (see next slide).

eventtype DataAvailable {readonly attribute <any type> payload;

};

component AirFrame : IDComponent {publishes DataAvailable dataOut;consumes DataAvailable dataIn;

};


Solution [2]: Event Types It is often the case that a component simply wishes to be

notified on a certain condition – i.e., the component does not need to examine the event type,

supplier ID, or payload. In this case, the event sink port of the component should

have a type declared corresponding to the “top” event type inheritance hierarchy.

This allows a component that supplies any type of event to be plugged to the port.

T1

T2

T3

CCM

CORBA “any” event type (top of event inheritance hierarchy)

CORBA “any” event type (top of event inheritance hierarchy)


Issue: Timer event subscriptions

In the OEP, components subscribe to timer events.

What should components subscribe to in CCM? Main point: how should this be presented to

developer in assembly descriptions What should we actually connect to in the

underlying infrastructure? RT event-channel seems like obvious choice, but are

there others.

20 HzTimerEvent

Device componet

What should the CORBA event type of this event be, and what should we connect to at design level?

What should the CORBA event type of this event be, and what should we connect to at design level?


Solution [1]: CORBA Timer Service

CORBA Timer Service as a component Port names associated with different rates

Hardwires rates to port names Different component may need to be generated for each

scenario (to provide port names associated with rates specific to particular scenarios)

Meshes well with conventional CCM configuration No extra attributes are needed in XML configuration file

…CORBA Timer Service

Timer20Hz

Timer10Hz

Timer1Hz

Port names


Solution [2]:

Container is responsible for handling and delivering timing events

The component needs to indicate its interest in certain timer events to the container along with a port on which it will consume these events.

Container itself can generate events, or Container can subscribe to timing service

(see Venkatesh’s talk on XML issues)

eventtype TimeEvent {readonly attribute integer rate;

};

component GPS {consumes TimerEvent timeout;

};

reconciling the boeing pces oep with ccm component structure john hatcliff (slide maker and talk...

Documents