It's All About the TECHNICAL Details - Connecting the Pieces in the IIoT

In Episode 12 of The Connext Podcast:

• [0:44] the details of Fernando’s role at RTI
• [1:00] Some of the benefits an application developer would gain by using Connext DDS
• [3:00] What is DDS?
• [7:10] What is IP Mobility and what’s an example use case? What pain-point does this address? How does someone configure IP Mobility?
• [10:40] Topic Query is to DDS what a select is to a database (and more details about this new feature!)
• [14:45] Things to consider when choosing between Topic Query, persistence service, and database integration service
• [17:05] Handling configuration data: Persistence Service vs. Topic Query
• [17:55] How does Routing Service help build scalable systems? We touch on the n-squared integration problem, peer-to-peer, system isolation, and more.
• [21:00] How would you go about using Topic Query?
• [22:04] DDS and Security
• [25:09] Performance implications of Connext DDS Secure vs. TLS and DTLS

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: Hi everyone and welcome to the Connext podcast. My name is Lacey Trebaol, and today I'm really excited to bring to you an interview that I did with Fernando Crespo. Now, Fernando is one of the product architects at RTI. He's responsible for our main products, which is Connext DDS. Recently, we launched our 5.3 version of the Connext DDS product. Now, today we're gonna be talking with Fernando about the technical details behind this launch, so we'll be learning how it is you can leverage the new features that are in 5.3, in connecting your pieces of your IIOT system. We hope you enjoy.

[0:44] the details of Fernando’s role at RTI

Lacey: First, can you talk a little bit about what you do here at RTI?

Fernando Crespo: Yeah, so I am a product architect at RTI, so I'm just responsible for Connext DDS. That is our middleware product. We have a whole tools ecosystem around that and we have micro version, so I'm responsible for the Connext DDS product suite. I just work with my team on new features and new developments. Everything that goes into that product.

[1:00] Some of the benefits an application developer would gain by using Connext DDS

Lacey: Great. Okay, for people who don't know who might be listening to this, what's middleware?

Fernando Crespo: So middleware is just a ledger ... I mean, traditionally, kind of a few years ago, I think, people used to send data on the network, just at the application level. They used to open a socket and just send data, I mean, from one point to the other. So middleware is kind of a ledger that sits between your application and the sockets, for instance, that is pretty much going to allow the application just focusing on business logic, versus on the communication aspect. And pretty much it provides all the capabilities that, before, traditionally people built on top, at the application level.

Lacey: What's an example of what it means to be able to sit there and focus on anything other than the logic?

Fernando Crespo: So it's one capability that the middleware provide, like for instance filtering on data. So you may be interested only in a subset of the data. That's something that you have done, now you have to build on top of the application before, so you're sending a lot of data, but you may have interest only in a subset. That's what the middleware is going to provide-

Lacey: So in this way, it's kind of giving you a point to confine that complexity-

Fernando Crespo: Yeah.

Lacey: -of all these things into one area, instead of having that logic floating around your application.

Fernando Crespo: Yeah, so there are all the capabilities that the middleware provide. Like, for instance, reliable delivery that ... I mean, there are some transport protocol, out there like this that provide that, but I mean, especially if you use CDP as a transport, so a middleware is going to allow you to pretty much implement that reliability layering, which, the middleware is going to guarantee that a piece of data that you send from point A to point B has made it to point B. I mean, all that logic doesn't need to be done at the application level. We call that quality of services in the DDS space.

[3:00] What is DDS?

Lacey: What is DDS?

Fernando Crespo: Well, DDS is just an API and a protocol standard for data centric connectivity, so it's just pretty much, implements a middleware. I mean, you can implement a middleware that is going to connect components together, okay, of a given system. One of the nice things of DDS is that it is a standard that is built to provide low latency, to provide reliable delivery, to provide, and to allow you to build kind of full tolerance systems, and it's kind of widely used. It's kind of one of the core protocols in the industrial internet of things.

