Arm: Making SDV’s a Reality

Overview

SANJAY: We have another special episode of the Driving Innovation Podcast from the show floor of CES 2024 in Las Vegas. In today’s episode, we have Robert Day, Director of Arm’s Automotive Go-to-Market. Robert is going to go over Arm’s involvement in automotive, as well as their initiative for enabling Cloud Native software development through their SOAFEE initiative. I hope you enjoy the show.

Agenda

ROBERT: Thank you. So I want to say thank you to Sonatus for letting us come to their fabulous booth at CES 2024 and talk a little bit about how we at Arm see making the software-defined vehicle a reality. There’s a lot of discussion about software-defined vehicles. A lot of people have been looking for sort of different ways to really kind of make this real. And that’s what we’re going to talk about today. So looking at the agenda, we’re going to talk a little bit about who Arm are, who Arm are in automotive. And then we’re going to go into what’s a software-defined vehicle. Why is a software-defined vehicle? And then some of the initiatives that we have that are going to, we believe, enable the software-defined vehicle as a reality. So a quick who are Arm. Well, so we are a technology company that makes basically IP to go into silicon products. And we’ve been pretty successful over our 30-year lifespan. And as you can see, there are quite a lot of Arm-based chips already shipped. And we estimate that 70% of the world’s population use products that have Arm in them. Interestingly enough, I started to count the number of Arm products I have in my house and I kind of stopped because it got a bit difficult. And what we’re seeing is, you know, this is kind of accelerating as Arm goes from, you know, being in consumer devices at the Consumer Electronics Show, but now into automotive. And that’s what we’re really going to talk about today.

Arm in Automotive

ROBERT: So Arm’s actually been in the automotive world for the last 25 years. Okay. Pretty much all of our life we’ve been in vehicle systems. But we’ve typically been kind of under the hood, if that makes sense. And so, you know, if you look at some of these stats here, you know, over 85% of the IVI systems run on Arm, which is sort of natural because IVI systems are like consumer devices. They just happen to be in your vehicle. But also now as new ADAS functionality comes in, autonomy comes in, a lot of the application processes are also built on the Arm technology. What we’ve done in Arm is we’ve created focused products for automotive. So we have CPUs, GPUs and ISP’s, which I’ll show you in a minute, which have functional safety as a key characteristic of them. We also have a fantastic automotive ecosystem, Sonatus being one of our ecosystem partners.

Why Software-Defined Vehicle

ROBERT: So why is a software-defined vehicle important? So firstly from an OEM perspective, it allows them to look at new business models, new revenue models, and new relationships with their customers. The thing about software-defined vehicles, as the name implies, is that early software development is critical. There is going to be so much software in a car, you can’t do it in one go. Okay? But we’re seeing that software-defined vehicle is the survival for the automotive industry. So interestingly enough, the journey is already underway. So this was a Gartner quote from last year that basically, in 2023, 50% of the top 10 automakers will offer new features through software updates. And that’s the whole point of software-defined vehicle, is you can bring these features in as software and you can update them, you can upgrade them, you can add new features. And that’s one of the key parts to this.

Are we ready for SDV

ROBERT: The next question is are we ready as consumers for a software-defined vehicle? And are we ready to pay for it? So Aurora Labs and Strategy Analytics did a study I think in 2022 where they asked consumers would you be willing to pay for software-defined features and services? And as you can see, almost 50% of the people said they’d pay $20 a month for additional services in their vehicle. That’s quite a lot annually. And over the lifetime of the vehicle. Some would even pay up to $50, which is really quite incredible. I’m not even going to do the math as to what that is in a year.

New requirements for SDV

ROBERT: So the thing about software-defined vehicle is there are new requirements to traditional automotive. So we need to be able to deliver the software-defined functions as advanced features. We need to enable innovation, but we also need to have agility. So it’s more akin to a more traditional software world than necessarily the automotive world. These things need to be updatable, upgradable. They need to be secure. And they need to be safe. Lastly, they need to be scalable. One of the key parts of having a software-defined vehicle is you can scale those features and functions over different models of your car. And so it’s going to be really interesting to see quite how this dynamic shapes up as we go into the era of software-defined.

Arm’s automotive products

