Announcing the First Connectivity Software for Architecting IIoT Systems of Systems

In Episode 11 of The Connext Podcast:

• [1:37] Drivers for Connext DDS 5.3 - What characterizes IIoT Systems
• [3:20] How do we solve the problem of reliable messaging with Connext DDS?
• [5:08] Looking at the Layered-Databus Architecture (or Systems of Systems) in IIoT Systems
• [6:27] Applying the Layered-Databus Architecture to Autonomous Vehicles
• [10:35] What is new in Connext DDS 5.3?!
• [11:47] Interoperable Security
• [15:36] Historical Data Query
• [19:34] Seamless Device Mobility
• [23:50] Web Application Interoperability

Related Content:

• [Blog] Connext DDS 5.3 Is Now Available to Help You Architect Your IIoT Systems
• [Getting Started] 5.3 Installation Videos for Linux and PC
• [Download] Get started with your free trial of the first connectivity software designed for architecting IIoT systems of systems.

Podcast Transcription:

Lacey Trebaol: Hi, everyone, welcome to episode 11 of The Connext Podcast. I'm Lacey Trebaol, and today, I'm really excited to share something with you. We're announcing the launch of our new product, Connext DDS 5.3. Today's interview is all about Connext DDS 5.3, it's hosted by my co-host Niheer Patel, and he is interviewing David Barnett, the VP of RTI's Products and Markets Team.

If you're a system architect, or software architect, a system integrator, if you're developing systems and applications for the IIoT, or the IoT, then this episode is a must listen. I hope you enjoy it.

Niheer Patel: Hello, everyone, and welcome to a special episode of the Connext Podcast. I am Niheer Patel, and today I am going to be talking with David Barnett, our Vice-President of Products and Markets here at RTI. We're going to be talking about the latest release of Connext, Connext DDS 5.3. David, this is really an incredible time, really exciting, thanks for joining me today.

David Barnett: Thank you very much for having me.

Niheer Patel: What we'd like to do is actually start out by talking about a little bit of context in terms of what's happening in the industry. Set up some industry examples and then go into the new features that are being announced with Connext DDS 5.3.

David, the announcement headline is RTI announces first connectivity software designed for architecting IIoT systems of systems. Why the need to differentiate between IIoT and IoT?

[1:37] Drivers for Connext DDS 5.3 - What characterizes IIoT Systems

David Barnett: Sure. I think there are some pretty significant differences between industrial internet systems and traditional consumer IoT systems, or maybe even early implementations of IIoT systems. In particular, the type of applications that RTI is focused on are those that are really mission critical IIoT applications, which are applications that really have some element of autonomous behavior, meaning they make local decisions at faster than human speed, and there are things that can run without human intervention.

If you think about early IoT systems, the focus was really on just connecting devices to the internet to applications running in the cloud. But, when you think about mission critical and autonomous IIoT systems, it's really not possible to put all of that intelligence in the cloud.

That intelligence has to be much close to the edge both for performance reasons, because these are systems that often have to respond in microseconds, or milliseconds, so it's not feasible to send the data to the cloud. They have to be very highly reliable, so you can't really depend on having a wireless or cellular connection back to the cloud. The total volumes of data that is produced in these systems, which can be millions of data updates a second, would just overwhelm whatever connectivity have back to the cloud.

Really, for those reasons of performance, reliability, resilience, and scalability, intelligence at these systems needs to be much closer to the edge, which is often today called in the fog, or fog computing.

[3:20] How do we solve the problem of reliable messaging with Connext DDS?

Niheer Patel: Okay. We're bringing the intelligence, a lot of the data processing, from remote cloud servers down into the actual control systems, these industrial control systems, or defense control systems, whatever they may be. But how do you accomplish, or how does RTI accomplish being able to connect all these devices? How do you send the messages back and forth so reliably?

David Barnett: Sure. I think one of the keys about the Connext DDS infrastructure is its ability to very intelligently distribute data where that is needed. Again, in an IoT system, whether you're talking about the data in an autonomous car, where you could be dealing with very large data sets coming from things like LiDAR sensors in cameras or in a hospital, where you could have literally hundreds of thousands of devices monitoring patients.

