[Whiplash7]

With the increasing trend in handing over more responsibilities of a running vehicle to an Electronic control unit (ECU), there is also an increasing number of unfortunate events that sight unintended acceleration as the cause of an incident.

The term unintended acceleration in simple terms refers to acceleration of the vehicle that was not intended by the driver.

When such an incident occurs the first component to be blamed is the Engine control module (ECM) that is responsible for the engine's behavior in most modern cars. The ECM reads how much the accelerator pedal is pressed and after a lot of calculations decides how much torque the engine shall produce. Hence it's quite obvious why when an unintended acceleration occurs the first guy to be blamed is the ECM. With this thread I would like to throw some light on what OEMs do to make their ECMs safer so that we make an educated guess before blaming the ECM.


1. The picture below is a basic overview of the ECM. The various ECU functions inside the ECM read the input signals from various sensors like the Accelerator pedal position sensor, Air mass sensor, temperature sensor, engine speed sensors, vehicle speed sensors etc. and use the information provided by them to calculate the torque that the engine shall produce. This calculated torque is then realized in the engine by actuating the engine actuators accordingly. eg. injectors, ignition (gasoline only), turbo charger etc.

Now what could possibly go wrong here that could cause an unintended acceleration? Give it a thought for a few seconds.

2. A few things that could go wrong are
-It is possible that the ECM's calculations are wrongly programmed and this shows up in certain situations as unintended acceleration.

Now lets see what is being done to address this problem. To prevent a miscalculation from producing unintended acceleration an additional layer or level of software is added that reads the sensors independently and checks if the torque requested from the ECU functions is within the expected torque range for current situation. Normally these two layers of software are designed and programmed by separate teams or even two different suppliers and hence the chances of the same program error in both SW levels are reduced. Therefore now even if for some reason the ECU functions are wrongly programmed the Level 2 (2nd layer) software will detect this unreasonable torque request and will not gives its approval for the engine to respond to the torque request by the ECU functions software layer or Level 1.

Having taken care of this do you really think anything else could go wrong that would result in the ECM requesting an unreasonable torque from the engine and probably produce unintended acceleration?

3. Yes, it is still possible that the hardware malfunctions,
- ECM does not execute a certain ECU function: It is possible that for some reason the ECM does not execute a critical ECU function which leads to a miscalculation of the torque value and probably an unintended acceleration.

- Certain parts of the ECM memory fail: It is possible that certain parts of the ECM's memory fail and hence the data read from here is no more reliable. Eg. the position of the accelerator pedal sensor was stored in the ECM memory and this is being read by one of the ECU functions to calculate the torque and due to a malfunctioning memory area the ECU functions reads 75% instead of the correct position of 25%.

- Processor failure: It is possible that the ECM's brain or the processor that processes the program malfunctions and hence produces wrong results that could possibly lead to unintended acceleration.

Lets see what is being done by OEMs to tackle this problem

A third layer of software or level 3 software is present partly using a different processor to check all the above scenarios.

To ensure that all ECU functions are executed promptly in the right order and are not missed there is a mechanism by the level 3 software to ensure this by marking the ECU functions executed and hence missing markers are detected to conclude that the corresponding ECU functions were not executed.

To check the memory failure, the third layer or level 3 software during startup and shutdown writes a known value to the memory and reads the memory again to ensure that the same value is returned. Also all information is redundantly stored in two different memory locations, when they are used both memory locations are read and if they are different it is concluded that the value is not reliable anymore.

To ensure that the ECM's processor is producing correct results the level 3 software periodically questions the processor that executes the ECU functions and checks if the responses are correct. eg. it asks the processor the result of 2+3 and if the processor responds with 6 then it is concluded that the ECM's processor is malfunctioning.

As you can see there are safety mechanisms in place ensure that all Software and Hardware systems are not malfunctioning. If any of the above checks fail the level2 or level 3 software layer initiates a safety reaction (plan B) that mostly would result in the shutdown of the engine or limiting the engine to minimum performance to ensure that you could drive it to the nearest garage. The reaction depends on the severity of the malfunction.

In addition to the above checks all critical sensors and actuators are also monitored. sensors values are cross checked with redundant sensors or other sensors to ensure that their values are reasonable.
For example the accelerator pedal being a critical component has two sensors in it. Also all critical actuators eg. throttle body is also monitored with a position sensor to ensure that the throttle has been actuated to the exact position requested by the ECM.

For more detailed information please read the following document that was prepared by the major German Automotive OEMs and suppliers
ak-egas-v5-5-en-130705.pdf

