Connext 6 - Designing Industrial IoT Systems for Scale 

In Episode 30 of The Connext Podcast:

• [2:21] The first things to consider when building large IIoT systems
• [9:29] Defining the Databus
• [11:12] New features and capabilities in Connext 6
• [39:54] Securing your data

Related Content:

• [Datasheet] RTI Connext 6
• [Infographic] RTI Connext 6
• [Press Release] RTI Announces the First Software for Highly Autonomous Systems

Podcast Transcription

Steven Onzo: Hello everybody and welcome to another episode of the Connext Podcast. This week we talk about the challenges of designing Industrial IoT systems for scale for now and for the future. We'll also discuss some of the features of Connext 6, and how they apply to large-scale connectivity. Rajive and Fernando, thanks for joining us.

Sumeet Shendrikar: Hi, welcome to the RTI Connext Podcast. Today's topic is designing Industrial IoT systems for scale and a preview of Connext 6 coming out soon. My name is Sumeet Shendrikar, I'm on the Professional Services team here at RTI. With me are Rajive Joshi from our Professional Services team, and Fernando Crespo Sanchez, a product architect on our Research and Development team. Rajive, can you give us a little bit about your background and what your role is on the services team?

Rajive Joshi: Absolutely, I'm the Principle Solution Architect on the Services team. I've been with RTI for about 22 years. I've been part of the product team, part of the research team, and then over the last 10 or so years, I've been in the field working with our customers. And that's largely what we do in our Professional Services team, from onboardings, to product trainings, to helping with architecture and design, and even taking on pieces of the solution, and building it out for the customers. So really, the focus of the Professional Services team is customer success. That's what gets me excited, is working with our customers.

Rajive Joshi: I do have another hat. I also represent RTI at the Industrial Internet Consortium, and there I chair the Connectivity Task Group and also the Automotive Task Group. So, I led the development of the Industrial Internet Connectivity Framework, or the IICF, that some of you might have heard of. It's available from the IIC website.

Sumeet Shendrikar: Fernando.

Fernando Crespo: Yeah, I think mine is something more simple than that. So I have been with the R&D team for about 14 years now. I grew up in Spain. I just moved to the US. I think it was a great professional opportunity. And I started to work with the middleware, Connext DDS right away, and currently, I'm a product architect for Connext DDS Pro, and have been doing that for a few years already.

Sumeet Shendrikar: I think we have a great mix here, because we have someone who's representing a lot of customer work, and someone who's representing the product team, and we'll get a chance to see how these two marry together.

Fernando Crespo: Yeah absolutely.

Rajive Joshi: Absolutely, yeah thanks.

[2:21] First things to consider when building large IIoT systems

Sumeet Shendrikar: First question right off the bat, when you're building these large IIoT systems for healthcare, say patient monitoring, or hydropower in dams like the Grand Coulee, oil and gas systems, autonomous systems, what are the first things from a technology standpoint that you should consider for your system? Rajive, I'll start with you.

Rajive Joshi: Sure, One of the things that we see common, across all of these systems, is that if there's a failure, there's loss of life or property, usually both, especially when you start talking about healthcare or autonomous driving. And even power, and oil and gas. These are all systems where failure is not an option.

Rajive Joshi: And the second thing to note about these systems is that the right information, the right data delivered too late, becomes the wrong answer. So they're also systems with data delivery and timing of some data delivery is critical. That changes the way you have to approach the design. So you care about performance.

Rajive Joshi: Also, these systems involve a lot of different things, different data objects, different complex information flows, so scalability is another big concern that shows up. And of course, you don't want anybody to be able to get into these systems, so security is another big concern.

Rajive Joshi: Safety, which at first you, really the impact on humans. Again, obviously this is a big concern. So, all these are big concerns. And finally, when you're starting to build these systems and they have complex data flows, there are many different teams involved. So, you have to be able to provide a solid foundation that allows you to build an architecture in which multiple teams can independently develop and participate, and allow you to build a solution that will actually come together nicely.

Sumeet Shendrikar: So that's a lot of different things you described. Where do you start?

Rajive Joshi: So really, we start by thinking about information models and data, right, because that is something that tends to be more constant over the lifecycle of the system. The data models are relatively the stable piece, whereas different components that you might add to an architecture may change over time as you think up new ways of doing things, that you think of new techniques, that you think up new capabilities that you might want to add.

Rajive Joshi: So we like to think of it as, think of the data architecture, build the data architecture, right, and then you can create components around it. And so this is where the Databus concept comes in, and this is what we call Connext Databus where it ... Building around the data architecture in a data-centric fashion allows folks to build systems that are scalable, that are modular in terms of software architecture, and then because the Connext Databus is designed for real-time, time-critical applications, you'll see that as I think folks would know it's being used in a lot of applications and systems of this kind. It's designed to be reliable and be real-time.

Sumeet Shendrikar: So it's a little different than what you normally hear, which is things like object-oriented interfaces. You're talking about data as your interface.

Rajive Joshi: Absolutely.

Sumeet Shendrikar: How do you approach that subject with customers since you spend so much time with them onsite helping them to try to architect these things out?

