To be fair, im still not sold that this is an advancement except maybe in simplifying the number of components. I'd prefer the car to work without "updates" and DLC. Why does my car need a firewall??
For what it's worth, I work in this industry and the general rule of thumb is that every increase in validation from QM (standard quality) up to the various levels of safety critical code has up to 10x the cost per line of code of the previous level.
Exactly that was done for decades.
Heck, manufacturers were issuing service bulletins to fix the fuel maps in their cars in the 1980s.
Now that all vehicles have entertainment systems connected to the internet, I guess it is tempting to use that to reprogram ECUs, I haven't been working in this area recently though.
The first use case of connecting entertainment systems to a vehicle bus that I can remember was to read some engine settings and turn up the volume on the radio at higher speeds.
Is anyone actually begging for this though? And why do you need a full bus? This feels like a luxury car problem that could be solved over I2C or something.
I’m reading this whole SDV thing, and outside of using less ECUs, it seems like an overengineered solution to what was hardly a problem. If we can update ECUs already with OBD-II, step 1 is just making a virtualized OBD-II port that the infotainment system can talk to. Everything else can then stay unchanged until later.
A "virtualized OBD-II" is really just a UDS server if I understand what you're trying to convey. UDS is a dumpster fire of a protocol that should be expunged from existence, but my personal feelings aside can be run anywhere you want. That exists. I'm not aware of many systems that directly connect the infotainment processors directly to critical CAN buses. Usually there's an intermediary component to isolate them.
Yes, but code that doesn't get written does not have bugs. And I don't want to control the rear window defroster, wipers, climate control, fog lights or whatever, on a touch screen menu buried 7 levels deep while going 130 km/h. It's bad enough that coffee makers, light bulbs and tooth brushes now have updatable firmware.
Why? If the rest of the car can function within design specifications for years, why can't the firmware?
I'm fine with updates to add compatibility with new protocols and such, but to me a bug implies there's a standing problem with the current system that's not due to some sort of wear/changing standard/component damage etc. While one can point to examples of cars with defective mechanical designs, I don't think anyone considers it impossible to create designs without such defects (where defects are defined wrt. specifications), why is this the view in software engineering?
But, do you have an example of a software project anywhere that's bug-free? I'd include the space shuttle code, but even that famously high quality development process produced a (low) number of bugs.
The reason for this is a physical limitation: the cars weren’t shipped with wideband O2 sensors, so there’s no way to measure the AFR when wide-open (since it’s targeting a significantly richer mixture, and narrowband O2 sensors can only signal whether a the combustion is stoichiometric, or rich or lean relative to stoichiometric, with no further info). The implantation is probably not a bug but rather a compromise; in an ideal world, the “most recent” BLM will hopefully be from an “almost wide open” part of the map, and the general rich/lean characteristics will be close enough. And, the fuel table in the factory tune is quite safely rich when wide-open, so even with a leaking injector causing the idle BLMs to be way off, the fuel being pulled when wide open will still be completely safe.
Aside from that, 128k of bug-free code.
What was wrong with ECU and ABS etc software prior to the OTA era that we're now apparently entering?
I've had plenty of cars--too many--and outside of a few warranty repairs involving re-flashing ECU/ABS(maybe), this was a very rare occurrence.
(Not counting deliberate tunes or re-flashes for modification purposes)
One, it's expensive. If your update takes half an hour to apply, under the old model someone's being paid half an hour to apply it. Either the manufacturer cuts the billable hours to the dealer and the dealer loses, or the manufacturer is paying that half hour out of increased prices to the consumer. With an OTA system there's usually no cost to anyone besides network traffic. This amounts to billions of dollars in savings for manufacturers.
Second, owners hate 1) paying for updates and 2) getting notifications about it in the mail. It generates bad press and bad experiences for the manufacturer.
Three, it makes the production line more efficient.
Four, the old systems sucked to maintain and for techs to use. They were also insecure and retrofitting security is impossible in a standards compliant way. The internet people have done a much better job with their standards.
Five, most owners are not like you and I. It's a feature for them that their car gets improvements and fixes automatically.
Six, you can be pretty certain what the rollout distribution is. Regulators don't like it when owners are driving around with years old recalls active because they forgot to schedule a dealer appointment. Manufacturers don't like keeping the inventory around.
Seven, "networked services" can piggyback on the same infrastructure and provide additional revenue streams. Certain corporate types think of this as one of the main benefits. Remember how manufacturers used to sell annual maps updates that no one bought? Some consumers also enjoy these sorts of networked services, which frankly I find a bit baffling.
Hmm, I disagree. Bug-free systems are expensive and hard, and get more expensive and harder as complexity increases, but you can absolutely produce a car that never needs updates. The vast majority of computer-controlled cars from the 80s to the early 2010s never needed updates, and the ones that did were performed at dealers (and were usually for non-critical things, because the critical things were simple).
GM had a good run in from the mid-90s to the mid-00s producing bug-free cars, even with some complexity. I don’t know of any software issues on any cars with LT1 or 3800 engines, nor with any of the tech in the Northstar Cadillacs. Displacement-on-demand could be considered a buggy implementation, but it was working as designed, and never got patched out, so I don’t think it counts.
That’s of course ignoring the decades of cars that had no computers at all. No software bugs being patched out with OTA updates in a carburetter (you have other problems obviously though, namely terrible fuel economy and emissions, and generally lower reliability).
If you make it a hard requirement for a car to be bug-free (maybe outlaw OTA updates and force physical recalls on any software problem?) I can guarantee manufacturers can make a bug-free car. It’ll just be way less complex and have way fewer flashy features, and will either cost more or have lower margins. It’s been done in the past, it can be done again.
There is a sweet spot for the level of computerization in cars. We had it somewhere around the year 2000, then waaaaay overshot, and haven’t corrected back.