I hope I have been able to convey the basic information present in the above document successfully and that you would be better informed the next time you come across an unintended acceleration incident (although I hope you don't come across such an incident).

[Jeroen]

Thanks, that is very useful and well written piece of information. Maybe just to add, systems gets designed in fail safe. So if a system or a component fails, the system returns to the most safe state.

[Jaggu]

This is really useful information about ECU designs. Thanks for sharing.

Would be interesting to see what are the safety features that are built in to mitigate such catastrophically failures as mentioned in the news?

Egs if the accelerator reading gets stuck is there a way in which the system can read an input from brakes or shift sensor to over ride it. If a shifter in automatic car will allow to shift out of drive mode even when the accelerator is giving full rpm signals etc.

[Whiplash7]

Originally Posted by Jaggu

This is really useful information about ECU designs. Thanks for sharing.

Would be interesting to see what are the safety features that are built in to mitigate such catastrophically failures as mentioned in the news?

Egs if the accelerator reading gets stuck is there a way in which the system can read an input from brakes or shift sensor to over ride it. If a shifter in automatic car will allow to shift out of drive mode even when the accelerator is giving full rpm signals etc.

Yes, of course such a safety mechanism is already there with most OEMs. Its called brake override and almost all OEMs implement this especially after the Toyota incident. When ever the brake and accelerator pedal is pressed together for a certain time the ECM cuts the performance of the engine to a bare minimum.

You could try this in your car, when idling in neutral gear raise the rpm using the accelerator pedal and then press the brake after a few seconds the rpm drops to idle even though the accelerator pedal is pressed. Normal performance would be restored after turning off-on the ignition.

I'm not 100% sure but I think the shifter should allow you to shift to neutral even though the accelerator pedal is pressed, but I could be wrong.

[katchkamalesh]

Though there were incidences of electronics going haywire, the authorities have been quick to modify the regulations governing the electrical and electronics of the vehicles.

The ISO 26262 standard provides regulations and recommendations throughout the product development process, from conceptual development through decommissioning. It details how to assign an acceptable risk level to a system or component and document the overall testing process of all automotive electronic and electrical safety-related systems.

[SS-Traveller]

If there was just the one ECM / ECU controlling the whole vehicle, programmed by a single person/group of persons, maybe we wouldn't have seen this thread being written. Trouble is, there are multiple electronic control modules 'talking' to each other - the one taking care of the gearbox, another keeping an eye on the brakes (and all that one can do with the brakes - ABS, EBD, TC, ESC, cruise control, hill hold, hill descent control, etc.), another for the safety systems (rollover mitigation, airbags, etc.) and then another looking after the suspension... and the list goes on. And these modules are not programmed by the same person/group (it would be impossible to do so, I'd guess).

In some rare instances, the 'talking' happens to get garbled - a bit like a Chinese speaker trying to communicate with someone speaking Greek, with a translator who only knows Swahili to explain things. Maybe there's a software glitch - or maybe rats got to the wiring that connects these little electronic 'brains'. And that's when weird things happen, and cars accelerate on their own, stop on their own, don't 'listen' to driver inputs, and end up trying to mingle with the scenery.

The less the number of electronic control modules in your car, the less likely that such stuff happens. But then, many of us are used to our cars looking out for us automatically, and this tribe of little 'brains' in our cars will only increase over the coming years.

As for me, there have lately been times when I climbed into a modern fancy car and didn't even know how to get the car to start or move - there's no key to turn, and no gearshift to move! I really hate those cars.

[T-Bone]

Hi All,

I am sure all ECU's (or any electronic device) will have a power supply, for it to function. So why don't manufacturers put in an "emergency stop" button which effectively,

1. Cut power supply to the ECU which might be similar to turning off the engine

Or

2. Override all current function/processes and enable safe stop.

Possible ?

[sandeepmohan]

Originally Posted by Whiplash7

Its called brake override and almost all OEMs implement this especially after the Toyota incident.

I have probably shared this information earlier. In a column written by Paul Horrell for Top gear magazine, he had put down his observations on the issue.

The first one remains a mystery as Toyota could not replicate the "unintended" acceleration issue in their labs. We are never going to know what really happens in a lab. As American politics would favor American car brands, there was also a theory that they bloated the issue to bring back customers. They started a marketing campaign for customers to trade in their Toyota's for American rides. Then one day, Toyota throws in massive discounts on their cars in the USA and customers come running back. The problem of "unintended" acceleration is no more a fear or problem.

