Flavio Sonnenberg
ERNI Switzerland


CI (continuous integration)/CD (continuous delivery) pipelines have become an indispensable tool in software engineering since they enable developers to automate many tedious processes to verify the quality of the source code and the testing of the applications. With a little effort, the software artefacts can be built and tested in various environments and with different toolchains. If all tests in the pipeline pass, the artefacts can be further deployed based on the project’s needs.

Since embedded software often runs on custom hardware, it brings its own additional challenges to the testing step, for example, the image deployment, side effects due to competition over limited and shared resources, and a tight interaction with the hardware which complicates the testing. These points make it essential to regularly test the already developed features on the hardware to detect regression as early as possible. Due to its complexity, the tests are often performed manually. This is very time consuming; therefore, it is easier to test only the corner cases of the just implemented feature instead of running the whole test suite. As a result of having a limited number of tests, side effects may remain undetected.

In addition to the mentioned challenges, the development of embedded devices carries the problem that the development of the software and the target hardware happens in parallel. Therefore, the final hardware is not yet available at the beginning, and it is challenging to detect if a bug is occurring in the hardware or the software. Furthermore, only a limited number of boards are available, which must be shared within the development team. To overcome these difficulties and to reduce the burden of executing the entire test suite regularly on the hardware, it would be beneficial to integrate the on-target tests as an additional stage in the CI pipeline. This stage could execute unit tests which run on the target, integration tests or even hardware acceptance tests from the software point of view. As a side effect, one or more complete hardware setups are made available to the whole development team. This article provides a conceptual overview of the chain between your CI/CD pipeline and the target hardware.


General setup

The setup consists of 3 main components:

  1. The CI/CD server executing your pipeline on specified triggers
  2. Local executor machine
  3. The hardware in the loop (HIL) connection


Figure 1 – Architectural overview


All three components have different requirements and need a different implementation based on the project’s needs.


CI/CD server

This hosted service (GitLab, GitHub, Azure DevOps, Jenkins…) executes a CI/CD pipeline for the configured triggers. Primarily, this is controlled by a configuration file which is part of the Git repository. Typical triggers to run the pipeline are merge requests, pushes, manual triggers and many more. Usually, this service does not run in the local facility and is shared within the company between multiple teams and projects.


Local executor machine

This machine must have direct access to the target hardware and must equip the pipeline executor with the permissions to access the hardware interaction channels. The pipeline executor is a piece of software provided by the CI/CD service that checks the CI/CD server for pending jobs and executes them locally, giving the pipeline execution access to the target hardware through the provided interfaces.

The connection between the pipeline executor and the CI/CD server depends on the service provider. It requires some local configurations (server URL/port, authentication) and server-side configurations (permissions, authentication).


HIL connection

The hardware in the loop connection is the core of the setup and is responsible for connecting the target hardware with the test execution hardware and providing this interface to the pipeline executor. This part of the architecture can be very complex and varies from product to product. It can consist of multiple hardware components or be a software module on the Local Executor machine.

At a minimum, it should provide a way to program or deploy the newly built software image either through a debugger connection or via a communication interface, the possibility to restart the target, and at least one communication channel to interact with the target. The complexity can grow from this point as much as the project requires it to. Failure injection, other communication channels, or hardware emulation of the connected devices could be added to create a test environment as close to reality as possible.


Final remarks

With the setup described, it will be possible to run your test cases targeting your hardware in the CI/CD pipeline and regularly get direct feedback on the results. To run tests on the target, the corresponding pipeline stage must execute a test script (part of the repository) containing the test cases which directly interact with the locally provided HIL interfaces, for example, to program or restart the board, to communicate through a serial port or to open an SSH connection to the target. An advantage is that the same test scripts can be executed locally, outside the pipeline, to achieve the same results on your desk.



This article gave a brief overview of how to connect your target hardware with your CI/CD pipeline, allowing you to execute hardware-dependent tests autonomously and adapt them to the different available CI/CD solutions in a general way. If you want to find out more, please contact Philipp Rey.


News from ERNI

In our newsroom, you find all our articles, blogs and series entries in one place.

  • 27.09.2023.

    Unveiling the power of data: Part III – Navigating challenges and harnessing insights in data-driven projects

    Transforming an idea into a successful machine learning (ML)-based product involves navigating various challenges. In this final part of our series, we delve into two crucial aspects: ensuring 24/7 operation of the product and prioritising user experience (UX).

  • 13.09.2023.

    Exploring Language Models: An overview of LLMs and their practical implementation

    Generative AI models have recently amazed with unprecedented outputs, such as hyper-realistic images, diverse music, coherent texts, and synthetic videos, sparking excitement. Despite this progress, addressing ethical and societal concerns is crucial for responsible and beneficial utilization, guarding against issues like misinformation and manipulation in this AI-powered creative era.

  • 01.09.2023.

    Peter Zuber becomes the new Managing Director of ERNI Switzerland

    ERNI is setting an agenda for growth and innovation with the appointment of Peter Zuber as Managing Director of the Swiss business unit. With his previous experience and expertise, he will further expand the positioning of ERNI Switzerland, as a leading consulting firm for software development and digital innovation.

  • data230.08.2023.

    Unveiling the power of data: Part II – Navigating challenges and harnessing insights in data-driven projects

    The second article from the series on data-driven projects, explores common challenges that arise during their execution. To illustrate these concepts, we will focus on one of ERNI’s latest project called GeoML. This second article focuses on the second part of the GeoML project: Idea2Proof.

  • 16.08.2023.

    Unveiling the power of data: Part I – Navigating challenges and harnessing insights in data-driven projects

    In this series of articles (three in total), we look at data-driven projects and explore seven common challenges that arise during their execution. To illustrate these concepts, we will focus on one of ERNI’s latest project – GeoML, dealing with the development of a machine learning algorithm capable of assessing road accident risks more accurately than an individual relying solely on their years of personal experience as a road user, despite limited resources and data availability.


  • 09.08.2023.

    Collaborative robots revolutionising the future of work

    The future of work involves collaboration between robots and humans. After many years of integrating technology into work dynamics, the arrival of collaborative robots, or cobots, is a reality, boosting not only safety in the workplace but also productivity and efficiency in companies.

  • 19.07.2023.

    When the lid doesn’t fit the container: User Experience Design as risk minimisation

    Struggling with a difficult software application is like forcing a lid onto a poorly fitting container. This article explores the significance of user experience (UX) in software development. Discover how prioritising UX improves efficiency and customer satisfaction and reduces risks and costs. Join us as we uncover the key to successful software applications through user-centric design.

  • 21.06.2023.

    How does application security impact your business?

    With the rise of cyber threats and the growing dependence on technology, businesses must recognize the significance of application security as a fundamental pillar for protecting sensitive information and preserving operational resilience.