It's not feasible to send all that data to the cloud, or even a single point in an IT system. Key in Connext DDS is the ability to be very intelligent about what data you send where. They're only distributing data to destinations and across networks if that data is needed in that remote location.

Because these systems tend to be, we would call, layered, a key piece of RTI's solution is something we call the routing service, which acts as a smart forwarding agent between networks. It can intelligently determine what data needs to be sent, say, from a car back to a cloud service, or from a patient's hospital room to medical records, so that it's only sending data that's needed by the remote system over that particular network link.

[5:08] Looking at the Layered-Databus Architecture (or Systems of Systems) in IIoT Systems

Niheer Patel: Okay. In that layered aspect, it's really interesting, because this is really some guidance at the Industrial Internet Consortium, is also putting out of this Layered-Databus Architecture, it's more of a recognition of what's needed to be done in different industries to create their industrial internet of things systems, does that seem accurate?

David Barnett: Yeah, that's exactly the case. The Industrial Internet Consortium earlier this year published a document, which defines the connectivity reference architecture for how you compose these industrial internet of things systems, which are really what we would call systems of systems, because you can have a system both in a hospital room that works autonomously, but then you also have higher level systems, such as for health records, or maybe applications like clinical decision support, and smart alarming.

Really, this is why we would call them systems of systems, because each of these different subsystems is part of the whole larger IIoT system, can have its own autonomous function and capability, but maybe deployed at a different physical location, so some might be running in the room, some might be running in fog servers, in the hospital, and some would be running in cloud systems, or at least IT data centers.

[6:27] Applying the Layered-Databus Architecture to Autonomous Vehicles

Niheer Patel: Okay. If I were to try to apply what you've just told me to, maybe the autonomous vehicle industry, it's a growing industry, really fun to talk about, I know a lot of it is still in the imminent future. But, if we apply this Layered-Databus Architecture, we would see maybe at the business levels, we'd have some sort of fleet management or companies managing all the thousands of autonomous vehicles over maybe a sort of business or fleet management Databus.

Then, you'd have maybe lower level Databuses where you control vehicle to vehicle, or vehicle to infrastructure, then of course, the really cool, and really fun stuff is in the car itself, is, as you mentioned before, how do you connect all the different sensors, the LiDAR cameras, to the vehicle drive components in a safety, critical manner in this case, but is that sort of the right application?

David Barnett: Yeah, that's the right application. I think what is clear in a system like this is that some data needs to be shared outside the car, some data may just be needed in the car. For example, the car will have applications that sort of fuse their radar, and LiDAR, and video data to develop situational awareness about what other objects, car, vehicles, people, obstructions might be around the car in order to develop a path for that car, or determine "Do you have to brake?" For example, something unexpected happening.

Clearly, you're going to be dealing with potentially hundreds of megabytes a second, if not more, of data within the car, you're not going to share all that out of the car. But, there could become times where it becomes necessary, or you might want to share that information out of the car.

One of the applications, Niheer, that you just described, fleet management. Let's say there is a problem with the car, and the car has stopped, and maybe it doesn't know, maybe there is an accident, or something is falling into the road, and it's something that the car doesn't itself understand. In a case like that, it may be necessary for the person managing that fleet of vehicles, may want to tap into more data from the data flow within the car, so temporarily, someone actually might want to look at the data feed, or the fused data to think what does the car think about its current situation. Maybe even somebody has to manually drive the car a bit.

During that period in time, you actually will have to share a lot more data out of the car while it's being micromanaged by the fleet operator at that particular point in time. But, you could never share all that data from every car all the time, because it would just overwhelm the network, and 99.999% of it you'd end up throwing away anyway, so it doesn't even make sense to absorb the cost of sending it all.

It's not just that some data is sometimes, or intermittently needed in other locations, it's that you have to dynamically adjust to that, because I don't know in advance to say "Radar, LiDAR, video data from this car should go to my operation center." It's really only when there's an incident that I want to now look at that data to determine what the situation is, and how to get out of it.

Niheer Patel: Okay. That's a really good point then, it's not really just about creating the different layers of these architectures, of these systems of systems, but it's really building in the ability to control how the data flows between those different layers of the system, and really give full control to the right parties on whether it's on the fleet management level, or maybe even at the vehicle level.