Much after this, Toyota did recall cars but not for unintended acceleration. This was a problem with a component in the throttle assembly that caused it to get stuck.

[Whiplash7]

Originally Posted by SS-Traveller

In some rare instances, the 'talking' happens to get garbled - a bit like a Chinese speaker trying to communicate with someone speaking Greek, with a translator who only knows Swahili to explain things. Maybe there's a software glitch - or maybe rats got to the wiring that connects these little electronic 'brains'. And that's when weird things happen, and cars accelerate on their own, stop on their own, don't 'listen' to driver inputs, and end up trying to mingle with the scenery.

There are safety mechanisms in place for such a scenario too. Normally all information shared between ECUs is via the CAN bus. Every information sent over the CAN bus is normally accompanied by 2 additional pieces of information, A rolling counter and a check-sum.

1.Rolling counter: Every time an ECU sends a data over the CAN bus the rolling counter information is incremented by 1 and usually rolls back to 0 after reaching a cont of 3 or 5.

For eg
Assume the data 25 being sent from once ECU to another periodically this is what happens to the rolling counter

25,0
25,1
25,2
25,3
25,0
25,1
......

Therefore if a certain instance of data was dropped by the CAN bus, then the receiving ECU would be able to know tellexactly which instance of data it has missed.
For eg.
25,0
25,1
25,3
25,0

So considering the above scenario the receiving ECU know that the data instance after 25,1 was missed since the next rolling counter value is 3 instead of 2.

2. Check-sum:
The second piece of information is the check-sum, In short or layman terms its a number that is calculated based on the data
For eg. is the data to be sent is 25, the check-sum could be 2+5=7, hence
25,0,7
25,1,7
25,2,7
25,3,7
25,0,7
25,1,7

The receiving ECU re-calculates the check-sum from the data (2+5=7) and checks if this value is the same as the check-sum it received with the data on the CAN bus.

25,0,7
25,1,7
23,2,7 <------
25,3,7
25,0,7

From the above sequence of data instances the receiving ECU would have calculated for the 3rd instance 2+3=5 and when 5 is not equal to the check-sum of 7 that it received with the data it knows that the data is not reliable and then makes a safety reaction (plan B)

Originally Posted by T-Bone

Hi All,

I am sure all ECU's (or any electronic device) will have a power supply, for it to function. So why don't manufacturers put in an "emergency stop" button which effectively,

1. Cut power supply to the ECU which might be similar to turning off the engine

Or

2. Override all current function/processes and enable safe stop.

Possible ?

The only reason I can of is that cutting complete power supply could also be dangerous like loss of power steering, electronic door locks and loss of active and passive safety systems. Also accidental pressing of this big red button on highways could be fatal.

Originally Posted by sandeepmohan

The first one remains a mystery as Toyota could not replicate the "unintended" acceleration issue in their labs.

I also remember reading elsewhere that a reduction in deceleration while braking in hybrid cars could have been misinterpreted by drivers as unintended acceleration. In hybrid cars when the driver starts braking, the electric motor is switched into a generator and starts generating electricity to charge the battery and hence becomes a load on the wheels while producing a braking effect. Now when the battery is more or less full and when the recuperation stops (motor is no longer in generator mode and hence not a load on the wheels) then the role of the main brakes is increased and if this handover is not done in a smooth manner you could experience reduced deceleration while braking and this cause panic in the driver.

[WAM-4]

I'll give my perspective to this having been on the inside as a function developer in Bosch for 4 years.

The ECUs per se are safe. However, they are only as safe as how well they have been programmed by the developers and how well the electronic algorithms that have been designed by the designers and technical architects.

The tough deadlines given by the OEMs make it impossible to test these modules [safety critical modules included] thoroughly! Corners are cut to meet time demands.

On a broader perspective the 3 most important things in Project Management are :

Cost.
Quality.
Time.

In order to reduce the cost and produce these ECUs in double - quick time, the obvious collateral damage is the Quality [testing].

Hence, we are seeing a lot of incidents, some potentially fatal, being recorded due to issues with respect to ECUs.

I had mentioned in my post in other thread just yesterday that it is time the automakers review the amount of integration of electronics into the mechanicals of the vehicle. They should take a call to reduce the electronics and give more control / responsibility to the driver who can then take corrective actions in crunch situations!

[audioholic]

