Software Defined Vehicles – Bertrand Boisseau, Canonical

This is texturing TV. Hey guys. Thanks for the throw.

We're here with Bertrand buso who is Automotive lead for canonical and we're talking about building software for software defined Vehicles, which is one of the more challenging things you're ever going to see in the land of devops Bertrand. Welcome the show. Hey Mike.

Thanks for having. What exactly is different about building software for a vehicle per se because there seems to be two classes of these things one is the sophomore that's embedded in the vehicle itself. And the other is the software that arrives over the air after the vehicle is constructed in on the road.

So what are you hearing from folks about the challenges and what exactly you guys up to in this space? That's that's the first of all that's a great question when you look at automotive and what a vehicle is today. It's not a single device.

Right? So we tend to say it's a computer on Wheels but a vehicle today has hundreds of ecos. So electronic control units basically hundreds of computers.

And that's I think what led to the suffer defined vehicle Trend which tends to well aims to simplify this super complex architecture that is embedded in the vehicle. And that is trying to I would say API if I the whole vehicle if that makes sense. So as part of that effort do I have to write really tight code because how much space do I have in an ECU?

How much memory do I have each car has I don't know 50 60 hundreds of ECU. So how do I write software that spans multiple ecues? What are the issues?

So well, first of all, we need to take into account the fact that all the ecos are in equal you're gonna have tiny sensors and microcontrollers to a super performance on dedicated to automate autonomous driving processors. So it's really a stretch and on top of that you need to take into account the fact that the vehicle. Well, it drives people it drives humans.

And this means that you need to take into account safety. So not only cybersecurity which you would expect from regular software but also functional safety to ensure that the safety of the passengers safety of the the pedestrians around the vehicle is guaranteed. It's way more complex.

I would say than writing. I would a regular application. each vehicle seems to have multiple ecu's made up of multiple processors and writing software for different Hardware platforms as hard enough and traditional it world.

Are we starting to see something that feels like maybe a unified obstruction that makes it easier to write all these different processors. How much progress are we making? So I wouldn't say there's yet a unified abstraction.

There are Trends and and clear approaches that everyone is trying to follow because it seems to be the the best way forward. What is clear is that? We need to simplify the way we develop which means also that we need to anticipate whatever Hardware we're going to have in the vehicle.

And this kind of to answer your initial question. This will also mean that the developers and Engineers have to rely on. Well defined ci/cd pipelines and on cloud Frameworks that can enable them to start developing on the cloud first and then pushing those those software features in the vehicle or on their development benches and Boards.

So once once you say that, how do you how do you efficiently emulate the performance and interfaces remotely on a cloud environment? And how do you emulate whatever's gonna end up being in the vehicle? Because in the vehicle you're gonna have tons of data that is transmitted from an ECU to another that is potentially saturating your your network and your gateways and this is also something that we're working on with Partners to make sure that whatever you work on remotely on a cloud framework really emulates as close as possible.

Whatever you're going to have in your vehicle. So this is typically what we call environmental parity. mmm You guys just join the eclipse Foundation.

They have a working group in this area. And what's the thought process behind that? Right.

So we believe that consortiums will help us learn and grow so learn in terms of what are the specific constraints that the automotive industry is facing. But also what are the best state of the Arts approaches that we need to to follow? I also believe the economical comes with well almost 20 years of Open Source software experience with the best of the best.

And that we can also bring to the table that expertise in terms of reliability in terms of in terms of security in terms of how we push over the air updates to millions of desktops. But also how we run. For like 70% or even more of 70% of the public Cloud instances run on Ubuntu Server.

So if I went to server wasn't relevant it wouldn't be the case. Right? So I do think that we can bring that sort of value to the table and also probably all the cloud native approaches that the oems in tier ones are trying to put in the vehicle.

This is something that we can we can help with. One of the challenges you see is it seems to me at least that by definition the applications that you're building for. These vehicles are event driven.

It's never been easy to build event driven applications. And now we're trying to build a vent-driven applications for a car that's moving that's connected back to various cloud services. So it doesn't seem like these are easy applications to build.

So do we have the skills to actually go do that or is there in general shortage of developers who know how to build these things? Well, first of all not all of the use cases in East views require evan-driven operations for the ones that do we indeed provide a preempt RT patch which basically enables you so it's not a hard real time. Right but enabled in enables you to have preemptive operations in a way that you ensure that is certain specific operation is is applied and run before any other right?

So that that can first I would say that can help you with a lot of use cases then obviously if you really want a hard real time, then you're gonna have to rely on a very specific approaches that probably you cannot replace with with soft real time. Another approach that we've been seeing is the need for the latency. This is something that you can you can get with.

With premedit but also with with Ubuntu in general so Linux does not prevent you from doing low latency. It's going to be a good correlation between the hardware and the software. Um, so I'd really depends it really comes down to what exactly are your needs in terms of performance what exactly are your constraints in terms of I would say Hardware configuration and then we we optimize it as as much as possible clearly.

Yeah. What's the margin for error for being late with these kinds of software projects? Each manufacturer rolls out new cars every year.

There are certain dates that start to be many would seem before an ECU is embedded into the car and then the software goes into that. So I suspect that this may not be as forgiving as it is in certain other devops scenarios. You're right.

That's clearly the case. But that being said with the push to suffer defined vehicles. We tend to reuse the same platform and the same software components.

So in the end, you're gonna You're Gonna Save time because you don't have to restart over your development. And this is something that we've seen in the automotive industry for years. Basically.

