Fog Computing: IT Compute Stacks meet Open Architecture Control Reply

Fog computing is getting more popular and is breaking ground as a concept for deploying the Industrial IoT. Fog computing is defined by the OpenFog Consortium as “a system-level horizontal architecture that distributes resources and services of computing, storage, control and networking anywhere along the continuum from Cloud to Things.” Looking further into the definition, the purpose is to provide low-latency, near-edge data management and compute resources to support autonomy and contextually-aware, intelligent systems.

In particular, fog computing facilitates an open, internet architecture for peer-to-peer, scalable compute systems that supports edge analytics, local monitoring and control systems. It’s this latter application to control that I think is particularly interesting.  Control systems have been in place for decades across multiple industries, and recently some of these industries have moved to create interoperable, open control architectures. In this blog, we’ll take a look at some existing open architecture frameworks that bear a resemblance to Fog and how Fog computing and these framework initiatives could benefit from cross-pollination.

Open Architecture Control

Back in 2004, the Navy started developing its Navy Open Architecture. In an effort to reduce costs and increase speed and flexibility in system procurement, the DoD pushed industry to establish and use open architectures. The purpose was to make it simpler and cheaper to integrate systems by clearly defining the infrastructure software and electronics that “glue” the subsystems or systems together. The Navy selected DDS as their publish-subscribe standard for moving data in real time across their software backplane (Figure 1 below).

Screen Shot 2017-04-11 at 7.57.41 PM

Figure 1. The Navy Open Architecture functional overview. Distribution and adaptation middleware, at the center, is for integrating distributed software applications.

Fast forward to now and we find the OpenFog Consortium’s reference architecture looks very much like a modern, IT-based version of what the Navy put together back in 2004 for open architecture control. Given that this Navy Open Architecture is deployed and running successfully across multiple ships, we can feel confident that fog computing as an architectural pattern makes sense for real-world systems. Also, we can likely benefit from looking at lessons learned in the development and deployment of the Navy’s architecture.

OpenFMB

The Open Field Message Bus (OpenFMB) is a more recent edge intelligence, distributed control framework standard for smart power-grid applications. It is being developed by the SGIP (Smart Grid Interoperability Panel). Energy utilities are looking at ways to create more efficient and resilient electricity delivery systems that take advantage of clean energy and hi-tech solutions.

Instead of large, centralized power plants burning fossil fuels or using nuclear power to drive spinning turbines and generators, Distributed Energy Resources (DERs) have emerged as greener, local (at the edge of the power grid) alternatives that do not have to transmit electricity over long distances. DERs are typically clean energy solutions (solar, wind, hydro, geothermal) that provide for local generation, storage and consumption of electricity. But DERs are intermittent and need to be managed and controlled locally, as opposed to centrally, which is all that is available in the current power grid.

Distributed intelligence and edge control is the solution. The OpenFMB framework is being deployed and proven in smart grid testbeds and field systems. Looking at the OpenFMB architecture (Figure 2 below), you can see the concept of a software integration bus clearly illustrated.

Screen Shot 2017-04-11 at 7.59.02 PM

Figure 2. OpenFMB architecture integrates subsystems and applications through a central, real-time publish-subscribe bus.

Like the Navy Open Architecture, the OpenFMB distributed intelligence architecture looks very much like a fog computing environment. Since OpenFMB is still under development, I would bet that the OpenFog Consortium and OpenFMB project team would benefit by collaborating.

OpenICE

Patient monitoring, particularly in intensive care units and emergency rooms is a challenging process. There can be well over a dozen devices attached to a patient – and none of them interoperate. To integrate the data needed to make intelligent decisions about the welfare and safety of the patient, someone has to read the front-end of each device and do “sensor fusion” in their head or verbally with another person.

OpenICE, the Open Source Integrated Clinical Environment, was created by the healthcare IT community to provide an open architecture framework that supports medical device interoperability and intelligent medical application development. OpenICE (Figure 3 below) provides a central databus to integrate software applications and medical devices.

openICE data flow RTI DDS

Figure 3. The OpenICE distributed compute architecture, with DDS-based databus, facilitates medical device and software application integration.

Again, the OpenICE architecture supports distributed, local monitoring, integration and control and looks very much like a fog architecture.

And now Open Process Automation

