Fail safe, fail friendly

.I drive a vehicle with an all drive-by wire setup.  Drive-by wire brake, throttle, and PRNDL (the shifting mechanism for those of you not in the Auto Industry (Park, Reverse…)  While as a controls engineer, and an environmentalist, I like both the performance increase and the weight savings to fuel savings that this brings it raises the question, what do you do when the system fails?

Image result for drive by wire throttle body

Primary mode: Fail safe

The first rule of safety critical software (and a break in a vehicle is safety critical) is to fail in a safe fashion.  There are several modes in which a brake can fail, from worst to best

  • Complete sensor failure: on highway
  • Partial sensor failure: on highway
  • Complete sensor failure: parked
  • Partial sensor failure: parked

First, what is a partial failure? A partial failure is when part of, but not all of, a redundant system sends back data that is not in alignment with the other parts.  Standard protocols for drive by wire brakes is to have 3 redundant sensors to determine

Of the four scenarios, the first is the most dangerous and poses an interesting question “what is the fail safe behavior?”  Hard braking could result in a rear end collision.  Failure to brake could result in running into someone.  Of course, this problem is no different from the one found in traditional fully mechanical/hydraulic systems.  For an overview of what to do if this happens, take a look at this article.

Secondary mode: Fail friendly

So what does it mean to “fail friendly?”  In a fail friendly scenario, the objective is for the system to maintain the maximum functionality without putting the user or the device in danger.   In the example of the brake failure, with an all electronic version, the vehicle could allow driving at speeds up to 5 mph.  This mode allows the driver to safely move the vehicle off of roads into a safe parking location.


Final thoughts

The way in which systems fail directly impact the end users experience of the product. Providing the secondary fail friendly mode results in a more positive user experience.


While traceability plays a key role in the software development process for many groups it presents as a high impact burden.  Modern software tools can simplify the traceability process however it all begins with the requirements.

Why is traceability important?

The objective of traceability is to ensure that requirements are met in the final product. Image result for traceability design v mathworksThis is achieved by the creation of traceability “check-ins” at each stage of the development process.  A check-in serves two purposes.  First, they ensure that the design process does not “drift” too far from the requirements.  Second, they provide formal documentation of adherence to the defined development processes.

How do we “check-in?”

Check-ins should be an automated processesImage result for check in where information is cross checked between the current state of the models and the requirements.   If the requirements are written in a testable format than the check in consists of running the tests and a human verification of the test result.  If they are not written in a testable format or the complexity is such that automated testing is not possible then a manual review is required.

Check-in deliverables

The primary deliverable of the check-in is a traceability report.  It documents that at each step in the process the model and related artifacts were validated against the requirements.

Image result for traceability matrix simulink

Final thoughts

Traceability is one of the core activities of a safety critical software design process.  Implementation of automated requirements tracing is greatly simplified in a Model-Based Design environment that includes simulation capabilities.