Why 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 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.
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.
I think this is a naive perspective. I've heard many similar stories from friends that work in the German automotive industry, and I think you would be surprised how many payment systems are tied together (e.g. (insecure) FTP servers to sync daily payments).
Every organization has these types of things internally. As an engineer, I don't like it, but it's a fact of life.
Banks can reverse transactions if they want to. Tesla's cavalier attitude towards manufacturing has yielded a 14% first pass through rate on the Model 3 line (which is abysmal and may bankrupt the company along with declining M3 demand) vs. the industry standard of ~80% FPT rate.
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.
I don't think the rework rate is a big deal for the customer. Ultimately manufacturing is about increasing the yield rate so that costs are lowered, because rework is expensive. But if you can make money with lots of manual rework on every product, it's no big deal. Something to improve next quarter.
I have so many electronic devices, from cheap to expensive, that have some passive component manually bodged on somewhere. They work fine. It just means that paying someone to rework 1000 boards was cheaper than throwing the boards away and spinning up Revision B immediately. It's not a big deal. Waste is worse than a product that is imperfect immediately off the assembly line.
People are waiting 3 or 4 months for replacement parts for their vehicles or Tesla has had possession of the vehicle (and the person is using a loner) for a similar amount of time. That won't fly in the mass market.
>>> It just means that paying someone to rework 1000 boards was cheaper than throwing the boards away and spinning up Revision B immediately. It's not a big deal.
It's not about money. Correcting and refacturing a board takes time, in the order of months even for a simple one. It's too long.
That link is not a source for declining Model 3 demand. Source?
My info shows that
• In July, over 60,000 test drive requests in the US alone
• 5000 Model 3 new net orders in one week in mid-July
• Total deposits greater than total refunds in the twelve months ending April 2018
• Reports of Cancellations Outpacing Orders proved to be False wording
Meaningless negative indicators include Goldman Sachs analyst David Tamberrino saying Model 3 social media activity had lessened and frequent critic Latrilife said Tesla’s Burbank Airport lot is under 24/7 surveillance
While I agree that 14% is horrible, that was a point-in-time number that is being compared to an average. One would hope that factories regularly run well above 80%. I'd also bet that some occasionally drop well below it for a day or so.
The details matter here and given the quality that I see in the field, I'm not convinced that this is such a horrible situation.
>I think you would be surprised how many payment systems are tied together (e.g. (insecure) FTP servers to sync daily payments).
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.
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!
Well, you can reboot the system while driving(both console and dash), nothing special happens other than the AC turning off for a brief period of time. Brakes, wheel, throttle all respond normally.
Source: Done this a few times to clear bad map data or occasional glitch.
Doesn't surprise me -- a couple of times my new 3 has had nothing on the display but it's still happy to let me put it in gear and drive away, and the display pops up within a second or two.
To be sure, it's a bit unsettling, and I wouldn't be thrilled about it deciding to not work for a day or two, but, in a way, it makes me MORE comfortable that the vehicle control systems function as expected.
There’s a distinction between safety critical equipment and essential equipment. If the former fails, it could kill you. If the latter fails, you can’t drive anymore but you won’t die if it happens on the road. Brakes are in the former category, while things like HVAC and instruments are in the latter.
Safety equipment must not fail, but essential equipment can fail as much as your customers will tolerate.
Seriously yes, at least ventilation. Anybody who don't believe this, try turn off your AC completely and see how quickly your wind screen is fogged up to the point you can't see out. (depending on which climate you live in)
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.
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.
This must be an acronym mixup. We’re talking about the Media Control Unit, i.e. the giant screen in the center of the dashboard responsible for zero safety-critical systems.
Yes, The infotainment stuff, like the screen, internal lights, speakers are connected via a low profile third bus system, certainly not the main CAN bus or profibus or firewire. Some, like in the BMW even via WiFi.
These are the systems usually used with Linux or Windows or Android. On top of the important stuff.
Ignoring the infotainment system for this argument (as they firewall it off from CANBUS and other life critical systems [1]), I argue that their IT infrastructure is safety related, as it governs Tesla's velocity in getting patches and security fixes out to vehicles in a timely manner.
Can you imagine a zero day being found in Windows with Windows Update being down?
There's no guarantee that any given car is connected and receives updates, so the safety-critical systems need to be good enough when the car ships. They might mess up, but then they'd at least be able to patch cars faster, while other manufacturers would have to do a recall.
> Tesla’s infotainment and IT infrastructure is unrelated to their safety.
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.
Runtime isolation is distinct from compile/build-time isolation. You're citing the latter, but it's the former that matters. Tesla gets this right, e.g. an interrupt in the MCU does not have any effect on braking, drive-by-wire, or ADAS systems while a car is in operation.
If that's the standard, then almost everything becomes safety critical. Drivers can easily get distracted by malfunctioning smartphones or apps. (Or, for that matter, properly functioning smartphones or apps.) Yet the prior discussion was based on the idea that things like iPhones and Facebook aren't safety critical the way this is.
>If that's the standard, then almost everything becomes safety critical.
Almost everything in a cars front panel and dashboard can be. I've read somewhere that people have been killed even because of something as quaint as the wrong placement of car ashtray.
One time I pulled up at the red light behind a Tesla while I was on a bicycle. Straight through the rear window I could see the driver and front passenger being distracted by the massive flat touch screen. The traffic light turned green, and had I been beside the Tesla, I would have beaten it across the intersection despite all that electric motor tech in the car.
Anyway this little illustrated anecdote of mine aside, driver distraction is a genuine issue - even for drivers at red lights. The number of times I've seen this type of behaviour transcend into moving off while remaining distracted (whether that's heads down visually or just mentally) is too boringly frequent to detail. Sometimes the distracted drivers even creep forward unconsciously while traffic is flowing across them. Emergency vehicles can't get through, drivers end up splitting their attention, pressure mounts once proper movement starts again, and all the while they don't realise they don't have full attention in a changing environment.
I've missed the light turning green while just looking out the window (our car has no screen). As long as people are only distracted while waiting at a light I wouldn't worry too much.
Except they're not only distracted while looking at their screen when stopped. The distraction continues after they start rolling again - one thing directly leads to another here.
It is my understanding that two major reasons for various ugly UI and unintuitive UX in automotive infotainment systems are patents and safety certifications.
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 they invited a couple reporters to tour, etc.
> The iPhone has to reliably connect for emergency calls and provide accurate location.
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.
That PR tour was in response to "AntennaGate" when Apple failed to engineer a phone to a life-or-death standard (well, if you were "holding it wrong").
Are there any interesting papers on formal verification of some of the most modern machine learning algorithms?
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?
Read the Barr report on Toyota’s unintended acceleration incident. They didn’t have the right failsafes and watchdogs and only a single bit was responsible for a critical feature. Meaning memory corruption or a cosmic ray flipping the bit can cause disaster. They didn’t follow anywhere near best practices in their firmware development. It’s not just the young upstarts that mess this up by being “reckless”
There's still the problem with exploding phones and batteries so even if it's just a phone it can go wrong in dangerous ways. (If it happens on a plane for example)
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.
Especially considering that the engineer was partially blaming Bosch as a supplier that made these processes necessary.
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.
It sounds more like they didn't follow the specific way bosh requires you to use their HW. I highly double VW or others would use Bosh if hacks are required to get them to work.
Updating the software of node are usually in the automotive industry only allowed by trained technicians. Allowing the updates to be done without turning in the car so a shop is the big difference.
Software update in is complex and hard and error prone, for quirks like the bosh stuff here. Many of the big players see it as almost impossible to try to do as Tesla and have it done at the users home.
Remember the Toyota uncontrolled acceleration bug and the report that came as a result of the trial. It seems like software is a bit of a second thought for some incumbents too.
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.
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:
> Skid marks notwithstanding, two of the plaintiffs’ software experts, Phillip Koopman, and Michael Barr, provided fascinating insights into the myriad problems with Toyota’s software development process and its source code – possible bit flips, task deaths that would disable the failsafes, memory corruption, single-point failures, inadequate protections against stack overflow and buffer overflow, single-fault containment regions, thousands of global variables. The list of deficiencies in process and product was lengthy.
>There are a large number of functions that are overly complex. By the standard industry metrics some of them are untestable, meaning that it is so complicated a recipe that there is no way to develop a reliable test suite or test methodology to test all the possible things that can happen in it. Some of them are even so complex that they are what is called unmaintainable, which means that if you go in to fix a bug or to make a change, you're likely to create a new bug in the process. Just because your car has the latest version of the firmware -- that is what we call embedded software -- doesn't mean it is safer necessarily than the older one….And that conclusion is that the failsafes are inadequate. The failsafes that they have contain defects or gaps. But on the whole, the safety architecture is a house of cards. It is possible for a large percentage of the failsafes to be disabled at the same time that the throttle control is lost.
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.
> 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.
At risk of beating a dead horse, I do find it interesting how despite the myriad of "driver hit the wrong pedal" news stories out there, only the Prius one starts from the "it had a mind of its own" angle.
I think what most people don't realise is that it's so incredibly easy to be fallible with "automatic" familiar everyday activities (i.e., not maths or remembering facts). I recall in driving school approaching a quiet intersection where I once lost proprioception of my foot and had to call the instructor to use her dual brake because I didn't know where my foot was or could no longer reach the brake pedal (I guess I'd have attempted the hand brake if I were alone).
From this single experience along with running other dark hypotheticals through my head, I am so cautious with many things that it bewilders me that activities such as "carpool karaoke" is not an atypical practice.
But otherwise yep, same thing with software only that the stakes are often lower thanks to the sheer number of non-mission critical projects out there. It's only the mission critical bugs that get the most attention and surprise.
No, I was just using a fancy word I've always liked because it seemed to describe things as best I could.
At one point in my life, I was simply an inexperienced learner driver. It isn't and wasn't a medical condition (for me anyway). I literally couldn't find where the brake pedal was because I couldn't really position my foot in the right place as I had clearly lost track of where it was in the footwell area. I also didn't want to take my eyes off the road and knew I was going slowly enough that nothing bad would happen (because the professional driving instructor had a dual brake, and I had a working handbrake too which I never used - we'll call that risk compensation).
Now all this said, it's incredible how many people are completely unaware of their own inabilities when it comes to mission-critical tasks (the Dunning-Kruger effect). This isn't even always limited to "incomptent" people - experienced professionals also make "simple" blunders. See also Air France 447, or various deceased pro/amateur race car drivers.
Speaking of failures though - another time (also while I was learning), I was reversing out of the car shed with my dad supervising. Before leaving, I complained to my mother (who was just outside the car) that my brake was difficult to press. She replied "just press harder", so I shrugged, obliged and went on with the "supervised" driving practice. Her confidence in me had me convinced that everything was fine so off I went.
Damn, the brake was so difficult to press - I needed both feet as well as some bodyweight on it to get the car to stop at each intersection - it hardly budged each time and felt like a dodgem car brake. I figured at the time that if I just kept things slow and got the handbrake ready, things would be okay? Anyway nothing bad happened; it was only a short session before dinner on quiet streets.
The next morning, my mother went to drive the car out of the shed and was alarmed at how broken the brake was. What was I to know - I was pretty new to driving and thought it was just the car being old and figured it was good enough at the time for my two feet. It was probably bad enough to require towing but I think my dad ended up driving it very slowly/carefully to the mechanic.
That was a bit of a long story, but I'm detailing this to highlight how "stupid" cascading failures are "alarmingly" common - it's not unheard of to exist in both the human side, or the electronic/mechanical side. It doesn't really faze me whether the Prius "acceleration bug" was human or machine induced. Both are often as bad as each other. The only thing we should depend on are multiple layers of redundancy and good systems design.
Edit: When I first started driving, I mulled over whether to go barefoot or not (either is legal here so long as the driver has control). These days, I fortunately can handle either confidently. I'm also much better at sport now (and therefore coordination) than when I was a teenager.
Koopman has a talk here on his blog that has more details about how ETCS (Electronic Throttle Control System) is safety critical. "If a driver pumps brakes, loses vacuum power assist...WOT requires an average of 175 lbs of force on brake pedal"
And what was particularly negligent about Toyota's software practices that "more likely than not" caused issues with ETCS.
I actually experienced this with a rental car in South Africa. I drove for 10+ seconds with the engine revving at full blast with the car in neutral and no mat impacting the pedal. Both feet completely removed from any pedal, using the handbrake to decelerate and pull onto the verge. The floor mat thing is total deflection by Toyota. The only thing that reset the accelerator was turning the ignition off.
In the case, this could possibly have been limp-home mode. I believe this engages if the ECU thinks the throttle pedal is faulty. It disables the throttle and applies a constant throttle setting to allow you to continue driving slowly - it sounds alarming in neutral, but once you put the car in gear, the revs drop as the engine is required to produce torque.
Happened to my 2001 Clio several years back, although in my case it was when I started the car, not during driving. My hypothesis was that it triggered due to my bad habit of turning the car off in traffic queues then restarting it with the pedal held down.
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
1 throttle and then the task dies, have you?
2 A. No."
From page 245. Further reproduction questions were all answered with a no further.
To get a successfully task death failure (what the engineer wanted to happen) the engineer had to modify the source code.
Further in the limited testing even with modifications, the failsafe triggered 100% of the time.
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:
That’s what it takes to be a challenger in that space. For example, most biotech series As are $100M, because that’s just what it takes to compete (but/lease equipment etc.).
When Windows came out, there were desktop unix(ish) systems, e.g. from Sun or Apollo. Of course they were an order of magnitude more expensive than a PC, so it's hard to argue that they really competed. At that time, if you needed a unix workstation, a Windows PC was not a viable substitute.
Theranos never had a real product or sales and was a fraud from the beginning of institutional investment. Comparing them to Tesla is pointless and has been done to death.
My point certainly wasn't to compare Tesla to Theranos. I didn't mention the two in one sentence.
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.
That's actually pretty interesting to me. I specifically remember seeing those multiple iPhones in the demo and wondering what they were for. Jobs kept putting one down and picking up another one to do a different part of the demo. It never occurred to me that the iPhone wasn't fully cooked and couldn't handle the demo without problems.
Steve was a full on sales person and was really, really good at presentations.
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.