Assuming that we can't split the software for a single component without a fair amount of todo, we need to identify the entire set of required (drivetrain etc.) functions that any block implements at the CAN bus level before tinkering can begin. I think the first question to contend with is which portion of the Vehicle data is sent via the CAN bus. I'm going to assume (perhaps incorrectly) that, like in other vehicles, the CAN bus is relatively insecure, a lot (if not most) of the vehicle information is sent over it, and once access is granted we can snoop on the messages and figure out what does what:
- What information is accessible via the CAN bus? Can we, for instance, read accelerator pedal position? Can we compile these functions into a big document?
- What are the overall modules within the Leaf system that transmit each relevant type of information and how can they be grouped? Take (1) above and group them under their device, tally which are required for vehicle operation and which (if any) are superfluous.
Anyways, here is my list of hypothetical crazy ideas to make the leaf a really cool car (tm):
- (probably "pretty easy" given the limited drivetrain-required functionality and lack of integration to other system components) Replace the entertainment system with a custom OS that can play FLAC files off the second SD card. Remove useless functionality (nav system). Replace the cellular modem with a 4G unit and network software that isn't implemented in such a fashion that it takes literally 3 days to download a JSON list of charging stations. Remove the polite voice that indicates the TCP connection state (what is this, 1980?). (Also I refuse to pay money to "upgrade" to a 2006-era cellular modem.)
- Provide limited integration between the HUD and the main screen (why are there two entirely independent sets of settings?). Make the HUD useful (see 4).
- Modify the drivetrain control. I'm not talking down to the SVM level - ideally we could simply alter the mapping of accelerator/break pedal input, eco, and B mode so that it wasn't absolutely and entirely foolish. B mode enables max regen down to a full stop, D mode doesn't enable regen without break pedal, and no god damn creep. Avoid destroying traction control and ABS in the process. Bonus points if we can alter the D mode break pedal behavior to engage maximum regen before mechanical breaks activate.
- Provide real information on the HUD. Replace the GOM with kWH. Provide a single HUD display box that does efficiency, % charge remaining, KWh remaining, miles to empty for a CONFIGURABLE and not VOODOO MAGIC DERIVED miles/kwh. (Why the hell, despite there being plenty of room to display all parameters on one window, do we have to click through 17 of them to see what we want to see?)
- Implement Cruise Control to match an efficiency requirement.
- For the main system, use a cool API like google maps to attain estimated range given terrain for a route. Tie this into the above cruise control efficiency attainer to use altitude info.
Some of this is definitely easier than others. I would hazard to guess the modularity is less-than-ideal at a physical CAN bus level and that the embedded software would be hard to split apart, but I know others have done a fair amount of work at that level so we can at least ascertain the difficulty before I break out the crowbar, soldering iron, and JTAG programmer.
EDIT: I almost forgot: modify the vehicle sounder to make my car do the Jetsons noise.