IIoT 101: What is a Databus?

In Episode 49 of The Connext Podcast:

• [0:14] What is a databus? How does it work and why should people care?
• [3:18] Can you talk about what that paradigm shift that Connext DDS takes on and the best way to understand it?
• [5:44] What is a layered databus and who uses them?
• [8:50] How do new technologies like 5g or even 6g affect the databus?
• [15:18] Do you have a favorite use case?

Related Content: 

• [Blog] Connext DDS and the Industrial IoT: The Top 5 Things to Know
• [Blog] Digital Transformation Revisited: The Promise of Things to Come in the 2020s?
• [Blog] What is IIoT? The Industrial Internet of Things Primer
• [eBook] The Rise of the Robot Overlords: Clarifying the Industrial IoT
• [Podcast] Clarifying the Industrial IoT

Podcast Transcription: 

Steven Onzo: Hello everybody, and welcome to another episode of The Connext Podcast. Today I'm here with Bert Farabaugh, Director of Field Application Engineering, and today we're here to talk a little bit about the databus. Bert, thanks for being with us.

Bert Farabaugh: Sure, no problem.

[0:14] What is a databus? How does it work and why should people care?

Steven Onzo: So I'd like to take a little bit of time to talk about the databus. I know plenty of people have heard of a database, but a databus is actually its own thing and very unique. And it's actually the architecture that Connext DDS is built on. So, can you start off by telling us a little bit about what a databus is, how it works and why people should care.

Bert Farabaugh: It's interesting that you already mentioned database in that regard, because almost everybody knows what a database is. Everybody who works or lives in some way, shape or form has to rely on a database to work. You go to the airport and you get a ticket for your plane, all of that is being done through a database of what seats are available and what the pricing is and everything. And so that technology of using a database has been around for a very long time because it works very well, and it works very well because it's centered around the information itself. 

But that information in a database is all information that is fixed and in place, but wouldn't it be nice if you could take that same paradigm of that data and put that data in motion, as far as applications that are live doing real-time control of various things. Whether it's a vehicle, or whether it's a patient-monitoring device, or whether it's a wind farm or a windmill of some kind, wouldn't it be nice to be able to share that information across applications, as opposed to just between terminals and people working at terminals? That's what a databus is; it takes that content and moves it in motion. 

You subscribe to information that hasn’t already happened, but you're subscribing to information that's going to happen. Your application’s subscribed to that information that's going to happen in the future, so that they can probably make a valid decision on what the next decision is supposed to be for dealing with that incoming data, and then they can generate output data and status information and tracking and all of that. 

So a databus in essence is a virtual concept of live information that's being shared between applications, and that live information is dissected into elements called Topics - and those Topics basically represent the essence of what that application is trying to accomplish.

Steven Onzo: So you could say one of the biggest differentiators of a databus and a database is that with a databus, we're talking about data in motion. That seems like the key word there.

Bert Farabaugh: It is. It's what is going to happen, as opposed to what has already happened. That's what we call data in motion. It's what is going to happen. But in a database you have tables of information and you have, inside a table, columns that define the information that's inside that table - and in a databus you have Topics, and those Topics are defined by a structure of fields of information. It's very similar. It's just information that's happening, live as opposed to information that already happened.

[3:18] Can you talk about what that paradigm shift that Connext DDS takes on and the best way to understand it?

Steven Onzo: Traditionally, systems would send messages to a centralized broker or other technologies alike - DDS works differently, and takes on a complete paradigm shift in terms of how the data is shared. Can you talk a little bit about what that paradigm shift is, and the best way to understand it?

Bert Farabaugh: That paradigm shift is really going from a centralized thing like a database as a centralized broker that's holding information. DDS's paradigm shift is that it's taking that into a peer-to-peer architecture, meaning the sources of data are actually directly connected to the elements that want to receive that information to make a valid decision of what their next move should be, what their next control element should be. And if you put something in the middle, a broker or a database or something in the middle that collects all the information and then sends it out - now the busier that your broker gets, the harder it is for it to send its information out. When you need it the most, it actually becomes less effective when you're sending more data. And that's usually when you need it the most. 

With DDS allowing you on a databus to connect peer-to-peer, meaning sources are directly connected with their reception points, you don't worry about that thing in the middle - that middleman that's really just collecting information and sending it on. And DDS takes care of all that complexity for you. So in essence you get the simplicity of the programming by just publishing data to a Topic, and subscribing to that Topic. But DDS takes care of all that connectivity and all that peer-to-peer infrastructure.

Steven Onzo: So getting rid of that middleman, is that what we mean when we say we're eliminating that single point of failure?

