Let’s not forget about software safety

Published by Jorge on

safety architecture defect

Software defects can kill people. I’ve revisited the case study of the unintended acceleration in Toyota cars in 2009 by Phil Koopman. You couldn’t believe what was found. For those that don’t remember, the case went to court for some deaths attributed to defects in the Electronic Throttle Control System (ETCS) that caused unintended accelerations with billionaire fines. Even the NASA helped audit the system.

The report shares a lot of evidence about the practices and parts of the design. These I found more painful: using old codings standards, having over 60,000 MISRA violations, no bug reporting system, no unit tests planned for a function with 146 cyclomatic complexity with more than 10,000 lines of code, and that pedal signals were not redundant, providing a single point of failure.

How this could happen? If you have ever worked in the software industry you can imagine. Most companies have quality standards. Likewise, unrealistic deadlines and projects that can’t bear time deviations. As time passes, people trade quality over speed making shortcuts to meet deadlines. But that doesn’t seem to be the only case. You can see that safety wasn’t a priority concern for the company. Seems like it was too early to care about it.

Back in 2022, software safety plays a major role in safety-critical systems despite making harder, more expensive, and slower the development. Automakers are pushing for faster development paradigms and shortening the time to market. At the same time, cars are becoming software and the complexity of the systems is growing. For this reason, keeping software safety into account is more critical than ever.

Let’s not forget this case as an example of what should be avoided and learn from it.

A Case Study of Toyota Unintended Acceleration and Software Safety


If you want to read more like this, subscribe to my newsletter or follow me on Twitter