"On a tangent, seeing how difficult it is to write flawless software for a ECU, is there any hope of writing good software for a self-driving car, which is an immensely more difficult problem?"
Really? How is self-driving immensely more difficult, if barely competent humans can manage it, while even expert humans couldn't begin to master what these engine controls are doing? Remember that the reason for the electronic engine controls, including electronic fuel injection, are not because the automakers wanted to pile on glitzy electronics for better sales. They were pretty much mandated by the stringent pollution control and fuel economy requirements. Catalytic converters cannot survive with carburators, much less sloppy incompetent human manual controls.
Not sure why so many people believe that driving a car is the most difficult thing imaginable.
Frankly, I like this take. (Sorry, I couldn't resist) Anyway, I'm with you, Frank. For me, his argument had a very philisophical feel to it. In other words, as I'm reading the exchange I wasn't questioning the limits of Toyoya's capabilities, I was questioning the limits human capabilities. And this time the laws of probability just happen not to be on Toyota's side.
Of course, mitigating that argument is the fact that no other manufacture's vehicles have failed in this way. But it still felt too philisophical to me. If I was a jurer, I would have needed some serious convincing beyond this.
More correctly, Barr should have said that the purported software event contributed to the crash (or even was a major contributor to the crash), since the layered failsafes did not successfully avert disaster. Saying the purported software event caused the crash is too strong; it is like saying that a butterfly the car hit caused a cascade that resulted in the crash. In reality, if one believes Barr, too many small things went wrong at the same time-- and it can happen to anyone at any time [here, car accelerates, environment is such that there is something fatal to crash into before a successful response can be made by the final failsafe, the driver, whose performance is variable across the population]
It is actually remarkable that the fairly poor reliability COTS hardware actually works as well as it does in the automotive environment. Barely any error detection/correction in the cores and still millions of cars drive around successfully every day. Or perhaps it is just because the surrounding environment of sensors and wires and exploding hydrocarbon in metal cylinders is so unreliable by comparison that people blame something else when the "wheels fall off"... like wings falling off a plane. It happens, but far less often than other failures so virtually no one worries about the wings falling off the plane when flying.
I think with the event of electronicly controlled transmissions and brakes and a common bus that connects these to the ECU(throttle) in the event of cascading failures this may not be feasible.
I have personally experienced two ABS failures and one other failure of Mechanical brakes - I walked away from all of these by pretty much using the transmission to shift into low, combined with the emergency brake to do this. Had this mechanical backup not functioned I would likely be in much worse shape medically than I am now.
Aircraft systems typically use three independent channels be they mechanical or eletro-mechanical -- any one of which will maintain control of the aircraft in the event of the loss of the other two.
This article (and all discussions on this subject) seem to ignore the number one safety system in place in all of these fly-by-wire cars, and that is the DRIVER.
For decades, drivers had to deal with the possibility of a stuck throttle. Were cables worry free?
In all of these supposed run-away cars, there was a transmission which could be mechanically shifted to neutral, and an independent hydraulic braking system which could stop the car, even if the engine was buzzing away at redline.
That doesn't mean the manufacturers shouldn't do their best to build a car that is bug free - but the ultimate responsibility lies with the driver. If the car does something unexpected, shift it to neutral and stop, period. If a stuck throttle is something you can't cope with, you probably shouldn't be behind the wheel of a 4,000 lb projectile.
There is no perfect world, all we can do is to make it better and better over time. Complexity is a problem yes, but modular/reuse-based design, agile software development, and continuous improvements can reduce the risk of bugs dramatically.
All the ECU controlled cars has this kind of automated control with manual control provided for the driver, but we can not say that it totally manual. Where ever automation is there these kind of malfunctions are possible. We should be ready for these kind of accidents as now the time is coming up for driver-less autonomous vehicles. God knows about the dependency on machines then afterwards.
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.