It's not practical to produce a car that never needs updates. That would be a bug-free system, which is impossible. Since they're going to ship updates anyway, a lot of focus is on minimizing the cost and hence OTA.
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.
> That would be a bug-free system, which is impossible.
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?
The rest of the car doesn't function within specifications for years. That's what recalls are fixing. These days, a lot of software recalls are being issued to work around physical design "bugs". The Tesla cybertruck frunk pinching issues are a well-publicized example.
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.
Not open source but mostly reverse engineered, and automotive: the PCM code for GM’s LT1 engines. The only thing that could be considered a bug is the behaviour of wide-open throttle fuelling, which was completely acceptable from the factory but made aftermarket tuning a bit tricky. Specifically, the fuel calculation routine would use the most recent BLM (short- and mid-term air-fuel ratio correction factory as measured by the O2 sensors) when calculating fuel delivery when wide-open, rather than locking it to a constant; the “most recent BLM” may be for a completely different area of the tune (like mid-RPM low throttle), where things like vacuum leaks or even just intake runner inefficiencies have a much greater affect on AFRs than when wide-open. This can result in either too much or too little fuel being injected, and under- or over-shooting the target AFR.
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.
It was not. Recalls have included software updates (sometimes via component replacement) since ECUs became common in the 1980s. Reverse engineering the binaries and flashing updated parameters is actually how ECU tuning used to be done.
But those cars are no longer competitive. There is only a marginal buyer group who wants to drive these "bricks", which would also unlikely pass the requirements set for new cars.
> It's not practical to produce a car that never needs updates. That would be a bug-free system, which is impossible. Since they're going to ship updates anyway, a lot of focus is on minimizing the cost and hence OTA.
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)
They are not complex, so less breaking point to begin with.
Also some bugs are considered not critical enough to do recall, they can be fixed when the owner return their car for maintainence. But now even those small bugs will be fixed by OTA update
Purely from a manufacturer's perspective (not personal opinion):
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.
> It's not practical to produce a car that never needs updates. That would be a bug-free system, which is impossible.
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.
Updating the software in the computers that control the car has traditionally been combined with providing diagnostic support for it through the dealerships, not done OTA. Having an OBDII connector has been mandated in vehicles for a long time, you plug something into it that lets you either listen to CAN bus traffic or reprogram an individual Electronic Control Unit (ECU).
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.
> 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.
One problem is that the ECUs are fairly dumb, they each have a limit on how fast you can send CAN frames to them without overflowing receive buffers. The protocol to reprogram them starts by asking the target ECU how much of a delay is needed between each frame then needs to keep to quite tight timing constraints when sending the new flash image, I have written a Linux network protocol module to do this.
I2C is also a bus, just one that's less reliable and involves more custom work to use.
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.
I absolutely enjoy speed compensated volume. It's nice to have about the same apparent volume inside the cabin as road noise increases while not being very loud when going slow speeds or stopped.
>That would be a bug-free system, which is impossible.
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.
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.