Actions
Forum Thread Details
  • Replies 3 replies
  • Subscribers 492 subscribers
  • Views 523 views
  • Users 0 members are here
Related

Consequences of Bad Firmware

fustini

I read this EDN article today:

Toyota's killer firmware: Bad design and its consequences | EDN

On Thursday October 24, 2013, an Oklahoma court ruled against Toyota in a case of unintended acceleration that lead to the death of one the occupants. Central to the trial was the Engine Control Module's (ECM) firmware.

It was very interesting to learn of the different coding standards and safety measures.  For exmaple, error detecting and correcting RAM:

 

Toyota claimed the 2005 Camry's main CPU had error detecting and correcting (EDAC) RAM. It didn't. EDAC, or at least parity RAM, is relatively easy and low-cost insurance for safety-critical systems.

and issues with software not conforming to standards:

On top of that, stack-killing, MISRA-C rule-violating recursion was found in the code, and the CPU doesn't incorporate memory protection to guard against stack overflow.

Toyota's ETCS used a version of OSEK, which is an automotive standard RTOS API. For some reason, though, the CPU vendor-supplied version was not certified compliant.

 

Has anyone dealt with systems and standards like this?

 

thanks!

drew

Parents

  • 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.

Reply

  • 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.

Children
No Data