More recently, Exxon-Mobil and other process automation customers have gathered via the Open Process Automation Forum to begin defining an open architecture process automation framework. If you look at the various refineries run by Exxon-Mobil, you’ll find distributed control systems from multiple vendors. Each major provider of process automation systems or distributed control systems has its own protocols, management interfaces and application development ecosystems.

In this walled garden environment, integrating a latest and greatest subsystem, sensor or device is much more challenging. Integration costs are higher, device manufacturers have to support multiple protocols, and software application development has to be targeted at each ecosystem. The opportunity for the Open Process Automation Forum is to develop a single, IIoT based architecture that will foster innovation and streamline integration.

Looking at the Exxon-Mobil diagram below, we find, again, an architecture centered around an integration bus, which they call a real-time service bus. The purpose is to provide an open-architecture software application and device integration bus.

Exxon-Mobile Process Automation Architecture

Figure 4. Exxon-Mobil’s vision of an open process automation architecture centered around a real-time service bus.

Again, we see a very similar architecture to what is being developed in the IIoT as fog computing.

The Opportunity

Each of these open architecture initiatives is looking to apply modern, IIoT techniques, technologies and standards to their particular monitoring, analysis and control challenges. The benefits are fostering innovation with an open ecosystem and streamlining integration with an open architecture.

In each case, a central element of the architecture is a software integration bus (in many cases a DDS databus) that acts as the software backplane facilitating distributed control, monitoring and analysis. Each group is also addressing (or needs to address) the other aspects of fog computing like end-to-end security, system management and & provisioning, distributed data management and other aspects of a functional fog computing architecture. They have the opportunity to take advantage of the other capabilities of Industrial IoT beyond control.

We have the opportunity to learn from each effort, cross-pollinate best practices and develop a common architecture that spans multiple industries and application domains. These architectures all seem to have very similar fog computing requirements to me.

We’re heading to Munich! Reply

events-hero-background (1)

London Connext Conference 2014 and 2015 events brought power DDS users together from a wide range of industries to share experiences, applications and expertise. For those of you who were unable to attend but curious about what you missed, head over to Community and view a list of the presenters and some of the presentations (2014 and 2015). For our third year, we wanted to switch things up a bit, and the first big change to the event is the location: we’ll be hosting our two-day event in Munich!

The second change (and the one I’m most excited to announce) relates to our agenda. In the past, we’ve created an agenda that showcases our users and their work through a curated selection of keynote presentations, demonstrations, and smaller group presentations. This year, in addition to these, we’re going to be offering 2 workshops! The first workshop focuses on using Connext Pro Tools and the other will dive into Connext DDS Secure. During these workshops, you’ll have time to get up and running with the products, ask questions and receive answers from RTI staff, and more.

This is just a sampling of what we’ll be offering. To register now, head on over to https://www.rti.com/munich-connext-con-2017. Also, if you’ll be attending and would like to be considered for a keynote spot at this year’s conference, please visit the conference page for submission details. We can’t wait to see you there!

Getting Started with Connext DDS, Part Two: Use Shapes Demo to Learn the Basics of DDS Without Coding Reply

GS_shapes_banner

If you’re building Industrial IoT (IIoT) systems, then you’re probably investigating the Data Distribution Service (DDS) standard. DDS is the only connectivity framework designed specifically for mission-critical IIoT systems.

IIoT applications have extraordinarily demanding requirements in terms of performance, scalability, resilience, autonomy and lifecycle management. To satisfy these requirements, DDS includes unique capabilities—differentiating it from other connectivity frameworks and low-level messaging protocols that were originally designed for consumer IoT and conventional IT applications.

To quickly learn more about DDS and how it is different, there is an easy way: RTI Shapes Demo. Included as part two in the Getting Started series, (see part one herehapes Demo is a game-like, interactive application that lets you explore DDS capabilities without having to do any programming. It is a tool you can use to learn about the basic (and some advanced) DDS concepts, such as publish-subscribe messaging,  real-time Quality of Service (QoS), data-centric communication, automatic discovery, brokerless peer-to-peer messaging, and reliable multicast.

Screen Shot 2017-03-23 at 4.49.24 PM

Screen Shot 2017-03-23 at 4.49.37 PM

There are two ways to get RTI Shapes Demo:

After installing Shapes Demo, watch this simple video tutorial to help you get started quickly.

You can also check out the User’s Manual under the Help menu. Chapter 4 walks you through examples that illustrate many of the DDS standard’s powerful features.

Download RTI Shapes Demo and start learning more about DDS today!