FACE and TPM: The Importance of the Transport Protocol Module

Part 15 of the RTI Military Avionics Blog Series

For decades, government aircraft programs have created single-purpose platforms with a dedicated mission. Platform development teams worked independently of other industry efforts and have enjoyed the freedom to create the most competitive platform that fulfills the program requirements. Often this freedom is inspired by program secrecy. Open standards were not required, due to the focus on a single mission for the platform. Typically one prime and its supply chain were the sole providers of the technology. And in many cases, the program used technologies that were already prototyped in-house. The available time and budget provided by a successful bid for a government program tends to encourage focused effort without concern for enabling other aircraft programs, especially those that were won by competitors.

As a natural result, these focused efforts produced exact outcomes which have inherent prime/supply chain vendor-lock. Further development, maintenance and augmentation was typically only available from the original developer and much of that expertise is guarded closely. In addition, technology advances were slow to be implemented, as they depended on government procurement business practices.

Due to the constant competitive environment of commercial aircraft platforms, the commercial aircraft created a far more agile business environment based on open standards managed by Aeronautical Radio, Incorporated (ARINC), Radio Technical Commission for Aeronautics (RTCA), and more. This open standards environment created a vast supply chain that could service a global aircraft/airline supply chain, and has been built upon commercial-off-the-shelf (COTS) hardware, software, tools, and other elements that drove affordability throughout the entire marketplace.

Recognizing the success of commercial aircraft procurement and facing more agile global adversaries, the U.S. government has adopted a Modular Open Systems Approach (MOSA) that takes advantage of open interfaces based on open commercial and military standards, coupled with accelerated procurement processes, that are created by best-in-class suppliers. MOSA adoption has now created an open marketplace for military avionics, based on reusable and interoperable components that span beyond the physical hardware and software, and include the data definitions.

A flagship implementation of MOSA is provided by The Open Group^® Future Airborne Capability Environment (FACE^™) Technical and Business Approach, which is required of Future Vertical Lift (FVL) and other leading military avionics programs. By using modular hardware and software with open standard interfaces, it is possible to source, develop, substitute, repair, add, and use cost-effective and highly competitive components from different vendors throughout the life of the program. This open competition between FACE suppliers will lower acquisition cost, accelerate schedules, and motivate more competitive implementations, based on the greater agility of commercial suppliers.

The FACE boundary diagram is provided below, with the defined interfaces illustrated by the circular icons between the modular segments.

Figure 1. FACE Architectural Segments

The FACE architecture permits a complex system to be subdivided into standardized functional modules. The applications which create, consume, or transform data and which cause the system to perform effective work – fly, navigate, apply force, evade detection, and so on – are the Units of Conformance (UoCs) within the Portable Components Segment (PCS) and Platform Specific Services Segment (PSSS). They use a common framework to communicate. In addition there can be a free choice of operating system(s), hardware, and networking. The Transport Services Segment (TSS) is provided as a means for the software applications to communicate and is shown to the right of the figure. Because the TSS is itself a FACE segment, there may be multiple TSS designs within a system. Indeed, this approach may be encouraged to reduce dependency on a single vendor or perhaps to de-risk a program.

However, the TSS may use different communication protocols. This will establish differing Transport Service (TS) Domains, which are understood within FACE as distinct UoCs. However it is improbable that those different TS Domains will be able to interwork naturally. Another software module, the Transport Protocol Module (TPM), needs to perform the TS Domain-to-TS Domain interworking.

Transport Protocol Module

In early July 2023, RTI was awarded the Modular Open Systems Approach (MOSA) Risk Reduction Sub Task 1 (Task 3) by Advanced Technology International. Under the authority of this agreement, RTI is evaluating the maturity of the TPM described by Future Airborne Capability Environment, Technical Standard 3.1 and will make recommendations so that TPMs may be portable between vendors.

The following sections describe the background to that activity and frame RTI’s work to accomplish those recommendations.

The FACE Technical Standard provides figures which illustrate how TPMs allow different designs of TSS to communicate data between them. In the figure below, two protocols are used (X and Y) and each protocol establishes an independent TS Domain. The TPM is seen as a function which adapts the external protocol used to carry data between TSS to the data format used within a TSS, so that it may be uniformly presented to the PCS or PSSS application. In practice, all the TS Domains will use the same resilient physical networking infrastructure.

Figure 2. FACE Conceptual Picture of TPM Application

Not every Portable Component application will need to communicate with every other Portable Component, so not every TSS will require every TPM available to the whole system. If a system only used two TSS types to establish two TS Domains, then it may even be imagined that only one TPM type might be necessary, if asymmetry of communication was considered to be acceptable. Nonetheless, the desire to permit the system evolution and adaptability promised by both FACE and MOSA will require that every TSS optionally accommodate every TPM.

A system builder that chooses to use two or more TS Domains by using TSS from different vendors will require the vendors to exchange TPM implementations. Vendor A will need to integrate a TPM from Vendor B, and vice versa. For each additional TSS vendor, additional exchanges of TPMs will be required for those TSS hosting applications that need to exchange data. So, each TSS may contain as many TPMs as there are TSS designs in the overall system and should allow for the integration of further TPMs.

With multiple TPMs each providing connectivity to a different set of applications (PCS or PSSS), some form of routing logic is preferable within the TSS so that each data element is sent to the appropriate TS Domain, or else the TSS must broadcast all data to every TS Domain so that every application has the opportunity of receiving it. That latter case is less desirable, as each TS Domain will require its own copy of the data being exchanged and the bandwidth required of the network supporting the TS Domains will multiply.