Rajive Joshi: Right. So, typically we start with thinking about the data models and the data flows in the system, and we start to define data-oriented interfaces for the different components. And once we have that and we can create that, we can then use that as a foundation for allowing different teams to participate, but because we are starting with the data architecture, we also have the process and the method to be able to integrate all the components using the Databus.

Sumeet Shendrikar: Okay. So, what are the major challenges that developers, systems architects, face? You mentioned scalability, security, safety. How is it different now with the Databus in play?

Fernando Crespo: Right. So I think it's difficult to assign the system. The problem is that there are so many things to consider when it comes to these large systems, right? So these are systems as Rajive mentioned before, in which you have hundreds of nodes, and you have data, different kinds of data. You have large and small data. Historical and real-time data. Confidential and not confidential. Security is also something to consider in this kind of system. Mobility, I think you can move components from one place to another, or you can lose network connectivity.

Fernando Crespo: So, it's kind of difficult just to consider everything at once. When you're designing one of these systems, and this is where the Databus comes into place. So the Databus is going to hide some of these complexities, and this is what we do here at RTI. So we are going to hide this complexity to people, so that the thing they worry about is the data itself, defining those data models, and the data that they want to exchange, and not so much about this other aspect like scalability, security, and so on. So, we want to hide that complexity, and this is where the Databus comes into play.

Rajive Joshi: Absolutely. So component designers and architects, they can focus on really just the data IO, what I produce and what I consume. And define that in terms of structured data types that you would normally use as an application programmer. So, it gives you an interface that's very natural for the system, the application developers, the component developers, but at the same time, it is defined using artifacts such as IDL and XML, so-

Sumeet Shendrikar: What does IDL stand for?

Rajive Joshi: IDL stands for Interface Definition Language. So you can actually version control those things, you can put them in your system as part of system artifacts, and you can also evolve them over time, and that leads us to the concept of what we call extensible types and-

Fernando Crespo: Evolution.

Rajive Joshi: ... data type evolution. So these interfaces can evolve over time.

Rajive Joshi: Now, as Fernando said, you are building around these interfaces, and the Databus really takes care of making sure that the right data gets to the right place at the right time. So, it's handling essentially the requirements for timeliness, and for scalability, and resilience, and fault tolerance, and security, and so on. And the job of the architect is really then to just configure the interfaces correctly, and configure the Databus correctly, and not have to worry about the low-level details of data.

Fernando Crespo: Right. It's a completely different paradigm, if you want to look at it that way, in which you approach system design. So here you just have to consider ... So it's all about the data, right? So, the Databus needs to be aware to be able to scale and to be able to meet all of these requirements, the Databus needs to be able to be aware of the data, okay? So what is the content of the data? So it needs to know about the data. This is what we call data centricity.

Sumeet Shendrikar: A lot of what you're talking about sounds very similar to conversations people have when they're talking about databases and how to use a database, but the difference here is we're talking about data in motion.

Rajive Joshi: Absolutely.

[9:29] Defining the Databus

Sumeet Shendrikar: There's no data at rest, and so we're using this term databus to reflect that aspect. Can you define what a databus is, just so we're all on the same page here?

Rajive Joshi: Sure, the word databus, you can think of this as a play on the word database. When you start thinking of a databus, you essentially apply the same mindset as you would apply for databases, except databases are about data at rest, and databus is about data in motion. And database is about essentially searching past historical data, whereas a databus is about essentially creating filters for future data. If you step back, what's coming across these data-centric approaches is the data itself in an interface to the components.

Rajive Joshi: And the infrastructure, in the gist of a databus' infrastructure like the Connext Databus, in the case of a database, is the database implementation, essentially, it's configured using rules, and it maintains essentially the integrity of the data, and in the case of a databus, getting the right data to the right place at the right time.

Fernando Crespo: It takes care of sending data from Point A to Point B with their requirements that the user has, including scalability. I just mention it again because it's kind of one of the first problems that people face, and we're designing this system from scratch, or even when they want to migrate, for instance, a custom solution or a system that they already have into something that is going to allow them to position themselves for the future, right?

[11:12] New features and capabilities in Connext 6

Sumeet Shendrikar: Okay. So that brings us to, you've mentioned a couple times the RTI Connext Databus. We've just announced Connext 6, and if want to hear more details about it, podcast 28 with Bob Leigh has an introduction to Connext 6.

Sumeet Shendrikar: But can you talk about new features and capabilities we've added that are gonna help address some of these problems that you described for people who are trying to build these large, scalable systems?

Fernando Crespo: I think one of the key things that we are addressing is that we have identified that to be able, these kind of systems, so you need something called a layered architecture. It's something, that Rajive is very familiar with. A system architecture-

Sumeet Shendrikar: Rajive, Fernando's talking about these layered databus architecture for the IIC.

Rajive Joshi: Yeah. This is something that has been identified also at the IIC. IIC is the Industrial Internet Consortium. It's part of the IIRA which is the Industrial Internet Reference Architecture, so a lot of acronyms there, but if you go to the IIC Consortium.org, you can download all these acronyms from there.

Rajive Joshi: So there's IIRA, and then the IICF, Industrial Internet Connectivity Framework, and they kind of work ... And then there's also the Industrial Internet Security Framework, and really the data, layered databus architecture is a core idea where you can build essentially a local databus, which is basically a local plane of communication. And-

