One of the most important challenges that system designers and system integrators face when deploying complex Industrial Internet of Things (IoT) systems is the integration of different connectivity solutions and standards.
With California weather getting warmer, I've been working on my beach body. I'm ok without washboard abs, but I wouldn’t mind trimming down the love handles. My shoulders are a bit strained, so a little physical therapy might be necessary as I crank up the effort.
It all started a few years ago when the Future Airborne Capability Environment (FACE™) Integration Workshop Standing Committee released the Basic Avionics Lightweight Source Archetype (BALSA) example of a FACE Reference Implementation Architecture. BALSA is a software application containing Units of Conformance (UoCs) aligned to the FACE Technical Standard. Its purpose is to provide a working example to potential FACE Software Suppliers and FACE Software Integrators. It is also used as a teaching mechanism of how Units of Portability (UoPs), UoCs and FACE Application Programming Interfaces (APIs) can be realized on a potential system.
As an RTI product developer working out of our Spain Office, my main focus is the design and implementation of our Connext DDS Secure product. With that said, I still interact with customers almost on a daily basis, especially our customers based in EMEA. But most of these interactions take place digitally (e.g., e-mail and phone calls), and through our (btw, fantastic) support and services teams. As such, I don’t usually have the opportunity to meet the customers I work with “behind the scenes” in person.
The Object Management Group (OMG) Data Distribution Service (DDS) standard is what is called an "open standard." This means that the standard is publicly available and provides a normative reference to help guarantee consistency, portability and interoperability. An open standard is not the same thing as software that is "open source." Open source software is computer software made available with its source code. Open source software may be shared and modified and distributed, usually under an open source license. The DDS Standard is an open standard and has open source implementations available. For example, OpenDDS is an open source implementation of DDS managed by OCI (Object Computing Inc.). There are many commercial distributions that are available as well, the most popular being RTI's Connext® DDS.
Training warfighters to the point that their reaction time and skills become muscle memory, reflexive and honed happens through consistent repetition. Effective training requires a system that provides true, high-fidelity simulations with response times closely matched to real-world scenarios. Truest fidelity is found by using the same technology that is used in systems deployed in the real world. After all, you do not get more realistic training than training with actual real-world systems. But what if you are trying to simulate a real-world scenario with several distributed components, each with its own set of disparate technologies?
Historically, most distributed simulations have been homogeneous. Integrators have typically put together simulation exercises where everyone uses the common wire-protocol found in Distributed Interactive Simulation (DIS) or a particular Run-Time Interface (RTI) for High Level Architecture (HLA). The Simulation would either need to agree on the Protocol Data Units (PDU) for DIS or the RTI and the Federation Object Model for HLA. In those cases where both DIS and different HLA RTI Federations needed to coexist for a simulation, a DIS/HLA Gateway was used. Simulations that involved using different HLA RTI implementations, or needed to have interaction with real-world systems that run over Data Distribution Service (DDS), or needed to use more protocols than just HLA and DIS, have been rare.
That is about to change. Both the Army and the Air Force are now in early procurements for all encompassing systems that will integrate multiple distributed simulations. The Army is currently evaluating first round demonstrations for a new system that will, "...provide a cognitive, collective, multi-echelon training and mission rehearsal capability for the Operational, Institutional and Self-Development training domains. To converge the virtual, constructive and gaming training environments into a single Synthetic Training Environment (STE) for Active and Reserve Components as well as civilians..." Similar to the Army's STE, the Air Force has a new initiative called the Simulator Common Architecture Requirements and Standards (SCARS). SCARS describes a desire for a common open architecture to facilitate rapid development and avoid the pitfalls of being ‘locked’ into the use of proprietary technology. SCARS plans on being able to integrate over 40 different simulators into one common architecture.
As Live, Virtual, Constructive simulation technologies, C4ISR components, and operational combat systems all merge into the same technology base, training and simulation system integrators are now faced with requirements for bridging multiple technologies into one seamless solution. Adding to that already arduous task, these integrators also have enhanced cybersecurity requirements. Figure 1 shows an example architecture of how systems can integrate today using the DDS Layered Databus Architecture Pattern with gateways to gain security.