Reconciling the Boeing PCES OEP with CCM Component Structure

1
Reconciling the Boeing PCES OEP with CCM
Component Structure
John Hatcliff (slide maker and talk giver) many
others contributed including Venkatesh Ranganath,
Gurdip Singh, William Deng
http//www.cis.ksu.edu/santos/KSU-CCM-Workshop
2
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.

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

4
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 dont 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.

5
Claims
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.

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

6
Motivating Example
void BM__PushPullComponentImplUpdate (const
UUEventSet events) UM__GUARD_EXTERNAL_REGION(G
etExternalPushLock())
BM__ComponentInstrumentationEventConsumer(GetId(
), "Update", events) unsigned int tempData1
GetId().GetGroupId() unsigned int tempData2
GetId().GetItemId() stdvectorltBM__ClosedC
omponentgtiterator devIter devices_.begin()
stdvectorltBM__ClosedComponentgtiterator
endIter devices_.end() for ( devIter !
endIter devIter) BM__ClosedComponent
component devIter const UUIdentifier
id component-gtGetId() if
(idInEventSet(id, events)) (see next
slide) UM__GUARD_INTERNAL_REGION
data1_ tempData1 data2_ tempData2
Get UUID of from supplier
7
Motivating Example (continued)
const BM__ClosedFunctionalFacet facet
component-gtProvideClosedFunctionalFacet()
tempData1 facet.GetData1()
tempData2 facet.GetData2()
8
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).
from MOBIES OEP Configuration Interface (v. 2.3)
Wendy Roll
9
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 components id to be set via
  the .cpf file.

interface IDComponent readonly attribute
string id
10
Issue Event Connections
CCM

• multiple typed event source/sink ports
• one push method for each sink port

T1
T2
T3
11
OEP Event Structure
OEP

• 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

12
Event Connections -- Assessment
OEP
static event type (kind)-checking is problematic

• 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

13
Event Connections -- Assessment
OEP
dynamic de-multiplexing (branching on source_ids
and event type-tags) significantly complicates
design-time formal reasoning
Example Dependency specification checking
dependencies between particular suppliers or
event types and other component actions are
tangled and more difficult to specify and check
statically
T1
T2
?
T3
OEP
CCM
14
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
15
Solution 1 Assessment
Pros (same as current Boeing structure)

• Generic structure (list of generic events) allows
  variable number of connections
• Generic event type allows event polymorphism

Cons (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)

16
Solution 2 Event Types
eventtype DataAvailable readonly attribute
ltany typegt payload component AirFrame
IDComponent publishes DataAvailable
dataOut consumes DataAvailable dataIn

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

17
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
CORBA any event type (top of event inheritance
hierarchy)
T2
T3
CCM
18
Issue Timer event subscriptions
Device componet
What should the CORBA event type of this event
be, and what should we connect to at design level?
20 Hz Timer Event

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

19
Solution 1 CORBA Timer Service
Port names
Timer20Hz
CORBA Timer Service
Timer10Hz

Timer1Hz

• 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

20
Solution 2
eventtype TimeEvent readonly attribute integer
rate component GPS consumes TimerEvent
timeout

• 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 Venkateshs talk on XML issues)