Continuous Integration CI

Automation Tool

Continuous Integration CI for embedded

Automated builds and tests have become an integral part of modern software development. Continuous Integration - or in short CI - is also becoming more and more popular in the embedded field.

When you start the video, content is loaded from Youtube and thereby your IP address is transmitted to YouTube.
Learn more

A “rapid feedback loop”

Every single time a developer integrates a code change into the version control system a fast and highly automated series of steps - a so-called pipeline - is triggered. Typical steps can be Build, Static Analysis, Unit, and System testing (see image below).

After each pipeline run, a qualified statement is available on how the change has affected the state and quality of the software. Within minutes, it is clear to the developer whether the pipeline run has been completed successfully.

If the pipeline fails since for example the build is broken, test cases fail or important metrics are not met, rework is necessary. Errors and faults are detected early and can be fixed quickly which is time- and cost-saving. Implemented the right way, CI can be a real productivity booster for software development.



Hardware in CI infrastructure

Although extensive tests can be executed independently from the target hardware, there will be a point in time when the software has to run on the target hardware. Stubbed or simulated environments cannot cover all the potential pitfalls: hardware peripherals are not available or don’t behave similarly to the real hardware, the timing behavior is different, the cross-compiler generates target-specific code and thus not the same code as the compiler that is used for the test environment and so forth. This is why it is reasonable to start with testing on the target hardware already in the early phases.


“Get the most out of your targets”

Working with embedded targets is always accompanied by some challenges: Limited availability of the latest hardware, evaluation boards, and related tools like debuggers are rare goods, and can be damaged quite easily.

A solution can be a setup of dedicated hardware test racks. iC7 BlueBox Debuggers, iC5700 CI, and iC5000 CI are accessible via USB and Ethernet. That allows shared access scenarios: Targets are located in an appropriate environment and available 24/7 from all around the globe. Engineers can access them for development purposes and manual tests, the CI Infrastructure can execute commit - or time-triggered (like nightly) pipeline runs.



Hardware debugger - a powerful testing tool

Testing with winIDEA

Complex test cases can be directly performed via winIDEA by using the flexible and extensive winIDEA SDK to implement the tests. Since debugging tools have full control over the target, it is possible to directly stimulate APIs and verify certain conditions during runtime. It is possible to manipulate parameters and variables and thus force error scenarios via fault injection.

With this approach, on-target tests can be performed on different levels without the need for any test code or test instrumentation on the target side (non-intrusive testing).


Integration in third-party tools

winIDEA SDK offers the ideal solution to give third-party or in-house developed testing tools access and control over the hardware and thus allow on-target test execution. Optimized algorithms ensure high-performance and lifetime-preserving (e.g., reducing flash wear-out) target downloads. The execution of selected test cases can be controlled and test results can be acquired and provided for further processing.


Trace technology

How does a code change affect the performance of the application?

What impact does a module have on the runtime behavior of the system?

Since applications are becoming more and more complex and controllers get maxed out to their limit, it is necessary to deal with such questions. With the implementation of automated timing analysis, it is easy to verify timing constraints and keep an eye on important timing metrics over the evolution of the software. Bottlenecks can be detected at an early stage and if necessary, corrective measures can be initiated. Using tracing technology also allows the non-intrusive measurement of code coverage. Instrumentation code that will affect the runtime behavior is not required.


Add-on modules

With the Add-on modules, all products are also fully controllable via the winIDEA SDK, it is possible to greatly expand the range of applications in the CI environment.

With the CAN/LIN it is possible to analyze the communication on busses in detail and parallel to the software. The ADIO can analyze the signals of the microcontroller’s output pins and stimulate the input pins.