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.
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.
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.
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.