Sumeet Shendrikar: Can you give an example, for example for autonomous systems?

Rajive Joshi: Yeah. I might pick an example from autonomous vehicles since that's sort of an area that a lot of folks are interested in. So, you might have a vehicle databus that's essentially the autonomous drive system for the vehicle. It might itself have components that may be doing planning, and decision making, and navigation, and control, and so on, and sensing. And we'll come to the sensing part in a little bit because there are some features that are particularly relevant to large data that are new in Connext 6.

Rajive Joshi: But now, this vehicle is a self-contained thing and you don't want essentially all the information inside the vehicle, especially when you have LiDAR, and cameras, and all that real-time data moving on that databus being shared outside the vehicle. Yet there are some relevant attributes you want to share. For example, what is my vehicle position. What is my speed. Where am I heading. So there's a subset of that data that you indeed want to share, for example, with back-end systems and possibly with other vehicles as well. And other vehicles would have a local vehicle databus inside, as well, and maybe in the back end, cloud side, you might have a databus. So, this notion of layering is essentially taking one databus and then rolling up some of that information, and using essentially a databus gateway as an adaptor or a bridge to another databus. And so you can roll up information and Connext DDS, again, is designed so that you can have only the right data that is of interest streamed through these databus gateways.

Fernando Crespo: Right, yeah. It would be impossible to think of these kind of systems as a flapping out...

Sumeet Shendrikar: So you have to have different levels of networking.

Fernando Crespo: You share the data with everybody, everybody can see all the data, so there must be some kind of force indicating before this case. So, you need to be able to isolate and route the data smartly, right? And the way to do that, so Rajive mentioned it, so there's a key component in this kind of system that is called the gateway component. For us at RTI, that component is called Routing Service, and it's a product that would be-

Rajive Joshi: This is the one that in the IIC documents is called the Databus Gateway, and in RTI Connext it's called the Routing Service.

Sumeet Shendrikar: Actually, maybe Fernando, you can talk about it. You have a lot of experience and familiarity with one of our largest healthcare use cases. They make heavy use of this notion of a layered databus architecture. I don't know how many end points they have, how many patients they're actually monitoring, but they make use of Routing Service quite a bit. Can you describe a little bit about that use case?

Fernando Crespo: Yeah, I think the use case is, it's essentially a patient-monitoring system where you have tons of devices, in employ using data off patient's, and you need to be able to access that data. I think that data may have to be accessed by doctors that are monitoring the patient, but that data may have to be stored as well because you need to access the data offline or later on. That data may have to go into the cloud. So there are a lot of subscribers for that kind of data that is produced in this kind of system. And it's not a small amount of data, so just imagine that would be hospitals, and so on.

Fernando Crespo: So for this kind of use case, layered architecture is kind of very sortable for these use cases because you have a component that we call Routing Service or the gateway that is going to do the smart routing. So in this kind of system you produce a lot of data. You only have a small set of subscribers trying to access the information that is produced in the system, right? So you have to be smart. You cannot broadcast and send all the data into the system because you would take the system down. There would be tons of problems.

Fernando Crespo: So what Routing Service allows is similar to a router, to an IP router, but it just does it based on the content of the data.

Sumeet Shendrikar: That's interesting.

Fernando Crespo: The data, the key piece here is that Routing Service, and the rate of OS, and the middleware that is providing access to that databus, is data-ware. So let's take a case as an example, so let's assume that we have a patient, right? And we are monitoring that patient. That patient we are probably seeing temperature, for instance. Ok, and you have a subscriber at some point, it could be a doctor, in the system that wants to be notified when the temperature goes above certain degrees. How do you do that? So you cannot publish every temperature reading into a system. You cannot pull it into a system because you would flood the network, especially when you have hundreds of patients and hundreds of sensors and different measurements that you can take.

Fernando Crespo: So what Routing Service does is essentially just allow a subscriber to connect into the system, and allow that subscriber to specify a set of interests. So me as a subscriber, let's say that I am the doctor. I usually use it with an iPad or some kind of handheld device. So me as a subscriber, I'm going to say, "Well, I want data for this patient with this temperature." So you specify that through something that we call field expressions, so just an expression that tells the databus what you want, right? So, what Routing Service is going to do, what the Gateway is going to do, is just to take that information and use that knowledge to provide the data.

Sumeet Shendrikar: So you're not telling the patient, "Hey, I need this only if it's above a certain temperature." You're saying, "Infrastructure, tell me whenever the data has it above this to make sure I get it."

Fernando Crespo: Correct. And that way, the data is just sent only where it has to be sent. And this is what is key about this kind of architecture, right?

Sumeet Shendrikar: And I think what's important about that use case that you just mentioned is that it touches on a lot of things you talked about at the beginning, which were security, safety, timeliness, time value of data, right? If you talk about this for a second with a patient, it sounds like something people have done in the past, but if you wait five seconds, there's a delay on the data. Obviously if that patient is a critical case, that may be too late. You have to expend. You have to make sure it's protected, that no one finds out information about who that patient is. And for a lot of people in the software world, it's just a matter of move fast and break things, but you really move fast in this world. This is life critical, so there's no chance to change things, so you have to make sure you are very clear and know your capabilities.