Since I work in the same field, I would like to share my experience with this topic. To give a brief intro, I write software for the Driver Assistance ECU, which is slowly going to turn into an Autonomous Driving controller ECU in the coming years. Hence, this ECU is capable of controlling the entire car, right from the Engine till the door locks. I can give a much more detailed bunch of info, but such things are highly confidential, and are not supposed to be shared anywhere. Hence, from the general information available across platforms and manufacturers, I can briefly summarise. Whiplash has already explained about the hardware and ECU level safety and various other measures put in place. I will not add to the same info.

When we speak about something like the ECU I work on, it is just not a single ECU doing its work, but its a huge network of ECUs and sensors. So huge that CAN and Flexray which were once the backbone of car networks are now replaced by Ethernet networks, especially for ADAS and autonomous driving. The ADAS ECU in most cars acts as a brain, and communicates with all the other ECUs with requests or commands. For example, if the ADAS senses there could be a collision, and wants to brake the car, it sends a brake request to the ESP, deceleration request to the TCM( to initiate a kickdown or disengage the clutch) and a throttle cutoff request to the ECM. They do their respective jobs and bring the car to a halt.

Seeing this, we can tell that in modern cars, its a complex network in action and not a single ECU. That leads to additional complications. In an event like unintended acceleration, there could be culprits everywhere, right from a faulty accelerator pedal to an throttle increment request sent by the TCM, to do revv matching while downshifting.

Now, since these are getting more complex, so are the processes, design methods, validation and testing. From the software point of view, we have multiple levels of validation, which will ensure that at no point of time in the entire code, there should be any garbage data sent out to any other module or internally to a different function. Uninitialised variables create so much of a trouble if it is transmitted across the system.

An interesting but silly mistake we found during a test run on the car was that the system would crash while taking lock to lock turns. Realised that there was a tan calculation which would tend to infinity once the steering angle crossed 89 deg. Such mistakes if they slip through into the market, it will cause system malfunctions. However, these dont make it to series software as this was just a protype software written without any of the checks in place. The probablity of such a mistake being found out at the initial stages is 1. However, consider the Skoda accident in the UK(the cause is not yet known) where the deceased driver tried to switch the driving mode while cruise control was on. This type of a use case has a lesser probability of being tested on the vehicle. In such a case, if a good development process isnt followed, the bugs in the system wont get caught.


Auto manufacturers are bound to be responsible to some extent if something goes wrong, and no one wants to appear in the news for wrong reasons. Hence, a lot of resources and money is invested to make these systems robust. We have a team whose job is to only ensure that the software developed has security checks at each and every function to give out safe outputs and also disregard any unacceptable inputs. We should always take the worst case scenario, and ensure that even if a code or an entire system fails, it should not affect the network and interfere with other ECUs in the car. Suppose the ADAS ECU fails, it should not end up sending an acceleration or a braking request to any ECU.

Also, within an ECU itself, we have two processors running the same code. Their outputs are then analysed by a third ECU, and compared to ensure both are working fine, and not failed. With such things in place, failure of ECUs are very rare, due to internal factors.

Assume the keyless entry ECU fails. It should ensure that the engine shuts down or the vehicle goes into limp mode, with limited speed or so. Hence at the hardware level, the KE ECU should be sending an ALL OK signal to the other systems. If it shuts down or fails, this ALL OK signal will no longer be there, which should alert the other systems to take necessary steps. If that check is not done periodically, the engine may continue to run even after the KE system fails, which will lead to unintended behaviour.

If I have to answer how safe the modern ECMs are - They are very very safe. Because a lot of people and companies are paid to make them safe at all levels possible, and implement the best redundancy measures to ensure everything works fine. Some of the measures are common across manufacturers, while some are proprietary. Hope I have added some insight into the way things work, but like I told, we cannot divulge detailed or clear information, but that would be interesting.

[Jeroen]

Originally Posted by SS-Traveller

If there was just the one ECM / ECU controlling the whole vehicle, programmed by a single person/group of persons, maybe we wouldn't have seen this thread being written. Trouble is, there are multiple electronic control modules 'talking' to each other - the one taking care of the gearbox, another keeping an eye on the brakes (and all that one can do with the brakes - ABS, EBD, TC, ESC, cruise control, hill hold, hill descent control, etc.), another for the safety systems (rollover mitigation, airbags, etc.) and then another looking after the suspension... and the list goes on. And these modules are not programmed by the same person/group (it would be impossible to do so, I'd guess).