David Barnett: Right. I think key is this is all dynamic. You can't be pre-configuring IP hosts, or addresses and say "This data goes from this car to these locations." Because you can't predict this in advance, these are all very dynamic ad hoc system, and they have to have the ability to adjust in real time to what the data flows are, and what data is needed in what location.

In fact, a lot of the extensions in our new 5.3 release are specifically targeted addressing some of these use cases.

[10:35] What is new in Connext DDS 5.3?!

Niheer Patel: Great. That's a great segway. Let's go ahead and jump into what we got in Connext DDS 5.3. For folks listening, Connext DDS 5.3 actually features two products, it's Connext DDS Professional, which is our flagship product with the DDS capabilities that David talked about plus all these additional product components that help you scale those Layered-Databus Architectures.

We also Connext DDS Secure, which contains all the good stuff in Connext DDS Professional plus the DDS Security Standard-Based Security Plugins that allow you to configure security, and make trade-offs with performance and security to suit different architectural needs. Those are the two products.

Now, let's dig into the features, specifically there's four big ones, I'll list them off maybe and then we can dig into them one at a time, does that sound right?

David Barnett: Sure.

Niheer Patel: According to the announcement, we have Interoperable Security, we have Historical Data Query, we have Seamless Device Mobility, which sounds like what you were talking about a little bit earlier, and Web Application Interoperability, which sounds really cool considering that most everything nowadays is made in a web form... one or another. Shall we start with Interoperable Security? What do we have here?

[11:47] Interoperable Security

David Barnett: Sure. A couple of years ago, RTI first introduced support for a early version of the DDS Security Standard, which really defined a very fine-grained data-centric approach to security that very much aligned it with the type of real time applications, you know, reliable application, the DDS itself targeted.

Now, new in this 5.3 release is that DDS Security Standard has been finalized and adopted officially by the Object Management Group. In 5.3, we've aligned our DDS security implementation with that adopted standard. This provides a couple of benefits to customers. One is now that we're using the Standard Wire Protocol as part of DDS Security, it means that our implementation will be forward compatible. If you deploy a secured device today using Connext DDS 5.3, that will inter-operate with devices that you deploy, or applications that you deploy in the future that are also based on future Connext DDS versions, now that the Wire Protocol itself has been standardized.

It will also even inter-operate with other implementations of the DDS Security Standard, which is often critical in a multi-vendor system, because different suppliers may choose to use different DDS implementations, and this ensures that they can still inter-operate on the network.

Niheer Patel: We've talked about healthcare and autonomous vehicle, surely the supply chain is early complicated there. Another industry that we're really focused in is smart energy. I could see with the diversity of vendors for smart energy, and microgrids in particular, need to have that interoperability, and the ability to secure your data. I have a customer quote here actually that says "With RTI's leading technology as the backbone" this is Spirae of course "of the Spirae Wave platform we're able to offer a proven secure and reliable solution now and for the future."

I wanted to hone in on the now and for the future part. Based on what you were telling me, it sounds like this will allow them to evolve their systems, evolve their offerings for their customers because of this forward interoperability, and at the same time, give their customers the flexibility of working with vendors who can now inter-operate with the Connext DDS Secure Messaging Framework.

David Barnett: Right. Interoperability is very important in industrial IoT systems, because they are multi-vendor, and they also have very long life cycles, and it is often difficult, if not impossible, to upgrade some devices and applications after they're deployed. In certain markets, which could include autonomous cars, medical devices, potentially things put under the power grid, because these are safety critical applications that often have to undergo rigorous certification process, once those devices are deployed, you really can't upgrade the firmware on those devices.

If I'm building it today with Connext DDS 5.3, I may still have to support that 10 or 20 years into the future, but I'm going to want to inter-operate with future versions of my products. Knowing that we support a standard security network protocol, it means you can now have that confidence that if you deploy applications today, that you can still inter-operate with those applications down the road, even if I'm moving to newer versions of Connext DDS later.

[15:36] Historical Data Query

