Reliable Detection of Sporadic Real-Time Errors

- Tweet0
- 0
- Pin It 0
- 0
- Subscribe to RSS
Subscribe

Subject: Reliable Detection of Sporadic Real-Time Errors

REAL-TIME REQUIREMENTS

Dear Friend,

The appearance of sporadic errors in a late project phase, or even worse, after start of production, are a testing nightmare. This is true for functional errors, but it also applies to real-time errors - a frequent sort of root causes behind sporadic issues. To detect, analyse and fix the entire spectrum of real-time errors in a systematic manner, it is essential to create and maintain a comprehensive set of real-time requirements, against which the system can be verified.

For this purpose, the INCHRON Tool-Suite supports 15 different requirement types. These requirements types have been tailored to the needs of our customers. Measurement results can be checked against the requirements based on trace logs (e.g. iSYSTEM, Lauterbach, AURIX DAS tool interface), either post mortem, or on-the-fly during test execution. In the latter case, sporadic errors can be detected as soon as these occur.

The intuitive, interactive and powerful visualization capabilities of the INCHRON Tool-Suite facilitate the root cause analysis a lot. BTW, did you know that understanding the root cause already contributes 80% to the total efforts to fix the issue?

Within safety critical systems, the net slack-time requirement is widely used to ensure and confirm, that the architecture is robust and unintended watchdog resets are prevented. For autonomous driving, the maximum end-to-end latency for functions and the data age are the most important requirements.

This example illustrates a scenario in which end-to-end latency requirement violations happen due to small variations in a system that comprises several activities sharing scarce resources. The first event chain (the series of arrows connecting events from the top line to the bottom line, indicating consecutive events that depend on each other) starts in the upper left corner at t=0 ms, goes all across tasks running on CPU1, the CAN bus, and interrupts and tasks running on CPU2. The event chain terminates within a so-called end-to-end latency of 15 ms, which fulfils the real-time requirements in this particular example. A second event chain of the same kind starts at t=20 ms. Task T_10ms that starts at t=22 ms, however, takes longer to execute, such that it is being pre-empted by T_05ms starting at t=25 ms. This even further delays the execution of T_20ms on CPU1. Moreover, T_20ms takes more time to execute as well, such that it runs into further preemptions. As a consequence, this event chain terminates at the interrupt I_CanRx on CPU2, far too late to be taken into account by the periodic task T_20ms starting at t=31 ms on CPU2. Depending on the way the software is implemented, this issue may either result in data loss, or unintended data reuse.

Further information about requirements and many other topics can be found in our Tool-Suite manual. Now available online!

Subscribe

Subject: Reliable Detection of Sporadic Real-Time Errors