The fragility of car computers revealed.
in [UK Drivers]
|
From: Adrian on 25 May 2010 06:08 Ian Jackson <ianREMOVETHISjackson(a)g3ohx.demon.co.uk> gurgled happily, sounding much like they were saying: >>All of those systems are constantly self-testing, and will interpret any >>anomaly as "shut down and get out of the way", with a fail-safe being >>designed-in. Sure, you might have to press the pedal a bit harder, and >>you might have to remember what to do if they lock - but that's a rather >>fundamental driving skill that all drivers should be expected to >>understand. It's why we still require wetware instead of leaving it to >>hardware and software alone. > Oh, indeed. However, the ability of any system to perform correctly and > react appropriately in all circumstances does depend vitally on the > designers' ability to foresee all possible eventualities. Don't forget that there's a huge difference in complexity between (say) a PC app and an embedded controller - both in terms of the range of functionality and the scope of the environment it has to deal with. The simplest - and by far and away most common is an ABS controller. You've got a very finite range of valid inputs. Four wheel sensor channels, with a narrow range of "correct" values on each. Add in an oil pressure warning feed, so that the ABS is disabled when the engine's not running, a brake light switch feed, so that it only does something when the pedal's actually pressed, and that's about the extent of it. > Occasionally, their foresight fails. If that were not the case, why > have there been so many updates with (just as an example) computer > software?!! The vast majority of which, to embedded systems such as we're talking about, are only minor calibration tweaks.
From: Ian Jackson on 25 May 2010 06:06 In message <htg6ha$k73$1(a)speranza.aioe.org>, boltar2003(a)boltar.world writes >On Tue, 25 May 2010 10:03:07 +0100 >Ian Jackson <ianREMOVETHISjackson(a)g3ohx.demon.co.uk> wrote: >>The problem is, while a braking system might have been designed to fail >>safe if the computer failed, what would happen if the computer didn't >>realise that it had failed? Moderate levels of RF interference are >>probably more likely to confuse a computer than to disable it. > >Doesn't even have to be computerised. If someone or something has messed >up the innards no "fail safe" system can be guaranteed to work as the >clapham rail crash demonstrated. > >But the point is that (so far) computers don't have enough control of a car >to cause the driver to lose control unless they're stupid americans. > Quite. I still reckon that the best brakes I ever had were rod-operated, on my old 1954 Ford Prefect. Of course, there was no fail-safe system, but then, there was little to fail! -- Ian
From: Ian Jackson on 25 May 2010 06:16 In message <66a53971-1d46-4071-b192-f8697056d410(a)z17g2000vbd.googlegroups.com>, Doug <jagmad(a)riseup.net> writes >On 24 May, 11:50, Adrian <toomany2...(a)gmail.com> wrote: >> >> Of course, that ignores (what a surprise...) the very different standards >> of hardware build quality for a controller intended for a 10-20yr service >> life in a hostile environment and a disposable bit of cheap consumer tat. >> >> Anyway, even if it does, you'll just glide gently to a halt safely on the >> hard shoulder. >> >Despite being in the fast lane and having to cross over in heavy >traffic with no brakes and no engine? Or, coast to a stop to remain in >the fast lane in heavy traffic? Glad it will never happen to me. It did (sort of) happen to me when the car suddenly ran out of fuel with no warning (duff gauge) - on the M40 north, just before the junction with the M42. Fortunately, the traffic at that moment was light, and I was able to coast unhindered across to hard shoulder, and roll to a standstill at the next emergency telephone. If the traffic had been heavy, t could have been a lot worse. -- Ian
From: boltar2003 on 25 May 2010 06:38 On 25 May 2010 10:08:51 GMT Adrian <toomany2cvs(a)gmail.com> wrote: >> Oh, indeed. However, the ability of any system to perform correctly and >> react appropriately in all circumstances does depend vitally on the >> designers' ability to foresee all possible eventualities. > >Don't forget that there's a huge difference in complexity between (say) a >PC app and an embedded controller - both in terms of the range of >functionality and the scope of the environment it has to deal with. Depends on what controller. The embedded controllers in a train or an aircraft will be running software a lot more complicated than your average PC app. The control software on the Prius is probably pretty involved as well I should imagine. >The simplest - and by far and away most common is an ABS controller. >You've got a very finite range of valid inputs. Four wheel sensor >channels, with a narrow range of "correct" values on each. Add in an oil >pressure warning feed, so that the ABS is disabled when the engine's not >running, a brake light switch feed, so that it only does something when >the pedal's actually pressed, and that's about the extent of it. The software for ABS is probably not as simple as you seem think as it could be getting difference speed readings from all 4 wheels and then has to decide if thats because all the wheels are slipping at a different rate or because he car is going around a corner and other situations along those lines. Any sufficiently complex bit of software will have potential bugs and its still just software running on a CPU even if its an embedded system. B2003
From: Adrian on 25 May 2010 06:49
boltar2003(a)boltar.world gurgled happily, sounding much like they were saying: >>Don't forget that there's a huge difference in complexity between (say) >>a PC app and an embedded controller - both in terms of the range of >>functionality and the scope of the environment it has to deal with. > Depends on what controller. The embedded controllers in a train or an > aircraft will be running software a lot more complicated than your > average PC app. The control software on the Prius is probably pretty > involved as well I should imagine. No, still fairly straightforward. Think about the sheer range of functionality required for even something simple like an OS running a web browser - and the range of likely attack vectors and input sanitisation required. Compare that to "Oh, look - that wheel's suddenly slowed down much more than the others" >>The simplest - and by far and away most common is an ABS controller. >>You've got a very finite range of valid inputs. Four wheel sensor >>channels, with a narrow range of "correct" values on each. Add in an oil >>pressure warning feed, so that the ABS is disabled when the engine's not >>running, a brake light switch feed, so that it only does something when >>the pedal's actually pressed, and that's about the extent of it. > The software for ABS is probably not as simple as you seem think as it > could be getting difference speed readings from all 4 wheels and then > has to decide if thats because all the wheels are slipping at a > different rate or because he car is going around a corner and other > situations along those lines. All it's looking for is a sudden change in the deceleration rate of a subset of wheels, relative to the others. > Any sufficiently complex bit of software will have potential bugs and > its still just software running on a CPU even if its an embedded system. Of course. |