What it Takes to Secure & Safety Certify an Autonomous System

In Episode 46 of The Connext Podcast:

• [0:48] What is it like to be a part of the safety aspect of autonomous vehicles? 
• [2:45] What does the word “Safety” mean to RTI beyond the traditional definition?
• [4:37] What is RTI doing with respect to Safety? 
• [6:10] The importance of safety knowledge for autonomous vehicle developers 
• [10:44] How to solve the need for safety certification from a technology perspective
• [19:21] The most common business challenges that we’re currently seeing in the industry

Related Content:

• [Blog] Connext DDS Micro is Huge for Developing Autonomous Vehicles
• [Datasheet] Connext DDS Micro
• [Case + Code] Accelerate Autonomous Car Development
• [eBook] The Rise of the Robot Overlords: Clarifying the Industrial IoT

Podcast Transcription: 

Steven Onzo: Hello everybody and welcome to another episode of The Connext Podcast. Today I'm joined by Sr. Product Manager, Niheer Patel. You know him from many previous episodes of The Connext Podcast where he discussed topics that range from new RTI product releases to even measuring performance metrics of Connext DDS. He's really our Connext podcast advocate/champion and we're happy to have him. Welcome back.

Niheer Patel: Hey, thanks. Happy to be here.

Steven Onzo: The topic for today is safety, specifically safety in regards to Connext DDS in automotive platforms for autonomous vehicles. That's safety markets, the level of safety within those markets and even safety certification. It seems a little overwhelming.

Niheer Patel: It is.

[0:48] What is it like to be a part of the safety aspect of autonomous vehicles?

Steven Onzo: But we're going to break it down into digestible bites and actually find out what the term safety means in this industry and why it's so crucial for autonomous vehicle development. But before we dive into the deep end of the technical swimming pool, I'd like to inch our way in through the shallow end, sort of get acclimated, feel the water.

Niheer Patel: That's a good idea.

Steven Onzo: As you know, the deep end can be a very complex and technical place. I want to start off by asking you what it's like being a part of this market revolution and more specifically being a part of the safety aspect of what will one day become a reliable network of autonomous vehicles out on the road.

Niheer Patel: Yeah, definitely. Absolutely incredibly exciting time for the industry, for RTI. A lot of this is really transformational for individual lives, for us as a company. We're doing a lot of really cool things. When we think about these huge transformations, the invention and rollout of the Internet, I remember the time before the Internet. Maybe I'm dating myself here, but it's huge how far we've advanced in 30-40 years. Cell phone technology, right? I mean, I had the flip phone. I had the brick back in the '90s and now it's just so ubiquitous, right? Self-driving cars. Right now we think of automotive as we get in a car, we drive ourselves, we drive our loved ones and we are inherently responsible for our own safety. But now with self-driving cars, we are relinquishing that to technology.

It's really humbling to think that the software that RTI puts out, the vehicles that our customers are going to roll out, all are really addressing how to keep people safe as this kind of new world unfolds.

[2:45] What does the word “Safety” mean to RTI beyond the traditional definition?

Steven Onzo: Like I said before, let's take it slow and begin by doing some defining. In terms of the automotive markets that RTI is involved in, what does the word safety mean beyond the traditional definition?

Niheer Patel: Very good question. Very tough question. Safety is a very layered complex term. At the high level, what it amounts to is the protection and the appreciation of the sanctity of human life. The appreciation and protection of property and property that belongs to people. Trying to keep them safe, to prevent harm from befalling people we care for. In many cases though, when we build things, we may not know who our end user is. At RTI, we develop software that our customers then roll into vehicles. They may know better who the individuals are that are using their vehicles. But how do we do the right thing to ensure that end user's safety?

Fundamentally, and this is if you get into the safety culture, especially for automotive, but really for any industry that has something to the likeness of a safety standard or certification process, this amounts to a culture. It's a mindset, especially when we're trying to innovate quickly and build new things. How do we take the time to think about what is the implication of writing this line of code? What are the possible upsides? What are the possible downsides? It's really hard to get out of that development environment and think about something that really amounts to a philosophical topic, right? That's human life.

[4:37] What is RTI doing with respect to Safety?

Steven Onzo: That's actually a really good segue because the next question I was going to ask you is what RTI is doing with respect to safety on RTI's side? What's the goal that RTI's efforts are reaching for?

