DDS and TSN: Where Software and Hardware Meet for Real-Time Data Exchange

In Episode 41 of The Connext Podcast: 

• [0:32] What is Time Sensitive Networking and why is it important?  
• [4:09] Common DDS and TSN use cases
• [6:02] What are the benefits of using DDS and TSN together? 
• [13:40] Is it more relevant to certain industries? 
• [16:35] Will there be an Object Management Group, DDS - TSN standard?

Related Content: 

• [Blog] DDS and TSN: Converging Towards a Single Commodity Solution for Real-Time Data Exchange
• [Podcast] Delivering Emerging IIoT Technology with RTI Labs
• [Product Page] RTI Labs
• [Website] Object Management Group

Podcast Transcription:

Steven Onzo: Hello everybody, and welcome to another episode of the Connext podcast. I'm Steven Onzo your host, and my next guest is RTIs CTO, as well as co-chair of the Technical Special Interest Group at the Object Management Group, who are the publishers of the family of DDS standards. I'd like to welcome Gerardo Pardo. Welcome to the podcast!

Gerardo Pardo: Hello!

[0:32] What is Time-Sensitive Networking and why is it important?

Steven Onzo: Thanks for being here. Well, today's topic is time-sensitive networking, TSN for short. And I thought it would be a good topic, because there's a lot of research going on around TSN right now. So I thought we'd just start with the mere basics. Can you briefly tell me what time-sensitive networking is?

Gerardo Pardo: Okay. Well, the first thing to understand is time-sensitive network is a new standard. Basically, it's coming up from the IEEE, which is one of the same standards bodies that creates things like the wireless Wi-Fi class of standards that we all use when we use our routers, for example. Or the ethernet type of a standard that we use when we connect to our wired network. So, the idea is that it's sort of an evolution of the ethernet technology, which is again the networking hardware that you use to connect your laptops to the network - he hardwired one, not the Wi-Fi one. And in this evolution, they are intending to address real time and networking in to the same data with bounded times/rounded latencies,  - that's called deterministic traffic - and this has a broad base of applications. There are a lot of domains where this is important.

This essentially will allow this technology that has been very successful and is very widely deployed to be utilized in a set of new applications that before couldn't use ethernet. They had to use some more dedicated networks. So the importobsance, I guess you can look at it from many different points of view. I mean, some people are looking at just from the simplicity point of view saying well before, because we couldn't use the regular ethernet for real-time traffic, we had to have two or three different networks, like one network dedicated for the machine-controlled traffic, one network maybe for the video traffic, one network for more like in a file transfer, supervisory traffic, you ended up with a single system that had three networks, which means three network access points, routers, switches, much more complex, much more expensive. Much more brittle, something breaks. Complicated to deploy in terms of cabling and so forth.

In automotive, for example, or in avionics, the length of cable is already very, very expensive. The layout of the cable, because they are kind of in a space-constraint type of environment - that added a lot of complexity. So the idea was, if you could carry all classes of traffic on a single network like ethernet, then all of a sudden you remove all that complexity. But there is also the cost aspect with ethernet being so popular, meaning it has such a big market, a lot of providers are selling this. So that kind of drives the cost down and again, what people are doing today, they are using these dedicated networks for real-time traffic that are market specific. The markets are not so big, so the costs are much higher.

And thirdly, some other people are looking at it from the point of view of the performance. Again, being such a big market drives a lot of investment. Those investments result in people spending more effort and coming up with faster and more capable networks. So now you look at the technology for ethernet, we're looking at 10 gigabit ethernet or one gigabit ethernet being pretty commodity priced. On the other hand, if you look at real-time networks, there is still a stack on 100 megabits per second or lower bandwidth because they haven't been able to evolve so fast because the market hasn't been so big. So some people are looking at it just from the point of view of getting better performance for their real-time application.

All of them are kind of all really interrelated. But I would just say to sum it up, it's performance, it's cost and it's deployment simplicity.

[4:09] Common DDS and TSN use cases

Steven Onzo: Right. It certainly seems like there's a demand for it in certain situations.

Gerardo Pardo: Yes. It turns out, you know, the real driver for these TSNs came from the audio and video community and I think what they wanted to do, they were looking at home type deployments where you've got multiple speakers around the house thinking like, hey, wouldn't it be nice if we could use a regular ethernet that people are laying up on their network to also carry the audio signal. But of course, audio signal is much higher bandwidth than some other signals. It has to be well-synchronized across different speakers, because otherwise it will just distort the stereo - It won't sound right, and it depends on the length of the cable and where the speaker is located.

These required sort of real time and deterministic traffic, so they were a big driver. But when that started evolving, a lot of other industries came and said, hey, we are also having the same problem. Like automotive for example is a big user of network technologies inside the car, and now they are going to autonomous systems where their demands are much bigger. Now they're driving lighter images, video images, multiple cameras in the car, dual sensor fusion at the same time that they're doing real-time driving, steering, breaking. So all those classes of traffics are now inside a car. Rather than using multiple networks, multiple wires, you can convert them all into a single real-time Time-Sensitive Network. And that is similar to these days like machine control. There is robotics, there is, in general, these kinds of complex applications or applications that are running a control loop.

