CAN Message Protocol

Owned by Karl Ding
Oct 01, 2016

Summary

The goal of this RFC is to define a CAN message protocol that will be used by our boards in the car. There will be an CAN interface board that talks to the motor controllers over the manufacturer's protocol. The goal is to trigger an initial discussion regarding the software implementation of the CAN message protocol, and not a complete detailed design.

Vocabulary

  • CAN: Controller Area Network (11-bits or 29-bits)
  • Plutus: the Battery Management System
  • Themis: the board inside the steering wheel
  • Motor Controllers: the devices that control the motors
  • BPS: Battery Protection System (see Plutus)

Motivation

The Motor Controllers will be separated from the CAN network that is used by our boards. An intermediate board will run on both networks, and handle bi-drectional transfer, allowing our network to communicate with the manufacturer's network (to control the motor controllers), and so that we can get telemetry data from the motor controllers. This also allows us to run both networks at different speeds, and isolate the two networks.

Detailed Design

This design comes from an initial discussion on October 1, 2016 with Titus Chow, Karl Ding, Lucas Francisco Fryzek (Unlicensed) and Calder Kitagawa. The main purpose of this messaging protocol is so that we can define a series of messages that will be used throughout the car and understood by telemetry.

Overview

The CAN protocol will use 11-bit identifiers. Essentially, this will be similar to a publish/subscribe system (or more accurately, like a broadcast architecture) where messages will be globally broadcast across the network, and any devices will listen for messages they are interested in.

Messages

These are the messages that will be transmitted over CAN. Each message will have a unique identifier.

  1. Left Turn signals
  2. Right Turn signals
  3. Hazard lights
  4. Brake lights
  5. BPS fault
  6. Acceleration
  7. Motor controller speed
  8. Motor "drive" message
  9. Motor temperature
  10. Motor current
  11. Motor speed
  12. Motor RPM
  13. Battery temperatures
  14. Battery current
  15. Battery voltage
  16. Battery balance strings
  17. Battery heartbeat messages
  18. Horn
  19. Power state
  20. MPPT data?

There is the potential for data from the MPPT boards. In total, this is probably going to be less than 6-bits.

Message Priority

In CAN, every message has a priority, so if two nodes try to send messages simultaneously, the one with the higher priority gets sent and the one with the lower priority gets postponed. This arbitration is non-destructive, and results in non-interrupted transmission of the highest priority message.

  • High Priority: Fault messages (BPS, relay) should be highest priority
  • Not-So-High Priority: Power state changes
  • Even-less-High Priority: Driver controls
  • Normal Priority: Everything else

Device Identifiers

Each message will have a Device ID that identifies the sender of each message.

  1. Plutus
  2. Dash board
  3. Themis
  4. Lights
  5. Chaos
  6. Telemetry
  7. Motor Controller Interface

So 5-bits should be sufficient. This allows us to add on additional "telemetry" components to the solar array in the future, if we care about it.

Acknowledgement Bits

Certain messages like faults should have some sort of acknowledgement.

  • We will use the RTR bit
  • A message needing acknowledgement will set the RTR bit
  • The device that is acknowledging will send the acknowledgement plus the CRC

Failures

The issue we care about will be message timeouts.

An invalid message would probably be due to a malicious attacker (which is super unlikely in our case).

  • If it's not a "serious" fault, then we just send a failure message and telemetry will pick it up
  • Otherwise, we should probably reset the device

Sample Messages and Structure

Example 1

Example 2

Questions

Some further questions we have following the discussion.

  • Can we get data from the MPPTs?
  • Are we still planning on splitting Lights into front/back to save the hassle of wiring?
  • What will be on Themis?
    • How will pedals (and potentiometer and throttle) be routed to Dash Board or Themis?
    • How will the split happen for critical/non-critical boards?
      • Themis will be the critical one
  • FIFO Hardware Queue?
    • We need to test our throughput to determine whether we can process messages fast enough
    • The work will happen in the abstraction layer