Curiously the chief engineer I knew at a major car service center, also felt the same way.
And that's not even touching on the insanity of building computerized vehicle systems with always-on GSM data links to the Net. Ask Michael Hastings how that worked out for him.
Also I agree that critical systems software should be legally required to be open source.
I'd hazard a guess that in a serious crash you're going to have a far better chance of survival in a modern car (crumple zones, airbags/side-cushions/curtains, ABS etc) vs a ~1980's or older car, and that the cause of said crash would be human error rather than a bug in the engine throttle code.
What I don't understand is how you can rationalize your preferences by thinking these old cars are safer because they don't have any software-defined points of failure. The chances of dying in a car accident because of driver error (by yourself, or by someone else) or mechanical failure (because of worn-out parts) are infinitely higher than by some kind of electronic failure. And if you end up in crash, your chance of survival will be much higher in a modern car, because of all the safety measures that have been added over the years. So IMO it doesn't make sense to stick with the things you've mentioned if safety is your primary concern.
On top of that: pilots of any caliber undergo far more rigorous training than what is required of a licensed driver in the US. They routinely have to train for the autopilot systems they use, etc. -- I trust a pilot to react appropriately when the fly-by-wire system goes haywire moreso than the average driver.
The automotive industry has quite a ways to go before I'll consider their safety critical engineering to be anywhere near the level of robustness present on even the oldest commercial airliners in service.
It's really hard to find cars with curtain airbags though without electronic accelerator and fake steering.
Because the way I see it power steering itself is just as mechanical as hydraulic brakes; and electronic steering is a far more recent development than throttle-by-wire.
If you're willing to accept power steering it's not too hard to find vehicles w/ side curtain airbags. Lots of '01 Toyotas had side curtain airbags, and it wasn't until '02 that they started putting drive-by-wire in the Lexus lineup (much later for the rest of their lineup, I believe it was phased in over '03-'05 for Toyotas.)
I adore my '01 Camry. The 5S-FE is a bit sluggish compared to modern powertrains, but its bulletproof, insanely easy to work on, and drives quite smoothly. It'll be a cold day in hell when I have to replace that car with a glorified playstation controller.
It'll come at a point when those cars will be unmaintainable, hard to aquire, expensive. I want to see if you'll still have the sae stance then. What if in 30 years it becomes illegal to drive your own car and can only use SDC's, will you still pine over the good old mechanica components then?
Thing is, if attackers that advanced are out to get you, you're pretty much screwed regardless.
Had Hastings been driving a classic car, I'm sure he would have suffered a tragic drug overdose or something instead.
Besides, even if your car isn't computerized, there's plenty of others on the road with you that are.
Servo power steering is acceptable, though my present car (1993 Subaru stationwaggon) has direct steering, and I prefer that.
The ECU however, was probably made ~10 years ago by a team of highly incompetent software developers trained as electronics engineers, with no access to any previous attempts by other companies and progressively getting worse over time (instead of being perfected). To make the ECU do something it wasn't made to do all it needs is a mere low voltage event just enough to flip a crucial bit, and many bits are crucial.
Not that I don't agree that it's silly to not drive cars with an ECU, but just saying that his point has merit.
In the olden times, the throttle was controlled by a mechanical device and tensioned springs. The failure characteristics were studied for 150+ years, and the state of the mechanical components could be assessed by visual or physical inspection. The failure scenarios for open throttle are also non-obvious things to workaround. What do you do? Pump the brake? Take the car out of gear? Depress the accelerator to reset? Turn the key? It's a complex decision matrix with life-and-death consequences, and the correct answer will vary by car configuration and vendor.
The ridiculous positions taken by posters here are indicative of how engineering fail like this happens.
Analog toaster and refrigerator technology has been working quite well for us for almost a century.
http://www.theatlantic.com/business/archive/2010/03/how-real...
Ultimately, Toyota was heavily penalized for fielding safety-critical software that it could not show was acceptably safe, which is a reasonable and desirable outcome, IMHO.
1) None of these cars are 700hp Supras that accelerate at drastic speeds. These were normal consumer cars that frankly aren't that fast even with the throttle fully depressed.
2) The brakes in all of these vehicles are many times more powerful than the engine. Pressing the brakes would have stopped the vehicles, even if the engine were attempting to accelerate full throttle.
In most cases I would never side with the corporation over average people. But this is one of those rare cases where lawyers were able to hire dishonest "experts" and snow over the judge and jury and get an unjust verdict.
I had a water bottle fall onto my right leg while turning, this caused a sudden but short lived acceleration (e.g. 10 MpH of unexpected acceleration for less than 1 second), this was enough to cause me to mount the curb, and do some decent property/car damage (thank god nobody was on the curb). The brakes worked perfectly, and stopped the car, but it does show how much damage even a tiny burst of unexpected acceleration can do (the entire incident was under 5-10 seconds).
It honestly boggles my mind that someone can dismiss any length of unexpected acceleration because "cars [aren't] 700 hp Supras." Consumer cars are plenty powerful enough to cause injury and death due to any length (even 1 second) of unexpected acceleration at the wrong moment. Sure, if you're going straight on the freeway then you aren't going to even notice, but in a car park, while turning, or stopped at a school crossing, the brake's ability to overcome the engine are largely irrelevant since you won't be expecting it.
The brakes in 2004 and newer models are controlled by the computer. It controls the hydraulic pressure to the brakes to maximize the amount of work the regenerative braking system can do. It uses a pump and accumulator to store hydraulic pressure, and solenoids to send it to the brakes as well as provide pedal feedback. The only time you directly control the brakes is if the main system loses all accumulated pressure. Until then, you're just sending pedal input to the computer and it does what it wants.
Some cars have a sensor to detect if you are overlapping the throttle and brakes and will cut the throttle if the brake pedal is detected as being pressed. This can frustrate people who attempt to match revs on downshifts in manual transmission cars.
No doubt there are accelerator-brake confusions in many of these cases, especially with older drivers. I'm really hesitant to say they all are in that category. Investigators need more "black box" info to see, for example, whether the accelerator and/or brake were being pressed in the seconds before an accident.
Edit: I mean, -if it was this obvious we should have known it by now?
My recollection is: It was widely reported at the time.
Instead, what gets examined are the artifacts like requirements documents, the results of tests, specifications and such. This allows poor code quality to be hidden, and, to some extent, encourages sloppy development practices (especially when time is critical). Exposing the code to more people will have several effects, but the main two (from my perspective) are:
* Developers won't release as much bad code, either due to pride or insistence from their management.
* Bugs may be more easily discovered and diagnosed if the code is available. As it is now, it's a black box. So if I find an issue I may be able to repeat it, but I can't examine the code to see why it's actually happening or to correct it.
If OpenSSL was closed-source my servers would probably still be vulnerable today.
It looks like at least having the source available made it easier for the good guys to discover the bug.
It IMHO shows a failure of the type approval process, maybe it didn't evolve enough with regard to the amount of software used in safety critical components. Inspiration from aircraft certification would likely be mùore than welcome in that regard...
Because it's open and findable. I think that was the point.
I do also know a self taught free lancer who makes an absolute killing cleaning up problems in various companies. He does really short contracts (like 2-4 weeks) in Tokyo and Osaka. Then he comes back to Shizuoka and hangs out for a couple of weeks. So there is money to be made ;-)
Granted, even here in the USA programming used to be considered "women's work", mostly revolving around planning and organization. So they passed it off to secretaries. I just didn't think that was something that was still happening.
http://www.smithsonianmag.com/smart-news/computer-programmin...
Ask anyone who has lived in Japan for a sufficient period of time and they will laugh at this statement, especially as it relates to programming.
https://www.youtube.com/watch?v=ouQFu1FDllw
To me it was an eye opener to learn about the different attitudes of tech professionals in countries such as South Korea and particularly Japan.
I highly recommend watching it some time.
Not that many people are getting killed, so it's an acceptable tradeoff?
i.e. brakes on cars are not designed the stop the engine but to absorb the vehicle's momentum.
This will have the effect of reducing the power assist, which is already reduced due to high revs / low vacuum.
If your car starts accelerating in an unintended fashion, you should push the brakes to the floor and keep them there, then if you have time shift into neutral and turn off the ignition (this shouldn't be necessary, but will help).
Many drivers won't actually do this in the heat of the moment, though, thus many deadly crashes.
I think part of the problem is that software development isn't considered an engineering discipline and code of engineering ethics goes out the window.
While you're at it, read the FDA list of food and medical recalls too, so much risk!
People are still buying and driving Toyotas.
When the VW emissions thing started making its way through the news cycle, I read comments postulating that this might be the end of VW. Hah - people are going to forget about VW just like they forget about everything else.
It wasn't the end of Toyota, and it won't be the end of VW; but it was the end of Toyota's goal to be the Biggest Car Company in the World[1][2], and it may be the end of VW's goal to be the Biggest Car Company in the the World.
Being #1 volume vehicle manufacturer is a curse!
1. https://hbr.org/2007/07/lessons-from-toyotas-long-drive - Interestingly, in this article Mr Watanabe claims that Toyota never had the goal to be the biggest car company.
2. http://www.economist.com/node/15576506 - James Womack, one of the authors of “The Machine that Changed the World”, a book about Toyota's innovations in manufacturing, dates the origin of its present woes to 2002, when it set itself the goal of raising its global market share from 11% to 15%. Mr Womack says that the 15% target was “totally irrelevant to any customer” and was “just driven by ego”. According to Mr Womack, the requirement to expand its supply chain rapidly “meant working with a lot of unfamiliar suppliers who didn't have a deep understanding of Toyota culture.”
Disclosure - I work for GM, these opinions are my own, etc.
One company, the guy in charge of software was a CE, who would have been fine as long as the hardware was at the level of sophistication as what he was taught at school (He knew 8051 microcontrollers really well). He was really good at giant switch-case statements. Function pointers were a little newfangled and suspect.
Basically, he knew enough software engineering to get the hardware working.
That's one big problem that needs to be addressed -- there aren't a lot of people being trained in the software side of embedded systems. You have CS grads who for the most part aren't given much training on the low end of the abstraction spectrum, and the opposite for CE people, so there tends to be a very fuzzy area in the middle that causes arguments between the two camps.
The other company I worked for literally had crazy coding standards that basically dictated 20,000 line functions and a bizarre sort of anti-DRY mindset that I will never understand. You were encouraged to c-c c-v a block of code, change one line, move on!
Thanks for posting.
It's like the worst internal shit code you see in the in house tools at many companies where the moment it ran it was considered done enough.
Oh my.
