How the Software-Defined Vehicle Trend Is Transforming Development Processes - MATLAB
Video Player is loading.
Current Time 0:00
Duration 19:49
Loaded: 0.83%
Stream Type LIVE
Remaining Time 19:49
 
1x
  • Chapters
  • descriptions off, selected
  • en (Main), selected
    Video length is 19:49

    How the Software-Defined Vehicle Trend Is Transforming Development Processes

    Dr. Hans Martin Ritt, Application Engineering Team Lead, MathWorks

    A large part of the future value of vehicles is going to be defined by software. While the automotive industry is adopting many development methodologies from the internet and mobile phone industry, it is important to consider safety and security as crucial requirements. Highly automated build and test systems—software factories—are a common practice, but what is necessary to make them ready for automotive? Frequent over-the-air updates are key to being able to react to security threats, but what is necessary to ensure that the safety of the vehicle is not compromised as a side effect? In this presentation, see how simulation and Model-Based Design can help in achieving the software quality and security that customers are expecting and integrating with automated build systems to enable the development speed and agility required to fully deliver the promise of software-defined vehicles.

    Published: 3 Jun 2024

    Good morning. Happy to be here and share thoughts about how we process the input, the expectations also that we heard over the morning. How can we help to make the software-defined vehicle future possible? And we also heard from presenters that it's really about integrating various tools into one setup to actually, in the end, deliver things. It's also making things complex for us to process this input.

    SDV. You might hear different definitions from people. Some define it really as primarily the vehicle. Some like talking about SDV as a topic that spans everything software and automotive. So really for us, it kind of is an effort right now to digest SDV and split it up into digestible pieces that we can work on and that we can ensure that our tools integrate well in the respective processes, that we work with partners and customers to actually make it happen. So it's really an active effort.

    And I will show today. I cannot have all pieces shown here today. I have selected three for today. The one that you also heard several times already this morning, automotive E/E architecture evolution. How are we responding to it? Software factory as a term was not so much mentioned this morning, but is a way to address the needs for a software-defined vehicle development. And the last thing that came up in the several talks, closing the DevOps loop.

    Starting with the first, automotive E/E architectures. We're clearly not involved in the hardware design for these architectures. Our level is, say, the application software that runs on these platforms. You heard several times about this trend moving from only microcontrollers on the vehicle to this high-performance computing on the vehicle, connecting to the cloud, and then the mobile phone. And really, the task for us, it's not addressing one specific aspect of it at a time, but we are looking to address this whole setup in one flexible environment that software can be developed for this new setup of the mobility systems.

    And as I already mentioned, this is for us not always easy. We could not do this without partners to actually have the examples, the demonstrators to show where it is working already and where do we need to invest to improve it. So that is the collaboration that Thomas already mentioned that we had over the past year, and a little bit more on this demonstrator. For us, it's covering this range from the microcontrollers over the high-performance computers, the cloud connection and the mobile phone, and then addressing the different perspectives that we are addressing with our tools, the development of the functions, as well as the verification and validation.

    What do we want to do to support this kind of architecture change? So when we also had that mentioned, the title of my slide here, maximize the reuse, be modular and adaptable in our development. If you look at these four categories that I created here in the picture, it really also for us was in the past very much a separate approach. We had an approach for microcontrollers. There's an approach for these high-performance computers. And then there's a cloud approach.

    That's actually you develop a software component, and you then decide to go in one way. And that's actually in a world where we need to be flexible. We need to be able to move things, even maybe after the vehicle has been deployed or brought to the market. It's really, from our perspective, our role or our goal, what we want to support, is to create a flexibility that software components can be moved at a stage on this kind of spectrum.

    Clearly, we would not move the braking controller to the mobile phone. That's straightforward. But like between the barriers here, there need to be flexibility, moving. As Thomas said, moving things now. Our legacy from microcontroller to the high-performance computers. And I think the other thing mentioned also already is the split between high-performance computers and cloud is not decided. We need to be able to move between these two also. That's this flexibility that we want to support.

    The other aspect that we hear and see is the high-performance. Computers are high-performance, but they become specialized for certain modes of operation. They have accelerators that are delivering the high performance, but they are actually then very specialized or difficult even to program. So having a way to at least ease the process from a relatively implementation-independent application to a very hardware optimized implementation is the other angle that we look at. Let me show that in two slides. One directly referencing the FEV demo.

    So that was part of our proof of concept that we took software that was developed for classical ECUs. Then in the classical AUTOSAR, that's basically our level, the middleware, so to say, that's kind of what we address and try to ease that process to a high-performance computer that has adaptive AUTOSAR. So it's not an automatic process, clearly. It's not that easy, but it should be as easy as possible. That's the goal.

    And the other angle that I described was the hardware support. So working that requires also for us collaboration with a partner-- in this case, Infineon-- to really ensure that the implementation of a very specific device can be-- oops, there was a very automatic animation. So moving to an implementation that is leveraging all the technology of this device without necessarily becoming a super expert of this one device that you added to your architecture.

    Now switching to my second topic, software factories. And I step back a little bit on looking at the development process. If you traditionally developed an automotive vehicle that took many years and that you work towards an SOP, then the vehicle was out in the field and it was as it was. Now we are targeting this world of vehicles that are out in the field. And there is a schedule of updates on some kind of weekly basis, maybe even. And the common answer that we see also being implemented from companies is what is sometimes called a software factory.

    Basically, this automated software build and test process that is able to, in a reproducible fashion, produce these updates. So far, so good. We have seen this being applied. The first domains that were doing this or that are doing that, remember the presentation of BMW at the AEK last year? The infotainment was the starting point. And it's working well. It's actually an accepted method to do this.

    But now we are talking about moving this into high-integrity, safety-critical software. There is a conflict that we see. The safety needs were addressed in the past by a several month long process of homologation. So how does that kind of fit together? We have a month-long homologation, and we want to have regular updates. And, yes, maybe we want to, for safety reasons, not upgrade functions all the time, but there might be security needs to actually update functions at a higher frequency. So there is this conflict. We can only reduce for the safety-critical functions the update frequency that is produced by the software factory.

    So we need to rethink. We need to augment the software factory. And there's two things that we see starting to being adopted. One is a very straightforward process in addition to what is already existing. And I'm using language like shift left from the V model here. Moving things earlier. So putting more than just something like MISRA checks or so in front of the built and test process. Really getting to formal code verification as part of the process to kind of prepare the software. That's really an accepted measure now.

    But then that's not enough. That will not be enough to replace more parts of the homologation in the software factory. It will most probably never be complete, but our goal is to help to automate more so that there is less manual activities that are happening. Basically, after an update of safety, critical functions have been delivered out of the software factory. So what does that mean? Yeah, we need to add models into the software factory.

    So some kind of virtual representation of vehicles completely or vehicle parts of the compute platforms, all in virtual forms, need to be added to the software factory-- to the automated validation as part of the software factory. And this will kind of go on. Even get to the level of virtual worlds that we include in the software factory and have virtual scenarios that we execute in the software factory. And as we discussed this with you, customers, and partners, we sense that there is a certain need for discussion of this topic.

    We sometimes now hear, because the software factories have often been built up by people that really focus only on code, an infotainment has no vehicle model to work against. Introducing complex models that are difficult to execute into the software factory is a discussion. I sometimes hear that there is a code-only approach for the software factory. And I don't think that this is a good direction or that is a good expectation.

    We really need for parts of the vehicle. We need models in the software factory. And there is no added value of enforcing a code-only approach. There is a need, also, on our side to better integrate into the automation infrastructure and scaling to cloud. That's no question. The better term that I put here on the slide is infrastructure to code. So, yes, our tools also need to be fully scriptable, automatable in the software factory, but it's not so much that it needs to be-- all the models need to be code.

    With that, moving to showing an example where this has been also done. That's a presentation from JTEKT at a recent event, a Japanese automotive supplier. So they really have that-- I'm just showing the title slide here. They really made this software factory model-based, adding these models, and achieved with that the ISO26262 compliance. That's really an additional step. It's not done by just automating things. It's this additional step to reach this compliance level.

    I'm only showing these two slides, the first and the last. It's also this incremental process that they applied. Yes, they started with a very basic CI system to automate the process in the software factory, but then they actually move it step-by-step to these compliance to safety processes. And you see here on the last slide, you see that term here, DevOps. DevSafeOps. That's kind of what they call it. Adding that perspective of safety-critical applications to the DevOps methodology.

    And that brings us to my last of the three topics. That's a shift for us as well that we start to look at the complete process from a DevOps perspective and see when are we getting involved, and what exactly would be our role in this flow? So moving you through one of these flows that how you can look at this is-- and I start now on the operations side. There is an incident in the fleet. The data needs to be made available for the developers. That's maybe not so much our area, but then it's about interpreting the data.

    As engineers and designers of vehicles, we are not staring at columns of numbers, right? That's not where we can understand the situation. We need to have resimulation to be able to actually see what has happened in the vehicle, with the vehicle. And then do dependency analysis using, for example, architecture models, develop the update, and then yeah, rebuild the necessary parts as part of the automated processes.

    Ensure that the complete system is still working. The update can maybe damage. Things that you didn't expect to damage, actually, with the update. So that needs to be ensured. And then, clearly, ideally actually update only the necessary part of the vehicle, not send the complete package of all software basically to the vehicle. And, again, as I mentioned, this is not possible for us to do completely on ourselves. Demonstrated that it's actually practically working.

    It is really a process that we need to work with partners. And in this case, it's Elektrobit and Amazon Web Services that we use basically to, yeah, connect to data and create a simulation infrastructure to be able to see, how can engineers understand what has actually happened to the vehicle with that additional functionality to actually have elastic resources to scale to the cloud?

    And then implement this whole process of a software factory that is with all the tools that you see here, the standard infrastructure, to have an automated build and test process. And then the last thing that I mentioned here on the slide is bringing in more things of the real world into the software factory. So, for example, virtual ECUs is a topic. There's not a virtual ECU or the real ECU. It's really this idea also that there are different levels of representation.

    A very detailed virtual issue would be really high computational effort. So you don't want to do this maybe every time. There's easier ways of first level virtual ECUs. And then you get closer to the final hardware that you do the final test, so to say, before actually delivering it to the vehicle. And with that, I come to my last slide.

    We're in this process also of still understanding and identifying the relevant processes. And I kind of put these three dots that I have a few more in mind that we could describe, like this that we need to address. And we would be interested in your priorities. What are other perspectives that you want to take that are maybe not well enough addressed today? And we would be also interested to actually then work with you.

    So we have really made this experience with Thomas here, FEV, and the other partners that I mentioned here in the presentation that it's really about creating something together, getting engineers from us into the projects, and see what is working and what is not working and what are the priorities, what needs to be addressed to move the overall topic forward. So I invite you all to approach me or the MathWorks team to actually let us know what we should work on. Thanks a lot.

    [APPLAUSE]

    View more related videos