This was why infotainment systems lagged the state of the art for so long - they were apparently shipping components that would have belonged in a smartphone from more than half a decade before.
In this case, I believe we had a few phones get A/B updates by Android 7, which was late 2016. Giving it a year or so to filter to more CPU chipsets, that would mean (if the old rule held true), we would expect to see A/B hitting new cars in the next year or two. This assumes auto makers are using enough of the Android BSP to get the bootloader with A/B (which isn't a given), and then that they use it!
Anyone with any experience of auto software know if the teams doing software are experienced and understand the platform side of things, or if it's a traditional front-end heavy "crunch release" type affair? I've seen some pretty poor quality infotainment systems in the past, so my assumption is inexperienced devs with limited platforms knowledge, focused on "get it working to ship it", but would be interesting to hear from anyone with experience of how this really goes down.
"You'll drive up costs for the hard-working American consumer"
"We'd have to cut salaries or fire factory workers"
"We wouldn't be able to compete against that car company from Nothereistan!"
etc.
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 easy for a company to decide to push a quick fix for a problem that really needs a more careful approach (but which might cost the company money).
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.
What is the difference between this and "No Deploy Fridays"?
It’s a 3 ton (+) machine with people paying attention less each passing day. It should be taken very seriously.
This seems far better than having an agency ad hoc review every single specific software update to vehicles - would people at the agency review the code? Do they write automation? Do they do manual verification?
https://www.pentestpartners.com/security-blog/reverse-engine...
And this is their decade old architecture. If you watch some cybertruck videos you’ll see it is much more elegant now.
It's also not something Tesla does better; numerous security researchers have bypassed that gateway.
Since you bring up Tesla: used to be that Tesla control units would fail after a certain number of drive time hours because they did so much logging to the flash chips they'd wear them out.
In a vehicle which is highly connected and basically should never lose power most of its life, they were writing logs to flash memory. Anyone who has done embedded work can tell you how stupid an idea that is.
https://www.tesla.com/support/8gb-emmc-recall-frequently-ask...
I understand EMMC/Flash is a bad idea, but what is the better approach, a HDD/SSD?
Calling out Tesla as a model for excellent software is insulting to SW that's actually quality.
What Tesla SW has and others lack, is a great "wow" factor, which consumers who don't get to see how the sausage is made, mistakenly associate with 'quality' because it behaves like their iPad, but don't know all the skeletons in that closet.
Tesla is very good at automotive software engineering.
You're making it sound like that mistake was an "I spilled my coffee on you boo-boo" and not a terrible engineering decision that should not have passed anyone with actual experience in the embedded industry, let alone a team. If this is the kind of engineering oversights that ends up in Tesla SW, only God knows what else they have lurking in there that hasn't yet reared its ugly head.
>Tesla is very good at automotive software engineering.
Citation needed. Repeating something doesn't make it true.
(Not like the subsubsupplier of that module even specced the extra flash memory for A/B update, hah)