With the further establishment of HIL simulation and testing as an increasingly integral part of development and validation processes over the last several years, the way in which HIL systems are designed, commissioned, and provided, as well as their utilization and integration into the validation processes, is also changing significantly. For example, the plant models used for real-time HIL simulation have often been developed and integrated based on the interaction between and experience of a few modeling and HIL experts. However, the growing number and professionalization of HIL systems poses several challenges that can no longer be overcome by conventional means.
At the same time, the requirements for HIL simulation are becoming more challenging as a result of stricter emissions regulations, electrified powertrain applications, more sophisticated performance algorithms in vehicle dynamics, braking and active safety features, and additional security requirements, for example, in autonomous driving. Therefore, the demands on the scope and accuracy of the models used in HIL simulation are increasing. For this reason, there is an increasing tendency to reuse models from other domains and departments, sometimes even implemented using different, domain-specific modelling tools.
Furthermore, the number of HIL systems being utilized by automotive OEMs or suppliers has grown significantly, from individual systems to entire HIL farms at large OEMs. The uncountable combinations of ECUs and model variants make this all the more complicated. Therefore, managing, assigning, and deploying models in the context of multiple HIL systems poses a great challenge.
Last but not least, shorter development cycles and the demand to increase productivity require a maximum level of automation in the utilization of the systems, which in turn requires downtimes to be minimized.
Against this backdrop, new approaches are needed to integrate and use simulation models
In other words, it is necessary to move away from expert workflows and toward a productive "model factory." Such approaches already exist, and they can be transferred to the HIL application, as we will show below.
Modern software development processes provide wonderful concepts for these new challenges, which can be adapted to HIL simulation in a very beneficial way. Continuous integration is one of these concepts, making it possible to develop large-scale software products in an efficiently and agile manner even in large organizations.
Continuous integration makes the following principle from the Agile Manifesto a reality: “Working software is the primary measure of progress.” The key concept of continuous integration achieves this goal by dramatically changing the way in which software is developed and tested. At first, the staff are organized into small agile teams with clear responsibilities and decision-making power. The teams organize their work into prioritized backlogs and work from top to bottom. In this way, the teams develop the software in small iterations, also called sprints, within a period of 1 to 4 weeks.
In agile development, each iteration generates a working increment of the product. In order to achieve this incremental development of the software, planning, developing, building, and testing must be combined with a unit test in every iteration. As a result, the quality of an increment is ensured during the development process itself; sometimes this paradigm is called built-in quality. Therefore, continuous integration contrasts with the waterfall methods, where the development and testing stages are separated from each other.
But how can this incremental development be achieved? Many techniques help in this dynamic and continuous process:
As we can see, automated and orchestrated testing is crucial in order to attain continuous integration. The article “Efficient Continuous Testing with dSPACE” describes the mechanisms and dSPACE’s answers to this uniquely automotive software development.
Agile methods and especially continuous integration are being implemented into the automotive software development more and more. Due to the special requirements for the code to be tested (because of real-time capability, for example), there are very high demands with regard to the quality and therefore the testing. HIL simulation is an essential part of the testing methodology, in addition to SIL testing.
In order to use HIL simulation in continuous integration approaches, the processes used to obtain executable HIL systems are changing dramatically. The commissioning and deployment of HIL systems in particular can no longer be understood as an expert discipline, performed one step after the other. Instead, all steps from the development of large simulation models to the deployment of multiple HIL systems must be performed in parallel.
Typical tasks in this process include:
However, as demonstrated by several companies, continuous integration approaches can be applied to HIL testing very successfully. Here, two continuous integration cycles are interacting with one another. The first cycle is the ECU software development process, and the second cycle is the model integration process for HIL. dSPACE provides comprehensive support and advice to its customers for getting the job done.
The following measures have proven to be real success factors for introducing continuous integration for HIL simulation.
A modularized model structure, which consists of small units, allows for robust, convenient, and efficient integration. Using a modular model structure, agile teams are able to achieve built-in quality since they can take responsibility for their own models and check their quality throughout different stages of testing (virtual and in real time) without being hindered by large models that are dependent on many other teams. This flexibility in the team and model management makes fast changing cycles possible with much higher performance, while at the same time making it much easier to manage variants.
HIL integration processes can be very lengthy and inefficient. This is often the case when two steps of the integration process are performed every time for the entire system model:
This circumstance is critical because, in most cases, only individual parts of the model (<10 %) have changed in an iteration.
The basic idea is to shift these two steps forward, away from the HIL integration and into the model development phase. For example, both steps can be performed automatically when new versions of the models are checked in. In this case, each model is already distributed as a generated and compiled piece of code. We call this deployment form model containers. This approach speeds up the HIL integration process considerably.
Connecting models to IO and other models is significantly easier as a result of the following techniques:
This allows for highly automated model exchange processes and efficient change management even with changing model interfaces.
In many cases, real ECUs are not yet available when HIL systems are set up. This can stop the whole HIL deployment and testing process. In order to overcome this problem, it is recommended that the missing ECUs be simulated. This can be done either by using quite simple behavioral models, called Soft ECUs, or—in a more advanced way—by using an existing ECU application code and building Virtual ECUs, which can also contain some basic software required for testing. Both Soft ECUs and Virtual ECUs can be interpreted as digital twins of the real ECU that is missing. Using Soft ECUs and Virtual ECUs consistently can speed up the HIL setup significantly because the system can always be executed regardless of whether the real ECU is available.
Apart from solving the availability problem, using Soft ECUs or Virtual ECUs can even make continuous testing more robust because, in the case of a single hardware component failure, the whole simulation can still be executed. A great deal of infrastructure is needed for this approach, especially for the required rest-bus simulation.
In many companies, the introduction of continuous integration processes for model development and integration in HIL applications is already a key to making HIL testing even more productive. The best practices above described, such as modular model structures, pre-compiled model codes, managed interfaces, and mappings, as well as the use of Soft or Virtual ECUs, are the key to applying continuous integration successfully. dSPACE tools and solutions can already be used in continuous integration processes for HIL simulation today. Thus, it is possible to set up highly automated model build servers and processes. New software models such as cloud-based integration and build processes and even build-as-a-service business models and infrastructures are on the horizon. dSPACE is always at the forefront of this development, working closely together with several customers on this topic. dSPACE’s tools experience can help to manage the transition from classic processes to a highly flexible and automated model production and delivery process that meets the upcoming challenges and changing requirements in the automotive development and validation landscape today and in the future.
dSPACE: Your partner in simulation and validation!
Faire avancer l'innovation. Toujours à la pointe de l'évolution technologique.
S’abonner à nos newsletters, gérer ses abonnements ou se désabonner