GM recalls 196,000 Hummers due to risk of fires – 3 people burned

GM is recalling nearly 200,000 vehicles

because the connector module that controls the blower motor speed in the heating and air conditioning system may overheat and catch fire.

It has confirmed 42 fires and in three cases 3 people burned.

Two of the three Hummer models in which people sustained the burns were destroyed by fire. .

Source:  Reuters  July 8, 2015

1 Comment

  1. Er … are we sure that this is actually a *software* fault? It sounds more like hardware to me?

    (Don’t get me wrong. I’m not an apologist for bad software engineers. Having worked for over 40 years as a software engineer, I know just how lax they can be and have on occasion made myself very unpopular by criticising lax working practices.)

    On the other hand it would not be the first software-induced fire. Back in the 1960s at the University of Manchester Regional Computer Centre they had an Atlas computer. This could be made to play tunes on the console by sending click pulses to it at controlled frequencies. One enterprising student programmer programmed it to play a Bach fugue. The music was OK but it made the computer console catch fire. Reason: The loudspeaker to which the click pulse was sent was not rated for continuous operation and overheated while rendering dear old Johann Sebastian. The fire was dealt with but not before it has destroyed the console, a replacement for which was found by accident when someone found the only one left under a tarpaulin in the basement of the maker’s headquarters building in Putney, SW London. Shortly thereafter a spoof specimen examination paper appeared on a notice board the the Manchester University Computer Science Department. On it one question read, “State the fire precautions to be observed when programming the Atlas computer”.

    If GM software is burning Hummers, at least it’s nothing essentially new … which is alas the only comfort I can offer.

    Incidentally I am the original author of the MISRA C coding guidelines for critical software. This now represents itself as an important standard – but it’s provenance is far from auspicious. Back in 1997 I was working for a developer of static checking tools for C. A then UK motor manufacturer sent us for review a draft of its own in-house coding standard. I was asked to perform the review.

    IMO the in-house version was terrible and I went through it writing down what I considered to be better rules. The effort was, if I recall aright, just three days. We sent off the review and were paid by the client. A few months later we received a first draft of MISRA C for comment. Behold therein were almost verbatim the rules I had scribbled down in haste a few months earlier. Of the rules that had been changed, all had been weakened or made more vague. Developments since then in the MISRA C Panel have, IMO, further weakened the standard.

    For version 2 of MISRA, I proposed a tightening of the definitions and the use of syntactic metlanguage to give precise characterisations of language constructs that might need to be controlled. The proposal was rejected, ostensibly because, “it would put off the user cionstituency” – for which read, “automotove software engineer cannot cope with technical precision”. At that point I disengaged from the MISRA C Working Group, partly because I was facing some major surgery, but also because I had lost confidence in its ability to make technically sound decisions. O am still of that view and now, though the working group convenor will officially deny it, I am unofficially banned from participation.

    That’s how industry standardisation works, folks!

Leave a Reply

Your email address will not be published.