Agnostic Build System: Powertrain build

Powering Volvo Cars’ Software Builds

We are thrilled to announce the release of the Volvo Cars Powertrain Build project, now available on OpenDev!

As a build system tailored for embedded software development using DSpace Target Link or Mathworks Embedded coder, this project is set to improve the way we as automotive embedded engineers handle our code bases. The idea is to make it easy to move between different targets, enable Software in the Loop (SIL) testing, and streamline our continuous integration (CI) processes.

Powertrain build offers to efficiently move embedded source code between different embedded targets, both Posix based and old school embedded ECU’s. This build system does what AUTOSAR never did, and is a tool that prepares us for the future of the car OS. Check out the article below to learn more about AUTOSAR:

The reality of AUTOSAR and the way forward

Our Powertrain Build project is designed to work harmoniously with the Zuul CI system. This ensures that all code changes are automatically tested and validated, providing continuous feedback to developers and maintaining the integrity of our codebase.

What is it?

The build system is written in Python for ease of use and flexibility, and these are the build options.

py -3.10 pybuild.wrapper --build ABC_123

Projects are defined in .json using Project, base and Unit configs.

The project config file contains project specific configuration settings and references to other configuration files. The base config file shares the same structure as the project config file and can be used for non project-specific configuration settings and default values, these could for instance be diagnostic core dummy file names. The units config file contains information about included software units and scheduling rasters. The software units are executed in the order they are defined within each time raster definition.

{
    "SampleTimes": {
        "VcExt10ms": 0.01
    },
    "VcExt10ms": [
        "VcDebug",
        "VcCarCfg",
    ]
}

Schedulers are not included in the powertrain build, but they could easily be added.

Usually, an interface configuration is used, where individual c-functions variables are connected to com-variables that are sent on different busses.

The system utilises C Preprocessor directives, instead of code switches, in TargetLink models, allowing for a superset C code representation of Simulink models.

Variables use different variable classes, to direct them to appropriate memory addresses.

The system includes unit tests for build scripts and HTML documentation for transparency and maintainability. One feature is the consistency checks that are done by creating JSON files of the code. Signal consistency is a wonderful tool, where we have the classic signals traveling in CAN frames. The tool reports if we delete signals that are used, or if we produce signals that are not consumed.

py -3.10 pybuild.wrapper --build ABC_123 --interface

A developer would usually follow this workflow, which is also detailed in the picture below:

1. Design the Simulink model and generate code using powertrain-build command.
2. Build the relevant powertrain-build project.
3. Inspect the generated artifacts, and commit those if desired.
4. Build the SIL binary, and write the unit and smoke tests.

Object Process Methodology diagram of a typical flow.

A typical file structure looks like this:

gitrepo/
├── ConfigDocuments/
│   ├── .
│   ├── .
│   ├── .
│   ├── SPM_Codeswitch_Setup.csv
│   ├── SPM_Codeswitch_Setup_ICE.csv
│   ├── SPM_Codeswitch_Setup_PVC.csv
│   ├── .
│   ├── .
│   ├── .
├── Models/
│   └── PVCTM/
│       └── VcPvcDemo/
│           ├── pybuild_cfg/
│           │   ├── config_VcPvcDemo.json
│           │   └── VcPvcDemo.yaml
│           ├── pybuild_src/
│           │   ├── tl_defines_PvcDemo.h
│           │   ├── VcPvcDemo.a2l
│           │   ├── VcPvcDemo.c
│           │   ├── VcPvcDemo.h
│           │   └── VcPvcDemo_OPortMvd_LocalDefs.h
│           ├── tests/
│           │   ├── _cumulated_code_coverage_
│           │   │   ├── ctcpost_merge_options.txt
│           │   │   └── experiment.spec
│           │   ├── VcPvcDemo_UnitTests
│           │   │   ├── 00_test_setup
│           │   │   │   ├── dataset.DCM
│           │   │   │   ├── sut_config.txt
│           │   │   │   ├── sut_interface.py
│           │   │   │   └── twTest.sil
│           │   │   ├── 01_stimulus
│           │   │   │   └── U_VcPvcDemo_ExplorativeStimulus.py
│           │   │   └── 02_watchers
│           │   │       └── U_VcPvcDemo_watcher.py
│           │   ├── ctc_env.bat
│           │   └── project.testweaver
│           ├── VcPvcDemo.mdl
│           ├── VcPvcDemo_par

Why open source?

As we’re transitioning to become a fully electric carmaker, we no longer have powertrain software development for combustion engines in house. However, there was a need to be able to develop and share the build system, since it is still used for electric cars.

The easiest option was of course to put the code as open source.

Since we like Zuul to run tests, and we do that internally, we asked Opendev. They kindly offered us our own tenant in their Zuul that you’ll find here.

We also want to fill Industry Gaps, as the build system addresses gaps that AUTOSAR couldn’t fill, providing a tool that is well-prepared for the upcoming advancements in car OS. Sharing the code behind these alternatives can foster positive feedback and collaboration with other OEMs.

It is also much more fun for us to work with our code in the open!

Now, we look forward to new collaborations, in the same open and friendly way that OpenDev has described in their contribution guidelines.

Go ahead and check out the code and let’s collaborate!