Rajive Joshi: Right.

Rajive Joshi: And there's also some interesting situations, use cases, that really our Databus is really very well suited for. For instance, you might find that this patient is showing some symptoms. And then you want to roll back and say, "I want to monitor the last five minutes, or the last 10 minutes, or what was really happening because I'm detecting an anomaly now. I want to see what's going on with this patient 10 minutes ago, and I want that historical data."

Rajive Joshi: So again, with Connext 6 we have some new capabilities. We call them topic queries that allow you to essentially ask the Databus, "Hey, give me that historical data," and as an application developer, you're not really doing anything different. You are simply just offering that data on the Databus. So again, this is a good example of where the infrastructure is smart enough to know that it has been given this data, and it can handle that data smartly, and just get that ... as I said in the beginning, getting the right data to the right place at the right time.

Sumeet Shendrikar: So Fernando, you talked about Routing Service and it was used in the healthcare use case. Can you talk a little bit about new features in Connext 6 with Routing Service that are going to help make that use case even easier, or help make that use case happen? Things like the multi input output, etc.

Fernando Crespo: Right. In fact, I'm really excited about these new capabilities that we are introducing with Routing Service. In that sense, we are kind of providing a whole new product, okay, with a whole new set of capabilities, and it's based on infrastructure that was already there. So it's not something that we have written from scratch, so I think that those, the core of the infrastructure, the core of Routing Service, was already present into that product. But one of the things that the gateway does is route information, route information from in-between domains, or from Point A to Point B, right? And to route information, you need to define route. It used to be the case where routes had a single input and a single output. So for instance, I could route information from a room where there's a patient on the administration floor of the hospital. Okay? Or a different room where there's a doctor. So I could route information, and I will define my route at one to one to do that. Okay?

Fernando Crespo: But one to one routes are not as scalable, and are not sufficient for this kind of system. So you have to be able to do a larger funnel if you want two from the same information. So if I produce a temperature reading, and I have a one to one route, I can send that only to one domain. Of course that domain can contain multiple subscribers. But what if I want to take that same reading and just store it into a database that is running on a different part of my system, right. So in essence, we are dealing with the same piece of data, and we want to make sure that that same piece of data is just sent to two different places.

Fernando Crespo: Well, this is what we call one to end route. So these are routes where you can have a single input, a single piece of data, that goes to different places. So, it's a little bit similar to multicast, if you think about it-

Sumeet Shendrikar: Think of it that way, yeah.

Fernando Crespo: ... but a gateway level.

Sumeet Shendrikar: To actually continue this network analogy, we talked about you can't really have a single layer 2 network. You need to have switches and routers in your network to produce scalability. Same way with a layered databus.

Rajive Joshi: Absolutely.

Sumeet Shendrikar: Now we're talking to a routing service which can have more of a multicast-like capability. We won't talk about broadcast. That doesn't make sense here, but a multicast-like capability. And then we also are introducing things like more logic inside a routing service that help manipulate the data if necessary.

Fernando Crespo: Correct. So you as the data flows through a route, you can transform the data. For instance, you could filter some set of data points that you don't want to send to others, right. So it's also a security gateway in that sense. And these are transformations, these transformations you can do with the data. They are transformations  you can write as a user.

Fernando Crespo: So we are providing a whole new SDK to do these kind of things, and we call it the process or API SDK, and it's much more powerful than what we have used in the past. 

Fernando Crespo: And in addition to that, It is very important that you have a gateway component, the variability on how to debug this piece of software is key for us. It's key when you have a big system, right, because it could become very complicated. So, we are also introducing a new way to monitor this component, and it's a way to monitor the component that is not as intrusive as what we used to do in the past. So if you try to monitor something, what you might have done is inject the system with more data and that is going to make it worse.

Sumeet Shendrikar: So let's keep going on the theme of Connext 6 now. One of the biggest focus areas for the next product release is this large use case you mentioned Rajive, particularly the autonomous vehicle use case. Let's talk about that large data. Can you talk about the new flat data and enhanced shared memory that our capabilities are being introduced to the product?

Rajive Joshi: Absolutely. So one of the things as we've been working with customers in the autonomous vehicle space, and also we are seeing this in imaging systems that show up in healthcare, but all these different applications that are popping up there, you have cameras that are capturing high fidelity images, LiDAR data, and other sources of information , and you are trying to do fusion, for example, in a autonomous system, autonomous vehicle system, you would be fusing information from a number of different search-data sources, and oftentimes all of this is coming into the same processor, or same system which is a multi-core system. It's usually resource development memory. Multiple sensors connect it. But you still want to preserve this notion for model or software architecture, and you want to still build a component based off the architecture. You want to build on that abstraction of data interfaces. So when you start doing that, how does that abstraction which make it easy to have multiple teams and maintain software, have the ability to be able to deploy that architecture one way in research and another way in production, give you, so the performance you need. For example, if I have to share an image from one component to another, am I going to make copies, and how many copies am I going to make because the number of copies that I make effects the latency of the system.

Sumeet Shendrikar: Let's take a use case here for a second to make it a little more concrete, right. You mentioned LiDAR. LiDAR is taking basically an image, a laser-based image, every period. And that period can be what, I don't know ... some number, whatever the scan rate is.