Bert Farabaugh: Absolutely. Getting rid of that middleman, it's not only a single point of failure, it's a single point of non-deterministic delivery of data. It's also now a single point of security risk. So if somebody hacks into or gets into that broker, they now have access to every element that's connected to that broker. And so by distributing that, in distributing the security and distributing the data flows themselves so that applications are only working on the information that they care about, it completely decentralizes the entire thing. And so, no single points of failure in any way, shape or form

[5:44] What is a layered databus and who uses them? 

Steven Onzo: For some of our customers to really optimize their use of Connext DDS, they utilize what we call a layered databus. Can you tell us a little bit about what that term means and the importance of a layered databus in a distributed system?

Bert Farabaugh: So a databus, as I've described, is a way for applications to share information. Well, there are cases where not all applications need to share all information. So take for example, in the new world of autonomous cars, inside the car, you have the actual vehicle control itself. The steering and the braking and the knowledge that there is an obstacle in front of you, or that you're going to be making a left hand turn or a right hand turn coming up. All of that control is localized. 

Well if you wanted to also share information from that vehicle with other vehicles, say within a quarter-mile radius of you so that if you're experiencing black ice, and your wheels are slipping, you might want to share that information, but they don't need to know that you're trying to steer the car to the right or steer to the left, or something of that nature. So the information that is relevant for the elements that are collecting that information belong on a databus, but you may need to layer it - add more databuses, so that at different layers they can get the information. 

So you can have an example of the car and then you can have another databus where vehicles, cars themselves within a quarter-mile radius, are communicating with each other. And then you could add another layered databus on top of that, where you're sending information from your cars, from the speed of what their traveling and their positions, to a traffic management system. And so you can share data at that now new layered databus that you have at the top. And then if you have a fleet of vehicles, trucks that are out delivering packages or whatever, then you have another databus that can happen all the way at the top layer where you can do fleet management. 

So it's all about, each layer is really about the information that's relevant for the task at that particular layer.

Steven Onzo: How common is using a layered databus among our customers? Does everybody use them?

Bert Farabaugh: No, not everybody. Some people just have a very localized real-time control task that they have in front of them, and they use a single databus for that. But there are lots of applications also. So more than 50%, probably closer to 65%, of our applications use a layered databus approach in some way, shape or form. Is it safe to say that the more complex a system, the more likely you are to use a layered databus? Complexity is interesting. It can be very complex without a single layer. It's more about scalability. It's more about the scale of your system and how you keep the relevant information going to the appropriate levels of your application that you need to make valid decisions.

[8:50] How do new technologies like 5g or even 6g affect the databus? 

Steven Onzo: So although DDS is far from a new technology, you hear about new emerging technology in Silicon Valley on a weekly basis. Where does DDS fall among new technologies and fads today? I know 5G is a popular buzzword, but I've also heard of 6G. So how does this affect the databus?

Bert Farabaugh: So the databus is not a fad - It's a concept, and it's really just the migration of an existing concept that has been around for decades and decades. Databases have been used since the beginning of computers and computing has been happening. So it's not a fad. Now, you talk about things like 5G or even 6G as far as increased capacity of your network - well those technologies can actually gain the benefit of a databus, because a databus can now share more information across various layers, or between layers if they need to. And the more information you can share, the better decisions your applications can make - as opposed to people making decisions, this is your applications, your computing applications, the better decisions that they can make as they go forward. So yes, it's really more of a complimentary thing or an enabling technology that helps these other fad things or these other technologies really shine.

Steven Onzo: And it speaks for itself too, based on the fact that Connext is running in a lot of soon-to-be autonomous systems that until then are monitoring and optimizing data to one day become fully autonomous.

Bert Farabaugh: Oh, without a doubt. We've been doing autonomy for a very long time. My personal experience - I had worked on an autonomous vehicle back in the mid-nineties. So we actually had a car about the size of a small Volkswagen bug that could autonomously drive around a facility and take pictures. And that's what its whole job was, to drive around the facility and take pictures all the time. But this thing could navigate itself and it used very old technology. We didn't have something like a databus back then, and... Sorry if I'm going off.

Steven Onzo: No, no, no. This is interesting, go ahead.

Bert Farabaugh: So we didn't have something like a databus back then. We just had, what is commonly used by almost everyone out in the software world when they want to do networking, is they use a thing called a socket. It's either a TCP or UDP socket. It's the rawest form of communication, and in fact, the databus leverages sockets underneath, but it puts a whole layer on top of it to make it much more easy. 

The building of this system was so difficult, because we had to make sure that every little piece was actually set up appropriately - and if one piece was wrong, that vehicle would go off track and it would go maybe down into a ditch, which is not good. If we had a databus where we actually centered the application around the data itself, our development time would have been cut by a factor of five, literally by a factor of five, by having a databus in place. So I don't know if that answered your question there.