Lacey: Okay. Explain what DDS is like I'm a five year old?

Fernando Crespo: Can I say a standard? No.

Lacey: No. I don't know what a standard is.

Fernando Crespo: DDS is a technology that allows you to move a piece of data, something, okay, from point A to point B, okay? It just gives you the assurance, or the guarantees that you expect from that data. For instance, if you want that piece of data just to get to point B, okay, and you expect it to be in point B, so DDS is going to allow you to do that, versus the data is lost, or something happened.

Lacey: Alright, so onto the 5.3 stuff, from Niheer

Fernando Crespo: Yeah.

Lacey: RTI is continuously innovating to deliver more value to customers.

Fernando Crespo: Okay.

Lacey: In the latest release we are promoting three benefits in particular, and the first one is IP mobility, ensuring accessibility to data on a network where a device's internet location may change. The second one is topic query, so that's enabling applications to filter through historical data, and to do anything right, to filter to find something they want based on a topic.

Fernando Crespo: Correct.

Lacey: Like, I want to know everyone on this floor who might have a fever, in a hospital, I can query based on that attribute, right, of the data?

Fernando Crespo: Yeah. If you are kind of familiar with DDS or with pub-sub systems. When you create a subscriber, or the data reader, so you are just subscribing to the livestream of data, okay, in yellow.

Lacey: Right.

Fernando Crespo: What topic queries are going to allow you is just to access the historical data that lives in the global data space, that lives in the cloud, or in the network. I like to compare topic queries to select a statement, for instance, in a relational database. They are not much different than that. It's that, instead of querying a relational data you're querying-

Lacey: The global data space.

Fernando Crespo: The global data space, the global DDS data space, so your data that is distributed across ...

Lacey: That can also include across other relational databases, as well as on devices that are hooked up to it, that can write?

Fernando Crespo: Yeah, so that can-

Lacey: I mean, it can include anything?

Fernando Crespo: That can include everything, so it can include information that is stored in different systems, so everything that can...to the DDS..., so it can be queried.

Lacey: Then, the third thing, the third benefit of 5.3 that we're promoting is DDS security?

Fernando Crespo: Right. DDS security works with topic queries and IP mobility.

Lacey: What does that mean?

Fernando Crespo: That means that, a topic query is a select statement, right? Just think of a topic query as a select statement, okay, on some data that is distributing on the network, right?

Lacey: Right.

Fernando Crespo: When you issue that topic query, when you issue that select statement, or you send it on the network, you will have a chance to protect that, so you have a chance, for instance to encrypt.

Lacey: Okay, so for the DDS security one he wants to know, it says, "Basically, there are security capabilities for using both topic query and IP mobility, correct?"

Fernando Crespo: Right, so they both can be secure. I mean, so that means our DDS security implementation, the ones that we are building in Connext DDS is friendly, okay, or-

Lacey: Plays nicely with?

fernando crespo: Works with topic queries and IP mobility.

Lacey: Okay.

Fernando Crespo: With topic queries, yes, by protecting the query.

Lacey: Yeah.

Fernando Crespo: Also by protecting the response, the data that is coming back, and when I say protecting it could be, for instance, encrypting, or it could be signing.

Lacey: Right. Then, for the IP mobility it's like re-authentication after relocation.

Fernando Crespo: Correct, by allowing you just to change your IP addresses, and just re-authenticate as needed.

[7:10] What is IP Mobility and what’s an example use case? What pain-point does this address? How does someone configure IP Mobility?

Lacey: Great. All right, so the questions. What is IP mobility?

Fernando Crespo: IP mobility is the capability that is going to allow your DDS application to change its IP address. For instance, you could have your mobile device, okay, in a room. You could decide just to move to a different room, so that could trigger a change in IP address, okay? That is kind of happening automatically under the hood, so before our next release, 5.3, it was not possible to work on these kind of scenarios.