Niheer Patel: Okay, RTI has made no secret of the work we're doing in safety. On the avionics side, we have developed safety evidence with our partner Verocel. We've incorporated it into safety critical systems for avionics. There's a lot of parallels now on the automotive side, right? That is largely defined at least as far as RTI is pursuing at this time in the ISO 26262 safety specification. There is another specification called SOTIF and that's safety of intended functionality that our customers are using heavily and that we try to support at least starting with the ISO 26262 software safety specification. What are we doing more specifically?

We are taking our DDS implementation, so Data Distribution ServiceTM, our core foundation of our product, taking our Connext DDS through safety certification according to the ISO 26262 standard to ASIL D. That's the Automotive Safety Integrity Level, which is, you know, what level of safety do we achieve, what level of risk are we mitigating? We're pursuing the highest level of risk mitigation there, so the highest level of safety.

[6:10] The importance of safety knowledge for autonomous vehicle developers

Steven Onzo: I think it's interesting, you mentioned this just a minute ago, that we're making the software and then we hand it over to our customers who then are doing a number of different things. RTI certainly has a good idea of what safety means. We have to build that into our software. Is it just as important for our customers to know what safety is? Also, what are the best resources they could find to actually understand and make sure they're looking eye to eye?

Niheer Patel: This is great. This brings up a great point, which is safety is a community effort. We have a good idea of safety for our software. But then when it comes to an OEM putting together a vehicle, they have to be the safety experts for that and we help fit our software into their vehicle. The great thing about RTI is we have this services organization that really knows how to architect from a data model perspective, how to architect these mission-critical systems and as an extension, safety-critical systems based on our software. However, there's also the electronics, the hardware...the mechanical aspects of safety. It really becomes a community effort. An OEM, a Tier 1 supplier with their vendors, work together with industry safety experts. There are experts that know safety inside and out.

They dedicate their lives to this. Leaning on them heavily is what everyone should strive for. Now, this isn't any kind of endorsement. I don't want to endorse any particular service vendor, but a couple folks we happen to know. First of all, every customer listening to this should really look at who can provide them the best level of service. There's a business aspect of costs that they have to consider, and actually maybe I'll make a point on the business side again if we have a chance, on how you gel with that service provider because you need to be able to have a solid relationship so you can focus on the safety aspects. There are companies like LHP, Mira, Exida. All of these are service companies. There are others. These are the ones that I'm personally familiar with.

We work with a company called Verocel. I mentioned them before earlier in this podcast that they helped us with the avionics side. They have a certified process and they're working with us in the same way we did avionics to help us get to the ASIL D certification for automotive.

Steven Onzo: Who do you think needs to have the highest level of safety knowledge when it comes to that customer side? Is it the developers or is it maybe people on the business side or is it both?

Niheer Patel: The short answer is everyone. I mentioned culture. The customers we've talked to, they train everybody who comes in to different degrees certainly. We have the concept of an operations department. Operations to keep the company going. They get some level of safety training. They at least get the insights into what safety means. Maybe it's at the level that you and I are talking about today, but then you go on into research & development, if you're working on the software, you need to know the safety processes for your product inside and out so that you're following it. Learning how to run the tools. Maybe it's static code analysis or maybe it's a test suite. A test harness, some traceability. There's a huge level of training there. It goes throughout.

The whole management chain needs to have this appreciation for safety. There has to be this cultural appreciation for safety. Otherwise, there could be some blind spots. Well, maybe pun intended there. It's really trying to make sure that safety is one of the top considerations for putting out a product the way you would think about just general quality or usability. Safety is maybe an extension of quality, but really it is its own aspect. There are companies that have organizations dedicated just to safety and that goes above and beyond quality.

[10:44] How to solve the need for safety certification from a technology perspective

Steven Onzo: We talk a lot about the different aspects of safety. We started off talking about the philosophical aspects. What is it? What it should be. All the way to ethics. What is this going to look like? Even the business side. But one big aspect that RTI focuses on and is trying to solve is the technology perspective. Can you talk about how that's done? How is RTI solving things from a technology perspective?

Niheer Patel: Before I get there, let me take one more step back and just kind of break down safety in my mind based on my experience in working at other companies that do safety work and then, of course, at RTI. There's one aspect which is just making sure software does what it's supposed to do and that we're communicating to our customers how to use the software in the right way. That's one part of it, but then there's this idea of functional safety. Does the software have features to help ensure safety? From potential errors, errors that are outside of the control of the developer, for example. That's important too. All of this comes together on the business side too. Maybe the ethical side too where we talked about protecting human life, but even on the business side, there's a consideration that's not mutually exclusive from appreciating human life, but that is appreciating the risks to the business and the liability.

