Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 19 Next »

DescriptionBMS Carrier Firmware
Target releaseMSXIV
Epic
Document owner

Arshan Khanifar

Project leads
Team membersArshan Khanifar 

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

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.

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 will activate the high side driver which sends a 12 V signal to the kill switches. If both are closed, the signal returns to the BMS carrier and powers the main relay coils (if the low side switches are also closed). When a kill switch is pressed, it opens and the relay coils do not receive 12 V, so they open and the car turns off. The regulations require that the car enters a BPS fault when a kill switch is pressed, and so we need a way of measuring if the signal has come back to the BMS carrier from the kill switches. In the lower-left corner of schematic page 5, you can see a voltage divider that sends a ~3.3 V monitor signal to the controller board if the kill switches are closed, 0 V if the kill switches 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

QuestionAnswer
What are the conditions under which we open the relays?

Over current, over temperature, over voltage, under voltage, upon request over CAN

How many ways are there to change the relay state? Is BMS Carrier the only one controlling them?Kill switch also controls the relay state externally.

What are the incoming CAN messages?

BMS Carrier CAN Messages
What are the outgoing CAN messages?BMS Carrier CAN Messages
What's the maximum rate we can have for voltage measurement?
What's the maximum rate we can have for current measurement?
What should it do when we power the car ON?Check relay states and ensure the batteries are within manufacturers specifications for over voltage, under voltage, over temperature, etc.
How are we computing the SOC? We will be using an OCV-SoC and coulomb counting method to start. (Ask Micah Black)
What are the temperature ranges for fan control?An offset linear fan control curve to start for easy implementation. This will make the fans run at full speed before the batteries reach maximum temperature.
Can fan status be monitored? Does it need to be? (rpm too high/too low)Yes, fans can and should be monitored to see any malfunctions. Specifications can be found here: https://noctua.at/media/wysiwyg/Noctua_PWM_specifications_white_paper.pdf
How many cells? 

How many thermistors? 


How many voltage measurements? 
How do you access the thermistors and cell voltages for all of the cells? 
How do you access the cell voltages?access is through the isospi chip, and to the ltc7811, we can use the ltc_afe driver for that. 

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



  • No labels