Time to Sync Up on Consistency in IIoT Systems

An important (and hotly debated) topic in distributed system design is which consistency model to use. Consistency models influence many parts of system design, and picking one over the other impacts things like system availability and robustness against network failures. This blog is meant for system architects that want to get a better handle on what it means to be or not to be consistent.

Read More

Benchmarking Connext DDS vs. Open Source DDS

I am part of the RTI services team and we frequently help our users with optimizing performance. To see how we stack up, I recently benchmarked RTI Connext DDS against two open source DDS implementations. You would expect that comparing one DDS implementation with another is easy, but from the length of this blog you can probably guess that this was not the case. To help users navigate some of the common pitfalls when comparing DDS implementations, I decided to write them down in a blog. However, this topic is pretty broad so I’ve focused this blog on latency.

Read More

When is Open Source the Right Solution?

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.

Read More

Can DDS Help Solve the Distributed Simulation Integration Challenge?

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.

Read More

Implementing Simple Introspection with Connext DDS in C++14

When I was first introduced to RTI Connext® DDS, it wasn't very long (after seeing the powerful tools) before I wanted to know how difficult it would be to implement domain introspection in its most basic form. Obviously tools, such as the Admin Console, are complex but that doesn’t mean that the basic principle on which they’re based – domain introspection – has to be. So I set about trying my hand at creating the simplest example of domain introspection that would have some demonstrable utility. This blog post covers my journey into this effort.

Read More

Using a Data-Centric Approach to Building Healthcare IIoT Solutions     

An interview with the CEO of DocBox, Tracy Rausch

During the RTI Connext Conference in San Jose, CA, I had the opportunity to talk with the CEO of DocBox, Tracy Rausch. For the the past 10 years, DocBox’s mission has been to drive efficiency in healthcare through the democratization of data. Their combination of hardware, software and analytics aims to arm healthcare providers with more actionable information than ever before. The goal is to provide a platform with similar capabilities to SMART on FHIR – an open application programming interface that allows developers to create apps (and clinicians to select apps) that work with their EHR system, regardless of vendor for mission critical, real-time data.

Read More