Just how many stories are here on EE Times about the Toyota "sudden acceleration" that completely fail to mention that the brakes will stop the car no matter how bad the embedded software is??
And do any of them mention the past history of "sudden acceleration" cases that were all found to be driver error??
To be clear, with the engine at full throttle, the brakes will stop the car. Unless the brakes are defective, and in all the publicized cases the brakes were found to be fine. So that means there had to be a simultaneous instance of "sudden acceleration" and phantom brake failure.
In the Oklahoma case, the black box in the plaintiff's Toyota also happened to conveniently have incorrect information about the fact that the driver/plaintiff was not applying the brakes. So for her story to be true we had sudden acceleration, phantom brake failure, and a lying black box!
For less sensational and much more informative coverage try:
Cross manufacturing has been SOP in the Auto industry at least since the 1970's. One example is power steering units that used to be made by then-GM's Saginaw Steering div, now part of Delphi. The drive units were used on GM, Ford, Dodge pickups and light trucks and probably used in other makes as well. Ford's now defunct Visteon used to make controls and sensors for GM and others so nothing new.
Duane, that is an excellent point. In fact, in this case, the main CPU was supplied by NEC (now Renesas); and the sub CPU (or a monitor CPU) was supplied Denso. Much of the code running on each of these CPUs were written by each supplier separately, and delivered to Toyota. So, the whole chain of who developed what stuff is getting much more complicated these days.
Good poit. From what I read so far, I know they made some correcitons. But then, at a time when the company is NOT acknowleding that there were bugs in the software, it is hard to tell what fixes they are making.
This sounds like some manager or accountant did not even approve the right tools for the Job. Memory Leak Detection Tools like Purify, and code Checking tools like LINT have existed for decades, and are very affordable.
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.