Actually, it’s not a bad thing at all, in fact there are many instances where the developers of the same system, working on different parts, are kept segregated. It introduces another level of security/safety. Of course, you need to spend time/effort on verifying that every box works with every other box. But at least it is highly unlikely you will end up with the same bug in every box as they “copied" each other work.

In the past control system in the aviation and airspace industry often followed this separate design team regime. For instance, on earlier rocket guidance system most relied on at least three different computers running in parallel. Very basic, all three computer agree, all is well, two computer agree the other one gets overrides etc. Each computer was designed/programmed by a different team in order to ensure additional safety/redundancy right into the design. The teams would work completely independent to achieve the same set of specifications. So you ended up with three unique computers, doing the identical same thing, but based on very different software architecture and programming.

Jeroen

[audioholic]

Originally Posted by T-Bone

I am sure all ECU's (or any electronic device) will have a power supply, for it to function. So why don't manufacturers put in an "emergency stop" button which effectively,

Its there on prototypes and test vehicles. But that is used to reset the system and not cut power. Power cut will mean a lot of other complications as explained in the previous post. Adding such a button on a series vehicle will reduce the assurance given by the manufacturer to the buyer. The system shouldnt fail. No what ifs in such a scenario.

Originally Posted by SS-Traveller

If there was just the one ECM / ECU controlling the whole vehicle, programmed by a single person/group of persons, maybe we wouldn't have seen this thread being written.

This sir, is and will never be possible. It is necessary to have a networked architecture. Also, I dont agree with this. No one working in this field will agree either. If you have one big system controlling an entire vehicle, room for error and failure is higher and so is the eventualities. When my ECM fails, I at least expect the ABS/ESP working to safely brake my car instead of having to sit in the car with all systems down and no steering/brakes. And one person writing the code? Far, far away from reality.

In some rare instances, the 'talking' happens to get garbled - a bit like a Chinese speaker trying to communicate with someone speaking Greek, with a translator who only knows Swahili to explain things. Maybe there's a software glitch - or maybe rats got to the wiring that connects these little electronic 'brains'. And that's when weird things happen, and cars accelerate on their own, stop on their own, don't 'listen' to driver inputs, and end up trying to mingle with the scenery.

I see this as very vague. Comparing Chinese and Greek with what happens in the car is far apart. Maybe a missed letter. But not a different language. And in any implementation of such a system, driver inputs are always given priority. There are overrides at the input level to ignore machine input if there is a driver input. It looks like you are speaking out of hearsay and internet articles which try to create sensational news. Like I told before, if there really is a software glitch, the system is designed to not misbehave and stay silent.

Talking about rat bites, those are only applicable to cars which are primitive, like what we have in India. In most of the cars here, there is a bunch of wires that go into the door from the car which if one is broken, it will lead to malfunction. Take the current generation cars available in foreign market, it will be a pair of wires and possibly a backup that can transmit the entire bunch of signals. If a rat bites this wire, it will still have a backup to do the same job and also the information about this break in link will be available on the instrument cluster. If you want to experiment driving after that, its at the owners risk.

[SS-Traveller]

Originally Posted by audioholic

It looks like you are speaking out of hearsay and internet articles which try to create sensational news. Like I told before, if there really is a software glitch, the system is designed to not misbehave and stay silent.

...which brings us to the reason why this thread was written in the first place. If the system didn't misbehave at least in a few recorded instances, we wouldn't really be debating about how safe ECMs are.

So why do electronic control modules misbehave, and why do cars grow a mind of their own?

PS: Computers and coding are not my forte, but certain terms like failsafe somehow lead us laymen to believe that nothing can go wrong in computer-controlled machinery - yet, time and again, things do go wrong.

Talking about rat bites, those are only applicable to cars which are primitive, like what we have in India.

Err... BMWs and Audis sold in India are primitive? GTO's BMW is primitive? All the cars mentioned in this thread are primitive?

[Jeroen]

Originally Posted by SS-Traveller

...which brings us to the reason why this thread was written in the first place. If the system didn't misbehave at least in a few recorded instances, we wouldn't really be debating about how safe ECMs are.



So why do electronic control modules misbehave, and why do cars grow a mind of their own?



PS: Computers and coding are not my forte, but certain terms like failsafe somehow lead us laymen to believe that nothing can go wrong in computer-controlled machinery - yet, time and again, things do go wrong.

Are there any well documented cases of such cars going of on their own? I mean really well factually documented?

Runaway cars and or engine are nothing new, happened before any electronics were introduced as well. We just did not have social media at the ready to discuss endlessly

Jeroen