Seamless Integration of FACE‑Conformant Components with Simulation Environments

A few years ago, the FACE™ Integration Workshop Standing Committee introduced the Basic Avionics Lightweight Source Archetype (BALSA), a reference implementation that showcases Units of Conformance (UoCs) aligned with the FACE Technical Standard. BALSA serves as a practical demonstration for potential FACE software suppliers and integrators, and it functions as an educational tool illustrating how Units of Portability (UoPs), UoCs, and FACE APIs can be implemented on a target platform.

While BALSA includes a basic Transport Services Interface (TSS) that performs satisfactorily, it lacks diagnostic tooling—an essential feature for troubleshooting. We explored replacing BALSA’s TSS with a DDS‑based implementation, specifically RTI Connext DDS (https://www.rti.com/industries/face).

The replacement was surprisingly straightforward—just a few hours to swap BALSA’s TSS for RTI Connext’s. This success confirmed FACE’s portability goal: the new TSS enabled full DDS tooling and seamless connectivity to other DDS‑based components.

During the June 2017 FACE Members’ Meeting (BITS event), five industry leaders—RTI, Honeywell, TES‑SAVi, Wind River, and Mercury Systems—joined forces to cross‑integrate FACE‑aligned components, validating the rapid integration benefits promised by FACE Technical Standard 2.1. Their results are documented in the FACE NAVAIR TIM Paper, “FACE Cross‑Integration Successes – Honeywell, RTI, TES‑SAVi, Wind River and Mercury Systems” (https://www.opengroup.us/face/documents.php?action=show&dcat=70&gdid=18823).

We also integrated the RTI TSS with Harris FliteScene, a high‑performance, combat‑proven digital moving‑map solution that delivers advanced situational awareness for civilian and military crews. FliteScene offers terrain awareness, obstacle avoidance, and 3‑D synthetic vision, and it is already networked with tactical systems such as Link‑16 and ANW2 to provide a real‑time common operating picture.

The integration served as a proof of concept for porting a FACE‑conformant component to RTI TSS. Using the object files and data model supplied by Harris, we followed these steps:

• Generate an IDL from the DataModel header files.
• Use RTI tools to produce DDS‑specific and TSS‑specific code.
• Create the RTI TSS configuration file.
• Link FliteScene object files with the generated RTI TSS and type‑specific code.

The integration proved effortless; within a few days we had a working prototype. FliteScene accepts numerous control messages—zoom, underlay, overlay settings—and positions the map based on real‑time location updates. Multiple data sources can supply position information, enabling flexible map control.

For intuitive control, we built a LabVIEW UI powered by the RTI DDS LabVIEW Toolkit (https://www.rti.com/products/dds/labview). The unified DDS framework allowed the UI, FliteScene, and RTI TSS to interoperate seamlessly.

Seeking to enrich FliteScene’s input, we explored coupling it with a simulation environment. VT MAK, a global authority in modeling and simulation, offers VR‑Exchange—a universal translator that performs protocol transformation and bridging. Its open architecture supports custom brokers for diverse data standards, including DDS.

FACE’s Transport Services Interface is designed to support multiple industry transport standards, notably DDS.

Because both FliteScene and the target simulation use DDS, we tested a direct connection: linking an F‑18 HLA federate to the FACE‑conformant FliteScene component. The integration was straightforward and achieved quickly.

Employing DDS as the TSS transport facilitates not only portability among FACE‑conformant components but also connectivity to any DDS‑enabled application. For FliteScene we used the RTI Connext‑based RTI TSS (https://www.rti.com/industries/face). On the HLA side, the VR_Exchange DDS broker translated HLA data into DDS topics. Because the FACE component’s data model differs from that of the F‑18 federate, we had to map between the two models. Two primary strategies exist:

• Modify the VR‑Exchange DDS broker to publish topics that match the FACE component’s expectations.
• Configure the VR‑Exchange to publish DIS PDU‑based topics and use routing services to bridge between the topics.

For our proof‑of‑concept, we adopted the second strategy. The routing service bridged the simpleBaseEntity topic from the HLA broker to the location topic required by FliteScene. Additionally, coordinate systems differed: HLA supplied geocentric coordinates, while FliteScene required latitude/longitude. We employed a custom transformation library within the routing service to convert between these formats, resulting in the architecture shown below:

To deepen understanding of HLA‑to‑DDS bridging, RTI is collaborating with the National Center for Simulation (NCS) to host a seminar titled “DDS for Simulation: How the Connectivity Framework is Meeting Interoperability Challenges” on April 10. Register for this complimentary event at https://www.simulationinformation.com/news/ncs-real-time-innovations-event-industry-10-apr-2018.