Expert Perspectives: A Conversation About Variant and Configuration Management in Software Defined Vehicle Development
|
In this blog, we will preview a section from our video, “Expert Perspectives: A Conversation About Variant and Configuration Management in Software Defined Vehicle Development” – Click HERE to watch it in its entirety.
Expert Perspectives: A Conversation About Variant and Configuration Management in Software Defined Vehicle Development
Welcome to our Expert Perspectives Series, where we showcase insights from leading experts in complex product, systems, and software development. Covering industries from medical devices to aerospace and defense, we feature thought leaders who are shaping the future of their fields.
We are excited to introduce Florian Rohde, an expert in electrification, variant management, software defined vehicles, continuous integration and validation, and AI in automotive development. With more than 20 years of experience in the automotive industry, Florian has worked with companies large and small, from Siemens to NIO to Tesla Motors.
In this episode, we discuss:
-
- Challenges in software defined vehicle development
- Variant and configuration management in SVDs – and which companies are excelling
- Balancing documentation, complexity, and speed
Below is a preview of our interview. Click HERE to watch it in its entirety.
The following is an abbreviated transcript of our webinar.
Kenzie Jonsson: Welcome to our Expert Perspectives series where we showcase insights from leading experts in complex product systems and software development, covering industries from medical device to aerospace and defense. We feature thought leaders who are shaping the future in their fields. I’m Kenzie, your host, and today I’m excited to welcome Florian Rohde, an expert in electrification, variant management, software-defined vehicles, continuous integration and validation, and AI in the automotive industry. With more than 20 years of experience in the automotive industry, Florian has worked with companies small and large, from Siemens to NIO, to Tesla Motors. Without further ado, I’d like to welcome Florian Rohde, who will be speaking with Matt Mickle, Jama Software’s very own director of automotive and semiconductor solutions.
Matt Mickle: Thanks, Kenzie. So my name is Matt Mickle. I run our solution development for automotive and semiconductor at Jama Connect. I’ve been with the company at Jama for about 11 years and worked as a consultant for most of that time. And now my team handles most of the consulting and development of solutions for automotive and semiconductor. And I live out in Europe, in Amsterdam. Came over here to help start up our European headquarters. And I’m joined today by Florian Rohde
RELATED: Buyer’s Guide: Selecting a Requirements Management and Traceability Solution for Automotive
Florian Rohde: Absolutely. Thanks, Matt. So I’m in the automotive industry for about 20 years. I started as an intern at Bosch, and then I started as a junior test engineer at a company called Siemens VDO, which then was incorporated into Continental. Back in the day, we were building electric power steering systems. So highly safety critical components in your car. So I got grounded into functional safety right from the beginning. I spent about seven, eight years at that company, both in Germany and in Romania. And then in 2012, I joined a startup called Tesla Motors, and that is bringing the interesting parts to our discussions here, I guess.
So in 2012, Tesla had about 2,000 employees worldwide. I was the first member and the founder of a team for vehicle software validation. So every software release, every software functionality on the vehicle level went through my signature for about six years. I counted over 700 releases in that time to the end customer and way more software that went through our test systems in that time. And after six years there at Tesla, I was one year at NIO as a director of integration of smart components. And starting 2019, actually, I became a consultant advisor all around SDV, software-defined vehicles, and basically trying to facilitate the communication between what you can call the old world and the new world. So the new players on the market and established 100-year-old OEMs because I speak both languages. I’ve been in both worlds. So I’m helping both sides, helping the new players really to understand regulatory things and scaling and things like that and helping the established players really to understand the role of software in today’s and tomorrow’s vehicles.
Mickle: Well, I know that when we started to talk about having this chat, one of the things that you’d mentioned is that you’re hearing quite often in the industry about challenges, especially as people are trying to shift into this modern way of working with software-defined vehicles. There’s still a lot of challenges around variant handling and configuration management. You have some strong background in handling some of those things, especially while you worked at Tesla. How would you say that your approach had to change when you started to think in a more software-defined vehicles perspective when it comes to variant management?
Rohde: Yeah. I think in general, there’s a lot of challenges. Variant management is one of them. But I think let’s focus on that for the purpose of this talk. Let’s not focus on engineering culture or software skill sets and so on. That’s, for sure, other topics we can talk about. But today, let’s talk about variant management, configuration management, etc. So on one hand, I see gigantic numbers of configurations out there when you look at legacy OEMs. And somebody told me just Ford F-150 numbers, they were like hundreds of thousands or even higher than that. So on one hand, you see the companies struggling with the variety of variants actually of their product. But then on the other hand, you also see R&D teams struggling with those variants, both in how to handle them on the development side of things, but even more so on the testing side of things, especially… So I’m a test engineer, originally. And for test engineers, additional variants are usually a nightmare because it just means basically one-on-one growth of your testing efforts.
So there is a problem that needs to be solved and it’s on two sides. It’s one, how do you solve that problem in your product itself? And the other thing is, how do you solve that problem in your tool chain? So things like what you’re doing on the requirement side of things, specification, and so on. Let’s look at the product for now. So Tesla had a different approach to this problem. They actually made themselves agnostic to the variety of variants. What does that mean? That means they developed their product software first and they were designing the software in a way that it can handle pretty much an endless amount of variance. Of course, and we can talk about that, there’s challenges to the validation of things. There’s challenges to how you handle software updates. There’s challenges how you handle releases. But we had a pretty good process in place to do so. But the alpha and omega of the whole thing is that there’s a system in place that allows the software to handle the variance without being handcuffed to some process from the past.
RELATED: Strategies for Mitigating Software Defined Vehicle (SDV) Development Risks and Reducing Costly Recalls
Mickle: Okay. So a lot of the challenges that I hear, and maybe some of what you hear, is especially around the alignment of the software with the hardware in terms of releases, considering those are evolving at different paces. So since the software is evolving so fast and handling multiple configurations, how do you account for that with what you’re doing with either tooling or the product?
Rohde: Right. So I think there’s a consensus in industry by now that the hardware has to be able to accommodate new software features over time. Or in other words, it has to be designed for a little more than it originally offers at start of production. There’s still a lot of hesitance around legacy carmakers because it’s a financial discussion, right? So I don’t think from technical point of view, anybody would disagree that the hardware should be overdesigned by, let’s say, 20% so the software can start evolving over time and creating new cool stuff. But it’s always a question how you actually finance that.
The good news here is that actually, hardware and compute power becomes more reasonable in pricing. So we’re not talking about dollars per bytes in memory anymore. We started talking about dollars per gigabytes, right? So we can actually make that happen a little easier. But obviously, there’s a strong legacy of hardware driving the timelines, and then the software goes on the hardware to make the functionality work as designed and then go into the car as a component. So now in the next generation of cars, you hear a lot the term of decoupling. So you’re decoupling software from hardware. What does that actually mean? That means that on the technical side of things, you have to find ways to have your software actually handling the car’s compute resource and not as a conglomerate of several separate ECUs. So we’re talking about zonal architecture at one point in the future, we’re talking about high compute power architecture, HPCs.
But on the other hand, it also means organizationally and structurally. So when I go back and look at the Tesla example, Tesla has one software that runs on all their cars. And the cars are, for sure, not all the same hardware. As a matter of fact, I like to sparkle that in here right now because a lot of people think Tesla holds the variance low, but that’s not the case. Yes, they have only four or five models in the field, five actually by now. But they actually perform some sort of a facelift statistically every week. So while in a traditional car-making you wait for about three to four years before you put in a flurry of hardware changes, and in between, the car stays more or less unchanged. What we experience at Tesla is that every week, there’s some new hardware going into the car. So there’s some new costs down available. There’s something better available. There’s some replacement parts available. It goes in right next week. And that means that you have thousands and thousands of different variants of Teslas driving out there, even though from the outside, they all look the same.
So what we did is we decoupled the software in a way that it’s “smart enough” to handle all these variants. So the way that works is there’s a package and that package of software contains all different options and variants, and it also contains the information who is allowed to play with who, so what variant is allowed to play with what variant of the other car component and so on based on our validation and release process.
But in general, in a very simplified way, the car knows what it is, and that’s already a huge difference to a lot of legacy carmakers. So the car has a digital information about its components in hardware and in software and in mechanics. And based on that information, it receives the software package and it builds its own personalized update out of that. And it’s talking to the components and updates the components with the right versions based on the information it has. This information is on the other hand also mirrored up into what they call the mothership, so the server area. So that information is available in real-time, and I’d like to talk about that a little bit because I think it’s extremely valuable, for example, for the validation and release process to set your priorities.
So let’s say I only have time to do one combination. So I would like to reach most people with my release today. Of course, I’ll do the next combination tomorrow and the day after. But today, I have only time for one and I want to reach the most people. So I can go and I can actually look what combinations are out there that are relevant for this release and I can prioritize my validation on that. Actually, at one point, we went so far that we even took time zones into consideration that we say, “We can validate all of this large area of the fleet, but hey, that will be midnight or 1 AM by the time they get it. So they will not install it for another eight hours or something like this. So let’s focus somewhere else.” So all this information is making it extremely powerful to manage your priorities and both in research… Sorry. And both in development and in validation.
CLICK HERE TO WATCH THIS WEBINAR IN ITS ENTIRETY:
Expert Perspectives: A Conversation About Variant and Configuration Management in Software Defined Vehicle Development
SDV Expert | Speaker | Consultant at iProcess LLC
Florian is a Las Vegas based strategy consultant with over 20 years of industry experience.
After working for Siemens and Continental he implemented a continuous validation concept at Tesla in his role as senior manager of the vehicle firmware validation team. He also served as Director of Smart Component Integration and Validation at NIO before he joined iProcess in 2019.
After working for Siemens and Continental he implemented a continuous validation concept at Tesla in his role as senior manager of the vehicle firmware validation team. He also served as Director of Smart Component Integration and Validation at NIO before he joined iProcess in 2019.
Latest posts by Florian Rohde (see all)