This is such extremely poor engineering that it throws me into a rage. There is nothing to prevent them from installing the update in the background progressively while driving and then just switching to the new version in one swift atomic operation (like changing the name of a directory) when it’s ready
There’s two major things limiting them actually. Bad software developers and using the barest possible minimum on processors and RAM to run the systems.
We both know that this will never happen. For the same reason why you can get a 300k$ car, and have an infotainment system that runs at 3fps. They don’t have any incentive to make it run better
It’s a mix of piece coat optimization and a lot of creep in what used to be a pretty lightweight process throwing it into the ditch.
The things that run software in cars largely fall into one of two camps: MCUs and SOCs. Think Arduinos and Raspberry PIs. Background programming, with an active and inactive partition, is absolutely possible on a SOC. They’re even file based, so you can do all kinds of clever things. Cars tend to not have many SOCs, so it’s not a monumental task to pitch having them each coat a little bit more for extra storage/processing. The biggest hurdles here are automotive grade and the very long development cycles. These both mean that the hardware is 3+ years old when it launches.
MCUs tend to have monolithic software builds (think literally everything gets compiled into a single .exe). There are a million billion of these things in a typical vehicle from most automotive OEMs. It’s… very hard to make them all have more capacity because you would take that cost and multiply it by 40 or so to get all the MCUs on a vehicle ‘upgraded’ for extra capacity.
If this all sounds a little crazy, it is. From two angles. First: do we really need as much software control in cars as we do? Marketing departments seem to think so. Second: the reason why there are so many small compute units in a car is the slow migration from mechanically controlled components to electrically controlled on. Back in the 80s the majory of automatic transmissions shifted based on a very complex mechanical system (look up a transmission valve body if you’re curious). Moving that to electronic control meant adding a computer to control that functional. Now take this and multiply it and you’ll kind of see the wreck in motion. Most OEMs are moving toward more centralized compute (fewer, larger, and smarter control units), but new electrical architectures take a lot of time/effort so it’s slow going.
I’m pretty sure that what’s being updated here is just the software for the infotainment display, which is likely a pretty powerful SOC that has nothing to do with any components that are necessary for driving the car.
Most OEMs usually show an update screen on their radio, even if something unrelated is being updated.
If the update is taking a long time it could be a really big file on a SOC. It could also be a smaller file being written to… very slow internal memory because when the part was sourced 8 years ago no one considered including memory read/write speed in the sourcing documentation. I’m betting the second, unless this OEM didn’t include background programming on SOCs, which is kind of foolish given how much easier it is on a SOC than MCU.
I can’t speak for this particular OEM, but 12 volt lead acid batteries don’t have very deep power reserves. The OEM choosing to leave the battery on during programming is likely a method of ensuring there’s enough juice to install the update and start the car on the next attempt.
This is such extremely poor engineering that it throws me into a rage. There is nothing to prevent them from installing the update in the background progressively while driving and then just switching to the new version in one swift atomic operation (like changing the name of a directory) when it’s ready
There’s two major things limiting them actually. Bad software developers and using the barest possible minimum on processors and RAM to run the systems.
I wonder if cut backs on the processing power had any relation to the chip supply chain issues over the past year or two?
Probably has more to do with the extreme penny pinching most auto manufacturers do
We both know that this will never happen. For the same reason why you can get a 300k$ car, and have an infotainment system that runs at 3fps. They don’t have any incentive to make it run better
That’s additional work. Easier to tell people to run the engines.
It’s a mix of piece coat optimization and a lot of creep in what used to be a pretty lightweight process throwing it into the ditch.
The things that run software in cars largely fall into one of two camps: MCUs and SOCs. Think Arduinos and Raspberry PIs. Background programming, with an active and inactive partition, is absolutely possible on a SOC. They’re even file based, so you can do all kinds of clever things. Cars tend to not have many SOCs, so it’s not a monumental task to pitch having them each coat a little bit more for extra storage/processing. The biggest hurdles here are automotive grade and the very long development cycles. These both mean that the hardware is 3+ years old when it launches.
MCUs tend to have monolithic software builds (think literally everything gets compiled into a single .exe). There are a million billion of these things in a typical vehicle from most automotive OEMs. It’s… very hard to make them all have more capacity because you would take that cost and multiply it by 40 or so to get all the MCUs on a vehicle ‘upgraded’ for extra capacity.
If this all sounds a little crazy, it is. From two angles. First: do we really need as much software control in cars as we do? Marketing departments seem to think so. Second: the reason why there are so many small compute units in a car is the slow migration from mechanically controlled components to electrically controlled on. Back in the 80s the majory of automatic transmissions shifted based on a very complex mechanical system (look up a transmission valve body if you’re curious). Moving that to electronic control meant adding a computer to control that functional. Now take this and multiply it and you’ll kind of see the wreck in motion. Most OEMs are moving toward more centralized compute (fewer, larger, and smarter control units), but new electrical architectures take a lot of time/effort so it’s slow going.
I’m pretty sure that what’s being updated here is just the software for the infotainment display, which is likely a pretty powerful SOC that has nothing to do with any components that are necessary for driving the car.
Most OEMs usually show an update screen on their radio, even if something unrelated is being updated.
If the update is taking a long time it could be a really big file on a SOC. It could also be a smaller file being written to… very slow internal memory because when the part was sourced 8 years ago no one considered including memory read/write speed in the sourcing documentation. I’m betting the second, unless this OEM didn’t include background programming on SOCs, which is kind of foolish given how much easier it is on a SOC than MCU.
I can’t speak for this particular OEM, but 12 volt lead acid batteries don’t have very deep power reserves. The OEM choosing to leave the battery on during programming is likely a method of ensuring there’s enough juice to install the update and start the car on the next attempt.
Backup cameras are mandatory by federal law. If your device is updating when you put the car in reverse then that wouldn’t be allowed.
It won’t be, if it’s done right.