It's important to keep all those in mind. These are all layers of safety. Now we're getting kind of to the more technical layer about what RTI is doing. This does not by any means preclude what other companies, other suppliers have to do for safety. What we're doing is taking our software through safety certification, but the way our software is used, and maybe this is really more of the point that we would want to discuss here, is at the end of the day, we have to go through the same types of processes. The ISO 26262 standard lays out the types of work that needs to be done. That doesn't really differ from other companies, how we do it exactly, the different tools, things like that. But the way our software would be used is to help with communications within the vehicle.

Fundamentally, that's what Data Distribution Service does within distributed systems is help disparate machines or applications talk to each other effectively, help isolate applications so that there's flexibility in making updates at a lower cost, really driving efficiency in those data flows and, of course, meeting performance requirements. Safety. In the vehicle, you may have communication networks, but to safety-certify those networks can be really expensive. What some folks do is they go down this path of implementing or treating their networks like a black channel. Black channel is anything between two nodes, two computers, two applications. We treat it as unsafe, which it's not safe, right? We're going to put some data out there, how do we make sure that that data when we receive it is good to use?

How do we make sure we receive it in a timely manner? How do we know if it's not going to come or if it's coming later? Inherently, in the RTPS protocol, which is that core protocol within DDS and kind of the foundation of Connext, a number of pieces of information like the sequence number, for example, and the way that sequence number is treated when we receive data. Let me actually pause there because I'm getting really excited about a lot of the technical details, but let me backup and talk a little bit about the errors that could arise.

If you think about this packet that goes across, that data packet gets corrupted. It could come out of sequence, right? Because we have a message that we break up and then we ship it over the network. Now when it gets routed, sometimes the receiver will get information out of order and has to put it back in order. It could be possible that that information is just delayed. It could be possible that someone inserts some information in an attempt to spoof data or to cause some sort of denial of service. That's where security comes in to help bolster that safety story. Again, these are autonomous vehicles. They're connected. They are susceptible to attacks the way your laptop or your phone is.

With things like the RTPS message, the protocol and the information that's contained in the header, the way the RTPS packet is managed based on the spec. This is how it's defined in the specifications, so it's nothing that any one of our customers, our audience could check themselves. In addition to some things like some sort of integrity check, like a CRC, these are things that are on the functional side that allow customers to use our software and protect against those communication errors that nobody would have control over because it's just not deterministic or it's not financially viable to certify that network. Sorry, that was a lot, but it's really, really exciting that just inherently the RTPS protocol can solve a lot of these problems.

Steven Onzo: No, it's really interesting. The notion of safety certification isn't anything new. You do safety for avionics as well. We had this conversation earlier about any commercial plane that's running right now, say from San Jose to Phoenix, has software in it that had to have been tested. This is not anything new. There are safety certifications and there is testing that needs to happen. But now we're doing it for vehicles on the ground and this is kind of a new thing. Can you talk about how those are sort of the same, those two processes?

Niheer Patel: Sure, it goes back to, hey, it's protecting them in life, right? One of the big differences is for avionics,  automotive volumes are very high. Making sure we address them appropriately, accordingly is important. The good thing is that fundamentally a lot of the processes are very similar. It's right requirements, trace it to design documents, trace it to your software code, and then trace it back up through test cases and test code and to the test results and have that level of visibility that you can say “hey, we've tested everything”. We've tested all execution pads in the software. We have no dead code. We have no software that could behave differently in different scenarios without an intentional input. A lot of the similarities there.

Now, some of the differences are very nuanced. It really comes down to how the software is delivered. With avionics, you have to know down to the exact piece of hardware and you have to show it to a regulator. You have to prove to regulators that your software is safe. It does exactly what it needs to do. But really that's all in the context of, as you mentioned, the plane. It has to be part of that full system. We can't certify our software. We can help our customers certify their system. Automotive, we have more flexibility because we can certify to a particular architecture. As long as we provide some sort of analysis, do some sort of hazard analysis, make sure we know what the possible ramifications are of using software that was tested on one platform, on a particular architecture may change.