Lacey: What would happen without IP mobility?

Fernando Crespo: Pretty much, you would lose connectivity and you have to restart the application. Some people just have like a system on top of that, so they just resolve the problem before, just at the application level, just turning down, and just restarting the application, basically.

Now, with IP mobility, this is all going to be transparent to the application. The application doesn't need to worry about anything like that. You just can move. I mean, you can just connect to different wi-fi spots, and you are going to continue working. You are going to continue getting your data.

Lacey: What types of customer use cases would demand IP mobility? Where would they benefit from that?

Fernando Crespo: One of the use case, for instance, is kind of the typical DACP use case, in which you get assigned an IP address, but that IP address expired, so you are going to get a new one. It's a little bit technical, but there are other use cases in which you cannot start your DDS application with network connectivity. You just start your DDS application in a box that doesn't have network connectivity, and you get network connectivity after that. You would be able to start communicating with other nodes, and other applications transparently, and automatically, without doing any work.

There is other use case, that as I mentioned before is a typical use case in which you have a mobile devices, nowadays, I mean you can run DDS in mobile devices which support IOS.

Lacey: Micro.

Fernando Crespo: We support Android, both in ... Well, connects DDS and also micro. You can have your mobile device, and you may be connected to a wi-fi spot, but you can move to a different one, so you can walk to a different room, and you are going to lose your old IP address, you are going to get a new one, so you're going to continue working on those cases transparently. This is kind of what IP mobility is going to provide you, that kind of capability.

Lacey: How do you use IP mobility?

Fernando Crespo: The nice thing of IP mobility is that you don't have to think about that, because it's completely transparent, so I got that question before. This is not the first time that I get that question, so that is how do I configure IP mobility? Although there are some configuration parameters, and then we can discuss as needed. IP mobility works out of the box, so you don't have to do anything. If you have a legacy system, using an older Connext DDS version and you move to a new one, 5.3, so you will just get IP mobility without code changes or configuration changes, or something. It just works.

Lacey: You don't need to recompile your old ...

Fernando Crespo: Nope. You don't need to recompile. You don't even need to change a configuration file. You just get IP mobility for free.

[10:40] Topic Query is to DDS what a select is to a database (and more details about this new feature!)

Lacey: Okay. What's topic query, just a simple definition?

Fernando Crespo: Topic query is to DDS what a select is to a database. That's the simple definition that I can give. It just allows you to access all the data, where there is, that is stored in the DDS cloud. I just call it historical data because it's data that was put in there before, and not necessarily live data. With topic query, you can query, and all that data you just can provide a filter expression, and a filter expression could be, for instance ... I mean, if you are in a healthcare application, you may want to know what was the temperature of a patient over the last 24 hours, right? You can do that with a topic query. You can just-

Lacey: Pull that data and then-

Fernando Crespo: Yeah, you just can pull the data from the different components that store that information.

Lacey: How does topic query differ from persistent service or a DDS application that's using database integration service?

Fernando Crespo: Topic query is just the capability that allows you to query historical data, okay?

Lacey: In the data space?

Fernando Crespo: In the whole data space, and persistent service is the capability that is going to allow you to keep data around, even if the original producer of the data is not in the system anymore. You can keep that data in memory. It's usually kept in a separate process that is the persistent service process. You can keep it in memory. You can keep it in disc. You keep that data for late joiners applications, so for applications that may join the system-

Lacey: They need to know about things that have already happened before they joined in order to operate properly.

Fernando Crespo: Correct. For instance.

Lacey: Right.

Fernando Crespo: That's what persistent service is going to give you, is that kind of capability. Now, you can combine topic queries with persistent service, right? It makes sense to query the persistent service cache, and you can do that with a topic query, for instance, although we do not support it yet, but we're going to support it pretty soon.

