Based on the story in the parent, it sounds like this was precisely a problem with software on the critical path, otherwise local mecs/breakdown service would have been able to fix it rather than give up.
https://thenewstack.io/how-the-u-s-air-force-deployed-kubern...
Fwiw - I am a kubernetes fan. Just not in cars.
Worker threads have a garbage API and I keep finding myself wanting to have n processes sharing m workers and there’s just no easy way.
If this setup can run my 95% uptime enterprise apps, I am sure as hell it can run my car too.
So shutting it down certainly seems sensible.
Sure, old carbie with distributor might've just ran with 3 cylinders , but that also might damage something.
Also auto makers don't really want to give user sensible error messages or even just metrics because without experience they might just misinterpret it as different problem.
For example if car have oil pressure gauge it is either nearly fake or heavily filtered. Oil pressure changes according to load but gauge going up and down might cause user to think something is wrong with car...
A car is not an iPhone - if the car can move at all, it must move.
The alternative could be freezing to death. What if I am driving in rural Siberia, or Canada, and there is no phone signal to call for help?
Sure, that doesn't necessarily invalidate your argument, after all this increase in car complexity (through "electronization" and smartification of more and more components) without the increase in debuggability/repairability is IMHO a bad trade-off for many consumers.
Case in point, our second-hand 2011 Ford Focus has a problem with the electronic steering assist. Apparently it somehow experiences some kind of over-voltage and the internal system shuts down. It's likely due to humidity. (So probably it's simply a design/manufacturing/QA issue.) Okay, but there's no way to get the actual data from the integrated electronics from the steering system, but it's possible to reflash a different firmware on it. Which resets the internal data. Which basically clears this error state, and the car will happily use it.
But there's clearly a mechanical error, there's a new "bad" noise when turning the steering wheel. But it's a 10+ year car, rarely used, and replacing the steering system is about ~1000 EUR, doing the firmware flashing was ~30 EUR. (Finding the guy with the laptop, who can flash the firmware through the good old ODB port was the challenge.)
And it's basically a big (market) information asymmetry problem. The car industry wants to sell more cars. Sure they sell some parts, but the more repairability a car has the less parts it really needs, as consumers can make their own tradeoffs.
A lot of software is created on powerful developer machines. But fill up a normal consumer machine with this software, and you start to notice that it maybe isn't so fine.
This is how things like Electron come to exist. I'm sure Electron works fine on developer machines, but once it trickles down to someone's cheap Celeron netbook, it runs worse than retro computers with 384KB of RAM.
Does it really have to be this way? Is more software "fine", if the same could be accomplished with much less code bloat?
P.S. As far as I've heard, one of the best ways for developers to combat this is to target your software for cheap netbooks proactively; test compiled artifacts there rather than on your powerful development machine. If you can make it fast in that situation, it'll be fast pretty much anywhere.
I once met someone who had optimized their DOOM clone using this method, and they claim to get millions of FPS on any vaguely modern machine, just through optimizing it for cheap netbooks.
Have the ECU only do the engine thing. Have the AC control just do AC control. Decouple dependencies and make it as simple as possible. Old cars already do it. Blinker switch send signal directly to light controller, not to some central box deciding what it should do with it.
If something needs config in addition to control signals, have it keep it own config and only be updated from the "config manager" (inforatinment box). If infotainment box dies, everything else still works.
Cars already are basically "microservices on a message bus". Let's just use what works with that - minimal coupling and maximum independence of "services"
> Had I been in a less complex car, a local garage could most likely have fixed the problem and sent us on our way. The sophistication and gadgets in modern cars are great until something goes wrong then they fail hard. Small local garages that used to be a life saver are next to useless now as they don't have the tools and knowledge to fix a mobile data centre.
Out of curiosity, what was the issue ?