Save Time and Work: Implement Continuous Integration for Environment Model Development!

As the amount of software in vehicles increases, software development for embedded systems has adopted agile development methods and implemented pipelines for Continuous Integration (CI). The aim has been to integrate software features and changes at least daily, and sometimes even hourly. The CI technology has enabled automation of their building process and give developers immediate feedback on their work.


Figure 1, A developer working on a development branch of certain software feature wants to commit his changes to the master branch of the software. In a CI process, the publication of change (pull request) automatically triggers associated activities to merge the update with the existing repository. Typical activities are Build, Test, Report, Merge and Release.

To give function developers the best possible foundation to deliver high quality software, the CI pipelines requires test environments on all system levels (e.g. unit, component, domain, and vehicle levels). At each system level testing with different test methods (e.g. requirements-based testing, interface testing, fault injection test, resource usage testing and back-to-back testing) is performed. These methods at each level will require a specific environment model designed to perform the testing.

To handle the number of environment models and simulation implementations that must be created, environment model development (figure 1) should take advantage of the process developed for functional software developmen. The environment models should be developed and verified by the experts within their respective field and passed upstream to create larger environment models for a higher system level. For example, environment models used for unit testing should be reused to create an environment model for component testing, and that environment model should be used to create an environment model for domain testing, which can be reused to create a complete virtual vehicle (figure 2). By reusing the environment models for each separate level in the system, developers could save enormous amount of time. These artifacts should be maintained as extensions for each system level simulation, ensuring reusability through the whole pipeline.


Figure 2, The simulation model tree. The vehicle model is created by combining the domain models e.g. for a BEV (Battery Electric Vehicle) some domains are Electrical System, Drivetrain and Vehicle Dynamics. Each domain is created by combining several component models, e.g. for the electrical system some components are electrical machine, high voltage battery, low voltage battery. Each component is created by combining several units, e.g. for the electrical machine some of the components are inverter and PMSM.

To handle this efficiently the reusable artifacts from each stage should be stored centrally as precompiled units that can be integrated upstream. This can be achieved through the dSPACE tool chain, more specifically by using tools like ConfigurationDesk and VEOS player. With these tools data containers such as .sic and .fmu can be built for hardware- and software-in-the-loop platforms (and VEOS). The compiled artifacts can then be stored in the container and reused during upcoming builds. This will reduce the build times for the next iteration of the environment model implementation significantly (table 1).

Table 1, Build times decreases rapidly when previously generated and compiled code is reused for the next iteration

Continuous integration is key for effective development processes. The tools when used efficiently will help your company to deliver higher quality software, decreased development time, immediate feedback to the developers and increased amount of testing. We believe that ConfigurationDesk and VEOS player will be important tools in your testing processes.

Do you want to learn more? Reach out to us at and we will set up a meeting. We are looking forward to collaborating with you!