A further difficulty arises. The TPM must contain the FACE-functional parts of the protocol stack, as well as the logic to administer it. This must be more than just the encapsulation/serialization parts of the protocol, because the TSS must implement some data integrity aspects of the communication including, for example, error correction for a reliable data path. That requires buffer management, retransmission logic, recovery mechanisms, and more. It is therefore preferable that each TPM implements all of the protocols used, rather than attempt a protocol adapter or translator function that would be prohibitive to maintain.

In practice, each TPM will contain a great deal of software, and the need to support multiple TPMs causes the TSS to now also contain a routing mechanism. The figure below modifies the earlier figure to show the necessary elements and attempts to scale them according to complexity.

Figure 3. Implied TPM Application

TPM Challenges

The reader will see that a TSS that must accommodate multiple TPMs – and provide some mechanism to choose which TPM to pass data through so that it reaches the correct end-point – is significantly more complex than the homogeneous TSS available today. That complexity will affect the scope of the safety artifacts necessary for system safety certification.  Even though the TPM will initially appear as the panacea for all the remaining inter-working issues in a complex airframe, an informed system architect will be motivated to reduce the number of TS Domains.

This blog anticipates the case when all TSS communicate with each other directly, either over a common negotiated framework based on Data Distribution Service (DDS^™) (perhaps over a TSN-enabled Layer-2 network) or by some other mechanism. It is possible to imagine that some endpoints may communicate through a chain of different TS Domains. In those circumstances, the complexity of the TPM and the necessity to translate and route each message will multiply the transit latencies. This too will encourage system engineers and architects to flatten the overall system by minimizing the number of TS Domains, thus TPMs, and hence reduce the necessity for translators, relays, and routing functions.

Working with Multiple FACE TSS and TPM designs

A system with multiple TS Domains will have multiple protocols being used to move data even if they all share the same physical network(s) and bandwidth assignments. It can be imagined that development and engineering difficulties will arise.
RTI’s own Connext^® TSS is based on the open DDS standard. RTI is entirely focused on the use of DDS in this and our other mission-critical and safety-critical military and commercial systems to solve challenging distributed system problems.

RTI: TSS and TPM Leadership

RTI is the global leader in FACE TSS technologies. We obtained the first FACE TSS conformance in December 2018, and we continue this leadership today with recent FACE 3.1 TSS conformance for leading OS and safety RTOS platforms. We also have now completed RTCA DO-178C DAL A certification evidence for Connext TSS.  Furthermore, Connext TSS has eight unique features that no other certified FACE conformant TSS provides:

1. Connext TSS 3.1 is the first and only FACE TSS 3.1 certified FACE conformant TSS
2. Connext TSS 3.1 has commercial RTCA DO-178C DAL A certification evidence available now on a wide range of operating systems and processors
3. Connext TSS 3.1 supports both FACE Operating System Segment (OSS) Safety Base and General-Purpose Profiles.
4. Connext TSS 3.1 has supports for all leading safety RTOSs, including DDC-I  Deos^™, Green Hills Integrity-178, Lynx Software Lynx-178, QNX, Wind River VxWorks^® , Wind River VxWorks 653, and Wind River Helix Virtualization Platform
5. Connext TSS 3.1 also supports Linux platforms and has certified FACE conformance for Red Hat^®  Enterprise Linux^®  Release 8.5.
6. Connect TSS 3.1 supports all processor families including Arm, Intel, and Power platforms.
7. Connext TSS 3.1 is open standards-based from top to bottom, aligning precisely with MOSA initiatives:
   1. At the top, the application layer (FACE PCS) and The FACE TSS API are managed by The Open Group^®  FACE^™ Consortium
   2. At the middle connectivity foundation layer, the marshaling and presentation of data to the FACE TSS and FACE applications is managed by the Object Management Group^® (OMG^® ) open DDS standard
   3. On the wire, the delivery of data on the network is managed by the OMG open Real-Time Publish-Subscribe (RTPS) wire protocol, enabling rapid interoperability
8. Connext TSS is supported by a wide range of software tools, RTOS, processor, and board partners.

The immediate future for the FACE TSS is the adoption of the optional FACE TSS TPM capabilities. RTI is proud to be the leader of the U.S. Army MOSA Risk Reduction Sub Task 1 for refining TPM capabilities. RTI will work with other program partners to advance the maturity of the FACE TPM standard to increase TPM adoption and enable an open standards-based foundation for TPM interoperability for the entire FACE community to enjoy.

Conclusion

Transport Protocol Modules will permit the inclusion and substitution of multiple TS Domains in a system. Some work is required to better define and implement a TPM and the necessary complexity of a TPM and the TSS host. This will influence the architecture of the overall system, particularly in regard to safety-critical aspects of those systems. There will be rapidly increasing system test and validation necessary as the number of TS Domains increases, but these may be contained provided that the rigor of using FACE conformant TPMs is maintained.

A well-specified and functionally complete definition and conformance test for all TPMs used will deliver the benefits of MOSA to those complex FACE systems. RTI is committed to meeting that objective, so that those FACE systems continue to deliver the advantages envisioned by this industry-leading MOSA open standard.

RTI looks forward to working with other FACE software suppliers working on ATI’s Modular Open Systems Approach (MOSA) Risk Reduction program to advance, refine, and mature FACE TPM capabilities to create rapidly interoperable and deployable solutions to accelerate the delivery of advanced avionics to our global customers.

To learn more about MOSA, please download the MOSA whitepaper.

To read other installments in the RTI Military Avionics Blog Series, please click here.

About the Author

Frank Gates is RTI's Field Application Engineer for south-central states. He has a 36-year career in mission-critical embedded systems, the last 13 in Aerospace and Defense.