4.3. BMS Module

4.3.1. Module Files

4.3.1.1. Driver

  • src/app/application/bms/bms.c

  • src/app/application/bms/bms.h

4.3.1.2. Configuration

  • src/app/application/config/bms_cfg.h

4.3.1.3. Unit Test

  • tests/unit/app/application/bms/test_bms.c

4.3.2. Detailed Description

A finite state machine with two main states (STANDBY and NORMAL) defines the BMS behaviour. STANDBY corresponds to the state where all the contactors are open and NORMAL corresponds to a state where the contactors are closed to allow current flowing. The transition between the main states is made in response to CAN requests read from the data-exchange module (database). The state machine transitions into an initializing state after start up and waits until it is driven via CAN into STANDBY. The BMS will automatically transition into ERROR state, once a malfunction is detected within the battery system that could be potentially dangerous. Additionally, the ERROR state prevents closing of the contactors and can only be left, if the cause of failure has been removed and a STANDBY request is sent to the state machine. A simplified flow chart of the BMS state machine and the possible transitions between the main states is depicted in the figure below.

# Copyright (c) 2010 - 2024, Fraunhofer-Gesellschaft zur Foerderung der angewandten Forschung e.V.
# All rights reserved.
#
# SPDX-License-Identifier: BSD-3-Clause
#
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
#
# 1. Redistributions of source code must retain the above copyright notice, this
#    list of conditions and the following disclaimer.
#
# 2. Redistributions in binary form must reproduce the above copyright notice,
#    this list of conditions and the following disclaimer in the documentation
#    and/or other materials provided with the distribution.
#
# 3. Neither the name of the copyright holder nor the names of its
#    contributors may be used to endorse or promote products derived from
#    this software without specific prior written permission.
#
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
# DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT HOLDER OR CONTRIBUTORS BE LIABLE
# FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
# DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
# SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER
# CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY,
# OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
# OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
#
# We kindly request you to use one or more of the following phrases to refer to
# foxBMS in your hardware, software, documentation or advertising materials:
#
# - "This product uses parts of foxBMS®"
# - "This product includes parts of foxBMS®"
# - "This product is derived from foxBMS®"

digraph bms_state {
    rankdir=TB;
    size="8,16"
    compound=true;
    node [shape = doublecircle]     nd_standby;
                                    nd_normal;
                                    nd_error;



    nd_standby                      [label=<<B>STANDBY</B>>];
    nd_normal                       [label=<<B>NORMAL</B>>];
    nd_error                        [label=<<B>ERROR</B>>];



    nd_standby -> nd_normal  [label=<<B>Discharge/Charge</B>>];
    nd_normal -> nd_standby  [label=<<B>Standby</B>>];
    nd_normal -> nd_normal
    nd_normal -> nd_error
    nd_error -> nd_standby


}

Fig. 4.2 BMS state flow diagram

All diagnosis flags are transmitted via CAN, allowing the superior control system to react accordingly. Diagnosis entries with a severity of Info and Warning flags are transmitted for information purpose only and no action is taken once a parameter threshold is violated and the respective flag is raised. In contrast, once a potentially hazardous situation is detected and an Error flag is raised, the BMS will subsequently switch, with the configured delay time to ERROR state and open the contactors. As soon as an error condition is detected by the BMS, the BMS will signal this the superimposed control system by setting EmergencyShutoff flag in CAN message f_BmsState.

Special attention must be paid to overcurrent errors when disconnecting the battery system from the application, because of the imminent danger of permanently welded contactors caused by erroneous switching actions. The contacts of a contactor can be welded, when attempting to disconnect the battery system while a current higher than the maximum break current of the contactor is flowing and thus the battery system cannot be disconnected from the application. In the worst-case, this could lead to permanent damage or even destruction of the battery system, in case the current cannot be interrupted or controlled. To prevent this from happening in an over-current scenario the BMS waits until the fuse of the battery system has been triggered and the current has been interrupted. Only then will the contactors be opened. This guarantees a maximum of safety while trying to maximize the contactor service life.