Earlier quoted context omitted.
If the infotainment system caused the MCUs to reboot while someone traveling "130mph on San Mateo Bridge" and that caused the break system to segfault due to unconventional way of loading parts firmware, it might be a life&death situation, easily. Examples in that threads go on, literally hundreds!
I don't understand how that could happen. MCU reboots, ???, brake system segfaults? What goes in the middle?
Former Tesla Firmware Engineer Discusses the System
201–210 of 589 posts
Re: Former Tesla Firmware Engineer Discusses the System
#202It's so weird to see the same bizarre hacky nonsense I would cobble together being used to run cars.
Re: Former Tesla Firmware Engineer Discusses the System
#203I really don't think tesla is the 'worse offender' when it comes to the type of horror stories we read in this article.
Re: Former Tesla Firmware Engineer Discusses the System
#204Earlier quoted context omitted.
Tesla’s infotainment and IT infrastructure is unrelated to their safety. If this guy worked on motor control or braking system firmware then that would be scary, but he didn’t.
If the infotainment system caused the MCUs to reboot while someone traveling "130mph on San Mateo Bridge" and that caused the break system to segfault due to unconventional way of loading parts firmware, it might be a life&death situation, easily. Examples in that threads go on, literally hundreds!
Source: Done this a few times to clear bad map data or occasional glitch.
Re: Former Tesla Firmware Engineer Discusses the System
#205Why is this interesting or surprising? Of course almost all challengers have hacky tech under the hood because they don't have the resources. Winning from that position is possible not because of generally better tech but by delivering something that the incumbents don't. Remember the demo of the first iPhone (vs the huge expertise of Nokia). Or how Microsoft won the desktop starting from a single user, cooperative m…
a) interesting, because it shows how other companies solve (or fail to solve) specific common problems.
b) surprising, because I thought they'd be much better at it.
Car infotainment is generally not categorized as safety-critical and can be quite similar to regular software development. Having remote access changes things: I always thought their security must be top notch if they had the confidence to launch that. Ssh-ing and deleting files sounds like the opposite of that.
Btw, saying that doing things properly increases risk must be the biggest load of nonsense I have ever seen on HN.
Re: Former Tesla Firmware Engineer Discusses the System
#206Why is this interesting or surprising? Of course almost all challengers have hacky tech under the hood because they don't have the resources. Winning from that position is possible not because of generally better tech but by delivering something that the incumbents don't. Remember the demo of the first iPhone (vs the huge expertise of Nokia). Or how Microsoft won the desktop starting from a single user, cooperative m…
These are cars first and foremost. They should not be given a hand waive over "break things and move fast".
Re: Former Tesla Firmware Engineer Discusses the System
#207Earlier quoted context omitted.
Cars weigh thousands of pounds and routinely drive upwards of 60 miles per hour. The success of the first iPhone or Facebook app didn't depend on using it to navigate through life-and-death situations not only for the users but also for everyone around them. There are places for 'move fast and break things'. But cars move fast already, and they can really break things.
The iPhone has to reliably connect for emergency calls and provide accurate location. That can be life or death. In fact, "Apple isn't ready to engineer phones at a life-or-death standard" was a fairly common critique of the iPhone in the early days. In response, Apple ran a little PR campaign around their radio engineering efforts--they had a web page that showed all the cool-looking rooms for testing radios, which…
An iPhone handling an emergency call is an exceptional use case.
A car driving is not an exceptional use case for a car.
A life and death scenario is occurs every few minutes, or continuously for something like a mountain road, if something like brakes, limited throttle, or steering were to fail.
But, I would, naively, assume that the operation of these critical components were in no way related to timing requirements of some process in Linux.
Re: Former Tesla Firmware Engineer Discusses the System
#208Content aside, what is the deal with images of screenshots of a forum, then posted to Twitter? Why not include a fax machine in there while you’re at it? Just link to the forum and we can all read the text.
Re: Former Tesla Firmware Engineer Discusses the System
#209Earlier quoted context omitted.
Agree completely. Hard real time is possible with Linux, we use it for sub millisecond control of Traffic Lights. The only issue we ever hit is proving that the code running is the stuff we expected to run.
> we use it for sub millisecond control of Traffic Lights Why would anyone need "sub millisecond control of Traffic Lights"? Traffic lights are mission critical systems, of course, but even millisecond precision should be more than enough, and possibly even 0.5x-1 second precision...
Re: Former Tesla Firmware Engineer Discusses the System
#210Earlier quoted context omitted.
When autocorrect meets "buttock-clenching", I'd guess.
You are correct sir or madam! I’m leaving it though, I like the sound of it.
Autocorrect didn’t enter my mind as a possibility.