Please forgive me I am not a car ECM engineer, but the approach to this I would take would be to have dual controllers and a staging sandbox on its own board.

Please forgive me I am not a car ECM engineer, but the approach to this I would take would be to have dual controllers and a staging sandbox on its own board. I assume perhaps incorrectly that the updates are already signed. The update process must validate against multiple consensus servers hosted in multiple regions and those servers must be validated constantly by Tesla and their operations team. I would have the car give the owner options for update frequency and options require things like "wait until car is being charged". I would also give the car owner options to manually apply available updates after validating a code against the manufactures website. The website should list all the firmware updates, fixes, checksums, etc... The owner should have the ability to roll back an update at least one revision. If the update fails the secondary controller should become active similar to how some computer motherboards have the option to store an active and rollback BIOS. It should be designed impossible to put the controller into update mode unless the car is powered down and on the charging system and the batteries are at some charge percentage and meet other safety requirements. These options should allow updates to occur when the person is not planning on using the vehicle, such as going to bed. Is this already the case? This is just my preference personally, I would require a physical switch that powers down all transceivers. This will be a requirement for me on all modern cars for ODB3 regardless. I also want the ability to review all data that will be uploaded in JSON. If I can not review this data, I will violate terms/AUP/laws and upload my own image. Even non EV's have remote updates and telemetry with ODB3. This is more common on cars manufactured after 2018. For now I am sticking with used older vehicles.