How can the completeness of integration and system tests of embedded systems be measured? This is done mathematically exact with structural tests. Unfortunately, the software instrumentation often used for this has the disadvantage of interfering with the timing of the release code and a number of other things. This is not necessarily important for module tests, but it is usually the case for higher level tests. So what to do?
In the presentation, a new observation method will be presented that non-intrusively and continuously measures the structural test coverage by means of a live synchronized digital twin. And thus provides an exact statement of how many white spots remained when the higher tests were performed. Is this non-executed code only accessible for module tests or not at all? Or is it missing one or the other test?
In addition, the deep view into the processor (without affecting the application) also allows parallel monitoring of a large number of complex timing constraints. These can be conveniently described in a high-level language and sound an alarm if, after ten hours of operation, a function has taken one microsecond too long. Without software instrumentation.
To improve the testability of an embedded system in this way, some software and hardware requirements must be taken into account when planning the system architecture. At the end of the presentation these are also explained.