2024 NDIA MICHIGAN CHAPTER
GROUND VEHICLE SYSTEMS ENGINEERING
AND TECHNOLOGY SYMPOSIUM
MOSA TECHNICAL SESSION
AUGUST 13-15, 2024 - NOVI, MICHIGAN
Enabling Multi-Vendor Model Based Application Development Using
the FACETM Technical Standard
Mark Snyder1, Mark McBroom2 Kirsten McCane3
1L3Harris,
Palm Bay, FL
2The
MathWorks, Novi, MI
3The MathWorks, Washington, DC
ABSTRACT
This paper discusses how a software development approach based on the
Future Airborne Capability Environment (FACE) standard and COTS model-based
development tools can enable modular and open software applications to be
rapidly developed and deployed in a manner strongly aligned with the Army’s
Ground Combat Infrastructure Architecture (GCIA) objectives. We describe the
use of multiple model-based tools for data architecture, software generation, and
system architecture, and describe how these tools have evolved to better support
open standards. It then describes the methodology used to integrate Simulink with
multiple FACE Transport Services Segment (TSS) implementations. The paper
discusses the tools and techniques used, the software components involved, and the
testing and validation process.
Citation: Snyder, M, McBroom, M., McCane, K “Enabling Multi-Vendor Model Based Application Development
Using the FACETM Technical Standard,” In Proceedings of the Ground Vehicle Systems Engineering and Technology
Symposium (GVSETS), NDIA, Novi, MI, Aug. 13-15, 2024.
1. INTRODUCTION (OSS) segment, which defines standardized
subsets of open standard operating system
The FACE™ Technical Standard [1] was APIs, and includes the Platform Specific
created to promote the development of Services Segment (PSSS) and IO Specific
portable software applications. It defines a set Services Segment (IOSS) that together define
of architectural segments that can be used to standardized means to access hardware
define a common operating environment that resources. The Transport Services Segment
supports software portability and reuse across (TSS) provides a standardized method for
different embedded systems. The standard applications to access data interfaces in
includes the Operating Systems Services software programming languages. The
Universal Domain Description Language
DISTRIBUTION A. Approved for public release; (UDDL) standard [2] standard provides the
distribution unlimited.
Proceedings of the 2024 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS)
means to define data exchanges that can be 1.1. FACE Tool Ecosystems
tied to software UoPs (Units of Portability)
within the system that use the TSS to Many commercial tools exist that support
communicate (Figure 1). As the FACE the FACE standard and MOSA development
technical standard continues to mature, its using FACE. For instance, to develop model-
adoption can be assisted by tools that enable based UoPs, MathWorks tools are a good
users to implement the standard in their choice. MathWorks joined the FACE
engineering workflows more easily. Consortium and is maturing its support for
Figure 1: FACE Canonical Reference Architecture.
integrating FACE-aligned software
FACE is a widely adopted, consensus- components with other avionics systems
based standard that has evolved over several starting with Simulink. Simulink is a tool
years through the Open Group Consortium. used in a variety of industries, including
Government, industry, software, and tool aerospace, to develop and test complex
vendors all attend and contribute to the systems. It is a model-based software tool
standard and offer products that aid adoption. developed by MathWorks that is commonly
used for modeling, simulating, and analyzing
dynamic systems. For example, Simulink can
Enabling Multi-Vendor Model Based Application Development Using the FACETM Technical…, Snyder, et al.
Page 2 of 10
Proceedings of the 2024 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS)
be used to model and simulate the behavior coupled, have well-defined interfaces,
and interactions between a set of FACE - minimize integration complexity, and
aligned software components representing promote reuse. MOSA starts with a strong
platform functions such as avionics systems, architectural foundation that is grounded in
fire control systems, vehicle electronics digital engineering principles. Within the
systems, and other functions which use or architecture, capabilities become
control these. Given its industry use and components with well-defined interfaces,
capabilities, MathWorks and its family of behaviors and known dependencies.
products are in a great position to help users Deployment is standardized onto common
more easily develop and implement FACE - frameworks, minimizing investment in
aligned software applications. infrastructure by allowing reuse. The
connectivity from architecture through
Other tools are used to support FACE components is well defined by interfaces and
application development that are also Open Standards such as FACE, and further
presented in this paper. Operator HMI defined for a domain of interest by objective
development tools, middleware and TSS architectures such as GCIA.
tools, and simulation tools are also discussed
in this paper. The FACE Technical Standard promotes a
modular and model-based design approach
2. MOSA Digital Thread that fits within the MOSA digital thread that
is designed to minimize complexity,
Modular Open Systems Architecture in encourage reuse, and improve system
practice is concerned with producing integration. The FACE and UDDL standards
capabilities that are modular, loosely define a model-based interface definition
Figure 2: MOSA Development Lifecycle.
Enabling Multi-Vendor Model Based Application Development Using the FACETM Technical…, Snyder, et al.
Page 3 of 10
Proceedings of the 2024 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS)
approach with standardized means of flow, and early identification of issues in
translating interfaces to software. By design or code. Within this environment,
breaking complex systems into smaller Simulink provides a variety of integration
modules and utilizing a model-based design techniques, enabling engineers to connect
approach and these standard interfaces, and exchange data between components
FACE Conformant applications can operate effectively. Additionally, it provides a high
more effectively together, promoting level of abstraction to effectively manage the
interoperability and modularity, and complexity of the software.
improving system performance.
Simulink also provides a range of modeling
Architectural patterns such as Service- abstractions that help enhance your algorithm
oriented architecture (SOA) are enabled by model to be suitable for mapping to run-time
the FACE approach, which promotes loose scheduling and communications that may be
coupling between software components by provided by integration frameworks and
encapsulating functionality and exposing it SOAs. Table 1 shows constructs within
through standardized interfaces. The FACE Simulink that promote modularity.
TSS can provide capabilities such as
publish/subscribe and Quality of Service
(QoS). In this way, system data needs such 3. MOSA Software Deployment and
as data persistence, data reliability, data Integration
security, and advanced interoperability can
be implemented, and architectural patterns Deployment in a MOSA environment often
like SOA can be realized. This aligned well involves the use of a software framework
with the Data Architecture and Data Sharing approach. In embedded systems, model
Infrastructure concepts found in the GCIA. content is often transformed into embedded
The FACE TSS can also be easily integrated components such as code or run-time
with existing open standards such as configuration. For instance, code generation
VICTORY [3]. may be used to populate software interfaces
or middleware data serialization
2.1. Model Based Software and FACE implementations, or to render algorithmic
descriptions to embedded code. Code
The FACE and MOSA approach aligns well generation from models, facilitated by tools
with the model-based design process that is like Simulink and Embedded Coder from
supported by tools such as Simulink. Using MathWorks, can play a significant role in
these tools, the system design provides implementing the FACE™ Technical
traceability, visualization of algorithm/ logic Standard. It enables engineers to translate
Table 1. Simulink Modularity Constructs
Area Benefit
Model Frameworks Ability to partition a design for real-time scheduling
and styles
Data Busses Capture interfaces in terms of their data structure
Simulink Model software services and provide points for integration of code
Functional blocks
State modeling Model application state and provide test frameworks
Messages and Ability to tie to middleware or TSS
interface blocks
Enabling Multi-Vendor Model Based Application Development Using the FACETM Technical…, Snyder, et al.
Page 4 of 10
Proceedings of the 2024 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS)
design models into executable code adhering application may use. The FACE
to standards. TSS toolchains also offer code Conformance Test Suite (CTS) is leveraged
generation for the FACE standard TSS to assess the software’s conformance to that
interfaces and TSS capabilities that provide profile. the FACE™ Technical Standard
data transport. provides standardized programming
language guidance for languages such as
Ada, C, and C++ that can enable easier
3.1. Software Tooling and Modularity verification of safety objectives. As with
other model-based software advantages
Once a software application has been listed, software environments such as
designed in a model-based, modular manner, MathWorks can help meet safety objectives
Model based tooling environments such as for software. Model-based design,
Simulink can be also structured to provide verification/validation (V&V), certification
end users with flexibility on how they may artifact generation, compliance reporting,
want to configure and deploy their software and embedded code generation with safety
applications. For developers creating FACE- features such as redundancy and fault
aligned software components, an architecture tolerance are some features that can help.
and design consideration is how they may
break up or aggregate their application and 4. MOSA Model Based Example
combine or distribute UoPs as necessary to
meet system needs. The Simulink To illustrate the advantages of a MOSA
environment allows for components within a model-based software approach involving
model to be generated as individual multiple vendors using open standards, a
executables or to be combined with other demonstration application was constructed.
components to generate one executable. In In this demonstration, a component of a
distributed embedded environments, where ground vehicle (an EOIR sight system) was
an optimal configuration of which developed and integrated by a cross-industry
components are deployed as UoPs can vary, team consisting of 5 different vendors. Each
this can be an essential feature for a vendor made use of the FACE technical
development environment. standard and model-based approaches.
3.2. Model Based Software and Safety 4.1. System Architecture
Model Based tools and a MOSA approach The system architecture for the
can promote software safety and higher demonstration was oriented around the
levels of Verification and Validation, which definition of several components with well-
can help to reduce the risk of accidents or defined interfaces defined in a FACE/UDDL
incidents caused by software errors. By data architecture model. The components
modularizing the system and adhering to were all pre-existing, and had some level of
standards such as FACE, system capabilities interface definition using the FACE standard
can identify their usage of Operating System already defined. Some additional
Segment (OSS) profiles that can identify architecture and modeling work was
intended deployment scenarios. The FACE conducted to form the system into an
OSS Safety Base profile provides a means for architecture that illustrated a MOSA system
software to limit its OS footprint to ARINC that illustrates aspects of the GCIA such as
653, while the FACE Safety Extended profile usage of FACE TSS, well-defined data
offers more multi-threaded features an modeled interfaces on portable components,
Enabling Multi-Vendor Model Based Application Development Using the FACETM Technical…, Snyder, et al.
Page 5 of 10
Proceedings of the 2024 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS)
Figure 3: MOSA Demonstration Architecture FACE and SysML Model Views
a software portability and modularity used to assess conformance and to generate
framework, and data distribution patterns interface definitions from the models. Each
such as publish/subscribe. component of the demonstration was
developed by a separate team using the
An example model illustrating the data standard, and integration was only performed
interfaces and Units of Portability (UoPs) at the end in order to assess the results.
along with an underlying UDDL domain
model for the sensor system is shown in 4.2. EOIR Controller Component
Figure 3. Data modeling for each interface
was conformant to the FACE technical To demonstrate support for the FACE
standard, and FACE Consortium tools were standard MOSA approach, Simulink was
Figure 5: FACE TSS Interfaces in Simulink Model
Figure 4: FACE driven workflow for EOIR Camera Controller Module
Enabling Multi-Vendor Model Based Application Development Using the FACETM Technical…, Snyder, et al.
Page 6 of 10
Proceedings of the 2024 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS)
selected to develop the camera controller One key module was the Situational
UoP using the workflow in figure 4. Awareness UoP, based on the L3Harris
FliteSceneTM Digital Moving Map UoP.
In steps 1 and 2, the model’s data dictionary FliteScene is a FACE conformant map
was defined. Using model-based application that includes support for all
transformations from the FACE model, IDL common mission database types, as well as
was generated, which Simulink can import. the ability to display tactical symbology,
This IDL becomes viewable as a data routes, sensor coverages, mission plans,
dictionary in Simulink, which can be used as terrain, and many more features.
FACE TSS interfaces to modules in the
model (Figure 5).
In steps 3 and 4,, the EOIR interface and
internal components were created as
Simulink model elements. The Simulink
model contains both a closed loop control of
camera position and a model of the 2-axis
camera gimbal, allowing for closed loop
simulation and testing in Simulink prior to Figure 6: Demo Operator HMI
code generation.
The HMI graphical elements were created
in a model-based tool environment (Protos
UP) that allows graphical assets to be created
and imported, and dynamic animations
applied. Similar to Simulink, data interfaces
to the elements and to state-machine logic for
the HMI were designed to interface with data
Figure 5: Camera Control Model Elements
interfaces from the FACE model, and the
code-behind logic was developed as FACE
In step 5 and 6, Simulink’s FACE and UoPs with TSS interfaces for all data. (Figure
embedded code generation facilities were 7)
used to generate the UoP implementation
with FACE APIs, including the TSS
Injectable Interface and Lifecycle
Management (LCM) APIs. The resultant
UoP is now ready for integration.
4.3. Crew HMI Component
The Crew HMI component allows an
operator to control the EOIR system as part
of a mission. The HMI itself consisted of
several UoP components deployed to a crew
HMI framework based on FACE graphics
services and FACE TSS interfaces. Each Figure 7: Model-Based Crew HMI Development
HMI module was independently developed.
Enabling Multi-Vendor Model Based Application Development Using the FACETM Technical…, Snyder, et al.
Page 7 of 10
Proceedings of the 2024 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS)
5. MOSA Integration components used to bridge between
middleware solutions.
After the components were developed by
the various teams, integration was performed. For the Crew HMI, the software application
For the demonstration, integration was done was deployed to an embedded target system
using two separate FACE TSS using FACE graphics services and a FACE
implementations to show modularity. One OSS. The HMI software itself used Vulkan
TSS implementation was from Real-Time- and OpenGL SC as interfaces to the GPU for
Innovations (RTI) that used OMG Data rendering and video conversion. All software
Distribution Standard (DDS) as the used for the crew HMI is fully aligned to the
underlying transport. The Data Distribution FACE standard, and several components of it
Service (DDS) is an OMG standard for real- have already passed FACE conformance.
time publish/subscribe middleware that is
widely used in many domains including
avionics, mission systems, automotive and 5.1. MOSA Simulation and Validation
industrial applications. DDS data types are
defined in a standardized Interface Definition Conformance of the MOSA components
Language (IDL) that prescribes data types in and interfaces was done at multiple stages of
a programming language-independent development. Part of the demonstration
manner. These data types are typically sent or objectives for this effort included utilizing
received from topics, which represent publish the FACE CTS to assess the generated
or subscribe connections through the DDS MathWorks UoPs and EOIR Data Model.
distributed data bus. Simulink and RTI DDS One feature of the L3Harris Cameo FACE
have a history of supporting ground vehicles, tool environment is continuous validation of
automotive applications, and associated the FACE model during editing. The FACE
weapons system, so this support was CTS Data Model Validation Tool (DMVT)
relatively well-developed. and IDL generation tool were used in this
stage to assess the data model, with no
For the second TSS, an L3Harris developed reported issues found.
implementation based on open-source non-
DDS message middleware was used. This To assess the performance of the generated
implementation made use of socket- UoP components, the team implemented a
management libraries that create data demonstration system employing the TSS
distribution patterns between endpoints, and implementations and observed the
was in use on much of the existing simulation performance of the generated models within
integration infrastructure described in the a simulated environment. To assess the
next section. correctness of the generated TSS and UoP
software components, the team used TSS
Both the EOIR and the HMI UoPs were data capture tools to monitor TSS
used in the demonstration integrated with connections and log data messages. These
both TSS implementations at various times were used to examine messages from the
and for various purposes. The UoPs interface in various system states.
themselves are agnostic to which TSS is
supplying the data distribution functions. In For system-level validation and mission
some cases, the TSS implementations were effectiveness assessment, the demonstration
used together, with interoperability components were deployed in a MOSA
Mission Simulation Integration (MSI)
Enabling Multi-Vendor Model Based Application Development Using the FACETM Technical…, Snyder, et al.
Page 8 of 10
Proceedings of the 2024 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS)
environment assembled by L3Harris and the ground vehicle and its mission, such as
employing other third-party components that turret/fire control, EOIR payload control, and
also align to FACE. MOSA high-fidelity terrain were used. The EOIR
Live/Virtual/Constructive simulation was payload controller UoP was integrated into
done using an environment called FLAMES as an equipment controller model
FLAMESTM from TernionTM. FLAMES for the EOIR sensor. All communications
supports the use of composable elements in into and out of the LVC simulation
simulation models that closely reflect the environment to other components used only
way actual systems are created and fielded. FACE messaging over the TSS. Other
Simulation actors are constructed from Distributed Simulation Protocols such as DIS
platforms, sensors, effectors, data processors, or HLA were not used. This approach
and AI logic mirroring human decision ensured fidelity and proper interface
processes. All levels of the simulation can validation for the UoPs that were being
have custom models implemented at various demonstrated and validated.
levels of fidelity. In addition, any required
interface can be used with custom models, The MSI integrates high fidelity terrain,
FACE TSS in our case integrated into ground vehicle movement, and sensor
FLAMES as custom data processor models simulation through the use of Unreal Engine
mirroring actors on the In-Vehicle-Network. as a component of the simulation
environment. An embedded streaming video
For the MSI, a highly modular LVC actor simulating the sight was used to create
simulation model of a ground vehicle was a low-latency networked video stream that
used. FLAMES supports the concept of was displayed by a video display UoP within
variable fidelity, and, for this demonstration, the Crew HMI. This Modular MSI approach
high-fidelity representations of elements of is shown in Figure 8.
Figure 8: MOSA Mission Systems Integration for Ground Vehicles
Enabling Multi-Vendor Model Based Application Development Using the FACETM Technical…, Snyder, et al.
Page 9 of 10
Proceedings of the 2024 Ground Vehicle Systems Engineering and Technology Symposium (GVSETS)
[2] Open Universal Domain Description
6. Conclusion Language (C198), published by The Open
Group, July 2019; refer to:
This paper has described the use of the www.opengroup.org/library/c198
FACE technical standard and model-based
engineering, from architecture through to
[3] Snyder, M, Allport, C, “Using FACE TM
component development, coding, integration
Technical Standard Features to Address
and validation, in a multi-vendor
Interoperability Between Ground Vehicle
demonstration highlighting the power and
Domain Open Standards,” In Proceedings
effectiveness of MOSA when applied to all
of the Ground Vehicle Systems
levels of the lifecycle.
Engineering and Technology Symposium
(GVSETS), NDIA, Novi, MI, Aug, 2023
A system model and FACE data model of
the system’s key interfaces was constructed
and used as part of an architecture based on [4] Elliott, L., Jenkins, S., Moore, M., and
the FACE standard and reflecting the goals of Yee, Howell, “Potential for VICTORY
the GCIA. Components of the demonstration and FACE Alignment – Initial
were independently developed, verified, and Exploration of Data Interoperability and
used model-based methods to ensure rapid Standards Compliance”, proceedings of
development and adherence to standards. the Vehicle Electronics and Architecture
Integration, verification, and mission (VEA) and Ground Systems Cyber
effectiveness was assessed, all within a Engineering (GSCE) Technical Session,
MOSA simulation environment based on 2019 NDIA Ground Vehicle Systems
Open Standards. The overall solution Engineering and Technology Symposium,
illustrates several aspects of the MOSA August 2019
digital thread, and served as a good
environment to investigate concepts of the
GCIA ground vehicle architecture.
7. REFERENCES
[1] FACE™ Technical Standard, Edition 3.1
(C207), published by The Open Group,
July 2020; refer to:
www.opengroup.org/library/c207
Enabling Multi-Vendor Model Based Application Development Using the FACETM Technical…, Snyder, et al.
Page 10 of 10
