Motivation FACE architecture encourages modularity of components on data boundaries Transport Services Segment interface is centered on sending and receiving typed data Naturally fits with ‘dataflow-oriented’ software design

Motivation Much of implementing a FACE architecture is data movement Transport Services Segment data is described by a data model I/O Services Segment can share some transport mechanisms with Transport Services What are some ways we can apply software engineering to make the architecture implementation robust?

Dataflow Abstractions Minimal aspects of a dataflow : Allow configuration of source/destination Support opening/closing Provide capability to read/write Abstract this idea as a class which can be implemented in many ways

Channel Channel class Implemented by specific transport mechanisms Can be used in Transport Services, I/O Services, or within a component

Transport Services Segment Transport Services Segment is intended to be configurable at initialization (change transport mechanisms) Each TSS Connection uses a configured channel Sending/receiving data can be separated from other logic using a Channel At initialization, the correct channels are created based on configuration

I/O Services Segment I/O Services Segment (IOSS) also lends itself to using Channels to handle different data flows I/O Services can be implemented as direct or distributed Direct I/O services are accessed directly via the I/O Services API in the same address space as the component Distributed I/O services are accessed via inter-process communication and allows a service to exist as a process used by multiple components

I/O Services Segment Direct and distributed I/O interfaces can be abstracted as Channels in the implementation Devices can be configured as using direct or distributed I/O without rebuilding the component

Channels I/O Services Segment and Transport Services Segment can use shared channel code for some types of data transport Channels can also be used by components to access the FACE APIs Problem: Accessing the I/O Services Segment requires construction of I/O message headers and bus-specific headers

Refinements Refinement Abstraction Alter the behavior of a channel to provide it with new functionality Example: Delay Refinement causes a channel to wait before performing a read/write

I/O Access Channel Component reads/writes to an IOS Access Channel which uses refinements to prepend the appropriate headers and call the I/O API Simplifies using the IOSS and enables code reuse

TSS Access Channel Similarly, the TSS API can be called via a Channel to further separate business logic from data movement concerns Allows combining TSS data with other dataflow like logic

Another Abstraction Treating dataflows using a generator pattern (source of iterable data) can simplify processing and separate error handling from other logic Error handling is encapsulated in an ErrorStrategy Generator uses a Channel combined with an ErrorStrategy as its data source ErrorStrategy determines message validity and it can be sent on to a data sink if appropriate

Another Abstraction Two ‘generators’ can be combined into a Transformer An input generator is used to get data, the Transformer modifies that data and returns it with next()

Example Use Getting waypoints from the TSS, checking constraints, and sending it to a destination in a Flight Plan Separates business logic (constraint checking), data error handling logic, dataflow to and from TSS

Summary The FACE architecture is data-centric Implementing the architecture and component can be greatly simplified by embracing this Utilizing and configuring FACE architecture is also simplified with the dataflow approach...This does not fit everywhere though!

Thank You Thank you for this event! AMRDEC The Open Group NAVAIR PMA 209 FACE Consortium