If there is a proper safety critical engineering process in place, do you think it is even possible for Toyota engineers like this Mr. Ikura to be guessing why vehicles are misbehaving on the road, after the fact, and that their guesswork involves vehicle electrical systems?
Here is a quote from a Toyota internal email that is almost surely is in the possession of the DOJ, one among perhaps a hundred similar emails:
"This is Ikura from 2SE-6G.
-Is it possible that the RPMs rise due to radio wave interference? And what level are the European standards?
(Previously, when I was in charge of Hilux in the Japan domestic service division, I experienced an engine stall malfunction due to radio wave interference from a nearby U.S. Naval Base in Yokohama. At that time I was told that it could absolutely never occur.)
→ Frankly, I (2SE) really do not understand this. At the very least, departments concerned with various electrical items must be gotten involved in a discussion."
What could that "discussion" entail?
I also find it astonishing that poor Mr. Ikura was treated to the same mind-bending response from his colleagues--basically, their claim that he did not experience what he experienced--in a weird echo of the treatment reported by many hundreds, even thousands, of Toyota's customers.
I have drafted a letter to a U.S. Senator to request an oversight review of the DOJ investigation scope. Anyone who wants to sign this letter with me can be in touch via my blog -- betsybenjaminson.blogspot.co.il
Toyota's engineering documents on vehicle development and determining the causes of SUA (most of these were the same docs as the ones turned over to the DOJ) have been reviewed by experts who know those standards very well, and I can say with confidence they saw no evidence that Toyota was following the standards. One of them, a software expert who specializes in safety-critical software development, said that he was "shocked."
It bears noting that much of Toyota's code was written before ISO26262 was published.
Barr's testimony indicates that the MISRA-C standard was more relevant. But Toyota did not follow its rules either.
I saw many references to "Toyota Standards" but also instances where people inside Toyota were attempting to change test protocols or pass/fail criteria for the throttle or ECU (one such attempt came from a throttle supplier, and one such attempt came from Toyota to Denso), and these seemed to be based on cost considerations. "We lack sufficient budget, so can we please just test once instead of the prescribed X times?"
Are you telling me that they did not follow even ISO26262/IEC61508 ?
I find it very hard (according to your analysis) that so many issues arise from firmware, when the process is so exhaustive.
Or, they did not follow any process at all. But they are required to, as far as I know. So I will assume a process was followed, but it [miserably] failed.
If this is the case, processes must be revised to minimize these things from happening. Although process is not itself a guarantee of high-quality, it is indeed a requirement for the high-quality to be achieved.
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.