Niheer Patel: Great. Yeah, that aspect of longevity is something that's really critical to keep in mind with these kinds of systems. We've talked about now and future, but let's go onto the next feature that we were announcing, and that's Historical Data Query. Let's talk about why getting past information is important.

David Barnett: Sure. We can even go back and look at one of the examples I described before. Let's say you're managing a fleet of cars, and one of the cars has now stopped because it's in a situation that it doesn't understand either what it is, or how to get out of it. Now, the human operator may need to temporarily take over.

But, to understand what's going on with the car, the human operator will kind of need a snapshot of what does the car see right now, and how did it get into this position.

Now, as I mentioned earlier, it's not possible to always send all that data from the car to the cloud, or operation center, because that data would just overwhelm the network. In fact, it may be that some of that data was actually even too high bandwidth to even send in real time over the network.

But, now, you're in situation where the human operator now needs that snapshot of data. It has to request that data after it was originally generated and published. One of the key new features in Connext DDS 5.3 is this ability to go query for historic data that you may not have received in real time when that data was produced.

Now, the operator of that car can actually go, even though he or she wasn't subscribing to the data when it was originally sent from the car, say "I now want to go back and see what does the car see right now, what did the car see maybe a minute or two ago, how did it get into the position that it's in." You can go back and look at that data.

Similar thing, you know, could be in a hospital. Maybe that you're getting an alarm now about a patient, for example, and again, maybe the doctor wasn't even, you know, maybe the doctor is at home, or at a restaurant, gets this alarm, and wants to go look at what led to this current condition, and they want to go get a snapshot of historic data. With the new feature in Connext DDS 5.3, it's very easy for the developer of that application to say "Give me the data that led up to this alarm or current situation," without that data having to have been subscribed at the time it was originally published.

Again, this way now I can request data when I need, even if the data had already been sent without overwhelming my network, because I'm only getting the data that I actually need, I'm not sending all this data at real time, that again, would, in the case of a hospital, completely overwhelm the network, it wouldn't even be feasible.

Niheer Patel: Yeah. To even try to store this data, you have hundreds of thousands of patients in a hospital, or hundreds of thousands of cars on the road, and by the way, these autonomous vehicles are expected to generate terabytes of data per day, storing that into some sort of database off car, off site, is just not even fathomable.

We need a way to get data directly from the point of origination, or some cache that's-

David Barnett: Right. What we rely on in Connext DDS is basically a local cache, which is typically in memory on each sensor, device, fog node that might be part of the system, and we cache the data there so that it can be then requested in the future, should it be needed by some other application without distributing it in real time, or the need to have any sort of centralized database, which again would have its own band bandwidth problems, as Niheer points out. Even that may not be feasible.

The fact that we maintain these caches in a distributed fashion is really the only way you can actually get the scalability that you need to both keep all this historical data at the rate that's produced, and then have it available when you actually need it.

[19:34] Seamless Device Mobility

Niheer Patel: Okay. Thanks. I want to come back to that doctor's example, where he's got the mobile phone, or mobile device, but before we get there, let's talk about this next one, Seamless Device Mobility. It seems like it's applicable. We've talked about dynamic networks. What does that mean for customers?

David Barnett: Sure. I think one of the challenges in a lot of IIoT systems is components so that system are mobile. We're not just talking about the fact that you might want to get mobile access from my tablet or phone, it's the original sources of data themselves could be mobile.

Looking at a hospital, a patient could have wireless monitoring sensors on them and be moving around the hospital. As they move around the hospital, they might connect to different access points, or different routers, or maybe they even are in a place where there might not be Wi-Fi access, and they have to switch over to the cellular network for example.

Same with the car, right? As the car is driving down the road, it's going to be connecting to different cell towers, maybe even to different carriers. Kind of the way IP Networking works is, as you roam, you often get what's called a new internet protocol, or network address.

I think, if you look at traditional connectivity approaches, what happens is when your network address changes, you often lose that network layer connection, wherever you were sending that data to. When you lose connection, it causes a loss of data while you have to then go re-establish the connection based on that new address.

