16 comments

[ 0.24 ms ] story [ 50.4 ms ] thread
$TSLAQ will control the conversation here but I'll put the official response, according to Chinese media, anyway -

  In response to the incident, Tesla officially responded 

  It can be seen from the existing accident video that the brake lights have not been lit for a long time during the high-speed 
  driving of the vehicle. This is consistent with the situation reflected in the background data:

  1) The vehicle switch has been deeply pressed for a long time, and once maintained 100%;
  2) There is no action to step on the brake throughout the process;
  3) During driving, the driver briefly presses the P gear button four times, and then quickly releases it, and the brake light also quickly turns on and off.
The 13 cameras with video of the incident was the actual scary thing here, you can at least buy floor mats that don't get stuck to control the accident part of the story.
The video is terrifying, I never understood why cars are able to go so much over the speed limit instead of being hardware limited to ~150kph in the first place

Having 500+ hp in a software limited car than can all of a sudden decide to go pedal to the metal is pure insanity

What would a hardware limit even look like in an electric car? A centrifugal governor on the axle that physically interrupts a kiloamp-scale conductor? A clock comparator between a Hall sensor on the wheel and a calibrated oscillator that keeps a contactor closed when the former is slower than the latter? These seem like heavy, error-prone systems that add more failure modes than they remove, compared to just having a software limit...
> What would a hardware limit even look like in an electric car?

A properly sized motor ? My electric scooter can't reach 200kph, even without the 25kph software throttle

A motor sized to be have a maximum speed of, say, 100 mph means by definition that the power the motor can send to the wheels at 100 mph exactly equals the power lost to drag etc. by the vehicle at 100 mph (under the design conditions, presumedly dry flat road). Which means that the time to accelerate to 100 mph is infinite; and, more importantly, the time to accelerate from 70 mph to 80 mph is going to be ridiculously long. In other words, a vehicle that is power-limited to a "reasonable" speed is unsafe for normal highway driving because of insufficient acceleration to pass and avoid hazards. There's a reason that even a modern econobox can easily exceed reasonable speed. If you want to limit speed, you have to do it based on (wheel) rpm, not based on power.
Still, do you need to do 0-60 on 2.9s in your 3 tonnes tesla ?

There is a whole spectrum between 0-100 in an "infinite time" and 0-100 faster than a supersport car of the 90s

> can all of a sudden decide to go pedal to the metal

Perhaps we should focus on this root cause? Why is the car even capable of this in the first place?

Maybe we should consider removing software from certain areas of automobiles. More is definitely not making things any safer.

Hydraulics and cable linkages are extremely robust. Even if the throttle on your 90s car gets stuck wide open, it would be trivial to pop the vehicle into neutral. A modern vehicle with the digital gear selector will give you a much more likely issue for such a bold action, especially if the computer is already misbehaving per acceleration.

The steering wheels aren't even real anymore. What would stop a gamma ray from glitching my steering program full left turn while driving at 80mph on the freeway? How much of our safety do we really need to make the computer responsible for?

> What would stop a gamma ray from glitching my steering program full left turn while driving at 80mph on the freeway?

The processor running this (ASIL D) software almost certainly has hardware mitigations for SEUs. The most common such mitigation is lockstep cores (see e.g. TI Hercules, Infineon Aurix) where the same computation is run through two copies of the core (usually physically displaced and rotated to reduce common cause errors), and the output cross-checked between the two. Handling a mismatch has various approaches, ranging from pure hardware (three lockstep cores with voting) to pure software (on detected SEU issue a reset and try again) to pure analysis (show that failing to issue a steering command in this time slice has no safety impact as long as a correct one is issued in the next time slice), with many middle grounds.

Different techniques to deal with gamma rays and other scenarios: every variable is stored in two places, the second is the complement value; plausability tests, can the value jump from 10 to 1000 in 10ms? and so on.

Source: me

And if something directly impacts the mosfet gate drivers, what then? Is there some sort of N+1 strategy all the way up to the mechanical steering linkage?
Yes. Every system is evaluated from a safety perspective and measures are taken. What's interesting is that N+1 redundancy is seldom used. Usualy there is a totaly different system that checks the main system. Like a software watchdog that checks a hardware one. This is also why they need 5 years to get out a model that is more or less the previous model. That and they really don't get software.
> Tesla China, for its part, has denied the driver’s claims that the vehicle’s brakes were unresponsive during the incident. According to the electric vehicle maker, data from the ill-fated Model Y showed that the vehicle’s accelerator pedal was depressed deeply for an extended period of time, even reaching 100% at one point. Tesla China also noted that the driver did not press the brakes during the incident.

https://www.teslarati.com/tesla-fatal-model-y-crash-china-re...

When I hear stories like this I'm reminded of my own similar experience in the 90s.

I was the passenger in a light truck (late 80s Toyota) with my friend driving in moderate freeway traffic. At the time we were moving around 30mph. I had a clear view of the pedals as the cabin was relatively sparse.

He suddenly accelerates then starts pumping the accelerator. The motion surprised me which caused me to look at his foot pumping the accelerator. I could hear the engine revving and feel the car lurch each time while also thinking we're going to hit the car in front of us if he doesn't stop.

After the 4th or 5th pump, his foot hits the brake. Just inches from the car in front of us, he turns to me and said, "The brake was stuck and wasn't working." I told him that he was actually stomping on the accelerator pedal the whole time.

He didn't believe me.

I am not trying to create a conspiracy theory here, but how difficult would it be to 1) sabotage an EV like Tesla to behave this way, and 2) for that sabotage to not be detected via monitoring how the vehicle does, and 3) could it or would it need to be done through physical alteration and/or software?
The video is bizarre: https://m.youtube.com/watch?v=3lTm3sMHZNE

It could have been a human error, but it seems that he did use the brake right before the car accelerated, so if he did mix up pedals, it was after he successfully slowed down to park. On the hand, regen braking can slow the car enough that you have to use the brake much less. This can also explain the stop lights turning on, iirc a full release of acceleration does that almost certainly. It is harder to believe that he was pushing the wrong pedal for that long.

If it is a pedal mixup, it could have happened with automatic transmission, except rate of acceleration us much slower. If so, we should have seen a similar cases when it took this long for a driver to notice they pressed the wrong pedal.

What a nightmare. I would never own a Tesla even if I get it for free.