Slashdot Mirror
Do Car Safety Problems Come From Outer Space?
Hugh Pickens writes "As electronic devices are made to perform more and more functions on smaller circuit chips, the systems become more sensitive and vulnerable to corruption from single event upsets. This is especially true of Toyota, which has led the auto industry in its widespread inclusion of electronic controls in the manufacture of their various car models. 'These circuit families store not just data, but their basic function electrically,' says Lloyd W. Massengill, director of engineering at the Vanderbilt Institute for Space and Defense Electronics at Vanderbilt University. 'In the unfortunate event of a particle flipping just the right bit, a circuit configured to carry out a benign action may be reprogrammed to carry out some unintended action.' Denise Chow writes in Live Science that some scientists are pointing to cosmic ray radiation as a plausible mechanism behind the sudden, unexplained acceleration reported to have occurred with the late model Toyotas."
"As the design of automobile systems continues to evolve from mechanical to electronic controls, relying more and more on various circuitry and chips, these electronic components may be vulnerable to being confounded by high-energy radiation writes Chow. Federal regulators were prompted to look into the possible role that cosmic rays played in Toyota's product recall fiasco after an anonymous tipster suggested the design of Toyota's microprocessors, software and memory chips could make them more vulnerable (PDF) to interference from radiation compared with other automakers. 'What's not known is what direction Toyota and other automakers are taking in terms of finding and correcting these issues,' says senior researcher Ewart Blackmore."
Interference from radiation doesn't just come from outer space, it comes from cell phones, TV/radio stations, microwaves.... you see where this is going. I once worked in an office where there was a cell phone relay antenna too close to a PC, and we were constantly reinstalling the OS until I told them to move things around in the area.
Thing is, when Windows gets a corrupted OS... it BSODs and we move on. Single-bit errors shouldn't send the car out of control... there should be some checksum that shouldn't add up. When a fault is detected, it should go to a backup program about safely shutting down the car.
Since the biggest Toyota runaway story has turned out to be a problem exists between seat and pedals situation... is this all hype with no science behind it?
While working for Motorola, I worked on electronic throttle control (ETC). We spent a ton of time working to make the system "fail safe". I think we all had in the back of our minds that it was only a mater of time before we would have to testify as to our engineering decisions.
My little part of ETC involved adding a sub processor which watch-dogged the main micro. The little micro asked a series of questions of the main micro. Both processors would need to agree on all the inputs and output of the system. The little micro would also ask question regarding real time OS (RTOS) of the main micro. The main micro would need to have tasks executing in the right order to satisfy the small micro. Lastly, the small micro would ask the main micro to perform math operations to verify accuracy. Oh, and the main micro was continuously checksumming it's memory too.
Both micros had a direct hardware disable path to the H-bridge which was delivering power to the throttle plate. The throttle plate was spring loaded, so, with power cut, the throttle plate would snap to an idle position.
Next came the electro / magnetic compatibility testing (EMC). We spent months inside huge chambers testing both radiation and susceptibility. One of the tests for susceptibility involved using a zap gun to spark a 20kV spark on each pin of our ECU. Not satisfied with that, our customer opened one of our modules and used a sparking spark plug to slowly zap our board to failure. Bottom line, that throttle plate better never stick one way, or the other.
In the end, it always amazed me that the whole thing would work at all. Seemed to me that the system was always seconds away from going into some kind of fail safe mode.
No, a stray bit flip is not going to facilitate a run away car. Least not on my system!
When I was working for NASA, on the NISN network, we'd get these weird router crashes for the old Cisco router located at (or very near) the South Pole in Antarctica. It was always a memory problem, and I'd always have to call someone to get them to powercycle the router. It irritated me to keep bothering those guys, so I opened a case with Cisco TAC.
The TAC guy sent a terse response, saying that particular crash was a "transient memory error" due to "alpha radiation or sun spots." That really pissed me off -- Cisco TAC just gave me a standard BOFH response! I escalated, and swung the NASA club around some, and finally got a senior engineer on the phone. "You said this router's at the South Pole, right? So that means it's at very high altitude, with very little ozone shielding, right?" "Umm, yeah." "Well there you go. There's a lot more radiation at that altitude than at sea level. Our stuff's only rated for sea level. See if they can .. I dunno, put a lead blanket over it or something."
I relayed the info to my contact at McMurdo, and he laughed and said he'd figure something out.
On a hunch, I checked the other two "high-altitude" routers we had, and sure enough, they both had a statistically higher failure rate for "transient memory errors".
http://unxmaal.com