@Aerospace, If I understand Barr's work correctly, he found a single-point failure mode, not multi-point failures as you claim.
Barr's conclusion that Toyota's software is defective is actually less important, in my view, than his conclusion that their engineering processes are defective. This validates the strong impression I and others have had in reviewing the 230 electronics-related internal Toyota engineering documents. The docs reveal a kind of seat-of-the-pants engineering, where engineering processes allowed designs in which Toyota engineers had to do detective work to find out why vehicles behaved unexpectedly, both during development (which may be acceptable for design processes of non-safety critical systems, but not for safety critical), and when receiving reports of vehicle behavior on the road, in the real world. I think you engineers can agree that a safety-critical machine must be absolutely predictable in its behavior, and the Toyota engineers recognized that the vehicles they were making were unpredictable. At times they used the word "ghost" to describe performance changes that they observed. Is this normal? Is it safe?
Barr's view of the substandard engineering practices that produced substandard designs has been supported in various ways by his colleague Dr. Koopman, as well as by engineers Gilbert, Leidecker, Barrance, Anderson, Rajkumar, Belt, Kirk, Hubing, Pecht, Armstrong, among others, both in the laboratory and in theory, the theory being primarily a comparison between proper safety-critical engineering practices and the practices that become evident in vehicle examinations and document review. The views of all of these respected engineers, taken together, substantiate Barr's conclusion about the engineering.
There is data that these failures occurred in the real world. The data exists but has not yet been published.
It is also plainly obvious that the hundreds of serious lawsuits against Toyota show that actual vehicle performance reveals engineering flaws. These vehicles are unpredictable on the road. That is a defect. As attorney Cole Portis pointed out in his interview on Israel's Channel 2, none of these lawsuits would have even been filed by law firms for plaintiffs if the facts could easily lead to blaming the driver for the death or catastrophic injury.
I will be very interested to learn why the DOJ ignored the electronics.
@AeropsaceEngr, respectfully, I disagree. If What Mr. Barr did was merely "postulating a combination of multiple failures," Toyota hasn't actually proven that the sticky pedals or floor mat actually occrred in the real world, either.
But I digress.
You may want to read what B. Benjaminson wrote here in a separate thread:
Mr Barr did not "prove" that the truly fatal flaw that "caused" unintended acceleration in the affected Toyotas lay in the software that had been designed into the vehicles' computer systems. He postulated a diabolical combination of multiple failures that could possibly cause unintended acceleration. There is no data indicating that those failures have actually occurred in the real world.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.