ROBERT: So at Arm, I mentioned we have these automotive products, so we have a kind of a range of what we call AE or Automotive Enhanced products from Arm. So we have a high-performance CPU product called Cortex-A78AE. This has an interesting feature in it called split-lock, which actually allows you to lock pairs of cores together for higher levels of safety. But if you want high levels of performance, you can unlock them. And you basically got dual cores then. And this is basically in our AE CPUs. We also have a functional safe GPU, the Mali-G78AE, and this has an interesting partitioning mechanism for having safe rendering. And we also have an ISP called the Mali-C78AE. So all these products are really important for running software-defined functions, running graphical applications in the car, which will be parts of these software-defined functions. And with the ISP, it’s being able to get really good fidelity camera images into the car for all the ADAS functionality and other things like that. So let’s move on to the SDV.

Four Pillars for SDV

ROBERT: So as we’ve been talking to the industry, we kind of recognized that there are kind of four pillars to achieving the SDV and the delivery of the SDV. So you’ve got kind of like the top and bottom, obviously safety and security, you need to have real-time. They’re things that automotive needs anyway and the software-defined vehicle needs them too. We need some standards outside of the traditional automotive standards. For the software-defined functions, there needs to be APIs and standards that we can build the software-defined functions on. We need to have some new software methodologies. I’m going to talk more about that today because that’s an interesting way that we can actually bring these software methodologies from other industries into automotive. Well, what’s very key, and again, I’ll talk about this in a little bit, is having the ability to run the software when the vehicle and the vehicle computing is not available yet. You have to be able to start early and you need to do things like simulation. And the big one, which I’ll get to at the end, is collaboration in the industry. We can’t have these sort of silos anymore. People need to work together. The problem is too big for one company to do it on their own. So let’s have a little look at some of these. So one of the keys that we just talked about was new software methodologies.

Modern development processes

ROBERT: So what we need to do now in the automotive world is bring modern development processes in to basically accelerate the development time and deployment time of software. We also need to have the ability to have this thing called environmental parity where if you’re developing in the cloud and you’re deploying to the edge, it’s really good if those two environments share the same instruction set to allow you to run the software in the cloud and then run it in the car. And we’ll talk a little bit more about that. Having easy deployability across a range of silicon providers is really important, too. It gives you that portability of your software as you move from generation of car to generation, or model of car to model of car. And what this really is also enabling is a shift-left strategy. And I’ll explain that on the next slide.

Shift-left strategy in automotive

ROBERT: So a traditional automotive development up here is pretty serialized. So you basically you design your software and your SoC and then basically you do your ECU and then you do your applications at the end here. So it’s a sort of serial process. You can’t really start too much of the application development when you don’t have these in place. Where we look at doing cloud native, we introduce the cloud. And if you can start doing application development early in the cloud, which is up here. What you can then do is you can really start to develop here while these are being done. So we’ve got parallel here. And then once you get your system integration, that’s when you can bring it down and test it in the vehicle. What we’re actually doing is testing it and developing it up here first. When the vehicle’s ready or the vehicle computes ready, you bring it down. The other thing this enables- so here’s your shift-left, time-wise. It also enables these continuous updates and upgrades, which is an important factor to the software-defined vehicle. So you’re continually being able to either offer new services, updated services to the consumers of your vehicle. This has a really kind of interesting possible relationship dynamic change between the OEMs and the people that drive their cars, because right now if you buy a car, you sort of drive it off the forecourt. You don’t really have much of a relationship with the company that built the car. Whereas now if they’re providing updates and services, you do. And so the relationship starts to change between people that drive the cars and people that build the cars. So how do we achieve this?

SOAFEE Initiative

ROBERT: So a couple of years ago, we started an initiative called SOAFEE. So it’s an industry initiative and it’s really designed to bring cloud-native software development experiences for automotive software-defined vehicle. Okay? And we did this by starting the SOAFEE special interest group. The first thing we wanted to do with this is to try and define a software architecture which will enable this. So SOAFEE is first and foremost defining an architecture versus any code. However, for people to really get going with SOAFEE, we knew we need to have a reference software implementation so that people can start developing and trying out these new methodologies for automotive workloads. And you can see the founding members and the governing members of SOAFEE are really across the automotive ecosystem. So we have OEMs, we have Tier 1s, we have cloud people, we have us, and then we have some software people. So we have Red Hat and SUSE who really know a lot about software development and how it all comes together. So we believe just in the governing bodies, we’ve got kind of a good view of what we want to do. I’ll show you a little bit more in a minute the members of SOAFEE as well.