Rajive Joshi: Whatever the scan rate is, yeah. Right.

Sumeet Shendrikar: And the amount of data per scan is something like on the orders of megabytes of data. And we're talking about moving megabytes of data through a system. Now usually this is a single-board computer so it might be moving through multiple processes on that board, which have multiple nodes, multiple SoCs. But now we're talking about how do you move that efficiently, because microseconds, milliseconds, matter. We're talking about the sense percept act kind of cycle, and want to make sure everything is processed within a well defined time balance. That's the safety part and secure, and criticality part of it. So now, what you're saying is being able to move that data through is something you could do in the past with a product, but what we've done is really make that use case that much better.

Rajive Joshi: Exactly. And so what we've done is, we have cut down on the amount of time essentially by an order of magnitude. And the larger it is, the bigger the improvement. So the bigger the image ... and really, the way ... we are calling these Advanced Shared Memory Transport. It essentially gives you a constant time way of sharing very large images and very large data segments. I'll leave it at that for now.

Rajive Joshi: So this is some new technology. We've got some patents around it.

Fernando Crespo: With everything that you have mentioned so far, constant time is key because there you have your scalability thing for much later, right. So, this is really important. The time to send the data is not going to increase. And for that, we have to address the copy problems.

Sumeet Shendrikar: And the one we're talking about right now is particularly for when everything is on a single board. So you can pass things through shared memory. They do have a memory region that they can all access to. But now, sometimes that data does have to go off board, go to some other node in your system, and we have things like flat data. So Fernando, can you tell us a little bit about flat data, how that helps a use case?

Fernando Crespo: Flat data is kind of a new language binding. Think of the language binding as ... Rajive mentioned it before IDL is the way you described your data with DDS, right? So it's an interface to finish your language similar to the way you will do it in C, right? Or C++.

Fernando Crespo: So with traditional language binding, the memory representation of the data is not the same as the wire representation. So there's a translation that needs to happen in the middle that we call serialization. Some people are more familiar with the name marshalling.

Rajive Joshi: JSON. We're using Xms, things like that.

Fernando Crespo: Exactly, so there's a transformation that needs to happen in the middle just to take the data that is in memory representation, and convert it into a buffering. Into a serialized array of bytes, right.

Fernando Crespo: So that representation takes a copy. So you have to copy array down, and when the array gets really large, that takes time, and that time increases with the size of the data. So what we have done is to coalesce these two things together. So in regards to flat data we are going to have a year and a half option as a user to use a language binding in which the memory representation of the data is exactly the same representation that you would have on the wire. So what you're really doing when you populate your sample, when you populate your piece of data, is to populate the buffer. So there is no cost on serializing or marshalling, and vice ver- ... And also tied to serializing or demarshalling.

Sumeet Shendrikar: So that technology where you were talking about enhanced shared memory and the flat data, that kind of fit nicely with each other because the first step is actually storing things in an efficient way such that you don't pay that cost of serialization, deserialization. And then the next saving comes from how you distribute that, whether it's over the network or whether that's over shared memory, and you get optimizations therein. But anybody can have access to those capabilities as needed.

Rajive Joshi: Yep. Yep. Absolutely.

Fernando Crespo: And one last thing to mention is that it's also important when you have all these capabilities, that they integrate nicely with the rest of the ecosystem, right, and the platform. So these large data features that we are talking about, so they are going to work for example with The Gateway component as well as Routing Service. So Routing Service is going to be able to access the data using this kind of service.

Sumeet Shendrikar: So to continue, you said it's really about getting it onto the Databus, and anything on the Databus can take advantage of it.

Rajive Joshi: So essentially again, going back to the same idea of the databus where the infrastructure is now further optimized which is the databus, and taking care of the data. So from an abstraction point of view, it's still a data-oriented abstraction for your developers, but now the databus is so much faster and so much more optimized, and now you no longer have the issue of, as your data gets larger, it takes longer to get it to someplace because now it can optimize that as well to the limit that is possible or physical, within the constraints of the network.

Sumeet Shendrikar: And we should point out that this is, as we mentioned, the Databus which means things like our Pro product and our Micro product are both going to have support for this capability, which means if you're mixing systems together, like you might have Micro running in a particular node, and Pro running in another one, but they will be able to work together.

Rajive Joshi: Right. Right. And Micro is for resource constrained, and that's basically the basis for safety-certifiable systems, which again, is something we are seeing with autonomous driving as well as in the medical space.

Fernando Crespo: It's not only Micro and Pro, but it's also tools.

Sumeet Shendrikar: Oh right, yes.

Fernando Crespo: Our tools will be able also to access that data.

Sumeet Shendrikar: Okay. We've talked a lot about now data flow. Let's talk about the data interface itself. One of the bigger things that's in Connext 6 is a refresh, or maybe an update, in addition to XTypes and the XTypes specification which comes from our standards body which governs the DDS specifications of the OMG. Can you talk a little about what's new with XTypes in Connext 6 and why is it so important?

Rajive Joshi: XTypes is really about, XTypes stands for extensible types, and basically it governs how you define your data types or data models, and how you can evolve them over time. So there's a notion of type extensibility in XTypes specification where you can define a type such that you can create drive types. There's the notion of an appendable type such that where you have a data type which contains members. The members themselves can be extended over time, and then this container type can also be extended. And that's a new concept.

