Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Former Tesla Firmware Engineer Discusses the System

twitter.com

Post reply on HN
Print view View original

281–290 of 589 posts

Re: Former Tesla Firmware Engineer Discusses the System

#281

Post by yitchelle »

8_hours_ago wrote: post #174
BugsJustFindMe wrote: post #74

Earlier quoted context omitted.

As a person who used to write navigation and control software for autonomous vehicles who occasionally gets downvoted for telling people that you really don't need a fancy RTOS for this stuff, you really don't need a fancy RTOS for this stuff. Linux is a very common platform for highly responsive robotic systems. I promise that their pid control isn't an Electron app.

Automotive ADAS systems generally require ASIL-D certification, which is much easier with an RTOS than Linux. I don't have much experience with real-time embedded Linux, but my understanding is that it is very difficult or impossible to certify to ASIL-D. Can someone correct me?

A RTOS helps because the vendor will usually provide the RTOS already certified for ASIL-D application. The rest of the software components will also need to reach ASIL-D, but getting the RTOS to ASIL-D makes things a little bit easier.

Re: Former Tesla Firmware Engineer Discusses the System

#282

Post by dwpdwpdwpdwpdwp »

starkruzr wrote: post #66
8_hours_ago wrote: post #52

Earlier quoted context omitted.

> the rockets fly with a heavily customized Linux install My jaw hit the floor the first time I heard this. Why Linux instead of an RTOS?? Apparently Tesla's autopilot also runs Linux, which seems like a huge accident waiting to happen (pun intended).

I've worked on RT Linux before. Works fine.

Ditto. The Xenomai Linux co-kernel does too. Handy for CAN/etherCAT controllers

Re: Former Tesla Firmware Engineer Discusses the System

#283

Post by yitchelle »

blub wrote: post #173
shittyadmin wrote: post #145

Earlier quoted context omitted.

Not just that but holy shit some of those commercial RTOSes have major issues. I work in aerospace and we recently used one where the whole system would crash after ~230 days of uptime. At least with Linux you're getting a system that's been used so much that all major issues like that are ironed out. Nothing beats a few million testers.

Ubuntu Linux has millions of testers, your custom version has only been tested by you and your customers :)

Hmm, doubt that there are millions of folks testing Ubuntu controlling a car.

Re: Former Tesla Firmware Engineer Discusses the System

#284

Post by pwinnski »

Twirrim wrote: post #58
liber8 wrote: post #31

Earlier quoted context omitted.

Not sure if you're being sarcastic or not, but the Toyota issues were not caused by any software bug. Most cases were caused by people hitting the wrong pedal. The others were caused by floor mats that were a bit too long, causing the gas pedal to stick. https://www.caranddriver.com/features/its-all-your-fault-the...

Regardless of whether the acceleration were caused by the software or not, the testimonies for the software experts called in to review Toyota's source code for the case were eye-popping: http://www.safetyresearch.net/blog/articles/toyota-unintende... > Skid marks notwithstanding, two of the plaintiffs’ software experts, Phillip Koopman, and Michael Barr, provided fascinating insights into the myriad problems with To…

People quote this repeatedly here, but I'm not sure what it's intended to demonstrate.

Most code is buggy, and the more closely you look, the buggier it is. Most of that same code operates without noticeable error.

That code analysis turns up "inadequate protections against stack overflow and buffer overflow" does not actually suggest that there was any stack overflow or buffer overflow, and people quote this as if it does.

Meanwhile, it is all-but-certain that the overall findings were correct: people hit the wrong pedal regularly, and if enough press attention is given, all of those wrong-pedal-pushers find each other and try to blame the manufacturer instead.

You started with "Regardless of whether the acceleration were caused by the software or not," but I think that's the important thing, and that software is buggy should surprise nobody.

Re: Former Tesla Firmware Engineer Discusses the System

#285

Post by eequah9L »

intern4tional wrote: post #135
eequah9L wrote: post #88

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.

