RTOS applications rarely fail because a single task is misbehaving. Instead, problems emerge from interactions that are often invisible at the code level.
Premium car manufacturers like BMW – companies with strong internal development expertise and decades of software experience – are investing in modern development tools to manage the growing complexity of today’s vehicle architectures.
One question I’m often asked—and one I often ask myself—is, “How many people are currently involved in developing embedded systems?” Counting engineers is a slippery problem (especially mechanical engineers, because they are often dripping in oil). I’d hazard a guess that there are probably between 2 and 4 million embedded professionals globally (depending on how we define ‘embedded’ and ‘professionals’), including both hardware designers and software/firmware developers.
Now I have another question for you. How many embedded system development teams around the world are using the tools from Percepio? The answer to this one is easy: “Not as many as there should be!”
In a case highlighted by debug specialist Percepio, a company building HVAC systems found, once again, a low-importance task failing to compete as expected. Once again, a watchdog timer reset the device. Without logs of what happened, they just looked like random reboots. With data captured by the targets themselves, developers obtained the clues they needed to create a fix.
…This kind of in-field observability is clearly not new. But it is taking on greater importance thanks to the proliferation of networked devices.
The world of embedded systems evolves, with devices growing ever more sophisticated and software-centric. In this new landscape, with highly interconnected environments that defy traditional testing and debugging approaches, a reactive, fire-fighting mentality is no longer sufficient. Developers need a proactive strategy to gain continuous visibility into system behaviour—a strategy known as observability-driven development (ODD).
A daunting task otherwise, Percepio’s Tracealyzer and Detect are changing the game of debugging embedded systems with real-time observability and faster fault resolution. Speaking to Johan Kraft and Andreas Lifvendahl, EFY’s Nidhi Agarwal explores how these tools are transforming development workflows. The hardest parts are timing-critical embedded systems, where adding instrumentation or software tracing introduces unacceptable overhead. It becomes even more challenging in heterogeneous systems built from third-party components, where we do not have full access to source code or internal behavior.
When using Percepio Tracealyzer and TraceRecorder, you may have noticed that thread names show up automatically, while other kernel objects (like queues or semaphores) are only displayed as hexadecimal numbers. But in the demo traces, all kernel objects have proper...
At Percepio, we appreciate Zephyr’s hardware abstraction and kernel architecture, which make it easy to get up and running on a wide range of hardware. Thanks to this, we have validated that Percepio Tracealyzer works on over 600 Zephyr-supported development boards.
The right tooling and practices around continuous observability is the developer’s seatbelt for software crashes, and can save you from a lot of pain down the road.
Tracealyzer 4.9 brings improved support for LynxOS-178®, the standards-based RTOS for safety-critical real-time applications from Lynx Software Technologies.
We serve cookies. If you think that's ok, just click "Accept all". You can also choose what kind of cookies you want by clicking "Settings".
Read our cookie policy