Sumeet Shendrikar: And this is sort of reflecting the reality that a lot of these large-scale systems, you can't change everything.

Rajive Joshi: Exactly.

Sumeet Shendrikar: You can only change pieces and you want to maintain ... You want to add new functionality, but you can't necessarily replace everything, so then it-

Fernando Crespo: Sometimes you cannot even stop. It's not about replacing. You can't even stop the system.

Sumeet Shendrikar: You can unplug the patient for a while.

Rajive Joshi: So these systems are nonstop. They are operational systems, and you might have deployed or shipped something with version one of the interface, and now maybe you introduce a new update. Maybe do a software update. Maybe you ship a new device, or you ship a replacement hardware, and that has a newer version of the software, right. And of course, you want this to be able to work seamlessly with the version you might have deployed previously, right, so how do you achieve that?

Rajive Joshi: That's really the problem that extensible types are solving, and so what I started describe was the different ways in which your data types can evolve. It also has support for when your data types can have new members added or removed. That's called mutable types. So, there's a number of things in XTypes specification that allows you to actually manage. And this is all coming from real world use cases where we are seeing, you know, people have these requirements. Some of these systems have shelf lives, and they might have cards or some inventory you might have shipped, and that might be sitting on a shelf for 10 years. And you might have shipped newer versions, so again, the problem goes the other way as well where you might be plugging in something you get from inventory and then plug into a system that should interoperate, right, so this is solving a very real, very practical problem in these types of systems which are nonstop. Which are operational. They have long lifetimes, and things change over time.

Fernando Crespo: Beyond the functionality that Rajive just described, XTypes is a specification that we have been supporting in the product for a long time. So I think it was introduced in Connext DDS 5.0. So users have been able to take advantage of that. That is kind of one of the key differentiators with respect to all other middleware technologies. It's being able to evolve your system without entirely stopping components, and so on.

Fernando Crespo: Now what we have done, or we are going to be doing in Connext 6, is just to pay a little bit more attention to the overhead of having that capability in place, right? So what is the overhead? What is that going to cost us, right? We are making it much more efficient, okay, the wire representation of that information that you need to evolve your system, so-

Sumeet Shendrikar: So to make it even more compact, and more efficient. Okay.

Fernando Crespo: Right, so if you want to support different versions of a type, you cannot do that for free. So you have to have some kind of metadata that goes along with the data on the wire just to indicate that. So that's what Rajive mentioned before with mutable types, right.

Fernando Crespo: So what we're doing in Connext 6, and what is describing the latest extensible type certification 1 and 2, is making this more efficient in the way we do that. So it'll take fewer bytes to do the same thing, right.

Rajive Joshi: Dan says it's important to note that those optimizations are really also in the spec itself, right. It also gives you the interoperability that's important in these types of systems.

Sumeet Shendrikar: But without the DDS implementations that may be out there.

Rajive Joshi: And between different versions of RTI implementations, and across RTI and Pro, you know Connext Pro, and Micro, and so on, over periods of time. And those are both important aspects.

Fernando Crespo: Some of the things are apart of the spec, and some of the things are RTI capabilities ... I mean they do not affect interoperability, but they will affect performance, so one of the use cases that was mentioned before is how to send efficiently LiDAR data, right. So LiDAR data is usually just simple structure with doubles or float. So to allow you do that efficiently, we are introducing new capabilities in the product that are going to speed up the way we marshall and de-marshall the data hundreds of times. So that key important capability is going to be part of Connext DDS.

Sumeet Shendrikar: Besides the extensibility ... So there's extensibility, mutability, what are these other things that are coming in the XTypes spec that are not going to be in Connext 6? So the annotations that we're going to support now, can you describe them?

Fernando Crespo: Yeah, so we are going to provide in addition to the performance improvements, new annotations. Annotations are just attributes that you can associate with a type, right. So for instance, it could mean a minimum and a maximum unit.

Rajive Joshi: Min and max, yeah.

Fernando Crespo: So, all these kinds of annotations are going to be supported-

Sumeet Shendrikar: And these go in the IDL, right? You find them in the IDL.

Fernando Crespo: And these will go into the IDL.

Sumeet Shendrikar: So what are some of the annotations that are going to be coming that are-

Rajive Joshi: Some of the ones that our customers have been asking for a long time are things like units.

Sumeet Shendrikar: Units? Okay, so what does that mean in this case?

Rajive Joshi: For instance, if I have a data type, let's take the shapes type that I think most people might have seen. I have a shape. I'm describing it by its color. The color identifies the data object. I might have a position x. I might have a position y. I might have a size. Well, what are the units of x?

Sumeet Shendrikar: Right. 'Cause it's...

Rajive Joshi: Is it in centimeters? Is it in inches? Right?

Sumeet Shendrikar: Who knows.

Rajive Joshi: Right. And that is important as we start to think of semantics, and think of semantic interoperability. So DDS, and again, I'm referencing the Connectivity Framework from the IIC, the IICF. Is the connectivity framework in the way it's described in that document, and it provides syntactic interoperably. The next level of interop is semantics, so you need these kind of-

