At least through the mid-late '90s, the American car manufacturers that I dealt with (from the late '80s until then) that were using Motorola MCUs for ECUs had very strict rules that went beyond DO-178B specifically because they were terrified of liability issues (though whether or not this was true in what actually went into production, I can't be certain, just that these were the rules I was told they had to deal with and all our products must supply a way to achieve). I dealt with airline ECUs, also, and never found them to be afraid of caches, for example.
1) no caches, unless the caches could be locked and used effectively as SRAM
2) no DRAM holding any code that was timing dependent (in general, ECUs used only SRAM)
3) the only branch backwards in the code was at the end of the code back to the start of main loop, forget about having function calls.
4) if at any test and set a flag wasn't ready, signal it to be dealt with on the next pass where it could be upgraded to an error
5) any code not written in assembly must be refactored in assembly so that predictable timing could be established
6) in general, everything was polled and interrupts are reserved for panic situations
I did not enjoy working with them and watching them ignore feature after feature that could have improved performance get tossed out the window out of fear or problems that had been pretty completely worked through and resolved before I ever got to college, given enough CPU power and fast enough data paths.
Somewhere around 1994, though, I had the opportunity to start working with the Honda and Ford racing teams, where the culture was understandably different. Able to use 32-bit CPUs to full effect, combined with the 68332's TPU for their timing specific things, allowed them to make the order(s) of magnitude jump in performance to give the soft real time (x can happen before time y, as long as it is guaranteed to happen before time y or a signal is thrown; not the same definition of soft real time everyone uses) approach a fighting chance over the hard real time (x happens at time y, even if delays need to be inserted to make sure that happens; again, not the same definition of hard read time everyone uses) camp. While I am very happy that car manufacturers all seem to have made that jump in every area, knowing that thorough testing of complex code is frequently the first thing management gives short shrift as deadlines approach does keep me open minded to the possibility that software could be the problem in situations like the acceleration issues. I can't recall of a situation where inadvertent acceleration was tracked back to anything ECU related, for what ever that's worth. Other aspects of car management, however...
