Cloud-Native Development and Model-Based Approaches for Software-Defined Vehicles

Thank you. Thank you, thank you very much. So are you ready for the gold rush or software-- sorry, sorry. Software rush. So this talk is all about that, right? So it's absolutely exciting to see everything is happening in automotive with some macro trends. Let's start with sustainability. We want to build a greener future for us and for our kids.

And then of course, we have some other macro trends related to technology. We started to talk about that this morning. And then these macro trends, of course, have to deal with autonomous driving-- cars are connected, we are all connected-- shared, and electrification, so the famous case. And we see, especially on the AWS side, really an increase in the attention on customer experience.

Users enter the car, they want to have delightful user experience like the one they have with the nomadic devices, smartphones at home, and so on, so not to break their digital life while they enter a vehicle but just continue that. And vehicle software, of course, now we enter a little bit in what's behind the scene of all this transition. What needs to happen? What's the state of the art?

Today's vehicles number ECUs is still too high-- more than 100, 150, a lot of code already, 100, 150 million lines of code in a car nowadays. And we are entering in an era of fully software-defined vehicles, where a number of ECUs need to decrease. So we are in the process of consolidating these ECUs, and the lines of code will increase. So it's a whole reorganization of the vehicle architecture in terms of electronic architecture and software.

So there are key challenges in all of this. Because cars are a complex product that needs hyperscale, first of all, especially if you think of autonomous driving and ADAS, that you have cars out there, fleet vehicles or the full production vehicles, that connect to terabytes of data, if not petabytes of data, if not exabytes of data. And all this data is used, as we saw in this big loop perspective, to simulate, resimulate, test, validate autonomous driving system to train artificial intelligence system. It's thousands of cores it operate. And most of this, and a big part of this, is executed in cloud.

This, despite the humongous amount of resources, this has to be done with agility and speed. We saw the references to DevOps. And you can't just wait a year or a new model to deploy new software. That needs to happen even on a weekly basis or when needed, when necessary.

Cost is an issue because if you think about all this storage, all this compute, this needs to be overseen very, very precisely and put in place strategies to address cost management and cost optimization in your designs. Safety in automotive is paramount, absolutely, priority zero. Functional safety is a regulated industry from the functional safety perspective and cybersecurity perspective. So this has to be at the center of what we do when we develop software for this sector.

And then the reason why we are here-- very happy to be here, by the way. Thanks for the invite-- it's an ecosystem play. it's not that one actor can do all of it. And the demo we prepared, by the way, it's a demonstration with four companies presenting different aspects of the software revolution that is happening right now working together to try to achieve a common objective that is software-defined vehicles. And again, key challenge is the complexity. This is surely a challenge that the sector starts to properly deal with.

And no OEM is just producing a car to be sold in a single market. It doesn't make sense. So the car is a global product. But being global means every single region, every single place have different regulations, different, for example, privacy rules and regulations. And you have to manage this kind of complexity as well.

So enter SDV. SDV is really fundamental to manage the software part of these aspects. And I'm trying to give a definition coming from two years of work with customer on SDV, where we try to synthesize the multifaceted implementation of this concept in their company. So SDV is a vehicle where the function can be updated, secured, and personalized throughout its lifetime.

But it's not just that. It's that the insight you generate from the SDVs out there improve the current and future generation of vehicle. So there's a physical dimension in SDV, as well, some OEM point at that. So there's a software part. Software needs to improve on a current vehicle. But the data that you collect can help to guide the design of next-generation vehicles. Those are software-defined vehicles per what we see with customer.

And let's try to break it down. We have three layers of SDV. First and foremost, you have hardware abstraction. So the software development needs to be decoupled from the specific hardware where the software runs into. Otherwise, it's not software defined. That's the basic thing, right? You need to decouple these processes.

And we say cloud first. We are saying the cloud, in our perspective, is the most abstracted environment of all. If you develop there, later on you port what you develop in cloud on a specific issue implementation. Software lifecycle management, another very important aspect, all the DevOps operation and tooling necessary to produce, test, and validate code. And then vehicle data. For us, SDV is the composition of two planes, the data plane and control plane-- data plane for this data and the hardware for the control plane part-- hardware abstraction.