Cloud-native Architecture

ROBERT: But I told you we were really trying to define an architecture. And as you can see here, we have this architecture where there’s some cloud stuff and some in-the-car stuff. The idea, however, is the actual applications, and a lot of this here will be constant, or consistent between the cloud and the edge. So it means as you develop things like your applications or your services in the cloud, when you’re ready to bring them to the edge, these should just work. And that’s where we’re using technologies like containers, where we’re using things like orchestration. These are kind of borrowed from what goes on in the cloud world. So they’re already well established. People are already familiar with it. What we have to do is make it right for the automotive. And what that really means is we have to consider things like functional safety, real-time, heterogeneous compute, which you don’t necessarily have in the cloud. So this is one of the challenges that SOAFEE is going to tackle.

SOAFEE Membership

ROBERT: So in the last couple of years, we’ve actually had quite a good set of members. You can see the governing body members, again. We’re up to, I think actually more like 115 members now. And you can see over here, you can’t see probably, but that’s the Sonatus logo. Sonatus are a member of SOAFEE. Which makes perfect sense because a lot of what Sonatus is really looking at is the software-defined vehicle. It’s cloud-to-vehicle. So they’re a really good expert in this area that we can work with.

SOAFEE Workgroups

ROBERT: So a little bit about SOAFEE’s structure. Again, I’m not quite sure how clear it’s going to be. So we have a governing body which is chaired by Bill from AWS. We have a tech steering committee and a marketing steering committee. The tech steering committee really looks after all the working groups that are doing all the work and the sort of areas they’re looking at are system architecture. We’re looking at cloud native. We’re looking at mixed-criticality, and we’re looking at technologies like hypervisor technologies that we think will be crucial. And then these kind of feed into this reference implementation that we put out as an open source way of getting to use SOAFEE early. So other things we’ve been doing. Actually, if we go back, you can see over here we have another Tiger team, it’s the Blueprints Tiger Team.

SOAFEE Blueprints

ROBERT: So just putting out an open source reference implementation kind of is good, but it kind of relies on people to go, okay, we will now we have to do something. Okay? So what we decided is to basically have these SOAFEE blueprints, which is a reference application, basically in an automotive use case that will run in a SOAFEE environment. It can be open source, it could be closed source. And so what we wanted to do was to bring example applications into the SOAFEE world for people to use and also to allow kind of OEMs to kind of get running quickly with examples out there. I’m going to go into a little bit of detail about what these blueprints are really doing. So a SOAFEE blueprint is essentially taking some of the time the reference implementation running on, you know, the firmware and the hardware. And then we have these containers. As I said, part of the SOAFEE architecture is really looking at containerization of workloads. So a sort of microservices approach. And so we have different workloads running in different containers. And you can see over here the different software elements where we have application-specific workloads, we have the base stack, which will include containers, orchestration, potentially hypervisors, tooling and everything else. And then the compute platform at the bottom. So that’s what a generic blueprint looks like. Now I’m going to give you an example.

Open AD Kit

ROBERT: So the first example was something called the OpenAD Kit. And that’s working with an open source autonomous drive software company called Autoware. And so what we did in this is we basically took the Autoware autonomous stack and we broke it down into different containers. And those different containers then communicate via a virtual network. So you can see the different functions are in each of the containers: mapping, perception, planning and vehicle interface. We kind of cheated a little bit to start just to make sure this stuff worked. And we’re actually running four full copies of Autoware in a container, but we’re only kind of having the mapping function working in that. What we needed to do to get to more of a microservices architecture was this. Where we basically bring each of these functions into its own container so it’s no longer running the full autonomous stack here, it’s running each of the functions. And that’s what we’re doing right now with this OpenAD Kit blueprint. Where it gets interesting with blueprints, and this was the reason for us doing them, is we wanted, you know, the industry to take these and start using them either as examples of what they can do if you’re an OEM or if you’re another tech company to bring your tech into this to make it even more interesting. And so last year we had a company called Kern Concept that said, okay, I’m going to go back to these containerized thing. And I know one of the functions in here, the vehicle interface, that’s a safety function. That doesn’t work, the vehicle doesn’t work. Okay? So that should be running in a safety system. So what they did, if I go to here, is they had two systems. They had one over here, which is running most of the Autoware stuff and then one over here, which is the safety function, which is running basically the vehicle interface and then having an Ethernet, an actual physical Ethernet between them rather than virtual Ethernet. So this is the same concept of having containerized microservices, but now we’re doing in a heterogeneous network- heterogeneous system. So what you can see is that the safety part’s over here, which you can then have on a safety microprocessor in this case an NXP. And then over here are application processes that don’t necessarily have to be the same level of safety.

