> That being said: OTA update is REALLY FUCKING SCARY for cars. What if someone puts the wrong update in the queue accidentally? (2)
OTA update is no more or less scary than any other form of software update, or in fact any other form of mechanical update.
Software engineers are generally used to the level of rigour that goes on with their software. If you're a web devloper shipping a commerce application there's an appropriate level of testing and process, because there's only a certian level of reliability you need to hit, and spending more money on that would slow down your development. The way you go about delivering software for medical devices for instance (which we do), is a completely different process with a whole different level of rigour, testing and documentation. Because that's appropriate in that environment.
There's a whole lot more documentation and thought that goes into the beam that stops the top of your house from falling down, than goes into the beam that stops your garden shed from falling down. It's no different than software.
It's not as simple as that. NASA can update software on the mars rover or interplanetary probes, but that's one device at a time, and the amount of effort put into it is staggering.
At the same time, consumer electronics are routinely broken by OTA updates.
Cars fall squarely in the middle, high volume and high price. Additionally, failures carry a high risk. Nobody will die if your webshop goes down, but if your car decides to steer into oncoming traffic, well, bummer.
The support beam analogy is flawed in the sense that the beams are simply made bigger to ensure they're strong enough even with considerable material defects, but this doesn't work for software, where a single little bug can lead to a catastrophic failure.
I am not aware of anything other than cars where such a high number of devices carries such a high risk factor. Certainly doing OTA car updates in a commercial environment is possible, but there is not yet a relatively foolproof way to do it.
OTA update is no more or less scary than any other form of software update, or in fact any other form of mechanical update.
Software engineers are generally used to the level of rigour that goes on with their software. If you're a web devloper shipping a commerce application there's an appropriate level of testing and process, because there's only a certian level of reliability you need to hit, and spending more money on that would slow down your development. The way you go about delivering software for medical devices for instance (which we do), is a completely different process with a whole different level of rigour, testing and documentation. Because that's appropriate in that environment.
There's a whole lot more documentation and thought that goes into the beam that stops the top of your house from falling down, than goes into the beam that stops your garden shed from falling down. It's no different than software.