Process, Methods, and Tools: The Key Enablers for Software-Defined Vehicles
Dr. Christian Müller, Vice President, Global Software Center, ZF Group
The notion of added value in the automotive industry is undergoing a shift. In a sector where hardware has been the main generator of profit for more than a century, a new rule now applies. Going forward, hardware will primarily form the platform on which software is later going to drive the vehicle.
Like smartphones, cars are increasingly turning into a technical platform where software is brought into play. To this end, the necessary requirements must be met: having fewer but more powerful ECUs, smart actuators, connectivity, and a service-oriented architecture where hardware is decoupled from software and driving functions are partitioned.
All these changes mean new requirements for the development of automotive software.
The tool landscape must be modern as well as up to date. Process, methods, and tools must be closely aligned and become a key enabler for the development of software-defined vehicles.
Published: 3 Jun 2024
Welcome also from my side. Thank you very much for the invitation. And what better evidence could you have that the automotive industry is completely in that journey of software-defined vehicle. So we have a sports car manufacturer talking about tops being the new horsepower. And you have a former gearbox company speaking about process methods, tools, and software. So let me show you a little bit of insight from a tier one perspective.
So, unfortunately, I'm not able to show you such beautiful cars like you did before. And to enable all these great customer features, of course, we need a lot of components and subsystems. And that's our role as a tier one. And as mentioned already, some of you still might note ZF, those are the gear company here. And, yes, we still produce gears and we still produce gearboxes, but doing much, much more.
And also, in the software-defined vehicle area, if I talk now a little bit on our current product range, you will see software is all over. So we have multiple thousand software developers now also in our company working on software already since years. And this is just a short overview of our product portfolio which we're dealing with, of course. Also, automated driving ADAS systems, but as well integrated safety systems.
Then on the lower side, you see everything which runs your vehicle in the x, y or z-axis. So everything, vehicle motion control, braking, steering systems, dampers, and so on and so on. And then, of course, also electric mobility. So having inverters, electrical drivetrains. And all of these products which we today offer for past cars, trucks, but also off-highway applications, have one thing in common. All of them are highly driven by software today.
And let me go a little bit about what changed in the past and the evolution, and why software is so important also for us, and how we deal with this complexity which we see, and this development. And let me go one level deeper in system and software, especially software architecture. And if you look here on the left side, this is where we are coming from. This is what we are doing since years, these more or less monolithic systems. So ECUs packed with a lot of functionality, highly distributed, connected with ethernet, and so on and so on. But mainly, local systems which are interconnected with each other.
And if you look at these software layers, of course, we are very much AUTOSAR Classic-driven, like the whole automotive industry in this area, having the functionality-based software with hardware altogether in several boxes. So those are all separate boxes distributed in the vehicles. And if we now look at how this developed, because the right side, this is the reality which is already there. It's not a vision. This is really what is today already there. And, of course, we still have these small boxes now called smart sensors and actuators with also still a lot of functionality right next to the development of everywhere where we need highly time-critical or safety-critical functionalities.
This is still, of course, very close and very embedded in these systems, but we already see the function block is a little bit smaller already than in the past. And where is all that functionality? Because all the functionality exploded, of course. And this is now what we see in all these new architecture areas. HPCs, domain controllers, zone controllers, however you may name them depending on which architecture you are currently. And this is where a lot of functionality is now there.
And you have a new OS. You have Linux just shown also there. So still extremely powerful hardware, as we've just seen in the slides before, and a lot of functionality. And the interesting thing, even connected to cloud applications and so on. Whatever we've seen. So you already seen these software architectures. It's an extreme jump to completely different complexity and completely different way of developing software on the technological side.
I will later on talk a little bit about, of course, processes, methods, tools, how we deal with that on the technical side. But before I go to that, I would like to put the focus also here on the different cooperation models because that's as well something. Beside all these technical challenges which we have in the technical changes, techno revolution, I would say, which we have, it's also a revolution in the cooperation models. In the past, it was typically such a monolithic system. Came from one supplier. They packed something. Of course, they had some subsuppliers for some software modules, maybe some hardware suppliers.
But overall, it was everything in one hand-delivering to the OEM, and OEM integrating that monolithic system. If you look at today's system, it's a highly, highly interconnected network of partners who interact with each other. And it's not unusual that in today's HPC, you will find software components for more than 30 partners. And that is an additional on top of the technological challenges. This is a huge challenge on the cooperation side because people have to be interconnected. It's a mindset thing, also. You have to work together on such topics.
Sometimes, it's not invented here, a challenge which you have to overcome. And also, of course, on the technical side, again, the process method toolchain. They have to be interconnected to be able to exchange data. We just learned about the big loop, which we have to close from the customer. And, of course, inside that loop, there are also the component suppliers. And you have to make sure that whole loop is really running completely seamless in there. So that's additionally on top to this.
And that's why I'm also personally convinced that we not only need a new technical solution, new technical approaches to cope with these challenges, and to make these great new user experience possible, and deliver great new functions seamlessly to the customer, but as well in how we cooperate together. And that's why I think it's so important, also, to have such conferences like today where from a lot of different angles come together because the cooperation is not only between an OEM and tier one, but it's really the whole network, including tool suppliers, where we need that very close cooperation to make this really possible here and bring it on the streets.
Let's have a look a little bit on one very specific aspect. And this, also, I mentioned already, that new functional distribution we had before. We had the function all in these monolithic systems. And if you look at today's architectures, you see distributed. And we as a tier one, we are delivering our products to a lot of different OEMs. And, of course, our customers are at different stages here and might have also a bit different approaches on these architectures.
But, of course, we would like to integrate as much of our functionality in these different architectures. And that means, of course, very important for us, we have to be ready for being able to integrate in different architectures. So we have to highly decouple our functions, our algorithms from the hardware, which is underneath, which is a completely different approach than before, where we developed completely monolithic systems. So that's what is very important, that we are able to, at the same time, supply two different E/E architectures with similar functionality in these areas.
But on the technical side, completely different approaches here. And as well, also, some technical details. Of course, control systems, still very signal-oriented. And that's still the case, of course, in new architectures as well. But there's the new service-oriented architecture, service-oriented functionality which comes additionally in place, which we also have to support in that journey here. So there's not the answer for a tier one thing. OK, here's my function distribution. This is how we will do it, but we have to be prepared to do it to integrate in a lot of different architectures and scenarios.
And, yes, as we've also seen in the previous presentation, I'm not talking about any vision for some years or whatever. But, no, all these topics are running on the street. And this is also true for ZF. And I just brought here one example of product cubiX, which is in the chassis control area. And there, we have such a completely decoupled new functionality now already in series, in vehicles running on the streets. So, again, we DON'T have time anymore for any vision to prepare or whatever. We are just inside. And we will never be finished with our process, method, toolset, or whatever. We always have to improve and make sure we deliver great functionality altogether to our customers in there.
So now let's talk a little bit about, of course, today, process methods and tools as well. So we saw all these great products, great approaches, how function are distributed, and so on. And we believe beside all the cooperation, mindset, discussion I mentioned already, we need highly great state-of-the-art processes, methods, toolsets to enable all of these. We saw the big loops already. And we also believe in having that, I would say, classic standards, which we have also from the IT industry, which, of course, we have to adapt also in the automotive world.
And it all started with some agile development methods, continuous integration, continuous delivery. Everybody had some Jenkins servers running somewhere and doing this stuff. And this now really scales. And we see that journey towards DevOps really closing the loop, of course, in first and during development to test vehicles to HL systems, but later on until the end customer, as we've seen. So really, we have to close that complete loop from planning until monitoring.
And I mentioned already, it's not only about technical challenges, of course. We have to focus on process to see, OK, how can we adapt our processes? How we can we highly automate our systems, but as well also the culture that also our developers think always through the whole cycle and see, OK, what is important at the end? And, yeah, it's nice. I put something here from a colleague from Microsoft.
"DevOps is the union of people, processes, and products to enable that continuous delivery of value to our end customers." We're all engineers, of course. Everybody likes to create great solutions, but that's what we always should have in mind. What is the value for our end customer in that? And why do we do that? Why do we believe in, really, these cutting-edge processes, methods, tools? And I will go into a little bit more details in the next slide as well.
And one is it's always about quality and efficiency. And it all starts with the beginning of a project. It's efficiency through the fast project setup. So we want our developers right from day one to be ready to deliver software into the vehicles. So having the complete toolchain, including testing everything already ready right from day one. High degree of automation I talked already about. And this really affects the whole tool chain.
And this will never be finished. So we always try to improve and add some aspects in there. And that's specifically challenging because we are not starting on a green field. We are not developing completely new software, but everybody of us has a lot of heritage of these monolithic systems which we had. And this is something. And everybody who dealt with AUTOSAR Classic already knows it's not meant for CI/CD and not meant for cooperation. And this is sometimes where we have to find new ways. And this is also where I'm convinced we only have the possibility to work on this all together.
Also, validation. I mentioned it already. All the overall validation of these ADAS system, but it starts really very early. It starts with code checks. It starts with static code analysis and so on, where we have these mandatory checks included in our toolchains already. All of this, very important. Also, dashboards. And it's not a dashboard. That's what I always tell also my engineers. The dashboard is not meant for the high management to say, beautiful, nice graphs, or whatever, or for the next ASPICE audit to show some nice things.
But, no, these dashboards are the daily tool for each and every developer to see, where am I? How did my new changes pass in the toolchains? Where do I have any flaws? And so on. So that's where we truly believe and we need these automated dashboards to really have the overview of the current state of the whole DevOps cycle. Where we are, what is the maturity, and so on and so on for each stakeholder starting from each and every developer.
Of course, then also management. But really, that should be the daily life because then we also only believe then you have the real and the good data in these dashboards. Also, very important, efficiency. We don't have to reinvent the wheel. Engineers, also, a lot of time tend to, oh, I quickly developed some small tool there, or I have some student developing and hacking something or whatever. And sometimes, this might still be good and some even necessary. But if we look at today's world and the toolchain offering, we truly believe we can really run a lot just with standardized off-the-shelf.
And if something is available on the market, we're not a tool company and we're just users. And we want to have a highly efficient toolchain for our engineers. And we truly believe in let's use standard as much as ever possible, and only where really needed. We adapt. We build interfaces or whatever. This is as well true if we look at the corporations which I mentioned. Also, of course, standardization, interconnection, interfacing with other tools. It is much easier if I use some market standards or even open interface standards than compared to some homebrewed development which I have to maintain.
And we saw it already, cloud-based. We saw these huge amount of data which we deal with. Of course, this is something which we don't do anymore on an on-prem system. But for us, the scalability is extremely important because maybe I have to do tonight 1,000 new software builds for all my products. Next night, maybe a little bit less. So I need that flexibility, that dynamic possibility to scale via an advanced cloud infrastructure.
To get all these benefits-- and as I mentioned already, this is not a vision. This is not a vision, a dream, but it's running in real. And here, you see some examples of the toolchain we established at ZF. And we are continuously developing and improving. Yes, it's already used in serious projects, but it evolves over time. You also don't see all tools which we include here, but a part of it. And we're convinced that this holistic approach, and really closing that loop, and combining, of course, different state-of-the-art tools on the market. So that's a very important aspect to be able to deliver. And, of course, it's about time. It's about integration time to be able to deliver faster.
This 44% is also not some theoretical number, but it's really measured in one of our projects which we were able to achieve by just switching that project from the former process to the new one. We didn't change a lot, but we immediately gained 44%. And if I get that with every build, every integration, of course, that's huge. And, of course, we're still targeting to even improve more and improve more in these areas, and see where we can become better here.
And, of course, we also have, as a customer, some wishes to the tool providers and some expectations for being able to achieve that. And state-of-the-art processes and methods, there, I don't mean necessarily our process methods to develop our products, but as well for the tool suppliers to be able to deliver their tools as well via state-of-the-art process methods. So if I want to use DevOps for my products, I want as well that I don't have to do, I don't know, a six-month project to introduce a new Simulink version and to prepare everything, to prepare migration plans.
It has to become as seamless as my own software development, of course. Highly automated I mentioned already. And automation is not only, also, of course, having these connections, these pipelines, being able to automate test cases. So that means also the toolchains have to offer options for automation, offering APIs, offering interfaces to get data from one or the other tool in this area. So that's a very, very important aspect which we need for modern toolchain. CI/CD ready. I mentioned it already. It has to be able to include it in pipelines as well.
Very important aspect, high availability. Of course, if I want to run these very fast loops for my own software and I have flaws in a toolchain in there and it always breaks in my pipeline just because something in the tool doesn't really work, that's a no go in that area. So that's why we need a really high availability of the tools as well here. For us, very important. We decided on a pure cloud approach. So it has to be cloud-native. Yes, of course, we have to lift a lot of these, I would say also, heritage tools via some workarounds into the cloud as well.
But it's always our goal, our expectation that we have it as a cloud native approach here. And cloud native not only means on the technical side, but as well on the license model side. And we had a lot of discussions when we built up in the last few years this toolchain, a lot of discussion with also smaller tool vendors which were just not ready. They said, OK, how many users will use that tool? And we said, no user will use it. It's just one. Technical users in the pipeline will use it. And the license model just not ready. They were just not able to. And it was a huge discussion.
And that's a very important expectation which I have towards MathWorks. We are having a very good cooperation, and also, some pilots on that journey where we tried also out together some things. And I think that's very, very important. That's also that cooperation model. And it's absolutely fine if not everybody has perfect solution, everybody already available because then we are not yet done. But having that close cooperation and work on these challenges together and see, and try also something, also maybe fail in some areas, and then work on these areas. Very important.
Continuous and seamless rollout. And this is on one technical side, but there are also regulations with all the ASIL standards you need to do, too. Qualification and so on you have to ensure. And in the past, for us, that meant IT got from the tool vendor a new version. Then they did some weeks, maybe months, some tests. Discuss with the tool vendor again. Got some bug fixes or whatever. And then after some months, we were able to roll out the new version, which was released, I don't know, six months ago. And that's, of course, nothing we want to have anymore in the future.
I want my users to be able to benefit directly from a new version live, ideally as a software, as a service. But that means, of course, also that there are new demands on the tool vendor side. They have to do some checks before, or whatever. And honestly, of course, with companies like MathWorks who are already in that industry for a long time, these discussions are much easier because, of course, MathWorks knows that also from a lot of other companies, the main challenges we had with the, I would say, classic IT companies who don't come of the automotive industry.
And to name one prominent example is Microsoft. We have a very close cooperation with Microsoft using Azure DevOps as a core for that DevOps environment. And we work together with Microsoft also on the tool qualification topic. They work together with certification company. They publish it. So that's why I can openly discuss it, work together with on that. And they opened up their development processes for them and made sure they get approvals on that. And that made our life much easier because we could skip a whole test phase before we could introduce a new tool version because we could rely on the tests which were done on the tool vendor side already.
Fast optimization cycles, which is true for our own products, but as well, of course, for the tool chain. So if there is a bug, we need fast optimizations. I cannot wait for the next release in, I don't know, six months. And very important, modularization and interoperability. I mentioned already the different cooperation models. But if you also see how many-- and as I mentioned already, it's not complete, that picture. There are many different tools have to interact for being able to deliver automotive software. You need that interoperability to be able to exchange data between the different tools and so on.
And, of course, you also see some very important MathWorks aspects in here. And I think that's also a very good relationship, a long-term partnership here to make these things happen because, as I mentioned already, this is something we cannot do on our own. We presented this journey. We presented our vision. But it's only together with partners that we are able to make that happen and real.
In the interest of time, I will not go into many more details about that toolchain. Just to give you, also, a little bit of-- as I mentioned, this toolchain is never finished. So we're always trying to improve, look at new versions of tools, but as well new tools which could be integrated, which could help us to deliver even faster or with higher quality. There are, of course, new regulational aspects. For example, all the cybersecurity tools there. I think we have the most additions which come into that.
But there's one additional aspect. And we heard already about AI, about AI in products. But we see also already in that GenAI. Everybody is talking about GenAI. So, of course, I need also to have a slide on this in here. But I can tell you this is really something where we truly believe and where we already have some very nice first results of really huge efficiency gains. Let me just show you a little bit of where we see potential in applying GenAI in just short.
And there, you already see it's really across the whole DevOps cycle where we see the potential. Of course, mainly on the left side because we're talking about GenAI. The rest of the AI is also a lot on the other side. But starting in the planning phase, for example, requirement classification. And that's really a tedious job at the beginning. So we get huge requirements, documents. And you need a hell of people doing that manual work, needing a lot of time for that.
And we use it already to really fasten a lot our development right at the beginning. Requirement writing. It's priority three from our perspective. But also there, we see some nice approaches here already. And then, of course, the same on the testing side. Test case classification. Very similar to requirements, classification. Then search functionality. Of course, very important also to see. As I mentioned already, we are delivering that our products to a lot of different customers who give us all their requirements, and we must make sure, OK, where do they match?
How do they match to our product specifications? And that's also a huge, tedious, manual job where we can help us.
Of course, at the end still, the manual users, the developer is still responsible for it. We have our checks afterwards, but nevertheless, it can save us a lot of time. And then, of course, very obvious on software development, everybody talking about GitHub Copilot and so on. And, yes, we are also using it. And I can tell you really, also, I saw all these nice papers some time ago saying, let's see how this really works also for us in the automotive domain. Everybody talking about some fancy Python scripts, or whatever. But does it really work for us?
And I can tell you, yes, it works. So we have some very nice efficiency results. And we are currently in the rollout for our software developers. Of course, it doesn't help in every use case or whatever, but it already can help us a lot. And we currently focus very much on not developing our own solutions, as I mentioned. Additionally, of course, some engineers would love to develop their own LLMs, or adjust, or whatever, especially our AI experts. But we see so much potential in just leveraging what is already there in the market just for our purposes in the area. And there, we still have more than enough to do and really some nice potential in here.
Code generation, yes, also, there will be potential, but for sure that code completion thing. And everybody of you who already worked with GitHub copilot I think see how nice this works and how really efficient this can help. And, of course, at the end, also there still, the responsibility is with the developers. But there, you see how important also these mandatory checks are, which I mentioned before to make sure we don't get wrong code by this because, of course, some developers say, OK, maybe don't look at this so much in detail. Which they get there and say, looks good. They just use it. So that's why these checks and validations are even more important in these areas.
So, also, for the sake of time-- I see my time is already red here. We'll not go into more details here. Also, of course, on the testing side, test generation. And so we see a huge potential. I would love to see also much, much more in the future, really, where we see a huge pace in here. And when we started our journey for that new toolchain roughly 2 and 1/2 years ago, nobody was yet talking about it. And now, we have it running in serious projects already.
So that's, I think, a very good example of how fast you have to adapt to new approaches which are there in the margin. Not only have to, but also, what huge potential is there by doing this because coming back to the initial challenges, we see the change in evolution. We see a huge raise of complexity in these chips and software. We saw the tops, which are increasing. We see the different cooperation models, new architecture, new software architectures.
We have to decouple the hardware from the software. And we are sure that we can only cope with it not by just adding more engineers or whatever. It's only by really having highly efficient process methods, toolsets to be able to cope with these challenges and deliver great products. And GenAI might be one of the aspects which really support in this area. Thank you very much and happy to answer questions.
[APPLAUSE]