[joezydeco]

And you're not familiar with what happened when a 3rd party (Michael Barr) was allowed to FINALLY look inside Toyota's engine code and determine the cause of the "Unintended Acceleration" problem:

"Barr checked the [Toyota] source code against MISRA’s 2004 edition and found 81,514 violations."

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

[OopsCriticality]

The model year 2005 Camry in question from the trial would have been made available in 2004, and the electronic throttle control system was designed prior to 2004 (IIRC, the ETC design was carried forward from the previous model). How does it makes sense to apply MISRA-C:2004 in this case, especially when the Toyota ETC in question was admittedly not designed under MISRA-C:2004 nor prior MISRA-C revisions?

It is inaccurate to claim Michael Barr determined the cause of Toyota's unintended acceleration: he proposed a possible failure mode that was persuasive to a lay jury. His proposed failure mode didn't leave a DTC, so there's no way to actually know if his proposed failure mode actually happened in this case (or in any other).

[danielweber]

Barr always struck me as something of a charlatan trying to bamboozle a jury.

[dogma1138]

I remember when this was posted on HN before, what I always wondered about is the discrepancy between the violations that NASA found and Barr.

NASA found 7000 and change Barr found over 81,000, I'm not sure whats the size of the code that was reviewed but that's allot, even if you count the fact that half of them might be silly like naming convention violations that still leaves quite an odd number for actual violations especially when considering that the code for an embedded system can't be that huge.

And the 10,000 global variables thing, well 10,000 sounds like a huge number but there wasn't any mention if they were a) necessary, b) implemented correctly, and c) out of how many variables in total? if the code they've tested has say 1 million variables then well.... And how they described global variables is also weird, they claimed that every software within the system can access them to me this sounds that your stereo or the rain sensor for the wipers can override data for the breaks, but that might be true only if everything is running within a single application.

If the breaks run as an independent application well then only every function within the break software (depending on the language and how global variables are implemented) could potentially access those variables.

To me pretty much that entire explanation seem to be constructed to sound worse than what it is, which is why I think that expert witnesses should only be allowed to be appointed and called by the court it self (as in by the judge so they and the jury could understand the technical details better) and not by either the defense or the prosecution.

[zb]

> there wasn't any mention if they were a) necessary,

They were not. It is never necessary to have 10,000 global variables. If you have 10,000 global variables you are systematically Doing It Wrong. (That's not to say it's uncommon. From my experience I strongly suspect that it's a very common practice.) As one of the witnesses put it, quite correctly IMO:

"And in practice, five, ten, okay, fine. 10,000, no, we're done. It is not safe, and I don't need to see all 10,000 global variables to know that that is a problem,” Koopman testified.

Trying to justify this is like trying to justify not having a bug tracker. Which, BTW, they didn't.

> b) implemented correctly,

There's no way to check 10,000 global variables to see if they're implemented correctly, and that's the entire point.

> and c) out of how many variables in total?

That is completely irrelevant.

> they claimed that every software within the system can access them to me this sounds that your stereo or the rain sensor for the wipers can override data for the breaks,

This was the ECU, it only controls the engine, not the radio or the wipers. It has tasks for stuff like monitoring the engine and wheel speeds, the accelerator and brake pedal positions and controlling the fuel injection. And all of those tasks were only an extra header file and a typo away from stomping on one of the 10,000 global variables belonging to another task, but that isn't even the issue. The issue is that there is no way to trace the flow of data in the system because it's completely unstructured.

> but that might be true only if everything is running within a single application.

Welcome to the world of embedded RTOSs, where everything is running within a single application. It's not a PC. "Applications" aren't a thing. There's certainly no memory protection.

[cnvogel]

    > Welcome to the world of embedded RTOSs, where
    > everything is running within a single application.
    > There's certainly no memory protection.

Generally, I agree, even though there have been quite a few chips already that have a primitive "Memory Protection Unit" that typically only distinguishes two processor states and you'd be able to protect the working data of e.g. the scheduler and your watchdog from the rest of the code running on your system. Which is much better than nothing!

But in the end the important consequence is: Having everything in one address space encourages people to violate the concepts that memory protection between tasks on your PC typically enforces, e.g. tasks reading from, and writing to other tasks' data structures without proper synchronization; instead of using proper IPC mechanisms like queues. Which is probably what these 10'000 global variables were used for.