Also in energy, for example. Anything that has to run a closed loop, periodic execution cycle a hundred times per second or so really needs some very deterministic networking and TSN assets. That's all these people are now saying, hey, if this thing is going to be commoditized and is going to be there, then we're interested, we want to use it.

[6:02] What are the benefits of using DDS and TSN together?

Steven Onzo: So you use software, which is DDS writing and then in the TSN, the hardware, how can they compliment each other so well?

Gerardo Pardo: Okay, well you've kind of said it in your question. So TSN is really, you can think of it as a low-level technology. Not in a negative sense, but rather saying where it sits on the stack, right? So you start with the hardware. So yes, TSN is a lot about the hardware.

You know, what do those switches look like? What do network interface devices that you connect in your computer look like? They're going to use the same cabling. The roller ethernet cables, but they are the network interface. The nix that are in your computer and the switches have to be so-called TSN enabled. So they are going to have different hardware that allows them to segregate and watch the different kinds of traffic and do differential routing based on the kind of traffic. And there's of course some software around that as well. How to schedule these things, how to identify the different thing. But it's so-called layer two software. Meaning in the network stack it sits below the TCP IPS stack, which is level three and level four.

Now when you look at what DDS is, DDS is a connectivity framework. It's really a way for applications to communicate with each other and integrate. So it's really a software technology that sits very close to the application. The application is actually talking about the streams at the high level. We call them topics in DDS: lighter image, speed, command, pressure, power level. And it's about applications discovering where other applications on the network are and being able to send information as a structure in a manner the different applications understand. Now of course something like DDS needs to run on top of some transport. On top of some hardware. And that's what TSN provides. So of course the DDS could run on top of some other things. It can run on top of shared memory or could run on top of regular ethernet or regular TCP IP UDP networks, but it can also run on top of TSN-enabled networks.

DDS is one more transport. But it's a transport that is actually able to meet the sort of deterministic and performance needs of a lot of the DDS applications. So from the point of view of DDS, it's a very good transport to have as opposed to some of the other transports that cannot really meet the deterministic and Quality of Service needs of the applications.

Now if you look from the point of view of TSN, it gives you this great technology but it's at a low level. An application cannot really use TSN directly, because an application that communicates about data types doesn't communicate about flows and bits and bytes. It needs some kind of higher-level mechanism to do that. So it needs some abstraction layer. But this abstraction layer has to give the application the capability to specify what kind of real-time requirements it has and DDS has those characteristics built into it.

It has this whole concept of Quality of Service where you can specify things like what flows need to be reliable, what flows needs to be best efforts, what are the latency budgets, what are the deadlines. So it has all this information about what the quality of the information and the quality of the flow should be in a language that is much more natural for the application. For somebody that is providing TSN, it gives those providers a very good mechanism to expose the capabilities of that technology on an application, so that the application doesn't have to go down and talk about low-level concepts and program out tags and ethernet frames and deal with these things that are very unnatural for people who never actually do.

So anybody that uses TSN is going to have to use some software layer at the high level. And among the different software layers that you could choose, DDS seems like the best one because it really maps and is also targeting the very same class of application. If you look at where DDS is deployed, it's in those same kind of robotic systems, autonomous systems, energy systems. So there's a natural fit both in terms of what they're trying to provide to the application, and which target domains are being raised by these technologies.

Steven Onzo: DDS and TSN is still in the early stages. This is a technology that's still evolving, but is there a scenario you could think of that would highlight how it will be used?

Gerardo Pardo: DDS and TSN. Well DDS has been around for a long time, so that's not a new technology itself. TSN is pretty new. TSN itself is still not widely deployed so there's hardware already that you can procure that does TSN and there are some people that can build some prototype applications with TSN, but I don't think you can buy right now a machine or something like that which is already running and deployed using TSN.

Because of that, the combination of DDS and TSN is also new. But we're working with the Object Management Group, which is the organization that has standardized DDS on what is called the DDS TSN specification, which will be a standard that defines how DDS applications would run on top of TSN transport. And the idea here would be that, because there are multiple implementations of DDS and of course also multiple implementations of TSN, we want to be able to essentially pick and choose and say, well your application is built with this implementation of DDS, maybe from RTI, or this other application would be from an open source implementation of DDS, from a different provider and it's right on top of this network component. This switch from this provider and all those things have to interoperate and work together. In order for all those things to work well together, you need some kind of common framework, common understanding, common ways in which the DDS Quality of Service is going to map to the TSN Quality of Service or deployment configuration. So that's what this standard is addressing.

Steven Onzo: You touched on this a little bit earlier - DDS and TSN compliment each other in a way that's going to help distributed systems with performance. But are there any other benefits of DDS and TSN working together aside from performance?

Gerardo Pardo: Well, if you understand performance narrowly as latency and throughput. Yes, there are a lot of other benefits. The benefit of the deterministic, and I think people looking for TSN are mostly interested in the deterministic and write it in the proper format. The ability to guarantee that this traffic will not be delayed because this is sensitive traffic that maybe is doing the control of your autonomous vehicle and making the decision of whether you should brake or not, or to steer right or left. And that cannot be delayed because if that's delayed, then the decision and the action will come late and then you'll run over a pedestrian or you'll go off the curb or something like that. You don't want that to happen. So there's definitely the benefit of the determinism.

