Test automation has been identified as one of the most prominent areas in the testing of embedded software. However, achieving effective automated quality assurance remains challenging, mainly due to the need for hardware involvement in the testing process. This form Hardware-in-the-Loop testing often requires a continuous connection to the testing environment, which can be expensive and impractical, especially for small and medium-sized enterprises. To address this issue, the digital twin prototype is designed to operate independently of the physical system while still enabling the testing of real embedded software.
Continuous Integration / Continuous Delivery with GitHub Actions
Each time a user commits changes, a GitHub Runner is triggered to build a Docker container. All dependencies are loaded into this container, and the code is compiled. This build step could also include static software checks to further assess the quality of the code. Once the containers are successfully built, unit tests are executed on the module under test. If these tests pass, we proceed to the next critical phase: integration testing. To illustrate how the digital twin prototype can be used for automated integration testing without requiring the real hardware, we have create an integration test from the script used for speed measurement. This integration test ensures that the digital model in the simulation runs at the same speed as the real one. After successful integration tests, the different Docker containers are released. The CI/CD pipelines are executed on three runners in parallel, one for x64 system, one runner on a RaspberryPi 3 (arm32v7), and the third on a RaspberryPi 4 (arm64v8). Notice that only the X64 runner can execute the integration tests that use virtual context from the GAZEBO simulation. GAZEBO has no ARM build available. The results of the different builds can be seen on the GitHub Actions overview page.
Manual Integration Testing
Since the CI/CD pipelines also only use Docker for test execution, the whole workflow can be executed manually. The different workflows implemented in this project are shown in the .github folder.