Perhaps surprisingly, most embedded systems have some element of safety involved with their use. If you're lucky the safety part is dealt with in hardware. But sometimes software is involved too.
Safety problems are often caused by the uncontrolled release of energy (or, in some cases, information) into the environment. Since most embedded systems have actuators, and most embedded systems have software bugs, there is the potential for uncontrolled release of energy due to a software bug. Thus, most embedded systems have some aspect of safety that must be considered during design.
The good news is that in many cases the potential outcomes aren't that bad, so nobody is going to get killed because of a software defect. But that isn't always the case, and it may not be obvious there is a safety problem if you don't give it some serious thought.
Ask yourself this: if the software does the worst possible thing, could someone get hurt? Not the worst possible thing you've designed it to do. We're talking about bugs here -- so you don't have any idea what the bug will make the system do. Instead, take a healthy serving of Murphy's Law and ask yourself if the system software really wanted to do the worst possible thing, what would that be?
Here's an example. If you design a microwave oven you don't want the cooking energy to be released when the door is open. If you use a hardware switch that interrupts power, nothing your software can do will cook the user. But if you rely purely on software, you can't just say "seems to work OK." You have to make sure there is no possible software bug that can turn the cooking power on with the door open (even if the software "wanted" to in accordance with Murphy's Law). You may not think a bug this severe is there, but you can't really say your system is safe until you've taken a methodical approach to knowing such a bug isn't there.
In a sense, the art of getting safety right is thinking up all the worst possible things the system could do and then demonstrating it can't do them. There are many software safety techniques that address this issue, but you have to use them or you won't know if your system is safe. You can find out more about embedded system safety in Chapter 28 of my book.
A connection on LinkedIn asked me for help deciding between job offers. I can't provide personalize advice, but here are my thoughts in ...
(If you want to know more, see my Webinar on CRCs and checksums based on work sponsored by the FAA.) If you are looking for a lightwei...
Cyclomatic complexity is a measure of the number of paths through a particular piece of code (a higher number means the software is more com...
If you want to estimate how long it's going to take to create a piece of embedded software (and how much it will cost), it's useful ...