How can we help with the cloud? With introduction in the last two years, we did a lot of work on SDV to create virtual workbenches. This is a way to say-- to collect in cloud the most diffused tools and virtual environments to enable automotive software development in cloud. Let me put it this way-- to make the cloud automotive friendly in terms of software. And that's really we worked hard to do so, and you have a demonstration in a bit.

The second is to host virtual electronic control units. But again, even here you will see not just to host high-fidelity versions of electronic control unit but the best proxy of an electronic control unit for the purpose you need to use it for. And then we have there-- sorry for that-- automotive-native Amazon Machine images-- it's a very difficult word to say-- will lift it in cloud automotive operating systems and stacks.

So in cloud now, we have QNX. We have VxWorks. We have Yocto Linux. We run several infotainment systems. We have stacks on top of it like the Elektrobit stack you see in the demo here, adaptive AUTOSAR and classic AUTOSAR, and so on. All this is implemented in these images, in snapshots of the operating systems that are loaded up and executed in cloud.

Traditionally, this is the way. And it's a visualization of the big loop that Jim was pointing about before in his talk. You see this is what we propose our customer in terms of defining a workflow to define-- to implement, develop, and test automotive software. On the left side, you see all the customer equipment. It can be developer desktops with electronic kits, electronic evaluation kits, hardware in the the loop rigs, test fleets, production fleet. All the systems send data to the cloud.

And when it's in the cloud that is the big infinity loop there, you just start with the processing the data, and you do quality analysis. You tag the data, you organize it, and you make it available to the entire organization. And this is an automotive data lake, a connected data lake. For example, BMW uses this. And you will see on YouTube some references of this in [? several ?] events ago.

And then this data is used pervasively in the organization. We have customers like here or Mobileye that create HD maps. We have customers like Toyota or BMW that are using it to train artificial intelligence. That's been very nice question before. And we are working very hard, of course, on everything is machine learning and AI related.

And then it's used to create models and algorithms. And you know, it was very important more than a year ago, approximately a year and a half ago, learning that we had at least three customers doing powertrain algorithm, powerful power train development, in cloud and optimization of this algorithm in cloud. And this is kind of new. It was new for us because it's a very hardcore automotive component that was developed in the cloud.

And we see a strong increase of everything is HMI related. Typically, cloud has been with no UI. But now we introduce a set of technologies that enable to create UIs in cloud and remote them through a browser. And that enables a new set of potential tools for developing HMI in the cloud.

And then you have two phases in the development, simulation and validation, that are really attached, plug this infinity circle to the V-model, classical of the sector for functional safety purposes, engineering practices. And all of this is orchestrated to developers' workbench. That's a concept I mentioned before, engineering workbench. It's where you enter in a browser and you find all the tools that you need to work on your specific task depending on your persona. If you are a validation engineer, if you are a powertrain engineer, if you are a simulation engineer, you will find your tools to do your work, your data to do your work, and so on-- your pipelines to do your work, and so on.

It's not a theory. We already have three customers using this approach. [? Conti ?] that we started with, the famous CAEdge project, and then Stellantis, and then very recently, even our CEO, Adam Selipsky, did a very nice LinkedIn post highlighting how Toyota is saving $10 million a year in using an app-- a properly organized workbench to automate their own development processes for automotive software.

But what is cloud auto-- cloud native? Let's go a little bit technical in here. And you see of course, the electrical/electronic architecture, we saw it, is evolving from 100 ECUs plus to domain controllers. So let's assume three for domain controllers, one for ADAS, HMI, IV, and powertrain; two zonal controllers-- a big computer in a redundant fashion, high availability, but just a big computer for the car. This is what the sector is seeing right now. Today, we are surely in the consolidated phase in domain architecture. And we start to see some designs about zonal central computers as well.

