[hga]

Outside of legally-critical software, such as automotive control systems: it doesn't seem that there is much focus on quality.

The analysis of Toyoda's software that might have been behind the claimed acceleration/can't stop the engine problems indicates that even there, at least Toyota is all but hopeless.

[schwarrrtz]

Yup.

> There are a large number of functions that are overly complex. By the standard industry metrics some of them are untestable, meaning that it is so complicated a recipe that there is no way to develop a reliable test suite or test methodology to test all the possible things that can happen in it. Some of them are even so complex that they are what is called unmaintainable, which means that if you go in to fix a bug or to make a change, you're likely to create a new bug in the process. Just because your car has the latest version of the firmware -- that is what we call embedded software -- doesn't mean it is safer necessarily than the older one….And that conclusion is that the failsafes are inadequate. The failsafes that they have contain defects or gaps. But on the whole, the safety architecture is a house of cards. It is possible for a large percentage of the failsafes to be disabled at the same time that the throttle control is lost.

> Even a Toyota programmer described the engine control application as “spaghetti-like” in an October 2007 document Barr read into his testimony.

http://www.safetyresearch.net/blog/articles/toyota-unintende...

[microcolonel]

I have seen analyses of ECM software; and I think they could benefit greatly from a new language.

The priority seems to be reliable real-time computation, and the solution is to calculate everything as a continuous function. Anything that would be a branch is instead a binary mix of the conditions, triggered with a threshold function.

I can think of many ways of structuring programs which are spaghettiish in C, but would yield the desired results in an automotive ECM.

[woodman]

I've tackled some problems that would have ideally, from a performance perspective, been implemented with very deeply nested if()'s. I've found a truth table like layout of bool evaluations to be a nice compromise between maintainability and performance:

  void doit(const tststructptr* in) {
    assert(in);  /* Because we test our code, for safety */
    const tststructptr t = *in;
    if      ( t.t1 &&  t.t2 &&  t.t3) { f1(); }
    else if ( t.t1 && !t.t2 &&  t.t3) { f2(); }
    else if ( t.t1 &&  t.t2 && !t.t3) { f3(); }
    else         /* TODO: Fix, this should never happen */
      releasenerveagent(SLEEPINGQUARTERS);
  }

A long sequence of ternary operators allow for a prettier layout, but is more error prone.