Near crash as Maserati Ghibli accelerates by its self…twice!
Discussion
stuart-b said:
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!
Totally unrelated, but you might find this interesting.https://youtu.be/_gZK0tW8EhQ
What have they said about this in the report?
Surely if it was driver error then you could replicate this fault code all day long by pressing both pedals at once? Or is that the case...
Surely if it was driver error then you could replicate this fault code all day long by pressing both pedals at once? Or is that the case...
Report said:
Diagnostic trouble code: 229900 - Brake Pedal Position/Accelerator Pedal Position Incompatible
Test Failed False
This Operation Cycle False
Pending DTC False
Confirmed DTC True
Test Not Completed Since Last Clear False
Test Failed Since Last Clear True
Test Not Completed This Operation Cycle True
Warning Indicator Requested False
Occurrence Flag Error
Original Odometer Value 1916.928 km
Most Recent Odometer Value 1982.464 km
Frequency Counter 5
Operation Cycle Counter 1
Vehicle Speed 77.114 Km/H
Test Failed False
This Operation Cycle False
Pending DTC False
Confirmed DTC True
Test Not Completed Since Last Clear False
Test Failed Since Last Clear True
Test Not Completed This Operation Cycle True
Warning Indicator Requested False
Occurrence Flag Error
Original Odometer Value 1916.928 km
Most Recent Odometer Value 1982.464 km
Frequency Counter 5
Operation Cycle Counter 1
Vehicle Speed 77.114 Km/H
hi pressing both pedals is the fault shown up, but in the incident both pedals were pressed when trying to get car under control the fault I believe happened before that and as that showed on car data Maserati are saying thats what it is...it did not show up the original fault or the flashing alert lights!
hi pressing both pedals is the fault shown up, but in the incident both pedals were pressed when trying to get car under control the fault I believe happened before that and as that showed on car data Maserati are saying thats what it is...it did not show up the original fault or the flashing alert lights!
Sounds pretty weird even more so that the ecu flags an error for multiple pedal application - that just seems a bit to convenient!
I see there was a historic recall but not for your vehicle, wonder if its related though
http://www.dft.gov.uk/vosa/apps/recalls/searches/e...
I can't believe it was shipped back to Maranello that's pretty crazy cost wise, I can't imagine they did that and then wouldn't go to the bother of fixing something if there was an issue!
I see there was a historic recall but not for your vehicle, wonder if its related though
http://www.dft.gov.uk/vosa/apps/recalls/searches/e...
I can't believe it was shipped back to Maranello that's pretty crazy cost wise, I can't imagine they did that and then wouldn't go to the bother of fixing something if there was an issue!
strath44 said:
Sounds pretty weird even more so that the ecu flags an error for multiple pedal application - that just seems a bit to convenient!
Does it? The OP says that's what he did ... it'd be weirder if it wasn't logged.strath44 said:
I can't believe it was shipped back to Maranello that's pretty crazy cost wise
It wasn't. Read the thread man! 
What's wrong with pressing both pedals at once? LFB is an established driving technique that many drivers choose to use. I personally don't do it that much, but that's just because I can't do it that well, but I can imagine more competent drivers than me would do it all the time, even on the public road.
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.
This is really interesting - thanks!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.
Waking this topic back up….
I have just purchased a Ghibli, only 50k miles, stunning condition etc etc.. driving along a tight side street yesterday, gently pressed the throttle, no foot on brake, left hand not on steering wheel near cruise control, all of a sudden, the exhaust growled, the car had gone WOT by itself! Rear end snaking, narrowly missing parked cars, hit the brake and thank god it killed off the revs.. momentarily after that, the throttle was lacking response but seconds later returned to normal.
Got home, scanned car, P2299-00 was recorded.
There are currently no floor mats in the car and the vehicle carpet does not catch the pedal in any way so it has nothing to do with the recall. Besides, even-if it was the carpet, that would not emit a fault code.
IMO This is a serious fault for a powerful car, I will now embark on getting to the bottom of it but I think it will be a software glitch.
I have just purchased a Ghibli, only 50k miles, stunning condition etc etc.. driving along a tight side street yesterday, gently pressed the throttle, no foot on brake, left hand not on steering wheel near cruise control, all of a sudden, the exhaust growled, the car had gone WOT by itself! Rear end snaking, narrowly missing parked cars, hit the brake and thank god it killed off the revs.. momentarily after that, the throttle was lacking response but seconds later returned to normal.
Got home, scanned car, P2299-00 was recorded.
There are currently no floor mats in the car and the vehicle carpet does not catch the pedal in any way so it has nothing to do with the recall. Besides, even-if it was the carpet, that would not emit a fault code.
IMO This is a serious fault for a powerful car, I will now embark on getting to the bottom of it but I think it will be a software glitch.
OLlOYDO said:
Waking this topic back up….
I have just purchased a Ghibli, only 50k miles, stunning condition etc etc.. driving along a tight side street yesterday, gently pressed the throttle, no foot on brake, left hand not on steering wheel near cruise control, all of a sudden, the exhaust growled, the car had gone WOT by itself! Rear end snaking, narrowly missing parked cars, hit the brake and thank god it killed off the revs.. momentarily after that, the throttle was lacking response but seconds later returned to normal.
Got home, scanned car, P2299-00 was recorded.
There are currently no floor mats in the car and the vehicle carpet does not catch the pedal in any way so it has nothing to do with the recall. Besides, even-if it was the carpet, that would not emit a fault code.
IMO This is a serious fault for a powerful car, I will now embark on getting to the bottom of it but I think it will be a software glitch.
There was a recall in 2016, your car had that implemented?I have just purchased a Ghibli, only 50k miles, stunning condition etc etc.. driving along a tight side street yesterday, gently pressed the throttle, no foot on brake, left hand not on steering wheel near cruise control, all of a sudden, the exhaust growled, the car had gone WOT by itself! Rear end snaking, narrowly missing parked cars, hit the brake and thank god it killed off the revs.. momentarily after that, the throttle was lacking response but seconds later returned to normal.
Got home, scanned car, P2299-00 was recorded.
There are currently no floor mats in the car and the vehicle carpet does not catch the pedal in any way so it has nothing to do with the recall. Besides, even-if it was the carpet, that would not emit a fault code.
IMO This is a serious fault for a powerful car, I will now embark on getting to the bottom of it but I think it will be a software glitch.
Gassing Station | General Gassing | Top of Page | What's New | My Stuff