EN 
DE 
Today, embedded systems control an enormous range of applications, from automotive control units and industrial equipment to medical devices and IoT products. Systematically developed and standards-compliant software tests have always been, and continue to be, of great importance for embedded systems.
Errors in embedded software can be particularly costly, especially in the event of product recalls or when functional safety is compromised. What state-of-the-art techniques can help with testing when working in safety-critical environments? When under time or cost pressure, some engineers turn to AI agents for testing assistance. How should one proceed - and is it permissible to do so - when seeking support in this way? How can quality be ensured?
Why embedded software testing presents unique challenges
Compared to traditional IT software, embedded software poses several additional challenges.
Limited resources
Embedded systems often operate with very limited memory, low CPU performance, and strict power consumption requirements. Tests must verify that the software runs under these conditions in all circumstances and also identify these “circumstances.” unter allen Umständen läuft und auch diese „Umstände“ ermitteln.
Hardware dependency
The software interacts with sensors, actuators, and specific hardware. Errors may only occur when the software interacts with the target platform. It is therefore important, among other things, to test with sensors that are at the limits of manufacturing tolerance.
Real-time requirements
Many systems must respond within defined time limits, for example, in the automotive sector or in industrial automation. Testing response times under various load conditions cannot guarantee that the worst-case scenario has been covered. Test runs should therefore be supplemented with an analysis.
Concurrency and Interrupts
Interrupts and the use of an RTOS significantly increase the complexity of testing real-time requirements and make debugging more difficult.
Expensive test environments
Target hardware or specialized test systems are sometimes in limited supply or are costly, such as the system shown in Figure 1. A test impact analysis can help identify tests that can be omitted with almost no risk.
Figure 1: Test environment
Testing doesn’t begin at the end of a project
You cannot “test software into good working order” at the end of a development process if problems already exist at the beginning. Various verification methods throughout the software lifecycle help identify defects early or avoid them entirely.
These include, in particular
- Review and refinement of requirements, which can be performed quickly and cost-effectively today with AI support
- Review of the software design and hardware design for testability
- Static code analysis for early detection of errors
- Unit tests to verify individual functions or modules
- Integration tests to validate the interaction between components
- System tests that verify the overall system behavior überprüfen
- Analytic approaches to ensure compliance with real-time requirements or the absence of data races
Each of these test phases uncovers different classes of defects. For systems with high integrity requirements, no test phase can be omitted.
Black-box testing and structural testing methods
Black-box testing methods are an important component of modern testing strategies. In this approach, a system’s behavior is tested exclusively through its interfaces, regardless of its internal implementation. This method is particularly well-suited for systematically validating requirements.
Furthermore, measuring structural test coverage plays an important role, particularly in unit testing. The coverage achieved assesses the adequacy of tests. Unfortunately, however, a 100% coverage rate is by no means a guarantee of a job well done. Accordingly, ISO 29119, among other standards, also requires the documentation of so-called test coverage items. Tracking structural test coverage in system tests can identify test gaps, but this usually poses difficulties for memory-constrained embedded systems.
Types of system tests in embedded systems
Embedded systems often have to function reliably under extreme conditions. Therefore, specialized testing methods are required. Typical test types include...
- Stress tests - Behavior under overload or during resource bottlenecks
- Load tests - Stability and performance under various load conditions
- Volume tests - Processing of large amounts of data
- Resource tests - Utilization of memory, CPU, or bandwidth
Real-time analysis: Worst-case execution time (WCET)
When a system must meet strict real-time requirements, worst-case execution time (WCET) analysis comes into play. The WCET analysis determines the maximum execution time of a non-interruptible program block. It is particularly important in safety-critical applications and, under certain circumstances, can provide a mathematical proof of compliance with real-time requirements.
Schedulability analysis for real-time operating systems
When multiple tasks run in parallel on a real-time operating system, it must be ensured that all tasks can be executed on time. Schedulability analysis, illustrated in figure 2, examines precisely this question. It verifies whether the planned scheduling can be realized under all circumstances given the available resources and priorities; this is referred to as “schedulability.”
Figure 2: Schedulability analysis
Proving such predictability is not trivial and is performed for a model of the system. Without certain boundary conditions, such as thresholds for maximum interrupt rates or maximum lengths of interrupt service routines, the proof cannot be successful.
Reliable detection of race conditions and deadlocks
Errors caused by concurrency, such as race conditions or deadlocks, are particularly difficult to find in tests. These errors often occur only under very specific timing conditions and are difficult to reproduce.
However, modern analysis tools and specialized testing methods enable the systematic detection of such problems (see figure 3). Under certain boundary conditions, it is also possible to prove that software is free of deadlocks or race conditions.
Figure 3: Test procedures
Scaling the testing effort - from consumer devices to safety-critical systems
Not every embedded system requires the same level of verification effort. A consumer IoT device is tested differently than a safety-critical control unit.
Standards for safety-related software therefore define different integrity levels and corresponding requirements for the scope of testing. These standards can also serve as a guideline for software with high integrity requirements but without safety-critical functions. In such cases, it is a matter of liability to scale the testing effort so that it matches the criticality of the system.
Practical knowledge from real-world projects
Many embedded software testing methods can only be truly understood when explained using concrete examples.
In practice-oriented trainings, developers, testers, and technical project managers learn, among other things,
- how to systematically design unit and system tests,
- which tools are suitable for static code analysis for which types of software,
- how to structure integration tests,
- how to implement requirements from standards such as ISO 26262.
Hands-on exercises help participants apply testing methods directly to real-world problems from their own project environments.
Conclusion: Quality doesn't happen by chance
As software becomes more complex, embedded software testing becomes more complex as well and is emerging as a key competency for modern development teams. Successful projects are characterized by a systematic testing strategy that
- accompanies the entire development process,
- utilizes specialized methods for real-time and resource testing,
- consistently employs test automation, and
- adapts the testing effort to the criticality of the product.
Those who integrate these principles early into their development processes reduce project risk and increase the reliability of their systems. Provided the necessary expertise is available, the testing strategy can also incorporate AI support and reduce testing costs.
MicroConsult MicroConsult specializes in training and consulting for of embedded system manufacturers. We are happy to support you with advice and practical assistance as you introduce new testing methods or expand your testing expertise
The MicroConsult training Testing the Software of Embedded Systems uses efficient examples for all tests and analyses mentioned in the article, and participants can take the examples and sample solutions home with them.
Further information
MicroConsult training: Testing the Software of Embedded Systems
MicroConsult Training & Coaching: Test & Debug
