I'm not sure folks understand the comm arch in a Tesla. CAN probably still is the main way data are slogged around between ECUs (this info is five years old).

I'm not sure folks understand the comm arch in a Tesla. CAN probably still is the main way data are slogged around between ECUs (this info is five years old). CAN works by broadcasting data values at some periodic rate (1 PPS, 10 PPS, 100 PPS usually) and there is no 'publish/subscribe' except that all data are 'published' and any ECU can listen. What the other ECU does with the data, the originator doesn't know. If one of those ECUs listening is the 'gateway' then it can pluck off the main CAN bus anything it likes, and store it for as long as it likes, and upload whatever it wants. New GW FW can be OTA loaded to save and upload different types of data. In Teslas, there are two main CAN busses: the regular one and the 'secure' one that does the brakes and other safety stuff. There is NO connection between the two; but there is a secured path where the gateway can listen & get data from the secure one. The point here is that vehicle safety CAN bus is likely unhackable remotely, as there simply is no RF path writing onto that bus. (all bets are off if you have the vehicle, physically). I believe all previous exploits have been fixed. And one more thing: ECUs have some amount of on-board flash that is used during a crash/power loss scenario. The "dump important stuff to flash" CAN command causes the ECU to take an NMI-style interrupt and do it. Also, if the ECU's own power monitor notices the ECU is about to lose power, there is enough energy storage on board to operate for maybe a few hundred ms. The important stuff is saved. Every ECU must have a way to OTA its code. E V E R Y O N E, including some door lock or whatever (essentially LIN to CAN gatewaying). There are no, as in ZERO, exceptions to this rule. (or, there weren't as of five years ago, ymmv)