Steven Onzo: Maybe we're going off a little bit off the beaten path right now, but it's an interesting topic. So you mentioned sockets, so prior to the databus you'd have to build sockets to communicate to a...

Bert Farabaugh: I would say 70% of the customers or prospects that we talk to today, they use sockets today, still do communications.

Steven Onzo: How does that work? So anytime you add a new piece of hardware or a new application, you'd have to custom-build a new socket?

Bert Farabaugh: Yes.

Steven Onzo: And add that, and custom add that, and all that work?

Bert Farabaugh: Yes, and that socket is only going to send data from source to reception point. It's not going to take care of any Quality of Service. It's not going to take care of any enforcement. It's not going to enhance it with any security. You have to custom-program all of that, if you want to have a robust system. And so a socket is just the smallest form and the layer that you use to do communications. Anyone that gets a software engineering degree, they know how to program to a socket. So that's why there's a lot of applications out there built on top of sockets, but DDS just greatly enhances the use of those.

Steven Onzo: Do you find that our prospects/customers in this odd space where they realize that this is an antiquated way of doing things, but they also have this side of them that's like, "This is a very mission-critical system, and it works great the way it's working right now. We really don't want to tamper with it." What's our solution for customers who say that?

Bert Farabaugh: It's very interesting - sometimes we go in and we'll talk to a customer, and they'll present to us what they're doing - and it might be based on the socket type of application and then we talk about how DDS could help them do this, and then help them do this other part of Quality of Service and data durability and data reliability - and life span and content filtering - and we just keep going and going and going. And they realize, "Wow, I'm having to spend all my time having to program each one of these things custom every time. Why should I have to do that?" So some get it right away - you can literally see a light bulb go off in their head when they understand the value of what DDS brings to them. 

And then there's others that are so entrenched in what they do, they feel like they cannot change. And it's interesting to see. Sometimes what they will do is - they can see that DDS might be something towards the future for them, but they don't want to touch what they currently have in place and so they'll bring DDS in to maybe enhance future capabilities for their system. But they will leave the old stuff on their current technology. 

We saw this happen with one of our accounts actually, they brought DDS in, and it was only supposed to be doing about 10% of their application - and 90% was on the old technology, which was based on COBRA, if you've ever heard of CORBA. They had their whole thing, their whole application built on top of CORBA, and within three years that ratio switched. So it went from 10% on DDS and 90% on CORBA to 90% on DDS and 10% on CORBA, because there's that last 10% that they really truly couldn't just get rid of.

[15:18] Do you have a favorite use case? 

Steven Onzo: It's actually a really good segue talking about use cases like that, because as the conversation winds down, I'd like to ask you about one of your favorite use cases that really highlights the benefits of a databus.

Bert Farabaugh: I would have to say one of my favorite use cases is really the patient-monitoring use case where you have sensors that are hooked up to people, whether it's measuring blood oxygen level, or your blood pressure, or your heart rate, or anything of a patient that's in a hospital. If you've ever, unfortunately, had to spend any time in a hospital or visited somebody in a hospital, you see all the machines hooked up to them. Well, what happens is, and if you've ever noticed these machines sometimes they... A sensor goes bad, and so it starts to beep all the time. Or one of the values is no longer in the right area because it's fluctuating, because the sensors are in the wrong spot or something of that nature, and it starts to beep, or the...Oh, what's that called?

Steven Onzo: Seems like something's always beeping in a hospital.

Bert Farabaugh: Yeah, I mean there's definitely always something. I'm trying to think of what that one piece is called. It's the blood drip... Not the blood drip.

Steven Onzo: The IV?

Bert Farabaugh: The IV. So the flow of the IV. Sometimes the IV, the hose gets cranked and so that thing starts to beep. But in essence there's always something going off inside the hospital, and so nurses and doctors - they hear that so much, they become immune to it. By bringing the sensors in the systems together in the hospitals - such that they can now track all the information - they can actually be automated in how they track that information, so that when an alarm actually goes off, it actually is a true alarm, so that they're actually coming in and actually working on that true alarm. 

Also the infrastructure - by using DDS for patient monitoring, it now enables any nurse, any doctor, anywhere in the hospital, to get live data from any one of their patients. So it gives them a freedom of care, a freedom of being able to care for any given patient at any time in their hospital, or even outside their hospital. And that's what I think is one of the truly great applications that we're working in today. I'm very excited about autonomous drive too, but I really love the patient monitoring example.

Steven Onzo: Excellent. Well, I think that's a great place to end, but I want to thank you again for coming onto the podcast and shedding some light on what a databus is and all of these use cases. It's really been really nice. Thank you.