SOAFEE target platforms

ROBERT: So talking of platforms, the other thing we needed to do is to have some hardware platform so you couldn’t see it from the map, but there’s a lot of our silicon partners are members of SOAFEE. And what we’re really trying to do now is to get them to bring their platforms. Have SOAFEE, the SOAFEE reference implementation onto those platforms. And so you can see we have companies like Renesas and NXP and Marvell. We also have a native cloud instance from AWS. So what that means is you can run SOAFEE bare metal in the cloud on a graviton, which is the Arm-based processor. And then we also wanted to have some interesting kind of like non-automotive developer platforms as well. So we’ve got the Turing Pi and the Raspberry Pi. In fact, at the COVESA event last night, the Raspberry Pi was one of the systems that was running SOAFEE. So, okay, so that’s SOAFEE.

How to get involved

ROBERT: If you are interested and you want to get involved, SOAFEE.io will give you quite a lot of information. There’s a Slack channel, the SOAFEE’s on LinkedIn. And if you want to join, probably the best thing to do is to actually contact me. Robert.Day@arm.com. Then I will help you become a member. So that’s SOAFEE. We believe it’s a really interesting part to making the software-defined vehicle a reality. If any of you’ve been paying attention, you’ll notice there are other consortiums out there which are also helping to make the software-defined vehicle a reality. But each of us is kind of in our own sort of world where we’re doing our own bits of it. And so it’s not always obvious. Well, how do these things all come together? So last March we decided we were going to try and help that as well.

SDV Alliance

ROBERT: So we formed a new alliance. This alliance was launched yesterday. And it’s a collaboration- a starting collaboration, I’m going to say, between four organizations that are all trying to make SDV a reality. So we have Autosar, probably the oldest of the… no, most mature of the consortium. We have COVESA, which used to be GENIVI or GEN IVI. We have the Eclipse SDV, and we have SOAFEE. And so what we’re doing is we’re fostering a collaboration between these different consortia. So it’s like the consortia of consortia, or the collaboration of collaboration if you like. And what this does just in the four organizations, there’s over 500 automotive ecosystem companies that are involved in these different consortiums. What this does also, and what we’re going to do as an alliance, is make it quite clear how these things fit together. And actually, at the launch event last night, we had a demo of parts of each of these running together just as a show and tell that this can happen. But what it does bring is it brings cloud-to-edge, it brings connected car, it brings open source, it brings open standards and real-time and safety, kind of all into the bundle together. And the goal is if we can actually get this right, this should make the OEM’s job a lot easier to do and develop and deploy the software-defined vehicle. But also it will encourage collaboration, more collaboration. Not sort of siloed consortium collaboration, but working together. And it’s been a really interesting journey over the last nine months just working on this alliance and doing the collaboration. Now we’ve launched, the work starts. So what I’d say is just watch for, you know, things that are coming out of the alliance. And again, if you want to get involved with the alliance, you can contact any of these other organizations. The last thing I’ll say is it’s an open alliance. We’re expecting other consortia will get involved with this. It’s not just the four of us. So we wanted to kick it off, but we’re encouraging other consortia to get involved with this alliance and with this joint industry effort. And we really believe and I’ve heard this last night when I was talking to two OEMs that this is something that they appreciate. So we’re hoping that this is going to be a really good start to, really the start of the software-defined vehicle journey. I said it’s already underway, but the reality of it big time is what we need to do. And we’re hoping all of these consortium members will come together, work together to really make this a reality. Let’s skip over this slide.

Conclusion

ROBERT: So with that, I’d like to say thank you. Thank you again to Sonatus for giving us the opportunity to come and talk about these software-defined vehicle cool things. And I hope you enjoy watching this online. Thank you very much.