Dataflow Oriented SoftwareDesign in a FACE™
ArchitectureDavid Heath and Trevor Stittleburg
Georgia Tech Research Institute
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