> As an engineer, knowing how a lot of software and hardware systems are actually implemented, 6 seconds is such a minuscule time frame.

It's a geological amount of time to a real-time system, which anything related to controlling a car absolutely will be. "Multiple seconds of unpredictable latency are OK" is an attitude that doesn't get you far when interacting with the physical world, and that's why there is an entire discipline dedicated to dealing with it that has to use special chips (e.g. the ARM R series), special OSes (e.g. VxWorks), and special tools (special IDEs, oscilloscopes, special cameras) to rise to the occasion.

If they let a "latency doesn't matter" system near any of these data streams, that's the scandal.

> It's a geological amount of time to a real-time system, which anything related to controlling a car absolutely will be.

The logging service that writes it down isn't really critical to the operation of the car. Even the notification has a geological amount of time before it has to notify the driver when compared to many other systems that operate on a near self driving car. I wouldn't be surprised if less critical components shared a non realtime timeslot between the actual realtime tasks.

One would assume they know that this log information is critical to the operation of the whole company, and engineer the logging system with that in mind - otherwise they can hardly make any claims about what a car was or was not doing when issues like this crash occurred.

I do understand that, and that may be the case, but I don't think it will surprise anyone if there's a piece of nodejs somewhere handling something it shouldn't have, because someone just needed to ship. We don't know the quality of their code base and hardware or of all the code bases and hardware modules provided to them by 3rd parties.

I would be surprised if nodejs were anywhere near the real time, safety critical systems here. I'd also not buy a Tesla in that case.

I've seen so many pieces of safety-critical hardware BSOD at this point that I would not be at all surprised.

I don't think you know what actual safety-critical hardware is if you are running Windows or even Linux on it...

Well, obviously the maker of said hardware doesn't know what safety critical hardware means, but that doesn't mean it doesn't exist.

I've seen both IV pumps, ventilators, and MRI machines BSOD.

Which almost always happens because someone messed up their C or machine code, not because of using nodejs.

> Which almost always happens because someone messed up their C or machine code,

Or hardware failure, possibly injecting faults into the system. See Page 14: https://www.hq.nasa.gov/alsj/ApolloLMRadarTND6849.pdf

What does that have to do with nodejs?

If there is node.js component anywhere near the controls of my car, someone needs to be taken out back and taught a lesson.

Dude, this ain't a webapp. It's a car, our lives are in her hands.

> It's a geological amount of time to a real-time system, which anything related to controlling a car absolutely will be.

s/will be/should be/ -- defects in design notwithstanding. Note that the latency involved with the sensing equipment (skin conductivity? pressure sensor?) could be large enough to be significant.

You're making the assumption here that it's only recording when the hands are on the wheel. Presumably it also records when the hands are off the wheel. So if the crash happened at (to completely make up a timestamp) 13:24:01.123, and the latest log entry says at 13:24:01.108 the hands were off the wheel, that would be good reason to say that the driver did not have their hands on the wheel at the time of the crash.

Of course, I don't actually know what the logs look like, but I'd rather err on the side of assuming that the designers of a real-time system for monitoring something related to driver safety took into account the idea that, when the car is involved a severe crash, they should have as much accurate data recorded as possible rather than leaving it sitting around for ages in un-flushed caches.

A driver of a Tesla car has mentioned in this thread that the car sometimes doesn't register the hands on the wheel.

Sure, but I would expect the logs to have more information than just the boolean "are there hands?", e.g. maybe containing the actual sensor data that was used to determine if there were hands.

The car should be conservative about the threshold it uses for the sensors in determining if there are hands (because it would rather err on the side of telling someone to put their hands back on, than err on the side of thinking someone has their hands on when they don't), but engineers analyzing the logs after a crash wouldn't have to use that same threshold when trying to determine if the driver was in control of the car at the time of the crash.

It might not be 100%, but it is probably safe to assume that their hands weren't on the wheel because they went head first into a concrete wall.

That's anecdotal information.

And Tesla is claiming otherwise. The driver in this thread likely has nothing to gain or lose by saying that, other than maybe the resale value of his car might be hurt. Tesla has a lot of reasons to be deceptive here.

Plus, it's a pretty common complaint in Tesla forums.

On the other hand, this is effectively an admission by Tesla that there are serious problems with the autopilot system. It should never guide the car into a barrier, no matter where the driver's hands are.

I believe it. Do you?

With the note that Tesla's 'hands on wheel' detection is pretty flaky.

$DEITY help us all if murderous robots can absolve themselves of responsibility after 15 hundredths of a second.

> Data about hand position could be in a write cache somewhere waiting to be flushed, inside monitoring service, inside OS, inside RAID controller, inside storage controller, or even de-prioritized by a busy IO scheduler.

You are vastly overestimating things here.

Critical functionality in a car would rarely if ever involve non-deterministic delays. Furthermore, the OS itself (if there even is one) would be a real-time OS.

But even if we assume such delays are present in a Tesla steering wheel monitoring task, absolutely none of the delays you listed would approach anything near a second...

> Critical functionality in a car would rarely if ever involve non-deterministic delays. Furthermore, the OS itself (if there even is one) would be a real-time OS.

It might not be safety-design-critical to have a record of the hand-presence sensor with high resolution, merely high enough resolution for safe operation of the vehicle.

Flushing these records to storage is an independent function for the sake of service/support/maintenance and is likely not a regulatory requirement. Though regulatory agencies are bound to be interested in the data.

"This needs to be investigated properly and not just by Tesla, they are a biased party."

That may be why they were removed, there's an inherent conflict of interest when only Tesla engineers are able to decipher Tesla's crash data.

You and the other commenter that says the wheel sensor is finicky should somehow contact the investigators (AFAIU that's NTSB). These are really important possibilities that may never be discovered by them.