Car "Body Control Module" - CAN bus architecture, and existing useful projects

Projects General Guidance
1

Hi all

I'm about to start designing a 'Body Control Module' for my 80's campervan, and would like any guidance anyone has on existing projects that may help, and/or hardware support.

My background is, I studied computer architecture, embedded computing, and electronics at university, and am now employed full time as a software developer. I have been an electronics hobbyist for 20+ years, and have been tinkering with AVR uC's since before Arduino, so my skill level should be up to the task :slight_smile:

My camper currently has a grand total of 3 computers in it, counting the aftermarket stereo, alarm, and solar controller. It was originally a commercial vehicle, and at the moment has had the interior completely stripped out pending a refit, so is a bare metal shell. (No dashboard even!!)

The plan is to install a system that accepts inputs from across the vehicle (eg. door open switches, panel switches, light sensors, pots) and controls outputs across the vehicle (eg. interior lighting via PWM, status indicators behind input switches, sink water pump, extractor fan etc etc).

This would normally be a straightforward system to design with one uC and lots of I/O, however I would like to avoid having massive amounts of wiring traversing the vehicle. It seems that the CAN bus was designed for just this use case, so am currently considering using this to allow a centralised uC to control all the outputs based on all the inputs.

Awesome ASCII art plan:

PWM   IO        PWM  ADC  IO           PWM  ADC  IO            PWM    IO             PWM    IO
 \    /           \   |   /              \   |   /               \    /                \    /
 Main uC         Ceiling I/O          Cargo wall I/O           Kitchen I/O         Rear door I/O
   ||                ||                     ||                     ||                    ||
 CAN rxtx         CAN rxtx                CAN rxtx               CAN rxtx              CAN rxtx
   ||                ||                     ||                     ||                    ||
 *=++================++======== CAN BUS ====++=====================++====================++=*

Logic for controlling things would be contained on the Main uC, which also has loads of I/O on it, as it will be situated by where the bulk of the vehicle's existing wiring congregates.

The other units will send CAN bus signals to notify the Main uC when a signal state changes, and accept messages from the Main uC to change output states.

Some decisions to make - your input appreciated :slight_smile:

  • 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 =]

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

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

  • Is there anything else I should consider?

Thanks for reading and contributing to my project!

Darren

2

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

3

Any progress in two years?

:slight_smile:

Also doing similar. Was almost thinking of scrapping my canbus idea and just sending the data via wifi from an d1 mini or something similar. Not sure if that would be as effective though.

Have a load of mcp2515 boards, so might just start with an 'engine control module' for sensors in the engine area, sending the data to CANBUS.

Then a dash/body control module to do GPS/Speedo/Internal temp etc...

Then a RPi for the cluster/infotainment and also to receive the CAN signals and display in a digital dashboard.

Anyways, I keep bouncing around. Hope your respective projects went somewhere!