In an interview with AEEmobility, Thomas Kleinhenz, Director of Automotive System and Software Architecture at Elektrobit explained, why a framework based on MATLAB and Simulink is an indispensable tool for customers to quickly and cost-effectively achieve a production-ready ECU for SDV.
With the separation of hardware and software in automotive architectures, the life cycle of new hardware architectures is getting longer, while software is released in much shorter cycles and can handle many generations of hardware in parallel. An important aspect of system definition is the evaluation of whether a new software function can be provided and executed on an existing or new system-on-chip (SoC). For this reason, Elektrobit offers its customers a framework based on MATLAB and Simulink that makes this possible.
AEEmobility: Mr Kleinhenz, what is behind the concept of this framework? What are the benefits for users?
Thomas Kleinhenz: This framework complements Elektrobit’s end-to-end closed-loop environment in software and hardware for model-based application development. We optimise the development of software-defined vehicles by using MATLAB and Simulink for the exploration of innovative ideas and the development of software functions, integration and verification from the cloud to the SoC. The goal of the framework, also known as the „target picture“, is to efficiently realise the concept of a software-defined vehicle. Suppose you have a new idea for a driving function or an algorithm for automated driving. The challenge is to integrate this idea directly into the vehicle without unnecessary intermediate steps such as creating new specifications or going through several processes.
In the automotive industry, virtualisation and the use of virtual ECUs (vECUs) are increasingly being used to model deeper system layers or the operating system. However, the question is how to complement this approach so that the idea can ultimately be implemented on a real ECU. This was the starting point for our considerations. Each company will implement this differently, depending on their specific systems and methods. However, the overall goal remains the same: how to develop an idea as quickly, efficiently and with maximum reusability as possible until it is ready for use on the final system. For us, Matlab/Simulink forms the core of the framework, but it is embedded in a broader context.
Thomas Kleinhenz is Director of Automotive System and Software Architecture at Elektrobit.
How can the framework help developers to assess whether a new software function can be executed on a specific hardware?
It depends on the situation. For a car manufacturer that already has vehicles on the market, the available resources such as memory size, processor performance and other dependencies must be taken into account when integrating a new function. These parameters can be modelled and described. At the same time, algorithmic functions can be characterised well, even if the exact implementation is not yet available. For example, it is known that the function processes certain data blocks or executes complex algorithms. Such requirements can be estimated well, as it is known how many MIPS (millions of instructions per second) and how much memory is required for certain operations. It is sufficient to first roughly understand what the function requires and what costs are associated with it. Once you know the requirements of the function and the available hardware resources, you can compare them. If the existing hardware resources are not sufficient, the function may need to be simplified.
A more interesting scenario occurs when a new platform or ECU is being developed. In this case, you want to map as many functions as possible on it and at the same time ensure that future functions can also be implemented. This can lead to a tension between technology and purchasing. It is helpful if developers can clearly explain which processors, memory and other resources are required. In the case of software-defined vehicles (SDV), this requires a comprehensive understanding of the system because, despite the term „software-defined“, the software ultimately has to run on hardware. This aspect must be given special consideration.
A third scenario concerns car manufacturers who are thinking about developing their own system-on-chip (SoC). This requires precise knowledge of the requirements.
The different levels of virtualisation.
What are the advantages of virtual ECUs?
Virtual ECUs make it possible to reduce dependence on physical hardware. Software development can begin at an early stage on a simulated hardware platform, such as a model of a processor like an ARM core, which will only be available in two or three years‘ time. This allows the software to be comprehensively tested and validated before the actual hardware is launched on the market. This offers the advantage that the latest generation of hardware is integrated into the vehicle at market launch, which in turn makes it possible to provide the vehicle with new functions and updates in the long term.
„The foundation of Software-Defined Vehicles (SDV) is made possible by the integration of the Elektrobit framework with MATLAB/Simulink. This framework enables consistent and rapid implementation – from the research of innovative concepts to the development and integration of software functions through to verification. It ensures seamless processes, both in the cloud and directly on the system-on-chip (SoC), in virtual and real environments.“
How does the framework bridge the gap between simulation, virtual validation and real tests?
It is crucial that the transition between the various phases – from simulation to virtual validation to real tests – is seamless. There must be no media discontinuity. I must be able to switch flexibly between the worlds. As soon as my application has been developed and the target platform has been defined, I should be able to decide whether I want to carry out the validation on virtual hardware or switch to the actual hardware. This process must work smoothly.
What challenges arise when using virtual ECUs, especially with regard to the detailed replication of hardware characteristics?
There are limits to what can be virtualised. The simulation of thermal properties is particularly challenging, as the power loss becomes more important with increasingly complex operations and must be considered in detail.
Virtual ECUs make it possible to reduce dependence on physical hardware. Software development can begin at an early stage on a simulated hardware platform, such as a model of a processor like an ARM core, which will only be available in two or three years‘ time.
What role will the OEM play in the system description in future?
The aim is to achieve a „shift left“. The various suppliers often develop their components in parallel without coordinating with each other at an early stage. It is only later, when they all come together, that it becomes clear whether the components really work together. If it is then realised that the interaction does not work, a massive integration problem arises that has to be resolved under great time pressure. This inefficient and energy-intensive approach can result in a vehicle being launched on the market too late.
To avoid this, the OEM must think through the overall system at an early stage: How is it structured? Which interfaces and components are required? This can be verified in a simulative environment such as Matlab/Simulink to create a solid basic framework for the system. Not all the details of the components need to be finalised, but the basic functional and non-functional requirements at system level – such as MIPS, power consumption, memory and performance – should be defined. Once these basics are in place, the OEM can delegate the development to various suppliers, whereby the interfaces, non-functional requirements and the test and simulation environment are clearly described. This enables a fast and efficient development process in which the system is virtually pre-developed at an early stage.
How much of this is already reality?
We are still a long way from this in the industry, as a completely different form of cooperation between OEMs and suppliers is required. It is more about a partnership model. OEMs and suppliers need to work closely together to achieve such development goals. The traditional top-down approach, in which the OEM sets the specifications and the supplier is easily replaceable if, for example, it is not cheap enough or has to be replaced for compliance reasons, no longer works with SDV. I think that’s a key point.
You also have to ask yourself why new OEMs entering the market are able to act so quickly. Of course, the existing structures play a role, but there are certainly other approaches that we can learn from and that we as a European industry need to find an answer to. I believe the solution lies in real partnerships across the entire supply chain. Take for example companies like Elektrobit, Vector or others: They need to coordinate more. It’s about creating a functioning ecosystem in which specific problems can be solved. There are already approaches, such as initiatives from industry leaders, to promote more cooperation. But to my knowledge, not enough has happened yet. Much more needs to happen here, also in order to better counter the competitive situation from China.
It is crucial to achieve a high degree of reutilisation of software and test cases. A co-operation model, as mentioned above, ensures that components are fully tested, interfaces work accurately and regression tests are performed reliably. An OEM that distributes its specifications to suppliers can integrate the incrementally delivered components and perform the regression tests using the corresponding test cases. In this way, the system develops gradually instead of in one large, risky step.
How realistic are the virtual ECUs compared to the actual hardware?
Although virtual ECUs come very close to the actual hardware, there are still aspects that only become visible on real hardware. There are concurrent processes and effects that cannot be fully mapped in simulations. Therefore, there will always be test cases that have to be carried out directly on the vehicle. Nevertheless, many functional tests can be carried out virtually in advance so that only the functional regression is tested in the vehicle. This is particularly important when it comes to complex functions. In the case of ADAS and AI, for example, the scenarios are so complex that they can no longer be fully covered by real tests alone.
What are the challenges of maintaining such virtual ECUs over the entire service life of a vehicle?
This is a key question. It is not just about maintaining individual software components, but also about the entire tool landscape, which must enable this long-term maintenance in the first place. If software has to be maintained for years, as required by the UNECE cybersecurity regulation, for example, this means that I have to ensure that I can reliably install security updates or bug fixes over a long period of time.
What does this mean for the tool chains? Do I have to freeze them to ensure that I can use them again in perhaps eight years‘ time to rectify a fault? These are crucial questions for which there are possible solutions, but a comprehensive answer has yet to be found. What is certain is that this topic is extremely complex and will require considerable effort, particularly due to the strict legal requirements. If these requirements are not met, manufacturers could be forced to withdraw their vehicles from the market, as has already happened in some cases. A consistent approach that ensures that software and the associated tools can be distributed and updated over a long period of time could help here. This would make it possible to rectify specific problems without having to overhaul the entire vehicle.
It is also crucial to further deepen our understanding of the systems. At the Mathworks conference, key solutions were already presented that could be helpful here. In particular, by introducing collaborative frameworks between manufacturers and suppliers, we could significantly speed up the development, integration and testing of functions.
Virtualisation and system simulation are already firmly established in other industries and have clearly demonstrated their benefits. Systematic simulations and modelling are used far more intensively there, and I am convinced that we can benefit from this experience to make processes in the automotive industry more efficient and cost-effective. We may need an industry initiative similar to AUTOSAR to drive forward common methodologies and partnership models. There are already many promising ideas and solutions, but we need to implement them consistently. In SDV, we need a deep understanding of the system.
In your opinion, what are the key points for successful SDV development?
When developing software-defined vehicles, it is essential to precisely analyse the feasibility of executing a use case on abstracted hardware. The path to success leads via a comprehensive simulation that derives both functional and non-functional requirements in detail. Equally essential is the precise estimation and characterisation of system parameters such as the optimised sampling rate of functions, the required MIPS, memory requirements and power consumption. In addition, the interfaces must be clearly defined – this includes both the bandwidth requirements and the integration of third-party software. Early integration of these interfaces and building blocks is ultimately crucial to ensure smooth processes. Finally, a robust testing framework must be established to comprehensively verify the production software to ensure quality and functionality. (oe)
Mr Kleinhenz, thank you for the interview!
The interview was conducted by Klaus Oertel, editor-in-chief of AEEmobility.
About Thomas Kleinhenz’s presentation at the Mathworks conference
