Embedded Systems without logging is a pain. But with logging it’s very often a desaster, too.
I wanted to present you my thoughts how to improve logging.
It’s not for the super experts knowing everything and every detail of your system by heart. But it’s for all the regular engineers out there who are facing a failing system. A system providing either nothing or an awful lot of superfluous information.
What if you would introduce an indicator describing the system’s healthiness. Something what would highlight an immediate status of the system: healthy or unhealthy. Stable or unstable. Reliable or doomed.
The system-healthiness indicator needs much effort before you can use it. But it will be a walk in the park afterwards. No longer fears of uncommon errors. No longer daylong investigation to find the failing parts in your system.
Stay tuned and be inspired.
Essential Answers Provided In This Episode For:
- Why is it logging that difficult in Embedded Systems?
- What is the intention of logging?
- How’s logging regularly done?
- Why is it dangerous to let SW-developers simply print out their algorithm’s result?
- How to make logging easier to find problems faster?
- What does system healthiness mean?
- Example: How to determine a healthy startup?
- How to implement System Healthiness for logging?
- What are the benefits of the healthiness approach?
- How to use Fourier Transformation in logging analysis?
- What are the prerequisites of using a healthiness indication?
- And much much more.