How the software is changing for that? Do you think the software stays the same, where you go from a microcontroller-based unit to a microprocessor-based unit where you have 16 cores? It changes everything in the architecture the software is architected. So we go right now from a situation where you see on the left, we have a monolithic automotive stack. Think about, for example, we use as a reference the Autoware autonomous driving stack. It's open source Initiative. Typically, Autoware was a monolith-- perception, planning, control, everything in a big container that you have to download and deploy.

The first step is really to break this monolith and create microservices. That means APIs. You will have a perception stack with an API that gives out the object list. You have a planning stack that will take in the perception and communicates with the API of the perception and gives out that planning instruction. And that will go into the control module-- so stack.

And you see this is really organized in different operating system. Perception still nowadays is executed maybe on a Linux system. Control needs to be executed on a real-time operating system. So we are in a concept of mixed criticality. And that's the final step where you completely introduce so-called mixed critical orchestrator that is able to manage the criticality level of these different workloads.

If you are in infotainment system domain, if you are in control, ASIL C, ASIL D, and that needs to be described properly and executed properly where you can find the hardware resources that enable that level of criticality. That is becoming, you see, a continuous relation between this big loop where you create software and the deployment strategies toward the real hardware.

Why we are able to do that now? Because in the last two years, we work very deeply with ARM as a partner. And you know that most of the systems automotive systems out there, especially the multicore ones, are based on ARM cores, ARM64-- think systems like Nvidia, Qualcomm, NXP, this kind of system. They are all based on ARM64 architecture, mostly v8.

You know what? We have ARM in cloud in the form of our AWS Graviton processors that are based on arm-- ARM64 v8. And we said, why can't we just take the software that runs in these ECUs on our v8 and load it up in our Graviton instances, in our Graviton computers? And we can. And we could, and we did.

That's why it's possible right now to execute big part of this software natively on AWS. And that's why we have systems like QNX, like VxWorks, like Yocto, and so on, running natively. It's not an emulation. It's a virtualization of the operating system. It's like having an evaluation kit in the cloud. You SSH into it, there's no difference in what you will see with respect to an evaluation kit on your desk, literally. OK.

And we believed so much in this approach that we opened up, and we co-founded together with ARM and other partners-- OEM, tier 1's, and the software vendors-- a Special Interest Group, SIG, called SOAFEE, where this we are trying to democratize this way of developing systems in cloud-native, cloud-first approach where you can have binaries and containers with different level of criticalities, so up to ASIL D, and then when it's done, deploy to real hardware, really inverting, flipping, the workflow as it is today.

And yeah, exactly. The objective of SOAFEE is really to provide the software architecture which enables cloud technology to be combined with automotive functional safety and real-time requirements. That's the missing part of it, right? It's not done yet. This is what SOAFEE is all about.

And to provide open source reference after implementation-- because, again, it's an ecosystem play. And as AWS, we are big-time open source contributors, and we think that's really important for the automotive to become standard in that way. We are promoting open standards and open source where possible.

And then what can we do with this parity between ARM in the edge and ARM in the cloud? We can do different things, leveraging different levels of fidelity, let's call it this way. The first level of fidelity is instruction set parity-- the same ARM64 here and there. And there, you can really do a lot of things-- load up operating system, load up stacks, and start to develop your application, and start to test it out.

And then you can go to the next level, to achieve CPU parity. What does it mean? You don't just do ARM64. You do, for example, Cortex-R that is very diffused in automotive-- cortex M, cortex A. In the cloud, we have Neoverse. So it needs to have a partial emulation of it.

And then you can do SoC parity, so System-on-Chip, where you start to emulate or simulate specific component in circuitry like ISPs, DSPs, or specific peripherals-- Cam, FlexRay, or whatever is necessarily, arriving to a full digital twin, the full system parity. But let's see an example to make it clear. Sure, it's a little bit small, but hopefully I can go through it.

This is not theory. We have demos and examples for all these use cases where we took, for example, an infotainment ECU based on Qualcomm, let's assume, with a QNX hypervisor, Android and QNX, and we load it up in cloud in an Android environment and in a QNX environment. And we just execute here in cloud the same code that is executed here.

