Download EVSTF-07-06e

EVSTF-07-06e
BMS Warning Signal Testing – Basic Requirements (EVS-GTR Task Force 9)
FORMAT-1
OEM
Description of Device Under Test (DUT)
REESS Emulator
Output Signals
No.
#1a Distributed BMS (one master controller and one
slave controller per module).
Up to two modules emulated.
#1a Centralised BMS monitoring whole REESS
(no slave controllers).
#6
Cell measuring circuit measures cell voltage and
temperatures which are communicated via CAN
to a battery controller. The battery controller
also measures the pack voltage, battery current
and does isolation measurement. All data is then
transmitted to a Master BMS that takes all
strategic decisions. The warning testing could be
done by only sending CAN signals to either
battery controller unit or to BMS.
36
1.5 x no.
of REESS
cells
197
1
Signal
Type
Analogue
voltage
(0.0V –
6.0V)
Analogue
voltage
(0.0V –
6.0V)
Analogue
or
CAN
BMS Output
Monitor
Signals
Bus
No.
Type
2
(min.)
CAN
1
CAN
1
CAN
Comments:
24 voltage and 12 temp signal outputs required from REESS Emulator.
Typically circa 120 cells. Therefore, up to 180 signal outputs from REESS
Emulator.
Connecting analogue signals to the BMS system is very difficult. One
solution could be to test the cell measuring circuit by their self and then test
the BMS warning by emulating cell temperatures on CAN or other used
communication data bus. The problem is that all OEM use different
solutions for the cell measurement communication.
FORMAT-2
OEM
Description of Device Under Test (DUT)
#1b
Distributed BMS
One master controller and one slave controller
per module.
Voltage and temperature emulated for 1 module.
Test Setup Requirements






24 voltage outputs (0.0-6.0 V range).
At least 12 temperature outputs.
Physical HV components (V & I sensors, relays, etc) present or
emulated.
Network signal emulator for the remaining modules.
Network signal emulator and logger for the vehicle side of BMS
(must have computation ability for signal protection signals).
Live monitoring of ~20 network signals on vehicle side to check
battery health and to measure test result.
Comments
Exact numbers of physical signals required
will differ between battery architectures.
#1b
Centralised BMS
Single master monitoring whole REESS (no slave
controllers).
Voltage and temperature emulated for all cells.






#2
Distributed BMS
One or several ECUs and one slave controller per
one or two modules.




Voltage and temperature emulated for 5-8
modules.



#3
N voltage outputs (0.0-6.0 V range).
At least N/2 temperature outputs.
Physical HV sensors (e.g. HV voltage, HV current) present or
emulated.
Physical HV components (e.g. relays) present or emulated.
Network signal emulator and logger for the vehicle side of BMS
(must have computation ability for signal protection signals).
Live monitoring of ~20 network signals on vehicle side to check
battery health and to measure test result.
N = number of REESS cells in DUT.
80 - 120 voltage outputs (0.0-6.0 V range).
At least 12 temperature outputs.
Physical HV components (V & I sensors, relays, etc) present or
emulated.
PC emulating the remaining cells distributed via suitable
network signal.
Internal battery network between battery ECUs (when more
than one)
PC simulating concerned parts of the vehicle communication to
control and supervise the battery status.
Logging and monitoring of vehicle and battery internal
communication
Exact numbers of physical signals required
will differ between battery architectures.
Physical components might differ between
battery architectures.
Typical maximum of ~120 cells for centralised
BMS.
Exact numbers of physical signals required
will differ between battery architectures.
OEM #3 Commented that ….
…. our systems would have similar requirements regarding data channels, etc [i.e. similar to OEM #1] . Number of required cells is probably right (for the foreseeable future).
I’m not sure about the vehicle interface signal count, however.
A few additional comments…
If this was to be done with a BMS from a vehicle (and not a special system, provided by the manufacturer), it would be necessary in all cases to open up the battery
enclosure and remove the BMS related components. We do not have any systems which are completely external to the battery.
In addition to the required number of individual cell simulations, it would also be necessary to simulate total battery pack voltage, and potentially, module voltages. We
physically measure pack voltage, for example. It could be done with either a separate emulator or by connecting the cell emulators in series.
Depending on the specifics of the test condition, it may also be necessary to simulate current as we make current measurement. Again, it depends on the details of the test
condition but a current sensor may be necessary to assure that the system is correctly operating before introducing a fault. Current is not a safety parameter but lack of
current measurement does create a fault condition.
The emulator needs to generate signals which are appropriately coordinated to appear to be coming from a single battery. Voltages need to move together, temperatures
need to move similarly, etc. They also shouldn’t be identical. Again, this is under the assumption that a normal operating state is desired prior to introducing a fault
condition.
Finally, it is important to keep in mind that technology is continuing to move forward. Vehicle serial data may not continue to use CAN, for example. Wireless interface
between cells and BMS modules is being considered. So-called, “smart cells” are being discussed wherein the individual cell makes and communicates measurement values.
These may communicate with a system via a unique proprietary interface. Measurements other than voltage, temperature and current have also been proposed. Given the
timeline of GTR and subsequent enforcement, some of these technologies are likely to be in use within the useful life of the GTR.
#4
Our experts prefer Format 2 of the proposal. In particular:
All I/O of the BMS shall be connected either present or emulated : inputs are coming from the modules themselves (cell voltage & temperature), but we have I/O with other
ECUs as well :
-
internal informations coming from a battery Junction Box: pack voltage and current
informations coming from vehicle network (through CAN network)
control informations sent to the relays/cooling system (pump, fan)
FORMAT 2 description better fits with these needs, maybe missing a relation to the cooling components.
#5
For format 1:
REESS Emulator output signals depends on each system design configuration and signal type (Analogue voltage) will be different by cell/module design (including cell
chemistry such as Li-ion batteries, Ni-MH or lead acid batteries).
We support all the comments on Format 1.
For format 2:
According to OEM#3 comment para.5, all OEM might be supposed to use a kind of emulator in the development stage, software debug or FMEA testing and so on. A question
will be raised if the testing body can validate the emulator as appropriate. We consider that it is important to understand what is necessary for validate BMS warning system
by themselves.
Para. 6 notices our concern in the simple manner.