Near crash as Maserati Ghibli accelerates by its self…twice!
Discussion
poo at Paul's said:
I thought pretty much all dbw cars nowadays auto disengaged throttle body when brake is pressed? Try left foot braking a modern hatchback and there's not smooth progressive tightening of your line, more a get thrown through the screen moment!
it allows some, but there will be an algorithm, if brake is hit hard would stop car suddenly even with accelerator pressed. more gentle would allow both. Someone more technical could advise, but would point to driver if no other faults. Thesprucegoose said:
poo at Paul's said:
I thought pretty much all dbw cars nowadays auto disengaged throttle body when brake is pressed? Try left foot braking a modern hatchback and there's not smooth progressive tightening of your line, more a get thrown through the screen moment!
it allows some, but there will be an algorithm, if brake is hit hard would stop car suddenly even with accelerator pressed. more gentle would allow both. Someone more technical could advise, but would point to driver if no other faults. I grew up on analogue cars and racing and rallying them, used to left foot brake on the road daily, but a skill sadly being lost and not learned by users of modern machinery!
Watchman said:
Is it a drive by wire? I suspect it is - many cars are these days. I always wondered what might happen when you get the equivalent of your PC going slow for a sec and then catching up. You say you tried to accelerate but nothing happened, then it did so without your input. Sounds like it was just registering the input from those seconds earlier. Maybe.
The software for engine/powertrain control as well as other safety systems is designed in such a way that you cannot have a "go slow".The OS is typically a minimal "real time" OS with no extraneous features - i.e. it is able to make absolute guarantees to individual processes about time lags. So, if a process asks for notifications every 5 ms, then if the request succeeds, then the OS is able to give a firm guarantee that these will be delivered on time, every time. This in turn requires significant differences in design of both the OS and the software. For example, procedures which may take an unpredictable amount of time, or cause lags, may not be available - for example, memory allocation at runtime is generally not possible. Instead, the developer must allocate all memory at compile time with static allocation. If the OS is unable to allocate the memory at boot time, the process cannot start. At the same time, the software tends to be written so as to always take a consistent amount of time to run - there is very little "if...then...else.." type code. Instead, the code tends to be mathematical equations and table look-ups which take a precisely defined and consistent time to run with only limited amounts of internal variables.
On a similar theme, because the software design guarantees timely response, there is usually no need for an event queue, so even if there was some sort of time lag, then you wouldn't get the desktop PC type effect, where all your last actions suddenly play out as the system catches up with real events.
There are internal failsafe systems as well, such as watchdog timers which reboot the CPU if the software doesn't keep resetting it every few ms. Modern automotive ECU CPUs also use dual redundant lockstep cores - At the end of each CPU cycle, there is a hardware comparator circuit which verifies that the two redundant CPU core subsystems are in the exact same state. If there is some sort of electronic glitch in the CPU, so that the main and redundant CPU cores end up in a different state, then the hardware comparator will reset and reboot the system.
Another approach that has also been used is to have a 2nd separate supervisory CPU which checks the health of the first (often a different design from a different vendor). In this case, both the main CPU and the supervisor CPU get duplicated sensor inputs, with the main CPU streaming digital sensor data (e.g. throttle position, brake pedal pressure) to the supervisor. If the data stream stops, or doesn't match the physical inputs, then the supervisor CPU recognises a catastrophic malfunction of the main CPU and removes power from the main CPU as well as key actuators (fuel injectors, ignition, fuel pump, etc.) This came out in the legal case against toyota for unintended acceleration. A software specialist for the claimant argued that if the process controlling the throttle crashed, then the electronic throttle could remain open. Toyota pointed out that the throttle control process also echoed brake pedal data to the supervisory CPU. If it had crashed, the supervisor would have triggered emergency shutdown as soon as the brake pedal was touched.
WatchfulEye said:
The software for engine/powertrain control as well as other safety systems is designed in such a way that you cannot have a "go slow".
The OS is typically a minimal "real time" OS with no extraneous features - i.e. it is able to make absolute guarantees to individual processes about time lags. So, if a process asks for notifications every 5 ms, then if the request succeeds, then the OS is able to give a firm guarantee that these will be delivered on time, every time. This in turn requires significant differences in design of both the OS and the software. For example, procedures which may take an unpredictable amount of time, or cause lags, may not be available - for example, memory allocation at runtime is generally not possible. Instead, the developer must allocate all memory at compile time with static allocation. If the OS is unable to allocate the memory at boot time, the process cannot start. At the same time, the software tends to be written so as to always take a consistent amount of time to run - there is very little "if...then...else.." type code. Instead, the code tends to be mathematical equations and table look-ups which take a precisely defined and consistent time to run with only limited amounts of internal variables.
On a similar theme, because the software design guarantees timely response, there is usually no need for an event queue, so even if there was some sort of time lag, then you wouldn't get the desktop PC type effect, where all your last actions suddenly play out as the system catches up with real events.
There are internal failsafe systems as well, such as watchdog timers which reboot the CPU if the software doesn't keep resetting it every few ms. Modern automotive ECU CPUs also use dual redundant lockstep cores - At the end of each CPU cycle, there is a hardware comparator circuit which verifies that the two redundant CPU core subsystems are in the exact same state. If there is some sort of electronic glitch in the CPU, so that the main and redundant CPU cores end up in a different state, then the hardware comparator will reset and reboot the system.
Another approach that has also been used is to have a 2nd separate supervisory CPU which checks the health of the first (often a different design from a different vendor). In this case, both the main CPU and the supervisor CPU get duplicated sensor inputs, with the main CPU streaming digital sensor data (e.g. throttle position, brake pedal pressure) to the supervisor. If the data stream stops, or doesn't match the physical inputs, then the supervisor CPU recognises a catastrophic malfunction of the main CPU and removes power from the main CPU as well as key actuators (fuel injectors, ignition, fuel pump, etc.) This came out in the legal case against toyota for unintended acceleration. A software specialist for the claimant argued that if the process controlling the throttle crashed, then the electronic throttle could remain open. Toyota pointed out that the throttle control process also echoed brake pedal data to the supervisory CPU. If it had crashed, the supervisor would have triggered emergency shutdown as soon as the brake pedal was touched.
We know all that but what about the carpet ?The OS is typically a minimal "real time" OS with no extraneous features - i.e. it is able to make absolute guarantees to individual processes about time lags. So, if a process asks for notifications every 5 ms, then if the request succeeds, then the OS is able to give a firm guarantee that these will be delivered on time, every time. This in turn requires significant differences in design of both the OS and the software. For example, procedures which may take an unpredictable amount of time, or cause lags, may not be available - for example, memory allocation at runtime is generally not possible. Instead, the developer must allocate all memory at compile time with static allocation. If the OS is unable to allocate the memory at boot time, the process cannot start. At the same time, the software tends to be written so as to always take a consistent amount of time to run - there is very little "if...then...else.." type code. Instead, the code tends to be mathematical equations and table look-ups which take a precisely defined and consistent time to run with only limited amounts of internal variables.
On a similar theme, because the software design guarantees timely response, there is usually no need for an event queue, so even if there was some sort of time lag, then you wouldn't get the desktop PC type effect, where all your last actions suddenly play out as the system catches up with real events.
There are internal failsafe systems as well, such as watchdog timers which reboot the CPU if the software doesn't keep resetting it every few ms. Modern automotive ECU CPUs also use dual redundant lockstep cores - At the end of each CPU cycle, there is a hardware comparator circuit which verifies that the two redundant CPU core subsystems are in the exact same state. If there is some sort of electronic glitch in the CPU, so that the main and redundant CPU cores end up in a different state, then the hardware comparator will reset and reboot the system.
Another approach that has also been used is to have a 2nd separate supervisory CPU which checks the health of the first (often a different design from a different vendor). In this case, both the main CPU and the supervisor CPU get duplicated sensor inputs, with the main CPU streaming digital sensor data (e.g. throttle position, brake pedal pressure) to the supervisor. If the data stream stops, or doesn't match the physical inputs, then the supervisor CPU recognises a catastrophic malfunction of the main CPU and removes power from the main CPU as well as key actuators (fuel injectors, ignition, fuel pump, etc.) This came out in the legal case against toyota for unintended acceleration. A software specialist for the claimant argued that if the process controlling the throttle crashed, then the electronic throttle could remain open. Toyota pointed out that the throttle control process also echoed brake pedal data to the supervisory CPU. If it had crashed, the supervisor would have triggered emergency shutdown as soon as the brake pedal was touched.
Are the pedals offset slightly Italian style? I once found myself heading straight into back of a car in queued traffic as I thought I had my foot on the brake. Luckily I didn't, at the time , I was convinced it was the car (as I am a driving god and do not make mistakes ;-)) the car in question was a Fiat Punto I think
Monkeylegend said:
We know all that but what about the carpet ?
I agree. That's what the cause was when my lexus suddenly accelerated wildly. I'd gunned it to complete a right turn. And after having let off the gas after achieving a suitable speed, the damn thing kept accelerating wildly. Anyway, I brought it to a stop, pulled over, and after putting it in neutral, the engine rpms were bouncing off the limiter, until I took a look in the footwell and found the pedal stuck under the carpet.
WatchfulEye said:
interesting things
I didn't know they were using separate redundant processing, I knew they had the lockstep setup though.Most people, even today, haven't any knowledge of real time systems, only interactive, and hence apply inappropriate norms to them. Try explaining it for the interested!
First thank you for all taking time for your comments in what feels like a mine field!
To clarify points that I haven’t made clear!
• Car firstly went to Maranello Egham not Italy
• I was careful in reflecting what happened so it was not be being a dick
• I wanted to point out I had plenty of driving experience and with automatic transmission cars not that I was a good driver
• The roundabout in question is a route I take every day for past three years
• I approached roundabout and when seeing the right was clear that was when I tried to accelerate, there was no fast approach or hard braking and was literally a minute from work
• The momentum allowed the car to enter the roundabout junction/road
• I did not go over the roundabout and damage the car, the steering was working
• It happened twice in quick succession but after the second time it seemed all the warning lights, multi colours flashed up on face of speed dial but I could not get my phone out quick enough to take a shot, this what’s make me think its not driver error, once maybe but twice?
• The time lag before the acceleration kicked in seemed an age felt like over 5 seconds surely a performance car should not have this short of lag and throttle should have cut out if brake pressed hard and it definitely did not as I remember hitting the brake pedal hard and car was still trying to accelerate
• 2016 recall was blamed on faulty mats, mine had factory fitted mats
• Even if under 30 days the fault has to be confirmed before rejection so has to be a honest dealership or independent report, was it a fault that was fixed?
• I have fitted a Gopro aimed at dash, but becoming a bit of a hassle so have to pick my drives
• Surely it cannot be a one off
To clarify points that I haven’t made clear!
• Car firstly went to Maranello Egham not Italy
• I was careful in reflecting what happened so it was not be being a dick
• I wanted to point out I had plenty of driving experience and with automatic transmission cars not that I was a good driver
• The roundabout in question is a route I take every day for past three years
• I approached roundabout and when seeing the right was clear that was when I tried to accelerate, there was no fast approach or hard braking and was literally a minute from work
• The momentum allowed the car to enter the roundabout junction/road
• I did not go over the roundabout and damage the car, the steering was working
• It happened twice in quick succession but after the second time it seemed all the warning lights, multi colours flashed up on face of speed dial but I could not get my phone out quick enough to take a shot, this what’s make me think its not driver error, once maybe but twice?
• The time lag before the acceleration kicked in seemed an age felt like over 5 seconds surely a performance car should not have this short of lag and throttle should have cut out if brake pressed hard and it definitely did not as I remember hitting the brake pedal hard and car was still trying to accelerate
• 2016 recall was blamed on faulty mats, mine had factory fitted mats
• Even if under 30 days the fault has to be confirmed before rejection so has to be a honest dealership or independent report, was it a fault that was fixed?
• I have fitted a Gopro aimed at dash, but becoming a bit of a hassle so have to pick my drives
• Surely it cannot be a one off
WatchfulEye said:
Watchman said:
Is it a drive by wire? I suspect it is - many cars are these days. I always wondered what might happen when you get the equivalent of your PC going slow for a sec and then catching up. You say you tried to accelerate but nothing happened, then it did so without your input. Sounds like it was just registering the input from those seconds earlier. Maybe.
The software for engine/powertrain control as well as other safety systems is designed in such a way that you cannot have a "go slow".The OS is typically a minimal "real time" OS with no extraneous features - i.e. it is able to make absolute guarantees to individual processes about time lags. So, if a process asks for notifications every 5 ms, then if the request succeeds, then the OS is able to give a firm guarantee that these will be delivered on time, every time. This in turn requires significant differences in design of both the OS and the software. For example, procedures which may take an unpredictable amount of time, or cause lags, may not be available - for example, memory allocation at runtime is generally not possible. Instead, the developer must allocate all memory at compile time with static allocation. If the OS is unable to allocate the memory at boot time, the process cannot start. At the same time, the software tends to be written so as to always take a consistent amount of time to run - there is very little "if...then...else.." type code. Instead, the code tends to be mathematical equations and table look-ups which take a precisely defined and consistent time to run with only limited amounts of internal variables.
On a similar theme, because the software design guarantees timely response, there is usually no need for an event queue, so even if there was some sort of time lag, then you wouldn't get the desktop PC type effect, where all your last actions suddenly play out as the system catches up with real events.
There are internal failsafe systems as well, such as watchdog timers which reboot the CPU if the software doesn't keep resetting it every few ms. Modern automotive ECU CPUs also use dual redundant lockstep cores - At the end of each CPU cycle, there is a hardware comparator circuit which verifies that the two redundant CPU core subsystems are in the exact same state. If there is some sort of electronic glitch in the CPU, so that the main and redundant CPU cores end up in a different state, then the hardware comparator will reset and reboot the system.
Another approach that has also been used is to have a 2nd separate supervisory CPU which checks the health of the first (often a different design from a different vendor). In this case, both the main CPU and the supervisor CPU get duplicated sensor inputs, with the main CPU streaming digital sensor data (e.g. throttle position, brake pedal pressure) to the supervisor. If the data stream stops, or doesn't match the physical inputs, then the supervisor CPU recognises a catastrophic malfunction of the main CPU and removes power from the main CPU as well as key actuators (fuel injectors, ignition, fuel pump, etc.) This came out in the legal case against toyota for unintended acceleration. A software specialist for the claimant argued that if the process controlling the throttle crashed, then the electronic throttle could remain open. Toyota pointed out that the throttle control process also echoed brake pedal data to the supervisory CPU. If it had crashed, the supervisor would have triggered emergency shutdown as soon as the brake pedal was touched.
Very interesting and certainly working in the software industry and with a family in the airline industry...faults are possible, which is why planes crash too!
One thing I would do is hook up a proper internal camera system, like a dashcam, in reverse, watching the dash itself and another watching the pedals. If anything this will give you confidence to drive, knowing any issue will be "caught on cam".
If anything (if it turns out to be a fault) you may save someone else's life.
If you see it was your mistake, you can fix it too!
Good luck
One thing I would do is hook up a proper internal camera system, like a dashcam, in reverse, watching the dash itself and another watching the pedals. If anything this will give you confidence to drive, knowing any issue will be "caught on cam".
If anything (if it turns out to be a fault) you may save someone else's life.
If you see it was your mistake, you can fix it too!
Good luck
Without a proper SW-level data trace it'll be nigh-on impossible to track down where the issue might lie, unless it's easily repeatable.
I've seen instances where entire teams of engineers can be led on a wild goose chase by one event in a voice of the customer fleet vehicle or otherwise. So many hypotheses, so many potential causes of failure and in the end with one event logged (but only verbatim testimony available) you just don't know where to go. Without data or repeatability, and with thousands of lines of code, and as Watchman states, very significant levels of redundancy you have to put it down to the soft squidgy thing in the driver-seat.
I would be asking for a powertrain module flashing to the latest software & calibration, and go for a new pedal box, then get on with my life.
I've seen instances where entire teams of engineers can be led on a wild goose chase by one event in a voice of the customer fleet vehicle or otherwise. So many hypotheses, so many potential causes of failure and in the end with one event logged (but only verbatim testimony available) you just don't know where to go. Without data or repeatability, and with thousands of lines of code, and as Watchman states, very significant levels of redundancy you have to put it down to the soft squidgy thing in the driver-seat.
I would be asking for a powertrain module flashing to the latest software & calibration, and go for a new pedal box, then get on with my life.
Gassing Station | General Gassing | Top of Page | What's New | My Stuff