This is an environmental parity level 1 because it doesn't require any further level of fidelity. The APK you develop in cloud is the exact application you're going to deploy in your infotainment system. You don't need anything else to work and create the vast majority of software.

Then of course, at the end you're going to execute test on hardware. But you can't start with the hardware the whole process, otherwise you kill the productivity of the ecosystem of developer that you want in the community to work to provide software for your infotainment system if we want to achieve this increase of code that is necessary to produce the SDV value, this gold rush, right?

The second is an example where we have adaptive AUTOSAR stacks that are executed natively in cloud, always environmental parity level 1. The third example, for example, is a TCU, where we want to have the higher fidelity in emulating, in simulating cortex implementation. Here, we have now a very powerful tool that is the ARM virtual hardware-- more than happy to provide information about it-- that is, again, an SoC emulation, simulation of the system itself that enables to launch in a virtual i.MX 8, a virtual S32G in the cloud with higher fidelity than just the instruction set.

And then the last level is full emulation, where you have really want to go high level and high fidelity, and, for example, you use an Infineon TriCore. We don't have the architecture instruction set in cloud. We just have ARM or x86, we need to emulate that. And here we have partners like Synopsys that can provide tools like Synopsys Silver that many of our customers are using in cloud already to do that kind of emulation.

There is an order, though. Again, the system parity, the parity level, is a little bit different to thinking about just going high fidelity. It needs to be written in terms of priority from left to right. Don't emulate if you don't need to in respect to the part of the development or workflow or validation that you are into, because that will increase cost, increase complexity, and maybe it's not necessary. So keep it simple and always start on the left-- virtualization on the left going to simulation and emulation when necessary.

And how can we apply that to model-based design? Super fascinating topic. I worked in model-based design the past 20 years. So again, first we can integrate data-- super important-- coming from synthetic simulation or real simulation.

Again, the design must be broken down in microservices where possible and the providing-- think about the Simulink model where you really break down the various Simulink parts, components in designs that can create microservices in the cloud. And the same software needs to be generated, the same binaries, at all steps from the model in a cloud execution in virtual ECUs or physical ECUs.

And then it's very important to separate targets and tool. This is super important step that SDV implies in a way. What does it mean? It means that when you execute, for example, a Simulink model, you don't have to execute the whole Simulink thing but the output of Simulink in cloud to let scale.

Because when you want to run a simulation, for example, in 10,000 virtual ECUs in cloud, you don't want to execute 10,000 times Simulink with the model inside. You want to execute the model that is the output of Simulink to optimize resources, keep costs controlled. And this is a very important thing, this separation of the tool that is used to produce software to this output of it. And then test and verification-- use the cloud because it guarantees scalability, elasticity, and it really fits with your demand and with your need. That can be very specific according to the part of the workflow you are into.

But it's not just a theory. Again, we are presenting today for the first time-- I think for the first time in the sector-- so it's an innovation, it's a real innovation-- a demo that combines a set of virtual ECUs composed with different strategies. To assume an example, you want to introduce a new functionality, a new mode in your car, a Sport+ mode.

And you see we have three ECUs here-- the infotainment that is essentially to activate the functionality, we want to have this new mode activated; a vehicle control unit that is an ASIL D consolidated ECU; and a battery management embedded ASIL D, you know, microcontroller based. To achieve that, you need different strategies. Again, you don't use always an emulation.

For the infotainment system and for the consolidated HPC, you just use native execution of code in native Amazon Machine images or directly native code executed with no level of emulation, while for the ASIL B, ASIL D unit, classic AUTOSAR typically, you introduce simulation techniques. And for the first time, there's a networking between these VCUs. These VCUs communicate through some IP. So it's pretty innovative thing.

What's the workflow? There's a Simulink workflow, of course, where you can update the control strategies between the VCU and the battery management system. So you see the two elements, two VCUs, are separated in a way and will define. You integrate the VCU and the BMS into the virtual vehicle model. And finally, you execute locally visually some inspection, some test of the combined system.