What are the implications if we moved to a different piece of hardware with the same architecture? Things like that. It's fundamentally every decision we make. Any change we make from a very known state, we've done the right level of analysis to see what the implications are and whether those are acceptable or if we need to go and do another level of testing.

[19:21] The most common business challenges that we’re currently seeing in the industry

Steven Onzo: I have one last question for you before you take off. I know everybody says this, but it's true. This is a market that isn't very well defined yet. There are a lot of gray areas. There's a lot of details that need to be ironed out, but that's part of the fun of creating a market revolution. That being said, what are some of the most common business challenges that we're currently seeing in the industry and trying to solve?

Niheer Patel: Great question. I think we're going to learn a lot more about this as these vehicles hit the road. I’m speculating, of course.  Historically for automotive, the biggest piece is liability. We've seen some with the traditional automakers, traditional vehicles. If there's an accident, typically it's the OEM that takes the brunt of it, even if maybe the financial part of it is spread out. I don't know. But you check out the headlines, it's going to be one of those automakers. From our perspective, we certainly want to help reduce that, because their names in the headlines don't help. Maybe it helps in the sense that it kind of raises awareness, but trying to minimize the need for that is within the scope of what we can, and is my goal for the company. What else? This is maybe more of a technology challenge, but it has business implications and that is how we build these vehicles to last. How do we build them so that we can evolve them over time?

We can provide continued value to riders, to passengers or to fleet managers or whoever it may be, whoever's the stakeholder. How do we continue providing value without having to go in and build a brand new car. We'll see some companies who have updates. They put out a model of a vehicle and then they can continue to update the software and build out the level of autonomy for their vehicle without actually having to put out a new vehicle. That evolvability of the system has huge business benefits, because you're reducing the cost and increasing the value of your particular vehicle platform, or in our case, the software we provide.

Steven Onzo: That's an interesting point. Do you think that autonomous vehicle developers can learn from other distributed systems who may have not originally built a very evolvable system where they're constantly maybe adding bridges and different channels that we can learn from that and just make something that is…

Niheer Patel: Absolutely, taking the safety part out of this, I know it's a safety podcast, but I'll put it on the side for a minute. We look at things like smart phones, we look at things like cloud computing, how we can continue to add some of these like microservices or these apps. We can continue to add value there, but we're not making a customer buy a new phone every time they want to get a new app. They can remove an app. They can add apps. They can store data for an app, like photos for example or podcasts, all without having to then go and upgrade the hardware. Sure, there's value in upgrading the hardware because I can store more photos or so forth. Yeah, as autonomous vehicles roll out, they may have started going like five miles an hour and now they can hit freeways and, and drive 40-50 miles an hour.

Depending on the autonomy level, you can drive vehicles on the road. You can drive them the same as any other vehicle and they still have some level of autonomy that can kick in like plane detection and kind of obstacle detection.

Steven Onzo: It seems like it's one of those things where you can't plan for every single instance that's going to happen. As you said, we're going to learn those things along the way, but you can certainly try your best. At least when it comes to safety, you make sure everyone's going to be okay and then learn the other things along the way.

Niheer Patel: To that point, our customers, what a lot of them are doing actually, if not all that we can talk about, they may not be able to predict it. But they can have the right safety measures in place and then go and learn it. You'll see all these autonomous vehicles on the road already. Here at RTI, we can look out the window and we see some driving by, but there's a driver there. There's somebody to take control. What we're seeing is that they're driving and while they're driving or the car is driving, they're there to make sure the car doesn't do anything it shouldn't. The car learns the AI algorithms. They learn what the right thing to do is, what the right response is, what is okay and what is not okay. They learn about the environment. They learn to detect different types of objects.

That's how we get ahead of not knowing what the potential disasters or issues might be, right, is we do a lot of this training. Before we start our career, we go through a lot of training called school or elementary school and so forth. In a similar way, we train these models so that when they go out in the real world as an adult, adult self-driving car, they know what to do.

Steven Onzo: I think that's a great place to end. I think we covered the multiple layers of safety and really this industry does have multiple definitions and there's a lot of different angles to it. I want to thank you for helping us break it down.

Niheer Patel: Yeah, thanks for having me. It's fun to talk about and it's definitely a really exciting time.

Steven Onzo: Thanks again, Niheer, and we hope to have you back soon.

Niheer Patel: Absolutely. Thank you.