Consequences of Bad Firmware

I think one should exercise great caution in interesting the reports on this subject. The current court proceedings are based on a huge project conducted entirely by those with a vested interest in blaming Toyota. What would really inform the discussion would be comparative analysis of other suppliers code for similar applications. My limited experience of safety critical systems development (mainly as an onlooker) suggests that Toyota's practices (as alleged) are not unusual.

No evidence has been offered (as far as I am aware) that the Toyota ECU actually malfunctioned - the assertion (probably true) is that it could.

In my view the most worrying aspect of the design was the lack of a fully independent check/failsafe system able to cut off fuel injection if the brake pedal was pressed.

I have zero confidence that any complex software system is free from faults - the only safe approach is to assume that the ECU is actually intelligent and quite determined to crash the car - and install some other simple system to shut it down when it goes off the rails. If this isn't possible then don't automate the functions in question.

MK

It's always difficult to comment on these, especially when there's lawyers involved. Design work in the automotive industry has long been cost based, and part of that is weighing up the likelihood and effect of a failure.

No complex software is foolproof, the more you add, the more could possibly go wrong. There's plenty of things that could go wrong, some of them are very unlikely and trying to write in the code everything you could think of makes the matter worse.

Safety Critical applications I have come across usually involve redundancy, status monitoring and a link to a hardware correction path (eg cut power and progressively apply brakes in Rail applications). It deals independently with one component in system failing by having another able to override what is usually a non-responsive module. Note usually the case in automotive, the braking power of a car always well exceeds the power of the engine, stand on the brakes and you'll stop and stall the engine.

Hi Drew,

The safety issues in software/firmware development has been a hot topic for years.

The requirements for a system are usually not passed down to the components since the end user/manufacturer is on the hook for testing/demonstrating compliance.

It is very hard to determine what a company did or did not do to verify compliance.

I know that in the DoD, the government would usually insist on an independent verification and validation group for any device that could result in a life threatening scenario.  Having participated on a number of these, the review process is very thurough and the testing is always scrutinized heavily to make sure that the conditions for catching failures is always observed.

I have been very disappointed to see the the Auto industry is reinventing a lot of software, standards and testing capability that the Aerospace industry has spent decades resolving.  I see a lot of "Not Invented Here" mentality as the vehicles get more and more software/firmware driven.

So in many ways, I am not surprised at the results.  A look back at the incidents of software issues in Aerospace should have alerted the Auto industry about the issues.

Their failure to learn from the Billions of dollars spent making systems "safe" has been very disappointing.

Perhaps this ruling on Toyoda will wake them up so that they do a better job of researching systems designs and borrow many of the standards that are common in the Aerospace industry.

Or they can continue to sell defective vehicles just waiting to crash.

Just my opinion,

DAB