Live data from Hacker News

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

twitter.com

131–140 of 189 posts

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

#131

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…

So this is mostly a solved problem at other OEMs, and I do not know how Ford does it.

I know that other OEMs do variant testing, have complex SILS (software in the loop) test systems so that all potential failure scenarios are tested in software prior to update. The downside is that updates are slow to release then, with some other OEMs only putting out an update once or twice a year, but they avoid this scenario.

Software wise, the industry is moving towards defined standardized interfaces for sensors that are versioned. Example: https://blackberry.qnx.com/en/ultimate-guides/software-defin...

Back to the topic though, all major domain ECUs will have an A/B partition. Usually one of these is the OTA master, and has the capability to update the other microcontrollers via UDS. For safety critical microcontrollers that do not have a A/B partition, about half will not support OTA (this is just a thing for small MCUs), and the other half are flashable completely. So something like this is rare and should only happen on a secure boot failure or some other catastrophic scenario, which ideally your SILS system will have tested (SILS won't test all scenarios but will definitely test all failure cases).

Larger OEMs may even have HILS (hardware in the loop systems) where these things are also tested on physical hardware prior to launch, but with software defined vehicles this is slowly going away.

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

#132
post #77

Earlier quoted context omitted.

So? Everything that can update firmware should do the same thing.

And then what? A/B update isn't magic dust, if some sub component ends up with an incompatible firmware because it had to boot to the alternate partition, you might still have an incompatible overall system. (Not like the subsubsupplier of that module even specced the extra flash memory for A/B update, hah)

Retain the known good firmware for each controller on master disk A, if the update fails, reflash all components.

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

#133
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.

An Audi doesn’t need a software update to replace a light from my experience. Also, my experience with Audi and BMW are that community tools exists to let you flash modules and change settings all on your own. Try that on a Tesla. Tesla is way ahead on software imo, but I don’t want my car to be like modern smartphones where they’re dependent on the manufacturer to maintain and keep working.

Mine did - had to code the module to the car.

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

#134
post #105
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?

What car do you drive? Go replace the headlights in a modern vehicle and see what happens. You have to code the module to the vehicle.

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

#135
post #23
post #12

I wish someone would make a truly dumb car. Sure you can have microcontrollers for emissions, safety, etc but beyond that give me a 1970s user interface and make the car as independent of technology as possible.

My eldest daughter knows her way around cars, and she refuses to buy any car that has any sort of computer in it. She knows how to change this, repair that, fit whatever and is very happy doing that. But she also knows that as a female if she goes into any garage for a 'diagnostic' she will be overcharged. In fact even for something normal with a 'non-computer' car she will be overcharged. Cars without computers are…

[deleted]

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

#136

It’s a bit troubling that automakers (and, well, anyone who is building things that have mechanisms for software updates) aren’t making software updates failsafe. If you have multiple copies of the image on storage, and you take care not to touch the currently-running image, then a failed software update to the alternate image shouldn’t have any impact. Think of it like blue-green deployments on the cloud; and it’s w…

My router has dual firmware partitions, the fact a car doesn’t is inexcusable

It was a great advantage, both in marketing and the real usage, when the motherboards started to support the Dual BIOS (GIGABYTE term, AFAIR). 2003 I think?

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

#137

Earlier quoted context omitted.

As a fellow “analog” automotive enthusiast, I’m curious how she defines computer in this situation? Given that ECUs / microprocessors have been standard on cars since the late 60s / early 70s. For me it’s the network connections and updates that scare me. The software on my ‘99 Benz hasn’t changed in 24 years, and I don’t need it too.

I’ll add a small point to this. The computers my old cars do have, I’m quite thankful for. Being able to purchase a ~100-200 buck code reader and easily plug it in and figure out what my warning lights are trying to tell me has been a great educational tool and saved me a ton in maintenance.

Advanced software can be used for good. It's sad that the same advanced systems that can perform extremely accurate self-diagnostics that empower even the most amateur mechanic to do their own work on extremely complex ICE setups for years and years will also be the component most likely to render the vehicle a 6000-lb brick made of animal skin and rare earth metals

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

#138

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…

That is very much standard.

Yep TiVos did something similar

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

#139

Do car companies outsource their software to fiverr or something? Every single car I rent lately is a buggy piece of shit.

Ugh. I rented a Ford Explorer recently, and somehow they managed to screw up Applr Carplay. I'm in a place I don't know very well, navigating using Apple Maps via Carplay, and my GPS location goes for a wander. Just wanders off so that the navigation gets way confused trying to route me to my designation, because the current location is miles and miles off from where we are. So I unplug my phone and suddenly my GPS l…

carplay just seems like crap on all cars I've used (including the new subaru I own)

I don't even try it anymore and just bring a vanilla charger and pipe audio to the car via bluetooth (which generally works without issue on every car I've tried) and the phone for actual navigation

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

#140

Earlier quoted context omitted.

That's not how vehicles are designed for many reasons. For one, there's no option where critical components aren't designed with updateability in mind. It's simply a fact of life that code has bugs, and the only way to fix those bugs is updates. It's valid to feel that that those updates should applied at a dealership where the system can be tested afterwards, but that has a lot of implications of its own.

You simply do not understand the point of extracting "basic car" from "smart car". The point isn't that the software will have no bugs. The point is that the basic car will have much less software and much more basic software and that it is much easier to test and ensure this software is in working condition. Also, it is absolutely not true that the basic software has to be updateable. With care, basic functionality…

I have a very deep appreciation for simpler automotive components. Please don't take anything I'm saying as discounting those very real benefits.

What I'm saying is that no practical amount of testing and verification can eliminate the need for updates. Let me give some practical examples I've seen: a bug in the silicon vendor BSP that prevented programs from accessing half of the physical memory. In another case the vendor provided optimistic battery curves that caused safety issues in certain conditions, so changes were needed after units were already in the field. In another case, a factory was taking the stuff we were giving them and using it to build weird Frankenstein images from various binary blobs, so nothing that had been produced for those weeks corresponded to anything that had been tested.

Post reply on HN