Page Comparison

Purpose (from IV):

A power distribution board is necessary to supply power to the various subsystems in the vehicle, including other microcontrollers. This board performs distribution, startup, shutdown and emergency shutdown as required in regulations. In addition to supporting powering the boards, it also powers components directly, such as telemetry, the horn, camera and others.

The current electrical system design requires two instances of Power Distribution boards, a front PD and a rear PD. In MSXIV, the same firmware was flashed to both boards, with a startup condition used to determine which configuration was to be processed.

Essentially, power distribution has a set of outputs which it can turn on or off based on the state of the system. These outputs include:

SW Components:

The functionality of Power Distribution is broken into three Tasks

• Master Task

• Lights FSM task

• Power Sequence FSM task

Master Task

Responsible for handling:

• CAN functionality

• FSM Cycles

• Horn (Front PD only) - Triggered on Horn event over can from steering*

• Brake lights (Rear PD only) - Triggered on brake event from pedal*

*NOTE: Brake and horn could be moved to power FSM, but makes sense to have them in main loop as they will always need to work, and this will make them extra responsiveIt maintains a power state, regulated by the power FSM which takes one of two states:

POWER_OFF

This is the first state of the car, when the AUX battery is initially connected. We must power:

• Power distribution (this is on by default, we don’t have to use the board to power itself on)

• BMS (DCDC enable only)

• Centre console

POWER_ON

In this state the relays are closed and the main batteries are connected. The motors are not connected so we are not able to drive. We transition to this state upon receiving a message from centre console with a POWER_EVENT_BTN or POWER_EVENT_BRAKE_AND_BTN. This state is mainly used for charging

We must power:

• BMS (DCDC Enable + Aux Enable)

• Centre console

• Pedal (for brake readings)

• Steering (for indicators)

• Solar 1 and 2

POWER_DRIVE

In this state, we complete MCI precharge, connect the motors, and indicate we are ready to drive:

We must power (in addition to the board above):

• BMS (DCDC Enable + Aux Enable)

• Pedal (for brake readings)

• Steering (for indicators)

• Solar 1 and 2

• MCI

• DRL lights

• Camera

• RPI Display

• Driver Fans

• Telemetry

POWER_FAULT

Must have BMS relays (BMS_AUX_EN) disabled, and MCI turned off. We should have access to our indicators and brake lights:

• BMS (DCDC Enable)

• Centre console

• Pedal (for brake readings)

• Steering (for indicators)

Additionally PD controls a few other outputs separate from the main power states:

Left/right turn signals:

• Monitors steering messages and centre console message for turn signals and hazard indicator

Brake Light

• On when brake reading from pedal > 0

BPS Fault Indicator

• When BPS Fault occurs

Lights FSM

The lights FSM is responsible for handling the indicator light functionality for the turn signals, hazard lights and the fault indicators. Its inputs are steering eventsindicator states, received in CAN messages from the steering board, as well as BPS fault indicatorshazard value from Centre console. It has the following state diagram:

Note: The BPS fault indicator is no longer handled by Lights FSM

Power Sequence FSM

The Power Sequence FSM is responsible for handling what gets power in different power states of the car. Based on inputs from the rest of the system, and state changes from power select, it will alter the source of power and be responsible for turning on and off different boards as needed. It receives as inputs CAN messages which indicate power events.

State Diagram:

Image Removed

General Master task format:

MasterTask() {
  init_fsm(lights);
  init_fsm(power_sequence);
  
  while(true) {
    run_can_rx_cycle();
    update_horn();
    update_brake_lights;
    run_lights_cycle();
    run_power_sequence_cycle();
    run_can_tx_cycle(); 
  }
}

TBD:

• Can monitor functionality will be required

Regs/Overall Car Design Questions:

• Do we have our lights integrated into our mech design?

  • It looks like we can have one set of lights for brake/signal, is this something we want to pursue?

• How are our cameras going to work? just on all the time? do regs say anything about this?

Expand

Module Seperation:

• bps_watcher - Watches for the BPS_HEARTBEAT to make sure that no fault has occured

• can_rx_event_mapper_config - Standard configurations for can_rx_event_mapper

• can_rx_event_mapper - Maps CAN messages to power distribution events

• current_measurement_config - Standard configurations for current_measurement

• current_measurement - Periodically reads current from load switches and exposes global storage

• front_uv_detector - Checks if undervoltage cutoff has occurred on front PD and sends a CAN message -Own board in MSXV

• main - Initializes all other modules

• output_config - Standard configurations for output

• output - General-purpose module for manipulating the outputs that power distribution controls

• pd_fan_ctrl - Control fans for front and rear power distro via ADT7476A

• pd_gpio_config - Standard configurations for pd_gpio

• pd_gpio - Receive events and set the PCA9539R GPIO pin states as specified

• publish_data_config - Standard configurations for publish_data

• publish_data - Publishes current measurements over CAN as generated by current_measurement

• rear_strobe_blinker - Blinks the strobe light, controlled by PD_STROBE_EVENT

Main Functionality

• BPS Watcher

  • Need to have timeout for BPS Heartbeat message

  • Unpack CAN, check for error - If a fault has occurred, we need to enter the Fault state, and go to aux power

• Can Rx Events

  • Will be receiving messages in the main loop/parse inputs in FSM

  • Needs to act on messages and execute functionality

• Current Measurement

  • Periodically read from load switches/analog inputs, act based on this

• Output

  • Abstraction over all outputs that are connected to PD

  • Items can be turned off/on, and some provide current draw measurements

