Handling of complementary errors in embedded software

Question

I've to design a firmware for an embedded device which may be in different error conditions at the same time. Each error condition requires to set the hardware components of the system into different states. Means every error condition requires a dedicated transition callback function for entering the error sub-state or a dedicated "in state" logic which is executed simultaneously with potential other error sub-state logic. In addition the states of the HW system components may be conflicting in different error conditions. Means there is need for prioritization to resolve potential conflicts between "safe states" for different error conditions. Each error condition shall be acknowledge-able. Means each error sub-state requires explicit transition callback function for leaving the error sub-state.

How should I model this design using e.g. an UML state diagram?

BTW: I've designed UML state diagrams before. However I never had to deal with that kind of requiremenst before. In my opinion the requirements cannot be abstracted in an "off the shelf" state machine design like I used before. The question is not about UML state diagrams but the given requirements.

Answer 1

Generally, the approach depends on if your program has a safe mode where certain outputs are always disabled, or if it must almost continue running though with reduced functionality. The former is by far the most common and the latter is typically just appearing in automotive & med-tech etc mission-critical control systems.

In the former case with a safe mode, you could weigh different kinds of errors to decide if they are severe enough to merit a transition to safe mode.

And then it also depends on the nature of your system, is it RTOS/multi-process or a single-process bare metal one. In either case you might want to implement a centralized error handler, how to do so might vary. C code example of a bare metal single thread system running a simple scheduler or state machine might look like this:

// main.c
for(;;)
{
  pet_wdog();
  result = run_state_machine[state]();
  if(result != OK)
  {
    error_handler(result, &state);
  }
}

Your error handler can then check the type of error returned from each state (or task, module etc), then make a decision based on the error. What state should it switch to next etc. Optionally you could run some callbacks from the error handler if that makes sense, in order to keep the module-specific code (disabling outputs etc) in the module where it belongs.

The advantage of handling all errors and state transitions from a single place is to avoid "stateghetti", a form of spaghetti programming where a state machine etc changes states from all over the place, with numerous local error handlers. Such designs make trouble-shooting and maintenance a real pain.

As for how you want to draw this design, that's not really important. Use UML, old school state charts or just some manner of generic bubbles & arrows. Long as the code reflects what you have drawn. What's most important is to give the design some thought before you start coding away. Re-designing an existing program is always a major task with high probability of introducing errors. Better then to get the design right from scratch... which is of course easier said than done.

Answer 2

A standard state machine can handle it. Each 'working' state would have a transition to the error states and the error state themselves would implement priority by switching to the 'most important' error.

Formally the switching condition (assuming E1 is more important than E2) would be:

on (E1) -> E1-state
on (E2 and not E1) -> E2-state

since to be unambiguous the transition conditions have to be mutually exclusive. In practice just code the E1 condition before the E2 one (unless you have a CASE tool, in which case the full expression is needed).

Do not try to graph such a state machine, it's an horrible mess! Pure state machines are not quite useable for these things (like, have you ever needed a counter in a pure FSM? good luck with the state count)