The Prius problem in particular strikes me as a pretty rare occurrence. You have to be driving a 2010 model manufactured before January 2010, and it has to be a model with ESC. Even then the Prius extremely rarely uses friction braking; only for extremely hard braking, ABS or ESC events, and braking below 8MPH does the Prius use the friction brakes. Then, as I read it, on top of that, you have to be in transition from gasoline to electric power (or possibly the reverse) at the exact moment of an ESC event, and you then have to depress the brake pedal for less than a second.
Now that being said, yes, I certainly agree that Toyota deploy the fix to all affected owners, but gosh, I don't see any need to "freak out" here.
I believe Mr. Psiropoulos is just trying to create some thought provoking discussion here. Embedded control is everywhere and here to stay. No matter how you cut it the advantages out weigh the risks.
Here is another software failure that is much worse: the human brain, which results in over 40,000 automotible deaths per year in the US. How do we fix that problem? With electronics and software!
I can't believe, that this is an article from Honeywell, which developed a special metholodogy to develop a safe software/system. And from which one are derived sevaral others.
I can't believe, if you look around yourself, how many things have in the a control loop some kind of SW: elevators, medical devices, etc. Have you ever thought about that?
I can belive if you want to drive a car with a maximum speed ~ 30km/h, than you don't need any electronic inside. But what about 200km/h?
Yes, we have been using antilock brakes for decades, everybody appreciate it, including for its reliability.
But, this is software controlled, each electrovalve can suppress brake pressure on each wheel upon software request.
So, we can do it well with embedded computers.
But if a pedal is at full stroke, software does not know if it is due to a mechanical lock (Toyota gas pedal ?) or due to normal driver intention.
Yes, we could implement consistency checks (pedal stuck at same position for too long, brake pedal pressed while gas pedal fully pressed, etc.).
But I agree that more software is too much software, and may cause more troubles.
So, let's make good and simple job for mechanics, good and simple job for electronics, and keep the brake torque more powerful than traction torque in order to let the driver stop the car even at full gas.
@devassocx: Re the mid-1960's Lincoln - really? On what basis can you claim that the SW implementation is "far more reliable"? If you're talking about quality of components I don't think you can compare 1960's era solenoids and switches to today's models. I would bet that the same implementation using modern components will be at least as reliable (and quite possibly more) than the SW implementation. The only reason SW would be more reliable is due to the simplicity of the window system.
Overall, I tend to agree with this article with respect to drive-by-wire (but I do love the entertainment and GPS systems in my car).
Having worked in Industrial Automation for a few years, I can tell you that we had plenty of mechanical and electro-mechanical safeguards built-in for the unlikely (but not impossible) event of software failure. These were automated systems such as luggage handling, and warehousing conveyor systems transporting boxes weighing 100's of lbs at multiple feet per second. These were not safetly-critical systems or manned vehicles, and yet because of the forces involved, wherever human met machine we had safety cages and Emergency stops (buttons that immediately disconnected all power to system) in case of failure to help prevent severe injury.
These safety systems were rarely used, but the important point is that there WERE times that they were used and customers deemed them a critical requirement for an installation.
We should not forget that the reason we have fly-by-wire in fighter jets and spacecraft is because it is _necessary_ not just convenient (in fighter jets it's humanly impossible to control flight surfaces with required precision). Also, those systems have very long and rigorous design and test cycles to help ensure reliability and even then, the systems are designed with multiple redundant control computers and fail-safe systems.
I'm fairly certain the auto industry doesn't have a comparable design process and until they do we should not place a computer in control of the critical control systems on an automobile.
I think entertainment, and possibly climate control, is fair game but leave a mechanical fail-safe in place for steering, brakes and throttle.
These days increasing impact of the computers is very prominent in every field, and this is changing the conventional engineering practices that are followed in that domain(medical, data communication),Automotive is not an exception. One way of looking at it is improve or groom the design with the help of this new concepts or technologies.
Errors has persisted all through the history of design from the very begining, rather they are very milestones for the best possible designs. Rare failures due to adoption of the technologies are inevitable. Better design methods and approaches in embedded doamin may stabilize the products and increse the "comfort to the user". This is the need which was existing and will continue to be so in future.
By the way, even mid-1960s Lincoln convertibles
had the 'window down before door open' feature.
It was implemented with mechanical switches and relays and I can assure you that your Mustang's software implementation is far more reliable.
Concerning software, I think that many rich and convenient features can be provided at low cost via this approach. Reliability
is obtained via testing. Shortcuts taken
there will surely compromise the customer's
Of course, language and development environments are important to keep costs low
and to quickly respond to system upgrades.
Computer control of critical systems as throttle, brake, steering in automobile industry need to be assured with robust safety systems on fault (tolerance, recovery, prevention) including redundancy similar to aviation/space standards. For such a new car price tag would have to be acceptable for the consumers.
I have to agree with Dean on this one. Computer control in vehicles has gone too far, even in non safety related functions. My 97 van recently refused to start because of a cold solder joint on the connection to the instrument panel! I don't know what the instrument panel has to do with engine ignition today, but it certainly never had anything to do with it in the past. I recently drove a newer van with radar proximity capability that drops out of cruise and applies the brakes if, in the computers opinion and perception via sensors it thinks you're following too closely. I didn't know what was going on at first, but soon found the drivers seat to be way too crowded. The last thing we need are vehicles resulting from the "Vista syndrome" with unnecessary and unwanted features. If they want to impress me, then show me my flying car.
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.