• Fan Control

  • Drive fans based on potentiometers/thermistors

• PD Gpio

  • Writes Gpio states based on received events

• Publish Data

  • Puts necessary messages on CAN BUS

• Rear Strobe Blinker

CAN Rx messages

Front:

• MESSAGE_LIGHTS

  • EE_LIGHT_TYPE_DRL

  • EE_LIGHT_TYPE_SIGNAL_RIGHT

  • EE_LIGHT_TYPE_SIGNAL_LEFT

  • EE_LIGHT_TYPE_SIGNAL_HAZARD

• POWER_ON_MAIN_SEQUENCE

  • EE_POWER_MAIN_SEQUENCE_TURN_ON_DRIVER_BMS

  • PD_POWER_MAIN_SEQUENCE_EVENT_TURN_ON_EVERYTHING

• POWER_ON_AUX_SEQUENCE

  • EE_POWER_AUX_SEQUENCE_TURN_ON_EVERYTHING

• SYSTEM_CAN_MESSAGE_POWER_OFF_SEQUENCE

  • EE_POWER_OFF_SEQUENCE_TURN_OFF_EVERYTHING

Rear:

• MESSAGE_LIGHTS

  • EE_LIGHT_TYPE_BRAKES

  • EE_LIGHT_TYPE_STROBE

  • EE_LIGHT_TYPE_SIGNAL_RIGHT

  • EE_LIGHT_TYPE_SIGNAL_LEFT

  • EE_LIGHT_TYPE_SIGNAL_HAZARD

• POWER_ON_MAIN_SEQUENCE

  • EE_POWER_MAIN_SEQUENCE_TURN_ON_DRIVER_BMS

  • PD_POWER_MAIN_SEQUENCE_EVENT_TURN_ON_EVERYTHING

• POWER_ON_AUX_SEQUENCE

  • EE_POWER_AUX_SEQUENCE_TURN_ON_EVERYTHING

• SYSTEM_CAN_MESSAGE_POWER_OFF_SEQUENCE

  • EE_POWER_OFF_SEQUENCE_TURN_OFF_EVERYTHING

PD Events to outputs:

GPIO:

DRIVER_DISPLAY
STEERING,
CENTRE_CONSOLE,
DRL,
PEDAL,
HORN,
BRAKE_LIGHT,
STROBE,
SIGNAL_LEFT,
SIGNAL_RIGHT,
SIGNAL_HAZARD,
NUM_PD_GPIO_EVENTS,

Rear Strobe Blinker:

STROBE

Lights FSM

SIGNAL_LEFT
SIGNAL_RIGHT
SIGNAL_HAZARD

SYNC_EVENT_LIGHTS

Power Main sequence (also handled by gpio

MAIN_TURN_ON_DRIVER_DISPLAY_BMS
MAIN_TURN_ON_EVERYTHING
AUX_TURN_ON_EVERYTHING
POWER_OFF_TURN_OFF_EVERYTHING

ICs:

• BTS7040

Front Power Distribution Powers:

enum {
POWER_OFF,
TRANSMIT_BMS_CLOSE_RELAYS
POWER_ON,
TURN_ON_DRIVE_OUTPUTS,
POWER_DRIVE,
} PowerFSMState;

Fault Conditions

We can enter a fault under 3 conditions, and we should be checking these conditions in every state:

• Loss of communication with BMS

• Receive a non-zero fault value from BMS

• Soft-Short Fault

  • Current values received from BMS/MCI/Solar do not match within ~2A

In a fault condition, we need to

• Cut the power to the BMS relays (turning off BMS_AUX_EN)

• Make sure MCI is off

• Turn on the BPS fault indicator

State Diagram

Image Added

POWER_OFF:

Output:

• Update power state CAN message

• Set Output State to be POWER_OFF (only BMS + Centre Console Powered)

  • Cut power to BMS relays (BMS_AUX_ENABLE not enabled), which is handled by above

Input:
Check for the following Transition Criteria

• POWER_BTN or POWER_BTN_AND_BRAKE event received from Centre console

TRANSMIT_BMS_CLOSE_RELAYS

Output:

• Sets Output Group to POWER_ON

  • Connects power to BMS relays (Enables BMS_AUX_EN) so that bms can close them

• Update power state CAN message, which BMS will use to update the relay state

Input:

• Waits for reply message from BMS with relay state closed, times out if not received

  • If above message received, confirm that power distribution is now using DCDC supply from batteries, if correct, transition, otherwise go back to POWER_OFF

POWER_ON

Output:

• Sets Output Group to POWER_ON (if we’ve transitioned from POWER_DRIVE or TURN_ON_DRIVE_OUTPUTS)

• Update power state CAN message

Input:

• Checks for POWER_BTN_AND_BRAKE event to start transition to POWER_MAIN

• Checks for POWER_BTN event to transition back to OFF

TURN_ON_DRIVE_OUTPUTS

Output:

• Turns on the output group for POWER_DRIVE, namely MCI

Input:

• Waits for a response back from MCI with a relay state == Closed, times out if it doesn’t arrive

  • On receiving power, MCI will begin precharge and close relays, and send a CAN message with the relay state

POWER_DRIVE:

Output:

• Updates drive state in output CAN message

Input:

• if (POWER_BTN or POWER_BTN_AND_BRAKE) transition back to POWER_ON

FAULT:

Output:

• Disable BMS Relays

• Set Output Group POWER_ON

  • Namely, this will disable MCI and other unecessary inputs

• Start BPS Strobe

Broadcaster

Module to broadcast relevant information from power distribution to Centre Console for error tracking

• TBD