And then there's also the benefit of essentially having a common framework that works from the high level to a low level. As opposed to having to put together different technologies. Now you have something that works well together and gives you that unified programming environment that allows all the applications to work together - and the benefits of being a standard, right? Because, yes, you could use something else other than TSN underneath, but then you're building on some proprietary technology from some vendor - even if you run DDS on top, and you also run  some custom networking hardware on top. Well, that is not going to be so interrupted or you're going to depend on a single vendor. And likewise, you could run TSN, but if you run a custom software framework on top, you're not going to be able to leverage the ecosystem of other providers and other vendors. So having those things working together has all these benefits of them separately and plus the benefit of the coordination between the two technologies.

[13:40] Is it more relevant to certain industries?

Steven Onzo: You mentioned automotive as being one of the industries that would see benefits from DDS and TSN. Are there any other industries that could gain advantage from this as well?

Gerardo Pardo: Well, I think in general we are going to discover what those are to a large extent. But the ones that are primarily coming out now are the industries that were already solving the problem in a different way and now they're realizing, hey, we can do this in a much more cost-effective manner. And these are machine control in general, like I said: things that have to operate in a continuous loop. So you can think of a multi-axis machine that will be a machine that has multiple models. These models have to do operating coordination. Let's say you are  trying to do a cut and this cut is a cut along the curve. Well, there's going to be...maybe this is an X/Y-type model, where one motor is controlling the x-axis and the other motor is controlling the y-axis. And then by coordinating those two models, then you're creating a shape. If those models are not well-coordinated and still getting the shape being a perfect circle, you'll have a shape that looks more like an ellipse or have little ripples.

So there's a lot of equipment of this nature. Right now there is 3D printing, for example - It's very popular. All these things that coordinate between different devices - and these devices sometimes have to be in different computers - so they are controlled by different machines. You have two robots working together towards something and they have a coordinated motion, or you have different parts of a car working together or you have things like sensor fusion.

For example, you've got a camera image from one camera and a camera image from a different camera and a radar image and a lighter image and those things are all taken from the same real perspective, but they are coming from different sensors and now you need to correlate them - and in order to correlate them, timing becomes very important. So that you are fusing the right image from the camera, and not an image that you took now with an image that was one millisecond later from the other one, because now you're going to get some lack of correspondence. It would be out of focus from the camera. You can imagine what happens when your camera's out of focus: You don't get the same resolution. You get small errors.

So all these kind of situations where you are dealing with multiple devices that have to operate in a coordinated fashion are going to benefit from that. And then you go back and say, well, what are those industries? Well we know machine control, we know autonomous vehicles, sensor fusion, robotics, audio and video. But guess what? You know as this technology becomes available, a lot of people are going to start saying: Wait a minute, I can also use that. Or maybe we're going to create an application that was not possible before because we're going to have this facility. But now that we have this facility, this application becomes possible. Some new things that we haven't thought about are going to become enabled when these technologies are readily available.

[16:35] Will there be an Object Management Group, DDS - TSN standard?

Steven Onzo: I understand there is a proposal for the Object Management Group to give DDS with TSN its very own standard. Can you tell us a little bit about that and when we can expect for it to be released?

Gerardo Pardo: Right. So I mentioned a little bit before what this was about, the idea of allowing DDS implementation from multiple vendors and TSN implementations from multiple vendors to be configured in the same way, so that a common tool chain can be developed. Or a tool chain from one vendor can operate on hardware or software from other vendors. Right now, there's a standard which has been in the works for the last two years, and is now in what’s called revised submissions. So there's already a draft to standard on the table that has been out for a couple of months now. People have had a chance to review it and we're close to the final submission in December.

So the expectation is that in December we will have the final submission. And if that submission is approved, which is quite likely based on the feedback that we've gotten in the previous submissions, then it will become a standard, what is called a beta standard. And over the next year, we'll be essentially creating prototypes, getting people out there to use it and then provide feedback so that one year later we will have what's called final ISO standards.

So basically we will have a beta standard sometime next year and then one shortly after that. By the end of 2020, we expect to have a version 1.0 finally available as a standard. That doesn't mean that vendors, once the document is approved, are going to start working towards this document. Oftentimes there is very little change between the final version and the beta. It just depends on how well it was written and how well it meets the requirements once people actually try to deploy it, and multiple vendors start to deploy.

Now we have already been working on this. We're one of the main authors of this standard, of this draft standard I should say. And we haven't been doing this on the backend. So we're working with TSN providers and with end users and they've been giving us feedback on this specification and we are creating a prototype that we're going to be demoing later this year before December. So it will help that the idea that we're specifying in the standard is based on something that is implementable and that meets the requirements of at least the classes of applications that we've evaluated.

Steven Onzo: I think that's a great note to end on. Gerardo, thanks for coming onto the podcast. I really hope you'll come back and talk more about future technologies that are in the works.