Even as a competent Design Engineer, I strongly advise there is no better safeguard against accidents than an experienced, skilled operator. It's just sad that people (in general) expect everyone else to protect them, and take no personal responsibility in the fact that they perhaps don't belong behind the wheel of a car.
This mentality has forced all automakers to include countless so-called 'safety' features, in effort to appease the unqualified demands of the public.
If you think about it, if we lived in a world where this was not so important, there would exist a natural-selection process which would help keep roads safer, merely by thinning the herd.
(I'm just sayin',,,please don't bombard me with insensitivity comments !!)
Yes, an engineer would have to be a prophet to consider all possibilities, bobjengr, and therein lies the problem. A class action suit resulting for one of those unforeseen problems can practically crush a company. It almost did in Audi's case, and we still don't know for sure what the cause was there.
What is alarming is how complex software is getting - and I think unnecessarily. It hasn't helped reliability. As an example, I rent dozens of vehicles a year, and in spite of the fact that none had more more than a few thousand miles on them I've had two rentals where the throttle and transmission simply stopped working when I was backing up - one in the desert, the other in the snow. Both times required shutting off the ignition to get them working again. In a combined 700,000 miles/65 years on my old personal vehicles under worse environmental conditions than I've subjected any rental to I've never once had an issue with the transmission (OK - except for leaking seals, and frozen solid due to -45F). I've also had two rentals suddenly go to full throttle for no reason (when cruise control was engaged) - fortunately both were on interstates with no traffic around me. Not hazardous, but definitely irritating.
And mind you, what will happen when these complex systems are subjected not to unusual environments - including EMI, but to deliberate malicious attack - say a bunch of teens who get their jollies out of watching drivers reactions when they cause a vehicle to accelerate just before a red light?
Building the safety case for software controlled weapon system; we are required to prove that the probability of a hazardous incident is less than 1 in a million. The only way to do this is by analysis, supplemented with tests. The system has to be partitioned and designed from the beginning to support the safety case. In the end it does not matter what fault or rather what faults in combination lead to a catastrophic event so all possibilities must be accounted for over the life of the system.
Excellent post Charles. One factor that contributes to the unknown is the condition of the car AFTER maintenance has been performed. I think we all have had problems resulting from maintenance that might have fixed one problem but created another. Then it becomes "he said--she said". Is the fault basic engineering or issues AFTER customary work accomplished during the life of the vehicle. I really don't know how engineers can prepare for outcomes such as this. I have been part of FMEA (failure mode effect analysis) exercises and sometimes the possible number failure modes are truly astounding. Add to that customer interaction and maintenance and you have to be a prophet to understand all of the possibilities.
You're right, critic, there will be failures. Watching my car struggle through the recent deep freeze, with mechanical parts locked up by sub-zero temperatures and snow, I wondered how good those autonomous vehicles will be when they face bad weather and aging parts. Will they know the headlights are blocked by ice and snow? Will the camera-based sensors be able to see under those conditions? And, if not, will they know they can't see? Vehicle intelligence will be built up by years of experience and, yes, failures.
Bob, I wonder if some of these cars would allow shifting into neutral. If the shifting is controlled by the same computer that has failed and locked the throttle open, then possibly not. And I know that at least a few transmissions are entirely controlled by electronics, although I think that they may have a mechanical link for the "park" locking function. And using the brakes can get interesting when the engine won't slow down. Quite a few years ago I drove a lab car about 50 miles after the idle speed cam control system froze, and the "idle" would run about 78MPH. The day was bitter cold and it was befor cell phones, and so the chice was sit and freeze or dive and heat up the brakes. They were quite hot by the time I got back. And even with good power brakes, slowing a vehicle with the engine running hard is not easy.
Most modern fuel-injected engines have an overspeed shut-down that either interrupts the spark, fuel or both to prevent an engine from overspeed destruction; it may sopund scary, but it does work. Selecting neutral and standing on the brakes shoudl always work. Like Asimov's 3 laws of robotics, a heirarchy of operation needs to be established that only allows safe operation and different failures would invoke different levels of over-ride up to stopping immediately. There will never a fail-safe autonimous vehicle until the definition of "fail-safe" has been established and agreed upon by all developers. Once those utterly defensible parameters have been incorporated, autonomy may be added. The rub is there will never, ever exist a definition of "Fail Safe" that can't be successfully challenged by lawyers. The technology may be perfect, but the written word will always be open to interpretation. "Thou shalt not kill." Seems to exemplify a simple, clear sentence, yet somehow we manage to re-interpret the meaning on occasion.
GTO, the understanding of how to shut down a runaway engine is indeed a potentially lifesaving thing. And having a runaway engine overspeed destruct upon shifting to neutral may be the lesser of the evils, but it is a very expensive one, since overspeed induced failures are seldom minor.
I have had stuck throttles a few times and switching off the ignition has always been the first step to recovery. The HUGE problem, which I have pointed out before in other discussions, is the cars that no longer have a way to switch off the engine. Instead, they have a big button that sends a shut-off request to the controls computer, and does not include a way to force the shutdown.
There is no rational reason for allowing such cars on public roadways.
A simple on/off switch that would disable the ignition system entirely independant of the control computers would solve the problem. It would also be able to provide an additional child-proofing safety function, which is how it could be marketed.
For all of my career in designing industrial control systems, there has been a requirement for a "Emergency Stop" function that must be independant of all control software and logic. That requirement is right next to the specification of the machines functions, and for very good reasons. Just like any other computer type of system, if a failure has caused an unwanted type of operation it can not be expected that the failed control system will respond to any command as required. So that is why the big red button provides the non-maskable hardware shutdown. Because if part of a system has failed other parts may also have
The paperwork that surfaced during the Pinto fire lawsuits showed that Ford made a conscious decision to balance the cost of production against the cost of liabilities. Nothing specific to the Pinto model ever came to light, but documentation exposed a culture that balanced the monetary cost of liabilities against the cost of producing the vehicle.
I guess safety didn't sell back in the Seventies, but hey, now there's a mandate for every contingency.
Festo's BionicKangaroo combines pneumatic and electrical drive technology, plus very precise controls and condition monitoring. Like a real kangaroo, the BionicKangaroo robot harvests the kinetic energy of each takeoff and immediately uses it to power the next jump.
Design News and Digi-Key presents: Creating & Testing Your First RTOS Application Using MQX, a crash course that will look at defining a project, selecting a target processor, blocking code, defining tasks, completing code, and debugging.
Focus on Fundamentals consists of 45-minute on-line classes that cover a host of technologies. You learn without leaving the comfort of your desk. All classes are taught by subject-matter experts and all are archived. So if you can't attend live, attend at your convenience.