That part I assume is on purpose, because even a computerized system could have "stop immediately" as the default policy when the emergency lever is pulled. Would be interesting to read the analysis that led to the decision. My guess is that it's because on-train issues are statistically the most likely emergency situation a passenger would signal (heart attacks, fights, etc.), in which case continuing to the next station (typically 30-90 seconds) where emergency staff can meet the train and access it, rather than stopping in the middle of a subway tunnel or elevated rail segment, is the most sensible policy.
http://www.huffingtonpost.com/2013/10/04/cta-blue-line-crash...
The tripcocks, I hope, are still connected directly to the brakes.
For those that like finding out, "What's the formal name for that?"... it's called a kill switch:
https://en.wikipedia.org/wiki/Kill_switch
For further reading, see the related "Dead man's switch":
Also pilots get proper training to handle their vehicles, car drivers not so much.
The point is, most of the options you've listed there really may be computer-mediated in modern cars. (And yes, I've heard that there's a strong correlation between unintended acceleration and older drivers, and that a lot of those cases really are driver error. But I don't think you're making that case here.)
The drivetrain spins the electromechanical motor at all times, adding drag. The drag is not just from the added mass of rotation, but also a dynamic resistance caused by electrical properties of the motor being varied in different ways so that the computer can achieve either regeneration (by temporarily changing modes to allow the motor and circuitry to act as a generator, usually during a coast downhill or to a stop), or additional braking (by electrically braking the motor, using the energy stored in the batteries, to add further resistance to the drive train at the cost of heat generation and range reduction).
If a check engine light that has to do with the electromechanical subgroups of your prius comes on (indicating a fault) those systems are disabled, meaning that the car is more or less non-hybrid during those times. Braking will feel stiff, and the car sluggish, but it is by no means dangerous to drive (unless you consider the new learning curve for the cars' performance profile to be dangerous, which it is.)
Also : Your emergency brake is indeed fully mechanical, but on newer models they may be released electromechanically via a command, i'm unsure. I haven't worked on one since the second generation.
p.s. you forgot a sub group. Your steering rack is also electromechanical. One of the first of its' kind in production. Meaning, if you ever experienced a total blackout, your steering would, too, become much more resistant. This , however, isn't considered to be a safety hazard, because at speed the steering rack does little to assist the driver. the forward momentum takes care of that. The steering assistance is mostly there for parking lot situations.
(source : I was at one time a toyota technician, and my back still remembers the recall on first generation prius battery packs, they weighed 124lbs and were way awkward to remove.)
All of these functions are electronic on the Prius (and indeed on every hybrid car that I know of that's on the roads). The balance between regenerative and regular friction braking in particular requires quite a bit of computer code and calibration to get right.
Vehicle tests confirmed that one particular dead task would result in loss of throttle control, and that the driver might have to fully remove their foot from the brake during an unintended acceleration event before being able to end the unwanted acceleration.
Every one of those approaches you suggested are, in many modern cars, fully software driven. And the article even shows an example of how a bug in the software can only be resolved through the exact opposite of what a rational person would do in a crisis.
I think the only actual mechanical failsafe left is the handbrake. Please tell me that's still sacred...
source: I have tested this at ~30-40 mph and nothing about that experience leads me to believe that it would be safer if I had been going faster, and at full throttle.
So you're probably right, it's a stretch to call the handbrake something useful in emergencies when in reality it probably wouldn't perform that function.
I don't drive cars, so i have no idea if that would conflict with normal uses of the handbrake. Perhaps it could have a position beyond the normal brake-engaging position that did this? So that if someone panics and yanks on it as hard as they can, they get the result they probably want.
Yuck!
>Luckily most the features you listed are usually implemented in separate ECUs.
What concerns me would be how the systems handle unexpected inputs.
In the article it notes that the only way to end one unexpected acceleration event was to stop using the brakes. I'm not sure if the vehicle in question has separate controllers, but if it doesn't that's a real concern that unexpected input from one tickles a bug in another.
Fair enough, but as far as I know not a valid point in this specific case.
>>Braking is a software function
Yes, but a completely separated system. The odds of both software systems failing simultaneously is getting in the hash collisions domain...
>>most Americans drive automatic (software) transmissions.
Again a seperate system, and you still have a neutral position.
Are you sure? It seems sensible to me that accelerator inputs would factor heavily into the braking system, so it seems very sensible to me that an unexpected condition in one could translate over to the other - as the article noted the only way to undo one unexpected acceleration condition was to completely remove your foot from the brake pedal. Sounds like cross-over to me...
>you still have a neutral position.
... which is likely just a software input to the transmission computer.
In all likelihood the only non-electronic failsafe is the handbrake, which I still think is a direct mechanical connection in almost all cars.
Not on my Nissan Leaf. The brake lever is a switch that turns what I assume (based on the noise) is a small motor to engage the rear brakes. As far as I can tell, everything is electronically controlled. Brakes, accelerator, "ignition", "transmission" (both in quotes because the Leaf really has neither), parking brake. If there's a firmware failure, there's not a mechanically-operated fail safe to save me.
It isn't, really, in a lot of newer cars. You have a brake override system [1] that can reduce the power output of the engine by various means.
[1]: http://auto.howstuffworks.com/car-driving-safety/safety-regu...
The gearshift in the Prius is totally electronic, and it does not allow you to switch into neutral if you're traveling above a certain speed.
I don't think this is correct (at least for 1997 - 2009 models). Could you offer a citation?
Edit: this made me curious, so I did some cursory research and found this:
http://answers.yahoo.com/question/index?qid=20100204083409AA...
According to one commenter, to shift into neutral when driving you can do one of the following:
1. Press the park button
2. Shift into reverse
3. Hold the shifter in the neutral position for 3 seconds
A video posted by a different commenter shows the driver holding the shifter in the neutral position for not quite 3 seconds, but still longer than is required to shift the car into other gears (and if my memory is serving me right, longer than is required to shift into neutral when stopped).
In any case, the most obvious way to shift the car into neutral did not work for us, and it's unlikely a panicked driver would think to try any of the methods listed above.
Aircraft investigation is really good at overcoming hindsight bias and looking at human factors in a more objective way. What seems absolutely logical for you to type, having read about these incidents before, might not be as obvious to a driver who hasn't read about unwanted acceleration but is suddenly experiencing it.
Of course, if the computer is busted, I'm assuming the long button press will be sent to /dev/null.
That is what sucks about cars with power steering, they don't get any of the benefit a car built with no power steering does.
Getting that boat of a minivan around the next corner in traffic was both entertaining, dangerous, and probably the best upper-body workout I got that year.
http://answers.yahoo.com/question/index?qid=20091121085512AA...
http://www.cliosport.net/forum/showthread.php?623742-06-Clio...!
Yes, better driver training could have made some of these faults less serious. Either by fully braking properly, switching into neutral, or other techniques. That doesn't excuse the faults though.
Software that ensures safety like this really ought to be mandated to be open-source.
I would suggest they should not be called "engineers" then. And in many countries, they're not. Part of the problem is that the tech community includes a lot of different people. Some are programmers, some are program managers, some went to engineering school, some are licensed engineers (in some other discipline). In the US, these are all commonly called engineers. Sadly, I think a lot of web programmers just don't know the true scope of the software industry and its practices.
If you want to design/build a bridge, you need a state license and insurance. The software industry isn't regulated like that. Anyone can design the software that controls a car. That's probably OK since web apps are non-critical systems. But I can't help but wonder if net security wouldn't be better if more programmers had better training in recognizing and improving the total impact of a system.
It is only the reputation of the company and potential damages in a lawsuit such as this one that put pressure on the car manufacturer and web-app startup to test their code in depth. Actually, I do wonder how much the US auto safety regulations are involved with firmware--or do they just test the macro behavior of the car?
Failsafe design flaws are not uncovered by testing code.
Failsafe systems are designed not by "the code works therefore it is safe", but by "assume the code FAILS". Regardless of how much testing is done, you still ASSUME IT FAILS AND ACTS PERVERSELY. Then what?
(Note that acting perversely is hardly farfetched in these days of ubiquitous hacking.)
I've really been enjoying the posts you shared relating to your time in aerospace. I think there are a lot of lessons the entire software industry should learn from...
The computer control systems were dual, meaning two independent computer boards. The boards were designed independently, had different CPU architectures on board, were programmed in different languages, were developed by different teams, the algorithms used were different, and a third group would check that there was no inadvertent similarity.
An electronic comparator compared the results of the boards, and if they differed, automatically locked out both and alerted the pilot. And oh yea, there were dual comparators, and either one could lock them out.
This was pretty much standard practice at the time.
Note the complete lack of "we can write software that won't fail!" nonsense. This attitude permeates everything in airframe design, which is why air travel is so incredibly safe despite its inherent danger.
Thank you very much for taking the time to share and answer my question!
The sample tests I looked at had none. The GRE exams I took had none. The engineering courses I took never mentioned it. I don't recall ever seeing an engineering textbook discussing it. I've never seen it brought up in engineering forums or discussions about engineering disasters.
And, I see little evidence of awareness of it outside of aerospace - Toyota, Fukushima, and Deep Water Horizon being standout examples of such lack. You can throw in New Orleans where hospitals (and everyone else but one building) put their emergency generators in the basement. And in a NYC phone company substation was entirely destroyed because a vital oil pump was in the basement that got flooded during Sandy.
I think the guiding principle of engineering regulation would lead one to believe that software controls for a car should be covered by licensing, but that this has not occurred in practice due to the regulations not keeping up with technological change.
Wat?
"Safe Systems from Unreliable Parts"
http://www.drdobbs.com/architecture-and-design/safe-systems-...
"Designing Safe Software Systems"
http://www.drdobbs.com/architecture-and-design/designing-saf...
I don't know the failsafe design of the 787, but I have faith that Boeing, the FAA, and the aerospace engineers know what they're doing with failsafe design.
But you're right in that if I was actually working on the 787, I would have no such faith, and would verify the designs I was responsible for.
In 1989, a DC-10 operating United flight 232 suffered an uncontained engine failure which damaged the tail and disabled flight controls, resulting in 111 deaths (and could have been more, but in a freak of chance, a DC-10 flight instructor was on board and was able to assist the crew in landing, which may have made the difference for the other 185 people on board). In 2010, an Airbus A380 operating Qantas flight 32 suffered an uncontained engine failure which damaged a wing, disabled a hydraulic system and braking systems, and disabled some flight controls while starting a fire. It resulted in... zero deaths.
In the early 1990s, Boeing 737-200 and 737-300 aircraft had a variety of uncommanded rudder movement issues, resulting in at least 157 deaths. In 2012-2013, the 787's battery fires resulted in... zero deaths.
In other words, the main difference between "then" and "now" is exactly the opposite of the usual arguments against modern aircraft development: more recent aircraft, when they have serious issues, result in fewer injuries and deaths than older aircraft when they experienced serious issues.
This track record of improvement gives justifiable faith that modern aircraft development is safer.
There was an in-flight fire, on an ANA 787. It made an emergency landing and the plane was evacuated. No lives were lost, and the airframe was not lost.
Yes, it's unnerving.
If you have computer-assisted hill starts, collision avoidance, or computer assisted braking [through ABS, certain traction & stability control systems, etc] your computer has control of your brakes.
If you have range-assisted cruise control, or early collision alert, your computer likely has total control over your throttle.
If you have parking assist, lane departure warning, lane following assist, or electric power steering etc: your computer has control over your steering.
If your car has a DCT: your computer has control over your shifting _as well as both clutches._ -- Meaning you have _no mechanical interface_ to disengage the motor from the transmission. This is similar to your Prius example: the shifter is not mechanical.
On many new cars: there's no ignition key to remove. You likely have a smart "keyfob" that simply needs to be within X-feet of the car, and then you have a push button ignition.
I'm sure there's some override for the button [push and hold for three seconds], but it's still going to go through some electronics to figure that out.
---
The only bit that scares me is that all these systems potentially share the CAN bus with the horrendous "Infotainment" systems that every manufacturer loves to install. shudders
I have to admit though I'm surprised that some of those accessories even require a bus as they're typically operated by simple switches.
I guess door locks, wipers, etc. make some sense: with the prevalence of central locking, as well as wipers that sense rain and things like that.
Windows are a bit odd, as they just need a very simple switch. I suppose having all the accessories on a common bus must simplify the wiring harness though.
---
I'm curious how TESLA integrates their in-dash system with the rest of the car.
I thought their in-dash console could control some rather safety-critical "preferences" of the car ... for instance I thought you could adjust the level of regenerative braking.
(Other manufacturers are also offering "sport modes", etc -- though they're not always controllable through the dash.)
They certainly don't require a bus in principle. However, if you want to understand both the business case and some very good engineering reasoning behind the use of data buses to control simple automobile accessories you should have a look at the wiring harness for an early 90's Mercedes or similar luxury car. Demand for fancy features drove the number of wires running to and fro to an unmanageable level. Having a mile of wires in a car is expensive for many reasons I'm sure you can imagine, as well as each connection point becoming an opportunity for something to go wrong.
I'm also curious how electric cars in general will manage safety systems going forward, especially in light of this Toyota court decision.
Once the clutch plates are no longer in contact the engine can do whatever it wants but none of that makes it to the wheels. And then you can get the car out of gear to coast, turn the whole car off and then back on.
There's no substitute to having a human being in the loop to execute high-level "executive" functions, especially when things aren't done to the very high standards of aerospace. You know, like cars.
There exist "manual transmission" that lack an operator controlled clutch. DCTs are very much manual transmissions, but many of them rely on a TCM to disengage the clutches.
There are all sorts of advanced DSG / dual-clutched transmissions in many newer cars, but even some older cars like the MR2 and Smart cars have a http://en.wikipedia.org/wiki/Electrohydraulic_manual_transmi... : quite literally a manual transmission where the clutch has been actuated electronically.
The explanation always seemed obvious to me: Non-technical driver experiences UA. In a panic shifts into neutral. Hears engine scream. Thinks, "The car is still going!" and doesn't realize that despite the sound, the car is actually slowing down.
I know this to be a common misconception in my experience. People commonly misinterpret high revs with "going fast".
But I had not considered that this correlation is only intuitive to me because I own a car with a manual transmission.
https://news.ycombinator.com/item?id=6615457
engineers are often not aware of basic principles of fail safe design. I mentioned Toyota, and this article confirms it.
Not mentioned in this article is the most basic fail safety method of all - a mechanical override that can be activated by the driver. This is as simple as a button that physically removes power from the ignition system so that the engine cannot continue running.
I don't mean a button that sends a command to the computer to shut down. I mean it physically disconnects power to the ignition. Just like the big red STOP button you'll find on every table saw, drill press, etc.
Back when I worked on critical flight systems for Boeing, the pilot had the option of, via flipping circuit breakers, physically removing power from computers that had been possessed by skynet and were operating perversely.
This is well known in airframe design. As previously, I've recommended that people who write safety critical software, where people will die if it malfunctions, might spend a few dollars to hire an aerospace engineer to review their design and coach their engineers on how to do fail safe systems properly.