Software Hits the Road in Automotive

Digital Engineering recently spoke with Julia Garcia Trombley, product manager for intelligent mobility and software at FEV.io, and Wensi Jin, global manager for automotive industry at MathWorks, about software-defined vehicles (SDVs). FEV.io is the intelligent mobility software brand of Germany’s FEV Group 

Can you provide an overview of what FEV.io does?

Julia Garcia-Trombley: We are known for our engine development work. We’ve been around for a little over 40 years now. We started FEV.io as an external brand not too long ago to really branch off from our traditional engine development and consulting to the new tech space, focusing on intelligent mobility and machinery.

Our group focuses on software safety and cyber security as well as systems engineering. We support basically all things that move, anything from trains, automotive of course to commercial vehicles.

We provide full vehicle development from prototype to production and in all areas of the vehicle. With software-defined vehicles, we touch every element of the vehicle abstraction level.

For context, what is a software-defined vehicle? How would you describe it to an engineer that is not familiar with the concept?

Garcia-Trombley: I would start by saying that software is already in our vehicles. It has been for some time now. We started to see the first kind of software features in the lower level safety features maybe 10 to 20 years ago.

The term software-defined vehicle is almost a relativistic one in the sense that you can have different degrees of software-focused vehicles. But the key defining feature of a software-defined vehicle is a vehicle that's actually defined by software. It’s not just having some software incorporated in the vehicle, but one where the architecture, the software architecture, is the defining characteristic of the vehicle.

How are you using MathWorks tools?

Garcia-Trombley: We have a long standing relationship with MathWorks  just in the sense that we use their tools on our projects globally. 

Wensi Jin: Our relationship is multilayered. Certainly FEV.io is a user of MathWorks tools. We also benefit from a lot of market insight from FEV.io from the car companies and suppliers on a global basis.

FEV.io created an initiative a few years ago to build a demonstration vehicle to showcase how the software in the vehicle will change and what the software defined vehicle may look like. To get to the software defined vehicle, what are the development processes, tools, the changes necessary to create such a product? And that's something that MathWorks and FEV.io collaborated on a global basis.

At MathWorks, we’ve seen that software has grown from the notion of software attached to a piece of hardware to enhance its capabilities, to software becoming its own complex product by itself. More importantly, the software is actually developed separate from hardware. It will keep getting upgraded while the hardware may remain the same.

This necessitates a few changes in the way you develop the software. You have to understand how the software works. Software testing through simulation becomes very important.

Could you talk about some of the ways that MathWorks helps you overcome some of the inherent challenges in these development processes?

Garcia-Trombley: Software introduces new challenges, especially the intricacies in just the sheer amount of code that's involved in some of these features. The architecture as well. The tool chain is one of the most critical elements of the software development process and in the vehicle lifecycle. We leverage MathWorks tools to manage the complexity of these new systems.

How do the concepts behind the software defined vehicles affect the design of the physical vehicle? How does this development work intersect with mechanical and electrical design and simulation?

Jin: The software defined vehicle is not just a software product. The software features are constrained by the vehicles and have to respect the physical boundaries or and also the safety notions when it comes to the vehicle.

So this is where I would say the vehicle aspect meets the software aspect. When we think about simulation, from a traditional mechanical-electrical simulation domain, simulation is getting better and more widely adopted in the vehicle development process.

Software needs to be designed just like a mechanical system. As you design the piece of software, just imagine I'm changing a lighting feature to turn on certain lights in different conditions. You have to simulate that in daylight conditions. You may have to simulate how this will work in a tunnel or in other conditions. There is a physical layer that has to be simulated, even though what I'm developing is lighting software. I have to simulate everything around the piece of software.

The software engineers cannot afford to work in isolation, then go into the vehicle for testing. That is costly and time consuming. And when you have updatable software that goes into different vehicle configurations, it's impossible to drive these physical vehicles with different configurations. The software engineers need a good simulation environment to give them the software testing capability they require from the very beginning.

The simulation needs to incorporate mechanical, electrical and environmental conditions, and run them at very high speeds. We also know when the vehicle is released, the software will interact with different drivers under different road conditions. In order to simulate all of that, we need to marry not just mechanical with electrical, but with the simulation of all these different domains with the relevant data.

Garcia-Trombley: The software-defined vehicle is still a vehicle, so the nature of the vehicles is still the same in terms of having physical components, having the wiring architecture, and there’s software on the vehicle today. It’s just going to expand.

But this is still a vehicle, and we should demystify the term “software-defined vehicle” in that sense. From an engineering perspective, this is complicated, but it’s not fundamentally unsolvable.

What do you anticipate will be some of the key innovations in this space engineers should prepare for, given the evolution of the vehicles themselves?

Garcia-Trombley:  I think there are different challenges for different users. If you're an OEM, you have to worry about cybersecurity related to over-the-air updates and the threat landscape being ever changing. People are going to really need to think about how they can future-proof their design so they can respond quickly to cyber threats.

There will also be issues with software functionality. How do you quickly fix bugs without impacting the full system and ensuring safety?

The same thing is true of AI and data management in general. Just the sheer amount of data means companies will need to gather this data and figure out how they can implement it and ultimately improve safety in their vehicles.

Jin: If a user develops a piece of software or a software feature using MathWorks tools, using simulation or using automatic code generation, that person is probably looking at a changing environment going forward. The operating system in the vehicle is going to change. The communication technology is going to change. The processors are going to change. From a tooling point of view, we need to think about how we can help our customers stay flexible.

The core software features can actually be represented very well independently using models. The software features stay strong and flexible in the models. Then as you change the processors or the operating system, how can we enable the users of the modeling tools to quickly turn the models into the code that runs in the vehicle automatically? That’s automatic code generation. That’s what we are planning for – how to help our customers deal with those variables by  keeping what they value the  most in the models and using mechanisms such as code generation and automated verification and validation so that they can quickly adapt their features from models into the actual operating environment in a vehicle.

Garcia-Trombley: From an OEM perspective, they have all this legacy software and modules running now. They'll eventually want to port over to the cloud and that affects architectures that affects functionality. They need to figure out the most streamlined way to start dealing with their legacy IP during this transition to new models and new architectures. It’s an evolutionary versus revolutionary approach.

Is there anything else you would like to mention about software-defined vehicles and the work FEV.io is doing with MathWorks?

Garcia-Trombley: The whole concept of the SDV is also predicated on the idea that post-production isn't really post-production anymore. You always have this evolving state, and we're starting to see new partnership models evolve and new companies that are managing different elements of the vehicle in this sense – whether that’s cybersecurity companies managing live threats or companies that manage cloud payments updating those features in the field or the fleet. They need to think about how they can work with OEMs and manage the post-production lifecycle. Those partnerships will look totally different than traditional suppliers, because they will be much more involved in the vehicle in the post-production state.

There are also some groups trying to develop common nomenclature around SDVs, particularly related to the degree of being an SDV, similar to levels of autonomy in vehicles. They are working on definitions, so as an industry we can all get on the same page. The OEMs are really struggling to build a roadmap here, and I think that is in part because the industry can’t even agree on terminology. Once we have those definitions, then we can start talking about implementation and roadmaps and technology enablement.