The Garage Podcast : S1 EP6
AWS in Automotive with Stefano Marzani, Part 2 of 2
Part 2 of a two-part episode with guest Stefano Marzani, the WW Tech Lead for Software Defined Vehicles from AWS. We discuss Prototyping, Machine Learning/AI, and ADAS/Autonomous Driving.
Listen to audio only version:
Episode Transcript | AWS in Automotive, Part 2
Table of Contents
- Overview
- Topic 3: Prototyping in the cloud and “Environmental Parity”
- Running on Arm in the cloud and the vehicle
- Start software development in the cloud
- Difficulty of validation for automotive
- Empowering developers via the cloud
- Vehicle software will triple in the next five years
- “Shift left” to accelerate design cycle
- $40-50 Billion lost to automotive recalls
- Developing vehicle HMI with the cloud
- SDV can reduce cost of recalls
- Consolidation of ECUs
- Consolidating software effectively without bloat
- SOAFEE and standards for automotive
- Topic 4: Machine Learning and Analytics
- Data collection and annotation with SageMaker
- Other frameworks for ML in AWS
- In-vehicle validation of new models
- Finding edge cases
- Tools to manage ML workflows
- Topic 5: ADAS and Autonomous Driving
- Near-term benefits from ADAS
- Seeking edge cases
- Decomposing autonomous driving
- Collaboration between AWS and Sonatus
- Importance of using real ECUs
- Summary
Overview
JOHN: Today in The Garage we present part two of our special two-part series on cloud computing for automotive with our special guest Stefano Marzani from AWS. In part one of our conversation we talked about data and compute aspects of cloud computing. In today’s episode we continue the conversation and talk about prototyping, data analytics and AI, and ADAS & Autonomous applications of the cloud. Let’s continue our conversation with Stefano Marzani from AWS. Let’s go!
Topic 3: Prototyping in the cloud and “Environmental Parity”
JOHN: That’s a perfect segue, actually, to our third topic, which is prototyping. And we were talking, as I mentioned, we were talking with Robert Day recently, and Arm is seeing Arm architecture being adopted across a wide range of subsystems in the car. And, you know, I’m proud to have worked in Arm for 14 years. So it’s a little close to my heart. But Robert was talking a lot about that. But I think that also means and, I think this is one of your points, that Graviton being in the cloud, having Arm-based instances in the cloud, as well as Arm-based instances in the car unlocks some really interesting potential capabilities for prototyping.
STEFANO: Absolutely, yes. We call it environmental parity, right? We started this, to use this term in Dev Summit Conference in 2021. Arm Dev Summit Conference in a workshop that we presented that have quite an important diffusion and visibility out there. Because it was the first time we were presenting this concept, why can’t we use Arm architectures in cloud to run the same software that runs in the same Arm architecture, if you will, in the cars, right? Same Arm architecture, not same processors, we have no idea, we have no intention to put the Graviton in a car, right? It’s really cars ECUÕs that are coming from a variety of suppliers out there like Qualcomm, Nvidia, NXP, all these are based on Arm cores. And again, the Arm core, there is exactly the same core that we have in graviton. Right? In terms of Arm 64, of course, it’s not the same really CPU, because in our Graviton is based on Neoverse architecture, while frequently in vehicles, you have Cortex, but the big bulk of the instruction set is the same.
Running on Arm in the cloud and the vehicle
STEFANO: That’s the reason why we can load, and after we had this idea we did it. So now we have a huge variety of embedded operating system that traditionally just worked in emulated scenarios or physical hardware, right, that are running natively in AWS cloud on Graviton. Systems like QNX, VxWorks, Yocto Linux, AGL. And for embedded developers is a new way to develop, we are seeing an incredible response, you know, for even a surprise, if you will, right saying, no, wait, it’s just launching this, this process in the cloud, and they have a QNX prompt in front of me, like, like I’m using an ECU kind of thing. Yeah, that’s exactly what we mean with environmental parity. You can start your work there. You need a hardware anyway but not to start the development.
Start software development in the cloud
STEFANO: That’s a huge bottleneck for the sector right now is important in your prototyping perspective, right? You can use low-down innovation if you always require developers and better developers to have hardware to work, right, because there’s no hardware but can satisfy the demand.
JOHN: Sure. And from a from a testing perspective, regression testing. We mentioned this on an earlier episode that we’ve started to do our own testing in a cloud-based way as well. So instead of having a rack after rack of systems that you sort of remotely power cycle, you can use virtual instances and EC2. So we’re doing that as well. And we see that, we see that benefit, and we’re, we’re doing a lot with that.
Difficulty of validation for automotive
STEFANO: Yeah. Yeah, absolutely. It’s, it’s a huge advantage, again, for developers, and for the validation phase, right? Think about that. Still, nowadays, the car is literally a system that is not, you know, tested deeply. It’s because this is for historical reasons. Again, we were telling at the beginning of the episode, that the car is undergoing this deep transformation from a system composed by 150-plus ECUs in a modern combustion engine vehicle to a lot less, say 30, 40, with consolidated computers. You will still have your microcontroller-based peripheral units for sensing or actuating. But the big compute will be done by consolidated architectures with multiple multiple Arm cores in there, 8, 12, 16, 40, right, in super consolidated architectures. And that’s super important, right? It’s a super important trend.
Empowering developers via the cloud
STEFANO: And you can’t expect developers to have these units on their desk to work, you have to offer them an environment, a cloud-native environment for the reasons we already saw. Because we have the data there. We have compute options there. We have Graviton there. So that’s the natural environment where developers can go find their tools, work, deploy on the hardware, and continue to test on the hardware, but not vice versa.
Vehicle software will triple in the next five years
STEFANO: Because if you start with the hardware, you just kill innovation. You know, in SDV it’s expected to triple the quantity of code in the next five years, from 100 million to 300 million, according to some analysts. How can you get to there if you still expect developers to have hardware to work and produce automotive code?
JOHN: Wow, that’s an incredible number I hadn’t heard that statistic: triple over the next three years?
STEFANO: Five years.
JOHN: That’s incredible. You know, I was thinking, I feel like there’s a virtuous cycle as well, because we talked in an earlier episode about consolidation of workloads and you mentioned that a minute ago. And I think, and we also talked about the importance of virtualization and having the ability to run these applications side by side, and yet not interfere with each other. It feels to me like that’s quite synergistic with this cloud prototyping approach as well virtualization, because you can take those same workloads you’ve tried there, and now they can coexist side by side. And it’s very much more similar, as you said, environmental parity, as you’d like to talk about, approach.
STEFANO: Yes, absolutely. Absolutely. And again, if you think about it, when you start to have 12, 16 cores, you don’t use all of them for a single operating system, it means that you need to partition these cores and run multiple operating systems. But this is exactly what we do in cloud, we have a hypervisor that manages on 64 cores on a Graviton processor, multiple OSs, right, it’s exactly the same. It’s different, of course, in terms of electronic qualification, many, many other thing. But from the software engineering perspective, we can do things in a way that the two environments are very close.
JOHN: So it’s almost proving out how it will exist in the final implementation in the prototyping and testing phase, it’s very interesting. It’s, it’s something I find very fascinating, technically fascinating, I think, also very powerful as a tool in development.
“Shift left” to accelerate design cycle
JOHN: And, you know, we’re seeing and we talked before, years ago about the shift left idea of how can we use virtual prototyping, how can we use Cloud and so on, to accelerate the design cycle. And we’re seeing and we talked about this in one of our recent episodes, as well, there’s pressure on the design cycle to design faster, and I think the competitive landscape for OEMs and tier ones is getting harder. And if these things can compress the design cycle, it can make people more competitive, save cost, and really, I guess, manage the sheer complexity, as you talked about this number of software lines going up, you have to get your hands around that. And I think you have to divide and conquer to make that work. Otherwise, if you think about it as a giant, monolithic system, it’s impossible to verify.
$40-50 Billion lost to automotive recalls
STEFANO: Absolutely. And there are other advantages as well. So shift left, for sure. Increase in code quality, because you can scale out test more. So that’s absolutely very, very important. Think about that in the automotive industry. Still nowadays, we have $40, $50 Billions lost every year for recalls. 70% are due to software fault. 70% of the recorded cases. So you think about that. That’s poor quality. Can we say that?
JOHN: Yeah.
STEFANO: Poor testing.
JOHN: Absolutely.
STEFANO: Not shift left.
JOHN: Yeah.
STEFANO: Right? So shifting left, decrease the cost, increase the quality. But I’d like to think about final users as well. Because what we’re seeing is, if you do not have these ECUs send around to develop, you can enable collaboration in the cloud. And this is super important. In fact, one surprising thing of SDV. We discussed about ADAS/AV services, based on telematics, telematics services.
Developing vehicle HMI with the cloud
STEFANO: We see a huge increase in HMI development in cloud, human machine interaction, user interface, user experience. And that’s to me, it’s fantastic. And you immediately realize why. You realize why because for the first time, you have a virtual ECU in the cloud, that presents a user interface in the browser. Immediately, I can show it to all my collaboration network around the globe, because the cloud has a global presence. So I can ask to a colleague in Japan, or to a colleague in South Africa, what do you think about my new user interface, according to your local taste? Or can you adapt it? Or can you work on it.
JOHN: And localization, language.
STEFANO: It’s literally a revolution in the way you do HMI systems, if you think about not having this hardware to go all around. But have a cloud-native, cloud-first, as we say, approach to HMI development. And we have a customer already trying to adopt it. And we recently again, released with BMW, a very interesting presentation about their development practices of HMI in the cloud at the last AWS summit in Berlin and we can provide the reference, of course. It’s a nice demonstration. But it’s not just to talk about always about BMW, for example, I can talk about the demo that we did at CES with Marelli. Marelli is a tier one. And they presented the first cloud native HMI system in there in at our booth. And it’s really nice, because there you see that we were developing an HMI application in cloud. And then deploying in Milan, in Italy. This was an engineer doing that in cloud, and then deploying it in Vegas in the booth, right? Again, you start with the cloud development, and then you deploy and customize on a specific hardware solution, right? And that’s really, really powerful, if you think about it. It’s not just powerful. It’s SDV, right? It’s software-defined. Otherwise, it’s hardware-defined if you start with the hardware it’s hardware-defined. If it’s really software-defined, you have to start with the software and later on, deploy.
SDV can reduce cost of recalls
JOHN: Exactly, exactly. So you just touched on so many things there. And I think I don’t want to lose the point you mentioned about recalls. We often hear a concern from OEMs, who have a big software development burden, which is true, saying, Oh, it’s too difficult to put in this software-defined vehicle feature. But when you think about a figure, like you said, $40, $50 billion, and many of those are software related. It would be crazy not to put in capabilities to be able to address this because it doesn’t take very much investment to save possibly billions of dollars.
STEFANO: Yeah, we had a very nice episode with of All Things Automotive with Martin Stamm from Conti.
JOHN: Yes, I saw that saw that episode.
STEFANO: Yes, you saw that? Where he explains why it’s like that, right?
Consolidation of ECUs
STEFANO: So traditionally, manufacturers, OEM, were having the need to integrate a new functionality. That means okay, we need to integrate one more ECU, and one more ECU, one more ECU, until you have 150. But if you think about the combinatorial effect of it, you will never test all the possible cases where you combine all these issues. That’s why, and that’s a good thing for the sector, pushed by electrification and other trends. The famous CASE, right, Connected, Autonomous, Shared and Electrified, plus user experience. This consolidation is happening.
Consolidating software effectively without bloat
STEFANO: And it’s a blessing for the sector to be honest where the problem is to transform the software that is in all this distributed system, and put it consolidated in these consolidated units. But, and there’s a but here, because it’s very important not just to say, okay, you know what, now we have the software in this ECU, I will just take it and plop it in my consolidated unit. That’s bloatware. You know, it’s ready to explode. You have to re-architect the system because the consolidated unit is deeply different from a single ECU that is cost-optimized. And it’s really, in terms of resources, the software there has been designed specifically for that almost-custom hardware. So that’s why we see so much, and you are aware of it right, the work we did, for example, with the Autoware Foundation on the Open AD Kit to take the software that, in that case, autonomous driving, that is classically monolithic, as we say a monolith, and break it down in microservices right to rearchitect it to be supported by a hardware and software platform that really calls for more modularity, more flexibility. Differential updates, right? Standardization of the interfaces. And all these are super important concepts to re-architect the whole industry in the automotive.
SOAFEE and standards for automotive
JOHN: You know, and what you just mentioned is very synergistic with the conversation we have with Robert Day recently about SOAFEE. And SOAFEE, I know Amazon was a founding member of SOAFEE, so you’re very much a supporter of this. A lot of what that’s trying to do is provide some of those standards, some of those consistent interfaces that you mentioned. But maybe that’s a conversation for another time.
STEFANO: Yeah, absolutely, itÕs such, by the way, a rich conversation, I think SOAFEE is a fantastic initiative. And if you read, SOAFEE is to provide a reference implementation based on open standards and open source. Oh, my, we need so much open standards and open source in the in the automotive sector, right? So that’s why initiatives like Yocto, COVESA, Eclipse SDV, AUTOSAR, are very, very important. And one of the very positive signs that we are noticing in SOAFEE is that we start to collaborate together, right? And we need to insist on that, right? Really, because open standards are key, you don’t compete on standards. That’s, that’s a no, right, you compete — when the standards are defined — you can start to innovate, for the things that the customer really, really needs and wants, that is not the standard. Whoever is “ah, yeah, I’m buying this car, because this standard is perfectly implemented.” Doesn’t make sense. Right?
JOHN: Exactly. It’s about enabling the value-added differentiation on top of the standards, but use the standards as the foundation.
STEFANO: As a foundation. Sure, again, it’s another way to save cost, to optimize. Why you are spending time and money to differentiate on a commodity feature, right?
JOHN: At this point, if you’re enjoying the episode, I’d love to encourage you to Like the episode and please subscribe to see more from us in The Garage. We film episodes about every two weeks, and we’d love to see you here again with another episode.
Topic 4: Machine Learning and Analytics
JOHN: So Stefano, we talked about so many different areas, I’d love to talk next about artificial intelligence, machine learning, and more generally, data analytics, because we talked about this incredible data lake that we gather, we talked about this compute capabilities in the specialty services you have in the specialty kinds of compute types, and so on. And the importance of prototyping and so on. But this whole area of machine learning and analytics is perhaps one of the most compelling, combination of those things that can do something that’s never been possible before.
STEFANO: Absolutely. And it’s always in the perspective of what we call the big loop, right? That’s super important, because you hear right, that the scientists that frequently say that the data set is the most important thing in building the modeling the right way, right? So in there, we always have that as a reference. So selecting the right data to be stored in the cloud.
Data collection and annotation with SageMaker
STEFANO: So, we need to have a little bit of artificial intelligence in cars to discriminate what’s relevant according to the situation, right? Maybe you had a hard brake. So why, or there’s a combination of factors. Or there’s in-vehicle testing, we’ll discuss about that super important feature right now. But anyway, when the data is selected, a little bit of machine learning there that needs to be updated, right itself? We send the data, we collect it, we clean it up, we organize data lake, perfect. Then we use part of this data to annotate part of it, right. So our customers annotate it for their own purposes, we have tools to do that, called SageMaker Ground Truth. And then we use when the tool is annotated, we just use it to train and validate the models. Here we have a variety of options. Sage Maker is our platform to do that.
Other frameworks for ML in AWS
STEFANO: You can use, if you are really a deep specialist in machine learning, you can use basic frameworks like PyTorch, for example, and really go at the low level of that or you can use on the other side, what we call AI services. Like services that really like recognition that you just send an image and you get the object list out of it. Right, so transcribes AI services. So we have these three layers.
In-vehicle validation of new models
STEFANO: When you’re training your model, through SageMaker, typically, you deploy it at the edge, but again, it’s a big loop. So it’s deployed but it is not yet in production. It’s there for in-vehicle testing. There is another version of that software that is currently in production. So the first phase is to analyze if this model has poorer or better performance, in respect to the one that is in production, exposing it to real conditions, potentially in a large number of vehicles out there, because we are constrained by the computer. So we have a little bit more juice, where you can run additional, you know, compute in there.
Finding edge cases
STEFANO: Exactly, as you said before, right to do what: to find for the special cases out there, the edge cases, as are called that, it’s impossible to just imagine them upstream in an abstract way, you really need to have the cars and a lot of cars out there to obtain validation of the performance of a machine learning model. And when you’re assessing that, and if you assess that the model is better, there is no regression, you switch it, and you put it in production, and the loop continues right? On a larger and larger amount of vehicles, right, so you see how machine learning is not just a magic way to train. But it’s really this intelligent loop. And it’s very important to define the workflows. And we have a lot of tools to manage these workflows. Some of them are in SageMaker itself.
Tools to manage ML workflows
STEFANO: Some others, for example, for data management are we have an implementation and managed implementation of Airflow, it’s called Managed Workflow with Apache Airflow. And we use that to compose all these workflows, right? I use that in my previous my previous job, Airflow, it’s a very powerful to compose these kinds of pipelines. Right? And that’s very, very important part of it. All this, frequently our customer use it in so called workbenches, right, more and more, our customers are asking us to enter a space in a browser where they can find their tools. These tools can be data pipelines, can be workflows, can be machine learning related data, access to the data lake, access to sectorial tools, very recently, for example, we presented at the dSPACE event, a collaboration with this space with MathWorks event collaboration with MathWorks. So you may find those tools there in that space, right. And so have the possibility to be very focused, have a uniformity of this environment, global distribution of this environment, global access to these environments, integration and the possibility to create automations, right. Recently our CEO recently posted on LinkedIn, that using this approach Toyota saved $10 million a year. It’s not bad, right, just to get the tools organized, and presented through a common interface with the possibility to create automations out of it.
JOHN: What I think is interesting about what you said is that there’s different parts to it: there’s starting with the data, the raw data, it’s having the ability to model and tune and improve the models. And then once you have that, in the cloud, all these different tools and modules that can connect together to do then post processing, post analytics. And there’s many different kinds. So that whole loop I think, is really important.
STEFANO: Absolutely, yes. And that’s why, for example, we organized it and make it public in through our autonomous driving data framework that is an open source initiative to try to put in the hands of our customer open source reference to create this kind of constructs and workflows. And, yeah, our customers are honestly are adopting most of this tool exactly this way in perspective of a workflow customers like Toyota, that uses for example, our P instances just to connect to our compute experience and discussion, right, to train the model in AWS. But again, it’s not just a single isolated activity. That’s just a part of a workflow. And that’s very important to be taken into account.
Topic 5: ADAS and Autonomous Driving
JOHN: And maybe it’s now’s a perfect time to shift over to the last of our topics, which is ADAS and autonomous driving, a scenario where we worked on for several years together, and we have a lot of experience. Let’s talk about how the cloud is important, I would say integral, to the evolution of ADAS and it also the potential of this journey that we’re all on, towards autonomous, which is quite a long journey, but we’re making strides.
STEFANO: Absolutely. And again, I’m very passionate and we already started our discussion on this point, I’m very passionate about providing an incremental approach to autonomous driving, autonomous features, autonomy in general vehicles, right?
Near-term benefits from ADAS
STEFANO: Because there’s a huge value that you can have now with ADAS system, let’s say L2, L3, as they are called level two, level three. And this is very important because first of all, they save lives. It’s simple like that. Right? So and we recently tested the car with latest generation ADAS and it’s fantastic. It’s a car that really has systems to do automatic emergency braking. For example, if you are distracted, and there’s an obstacle, the car brakes. Simple, but if it works, it saves lives. So it’s super important part to me. And more and more, I’m convinced that autonomy, it will be a collection of these functions that will be progressively automated, right? So it’s important to give, to think about, in addition, incremental functionality that will be automated in the vehicles. That’s my perspective about it. And the way we’re doing cloud, again, using everything we discussed, essentially, the variety of compute options, the possibility of these data lakes, constructs of data lakes, and machine learning tools, those are the basic thing that are needed for ADAS. and autonomous vehicle development. There’s another aspect of compute options again, for two reasons that are specific to ADAS that’s very, very important that is, you have frequently you collect data from the field and you store the data in S3 in the data lake. And then you use it for validation, right? So you typically replay that data collected from vehicles in your algorithms under development to assess the fact that they are better or worse than, than the previous one and previous generation. Or you use compute to do synthetic simulation on the other side. So you have, we have a wonderful use case with Valeo that we presented in the failed CES to COVID, unfortunately, where nobody went, but we prepared this awesome demo that is there’s a video on YouTube, we can put the link of course, where you see the Valeo using two technologies, one was IPG CarMaker and the other Foretellix to, you know, multiply the scenarios of through synthetic simulation, and multiplying it to 1000s of different variants of the scenario on AWS, because you have the scalability, you have elasticity of compute your have availability of compute, and then try really to cover all these edge cases, right to explore if there’s something missing in our analysis, essentially, right?
Seeking edge cases
STEFANO: And try to capture to shift left, if you will, exactly as we discussed, the resolution of this problem before the software hits the vehicles themselves, right. So it’s, again, it’s a matter of composing these workflows again, and in AWS, we have all the tools to enable our customers to do that. And if not, we are happy to work with our customers to create them.
Decomposing autonomous driving
JOHN: Absolutely. And I think a lot of people I think might think that the autonomous driving task is a monolithic task. But in fact, there are many, many subtasks. I like to joke that there’s the bicycle recognition task, and lane keeping. But all joking aside, there are many different. You have to decompose this very, you know, the way we drive, we just drive and that’s it. But actually, the way ML and way artificial intelligence does it is decompose it into different parts of it. And what you mentioned a minute ago, I think, is very interesting. Because when you think about training, you know, if you think about driving as a person, you know, most of the time, it’s quite boring, you know, you just keep going straight, and it’s boring. So what’s difficult than the things you have to practice for is that while there may be a sharp curve or this obstacle, but what you mentioned is so interesting, as you can accelerate the edge cases, to give me lots and lots of edge cases to help the model learn much more quickly than you could in a real driving scenario.
STEFANO: Absolutely, absolutely. That’s totally true. And that’s why for example, as we discussed, microservices are important in this perspective, because maybe you want to just swap out the perception model, but leave the rest as it is, right. So to have different teams with different skills, working on their small piece, right. So that’s a super important part, recognizing the different personas that are in the in the ADAS or autonomous vehicle development. Super important part, right. So totally, it’s a complex scenario. But again, we have good good references in there. Again, the case I was describing with Continental was ADAS development, and you will really see how they gained in terms of saving time, saving cost and agility. When adopting a cloud native approach, right? That’s was the intention of this CAEDGE exercise that we developed with them. That was, by the way, in a software-defined vehicle experience as well. So that’s a great reference. So our collaboration with Conti is really where we started to think about most of these constructs. So really, great collaboration.
Collaboration between AWS and Sonatus
JOHN: To wrap up our conversation, I thought we might take a minute to talk about some of the areas that Sonatus and AWS are working together.
STEFANO: Yeah, with pleasure because again, I hear in the garage I saw some amazing demos — thank you so much for that, by the way, for showing me them. And it’s just amazing, right some of the features I saw about, for example, controlling the logic of the vehicle and deploy new logic according to new situation are exactly in line with what we discussed in terms of SDV, big loop update. So you really see that happening. So that’s really fantastic to see. And, yeah, it’s great collaboration. And it’s a perfect example. You see, it’s not you’re not just sending data or collecting data, you start to implement this view of a data plane, yes, we need to collect data, but for the control plane as well. So the possibility to manage this micro logic, from cloud to edge and back, you have to have some of these micro logic, maybe some machine learning at the edge, and you need to exercise some of these micro logic or machine learning in the cloud. And if you think about consolidation, if you think about Arm cores, you know, it’s a system that we say it’s a continuum between the cloud to edge. And I think you’re really doing a great job in implementing this vision with your series of products.
JOHN: You know, thank you very much. And we talked earlier about data and you know, our Collector product is very highly optimized, it gathers, tuned, carefully selected data, high value data and sends it to the cloud, and we’re working with you on that. And then the Automator product you just mentioned, that we recently launched, allows us to take that idea of smart data, but then to take actions, whether that’s actions inside the vehicle actions outside the vehicle. We didn’t really touch on, on the vehicle testing, but the vehicle testing problem is also getting a lot more complicated. And so we’re excited to be able to use that in new ways to, for example, improve the production workflow, as well as providing better downstream services. You mentioned connected vehicle before downstream capabilities to the user, and even to value added service providers down the field.
Importance of using real ECUs
STEFANO: Yes, and that’s absolutely interesting. And it’s another super good point I saw because you’re doing it on real ECUs. And believe me, it’s a huge difference, because I am always saying, you know, you’ve got to think that when you’re developing a new software components or hardware components for the automotive, it’s 50% is development. 50% is V and V [verification and validation]. In the case ADAS and AV, let’s do some assumption. ADAS, I think, is 20-80, probably. In AV, it’s 1-99. Right? So because really V and V and you see that, when you start to see code running in really CPUs, is different, right? It’s not just anymore a prototype on your desk based on an evaluation kit. But it’s something that goes in a million vehicles, two million vehicles, ten million vehicles. So it makes the whole difference.
JOHN: You’re right. And it’s we’re so pleased to be in you know, by this year, we’ll be in dozens of models, and by the end of next year, millions of vehicles. So it’s exciting to see, this is not a prototype, it’s not a science project, but it’s real production. And you learn a lot from real production where the rubber meets the road as it were. It makes it a lot harder.
STEFANO: Yeah. And whoever is in the automotive recognizes given the effort to be compliant with the regulations. That’s a big part of this industry, right? So you can’t just deploy code as you’re deploying in phones. Right? It’s not the consumer device, in the sense that it’s a regulated product, you have a functional safety, you have cybersecurity. And those are aspects that are paramount. And really important for us. It’s a top priority, priority zero.
Summary
JOHN: Yeah, there’s so many things we’ve touched on today, we could have many different hour-long conversations on just different subtopics we talked about, but we’re going to have to bring it to a close today. So first, I want to thank you so much for being here, Stefano. It’s been my pleasure to have you. And I’ve learned so much in today’s conversation, and I always enjoy talking with you, and hope you’ll come back and see us again.
STEFANO: Likewise, thanks for having me. It’s always a pleasure. I learned a lot myself. So fantastic.
JOHN: Thanks, Stefano. So in today’s episode, we talked about every aspect of the cloud, and specifically from AWS, talking about the ways that cloud can benefit and improve the automotive and the vehicle workflow, starting with data and how important data is, and the many different ways you can use data, talking about Compute and the need for different kinds of compute services, solving different types of problems. We talked about prototyping, and particularly the ability to prototype vehicle functions in the cloud and deploy into a real vehicle, which is very compelling. We talked about machine learning and analytics and how data analytics can be used to add value in many different ways. And finally touched very briefly on autonomous driving and ADAS and how important it is to improve that and optimize that flow. This has been a wide-ranging conversation. I hope you enjoyed it, and we look forward to seeing you on another episode of The Garage very soon. Thanks very much.