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. KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

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. KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

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 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. KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

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. KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

6. Motivating Example Components are uniquely identified by (GroupId, ItemId ) pair Iterate over list of facet providers (note hard-coding of structure for BM_Closed) Does this ID appear in events that were pushed? Locking macros – components are “aspectized” on locking strategy void 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; } Get “UUID” of from supplier KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

7. Motivating Example (continued) When supplier ID matches with ID actually arriving in current event, get the associated component’s facet Call facet method to fetch data. const BM__ClosedFunctionalFacet& facet = component->ProvideClosedFunctionalFacet(); tempData1 += facet.GetData1(); tempData2 += facet.GetData2(); KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

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 KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

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 component’s id to be set via the .cpf file. interface IDComponent { readonlyattributestring id; }; KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

10. Issue: Event Connections OEP • single event sink port receiving a list of generic events • a single push method that dynamically de-multiplexes. {e1,…, en} CCM • multiple typed event source/sink ports • one “push method” for each sink port T1 T2 T3 KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

11. OEP Event Structure {e1,…, en} 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 KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

12. Event Connections -- Assessment {e1,…, en} OEP • 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 static event type (kind)-checking is problematic KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

13. Event Connections -- Assessment {e1,…, en} {e1,…, en} OEP dynamic de-multiplexing (branching on source_id’s 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 CCM OEP KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

14. Solution [1]: Event Types Mimic OEP Component Event Interface Structure Sequence(GenericEvent) {e1,…, en} OEP CCM …CORBA Sequence type Mimic OEP Generic Event Structure eventtype GenericEvent { readonly attribute integer event_id; readonly attribute string source_id; readonly attribute any payload; }; KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

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) KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

16. Solution [2]: Event Types eventtype DataAvailable { readonlyattribute<any type> 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). KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

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 KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

18. Issue: Timer event subscriptions Device componet • 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. What should the CORBA event type of this event be, and what should we connect to at design level? 20 Hz Timer Event KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

19. Solution [1]: CORBA Timer Service Port names • 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 Timer20Hz CORBA Timer Service Timer10Hz … Timer1Hz KSU CCM Workshop --- Reconciling the Boeing OEP and CCM

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 Venkatesh’s talk on XML issues) KSU CCM Workshop --- Reconciling the Boeing OEP and CCM