Introduction

Our CAN protocol is designed to take advantage of the broadcast-based, multi-master aspect of CAN. For more background, see Intro to CAN (Controller Area Network) or CAN Message Protocol.

Generally, we will only look at the message ID when processing messages. The source device ID is primarily for debugging, although it may also be used to require a specific subset of devices to respond to an ACK request.

Messages

We define our basic ID structure as follows:

This allows us to prioritize messages over the sender, and ACKs will always have higher priorities than the message itself. The idea is that a message's contents are more important than which device is sending it, and that if we have a message that needs to be ACKed, the ACK is time-limited and needs to be received ASAP.

Currently, an ACK's data payload is unused. This may eventually store information such as board ID, version information, and the original data CRC. 

It is unknown whether we need to support custom data chunking or a few fixed formats will be adequate.

Critical Messages

Note: not in any specific order

Critical Fault

• Sources: killswitch, BMS fault
• Should cause power cutoff, BMS fault signals (strobe, driver LED)

Motor Drive

• Sets direction + torque
• Require resending every 100ms?

Motor Cruise

• Could be combined into motor drive
• Always forward, set target speed
• Overridden by mechanical brake, cruise control toggle
• If throttle pedal is pressed, only change if increased torque will result in higher speed, revert back to target speed once released

Signal Control

• Left/right turn signal, hazards, DRL, headlights?, brake lights, horn

Bus Current Limit

• Allow Plutus to set the overall bus limit based on SOC?
• Motor is really the main concern here

Heartbeat Request?

• Chaos regularly broadcasts heartbeat request, expects responses from critical systems
• Could have other critical systems expect heartbeat requests to handle case where chaos is dead
• Alternatively, each board regularly broadcasts heartbeat packet and chaos just expects regularly timed packets

Power On/Off

• Chaos uses for power sequencing, clear faults

Debug Messages

Throttle position

• Probably displayed as a percentage?

Mechanical brake position

• Do we need some sort of interlock to prevent burnouts?

Battery voltage

Battery current

Battery temperature

Battery SOC

• TODO: figure out best way to generate curves - FW based would require lots of charge/discharge tests

Solar voltage

Solar current

Solar power

• Could combine voltage + current into this

Motor speed/rpm

Motor current

Motor voltage

Identification/heartbeat

Power rail change

Aux battery state

Signal state change

Devices

Protected/Critical

Chaos

Listens for: Heartbeat, fault

Broadcasts: ID, Fault, power rail change, aux battery state

Plutus

Listens for: Fault, heartbeat?

Broadcasts: ID, Battery voltage, temperature, current, SOC, fault

Themis

Listens for: Fault? (alert driver?)

Broadcasts: ID, Signal control, power on/off, motor drive, motor cruise, throttle position, mechanical brake position

Lights?

Listens for: Signal control, fault (strobe)

Broadcasts: ID, Signal state change?

Telemetry?

Listens for: All

Broadcasts: ID

Unprotected

Driver Display

Listens for: All

Broadcasts: ID

Motor Interface

Listens for: Motor driver, motor cruise, bus current limit

Broadcasts: ID, Motor speed/rpm, motor current, motor voltage, motor 

MPPTs

TODO: Do we want 1 board per MPPT or 1 board per string? - probably per string 

Listens for: None

Broadcasts: ID, solar voltage/current/power

Systems

Power

Chaos/Plutus/Themis/Solar?/Motor?/Lights?

Basic operation: Themis broadcasts power on, Chaos begins power on sequencing - DC-DC on, all systems online

Heartbeat: Chaos expects heartbeats from all critical systems? or at least plutus

On BMS fault: Plutus broadcasts fault message, chaos acts on event and kills all HV relays, lights turns on strobe, and themis displays driver fault notification

On killswitch: Chaos broadcasts fault message, kills HV relays - notification?

If nearing low SOC: Plutus broadcasts bus current limit - reduce max current draw, motor interface adjusts max torque

If nearing high SOC: Plutus broadcasts bus current limit - reduce max input current, motor interface adjusts max regen strength

At full charge: Cut off solar relay? probably never going to happen, maybe not worth it - just add optional switch to do so manually?

Control

Themis/Motor