Any progress in three years?
I've started doing the same thing with my car (a '95 Chevy Caprice with OBD1), but I'm also working on reading the PCM via the ALDL port, and eventually driving the existing instrument cluster as well. There will also eventually be a Raspberry Pi driving a UI via touchscreen, but since Pis tsake time to boot, the lower level body control will be a group of Arduino-based nodes controlling everything, from exterior lighting to the power stuff in the doors to the climate control and dashboard.
The nodes I've identified for my project so far are:
Master: reads data from PCM, reads statuses from client nodes, can send commands to nodes as well. This will eventually communicate with the aforementioned Raspberry Pi.
Underhood: control exterior lighting at the front of the car, plus reading various sensors not hooked up to the existing PCM
Cruise control: drive the cruise module. Possibilities here include setting the module to preset speeds, increasing/decreasing the set speed by 5 or 10 mph, or even recommending a speed setting based on location
Instrument cluster: drive gauges, indicator/warning lights. This would drive the existing cluster but could also be used to drive a so-called "glass cockpit".
Climate control: control fan speed, temperature, and vent settings
Doors: one per door, for power windows/locks/mirrors/door jamb open switch. Actually lots of I/O.
Dashboard: all the other interior knobs, switches, and buttons. Mostly inputs.
Rear: Taillights, gas tank level sender, trunk light
Anyway, you wanted input, here's some stuff I've thought about. Hopefully it might help someone else.
* Use an Arduino for each I/O node, or just use a dedicated I/O expander like MCP25050 (PDIP package available for ~$6) - expander would involve more learning, but would probably simplify everything, and maybe result in a new open source library if there isn't one already =]
I've pretty much settled on using an Arduino for each functional node, using 8-bit shift registers if more I/O is needed (like for all the warning lights in the instrument cluster).
* Use another bus instead? SPI would involve more slave-select lines than I'm comfortable with, and I2C is probably too susceptible to in-car EM noise. LIN seems to be short-distance only. Maybe something like Ethernet might be suitable.
I thought through this one long and hard. I had originally settled on SPI, because it would have been simpler than I2C, and the signals could be converted to differential pairs for noise resistance. But then I considered the hardware complexity in hooking all this together, plus the want of having the individual modules being able to initiate communication with the main controller on their own, and realized that what I was actually doing was designing a really crappy version of Ethernet. So now it's just going to be a bunch of little client nodes on an Ethernet bus using commodity hardware. The wake-on-LAN functionality should be good for waking them up when needed.
* Run a separate 5V line around the vehicle, or run a 12V->5V regulator for each node? Leaning towards a common ground and running a 5V regulator for each node, for no real reason other than it seems cleaner than having multiple voltages floating around the camper.
I've decided to go with a single 12V always-on power source for each node and let each node do its own voltage conversion. Part of the data stream will be an ignition key status bitstring so the nodes can simulate accessory power or power in start or run functionality.
Hope this helps. It's a pretty ambitious project to be sure but the payoff should be worth it.
TJ