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.
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. Obviously riding the clutch or the brake caused undesirable wear and was avoided.
"........in electrically noisy environments with connectors subjected to adverse conditions and wires flexing, the possibility that a bit might get flipped doesn't seem surprising......."
You are right to draw attention to the potential problems caused by poor electrical contacts particularly in connectors. These problems are exacerbated by the use of the vehicle body as a ground return for electrical circuits.
There is a multitude of electrical connectors in the modern automobile, each with a pair of vulnerable electrical contacts. For example an engine ECU may have upwards of 50 connectors. Designers in the automobile industry carry out exhaustive Failure Modes and Effects Analysis (FMEA) on components, sub-systems and systems and use this as a basis for the design of fault detection software. Some manufacturers carry out a 'PIN FMEA' for each electronic control unit and its associated wiring harness that lists the potential failure modes of the circuit connected to each pin and the possible resultant effects in terms of system performance. In the case of sensors, the 'PIN FMEA' covers the failure modes of the entire sensor loop. This useful approach to identifying potential problems is deficient in two respects:
1 The failure modes are identified and treated "one at a time", whereas in practice, as far as multi-pin connectors are concerned, common mode failures affecting several pins may occur more or less simultaneously. For example, although the likelihood of two sensors failing simultaneously may appear to be very small, should a multi-pin ECU connector come loose, the likelihood that several sensor circuits may be simultaneously become intermittent is quite high.
2 The FMEA method as presently implemented does not sufficiently recognise and deal with short duration dynamic intermittent faults. Faults are considered as if they will be open or short circuits and the intermediate situation where there are short duration intermittencies are not taken sufficiently into account. Intermittent contact faults in low-current sensor circuits excited by mechanical vibration will make a circuit noisy but, since the average circuit parameters may still remain within the bounds of what is deemed "normal", Electronic Control Unit (ECU) software designed to detect hard faults will not necessarily trigger diagnostic trouble codes (DTCs).
Electrical intermittencies may take many different forms, some of which might be very difficult to locate and confirm in a normal automobile servicing environment. Road-induced shocks and mechanical vibrations induced by the engine and transmission will stress potential points of electrical intermittency simultaneously.
Electrical contacts subject to vibration may become microphonic, as in the carbon microphone. Battery and ground terminals can become loose giving the potential for the generation of large transient voltages on the the DC power bus. Sensor connectors can become intermittent resulting in false speed signals and false accelerometer readings.
What are the engineering and design challenges in creating successful IoT devices? These devices are usually small, resource-constrained electronics designed to sense, collect, send, and/or interpret data. Some of the devices need to be smart enough to act upon data in real time, 24/7. Are the design challenges the same as with embedded systems, but with a little developer- and IT-skills added in? What do engineers need to know? Rick Merritt talks with two experts about the tools and best options for designing IoT devices in 2016. Specifically the guests will discuss sensors, security, and lessons from IoT deployments.