The complexity associated with the development of embedded systems is increasing rapidly. For instance, it is estimated that the average complexity of software projects in the automotive industry has increased by 300% over the past decade.
Today, every piece of hardware is driven by software and most hardware is composed of multiple electronic boards running synchronized applications. Devices have more and more features, but adding features means increasing development and debugging complexity. A University of Cambridge report found that developers spend up to 50% of their programming time debugging.
Thankfully, there are practical ways to reduce the complexity of debugging embedded systems. Let’s take a look.
Earlier is better
Debugging will only be efficient if you have the right information.
Bugs will pop up during the entirety of a product’s lifetime: in development, testing and in the field. Resolving a bug later down the road can increase costs by as much as 15 times and lead to user frustration, in addition to creating challenges associated with updating embedded devices that are in production.
However, identifying bugs at the early stages of your product’s development will allow you to track them while prioritizing them by severity. This will allow you to debug before other dependencies and variables are introduced later in the lifecyle, which makes bugs easier and cheaper to resolve.
To properly replicate a bug, you must be able to have a device in the exact same state it was when the bug first appeared. With embedded devices, there are three distinct variables to look at when issues crop up:
- The software version. This is the version of each feature. This applies to the code you build as well as to potential dependencies, such as imported libraries.
- The board version. Specifically, the design of the board. Board design changes constantly as components are added/removed or moved around.