Software-defined vehicles: The future of the automotive industry? — Thoughtworks Technology Podcast
[music] Hello, everyone, and welcome to the ThoughtWorks Technology podcast. I'm one of your regular hosts, Ashok Subramanian, and I'm joined today by another one of our regular hosts, Ken. Hi, I'm Ken Mugrage, nice to speak to you again. Today we are joined by two guests who are experts in a topic that is probably becoming quite relevant to all of us today. I'll let our guests introduce themselves first. Sriram, do you want to start off? Thanks, Ashok and Ken.
It's good to be on this podcast. My name is Sriram. I'm from Bangalore, and I'm a business leader for software-defined vehicle topics in ThoughtWorks. Michael? Hello, everyone. My name is Michael. I'm a developer. Clearly, my background is in the web and the cloud world, but the last years, I've been working only for automotive and embedded automotive development.
I do everything SDV in ThoughtWorks. As our guests almost gave away what this episode is going to be all about, it's all about software-defined vehicles. I think to get us maybe started off, software and automotive, it almost seems like going back a few years, you wouldn't have put the two of them in the same sentence. Yet I think here we are today almost talking of vehicles that are being defined by software.
Perhaps we can maybe start off by why is software becoming so key in the space? Sure. I've been reflecting on this question for a long time now. When I think of it, the demography or the characteristics of the population who are buying a vehicle or a car today are those of digital natives. Therefore, the expectations from car wear is extremely different these days. To deliver to that experience, I guess software is going to be a very integral element. Therefore, it's very clear that the entire talking point about automotive is software leaders.
Michael, you had a perspective as well. You want to share that? Yes, if we think about what features can we add to cars and how these are evolving, I think there are two aspects inside a passenger car where great innovation is happening and the evolution is happening. That's who won the infotainment, the big screen in the middle, and maybe the instrument cluster and other screens.
The second one is ADAS, advanced driver assistance systems, or autonomous driving. Both of these obviously rely on certain capabilities of the hardware, but the differentiator of the functionality comes from the software. I guess you could argue, cars didn't run without software for two decades.
We come to the point where it becomes the key differentiating factor for the user experience. Yes. Nowadays you can't almost think of doing anything without your phone. It's almost a natural extension of taking that almost everywhere in there.
Definitely. There's a lot of talk about SDV. When you are talking to clients and as you're developing our thinking in the space, are there other things that are-- I've heard of things like CASE, how does that actually fit in? Maybe a bit of, if you could give our audience a bit of the history of how this thing has actually evolved to what we are calling SDV today. I think CASE stands for connected, autonomous, shared, and electric. At least I came across this acronym first, let's say, in 2018, so about five years ago.
To me, software-defined vehicle and CASE are somewhat two different perspectives on a very similar thing. One describes more how the physical product of a car is evolving. It becomes connected and connected to digital services.
It becomes autonomous. It becomes electric and so on. Also what we see, the shared aspect of it, we have more and more services where you can basically buy mobility rather than buying the physical product. CASE to me is more about the product, the car, and software defined vehicle, from my perspective is more about how is this implemented.
This is obviously implemented by physical components, but much, much more also right now because of the software that is running on this. Sriram, would you agree? Absolutely. I can only think of an analogy. Many times these days cars are compared with phones very loosely. Just to explain CASE, I think when there was these Nokia phones, the Blackberry phones, and then there came touch screens.
That was an evolution. I would see a connected car as an evolution of a car. Of course, electric is very clearly a different powertrain, and autonomous is a very different way of driving your vehicle. A shared mobility is to bring in new business models to the ecosystem.
The common denominator across all of these evolutions is software. I think that's where I feel today there's a lot of talk about software-defined vehicles. Maybe to add to that, because you mentioned-- Often we hear this analogy, the smartphone on wheels. I think there are many aspects why I don't like this analogy. I think if we think about right now, software becomes the differentiating factor for the functionality of a car because of infotainment and ADAS, AD systems, but I guess it won't be very long where you set the expectations, and that is similar to a smartphone. I buy a car and over the next two, three, four, five years, it gets updates and it adds to the functionality.
Same you have with your phone. I think there the analogy of smartphone is good. I guess we will also come to the point where a car is more about-- Think about you buy €1,000 PC from the electronic store right now. It's a box. It has some hardware, but within hours you can install software and you can make it a workstation.
You can make it a gaming PC. You can make it a media server. The software defines how you can use it, and I think the more we move away from this privately owned physical product car to more they're just devices for mobility, the more we will see aspects of those.
Through the software, you define how the car can fit into a larger system. That actually opens up a question I'd like to ask is where does security and those types of things live in this world? You talk about things updating themselves and so forth. My computer actually updated right before this recording. I'm like, "Come on, finish in time for the meeting."
If that happened into my car while I was merging on the highway, that would've been very bad. How do we balance this, turn your thing into whatever it's you want and security with this ability. I read this book called The Car Hacker's Guide Handbook, or something like this, and it begins with the attack vectors of a modern car.
I looked at my 12-year-old Volkswagen and no, it doesn't have this one. It doesn't have this one. It doesn't have this one. Yes, over time, obviously, the potential attack vectors of a car they increase. I don't think it's that much different to connected devices. We got from 2016 onwards with the IoT world. You have to think really hard about the threat modeling and about what are the things you want to avoid.
Because I think what becomes clear, if I have physical access to a car and a screwdriver and time, likely I can't do much to make it 100% secure. When it comes to, I can directly connect to a car through the Wi-Fi, Bluetooth, or whatever, and can do stuff without even having physical access to it, this is something we clearly need to avoid. I think the worst-case scenario is somebody takes the firmware update server over and has a malicious software update for all of the cars that are out there. That's the worst case. I guess very similar to systems where we have connected devices, we need to have those different scenarios and then put measurement into that.
To be very honest, I think that we need to adapt lots of practices we find in other domains to this one, but I fully agree with you. I don't want to be on the Autobahn and then have a software update. That's the easier thing to solve, I would say.
[chuckles] When you think about manufacturing, there are many, many different players involved, and the whole automotive landscape is filled with-- Obviously, you've got the main manufacturer of the brand, but this big supply chain and many other people who are contributing to that. When I'm thinking of software in this space, it almost is this, I suppose a collection of many different bits just similar to the hardware that's being put together. Is that true? Is that how you view this world as well? You've got different pieces of components by different people having to come together. I would definitely think so.
Just because you're talking about software and automotive, not that software did not exist in automotive even before. Let's say Michael heard about CASE in 2080, software always existed in cars. Let's say even in today's car there are about 100+ ECUs, which means there are about 100 million lines of code return. Even in today's world, this software comes from different players.
This is not going to change, but just the fact that who's going to bring in this software in tomorrow's car will probably change. There will probably be predefined roles in our OEMs did some part of the work, our tire ones being brought in some part of work. Today hyperscalers can bring in that little bit different kind of work. The ability to bring software into a car basically is going to be different from different set of stakeholders. Very clearly the number of lines of code is just going to exponentially increase.
I think the world is not going to be different, just that the role and the software that different players in this ecosystem bring into the vehicle and the different layers of the tech stack, this is definitely going to change. A modern luxury passenger car has about 100 electrical computing units, ECUs. Computers, some of them are very, very small microcontrollers. Some of them are almost full-blown PCs. If you think about you have a 100 different computing units that have to collaborate together, this is a very complex system. Obviously, there are things where you divide then the complexity.
I think what is changing now also in the era of SDV is the architecture. It tends that there will be fewer, even more powerful computers that run a lot of the logic and there will be smaller units that are very tight and close to the hardware, as in, I need this piece of software for the airbag, and when I change the airbag, I need to change this. Also then you have this abstraction of, oh, this is taking care of this, the emergency braking as an ADAS function.
This might then be abstracted. Right now, people think really hard and design upfront how all this collaborates together. What a lot of people are aiming for right now is to have this hardware abstraction layer in between so that you can lose use business logic on different variants of hardware, if that makes sense. Who owns the customer experience in this world? That's a fantastic question. All that's been done, I think, at least in my personal view, and that's where the interesting game is, and I think in my view, it's definitely the OEMs or the manufacturers because ultimately people buy cars for a brand, for a logo, for their convenience. Ultimately, they are responsible, in my view, for the consumer experience.
Yes. I think the customer experience is defined besides the physical product of the car and how it sounds and how it behaves on a physical layer by the screens you see, and by the functionality, especially in the ADAS area. These are the two things.
What I find interesting that some of the OEMs want to keep those things really, really close to the heart because that's where the innovation is happening. At the same time, these systems are very, very complex and just very expensive to develop. What you see also is that some of the OEMs are moving more and more to things like Android Automotive, which is basically then an Android system running in infotainment. Because think about all the features there, it's just a lot of code.
What we also see on the other big part of this and the ADAS and AD systems that you have, specialized companies, for example, Mobileye or Nvidia, that provide them the sensor kit and the computing hardware and the software for it. I think as an OEM, you should keep those things very close to you because that's a differentiating factor. At the same time, you also have to make a business decision. You can't write every single line of code yourself. That's not possible anymore. Clearly, a lot of new hardware is also being developed at the same time.
At the same time, you also have to develop software on top of that. A while back, you mentioned this concept, a layer of hardware abstraction on top. Give a bit more example on what that might actually mean? Does it mean you can swap, like you have a piece of unit, it goes defective and you can swap that out and everything else in the system still works? What did you mean by when you said hardware abstraction layer? First of all, it's splitting the software into the pieces of the software that are hardware-bound, meaning different hardware would require different things there. Very close to the actuators and sensors of the car and then you have the more functional and business logic on top.
That's a cut you probably would like to have, which is, to be honest, not given in a lot of places that you basically write the features again and again with every new hardware that's coming all the way. It's also about the level of abstraction you have in the interfaces. Right now, it's not uncommon that you plan the communication on a very low technical level. This integer is sent from this ECU to this ECU, and it means that's the velocity or whatever. When you think about a hardware obstruction layer, you want to move away from this very, very specific integer to more domain-specific interfaces.
In some cases, the way you're describing, some of the domain interfaces given the ultimate experience that you want might be something that the OEM actually ends up defining so that they can work with multiple different suppliers in that case. I think, Sriram, you had mentioned software isn't new in this space, but clearly, I think software wasn't really moving at the pace at which we're seeing it, or even customers expected. You expect your phone or apps to update on a fairly regular basis.
Given the manufacturing industry or background, a lot of the car manufacturing ethos needs to come from-- What's the shift or what are the things do you think the auto industry can learn from other industries that have like adopted software or software engineering practice a lot earlier? In my view, automotive industry in its tipping point that way. I think automotive industry has always been learning from the other technology spaces to make the experience in a car better and also to make mobility safer and efficient. From an engineering point of view, this evolution has always been there. In the recent past, and of course in the future, if I can think of three things, I was thinking of A, B, C, D, but I could only think of A, C, and D. A is in a sense the architecture. A lot of emphasis is made on the E and E, the electrical and electronics architecture in a car.
This is fundamentally improved a lot, and this is creating a lot of efficiencies and a better way of writing software and therefore delivering value. The other two aspects is the play with cloud and data. Let's say the electronic control unit are always just seen as an embedded device. Today, these devices are becoming edge devices and they're easily interfaceable to the cloud.
Today's cars produce so much data. With the ability to use this data effectively, I think the value that we are able to deliver in mobility has improved. I think these are three areas which very clearly the automotive industry has stood to gain from the technology industry. What we have to understand is 20 years ago, the software for the car was not the significant cost factor when you developed the car.
That's a very, very small portion. Having profound capabilities and also capacity in software development is not nearly as important as it is today. Therefore, also, the ways of working and the practices have been optimized to make the start of production. When the factory is ready, the software needs to be ready to make it as efficient as possible. Software was almost treated like a small hardware component.
Now this complexity is much bigger, so this already doesn't work that well anymore. Also what we have to understand is in the era of SDV, the software for a car is never done. Just because we have the start of production, doesn't mean we stop developing for this now. This massively impacts also the processes within the OEMs and the tier ones, but also the collaboration with the partners.
Before that, you can write a spec. You implement it. You test it, and if this is a very waterfallish long-term thing, that's okay as long as the quality is good at the end, and now you have to think about, "How can I do this in a much more iterative way?" I think this is one of the things that we know from the web and cloud world, the saying is there, "If it hurts, do it more often."
The more often you do things in smaller chunks, the better you get at it. I guess that's one of the paradigms that need to be adopted in a certain way when we are developing software for cars. I think the link you drew over there, it just definitely resonated quite a bit. You can't really think of it as a journey with a defined start and stop. The expectation is you have to continue to evolve it, and then you almost have the car as a platform where really to accept updates of software that need to be continuously delivered. The shift in the mindset of something of, okay, you manufacture the car, but actually, in some ways, that's not just the end product and the end product can continue to evolve, and that shift in mindset.
One thing to add there, because there are other industries where you have heavy regulations and compliance requirements as well, but in the automotive industry, that's also given. If you now design a software, develop it, and test it, then you basically also do the audit that it's allowed to drive on on the public road. In the world of a software-defined vehicle where you say, "Want to update the software or certain parts of the car every month," you also need to find more iterative and other ways how you fulfill the compliance requirements and also how you do the audit process. I think one thing we can also see in other industries and in other parts is, keep all the information that you need for this as close to the code as possible. In a lot of other industries, we're speaking about architecture's code because if the architecture is also defined within your code base and you have a pipeline that produces the diagrams for this, there's a much better chance that it's congruent with the code. The same thing goes then for the requirements, for the functional safety, protocols, and documentation.
I guess that's not one thing we just came up with at ThoughtWorks, but this is also something we see in the industry right now happening, that people try to move away from SharePoint folders and Word documents to X as code. Which brings me a loop back to, we talked about customer experience a little while ago. I'm not going to throw the manufacturer under the bus, but my partner and I both have vehicles from the same manufacturer.
They did a software update that alerts us if there's an emergency vehicle ahead, which sounds like a great thing, "Hey, there's a collision ahead. There's an ambulance on the side of the road, be careful." In truth, it has tons of false alarms. I'm sure it worked well in their controlled environment, but they had to pull it back about a month after launching it because people were constantly being more distracted. We would talk about customer experience upfront and the OEM owns that, but how do you manage that over the life of a vehicle? We keep ours for six to eight years. How do you recommend to our clients or manufacturers that they take that into account as these systems are evolving? One aspect is a lot about shifting as many things left as possible.
Shifting left in the sense of, do the testing, the verification as early in the process as possible in the sense of testing software with cars, with physical cars is slow and expensive. Testing functionalities in the wild on public streets is even more expensive to that. What we see is that people put a lot of effort now into simulate things as much as possible in a virtual environment.
I think this reminds me a lot of what we see in software development as a test pyramid, where you want to do lots of things on a unit basis and some things on integration basis, and the functional basis. You want to do lots of things on a developer desktop, then some of the things in virtual environments, some of the things on test benches, and then do only a few things on physical testing. I think that the better you get at the capability of testing the real world early in the process, the likelier the better quality you get out.
I don't think it will prevent cases like you say, that we need to roll back functionality because I much prefer that functionalities on the safer side have the false alarm rather than the other way around. This reminds me of a thing when I was at a conference about autonomous driving, some person said, "Always remember, ask yourself if you would put your kid in there. What you just developed, would you put your kid in there?" I think there will be a long process. Virtual validation, virtual testing is clearly one of the levers, but I guess we will just have to accept that we'd rather be on the safe side than on the just throw it out and ship it innovation side. Are we seeing methods that we use in other-- like digital twins? Are we seeing those kinds of things? Because I have the sensors on the highway. How far away are we from that, where I can actually virtualize using something like a digital twin, the road test without being on the road? Yes, I think this is a huge topic.
If I look at what is done in the autonomous driving space, where you basically not only record thousands of miles of data as sensors input, and then use them for the testing of your newly created software, but also that you use basically synthetic sensor data. You generate the images for the camera inputs and so on and so on. I think Nvidia does some talks about this. That's clearly one thing. Also, I think the tools and the environments just starting to mature.
If I see something like a digital auto there, I can basically write the functionality of a component of a car and test it in a fully virtual environment. Things will evolve, and I think the concepts we see from the web and the cloud world, all of them almost apply. When it comes to physical things, things are always more complicated and just larger. I just like to add one other perspective to this.
As much as we talk about virtual validation, the very fact, Ken, you mentioned that your car was able to roll back the feature that you didn't like. That in itself is a good step forward. Years ago, or let's say even in recent past once a manufactured car comes out of the factory, you just can't update it anymore. The value in the car is only depreciating.
Today's car, by adding these features, the value of the car continues to increase, or at least, let's say it does not depreciate. Let's be honest. I think all manufacturers are also trying to understand what are those best use cases.
It differs from geography to geography. It differs from age group of the people driving it, and also the ability to put in the right amount of technology at the right price points. I think all manufacturers are learning this to provide the best mobility experience. I think the very fact that you said ability, rollout function and possibly also update is indefinitely a positive step and a good learning experience for the manufacturers as well. Now, slightly maybe changing tack, but I know we've spoken a lot about the context in which we are operating. I'm just interested in exploring certain trends or innovation themes, things that you are beginning to see.
Clearly, there are a whole bunch of new languages, frameworks, and different approaches that have come up over the years. Are you beginning to see any of these gaining interest, adoption in the space? Is there a particular favorite choice of language or framework that if you were to build something as a component in an SDV ecosystem, what would be the default that people tend to go to? The default for embedded automotive development is as a programming language, C++. Then you have CAN and some IP as the network protocols. You've got a huge standard on the AUTOSAR consortia that's basically it is the de facto standard, at least for especially German OEMs. When it comes to the HMI, I think especially QT is the thing that is go-to.
I think in all those areas we see new technologies emerging. People are starting to try out new things, and people are starting to adapt new things. What I find personally interesting as a programming language is definitely Rust. We are very involved also there. It just eliminates a big amount of things that you can't do with C++ and all the mistakes and errors you can make.
It just eliminates that, and it's on the same level of performance as C++. Also, I think what we see is that a lot of people, especially in the autonomous driving field, are using ROS, Robot Operating System that comes more from the robotics and manufacturing world. It just seems that the concept of nodes and nodes collaborating together seems to be very good at iteratively adding functionality there.
On the HMI space, yes, I think people besides Android Automotive play around with ESLint, React Native, and things like that. We always-- [crosstalk] I'm sorry, what's HMI? HMI is a human-machine interface, and that's basically the word for my instrument cluster. The stuff that's in front of me and the infotainment, the stuff that's in the middle. Sorry, I should have explained that. We have to remember everything needs to be safe and certified before being deployed to road vehicles. Adoption will be slow, but definitely, things are moving there.
Sriram, you're smiling. You want to add to that? No. When you said human-machine interface, I was only thinking of what my colleague said.
It's no longer just the interface. It's probably human-machine interactions these days. [laughs] In the evolution of this place, clearly in other parts, Michael, your reference it's getting quite similar to web applications or other parts of software development. One of the things that we have definitely seen is the increasing use of open source, or open source by default in many other industry and sectors.
Are there open source framework tools, like are OEMs or manufacturers contributing or collaborating towards more open standards? I think there has been a huge increase in the last two years, just to name a few things. I think consortias or collaborations like COVESA or Eclipse SDV, there you see lots of movement and also OEMs contributing to open source projects. To be very honest, it's a mixed thing. Some of the projects are to try out things, to showcase something, or to do some research. Some of the things are meant to be put into production, and for some, you also don't know.
Remember when we had this big data wave and with Hadoop where there was like a zoo of different things? Some of them people forgot about and were discontinued. Some of them became a de facto standard. I think it will be very similar there. Also, especially when it comes to the standards of data and vehicle data outside of the car, VSS and VISS are really interesting things that are picking up pace right now. At the same time, I would not make a prediction about the role of open source software for embedded cars.
Embedded software, historically that has been difficult for adoption. People don't like to give away their tea. It's the old open-source discussion. We've had that in other industries. [chuckles] Which also is the standards discussion. With apologies to the fact that I know that this is an international audience in the United States, one manufacturer that's advertising, "Hey, our car can drive itself," is only on specific highways in California and Nevada, which is two of our 50 states.
It's like, "Well, why are they even allowed to advertise in other states?" Then you have on the other end of the spectrum Teslas that people think they can do their makeup or their organization or whatever as they're driving down the road, which is probably not accurate. How important are standards and stuff to this to be able to go forth and say if we're going to interact with an ecosystem like a smart city, or if we're going to interact with fleet management software or that thing, are those evolving or is it really just a race to Blu-Ray versus HD DVD at this point? I think standards, in the sense of I publish an interface, or I publish a standard, I think even in the automotive industry, I wonder how much they can keep up with the pace of innovation. Because if we think about other industries, show me where people thought really hard, came up with a standard, and then everyone implemented it. I think much more we see people write good services, good software, maybe even open source software, publish it, and then it becomes a de facto standard. I would not be surprised if that happens for certain aspects.
For the automotive industry when it comes to regulations, especially when it comes to putting autonomous driving from experiments and research to operations, the European Union and the German legislation passed a law about this, which is I think the first of its kind in the world, and that seems to be very reasonable. I guess, yes, we need to adapt our laws and rules about doing these things in the world. I guess we are there definitely on the point where it goes to what the legislation thinks about how will this be in operations, not just how we can develop and test it. I think standards is one aspect, regulations is another. The way I look at standards is it's going to speeden up development. Many of these consortia when different, let's say OEMs, Tier One, hyper scalers, tech companies come together and create frameworks or standards, I think it helps in two reason, one acts as a force multiplier and avoids duplication of creating the same thing everywhere.
Also gives opportunity for, let's say, newer players to come and use these standards, and developing then the sense or restricting a set of players to only work in a particular tech stack space. Regulations, I think is going to be extremely important. As Michael said, he doesn't like the things, smartphone on wheels and that scenario is automotive are very, very different. Why regulations continuously it's very important to keep track of. That's something that's not going to be negotiable at all in an automotive space. because all said and done, it's extremely safety critical.
Therefore, adhering to these regulations and ensuring whatever technology improvement we do in this space we keep safety at its forefront. I know we've covered quite a lot of ground and clearly this it's a broad topic with many, many things to deep dive on. That definitely was one thing, maybe Sriram and Michael, I think one question I did want to ask both of you, you've clearly both been immersed in this field, in the space for quite some time, and spent some time thinking about it. If I were to ask you about one thing from your point of view that either you think over the next few years will become quite key or quite important for anyone looking at like SDV in the space. One thing if I would say it'll be great for our listeners to say, what would two experts in this space be talking about? I think what experts would be talking about is not just about moving from A to B.
Mobility is no longer going to be just movement from A to B. It's going to be more than moving from A to B. It's about the experience. It's about the interactions with the ecosystem. I think that's what mobility is going to be. Having said that, I think mobility it's a very integral part of being human.
People definitely want to be moving around. In that sense of moving around, how can I create a better experience, a safer experience will be the focus of people who build cars and people who build software for cars. Michael. When I finished college with my computer science, the coolest thing in the world for a lot of people was to work for companies like Facebook, Amazon, or Google. I could make an argument that this changed a bit.
I think OEMs who embrace the era and the transition into SDV and fully unlock that what software can do with cars have the potential to take this place. For me as a developer, the first time I was sitting in Stuttgart and somebody in Berlin was typing on a screen and the window rolled down in Stuttgart, it was a tiny thing, but it was so rewarding and so much fun, and that I would think can be a big thing for companies. Awesome.
Thank you, Sriram and Michael, for sharing your insights on this topic. SDV clearly is something that we all will be keeping an eye on. Thanks for sharing your insights and perspectives on this. Thank you, Ken, as well for joining me as a co-host. -Thank you. -Thank you.
Thanks for listening to the ThoughtWorks Technology podcast. I hope you enjoyed the episode today and we look forward to you joining us on another episode in the future. Thank you, all.
[music]
2024-02-14 08:30
