MeasurementBlues, I thought the article implied the memory corruption "may" have caused the bit flip. Given all that I read in the article it makes me quite concerned about self driving cars. I hope that there will be standards employed simular to the FDA's life critical devices. With a little (very little) experience with fail safe coding and hardware design it seems obvious to me that cabling could fail in many ways. Cable signal design should have provided for an easy means of detection of a single or multiple line cable falure, sort of like the old active low signals with pull ups for backplanes. It is important to keep in mind the technical challenges involved in coding but I wonder if there should be an electronic override feature that provides either a fresh reload of code (if it is possible to do safely - I don't know what the reload/power up looks like) or a fully parrallel "simple" processor to allow for "direct" user control with minimal bells and features.. Just thinking that if nothing else, being able to TAKE back control in a manual as possible means would be at least reasurring.
Was the rate of acceleration was specified in any of the reports both the agencies had provided. Or in the event of accident it was found that how much approximate was the rate at which the car had accelerated?
The "failed to comply" simply refers to the general OSEK compliance testing.
There is (or was - it's been a while since I was involved in OSEK) a requirement that you submit your OSEK implementation for compliance testing before you are allowed to call it an OSEK-compliant operating system. Toyota's OSEK apparently hadn't been submitted for this testing, so was not officially OSEK-compliant (and couldn't legally refer to their OS as OSEK - as the trademark terms for OSEK say the only permitted use is for compliant OSs)
"Before power brakes and automatic transmissions, using the right foot for the gas pedal (a 'light' touch) and the left foot for the clutch and the brake (a 'heavy' touch) made good sense."
This is getting rather tangential, but it seems to me that when driving a stick, you have to be able to press both the clutch and the brake together, although not exactly simultaneously. Therefore, it's practically impossible to use the same foot for both.
Slow down for a red light. You lift your foot off the accelerator. Perhaps you downshift for some engine braking. You start applying the brakes. As the car slows down, clutch still engaged, you will have to push in the clutch to keep the engine from stalling, as the car comes to a stop. Meanwhile, your right foot has been braking all along.
Or, slowing down for a tight turn. Foot off the accelerator, you brake gently with your right foot, then push in the lcutch to downshift, release the clutch while still braking gently, and then accelerate out of the curve. Sill pretty hard to do with just one foot.
Honestly, I see no good reason for pushing the accelerator and the brake at the same time, unless you're a teenager looking to spin the wheels when the light turns green, and still too clueless to understand the damage you're doing to dad's car.
Frank, yes, the memory corruption referred here is caused by software defect.
Now, there are different types of software defect that causes memory corruption. They include: -Buffer Overflow -Invalid Pointer -Dereference/Arithmetic -Race Condition(a.k.a., "Task Interference") -Nested Scheduler Unlock -Unsafe Casting -Stack Overflow
The experts' group found software defect in 2005 Camry L4 in every single item listed above.
Frank, just to clarify the findings by the experts' group in this case, let me add a few more details.
Accorinding to the experts group,
"2005 Camry L4 source code and in-vehicle tests confirm that some critical variables are not protected from corruption. For example, a)Mirroring was not always done; and b)No hardware protection against bit flips."
The group also found "sources of memory corruption are present." The group referred to that "Stack overflow can occur; and there are software bugs -- NASA found bugs and Barr Group has found others."
The group, thus, concludes that they found enough evidence that "Toyota's ETCS software can malfunction."
"failed to comply" suggests that OSEK compliance was mandatory. I'm pretty sure that's not the case. More in general, it seems to me that the article could do a better job in providing context.
A 2005 electronc controller was most likely designed in 2002, given the long and rigorous tests that are standard practice in automotive. So it may be unfair to compare a 2002 design with what is considered state of the art in 2013.
Somebody else has already pointed out that ISO26262 did not exist then, but also I would bet that automotive grade dual-core lock-step microcontrollers with SRAM ECC did not exist then.
Technology goes forward by improving on the existing state-of-the-art, but that is a moving target.
It would be great if Barr Group could share their calculation of the probability of occurrence of the failure mechanisms they identified, and if they could compare such probability with the probability of a mechanically-only failure and also with the probability of electronic failure in other manufacturers' vehichle of the time. Which I think is the definition of state of the art.