Anyway, so it makes sense to do that. With respect to database integration service, well database integration service is just a way to store DDS data into a relational database. It just gives you a way to use a different API to access the data that is on the global data space, so you can use DDS. That is our traditional API, but you can also use a scale. That's what database integration service is going to give you, and the nice thing of database integration services is that it is bi-directional. You will be able to store DDS data into a database, and just do, run scale statements, and just query that data, do data mining on that.

Lacey: You gain some of the benefits of having the DDS system, but you don't have to change the way you interact with the data?

Fernando Crespo: Correct. You can still interact with the data using a scale.

Lacey: Yeah.

Fernando Crespo: I mean, this is what you understand or what you used to do, and vice versa, it's also the case, we also support the opposite communication pattern. It's essentially, you just use a scale, for instance to update a row in a table, and that row update is going to be propagated. It will be replicated to a different row using DDS. It works in both directions, so that is what database integration service does.

Topic query, it doesn't work with database integration service. It doesn't make sense on that sense. Essentially, you cannot ... You already have the query language at this scale-

Lacey: Right.

Fernando Crespo: -when it comes to the database integration service. Topic queries, the query language for DDS-

Lacey: In DDS, for Connext DDS?

Fernando Crespo: For Connext DDS, yeah.

[14:45] Things to consider when choosing between Topic Query, persistence service, and database integration service

Lacey: All right. Moving on. I'm a customer. I have a use case. How do I choose between topic query, persistent service, and database integration service? I'm guessing that the answer is if you want to use SQL, and that's your happy place, with your relational database, you are going to go with database integration service. If you need to query things, and you don't want to be tied to SQL, or you don't like SQL, and you don't need to use it, but you want to use DDS API, then you would go with topic query, and you would use 5.3.

Fernando Crespo: Yup.

Lacey: If all you need is the persistence aspect of data, but you don't need the ability necessarily to have it constantly be queried across your entire data space, when would you use persistent service and not use topic query?

Fernando Crespo: They both are orthogonal they work together, right? You can use ... Persistent service is going to give you the capability of keeping data around, okay-

Lacey: Right.

Fernando Crespo: -even if the original producer of the data-

Lacey: Crashes.

Fernando Crespo: -crashes, for instance. It's not in the system. It's just going to allow you to do that, okay? That data is going to be around for applications that may join the system later.

Lacey: How would you query that if you didn't have a topic query? Could you?

Fernando Crespo: If you don't have topic query what you do is you subscribe to the data, the first time and you can provide a filter expression, and you are going to get everything that matches that filter expression. What you cannot do is to go back and say, "Well, I'm really interested on this piece of data, but now I want this other." In order to do that, doing that, I mean in the old, without using topic query, requires you to create new subscribers-

Lacey: Right.

Fernando Crespo: -to the data, okay? That's kind of what topic query-

Lacey: You can't just navigate the data space and search it? You had to spin up instances to handle all those queries?

Fernando Crespo: Correct, sadly, because what you subscribe to when you create a regular subscriber or data reader, I mean that is how we call them, with DDS, you just subscribe to a subset of the data. You subscribe to the live feed of the data. You are going to get everything, all new, that satisfy that expression, but you cannot change your mind now and say, "Well, I want something else." You can change it but you have to create a separate subscriber

Lacey: That's more work for you.

[17:05] Handling configuration data: Persistence Service vs. Topic Query

Fernando Crespo: -that is a heavy ... I mean, it's more heavy lifting on the application side, right? I mean, one typical use case for topic queries that some of our customers have, is kind of configuration data. Usually, people store configuration data, many of our customers store configuration data in a persistent service, okay? They just start a producer that changes a configuration perimeter. It could be like the configuration of a medical device, for instance. It changes that configuration. That new configuration is stored in a persistent service, and now you can access to it just by using a topic query.

You can say, "Well, what is the configuration for this medical device," or, "What is the configuration for this other?" You can do these kind of things with topic queries, combining them with a persistent service. The topic query thing is that it behaves pretty well with routing service, so it propagates through routing service instances, which is really good because it just help ... It makes those queries really scalable on that sense.