The linked trial testimony says otherwise. The engineer states he found bugs, and theoretically it might be possible he was unable to reproduce. Further, he evaluated the software against his own coding standard which was a variant of another. The engineer was questioned: " Q. Now, you have not reproduced in vehicle testing your 25 theory that there's a software bug that opens the THIS TRANSCRIPT IS NOT PROOFREAD 30…

I'm rereading, and I think you are right. I misremembered.

Re: Former Tesla Firmware Engineer Discusses the System

#288

Post by gamblor956 »

dfox wrote: post #214
gamblor956 wrote: post #160

Earlier quoted context omitted.

Custom as in customized Oracle/SAP, or custom as in from-the-ground up custom? The former is generally a given for a company of any significant size (employees or business activity). The latter is unheard of for most backoffice functions (other than specialized accounting and finance functions) since it's a waste of money and would place the company at significant legal and regulatory risks--it would require effectiv…

In my opinion once you start to need heavy customization in off-the-shelf ERP solution (ie. because you do not fit in the vertical that the system is designed for) you are generally better-off writing the whole thing in house. And if you want to do it as web application then ASP.net with WebForms is one of the more productive approaches to that problem.

As someone who now works in the "backoffice" I would say that building backoffice solutions from scratch is the height of hubris if your primary business doesn't involve those backoffice functions. There's a million small things on the compliance side that need to be addressed, and which the incumbents know about and already handle.

This applies even if you need heavy customization. In fact, it applies even more--since that level of customization usually means sufficient complexity of backoffice needs that only the pre-built service providers will have the sufficient depth and scope to cover you.

Re: Former Tesla Firmware Engineer Discusses the System

#289

Post by strlen »

UK-Al05 wrote: post #179
gamblor956 wrote: post #160

Earlier quoted context omitted.

Custom as in customized Oracle/SAP, or custom as in from-the-ground up custom? The former is generally a given for a company of any significant size (employees or business activity). The latter is unheard of for most backoffice functions (other than specialized accounting and finance functions) since it's a waste of money and would place the company at significant legal and regulatory risks--it would require effectiv…

There isn't actually that many sap/oracle like packages in .net Even dynamics isn't .net

There seems to be a misconception that enterprises (specifically ones where software is not considered a product) means Java and .NET with frameworks. Reality is that is this just the tip of an iceberg: a bank, a hotel chain, etc... might use Java or .NET for web applications yet great deal runs on proprietary software. Much of that software either runs on machines that are still sold and marketed as mainframes or if on commodity hardware (which nowadays offers plenty of vertical scalability in terms of memory and total number of CPU cores) coming from a mainframe lineage.

It seems as if there were two distinct cultures of engineers. Those working on workstation-grade hardware networked over TCP/IP (whether running proprietary UNIX, open source UNIX, or Windows NT) -- and Java emerged out of this.

The second cultures were developers building mainframe applications; usually they would be ones working on problems related data processing, planning, and automation for businesses (not just enterprises but also many SMBs, government organizations, hospitals, etc...)

Java clearly emerged from the first culture being built by a vendor of networked UNIX workstations. Some of Java's most memorable failures - either exceedingly complex and brittle systems like RMI, JMS, and J2EE (I mean this literally: not modern Java EE like Jersey/CDI/etc... but EJB 2.0) or features that were in retrospect far ahead of its time (JINI or JXTA, compare with consul/etcd/zookeeper and the idea of a service mesh today) came as an attempt to commoditise approaches commonly used by the first group as frameworks for solving the domain specific problems of the second.

Re: Former Tesla Firmware Engineer Discusses the System

#290

Post by h4b4n3r0 »

devy wrote: post #64
mikeash wrote: post #20

Earlier 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!

There’s no concept of “reboot” with MCUs, since there’s usually no OS. Likewise there’s usually no concept of segfault, because segfault requires memory protection which is something most MCUs don’t use.
Post reply on HN