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

A recent software update was not successful. Your vehicle cannot be driven

twitter.com

Post reply on HN
Print view View original

101–110 of 189 posts

Re: A recent software update was not successful. Your vehicle cannot be driven

#101

Post by 7thaccount »

mikewarot wrote: post #74

Back in the 1980s I was in the room with a customer who I had written an inspection system for, using a hand-held computer. After downloading the data from the handheld, it would upload a new inspection route. While demoing the transfer, He asked "What happens if I disconnect this right now?".... I didn't know, and said so. I week later it was bulletproof... you could unplug it any time you wanted, and never lose dat…

As someone who has been considering an EV, I'm noping out pretty hard right now and thinking about buying an old and reliable Honda Accord. A few more of these posts and I'll be driving a Volkswagen bug with a garage full of spare parts ;)

Re: A recent software update was not successful. Your vehicle cannot be driven

#102

Post by amelius »

andsoitis wrote: post #99
amelius wrote: post #94

Earlier quoted context omitted.

We should have a law for this. In most countries, new vehicles need to be tested by govt agencies before they are allowed to hit the road. The same should hold after software updates. Ideally, the update should be done by independent agencies, so they can make sure the software is tested and they can properly inform the user (something which we already know companies don't always do). The way it is now, it is all too…

You want an agency to validate every single software updates to vehicles?

At the very least, I want the agency to keep a hold on the update for $N days.

That way, I am more convinced that the software engineers of the car manufacturer won't push any quick fixes that might cause bigger problems later.

In the case of urgent problems, the correct response is to ground the fleet. This will cost the manufacturer money, but I'm a software engineer for long enough to know that a quick fix won't be a safer solution.

Re: A recent software update was not successful. Your vehicle cannot be driven

#103

Post by analog31 »

fmajid wrote: post #83

For decades software engineers have moaned “why can’t software engineering be a real engineering discipline like civil engineering”. The travails of the legacy car makers, compared to Tesla or Rivian, show conclusively mechanical engineering is easier .

>>> why can’t software engineering be a real engineering discipline like civil engineering

Programming pays better than civil engineering or mechanical engineering.

The software team pays better than the hardware team, and programming in support of hardware pays like hardware. When asked why, the answer is: "Software is more valuable because it's closer to revenue." And: "Software has no cost after it has been written once." No manger or engineer can explain what this phrase means, but it's taken as conventional wisdom.

Re: A recent software update was not successful. Your vehicle cannot be driven

#104

Post by inferiorhuman »

neither_color wrote: post #58
rpmisms wrote: post #4

My Tesla had an update fail, and it didn't break anything, I just got a new update package the next day. I also replaced my own headlight and had to run a software update to initialize the new part. I called a service center and had a software update in less than an hour. Try that at Audi.

Back when it was in news cycles that Tesla's stock couldn't possibly be worth more than legacy automakers' because it was only a matter of time until they came for Tesla's lunch, I couldn't imagine they'd fumble it this badly.

Lord knows Tesla's never had any problems with updates before…

https://teslamotorsclub.com/tmc/threads/my-car-is-bricked-by...

https://old.reddit.com/r/TeslaLounge/comments/112oqln/new_te...

https://teslamotorsclub.com/tmc/threads/failed-software-upda...

https://old.reddit.com/r/TeslaLounge/comments/qt0ekf/2021_mo...

Re: A recent software update was not successful. Your vehicle cannot be driven

#105

Post by smsm42 »

rpmisms wrote: post #4

My Tesla had an update fail, and it didn't break anything, I just got a new update package the next day. I also replaced my own headlight and had to run a software update to initialize the new part. I called a service center and had a software update in less than an hour. Try that at Audi.

I replaced two of my lights in my car and I had to re-adjust the carpet piece that covers it. That's all I had to do, no software updates, no service centers, nothing.

Are we going in the future to have to call a service center for a software update when we replace a floor mat or a windshield wiper?

Re: A recent software update was not successful. Your vehicle cannot be driven

#106

Post by [deleted] »

onetimeuse92304 wrote: post #97
jnwatson wrote: post #86

Earlier quoted context omitted.

That is very much standard.

I wouldn't know what the standard is. This seems like something my kid could figure out. It is a shame that multi-billion dollar company that makes consumer products costing hundreds of thousands of dollars can't.

[deleted]

Re: A recent software update was not successful. Your vehicle cannot be driven

#107

Post by rollcat »

onetimeuse92304 wrote: post #84

Some 20 years ago I was asked to prepare OS distribution with OTA upgrade capability for some PoS system. I think I prepared two system partitions and a custom MBR which would alternate the system partition on every start (uses one bit of non-volatile memory to alternate selection of partitions on each boot). When the system starts, it does self-test. If it fails the self-test it just restarts. If it succeeds -- it w…

A/B boot is old, good, and proven, but what do you do when you have dozens of separate microcontrollers, each governing a semi-independent subsystem, all running their own software that needs its own updates? It would make sense from safety/reliability PoV when a crash/bug in a slightly less critical system (like adjusting mirrors) does not affect a slightly more critical system (like indicators). What do you do when updating only one of the components fails? Do you rollback everything? Do you continue with the rest?

Just to be clear, I'm firmly in the "less smart = more reliable" camp, but even a SoC resembles a distributed system nowadays, and this architecture has its merits. The GPU on my M1 Mac crashed, rebooted itself, and all I saw was 1-2s of glitched graphics - no application noticed. Of course ideally GPUs wouldn't crash, but the same could be said of cars.

Re: A recent software update was not successful. Your vehicle cannot be driven

#108

Post by chillingeffect »

Fwiw there are dozens or perhaps 100s of microcontrollers on cars, usually sharing a small number of comms networks. Not all have the luxury of flash space for dual-boot. It's possible an error on one can affect a large number of others. It should be better, but it's more complex than a single firmware image.

Re: A recent software update was not successful. Your vehicle cannot be driven

#110

Post by onetimeuse92304 »

rollcat wrote: post #107
onetimeuse92304 wrote: post #84

Some 20 years ago I was asked to prepare OS distribution with OTA upgrade capability for some PoS system. I think I prepared two system partitions and a custom MBR which would alternate the system partition on every start (uses one bit of non-volatile memory to alternate selection of partitions on each boot). When the system starts, it does self-test. If it fails the self-test it just restarts. If it succeeds -- it w…

A/B boot is old, good, and proven, but what do you do when you have dozens of separate microcontrollers, each governing a semi-independent subsystem, all running their own software that needs its own updates? It would make sense from safety/reliability PoV when a crash/bug in a slightly less critical system (like adjusting mirrors) does not affect a slightly more critical system (like indicators). What do you do when…

I don't think "more smart = less reliable" is inevitable.

The goal should be designing it in a way that failure of the more smart features does not spill to critical functionality. Or that you can use it in a degraded state sort of like fly by wire planes do.

I have no car design experience, but here is my 5-minute idea:

For starters, you build a basic car. It drives, it has basic indicators, it has ABS, etc. It has some APIs that can be connected to but there is limited ability to break the basic car through those APIs.

Then you build your smart car around it by adding to the basic car. You add on more computers, electronics, etc. But any time you rip off the smart car functionality, you still have the basic car working.

If there is a need to update software, this should really only be needed for the smart car part. But even if it fails completely, the basic car underneath should be functional and you should be able to use the car albeit without infotainment and navigation and other "stuff". You should be able to do whatever you need to do, call your mechanic and limp there to get them to sort the problem out for you.

Post reply on HN