[17:55] How does Routing Service help build scalable systems? We touch on the n-squared integration problem, peer-to-peer, system isolation, and more.

Lacey: Really quick, for people who don't know, what's routing service?

Fernando Crespo: Routing service is just a component that allows you to be a highly scalable system. Usually, Connext DDS is a peer to peer middleware, right? That means you get the nice things of being peer to peer in the sense that you don't need a server in the middle. You just discover everybody, nothing a point of failure, but it's really expensive. As your system grows, it's really expensive to scale it with a peer to peer.

Lacey: The N squared integration problem.

Fernando Crespo: Right, especially if you have pub-subs communication patterns, like that is what kind of the main communication pattern that DDS provides. Now, with routing service you can isolate DDS subsystems, and you can make them more scalable. Usually, routing service is using a hierarchical architecture, so you can isolate communication in different DDS app systems. They don't need to talk to each other, or they don't need to share all the information among each other, so they just share the information that they are interested in.

Routing service is kind of the component that is going to allow you to do that. It's kind of the component in the middle. That's many things it also does, the whole transfer ... I mean, routing service is also kind of a process that allows you to integrate systems that do not necessarily talk DDS, right?

Lacey: That's the use case I'm used to associating, routing service one ...

Fernando Crespo: The one that we see nowadays, like for instance, the one that … is kind of the scalability use case. You use routing service to isolate DDS subsystems, and just to scale that way. Then there is the kind of integration aspect of routing services. There are multiple use cases. The integration aspect is the one that is going to tell you to bring non-DDS data into the DDS cloud, right, and vice versa. You do that with routing service adapters. Traditionally, also routing service was used as a security checkpoint for DDS assistance, so now that we have secure DDS, I mean, there are other ways to do it.

Also, routing services use kind of, as a component, in combination with TCP or our wide-area network transport, to access the wide-area network, to exchange DDS data on a wide-area network, for instance, the Internet, with uppercase I.

Lacey: Uppercase I.

Fernando Crespo: It is used to do that as well.

Lacey: Routing service, I know it has a lot of ... It's kind of like DDS, right? It has a lot of capabilities in it.

Fernando Crespo: Yeah.

Lacey: It's just, it's like a multi-tool, but that's not a sufficient definition, and I feel like the list that's on the website, while I understand because I know the product and I've seen it used, where each one of those little things would apply, just looking at the list is a little-

Fernando Crespo: Right.

Lacey: -oh my god. Does it also butter my toast?

Fernando Crespo: Right.

[21:00] How would you go about using Topic Query?

Lacey: Gives you back rubs. Okay. How do I use topic query?

Fernando Crespo: There's a new API that is called create topic query. You need a data reader in order to create a topic query, and you create topic queries for the data reader. Every time you invoke create topic query, you are just kind of creating that select statement on the global data space.

You get the data, so when you create a topic query, you also provide a filter expression. You can think of that as the ware part of any scale. Select a statement, and that is it. There is not much to do now. When you create a topic query, you just receive the data on the same data reader for which you created the topic query. You just use the same APIs, I mean, to read and access that data, when you will use for live data.

[22:04] DDS and Security

Lacey: Let's talk about DDS and security.

Fernando Crespo: DDS security is kind of the-

Lacey: The OMG specification.

Fernando Crespo: The OMG specification just to secure DDS data on the global data space.

Lacey: You have the DDS security spec, and that's an extension of the DDS standard-

Fernando Crespo: Correct.

Lacey: -which is written by OMG and we've been contributing to since. Through our Connext DDS secure product, we implement plugins and a security solution?

Fernando Crespo: Right, so the DDS security spec defines two things. It defines the security model, and it defines pluggable API, and by the security model I mean, while it defines the, that for instance, a data reader can be allowed, for instance, what is the access control to the ES topic, so that's kind of part of the security model. It can be allowed to access certain topics, certain data but not other writer, a data writer can be allowed, you know, a domain can be allowed to publish data on a topic or not, okay?