Sumeet Shendrikar: So if have two different units, for example. If I have two applications built with the same type but different units, what happens on the wire? What happens when I run my system?

Rajive Joshi: Range is another important one, so what is the range effects? Does it go from 0 to 100, or does it go from -100 to a plus 100? If it's in Fahrenheits, it might be from -32 to you know. If it's Celsius, it might start at 0, right? So again, depends on the units and the ranges are interrelated.

Rajive Joshi: Then there's what is the default value? So Extensible Types has this notion of optional members as well. So we are supporting that, and as you define the data type and you have an optional number, what happens if it's not specified? So those are default values and you want to be able to specify that. Those those are all new things that are coming in in Connext 6.

Sumeet Shendrikar: Connext reminds me that I'm not a Ada developer, but Ada has a similar type of syntax that lets you specify your ends, and why people like Ada is 'cause is because it has that enforcement built into the language. Or if you put a range, it will say, "This is outside," and raise an exception. So, it sounds like we're doing something similar.

Fernando Crespo: We will enforce that. So if you go out of range, or if you try to compile a piece of data, to put on the network, a piece of data that has a value that is above the maximum, it will tell you that it cannot serialize.

Sumeet Shendrikar: So the safety mechanism now is ... an additional safety mechanism is defined through your data, itself, vs. anything that the infrastructure only has to learn from your data model, not something you have to specifically write into your application exactly.

Rajive Joshi: That's right. Now what also makes this interesting is that this is all discoverable as part of DDS discovery. So now you can not only discover the data type, but you can also discover what the metadata in fact, and ranges, and default values, and so on, are.

[39:54] Securing your data

Sumeet Shendrikar: That actually leads to kind of an interesting question though, right? You can discover these things. DDS is about this Databus where anything can talk, publish, or subscribe, and you can find out these details that are fairly intimate about each of the nodes. How do you prevent that from happening, though, right, if you're going to bring this into your system?

Rajive Joshi: Right. So this is where the DDS security specification comes in, and that's also, they're updates to that and essentially this is a converge release which will have DDS security spec, the security DDS specification implemented, and Connext Pro as well Micro.

Fernando Crespo: Micro. Yup.

Rajive Joshi: And the DDS security specification essentially talks about how you authenticate before you join a DDS domain, so it's ... So, to be able to discover, you have to be able to join that domain. To be able to join that domain, you have to have the right credentials, which are described as X.509 certificates in the DDS security spec.

Fernando Crespo: One of the nice things of the security spec that we have been supporting in the product since last release 5.30. Well, it was supported before, but last release was kind of the big one where we introduced Secure DDS. So, it's your capability of securing specific data flows. So you don't secure the pipe. You don't secure all the communication that goes on the network, but you can secure individually different data points...

Sumeet Shendrikar: And this came up with something like our healthcare customers, right, where they have PII, patient identifying information. Anything that has that data inside of it needs to be encrypted, authenticated, because of HIPAA rules. But other types of data, like say wave forms, or something that's a high sensor reading that doesn't have that person's information in it, doesn't have to be because it's coming at such a rate that the encryption cost may be too much. And that ability to choose when and where actually is fairly important in why you want to go with something that's on a data-flow basis.

Rajive Joshi: Absolutely. For example, if you have high frequency data, you may choose to just sign it and not encrypt it, whereas commands and so on, which may require more confidentiality. So, you can control on a per data-flow basis as Fernando said the encryption. The other thing is you can have very fine grained access controls. You could say that this application, or this participant, can only write to these topics. And this one can only read from these topics. And so you might say, "Well, a sensor cannot write command data," right? And so, even a sensor got compromised, it cannot introduce a command data. And command data would also be encrypted, whereas the sensor data ... If it's a high frequency sensor, it may just be signed, right. So you could put fine grain security controls like that, and as Fernando was saying, it's really about securing the data, not just securing the pipe. Which is very sort of traditional approach this has been. I think this is probably the only specification that goes at that level of fine grain, and-

Fernando Crespo: Yeah, and coming back to the big challenge that we mentioned at the beginning of this, the scalability challenge, so that's one more thing to worry about, right, so how do you secure your data, and you do it in a scalable model, right? So, one of the things that DDS Security is introducing is the capability for instance, of doing secure multicast. Okay? So how you send secure data to multiple subscribers at the same time without making individual copies on the network, right?

Sumeet Shendrikar: Which you can't do with any of the DTLS or TLS that's out there today.

Fernando Crespo: Right. Right. When you put all these together, I think you just realize of how complex it is to architect an IIoT system. 

Rajive Joshi: Absolutely.

Fernando Crespo: And all the challenges that are associated with that.

Rajive Joshi: Right. And that goes back to the scale part of it. So again, it's bringing together the things we're talking about in the beginning of the performance, the scalability, the fault tolerance, and the availability, the security, just so that you can build trustworthy systems that not only are safe and secure, but are also resilient and reliable, and also give you the level of privacy controls that you need. And this is something critical that all Industrial IoT systems need.

Sumeet Shendrikar: Okay. So, you both are clearly passionate. What gets you excited about Connext and DDS?