One of the key features in Connext DDS 5.3, which we're calling Mobility or IP Mobility, is now the ability to automatically handle changes in the low level network address without losing any data in that process. Even if your IP address changes, and you maybe lose at the IP Network layer, you briefly lose connectivity, we make that transparent to the application, so at the Connext DDS level you're not losing connectivity.

From the application's perspective, you're always connected to that device. Any data that may have been deferred because the network connection was temporarily down will then be resent once that connection is reestablished.

There's now nothing for the application developer to do. From an application developer perspective, it's like you have a continuous connection even if I'm roaming between access points, or routers, or even across different network types, maybe it's a wired, maybe it's a patient monitor that's connected to a physical ethernet in the room, then you disconnect it from the physical ethernet, and it goes over Wi-Fi. Then, maybe you disconnect, you know, loses connection to the Wi-Fi, and switches over to cellular, you can make all of those transitions now without the application program, or having to worry about that at all. It's all completely transparent to the developer integrator, and no data is lost.

Niheer Patel: Before this feature, it was on the application developer. To be fair, customer or non-customer, it could've been anyone else that's building their connectivity solution, would have to bake it into their applications. Is that correct?

David Barnett: Yes, correct. Really, it doesn't matter how you were doing communication. If you were using IP, this is kind of an inherent challenge with IP, and the way IP is implemented in a lot of operating systems is the connection is lost when the address changes. That would be true if you were writing your own communication software, or using some other standard.

I think what we're doing in Connext DDS is basically adding a layer above the network communication to maintain this notion of a session even if the underlying network connection is interrupted.

Niheer Patel: Okay. Maintaining that connectivity, but abstracting it away from application developers, or device integrators, so that they don't have to worry about if they just are able to take advantage of this capability like they would many of the other features in Connext DDS?

David Barnett: Exactly. If I say I need data reliably in this application, I'll get data reliably even if that underlying network wasn't reliable.

Niheer Patel: All right. Thanks. Okay, we've got one more left, and this I think maybe it'll tie back into your doctor's example with the mobile device, but I'll leave it to you to describe this Web Application Interoperability. Why do we need to be interoperable with web applications?

[23:50] Web Application Interoperability

David Barnett: Sure. A lot of times I think user interfaces or HMIs today are built using web technologies, so they're built to run in web browsers, or using web-type scripting languages. The last key new feature we're going to talk about in Connext DDS 5.3 is support for our web services interface.

It's basically a RESTful HTTP based API to data that's being distributed with Connext DDS. Now, directly from my web application, or scripting application, I can use a web service's API to publish and subscribe to data on the Connext DDS Databus.

Niheer Patel: All right. If we were to tie all these together, maybe we could do the healthcare example. We have Interoperable Security for bringing together all these devices from different suppliers. We have Historical Data Query, if a doctor on his, or her, mobile device needs to get access to data about a patient that has already passed, but it's cached, they can do that.

Then, if this same patient, if the doctor decides the patient needs to be moved to another part of the hospital, for example, it's going to connect to a different access point, we cover that with our Seamless Device Mobility, so it's transparent to the doctor, transparent to the patient, transparent to everybody.

Then, finally, with this Web Application Interoperability, the doctor gets this state-of-the-art user interface to gather data about the patients, and to be able to visualize it without having to worry about spreadsheets, and charts, and detailed numbers, they can get the information presented in a way that makes it easier for them to do their jobs. Does that maybe summarize that?

David Barnett: That's a great summary. I think if you look all these features are very complementary and really fundamental to building these layered IIoT systems of systems.

Niheer Patel: Okay, great. David, that sounds really awesome. I know you're really busy with the launch activities, so I really appreciate your time today.

David Barnett: Okay. Thank you very much.

Niheer Patel: For folks listening in, Connext DDS 5.3 is available today at www.rti.com/downloads. If you're a first-time user, you can go to the site, you can get registered, you can download an evaluation version. You can get some more resources, more help at www.rti.com/gettingstarted. If you want more details on pricing and packaging, reach out to us on the website, or contact your local account rep.

Lacey Trebaol: Thanks for listening to episode 11 of the Connext Podcast. We hope you enjoyed it. If you'd like to learn more about what you heard today, head on over to podcast@rti.com. Thanks, and have a great day.