Feature: Automotive
because standards such as ISO 26262 and process frameworks like Automotive SPICE formalise them within structured development lifecycles. However, the growth of soſtware complexity presents a practical challenge that standards compliance alone can’t fully address. Modern automotive platforms may comprise hundreds of
soſtware components executing across multiple cores and interacting through many communication channels. Even extensive validation programs can’t exercise every possible combination of operating conditions, workloads and system states. As a result, some defects emerge only under specific runtime circumstances. A race condition may remain dormant until a particular sequence of events occurs. A timing issue may appear only when system load reaches a certain threshold. Resource contention that appears insignificant during testing may contribute to unexpected behaviour aſter extended operation in the vehicle. Tese failures are oſten difficult to diagnose because they arise
from interactions that are not easily visible during development. Engineers may know that a fault has occurred, yet lack the information needed to understand how the system arrived at that state. In safety-critical development, this matters beyond diagnosis. Runtime visibility helps fill that gap by revealing how soſtware components interact and how the system behaves over time – information that traditional test logs rarely capture with sufficient fidelity.
Understanding behaviour in real time Traditional debugging techniques were developed around the assumption that soſtware can be paused, inspected and resumed. Faults that depend on runtime interactions between tasks, interrupts and shared resources require a different approach, because halting the system might destroy precisely the temporal context that explains the fault. Te critical question is not simply what the soſtware was doing when a fault occurred, but how the system behaved in the period leading up to it. Runtime observability techniques address this directly,
capturing information about scheduling activity, interrupt behaviour, resource usage and communication events during normal operation. Engineers can then reconstruct the sequence of events that preceded a failure. What may appear as an isolated fault can oſten be traced back to a chain of otherwise legitimate events that collectively produced an unexpected outcome – timing relationships that are difficult to infer from source code become visible when viewed through the lens of actual system execution.
Making runtime behaviour visible One of the enduring challenges in embedded soſtware development is that many of the mechanisms governing system behaviour operate beneath the level of application code. Task scheduling, interrupt handling and resource arbitration are fundamental to system operation, yet their effects are oſten difficult to observe directly. Soſtware tracing addresses this by recording execution activity
and presenting it as a coherent view of system behaviour over time. Te approach is not new, but the sophistication of what
can be captured and visualised has advanced considerably. Percepio’s Tracealyzer, used widely in RTOS-based development including safety-critical automotive applications, illustrates what distinguishes a purpose-built observability tool from a general- purpose logger. Where traditional logs present isolated events, modern
tracing tools correlate execution activity across multiple views, linking timing data, kernel interactions and resource usage into a coherent representation of system behaviour. Tis allows engineers to move rapidly from observing an anomaly to understanding its underlying cause. For automotive development specifically, the tool supports
runnables – a concept defined in AUTOSAR-aligned soſtware architectures, where a runnable is a discrete soſtware component typically implemented as a single C function. Tracealyzer treats runnables as a special class of instrumented
interval, enabling detailed timing profiling of individual soſtware components within their execution context. Tis makes it straightforward to measure and verify the temporal behaviour of individual runnables, supporting analysis at the same level of granularity typically used in functional safety engineering.
An example: Diagnosing a watchdog reset A diagnostic example published by Wittenstein high-integrity systems, whose SafeRTOS product is certified to IEC 61508 SIL 3 and is used in safety-critical applications including automotive systems, illustrates the type of timing-related faults that runtime observability is designed to expose (see https://www.
highintegritysystems.com/wp-content/uploads/2026/02/Visualizing_ SAFERTOS_Applications_White_Paper.pdf.). In the example, a customer was experiencing a randomly occurring system reset. By placing a breakpoint in the reset exception handler, they established that the watchdog timer had expired – a timer that should have been serviced periodically by a high-priority task. Without further information, the cause was opaque: the task existed, it had the right priority, and nothing in the static design suggested it should ever fail to run. Te engineer instrumented the system with custom user events
in Tracealyzer, logging the watchdog margin – the remaining time before expiry – each time the timer was serviced. Te resulting trace immediately revealed that the margin was eroding over time rather than remaining stable, eventually reaching zero. Te visualisation exposed the task that was responsible for the missed service, and that its last action before the reset was a call to xQueueSend – shown in red in the trace view (Figure 2), indicating that the call had blocked. A blocked queue send means the target queue was full. But
why was it full? Tracealyzer’s Kernel Object History view showed the complete history of all operations on that queue. Te picture that emerged was of a producer outpacing a consumer: messages were accumulating because the task responsible for draining the queue – ControlTask – was receiving insufficient processor time. Overlaying a CPU load graph on the watchdog margin plot made the relationship explicit: as ServerTask’s CPU consumption increased in the second half of the trace, ControlTask was
www.electronicsworld.co.uk October 2026 31
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44
