Live data from Hacker News

Former Tesla Firmware Engineer Discusses the System

twitter.com

121–130 of 589 posts

Re: Former Tesla Firmware Engineer Discusses the System

#121
post #94

Earlier quoted context omitted.

Any substantiated argument why using Linux "is a huge accident waiting to happen"? Did you know that Linux can handle hard RT, if you use the right hardware (and maybe the right kernel/patches).?

I'm speculating that he does know. But with all the filters you added (right hardware, right patches etc.) you would be better off to add the right patch -Linux/+ Besides, if you follow Linux kernel development, you see that the effort is virtually never for real-time but for general purpose.

Any RTOS has the very same hardware restrictions, and often only works on a very small number of (certified/supported) platforms.

There is no reason per se to attribute any downsides onto these "filters".

Re: Former Tesla Firmware Engineer Discusses the System

#122

I used to work at SpaceX on the team that did a piece of software called "WarpDrive". It was a massive monolithic ASP.NET application, with large swaths done with ASP.NET WebForms and a slow frontier of ASP.NET MVC gradually growing when I was working there. This application was responsible for practically everything that ran the factory: inventory, supply chain management, cost analysis, etc. Elon is a big Windows f…

Given the many ASP.NET software packages that handle all the backoffice functions you've described, it sounds like they chose the right platform for that. Why would you want to run backoffice on Linux and then re-create all those wheels by hand in-house? Relying on the expertise of other companies for basic backoffice systems is actually recommended practice until you become big enough to actually need custom softwar…

Very little off-the-shelf software was in use. The whole thing was custom.

Re: Former Tesla Firmware Engineer Discusses the System

#123
post #62

Earlier quoted context omitted.

Yeah I don't even do embedded work or anything real-time and even I know that in applications like this you should probably be using something like Green Hills Integrity RTOS.

(no judgement) Given that you've never worked in the field, what makes you think that?

It has a long history of use in Aerospace and military applications.

Re: Former Tesla Firmware Engineer Discusses the System

#126
post #107

Earlier quoted context omitted.

Check out this, and the linked court transcripts linked therein: http://www.safetyresearch.net/blog/articles/toyota-unintende... The security researchers who were expert witnesses in the Toyota case and that analyzed Toyota's source code testified in court that they managed to reproduce the unintended acceleration with a real car on a dynamometer.

Is it what people call fake news nowadays? I once had a project with a major lobbying organisation with links throughout the automotive industry. The one that published regular reports on real vs declared emissions discrepancies long before the VW scandal. They were unanimous when asked about the unintended acceleration bug. It was a case of mass hysteria.

Is it possible that the timing on your contact with them made a difference? It seems that NASA/NHTSA concluded in 2011 that it was a mechanical defect, but research concluding in 2013 showed that it was totally possible to have been caused by the software.

At least according to the summary based on sources used for Wikipedia:

https://en.wikipedia.org/wiki/2009%E2%80%9311_Toyota_vehicle...

Re: Former Tesla Firmware Engineer Discusses the System

#127
post #80

Earlier quoted context omitted.

I don't understand how that could happen. MCU reboots, ???, brake system segfaults? What goes in the middle?

Probably everything has access to everything on the CAN bus. IIRC car manufactures are irresponsibly lazy and never properly air-gap infotainment from critical stuff.

Even if this were true (and as another commenter says, it's not) I don't see how that fills in this gap. It would make sense if the first step were "MCU goes crazy," but not with a simple reboot.

Re: Former Tesla Firmware Engineer Discusses the System

#128

I used to work at SpaceX on the team that did a piece of software called "WarpDrive". It was a massive monolithic ASP.NET application, with large swaths done with ASP.NET WebForms and a slow frontier of ASP.NET MVC gradually growing when I was working there. This application was responsible for practically everything that ran the factory: inventory, supply chain management, cost analysis, etc. Elon is a big Windows f…

What's wrong with ASP.NET? It might not be the most sexy framework out there, but it's great for this sort of thing - there's a huge business application ecosystem surrounding it.

Re: Former Tesla Firmware Engineer Discusses the System

#129
post #51

They've been going 100mph for years now. It doesn't come as a surprise to me that they haven't gone back and made it pretty. While not even remotely on the same scale, I just spent 3 weeks building an app as fast as possible because my client's old one was causing 75% of their support calls. The code isn't pretty, but it works and it works a lot better than the old one. I know deep down that code is going to stay ugl…

They are making vehicles, not apps.

I understand that.

I guess I was commenting more on the general messiness he was describing. I can empathize with it is all. I can see how quickly and easily it happens in the small apps I build, I can't imagine how hard it would be to reign it all in at Tesla scale at the pace they've been going.

Re: Former Tesla Firmware Engineer Discusses the System

#130

Earlier quoted context omitted.

Google's self-driving cars run a modified Ubuntu. Or did, last time they talked about it. https://www.youtube.com/watch?v=7Yd9Ij0INX0

I'm sure anything embedded is almost nothing like the pre-modified stock. The few paper I've read from embedded people is that they know how and will strip everything down until things are like they need.

"strip everything down" consists in removing packages, especially daemons, you don't need.

You don't (want to) make huge changes to the kernel and libraries codebase tho, even if the changes are meant to remove code you don't need, because testing a heavily modified OS gets prohibitively expensive.

Especially on "modern" embedded from the last 10 years were RAM and storage are not that limited.

Post reply on HN