Former Tesla Firmware Engineer Discusses the System
twitter.com
twitter.com
The tech and products were complex. The turnover rate was high and training new hires was a lengthy process. The new projects coming down the pipeline never ceased (this was during a period where FH/F9-1.1/Dragon/Crew was all under design/development and constant iteration).
It was fun for a young engineer, but burnout is real.
*WarpDrive was actually pretty impressive given the amount of stuff that it did.
"We're paying more for programmers than almost anyone else in the industry!" is an obvious thing a bean counter would notice and point out. Productivity is harder to measure, and all that time lost to training on the job doesn't immediately leap out in spreadsheets because it's blended with actual work.
Well they landed a rocket on a barge in the ocean so something about that model must be working right
Agree about WarpDrive being pretty amazing for all the stuff it did. Although amazing things tend to just clump up from all the features that you need, and you end up with an app that is hard to manage.
It wasn't all bad. There were other groups at X that provided pretty amazing tools for people to get things done (thanks, @cbanek and friends!)
Soon after he was ousted and Thiel was made CEO. Interesting to see he's still pushing Windows.
Source: Paypal Wars by Eric Jackson
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).
These things frighten me everyday. What frightens me even more, is the people who work on autonomy without a real grasp on determinism. It's unfortunate that the people who have the most high tech backgrounds (phds in computer vision AI, etc) applicable to autonomy, have never implemented safety critical autonomous systems outside of a research project that tested some aspect of detection or control in a test environment and had to only work once to get a paper published.
For general robotics linux is great. But there is an enormous difference between a robot roaming around your house bumping off walls, and a vehicle carrying a whole family at 70mph.
Most of the linux based systems I have worked with have some form of redundancy, whether it be other chips running linux, or ideally ECU's running an RTOS that perform monitoring, gating, and/or some level of safety fallback control. The RTOS based redundancies often are what provide ASILD. Trusting a single linux processor is what everyone does to get funding, but when you go out and test on public roads with human lives at stake, or start selling a product, you better have some quantitative guarantees other than "It's been fine so far..." That kind of stuff makes me angry.
I’ve seen the same pattern a few other times. Slow, hand built, rad hard systems CAN be more stable and demonstratively safer... but that is rarely the case and the effort required to get such a system right is orders of magnitude greater than using standard “undeterministic” systems. That engineering effort can be better spent innovating and building fundamentally more advanced solutions.
Just my experience. Just my opinion
I haven't messed with an RTOS before but have done some fooling around with scheduling on microcontrollers and I can see why linux is tempting for ease and speed. But we're talking rockets and self-driving cars. These things are expensive as hell, can easily kill people, or both. It seems like the exact sort of place you'd want to take the time and effort to be sure.
0. which infamously occurred on the Mars Pathfinder. https://www.rapitasystems.com/blog/what-really-happened-to-t...
maybe you don't, but genuinely curious how do you validate/guarantee scenarios then?
Given all the wtf stuff in TFA, it might very well be...
Same reason SpaceX eschews radiation-hardened processors for redundant off-the-shelf cores: supplier competition. There aren't many RTOS engineers on the market; there are many Linux engineers. Once they got over the cost of hardening the kernel, SpaceX found itself at a scaling advantage versus RTOS-based competitors.
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.
There aren't many Linux engineers who have experience with resource-constrained systems or real-time programming requirements.
A devil-may-care throw-caution-to-the-wind cavalier attitude?
>supplier competition
I stand corrected. And I'm never buying a Tesla or property even remotely close to SpaceX launch sites...
Not to worry, the tight control loops the require determinism all run on Arduino boards.
Did you know that Linux can handle hard RT, if you use the right hardware (and maybe the right kernel/patches).?
So yes, I'm sure that Linux can work. But it will be difficult to prove to auditors that it will always work.
Besides, if you follow Linux kernel development, you see that the effort is virtually never for real-time but for general purpose.
Does TFA (which sure, is for Tesla, but same leadership) describe an environment where people use "the right hardware"?
Regardless. There are many and far better alternatives to Linux for real time applications.
An RTOS has nice guarantees, and I definitely see the appeal, but on the other hand:
- SpaceX machines receive more irradiation that computers on the ground, so computation errors already make the behaviour of the software chaotic,
- The wealth of complex, widespread libraries helps a lot.
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 software (generally, north ten thousand employees).
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 effectively becoming experts in accounting, HR, etc.
(1) Stable platform that's backward compatible over long periods of time.
(2) Very good rapid application development tooling, e.g. Visual Studio which is probably still the best IDE overall.
(3) A huge trained developer base making it easy to recruit. Same goes for IT personnel.
(4) A huge pool of software, custom dev firms, etc.
(5) Certification for US DOD and other certification-heavy environments where Windows is used heavily, which may be important for an aerospace company.
(6) Integration with everything in the business and government world is already done.
(7) Windows has a lot of complex user, permission, and policy management stuff. Active Directory is The Standard for UAM in the corporate world.
The cost of Microsoft licensing is chicken feed compared to the cost of building and launching rockets.
Overall I don't think it's a bad decision. Not everything is an Internet startup or hacker project. Right tools for the job.
I've always wondered why there's such a small list of decent IDEs for C anything.
I usually just stick to vim and a handful of plugins.
They could have bought something off the shelf. Not sure what was the value in building everything from scratch
What I don't understand is why the UI sucks so very, very much every single time. And why it's so very, very slow. It seems like it has to be on purpose. Can anyone with insight explain it to me?
wow - this is surprising to me and wasnt mentioned in the biography - any ideas why ?
https://www.amazon.com/Founders-Work-Stories-Startups-Early/...
That's good to know. When I saw the inside of the Dragon capsule, with its shiny touch controls, I was already imagining Astronauts having to deal with installing Android updates on their control tablets while mid-flight, or some other crazy stuff along those lines.
I find C# and .NET runtime (before it meets windows) quite nice. I'm not a big C#-er myself though.
What OS kernels are actually used that are written in anything other than C? Plenty of them (INTEGRITY, VxWorks, QNX) written in C are used in secure, mission-critical applications.
A language is a tool, and like any tool it can be badly designed and/or unfit for certain purposes.
And this is why Torvalds takes kernel API stability seriously...
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 multitasking system (vs all the sophisticated Unix-based systems). Or Facebook running on despised MySQL and PHP.
These hacks are part of the strategy. It's risky but probably doing these 'properly' would increase the risk even more.
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.
Every organization has these types of things internally. As an engineer, I don't like it, but it's a fact of life.
Source - https://www.businessinsider.com/tesla-hit-model-3-target-by-...
We're at the point in the Tesla story similar to that of 2008 where Dr. Berry et el were watching the housing market collapse around them and the banks wouldn't re-price the swaps. Tesla is already bankrupt, most people don't know this yet. But they will.
It's not like those matter. The bank itself guarantees the integrity of your account and can reverse charges. And of course would be insured for such losses.
Being killed by a car, otoh, is more permanent.
Can you imagine a zero day being found in Windows with Windows Update being down?
2. Apparently people can ssh into the infotainment system.
1 + 2 => someone hacks into the infotainment system and flashes a safety-critical ECU. I guess/hope there's some protection in place to prevent that.
Only if it's deliberately isolated in the vehicle. It should be. Aaaand, it isn't: the firmware upgrades to all other car computing elements go through it.
Because drivers can't get distracted and crash because of a failure in the infotainment and IT infrastructure?
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.
Clearly when we "verify" Waymo or Tesla auto-pilot, we're going to want to use that stuff, right? Surely they won't just provide insurers with some data about the billions of miles they've driven without accidents and how humans can only drive like a million miles without an accident and try to get the insurers to give them policies...
Just like when we hand out licenses, we always check to make sure the 16 year old took some formal driving classes from professional driving instructors... I wish things were better but we don't care about this stuff as a society until much later usually. When did the car first appear? When did the first seatbelt law appear?
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.
Bosch supplies VW (includes Audi, Seat, Skoda, ...) and various other large incumbents, as one of the biggest car manufacturer supplier. Why do people think they are considerably better off? Their practices are often equally ridiculous and dangerous.
As a rat in that cage you do whatever you need to make things work.
https://www.caranddriver.com/features/its-all-your-fault-the...
First, we're talking about a multi-billion dollar company here (they've raised ~ 15 B), not some small "challenger".
Second, your example is the iPhone and Facebook. Those don't have the potential to kill their owners or run over people.
We can't have them be both challenger in that sense, and accept that challenger in their case means multi-billions.
Challenger or not, $15 B doesn't explain a totally crappy software engineering process and result even if its just for the infotainment system.
All of the what? The only competition on the desktop when Microsoft won was QDOS.
Musk fan or not, you can't deny this has no interest
For every good success example, there is a good failure example.
My point is that for every good example of a success story (about startups in this case), there's a good story of a failure. And the failures are much more than the successes. If you want to discount the failures because they don't fit your narrative, then you should equally oppose the successes when they don't fit your narrative.
TL;DR my post is a reply to a post and should be seen in that context. You've taken my post out of context; please don't do that.
Moreover, I recently read the book Bad Blood and I found it interesting to get an inside look at a startup who present themselves better than they actually are. I don't believe that part of the Theranos debacle is so uncommon. The severity and unique market though, are. And, that's actually underlined by the Twitter thread (the pictures). Another similarity is the massive quitting and burnout of quality personal, the fear of being fired and standing up, low morale. Those are, IMO, interesting similarities.
>The iPhone could play a section of a song or a video, but it couldn’t play an entire clip reliably without crashing. It worked fine if you sent an e-mail and then surfed the Web. If you did those things in reverse, however, it might not. Hours of trial and error had helped the iPhone team develop what engineers called “the golden path,” a specific set of tasks, performed in a specific way and order, that made the phone look as if it worked.
>They had AT&T, the iPhone’s wireless carrier, bring in a portable cell tower, so they knew reception would be strong. Then, with Jobs’s approval, they preprogrammed the phone’s display to always show five bars of signal strength regardless of its true strength.
>None of these kludges fixed the iPhone’s biggest problem: it often ran out of memory and had to be restarted if made to do more than a handful of tasks at a time. Jobs had a number of demo units onstage with him to manage this problem. If memory ran low on one, he would switch to another while the first was restarted. But given how many demos Jobs planned, Grignon worried that there were far too many potential points of failure.
Tesla has a larger market cap than Ford, GM, or Honda.
Having both would be nice, of course.
Do you not have bluetooth, satellite, or LTE in your car?
This poster seems to think well of the QA team they had. However,
It doesn't matter how great your QA team is, if the quality isn't in the system the QA team can't put it there. All they can do is tell you that you're making poor quality products, and attempt to inform management (as QA rarely has real authority) who should then act on that and work to improve the system. If quality isn't part of the corporate ethos, then they (QA) will make little difference in the end.
By inform, I don't mean "rat out". I mean, management has to have a learning objective. To understand the system that they're managing (because no one understands it fully, their mental model is different than what's actually happening). QA, along with other sources, inform the model of management who can then work with teams to improve the overall system.
This is the core of the TQM/Six Sigma theory
You will always have some product that needs to be reworked or rejected. The goal is to ensure quality at every stage in order to reduce the amount of rework. You don't want to go the way of the old US car companies who had to suffer major setbacks in the market because they were spending gross amounts of time reworking defective cars before they could ship them. I do not have a copy of it in front of me, but one of Womack's books had some numbers. Double digit percentage of time for a car's production was spent reworking the car after it had been made to make it suitable for sale.
Now, a premise of Agile (and Lean) is to improve the feedback loop. This is where testing and other inspections come into play. By doing them more often (run unit tests on check in, reject if any formerly passing tests start failing, for instance) you can address some quality concerns earlier.
But you still have to address the cause of the rejections. If Stage 10 of production consistently requires rework, it's great that you're catching, addressing, and doing the rework right then. At least it's better than after Stage 20. But management has to work with QA to not just inspect and accept/reject, they have to address the systemic causes of the failure.
can you as an owner delay updates?
I have a Model 3 and so far haven't had any problems with updates. Installed the most recent one (2018.32.2) last night.
"... caused almost the entire fleet to reboot loop ..."
I am not interested in being part of someone's fleet. The fact that they use this language at all to describe an end-user who has purchased an automobile suggests that their expectations and my own - of what it means to purchase and operate a car - are in deeply (possibly dangerously) mis-aligned.
Source: Father worked in car industry. All of my neighbors, too. Pretty much everyone I knew and then, eventually, me... albeit tangentially.
I am aware of that and I hear that terminology used by rental car companies and equipment dealers, etc.
My objection is to what I hear as a subtle difference - the post-sale automobile to a private, end-user is still referred to as belonging to their fleet - as if one's ownership and use of the car were a minor detail.
I dislike this subtle shift in language and attitude.
It's the language used by the rest of the industry including manufacturers, not just private owners.
So, if you have a car manufactured any time in the last 25 years, you're running software that hasn't likely been patched in years, has a ton of unknown defects and bugs, and might kill you if you hit an edge case that wasn't tested before it was shipped to you.
I much prefer Tesla's ability to fix software defects remotely than driving a defective piece of software. For example, I had a 2009 Hyundai Genesis that worked great until I had about 75,000 miles on it, then it mysteriously started losing engine power and I had the entire computer reboot a couple times while I was driving. Imagine your entire instrument cluster going dark and losing engine, braking, and steering power while you're traveling 75 mph on the freeway. The Hyundai dealership said the only way I could get a software/firmware upgrade was by purchasing a $500 maps DVD and having them update my system manually, which takes several hours, for which I'd have to pay one of their trained technicians to do it. Fuck them.
I vowed after that to never buy a car again that can't receive OTA updates. Would you buy a smart phone that can never get security fixes or updates? Given the tech in our cars now, why would you buy a car that wouldn't either?
So what do I do instead? I mostly cycle and ride where motorists don't drive and set the largest possible safety margins. I recognise this is not immediately practical for everyone but I'm fortunately set up in the right place with the right knowledge to achieve this.
So far this year, I've been in a car four times, a train twice and a plane twice. Musk is pushing for a world where everyone is dependent upon a form of low-occupancy heavy motorised transportation (including wanting to reinvent the train). Naturally, I recoil at this and so should more. More cars will never save the world.
> ol' musky isn't totally paranoid - we did catch bad actors doing stuff and they were nailed to the wall. finding a real apt in your network can be some next level shit
That looks like confirmation that there really were internal threats found as claimed by Elon.
[1]: https://forums.somethingawful.com/showthread.php?threadid=38...
Elon likes to push that narrative that there's this epic battle between himself and people with short positions in a good vs. evil way.
In fact, it seems pretty apparent that the company is in trouble and the people saying that have put their money where their mouth is. They also probably aren't obsessing over it every last minute or pushing narratives to try to get the stock to tank, it'll do that on it's own. In fact, I bet the majority of people who are holding tesla shorts aren't sneaky oil execs, but hedge fund guys who want a pickup/hedge for the market as a whole. It's pretty common to short stocks that look weak to protect against general market volatility for when your main portfolio takes a little dip
The conspiracies and the cult of personality surrounding a company in moderate financial trouble with problems delivering their product is pretty strange to me. Startups fail all the time, they also over promise and under deliver all the time.
There haven't been any real claims of people trying to influence the tesla stock price other than Elon. If he has this kind of info, he should send it to the SEC since they should be able to track down the nefarious bastards that hold a short position.
This is one of those situations that is probably exactly what it looks like. Elon is learning that hardware is much tougher to build than software.
My point was only that when there's a lot of money on the line, we should be skeptical of uncorroborated info (good or bad).
My personal expectation that it's all true is about 60% right now. Some of the figures could be exaggerated or misremembered, but most of the hackiness described is plausible.
> As a long-ago ex-Googler I find it amusing to watch employees name-drop where they work, always with some underlying subtext implying authority [...] Parent comment doesn't simply imply this but explicitly uses it as the basis for calling OP out. It's amusing because the namedrop is always accompanied by some claim they felt they couldn't support solely through a sound argument.
https://www.sitebuilderreport.com/blog/the-story-of-elon-mus...
I am short TSLA, make of that what you will.
USENIX talk from VP of software at SpaceX (2016)
https://www.usenix.org/conference/lisa16/conference-program/...
(Speaker was concurrently interim VP of Autopilot at Tesla for a bit as well)
Few interesting bits:
- Speaker’s background is SRE at Google
- Engineering culture: Authority, autonomy, accountability. Blameless postmortems
- High Integrity C++ & MISRA coding standards
- The spacecraft has multiple onboard computers, all running Linux
- Tripe String Architecture, 3 redundant computers, whose results are cross checked with majority voting before being applied in real time, given radiation tolerant over radiation hardened hardware
Left as a reference, citation. Mods: Wouldn't suggest changing to this URL, UX is pretty ick, easier to read the Twitter screenshots.
I may trust Tesla not to crash my car or violate my privacy, but I also have to trust them to sufficiently secure the SSH keys from bad actors who would (or sell them on the black market where they almost certainly would arrive in malevolent and capable hands). The latter is what scares me.
I mean, they are held to lower standards than random production VMs that I manage at work, and those can't even kill anyone.
This is the most WTF aspect of the model 3 to me and seems to confirm that there isn't going to be some last-minute mitigation. I know it was done because autopilot was expected to be mature by the time model 3 rolls out, but I don't see how it can even be street-legal when you need to look away from the road to determine your speed.
There's an entire generation of traffic safety cameras that detect people looking down away from the road and it looks to me like they'd be tripped by a model 3 driver just reading their speed...
It's also faster and easier to take screenshots than it is to preserve formatting of HTML/CSS and it suits Twitter.
Related topic: Azealia Banks's recent screenshots of messages relating to Elon Musk, his companies, and other things.
The OP user did end up posting a link to the thread, but I never bothered clicking it. The first screenshot grabbed my attention sufficiently that I just continued looking at the next. They almost act in a similar manner to Wikipedia link previews. Twitter for better or worse is where things still go "viral". I had a love-hate relationship with it but no longer spend a lot of time there these days. There is some method to the madness...
There are lots of people with motivation to pull it off. Either for money or for some political reason nothing to do with Tesla.
Tesla is not alone. Hardware companies in general don't think about software security at all. They are security nightmares waiting to happen.
While there is some cringeworthy stuff in there, I've seen way worse in healthcare when people's personal data and medical history was at stake. Nothing made me so alarmed that I wouldn't drive my Tesla.
I really don't think tesla is the 'worse offender' when it comes to the type of horror stories we read in this article.
This is what systems look like in every industry. Look no further than the crappy Java SWT GUIs you see in those leaked abhorrent NSA powerpoints.
I will never sign a NDA that doesn't expire in <10 yrs after cessation of work, as its just too risky to indefinitely hold any information secret to the level required in most NDAs. Management changes, and what the current management is fine with, future management could not, or you do some work that the company doesn't like 10 years down the road and they dig through the filing cabinet looking for something to hit you with.
https://forums.somethingawful.com/showthread.php?threadid=36...
Do software engineers typically have confidentiality agreements that prohibit releasing proprietary information?
How does that invalidate anything of what he said or vindicate Tesla exactly? Do you believe that because some large companies are shitty places to work that everyone should just accept it as the status quo and shut the fuck up about it? Why are you expecting a single employee to try to 'change things' and why do you think that him speaking up about the issues is not an attempt to do just that?
I don't get your attitude at all.
If you say so. As an embedded system engineer, I mentioned this twitter thread when I was shooting the breeze with my boss because it reminds me we hold ourselves to a high standard even though my brain sometimes turns into a perfectionist that can only see the problems with our product.
I don't know how to say this without going into full on humblebrag mode, so I'll give the condensed version. He touched on a handful of points that are common between our companies/products, and where I often worry about quality. In those cases I was reassured by the fact we don't have that severe of problems, and the way our processes are designed it would never be allowed out of the lab.
You would be shocked to find the amount of Perl/Tcl glue in any ASIC company, for example.
Free software cars when?
Here: https://www.reddit.com/r/EnoughMuskSpam/comments/99sbwa/form...
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 ugly for a while but that isn't what's important right now.
Sounds like every corporate environment I ever encountered, and Tesla it seems. It usually happens becuase they have the money to do it wrong multiple times rather than no choice but to get it right the first time.
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.
Did you ever floor a car and have the engine shut off because there was too much fuel?
No thanks, I don't want to go back to those days!
I certainly miss those days. Working on my current vehicle is a PITA. The fuel rails, coils and plugs take hours to change. On my old car, I could do that in 15 minutes even if the engine was hot. I can't even imagine how proprietary the components on a Tesla must be or how difficult it will be to fix myself.
I've never operated a fuel-injected vehicle that I wished had a carb.
The truck I learned to drive on would cut out if you turned left abruptly, or hit a slight bump while turning left somewhat less abruptly, while off the throttle. We lived on a really steep hill with a ravine at the bottom which meant if you weren't careful to give it gas on the (downhill!) left turn, you would soon find yourself operating a vehicle with no power steering and no power brakes, trying to use one arm to steer the now-manual steering, while using the other to try to restart it, while stomping on the manual brakes, hoping everything came together and restarted before the ever-increasing downward grade ran you across a busy road and into a ravine.
My first motorcycle had a carb, and fuelling issues on motorcycles are even WORSE because they screw up your balance.
Does anyone know what forum they are referring too?
In the few hours after I stopped procrastinating at work today, every post in that thread has went to multiple thousands of likes/share/etc. Guess that's my answer.
thanks but no thanks!
Tesla:Elon Musk:?
Think I will be holding on to my ten year-old car as long as possible.
The latter fits better with their marketing vs. reality gap on “autopilot” and subsequent crashes.
Excuse me, I am a native English speaker and I do not understand this reference
a) car manufacturing is one of the most competitive industries, b) 1000s of engineers are working on making better cars, c) if it was possible to make profitable, affordable, self-driving electric cars, somebody would have done it. Comes off as a snake oil salesman.