Rajive Joshi: Well, it's cool. And it works. And it's fun to work with. And it's just fun to be able to take problems that I don't know otherwise how you would actually really tackle in a way that is practical. I see a lot of people doing tar projects and research projects, and so ... But how do you go from there, where you sort of got on this, hey, this cool little thing working, to something that you can actually deploy so that people can depend on it, and life depends on it?

Sumeet Shendrikar: You can sell it.

Rajive Joshi: And you can sell it, right?

Sumeet Shendrikar: In a repeatable way, yeah.

Rajive Joshi: But people can sell all kinds of things, right. Depends on how good of a salesperson you are. But so that we can depend on it in a way that it becomes almost invisible in our day-to-day lives. And being able to do that, and having a technology that gives you not only the ability to do R&D and quick, rapid innovation and development, but also to be able to take that same foundation, and the same architecture, and then apply it for production systems, and build architectures that actually will survive at scale, be trustworthy, and actually be something that will be part of our day-to-day infrastructure and daily fabric of life. I think that's what's really the exciting part of this technology, and that's really, I think, for me, I find it just exciting and empowering every day to be able to work with this, and the people, of course at RTI that are just amazing.

Sumeet Shendrikar: Fernando.

Rajive Joshi: And to make this.

Fernando Crespo: Well to me, I think Rajive said it all, right? So, I think to me ... well first, I move myself a lot by motivation and by challenge, being challenged, and we're working on a complicated problem so this is not something simple, right? So that complication mixed with the fiber that can be applied to so many use cases, and you can get familiar with all these industries, okay, that you're not familiar with. It could be Healthcare, and now autonomous driving. But it could be financial. Or it could be-

Rajive Joshi: Or the Hyperloop.

Fernando Crespo: Hyperloop. I mean all these kind of new things, right, it's amazing how things are evolving. So that's what really motivates me on what-

Sumeet Shendrikar: I think what's interesting about the two of you, at least, Rajive, you've been at RTI for 20 ... about 20 years?

Rajive Joshi: About ... over 20 years, yeah.

Sumeet Shendrikar: And Fernando you have at least 15?

Fernando Crespo: I think it's 14.

Sumeet Shendrikar: 14. Okay.

Rajive Joshi: It will be 22 for me, December.

Sumeet Shendrikar: So both of you were in there from the very beginning of DDS, before it was even a standard, or as it was becoming a standard. And now I've seen it evolved, and the size of the systems, I think, have grown as well. So you've got this unique perspective that's says, alright this thing is making out to bigger and bigger, and more and more use cases. So it's interesting that you still have that passion after so long, because that's a long time in Silicon Valley.

Rajive Joshi: Yes.

Fernando Crespo: Yeah, It's a long time, but I think we're kind of ... If I have to pick one moment, just to be at RTI, I think it would be this one. I don't know what you think, Rajive, but-

Rajive Joshi: I think so. I think we are ... I feel like at an inflection point in the way the technology has evolved, and also where the industry is going, and with all the stuff in the IIC, and all the developments that are happening at the Industrial. And I think the technology now is mature enough. It is at a point where I think it brings together enough number of things that ... It's really solving some really tough problems, and there's really no other technology like it out there, just plain and simple.

Fernando Crespo: And as a plus, I think, you can also talk to your family about that.

Rajive Joshi: That's right.

Fernando Crespo: That was difficult for me. It was a challenge.

Rajive Joshi: Your mom test never was so, so difficult, yeah.

Fernando Crespo: What do you do? You just send data from anywhere.

Sumeet Shendrikar: I think my wife is getting there. She's almost there in understanding exactly what it is we do at RTI.

Rajive Joshi: But if you think about it, human society is really about communication, right? And now when we talk about IoT, we're talking about the Internet of Things. So the endpoints are not people, now it's machines and you're taking the humans out. And so you are starting to build systems that are autonomous. And when you talk about autonomy, you have to move up the connectivity stack and the notion of what we would call technical interoperability where, you know ... The sooner the human language at the endpoints, right, just like the telephone. It's efficient. But when you start to build algorithms and components that don't understand that common language, you have to build that common language in the architecture, and that's what syntactic interoperability is. And that's the foundation that DDS gives you because it allows you to build around data. Same thing with database and other things, so that's, I think, it's just pushing them a little further in terms of the evolution of technology because I think this is a key enabling technology for essentially everything next generation, and really Industrial IoT, and wherever it takes us from there.

Rajive Joshi: If you watch any science fiction movies or Star Wars, I like to imagine, "How do you build that architecture that you see in Star Wars," right? And you need this type of a foundation to get there.

Sumeet Shendrikar: So, thank you for listening. If you want to find out more information, you can go to our website at www.rti.com, and there's a blog post from Bob Leigh announcing Connext 6 which will also have links to the product page and to the What's New data sheet which describes a lot of the capability we just talked about today.

Sumeet Shendrikar: Rajive, Fernando, thank you.

Rajive Joshi: Thank you,

Fernando Crespo: Thank you for having us.

Rajive Joshi: Yep. Thanks.

Steven Onzo: Rajive and Fernando, thank you very much for that terrific discussion, and thank you to all the listeners out there for tuning in. Join us next week as we talk to RTI's oil and gas industry expert, Mark Carrier. If you have suggestions or feedback on this or other episodes, please contact us at podcast@rti.com. Thanks and have a great day.