What happens is You're Going To Source a certain tier one and tier two and maybe tier three and you're gonna probably start from what they have of the Shelf. You're gonna fine-tune it because it doesn't match your specification and requirements and you end up with a six months to year of delay based compared to your initial launch date. By reusing the same suffer components and by making them evolve and adding new features adding new bug fixes Etc, but not starting from from scratch.

We did definitely save time you save money and it's scalable right? You can you can apply to not only one model but to all of your model and models generations and in theory, if it's if it's open source, you could even share it with other oems or other two ones because I would say that's not where you do the differentiation like from a branding perspective. If you have a certain low level suffer component that is reused by your competitor.

That's not gonna make this a big difference right in terms of in terms of branding right. So, I think it's a win-win if the whole ecosystem and Industry collaborates together towards that suffer defined vehicle Target. And that's also why coming back to your previous question.

That's also why we're increasingly investing and working with consortiums. We're trying to make sure that we're in the right ones because obviously there's a ton of consortiums and they don't focus on the same way of doing things and on the same Target, right? So you mentioned Eclipse as DV.

We're also part of Sophie or also contributing to ISO 21434 and ISO 26 262 standards. So we're doing as much as possible to learn because we're still at the I would say the growing phase in the automotive automotive industry, but we do aim to to push it even harder and make sure that we we bring the right knowledge and the right ways of doing to the industry if that makes sense. We have seen car manufacturers begin to tout how much they're investing in software.

We've even seen maybe a couple of Executives being removed because they didn't do such a good job with software. But I guess my point comes to you is is the way that we're gonna differentiate cars going forward is really going to come down to the software or how much of it is still about the vehicle and the hardware or is it all gonna be a software driven conversation? That's a great question.

Um, I think that the key differentiator when you buy a car is going to be the user experience and by user experience, I don't just mean from you know, sitting in your car and having a specific user interface our certain welcome sequence if you will. It's gonna also happen outside of the car. It's gonna happen when you're gonna want to do some some car sharing use cases do some right-haling use cases all the all the extended Mobility.

This is also part of the The end-to-end Branding perspective that needs to be taking into account. When you when you look at some successful brands that managed to do both the hardware and software. I'm thinking of a specific one in the smartphone industry.

It goes beyond the UI, right it goes beyond the object. It's whatever added value you can bring whatever features you can bring on top of that. So, of course, you need to have great great Hardware Great software, but at the end of the day, what does the customer remember when it comes to user experience?

It's not the hardware. It's not the the number of of course or how much round do I have in my my pocket? Right?

It's it's how great the user experience will be and that's that's where the differentiator is. Um, and that's where they have added value to bring so our basically our job as software editors is to make sure that we we provide the right enablers we make we make sure that they work perfectly and then and then they put their bricks on top of that and and they add the value I would say. Speaking customer experience, you mentioned safety historically Security's been something of an afterthought when it comes to student application development.

Is that a different scenario here? Because each case is now extraordinarily Mission critical. Yes, you cannot you cannot allow any mistakes when it comes to Automotive right you I mean that also comes with with the sdv trend since every component at some point needs to be updated over the year.

It also means that it it is connected at some point. if it's connected then potentially there's a risk right so You didn't have that 20 years ago when you only had a radio and you had no connectivity whatsoever. There wasn't any risk of someone, you know connecting to your vehicle and hitting the brakes right, but that wasn't even a scenario.

And the more the vehicles are connected the more you're going to see that sort of. potential risks and we need to make sure that well that risk is completely taken care of and Ensure that whatever the whatever these you it has to be completely protected in whatever possible manner right we've seen some proof of concepts of hacks that you know, we're relatively famous a couple of months and years ago and this is scary and if you know oems still want the customer to trust their brand and to well to take the risk of of driving their cars oems in tier ones need to ensure that the security is that at the best possible the highest possible level, right? And I think that that's as much as Automotive is one of the most Innovative industry in the oh sorry right now, it's as much as sorry as much as Automotive is one of the most Innovative Industries today.

It's also one of the most exposed ones We've seen the high risk of I increase sorry of bugs that have been identified in vehicles in the past few years and it's really it's increasing. So I do think that there's there needs to be a lot of investment in the cyber security space for vehicles. That's here.

Yeah. So ultimately what's your best advice to folks who are devops professionals thinking about going to work in the automotive industry. There's a lot of demand.

It's probably a lot of money to be made but you know, what should they be thinking about going in? That's a great question. I would highly recommend to follow, you know, the state of the art methodologies.

I would also recommend to use open source because well it's transparent. So it allows you to audit yourself all of the pieces of code that you're using or that you will be using as much as possible if they can trying to try to contribute to well to to the these methodologies to make sure that they evolve because principle that doesn't involve. Well probably will will be obsolete very quickly with with all that is happening in the industry.

So it needs to move forward and in order to move forward. We need to have the best experts contributing at some point. Um, so that that comes you know with consortiums that comes with standards and that's also the good transition towards certification.

I think at some point if you want to to have labels of trust that you can you know rely on the product needs to be certified and that's also something that we're strongly working on to make sure that the right software is certified at the right level for the right you use case. So yeah, basically that's I would run it up. Yeah.

All right, folks you heard it here software defined vehicles are among the coolest things. You can build software for however, it's important to remember that the margin for error is zero Hey Bertrand. Thanks for being on the show.

Thanks so much. Thanks for your time. All right back to you guys in the studio.