About NEO

NEO is an attempt to create a real-time Event Communication Framework (ECF) that is completely integrated within the CCM framework specifically the OpenCCM implementation. The effort will also drive towards creating an interface independent of the event delivery mechanism.

Distributed systems typically involve a large number of interacting components, and developing such systems is a challenging task. We are building Cadena -- an integrated environment for designing and building Corba Component Model (CCM) based systems. More  information about cadena and its related resources can be obtained here. NEO is a subsidiary of CADENA. With NEO we intend to provide an adaptive framework that includes various functionalities like correlation, mode awareness etc.

With CADENA, a component designer can design CCM components and use the facilities to interconnect, analyze and deploy the assembled applications. Such deployment generally requires the use of distributed middleware services to implement application requirements such as event communication and data distribution. To satisfy performance goals, however, a designer is often faced with choosing between a number of possible middleware services or specialized version of the same service. Writing code to deploy the system (glue code to interconnect components via middleware services) and to configure middleware services can be a tedious and an error­prone task. The ECF proposes to address these issues. The framework includes a Corba­based event channel which has been integrated into the OpenCCM infrastructure used by Cadena. The framework also provides a set of alternative light­weight mechanisms to implement the event service functionality. We have evaluated the performance of these mechanisms, and have identified the context in which each one is suitable. The framework enables us to implement algorithms in Cadena to analyze an application to identify the mechanisms best suited for implementing the different event connections, and to automatically synthesize code and metadata to configure the containers to used the appropriate mechanism for each connection.



As proof of concept various experiments have been conducted and a complete picture of the analysis is provided in the paper submitted at RTAS'04. This implementation is specifically suited to fit the OEP scenarios provided by Boeing. Here we present the performance of two such scenarios.

Case Study

[+]ModalSP

   [+]Scenario Description

3.3 Product Scenario 1.3 - Modal SP


The Modal SP scenario alternates between modal steering components: components which change their event-based operation based on the state of the system.


3.3.1 Purpose

The purpose of this scenario is to show simply how the flow of events through the system changes when a component has internal execution modes. Although the event dependencies are defined at initialization time, the run time event flow only exercises portions of the full event dependency tree at any given time.


3.3.2 Requirements

Functionally, the system interactions represent the determination of the steering cues that are shown on the navigation display. The steering can either be a result of a tactical (weapon release) objective or a navigation objective. The pilot can select which steering mode he wants. Navigational steering is fed by navigation steering points, which can be altered by the navigator. Following sections describe specific requirements associated with both inputs and outputs for this product scenario.

3.3.2.1 Input Requirements

The system shall request new inputs from the GPS subsystem at a 40 Hz rate. The system shall poll for a pilot steering mode input at a 1 Hz rate. The system shall receive data from the navigator controls at a 5 Hz rate.


3.3.2.2 Output Requirements

The system shall disable the display of steering information when deselected by the pilot. When the navigation steering mode is selected, the system shall: " Update navigation steering information display outputs at 20Hz rate based on current airframe data and the current list of navigation points that have been submitted by the navigator. The latency between the GPS data inputs and the display output shall be less than a single 20 Hz frame. The latency between navigation point input and the associated output shall be less than a single 5 Hz frame. When the tactical steering mode is selected, the system shall: " Update tactical steering information display outputs whenever the airframe position data changes. The system shall display new aircraft position data at a 20 Hz rate. The latency between associated inputs and this output shall be less than a single 20 Hz frame.


3.3.3.2 Collaborations

The behavior of this scenario is best described in three stages. The GPS wakes up upon a 50ms interval timeout and issues a Data Available event. The AIRFRAME receives that event and issues its own Data Available event. The NAV_STEERING and TACTICAL_STEERING components both receive this event but do not issue events since they are both disabled. The NAV_STEERING component does update its internal state based on NAVIGATOR inputs, but does not issue any events. In the second stage, the PILOT_CONTROL enables the NAV_STEERING. Now when the NAV_STEERING component receives the AIRFRAME's Data Available event it updates its state and issues a Data Available event causing the NAV_DISPLAY to display its updated data. In the third state, the NAV_STEERING component is disabled and the TACTICAL_STEERING component is enabled. The NAV_DISPLAY now runs off of the TACTICAL_STEERING Data Available event.


   [+]Performance figures

[+]MediumSP

   [+]Scenario Description

3.4 Product Scenario 1.4 - Medium SP


The MediumSP scenario shows event dependencies on a larger scale then on previous scenarios. It contains 50+ components that have complex event connections.


3.4.1 Purpose

The purpose of this scenario is to show an intermediate set of event connections and invocation connections for increased complexity but not increased to the scale of a representative scenario (100's - 1000's of component instances).


3.4.2 Requirements

Functionally, the scenario represents steering calculations needed to support various displays on the aircraft. The tactical display shows tracks that have been detected by tactical sensors.

3.4.2.1 Input Requirements

The system shall request new inputs from the TrackSensor1 subsystem at a 20 Hz rate. The system shall request new inputs from the TrackSensor2 subsystem at a 20 Hz rate. The system shall request new inputs from the TrackSensor3 subsystem at a 20 Hz rate. The system shall request new inputs from the TrackSensor4 subsystem at a 20 Hz rate.


3.4.2.2 Output Requirements

The system shall display new tactical steering data at a 20 Hz rate. The latency between associated inputs and this output shall be less than a single 20 Hz frame.


3.3.3.2 Collaborations

The BM__DEVICE_COMPONENTs are triggered at 20 Hz and they all produce Data Available events. When the navigation sensor events are all received by the AIRFRAME component it issues its Data Available event. Its event is received by the NAV_DISPLAY that then updates the display. The AIRFRAME Data Available event is also received by the TACTICALSTEERING component that when it receives other track and sensor events as well, issues its Data Available event. The TACTICAL_DISPLAY components then receive this event and update their displays.


   [+]Performance figures