 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
Car Forum / Driving, Maintenance, Tuning / Driving / May 2005So You Think You Want Computer Controlled Steering
Item: Software glitches cause Toyota Prius to stall at highway speeds: http://money.cnn.com/2005/05/16/Autos/prius_computer/index.htm?cnn=yes Now think about a computer programming error that causes the steering to do a hard left at highway speeds. Dave Head > Now think about a computer programming error that causes the steering to do a > hard left at highway speeds. > > Dave Head Microsoft? Gives a whole new meaning to 'software crash'. Now, that was totally unfair to Microsoft, lots other software crashes, they just lead the field in that area. > > Now think about a computer programming error that causes the steering to > do a [quoted text clipped - 5 lines] > totally unfair to Microsoft, lots other software crashes, they just lead the > field in that area. I miss my 1983 Ford all of a sudden. Dave >> Now think about a computer programming error that causes the steering to >do a [quoted text clipped - 5 lines] >totally unfair to Microsoft, lots other software crashes, they just lead the >field in that area. Well, its probably because they _do_ more software than any other company. Sit back and never write a lick of code, and your code isn't going to crash. You'd want a team like the one that writes software for the space shuttle to write software for a computer controlled steering function, and you'd want triple redundant hardware to ensure reliability. And you'd want mandatory servicing of the mechanism only by people qualified to ensure that they knew all the failure modes and how to avoid them. I think its too steep a set of requirements just to do the same job done by mechanical means cheaply and reliably. Mechanical steering is extremely reliable. It'd be really expensive to match that reliability with a computer system. Dave Head > You'd want a team like the one that writes software for the space shuttle to > write software for a computer controlled steering function, and you'd want > triple redundant hardware to ensure reliability. And you'd want mandatory > servicing of the mechanism only by people qualified to ensure that they knew > all the failure modes and how to avoid them. And the same people that demand all of that will demand it doesn't add a cent to the cost of the car. > Well, its probably because they _do_ more software than any other company. Sit > back and never write a lick of code, and your code isn't going to crash. Yes, they "do" more software than anybody, sadly quality control and security they don't do. They have managed to create multi-billion dollar industries in companies trying to cover their defects, though >> Well, its probably because they _do_ more software than any other company. Sit >> back and never write a lick of code, and your code isn't going to crash. > >Yes, they "do" more software than anybody, sadly quality control and >security they don't do. They have managed to create multi-billion dollar >industries in companies trying to cover their defects, though Yeah, because sun has no bugs in their java sh.t. And linux has no issues either. When are you going to send me the check for the bridge I sold you? > Yeah, because sun has no bugs in their java sh.t. And linux has no > issues either. When are you going to send me the check for the bridge > I sold you? I never made any such claims. But overall, Sun's Java and the independant Linux have proven to be far more robust and secure than Microsoft's products. I won't even bother to mention FreeBSD. > I never made any such claims. But overall, Sun's Java and the > independant Linux have proven to be far more robust and secure than > Microsoft's products. That's because people really haven't been trying to hack into those systems. I don't see why the Linux kernel just got around to implementing a "trial" version of ACPI management (in the 2.6.x branch) when Windows has had a working version of it for the last 6 to 7 years. >> I never made any such claims. But overall, Sun's Java and the >> independant Linux have proven to be far more robust and secure >> than Microsoft's products. >That's because people really haven't been trying to hack into those >systems. FUD. It would be far easier to hack into those systems because they are open-source if they *were* as vulnerable. All the potential bugs are immediately visible. M$ OTOH onscures its source code so it takes a lot of hit and miss to determine if a vulnerability exists. >I don't see why the Linux kernel just got around to implementing a >"trial" version of ACPI management (in the 2.6.x branch) when >Windows has had a working version of it for the last 6 to 7 years. More FUD. I've been using ACPI in a 2.4 kernel for well over 2 years. The "trial" 2.6 has been working for a year. The Windows "working" version can't handle standby/hibernate in my new laptop after a "service" pack upgrade. Linux's works; with some limitations because the display drivers that are proprietary (binary-only) do not like it. As for computer-controlled steering; as long as Micro$oft Quality remains acceptable in software, I won't have a bar of it. Vendors have not inspired a great deal of confidence in their implementations of stability controls, etc. It doesn't *matter* that they work most of the time. The have to work ALL OF THE TIME. It's not an executive desk toy.  Signature/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | I'm a .signature virus! X against HTML mail | Copy me into your ~/.signature / \ and postings | to help me spread! > It would be far easier to hack into those systems because they are > open-source if they *were* as vulnerable. All the potential bugs are > immediately visible. And they'll remain unless one tries to exploit them. While a lot of people work on the code, no one person knows all of it. >>I don't see why the Linux kernel just got around to implementing a >>"trial" version of ACPI management (in the 2.6.x branch) when >>Windows has had a working version of it for the last 6 to 7 years. > I've been using ACPI in a 2.4 kernel for well over 2 years. The > "trial" 2.6 has been working for a year. > > The Windows "working" version can't handle standby/hibernate in my > new laptop after a "service" pack upgrade. I've had the opposite experience. I've been unable to get ACPI to work with my laptop under Linux (nor my modem nor wireless adaptor). Everything worked seamlessly with Windows 2000. I was able to get sound to work by recompiling the 2.6 kernel and running LILO though. >> It would be far easier to hack into those systems because they are >> open-source if they *were* as vulnerable. All the potential bugs are >> immediately visible. >And they'll remain unless one tries to exploit them. Erm no. Code reviews occur. Independently. And quite often security patches come out saying that there's a fix for a potential vulnerability; but those who found it have no idea how it might be exploited. >While a lot of >people work on the code, no one person knows all of it. That part is true. However, you don't need to know it all to see typical vulnerabilities. Quite often, it's the "usual misteaks". And because Linux is very modular, vulnerabilities are usually isolated to particular functionality. >>>I don't see why the Linux kernel just got around to implementing a >>>"trial" version of ACPI management (in the 2.6.x branch) when >>>Windows has had a working version of it for the last 6 to 7 years. >> I've been using ACPI in a 2.4 kernel for well over 2 years. The >> "trial" 2.6 has been working for a year. >> The Windows "working" version can't handle standby/hibernate in >> my new laptop after a "service" pack upgrade. >I've had the opposite experience. I've been unable to get ACPI to >work with my laptop under Linux (nor my modem nor wireless >adaptor). ndiswrapper is your friend. >Everything worked seamlessly with Windows 2000. And you've written to the manufacturer of the laptop letting them know that their Linux support sucks? Until people start doing that frequently, manufacturers will simply churn out the same old junk. >I was able to get sound to work by recompiling the 2.6 kernel and >running LILO though. Seems to me like you found a hard way to do it. :-) The only kernel recompile I've had to do recently was for an orphan CPU that's not properly detected. Windows runs on it in 486 mode. But it's closer to a P-III. The thing is; I *could* recompile Linux for the specific processor. Strangely enough, another version of Linux runs fine on the same system, correctly detecting the processor. When I get some time, I'll diff the source trees and find out why. Again, I couldn't do that with Windows. Nor would there be the possibility of finding that one vendor's version of the same nominal kernel actually fixes something that the other's hasn't. Car makers usually try to arrange for second-source on everything. It reduces the chance of production stopping and reduces the liability and damage if one supplier provides faulty parts that don't show for some years. Signature/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | I'm a .signature virus! X against HTML mail | Copy me into your ~/.signature / \ and postings | to help me spread! > Erm no. Code reviews occur. Independently. And quite often security > patches come out saying that there's a fix for a potential > vulnerability; but those who found it have no idea how it might be > exploited. It depends. If enough people are out there probing the potential vulnerabilities of Linux, then they will spot vulnerabilities that the code reviewers may miss. > And because Linux is very modular, vulnerabilities are usually > isolated to particular functionality. I thought Linux was more of a single layer OS of sorts. >>>>I don't see why the Linux kernel just got around to implementing a >>>>"trial" version of ACPI management (in the 2.6.x branch) when >>>>Windows has had a working version of it for the last 6 to 7 years. >>>I've been using ACPI in a 2.4 kernel for well over 2 years. The >>>"trial" 2.6 has been working for a year. Forgot to mention, but the reason I referred to it as a "trial" version was because the kernel configuration options referred to it as an experimental implementation. > ndiswrapper is your friend. Thanks, I'll give that a try and see how it works. > The only kernel recompile I've had to do recently was for an orphan > CPU that's not properly detected. Windows runs on it in 486 mode. > But it's closer to a P-III. Which distribution do you use? My experience mainly lies with Mandrake. The installation, by default, will not properly detect the AC '97 sound system, the WNC wireless adaptor, nor the MDC 56k modem on this laptop. Only one form of network access does work, and that's the 10/100 Ethernet card. The problem is that it's rather difficult for me to find a port to connect to. I can easily find wireless access points, and telephone lines to use, but without the ability to connect to the internet, I can't do much in the way of getting drivers... >As for computer-controlled steering; as long as Micro$oft Quality >remains acceptable in software, I won't have a bar of it. Such embedded systems are a totally different ball game. Microsoft HAS been trying to get into it, with fortunately limited success. SignatureThere's no such thing as a free lunch, but certain accounting practices can result in a fully-depreciated one. >>As for computer-controlled steering; as long as Micro$oft Quality >>remains acceptable in software, I won't have a bar of it. >Such embedded systems are a totally different ball game. Microsoft >HAS been trying to get into it, with fortunately limited success. Like BMW's "iDrive"? More accurately called "Nobody Drives". Embedded systems *should* spawn from Engineering. Unfortunately, many "software engineers" think that they are Engineers. So you get cockups like the ABS/DSC being disable when the driver presses the brake pedal (too hard) and it won't reset until you close all windows and shut down. Signature/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | I'm a .signature virus! X against HTML mail | Copy me into your ~/.signature / \ and postings | to help me spread! >>>As for computer-controlled steering; as long as Micro$oft Quality >>>remains acceptable in software, I won't have a bar of it. [quoted text clipped - 3 lines] > >Like BMW's "iDrive"? More accurately called "Nobody Drives". iDrive is based on Windows CE, right? Yeah. >Embedded systems *should* spawn from Engineering. Unfortunately, >many "software engineers" think that they are Engineers. Some software engineers ARE engineers. Many, unfortunately, are not yet pretend to be. There are many software-dependent life-critical systems out there that work well. >So you get cockups like the ABS/DSC being disable when the driver >presses the brake pedal (too hard) and it won't reset until you >close all windows and shut down. The first part was a deliberate design decision; it was an attempt to fail safe. Reasonable enough, but the threshold was set too low. The way this was reset was a horrendous design decision. Neither has anything to do with the particular problems of software; ask anyone who has had to reset a Ford fuel pump (which is entirely electromechanical). SignatureThere's no such thing as a free lunch, but certain accounting practices can result in a fully-depreciated one. > >So you get cockups like the ABS/DSC being disable when the driver > >presses the brake pedal (too hard) and it won't reset until you > >close all windows and shut down. > > The first part was a deliberate design decision; it was an > attempt to fail safe. Reasonable enough, Sorry, I'm a bit slow today. Why on earth would you want to disable ABS when someone braked too hard ? Isn't that exactly what ABS in passenger cars was designed for? (Avoiding brake lockup when some moron floors the pedal because they don't know how to brake properly). > Neither has anything to do with the particular problems of software; > ask anyone who has had to reset a Ford fuel pump (which is entirely > electromechanical). Can you fill us in on the details? >> >So you get cockups like the ABS/DSC being disable when the driver >> >presses the brake pedal (too hard) and it won't reset until you [quoted text clipped - 8 lines] >some moron floors the pedal because they don't know how to brake >properly). I think the engineers decided that a high reading from that particular sensor likely meant a system malfunction, not someone braking hard. In that case, the safest thing to do would be to disable the ABS system. It appears they were wrong; my point is that this isn't a problem specific to software. >> Neither has anything to do with the particular problems of software; >> ask anyone who has had to reset a Ford fuel pump (which is entirely >> electromechanical). > >Can you fill us in on the details? Ford used to (and may still) have a system where if the car got a hard enough bump, the fuel pump would be shut off (to avoid spewing fuel all over the place in an accident). To reset it, you had to turn it off, get out, and push a button hidden in the trunk. SignatureThere's no such thing as a free lunch, but certain accounting practices can result in a fully-depreciated one. >>> >So you get cockups like the ABS/DSC being disable when the driver >>> >presses the brake pedal (too hard) and it won't reset until you >>> >close all windows and shut down. >>> The first part was a deliberate design decision; it was an >>> attempt to fail safe. Reasonable enough, >>Sorry, I'm a bit slow today. Why on earth would you want to disable >>ABS when someone braked too hard ? Isn't that exactly what ABS >>in passenger cars was designed for? (Avoiding brake lockup when >>some moron floors the pedal because they don't know how to brake >>properly). >I think the engineers decided that a high reading from that particular >sensor likely meant a system malfunction, not someone braking hard. Sorry; that's simply not acceptable as an answer. Either the "engineers" are grossly incompetent or they erred severely in deciding what is a failure by being ignorant of the boundary conditions. Drivers are taught to exert as much pressure as possible, as quickly as possible on ABS-equipped cars for emergency braking. I'm no body-builder but I have managed to peak close to 2 kN pedal force in brake simulators. That should be achievable by an adult male. A person (unless disabled) can exert a force equivalent to more than twice their body weight using their foot; provided that they are seated correctly. The rule-of-thumb for *minimum* brake pedal force for activating ABS used to be 80 kp (just shy of 800N). Yet the ABS/DSC was disabled by forces as low as 70 kp. >In that case, the safest thing to do would be to disable the ABS >system. No. The safest thing is to ignore the "unbelieveable" and to obey the driver command within the physical limits of the system. The system was still otherwise fully functional except for the detected "over-pressure" signal causing the ABS functionality to be disabled. There was no inherent physical limit being exceeded other than (AFAICT) the range of the input pressure sensor. The safest thing to assume under those conditions is that the driver wants maximum braking *with* ABS. >It appears they were wrong; my point is that this isn't a >problem specific to software. This discussion is about the advisability of electronic steering in the real world. The possibility of discontinuous behaviour of software when it fails is known to be potentially catastrophic. The risk of failure outweighs the assumed benefit. Signature/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | I'm a .signature virus! X against HTML mail | Copy me into your ~/.signature / \ and postings | to help me spread! >>>> >So you get cockups like the ABS/DSC being disable when the driver >>>> >presses the brake pedal (too hard) and it won't reset until you [quoted text clipped - 18 lines] >possible, as quickly as possible on ABS-equipped cars for emergency >braking. My point isn't that it wasn't a mistake, but that it's not a mistake particular to software. The _specs_ were wrong. >This discussion is about the advisability of electronic steering in >the real world. > >The possibility of discontinuous behaviour of software when it fails >is known to be potentially catastrophic. The risk of failure >outweighs the assumed benefit. Purely mechanical systems and electromechanical systems can also exhibit "discontinuous behavior" when they fail. SignatureThere's no such thing as a free lunch, but certain accounting practices can result in a fully-depreciated one. >>>>> >So you get cockups like the ABS/DSC being disable when the driver >>>>> >presses the brake pedal (too hard) and it won't reset until you >>>>> >close all windows and shut down. >>>>> The first part was a deliberate design decision; it was an >>>>> attempt to fail safe. Reasonable enough, >>>>Sorry, I'm a bit slow today. Why on earth would you want to disable >>>>ABS when someone braked too hard ? Isn't that exactly what ABS >>>>in passenger cars was designed for? (Avoiding brake lockup when >>>>some moron floors the pedal because they don't know how to brake >>>>properly). >>>I think the engineers decided that a high reading from that >>>particular sensor likely meant a system malfunction, not someone >>>braking hard. >>Sorry; that's simply not acceptable as an answer. Either the >>"engineers" are grossly incompetent or they erred severely in >>deciding what is a failure by being ignorant of the boundary >>conditions. Drivers are taught to exert as much pressure as >>possible, as quickly as possible on ABS-equipped cars for emergency >>braking. >My point isn't that it wasn't a mistake, but that it's not a mistake >particular to software. The _specs_ were wrong. That's not a valid reason. It may be an excuse but not a valid one. Specifications shouldn't come out of thin air. A competent Engineer would have spotted the error in the "specification" at the beginning. And if not then, then when checking boundary conditions. I don't work in that area of the industry yet I know (as would any layman who's tested their skills in a braking simulator at a motor show) that a pedal force equivalent to 70 kg of weight is *easily* exceeded by a trained driver in emergency braking situations. I expect that the force could exceed 2kN. It wouldn't be a sensor fault. The hydraulics should safely cope with resulting pressures and still have a safety factor. >>This discussion is about the advisability of electronic steering in >>the real world. >>The possibility of discontinuous behaviour of software when it >>fails is known to be potentially catastrophic. The risk of failure >>outweighs the assumed benefit. >Purely mechanical systems and electromechanical systems can also >exhibit "discontinuous behavior" when they fail. But they typically do not "reset" themselves and conceal their faults. I gather that you don't subscribe to comp.risks. Signature/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | I'm a .signature virus! X against HTML mail | Copy me into your ~/.signature / \ and postings | to help me spread! >>My point isn't that it wasn't a mistake, but that it's not a mistake >>particular to software. The _specs_ were wrong. > >That's not a valid reason. It may be an excuse but not a valid one. >Specifications shouldn't come out of thin air. Again, I'm not disagreeing that there was a problem. I'm disagreeing that it was in any manner particular to software. There are problems particular to software; this wasn't one of them. >>Purely mechanical systems and electromechanical systems can also >>exhibit "discontinuous behavior" when they fail. > >But they typically do not "reset" themselves and conceal their >faults. I'd say it's common. Some transient condition (overheat or overvoltage, for instance) occurs which causes the failure (doesn't matter if the transient condition should have been handled or not), the failure causes the transient condition to go away, the system works fine when restarted. >I gather that you don't subscribe to comp.risks. No, I'm quite paranoid enough already. SignatureThere's no such thing as a free lunch, but certain accounting practices can result in a fully-depreciated one. >>As for computer-controlled steering; as long as Micro$oft Quality >>remains acceptable in software, I won't have a bar of it. > >Such embedded systems are a totally different ball game. Microsoft HAS >been trying to get into it, with fortunately limited success. If you think Microsoft code is bad, wait until you see the code for the typical embedded system... SignatureLife is short - drive fast! http://www.geocities.com/scottenaztlan/ >> I never made any such claims. But overall, Sun's Java and the >> independant Linux have proven to be far more robust and secure than >> Microsoft's products. > >That's because people really haven't been trying to hack into those >systems. Yeah, right. That's what Microsoft would have you believe, anyway. Everybody just picks on them. >I don't see why the Linux kernel just got around to >implementing a "trial" version of ACPI management (in the 2.6.x branch) >when Windows has had a working version of it for the last 6 to 7 years. And power management has exactly what to do with security? (not that I'd agree that Windows power management works worth a damn) SignatureThere's no such thing as a free lunch, but certain accounting practices can result in a fully-depreciated one. No, I don't think I want computer controlled steering. In fact, I'm quite sure I *don't* want it. I'm equally sure I never asked for it. > Now think about a computer programming error that causes the steering to do a > hard left at highway speeds. Hold on a minute... no car yet has that kind of steering system. The electric power steering in a few models of cars uses an electric motor instead of a hydraulic pump to provide steering boost, but there's still a physical shaft conected to the wheels. It's no more likely to fail or cause erratic steering than a hydraulic pump. The closest to what you are talking about is found in some newer stability control setups. In an extreme skid, the steering wheel will apply a slight "suggestion" of counter steering force to the wheel. > "Dave Head" <rally2xs@att.net> wrote >> Now think about a computer programming error that causes the steering to [quoted text clipped - 13 lines] > slight > "suggestion" of counter steering force to the wheel. You are incorrect. BMWs' "Active Steering" uses an computer controlled electric motor that turns a planetary gearset to amplify the steering input to the hydraulics. It is programmed to give a wide range of variable-ratios at different speeds, and does give a little opposite lock in oversteer conditions, as you say. Although it might be capable of going out of control; it's not at all exposed to hacking because the computer in control is the DSC/ABS computer and that's not exposed to the outside world. Floyd >> "Dave Head" <rally2xs@att.net> wrote >>> Now think about a computer programming error that causes the >>> steering to do a hard left at highway speeds. >> Hold on a minute... no car yet has that kind of steering system. >> The electric power steering in a few models of cars uses an >> electric motor instead of a hydraulic pump to provide steering >> boost, but there's still a physical shaft conected to the wheels. >> It's no more likely to fail or cause erratic steering than a >> hydraulic pump. >> The closest to what you are talking about is found in some newer >> stability control setups. In an extreme skid, the steering wheel >> will apply a slight "suggestion" of counter steering force to the >> wheel. >You are incorrect. BMWs' "Active Steering" uses an computer >controlled electric motor that turns a planetary gearset to amplify >the steering input to the hydraulics. It is programmed to give a >wide range of variable-ratios at different speeds, and does give a >little opposite lock in oversteer conditions, as you say. >Although it might be capable of going out of control; it's not at >all exposed to hacking because the computer in control is the >DSC/ABS computer and that's not exposed to the outside world. Less concerned about hacking than the general competence of design and inclusion of "failsafes". vis: http://www.autobild.de/aktuell/neuheiten/artikel.php?artikel_id=7348 Summary: A Berlin Police BMW 5 series (E39) went out of control for unexplained reasons late last year. The driver was sent back to driver training school. Something didn't gel so media investigators went out and did some testing. When they hit the brake pedal too hard, (with only about 700 to 900 N force) it caused the ABS/DSC to be disabled... and it remained disabled until the car was turned off, the windows closed and the car locked using the remote control. (Sound familiar?) The brake pedal force sensor also believes that a load equivalent to 120kg is "implausible". Signature/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | I'm a .signature virus! X against HTML mail | Copy me into your ~/.signature / \ and postings | to help me spread! >> Now think about a computer programming error that causes the steering to > do a [quoted text clipped - 12 lines] > slight > "suggestion" of counter steering force to the wheel. There are cars that have fly by wire steering... New Lexus GS is one of those, I believe. >>> Now think about a computer programming error that causes the >>> steering to do a hard left at highway speeds. >> Hold on a minute... no car yet has that kind of steering system. >> The electric power steering in a few models of cars uses an >> electric motor instead of a hydraulic pump to provide steering >> boost, but there's still a physical shaft conected to the wheels. >> It's no more likely to fail or cause erratic steering than a >> hydraulic pump. >There are cars that have fly by wire steering... New Lexus GS is >one of those, I believe. It wouldn't be allowed on the road in most countries. Signature/"\ Bernd Felsche - Innovative Reckoning, Perth, Western Australia \ / ASCII ribbon campaign | I'm a .signature virus! X against HTML mail | Copy me into your ~/.signature / \ and postings | to help me spread! > Item: Software glitches cause Toyota Prius to stall at highway > speeds: [quoted text clipped - 3 lines] > Now think about a computer programming error that causes the steering > to do a hard left at highway speeds. Because as we all know, human controlled cars never crash, right? It's all about the numbers -- if human controlled cars kill 50,000 per year and computer controlled cars kill only 10,000; which is better? SignatureBob >> Item: Software glitches cause Toyota Prius to stall at highway >> speeds: [quoted text clipped - 8 lines] >It's all about the numbers -- if human controlled cars kill 50,000 per >year and computer controlled cars kill only 10,000; which is better? These cars are human controlled with a computer mediating the interaction. So in your scenario you'll have human error killing 50k and computer failure killing 10k, for a total of 60k. SignatureThere's no such thing as a free lunch, but certain accounting practices can result in a fully-depreciated one. >>Because as we all know, human controlled cars never crash, right? >> [quoted text clipped - 4 lines] > interaction. So in your scenario you'll have human error killing 50k > and computer failure killing 10k, for a total of 60k. Bad math. Presumably, the computer would prevent some of the 50k. I don't have a clue what the real numbers are, but it's clear there's not enough data in yet to condemn computer mediated steering out of hand. SignatureBob >>>Because as we all know, human controlled cars never crash, right? >>> [quoted text clipped - 6 lines] > >Bad math. Presumably, the computer would prevent some of the 50k. How? We're talking about a computer which turns the wheels in response to human input, not some sort of intelligent system which knows when you're turning into a crowd of toddlers. SignatureThere's no such thing as a free lunch, but certain accounting practices can result in a fully-depreciated one. >> Item: Software glitches cause Toyota Prius to stall at highway >> speeds: [quoted text clipped - 5 lines] > >Because as we all know, human controlled cars never crash, right? Its _still_ gonna be human controlled, with a computer between the steering wheel and the direction-determining wheels. >It's all about the numbers -- if human controlled cars kill 50,000 per >year and computer controlled cars kill only 10,000; which is better? Its only that the car company's dream is to get rid of the heavy steering column, rack and pinion steering gear, tie rods, and power steering hydraulics and replace it all with maybe a joystick or two and some electronic actuators coupled with a computer and associated other electronics. Same failure mechanism, namely the driver, _plus_ the damn computer and electricals and electronics. Dave Head |
Reply to this Message |
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.