Then when you're done, you are satisfied with your visual inspection, your preliminary testing desktop, you scale it out. What does it mean? You launch the set of VCUs in cloud, and you start really to scale the testing out to thousands of instances. It's like, again, multiplying the capability to test out.

And this is, again, super necessary. You know the car is still a product that is undertested in terms of test coverage overall in terms of system functionality. So testing is a priority. And increasing the testing coverage, it's really a priority. But we can't do that if we have an architecture that is too complex and a hill that are not properly organized.

Good. What does this imply? So these four companies collaborated. And you see how this demo can connect the model-based design to the DevOps operations, so really, connect to data and simulate, connect to tools like Jenkins, GitHub, GitLab Runners, and so on to provide a Ci loop, CI/CD, and then virtual testing in cloud through proper methodologies, and achieve that agility that is really necessary to implement this kind of system.

So just to conclude-- you know, sorry for the vast amount of icons there, but I promise I'm not going to go through that. I just need to highlight the blocks. What's our concept here in terms of SDV architecture? You always have a physical hardware. And in no way we say that hardware is not existing anymore. We just say it's at the end of the process.

And hardware and its own digital representation in cloud through, again, different techniques-- native execution of the systems, emulations, virtualization techniques-- and then you have the developer workbench, engineering workbench. So assume a developer, quality engineer, data scientist needs to develop an application. The developer will find its own tool, their own tool-- MATLAB Simulink, tool to do your remote, tool to configure the system, over-the-air update toolings in one place, and for the specific necessity and needs of the persona that requires to work.

And then automotive virtual targets from QNX to VxWorks or virtual hardware, Synopsys Silver, Yocto Linux, Yocto Linux with adaptive AUTOSAR from Elektrobit, bit, Ubuntu, and so on, so virtual targets. And last but not least, build pipelines. They can build pipelines, they take the source code, and deploy the code in terms of binary or containers ready to be used in the virtual instance first, and later on being deployed on real hardware for final validation.

This is the way we see it organized. Why it's relevant? And the relevance of it is really, it has an implication at an ecosystem level. Because think about the classical process of testing an ECU and the supply chain and the value chain in automotive. You have a supplier sending you a sample, a sample [? B, ?] physical ECU. You start to work. Something is not working, maybe you send the ECU back-- back, forth, back, forth.

In this way, with virtual environments, you have full control of the environment from the OEM perspective. And when you need to collaborate with a third party, you don't need to send any more ECUs back and forth. You open up in cloud, in AWS, the access to your environment in a protected and absolutely confidential way. So you are sure that your ecosystem of suppliers will work with your parameters, your environment. And when they deliver code, it will just work because it's designed to work by construction. And as an OEM, you receive the code, you test it out on real hardware, on your test fleet, and you release. But it's a complete flip of the process, as you can imagine.

So some final conclusion. SDV is happening. The gold software rush is open. And it's started. So got to [INAUDIBLE], right?

And this will transform significantly tools, workflows, and in the automotive sector and the supply chain and the value chain. There's this very nice definition from Porter, the same guy of the competitive forces that created a white paper about the product-- the transforming the nature of the product. So this is one of the cases where the product is not just the incremental innovated. It is transformed in its own nature. It's a big thing that is happening in the sector.

And model based is fantastic position to capture some of this SDV transformation revolution, really, because it's a first layer of abstraction. The power of abstraction that model based have with the power of abstraction of SDV-- abstracting hardware, abstracting data definition-- it's really good fit. And thanks with the collaboration with MathWorks, we did provide-- we can provide our customers with more powerful SDV-aligned model-based tools that are properly architectured, that can leverage natively cloud-native practices, cloud-first practices in developing this kind of test.

Again, please come to see the demo in the demo area. I will be really, really happy to have any kind of feedback and comment, challenge, because, again, this is something that we need to build together. This is really, really important. No single actor can do it alone.

So some, as always, as AWS we conclude with our customers. And we thank you for-- I thank you for your attention.

[APPLAUSE]