Lacey: Okay.

Fernando Crespo: These kind of things, that's kind of the security model, and then it also defines a pluggable interface. For instance, if you want to do authentications, so there are many ways to do authentications, so the DDS security specify a default plugging implementation that we support in our secure product, but the user could choose to use something different. There is a whole pluggable interface with that. Same for access control, for instance, or same for instance, data encryption, or data signing. All these kind of things are things that you can do differently than what the default planning-

Lacey: You can customize your security solution to your needs?

Fernando Crespo: Yeah. You can customize your security solution. That's kind of what the pluggable API allows you to do.

Lacey: All right. Why would I choose DDS security over TLS or DTLS? Elaborate on the fine grained security, and the ability to make performance trade offs.

[25:09] Performance implications of Connext DDS Secure vs. TLS and DTLS

Fernando Crespo: What we are talking about when we mention TLS, or DTLS, it's about securing the pipe or the transport. DDS security provides you finer control than TLS or DTLS transports. Also, DDS security is kind of standard, so TLS and DTLS transport are just components, I mean, provided by RTI but they are not standardized. When I say that is, it provides you finer control, is that with TLS and DTLS ... You can protect the information that goes on the wire between two DDS applications, but you cannot, for instance, give different permissions to one application or another. You just get all or nothing. You just secure the pipe. With DDS security, you have finer control, so you can, for instance, give to an application permissions to publish data on a DDS domain but not on all the topics, for instance, just on a subset of the topics.

Vice versa also, so you can also give an application just permissions to read certain topics and not others. It just secured your data at the topic level, versus securing your data at the transport level.

There are also performance implications. TlS and DTLS, those two solutions, do not support, for instance, multicast. One of the kind of nice features of Connext DDS is that it supports multicast communications, so you can pretty much scale, I mean, your one to end communications, especially with pub-sub because we can use multicast under the hood. Without implementation of DDS security, with Connext DDS and DDS security, so you can still use multicast and secure your data. You couldn't do that with TLS and DTLS.

That's kind of from a performance point of view, so that will leave you much more scalability, especially in use cases where you have like a large funnel, and you want to ... There are a lot of subscribers for the data that you make available on the network. Then, there is the aspect of plug-ability, so you cannot plug things into the TLS or DTLS transport. You can plug, for instance, your own encryption, or your own signing, algorithms with DDS security. With TLS and DTLS you just use what the transport has to offer that is ... We use open SSL as the underlying security library.

Lacey: We talked about Connext DDS Secure, and we've talked about IP mobility, and topic query. How does the security fit into the previous discussions and everything we've had about IP mobility and topic query? Can we securely use IP mobility and topic query?

Fernando Crespo: Yeah. It works with both of them. In the case of topic query, so you can use Secure DDS just to protect the request for a query, and also the response like, you will protect regular live data that you subscribe to with data readers. There is nothing special about that, and in the case of topic query, we are going to make, pretty much it will be robust to IP address changes. You will be able to change your IP address. It's not that the re-authenticate. I mean, we mentioned that before but it's not that we are re-authenticating when we use IP mobility. It's like we are kind of signing the data. When there is an IP address change, and you have to announce that to the other side, so we are just kind of signing that data to make sure that nobody else-

Lacey: Inserts something else-

Fernando Crespo: -an intruder, and just put there whatever they want, just change the IP address to, for instance, a different machine that you shouldn't be talking to and this stuff. The other thing that I can tell you is that the way we secure IP mobility, it's not part of the standard right now. It's something that we are kind of incorporating on the standard.

Lacey: All right. Thanks for listening to episode 12 of the Connext podcast. We hope you liked it. If you have any questions about what you heard in today's episode, please reach out to us at podcast@rti.com, or head on over to social media. Thanks so much and have a great day.