Goals / Background / Strategic Fit / Requirements

Detail the behaviour of the BMS carrier board and how firmware should enable/control it. 

Monitors voltages, currents, temperatures, fan status and a whole bunch of other things relevant to the the battery and other battery related boards.

Board Overview (Firmware)

I/O 

• CAN 
• Kill Switch 
• AFEs (isoSPI) 
• Fan Control 
• Current Sense Board (isoSPI)
• Relays

Stuff that happens that board needs to deal with

• CAN Message recieved
• Monitor Temparature (AFE)
  • Too High→ increase fan speed
  • Too low → who cares (?)
• Car powered on
  • validate battery health / status
  • turn on relays
  • turn on current sense board
• Monitors state of charge
  • Voltage
  • Current

• Kill Switch flipped (?)
• AFE Under/Over volt
  • Disconnect relay

Revised Block Diagram

Design Notes

• Main initializes killswitch, current_sense, battery_heartbeat, cell_sense, and fan_control. 
• Killswitch, current_sense, and cell_sense need direct access to battery_heartbeat in order to quickly raise or clear faults.

Detailed Design / Modules

Main

• Initializes other modules, initializes CAN and other modules
• Stores most updated measurements
• Current
• Cell voltages
• Cell temps
• Relay state
• Fan speed

Killswitch

• Initializes a debounced GPIO pin to handle killswitch presses
• Exposes init

Battery_heartbeat

• Periodically transmits battery status and receives acks
• Exposes ability to raise and clear faults based on a bitset, and init
• Opens relays in case of fault and updates relay state

Relay_control

• Statically sets relay state, updates stored state, and returns whether the relay state set was successful.
• Exposes set_relay_state
• Note: may need to have a delay when setting relay states to avoid drawing too much current at once

Current_sense

• Registers an interrupt to update the stored current value based on ADC reading
• If the updated current value is above a threshold, raise overcurrent fault
• If the overcurrent fault bit is set and the updated current value is below the threshold, drop the fault bit
• Exposes init

Ads_1259

• Driver for the ADS1259 24 bit ADC
• Exposes ltc_adc_register_callback

Cell_sense

• To be ported from MSXII firmware.
• Raises / lowers faults similar to current_sense, including overcharge, over temperature, over current, under charge

Fan_control

• Periodically updates the fan speed based on the temperature
• Uses an offset linear fan control curve based on the desired operating temperature of the battery (refer to datasheet)
• Exposes init

Meeting Notes

• logs all 
  • Voltage, 
  • Temp, 
  • Current
  • Relay States
• Controls
  • Relays

• used for state of the charge model: 
  • state of the charge status of battery how much energy
  • we need fast logging for a good soc model
  • overcharge
  • over temperature
  • over current
  • undercharge
  • power distribution tells u something’s wrong
    
    • dc dc failed
  • precharge board: 
    • precharge failed 
• controls the relays
• if AFE undervoltage, we disconnect the relays
• you can also disconnect from car power button so that comes from can
• other conditions: 
• controls fans based on the temp
• car turn on: checks battery pack status, then connects relays
• turns on the current sense board: firmware doesn't need to care it's literally a line that goes to it.
• RPI will be SOC algorithm
  
  • connetion between pi's haven't made decision

How it works: 

• Three AFEs 
• Temperatures measured via thermistors (AFEs)
• gpio's control the mux (for AFEs)
• adc: for reading measurements
• we talk to the AFEs and Current Sense using iso-spi
• LTC6811 is the chip (AFE/Battery Monitor) (6811-1)
  • According to the datasheet, the 6811 is pin and software compatible with the 6804 used in MSXII. The changes seem to entirely affect electrical characteristics.
  • So we should be able to reuse the majority of AFE driver code

Killswitch:

• The killswitch MCU has an Enable Line (PB9) and Monitor Line (PB5) 
  • The Enable Line is an output from the MCU that causes the relays to close if the killswitches are closed 
  • The Monitor Line is an input to the MCU that measures the state of the killswitches 
• Enable activates high side driver which sends a 12V signal to the killswitches 
  • If both killswitches are closed, the signal returns to the BMS carrier and powers the main relay coils 
  • If a killswitch is pressed (Open), the relay coils do not receive the 12V and they open, shutting off the car 
• A monitor line is required because the regulations require the car to enter into a BPS fault when a killswitch is pressed 
  • We need a way of measuring if the signal has come back to the BMS carrier from the killswitches 
  • Lower-left corner of schematic page 5 shows a voltage divider that sends a 3.3V monitor signal if killswitches are closed and 0V if killswitches are open

Changes that probably need to be made to MS12 plutus to work with MS14 bms carrier board (if that firmware is reused, not comprehensive)

• change heartbeat behaviour (heartbeat functionality needs to be figured out first)
• add/remove CAN events that can happen
• change/verify Killswitch behaviour
• LTC6811 should be pin/software compatible with one from MSXII, pin mapping/drivers should be updated to reflect new pinout scheme
• everything else mentioned above/below

Questions

Misc Links

Some Guys Masters Thesis on EV BMS - https://pdfs.semanticscholar.org/7b9d/934eaf10114c091e1229ed4d65de3a1002a0.pdf

LTC6811 (Battery Monitor) Datasheet - https://www.analog.com/media/en/technical-documentation/data-sheets/68111fb.pdf

Car's Power States

Old Block Diagram 

This block diagram is highly inspired by MSXII's Plutus. Some minor adjustments were made to make it slightly more easy to understand.

Reasons to revise:

• Relay_control doesn’t need to be under fault_handler since it’ll also receive messages from center console
• Event driven architecture
• System_init is not necessary since startup logic is handled by center console
• Fault handling is also moved to center console