methods
1 GW
Thanks for reading.
Assumptions: We are talking about a distributed BMS, not a monolithic BMS. In this case we have between one and dozens of slave modules embedded in cell groups of 4-12S, communicating over a private dedicated isoSPI bus, and the Master is charged with directing the slave units (when and how to balance, what to report, etc) and interfacing with the outside world. We assume that the Master buffers/protects the Slave modules from the open CAN buss (Where many adversarial events can occur) and the master has sole control over the primary Contactor, Precharge circuit, and carries such responsibilities as reading current sensors, monitoring leakage currents, accepting/transmitting emergency communications over a CAN bus, and broadcasting standard telemetry data.
With that assumption, lets assume worst case:
CAN buss running at 1Mhz
Extended packets or proprietary protocol
Busy primary CAN bus... lots that needs to be filtered out... consider it an adversarial CAN buss where an idiot wants to flood us, trip us up, etc. Assume it is wired into WiFi straight to North Korea.
The Question high level:
How many object types would the Master have to receive in real time?
How many object types would the Master have to process non-real time?
How many object types would the Master have to Transmit: Real time, broadcast, and asynchronous?
Constraints
We are trying to implement a LOW COST solution that covers a broad range... so no "ultimate solutions"
Transmit hardware level
Do we need a $1 super simple CAN chip with a basic 2 level deep buffer with a little masking and filtering... or a very fancy ?($7) chip that handles everything under the sun?
Intermediate
Do we need a chip (uController, FPGA, or other) between our CAN chip and our Processor to FIFO and unpack complex messages... thereby allowing the primary MCU to be more deterministic and focused on the job of BMS'ing.... or... do we try to keep communication complexity down far enough to actually handle the CAN business right on the primary MCU (where MCU would need to handle all the slaves and peripherals... AND ... the CAN bus)
Primary MCU
I believe that to ensure we glide through qualification that the Master should be deterministic... at time 0... or time 1000000000.... I can tell you exactly what it has done, is doing, and will do next (yes this is easy to accomplish with a state machine and time slicing... where one time slice is dedicated to servicing interrupts)
Go big, or go home
If I try to handle the CAN on the MCU I must strictly limit the amount of communication I tolerate and I will need to use a higher end CAN chip. In this case I would guarantee that I respond to an EMERGENCY object within Xus... and that I would accept "requests" in a lossy-queue or asynchronous matter. I would need to only broadcast per-programmed packets and I would not want to respond to data requests on any sort of recurring basis. I would filter nearly everything out at the hardware level and I would bias toward ignoring CAN and focusing on Battery state and safety.
Going big means I use either a basic or complex CAN chip along with a (pretty small) dedicated MCU which does nothing but handle CAN. My primary MCU would update this chip with "fresh data" as it saw fit, accept emergency interrupts from this chip, and read deep buffers off the chip asynchronously. The CAN Buffer chip would be tasked with all the unpacking... such that data is "ready" by the time the primary MCU gets it.
So....
I have seen an implementation or two... but there are dozens and dozens of OEM's out there who do all sorts of crazy things on any number of CAN busses.
Does anyone have direct personal experience with arbitrating a situation like this?
I know how I would do it... and how others have done it... but I am also prone to steer off into the weeds and do geek stuff that others scratch their heads about (blame aerospace).
My instinct is to use the best CAN chip I can afford, stick a tiny uP on it to implement (say CANopen or ISOblahblah) and keep my primary MCU focused only on BMS duties in a deterministic way.
Second choice would be to run a really good CAN chip and bump my primary processor up to something faster that can handle both duties.
Simple is better.
Simple is cheaper.
Less is usually enough.
I am really only producing a "fill the crack" distributed BMS that AT MOST would serve as the equivalent to a "Demo Board" for OEM's developing around LTC based slave systems... but at worst would need to be good enough for Experimental Flight, very large batteries stored in the home, of course Cars and vehicles of every shape and size, and motorcycles/extreme bicycles.
thanks,
-methods
Assumptions: We are talking about a distributed BMS, not a monolithic BMS. In this case we have between one and dozens of slave modules embedded in cell groups of 4-12S, communicating over a private dedicated isoSPI bus, and the Master is charged with directing the slave units (when and how to balance, what to report, etc) and interfacing with the outside world. We assume that the Master buffers/protects the Slave modules from the open CAN buss (Where many adversarial events can occur) and the master has sole control over the primary Contactor, Precharge circuit, and carries such responsibilities as reading current sensors, monitoring leakage currents, accepting/transmitting emergency communications over a CAN bus, and broadcasting standard telemetry data.
With that assumption, lets assume worst case:
CAN buss running at 1Mhz
Extended packets or proprietary protocol
Busy primary CAN bus... lots that needs to be filtered out... consider it an adversarial CAN buss where an idiot wants to flood us, trip us up, etc. Assume it is wired into WiFi straight to North Korea.
The Question high level:
How many object types would the Master have to receive in real time?
How many object types would the Master have to process non-real time?
How many object types would the Master have to Transmit: Real time, broadcast, and asynchronous?
Constraints
We are trying to implement a LOW COST solution that covers a broad range... so no "ultimate solutions"
Transmit hardware level
Do we need a $1 super simple CAN chip with a basic 2 level deep buffer with a little masking and filtering... or a very fancy ?($7) chip that handles everything under the sun?
Intermediate
Do we need a chip (uController, FPGA, or other) between our CAN chip and our Processor to FIFO and unpack complex messages... thereby allowing the primary MCU to be more deterministic and focused on the job of BMS'ing.... or... do we try to keep communication complexity down far enough to actually handle the CAN business right on the primary MCU (where MCU would need to handle all the slaves and peripherals... AND ... the CAN bus)
Primary MCU
I believe that to ensure we glide through qualification that the Master should be deterministic... at time 0... or time 1000000000.... I can tell you exactly what it has done, is doing, and will do next (yes this is easy to accomplish with a state machine and time slicing... where one time slice is dedicated to servicing interrupts)
Go big, or go home
If I try to handle the CAN on the MCU I must strictly limit the amount of communication I tolerate and I will need to use a higher end CAN chip. In this case I would guarantee that I respond to an EMERGENCY object within Xus... and that I would accept "requests" in a lossy-queue or asynchronous matter. I would need to only broadcast per-programmed packets and I would not want to respond to data requests on any sort of recurring basis. I would filter nearly everything out at the hardware level and I would bias toward ignoring CAN and focusing on Battery state and safety.
Going big means I use either a basic or complex CAN chip along with a (pretty small) dedicated MCU which does nothing but handle CAN. My primary MCU would update this chip with "fresh data" as it saw fit, accept emergency interrupts from this chip, and read deep buffers off the chip asynchronously. The CAN Buffer chip would be tasked with all the unpacking... such that data is "ready" by the time the primary MCU gets it.
So....
I have seen an implementation or two... but there are dozens and dozens of OEM's out there who do all sorts of crazy things on any number of CAN busses.
Does anyone have direct personal experience with arbitrating a situation like this?
I know how I would do it... and how others have done it... but I am also prone to steer off into the weeds and do geek stuff that others scratch their heads about (blame aerospace).
My instinct is to use the best CAN chip I can afford, stick a tiny uP on it to implement (say CANopen or ISOblahblah) and keep my primary MCU focused only on BMS duties in a deterministic way.
Second choice would be to run a really good CAN chip and bump my primary processor up to something faster that can handle both duties.
Simple is better.
Simple is cheaper.
Less is usually enough.
I am really only producing a "fill the crack" distributed BMS that AT MOST would serve as the equivalent to a "Demo Board" for OEM's developing around LTC based slave systems... but at worst would need to be good enough for Experimental Flight, very large batteries stored in the home, of course Cars and vehicles of every shape and size, and motorcycles/extreme bicycles.
thanks,
-methods