Battery management system and method for transmitting data in a battery management system

Abstract

Embodiments of the invention relate to a battery management system and a method for transmitting data in a battery management system. The invention relates to a method, in particular a method for a battery management system. According to an embodiment, the method comprises providing a digital message comprising a plurality of frames, wherein the plurality of frames comprises an ID frame, at least one data frame, and a checksum frame. The checksum frame comprises a checksum value computed based on data contained in the other frames. The method further comprises generating a CAN message, wherein the data contained in the data frame(s) and the checksum frame is inserted into a data field of the CAN message, and wherein an identifier contained in the ID frame is inserted into an ID field of the CAN message. The method further comprises transmitting the CAN message via a CAN bus line and receiving the CAN message and reconstructing the digital message.

Description

TECHNICAL FIELD

[0001] The present invention relates to the field of battery management systems and methods pertaining thereto. BACKGROUND

[0002] A battery management system (BMS) has the task of monitoring the charging and discharging of a battery (also referred to as battery pack) built from a plurality of battery cells or battery blocks. The battery management system can comprise a plurality of modules (for example one module per battery cell), which can each communicate with a control unit. This control unit is often referred to as battery management unit (BMU). This communication can be implemented by means of a digital communication bus. For example, the BMU and the individual modules are arranged next to each other in a daisy chain. The BMU can be considered the master node of the communication bus, while the individual modules comprising a cell supervision circuit (CSC) form slave nodes. Each bus node has an address, and each node forwards a received message to the next bus node until the message reaches the bus node to which the message is addressed. The structure and the mode of operation of a daisy chain bus topology are known per se (see, for example, US 2017 / 0346308 A1) and are not explained further here.

[0003] The known communication bus employed in battery management systems uses frame-based serial data transmission, in which for the data transmission so-called UARTs (universal asynchronous receiver transmitter) can be used. A UART transmits data as a serial digital data stream with fixed data frames (UART frames), which usually comprise a start bit, five to nine data bits, optionally a parity bit for identifying transmission errors, and an end bit.

[0004] In the automotive sector, various electronic control units (ECU) usually communicate by means of CAN (controller area network) or other fieldbus systems. In order to be able to couple a UART-based bus system of a battery management system to an ECU by means of CAN, a special interface is required, which can be referred to as CAN / UART converter. Such a CAN / UART converter is relatively complex to implement. At least two microcontrollers are required; one microcontroller for the protocol processing of the CAN protocol and one microcontroller for safety applications. The software executed by the microcontrollers has to meet the requirements according to ASIL-D (automotive safety integrity level D according to ISO 26262). In particular in distributed systems with multiple daisy chains that should communicate with the ECUs, multiple CAN / UART converters are also required, which further increases the technical and economic outlay. Furthermore, the known CAN / UART converters do not easily support so-called vector tools (CANalyzer) for analyzing the transmitted data.

[0005] The object of the present invention is to improve and more efficiently design existing systems while maintaining the same safety requirements (ASIL-D). SUMMARY

[0006] The above object is achieved by the method, the battery management system and the CAN / UART conversion module according to the present application. Various embodiments and further designs are outlined below.

[0007] The present invention relates to a method, in particular for a battery management system. According to an embodiment, the method comprises providing a digital message comprising a plurality of frames, wherein the plurality of frames comprises an ID frame, at least one data frame, and a checksum frame. The checksum frame comprises a checksum value computed based on data contained in the other frames. The method further comprises generating a CAN message, wherein the data contained in the data frame(s) and the checksum frame is inserted into a data field of the CAN message, and wherein the identifier contained in the ID frame is inserted into an ID field of the CAN message. The method further comprises transmitting the CAN message via a CAN bus line, and receiving the CAN message and reconstructing the digital message. Furthermore, a corresponding battery management system and a CAN / UART conversion module are described. BRIEF DESCRIPTION OF DRAWINGS

[0008] Embodiments are explained in more detail below with the help of the drawings. The illustrations are not necessarily true to scale and the embodiments are not limited to the aspects shown. Rather, it is noted that the principles on which the embodiments are based are shown. In the drawings, the following is shown:

[0009] Figure 1 An example of a bus system with a BMU and three CSC modules connected thereto is shown schematically, the CSC modules being connected with a battery stack.

[0010] Figure 2 An example of a distributed system with a BMU and two CSC module chains connected thereto is shown, wherein the BMU has a CAN interface and each of the CSC module chains comprises a CAN / UART conversion module.

[0011] Figure 3 An example of a possible implementation of a CAN / UART conversion module is shown, wherein separate microcontrollers are used for protocol handling and for safety applications, respectively.

[0012] Figure 4 An example of a more efficient implementation is shown, wherein no protocol handler and safety microcontroller are required due to the specific way of data transmission.

[0013] Figure 5 The structure of a CAN message is shown schematically.

[0014] Figure 6 An establishment of one of the UART frames for communication with a CSC module is shown by way of example.

[0015] Figure 7 The embedding of the UART frame into a CAN message with end-to-end protection of the UART frame is shown schematically.

[0016] Figure 8 The encoding of the address of the CSC module using the basic ID field of the CAN message is shown.

[0017] Figure 9 The reconstruction of the UART frame from the CAN message is shown schematically.

[0018] Figure 10 is a flow chart for illustrating an embodiment of the method described herein for data exchange between a CSC module and a battery monitoring unit (BMU). DETAILED DESCRIPTION

[0019] Figure 1 An example of a battery management system (BMS) with a battery monitoring unit (BMU) 20 and a plurality of cell monitoring circuits (CSC) connected thereto is shown schematically. In the present example, three CSCs 31, 32 and 33 are connected in daisy chain fashion with the BMU 20. Depending on the application, significantly more than three CSCs can also be arranged next to each other. The BMU 20 and the CSCs 31, 32 and 33 are part of separate modules (also referred to as modules M0-M3 in Figure 1 ) which are galvanically separated from each other and can be arranged on various printed circuit boards (PCB). Alternatively, also a plurality of CSCs can be arranged on one PCB. The galvanic separation can be realized, for example, via capacitive coupling.

[0020] The battery 10 to be monitored can have a plurality of battery packs (groups of cell units), which in turn have a plurality of cell units. For example, a high-voltage lithium-ion battery with a nominal battery voltage of 400 V can have eight battery packs, which in turn have thirteen cell units each. Each CSC 31, 32 and 33 is connected with a group of cell units and receives the respective cell voltage. Depending on the application, also the temperature of the cell units can be detected. The galvanic separation mentioned can be necessary in order to decouple the different voltage levels of the individual series-connected cell units. The purpose and basic functionality of the BMU 20 and the CSCs 31-33 are known per se and are not explained in more detail here.

[0021] With regard to the communication between the BMU 20 and the CSCs 31-33, the BMU 20 characterizes the master bus node and the CSCs 31-33 the slave bus nodes. The individual modules M0-M3 can have a serial communication interface (e.g. UART) as inFigure 1 As shown, these serial communication interfaces are connected serially in a daisy chain via data lines. The shape and content of the UART data frame will be described in more detail later.

[0022] Figure 2 An example of a distributed BMS is shown, which has a BMU and two or more daisy chains with multiple CSCs. In this example, a first daisy chain with CSCs 31-33 (modules M1-M3) and a second daisy chain with CSCs 41-43 (modules M1'-M3') are connected to the BMU 20. The connection between the two daisy chains and the BMU 20 is indirect. The electronic control unit (ECU) including the BMU 20 also includes a CAN transceiver 21 to enable connection of the BMU to the CAN bus cable L. The chain of CSCs 31-33 is connected to the CAN bus cable L via a first CAN / UART converter 22, and the chain of CSCs 41-43 is connected to the CAN bus cable L via a second CAN / UART converter 23. Figure 1 Compared to the system, the first daisy chain module M0 (and similarly, the second daisy chain module M0') does not include the BMU, but includes the mentioned CAN / UART converters 22 and 23.

[0023] use Figure 2 The structure shown allows for the coupling of a distributed BMS with multiple CSC chains to a BMU located within the central ECU. This "smart" integration into the BMU is typically implemented through more or less complex software. Nevertheless, CAN / UART converters 22 and 23 can be relatively costly modules to implement, especially given the relatively high functional safety requirements, particularly in the automotive sector. Therefore, various standards (especially ISO 26262) are necessary, and ASIL-D (Safety Integrity Level) is generally required in vehicle batteries. Figure 2 The diagram also shows the VT analysis tool used to analyze data traffic on the CAN bus. Such analysis tools (such as the vector tool mentioned at the beginning) are known in themselves and can play an important role in the development process.

[0024] Figure 3 This section shows examples of possible implementations of a CAN / UART converter. Such a module (see...) Figure 2 Modules M0 and M0', according to the example shown, include a CAN transceiver 220, a microcontroller 221 operating as a protocol processor, a further microcontroller 222 (security controller) implementing security applications therein, and a first CSC module for connecting the daisy chain (see [link to CSC module]). Figure 2 , UART transceiver 223 of modules M1 and M1'.

[0025] The CAN transceiver 220 and the UART transceiver 223 provide essentially the functionality of layer 1 (physical layer) of the generally known OSI model (see ISO / IEC 7498-1 : 1994) according to the respective standards. The microcontroller 221, also called protocol processor, provides essentially the functionality of layer 2 (data link layer) of the OSI model, i.e. those functions which are also called "CAN protocol" and which relate to the CAN message format. The microcontroller 222 provides safety functions which are necessary to fulfill the high requirements of ASIL-D. The UART transceiver 223 is connected via a galvanic separation to the first CSC of the daisy chain, which galvanic separation is symbolically represented in Figure 3 by a capacitor. The microcontroller 222 is essentially configured to convert a received CAN frame into a UART frame, wherein for data security a CRC value has to be calculated with respect to the data contained in the UART frame, since this frame conversion leads to a change of data.

[0026] The implementation of the protocol processor functionality (microcontroller 221 ) and the safety functionality (microcontroller 222) can be technically relatively cost-intensive. Furthermore, Figure 3 The CAN / UART converter structure in the prior art does not support functions for analyzing the data traffic, which can be valuable aids in the development process. Such analysis functions are supported by the CAN protocol and are generally known under the name "vector tool". In this respect, the software tool of the company Vector Informatik GmbH is practically the industry standard and is also known under the names CANalyzer and CANoe. With the aid of the analysis tool VT (see Figure 2 ) it is possible to "listen" to the data traffic on the CAN bus line as described and to assign this data traffic to specific transmitters and receivers.

[0027] The embodiments described in the following aim at simplifying and more efficiently designing the implementation of the CAN / UART conversion and (optionally) at enabling the use of a vector tool or similar analysis tool in a battery management system. Figure 4A CAN / UART converter according to an embodiment is shown. According to the example shown, the CAN / UART converter includes only a CAN transceiver 220, relatively simple logic circuitry 224, and a UART transceiver 223. As in the previous example, the CAN transceiver 220 and UART transceiver 223 essentially provide Layer 1 functionality of the OSI model. The function of logic circuitry 224 will be discussed in more detail later. The task of logic circuitry 224 is to convert the bit stream of CAN messages received by the CAN transceiver into UART frames, wherein the data included in the UART frames (including CRC values) has been fully included within the CAN messages. That is, logic circuitry 224 can actually receive the bits to be packed into UART frames directly from the CAN messages without having to perform complex bit operations (see also...). Figure 7 ).

[0028] Before discussing the actual CAN / UART conversion, using Figure 5 This briefly illustrates the known CAN message format. CAN supports two message formats that differ essentially in the length of the ID field. Figure 5 In the standard format (basic frame format) shown, the ID field is 11 bits long, while in the extended format (extended frame format), it is 29 bits long. The bits or bit fields of the CAN message—SOF (Start of Frame), RTR (Remote Transmission Request), IDE (Identifier Extension), RES (Reserved), DLC (Data Length Code), DATA (Data Field), CRC (Cyclic Redundancy Check), DEL (Delimiter), ACK (Acknowledgment), and EOF (End of Frame)—are well-known and will not be elaborated upon here. The 11-bit ID field in the standard format is also called the basic ID. This basic ID also exists in the extended format, where the remaining 18 bits are called the extended ID. This ID must be unique and identifies the message and indicates its priority. If two bus nodes attempt to send messages with the same ID, an error will occur.

[0029] Figure 6 An exemplary set of UART frames is shown, such as those that can be used for communication with the CSC module. According to... Figure 6 Message U (a group of UART frames) consists of six frames F1-F6, each including a start bit, eight data bits, and one stop bit. Asynchronous data transmission is characterized by the transmitter not transmitting its own clock signal to the receiver on its own control line. Instead, the receiver synchronizes on the frame length (which corresponds to the time interval between the start and stop bits) and the set bit rate. Synchronization frame F1 contains no valid data and is used only for synchronization. ID frame F2 includes an identifier representing a specific CSC module. Figure 3In the example of Fig. 1, there are six modules M1, M2, M3, M1', M2' and M3', which can be assigned, for example, the IDs 0001, 0010, 0011, 0100, 0101 and 0110.

[0030] The address frame F3 is used for addressing the units assigned to the CSC module. As mentioned, the CSC module can monitor a plurality of individual battery units. The data frames F4 and F5 comprise the data (16-bit words) to be transmitted, and the CRC frame F6 comprises the CRC checksum. It is understood that, Figure 6 The message U shown with six frames F1-F6 is only one example. Depending on the implementation, the message U can also be structured differently. Irrespective of the implementation, in any case a unique ID can be assigned to each CSC module, and a unique address to each unit monitored by the CSC module.

[0031] Figure 7 A scheme is shown how the message U comprising a set of UART frames is packed / embedded into a CAN message, so that the CAN / UART conversion can be comparatively simple. Depending on the communication direction, the embedding of the message U takes place in the BMU (message from the BMU to the CSC module) or in the CAN / UART converter (message from the CSC module to the BMU). When the message U is embedded into the CAN message, all redundant data such as start and end bits (and possibly parity bits) can be omitted. Likewise, the synchronization frame F1 need not be packed into the CAN message, since the synchronization frame F1 does not comprise information.

[0032] The identifier contained in the ID frame F2 is transmitted in the subfield of the base ID of the CAN message. For example, the identifier of the CSC module is written into the four bits with the lowest significant bit value (the least significant bits). The address frame F3, the data frames F4 and F5, and the CRC frame F6 are written into the data field DATA of the CAN message, wherein the CRC value contained in the CRC frame F6 can be calculated, for example, with respect to the data of the frames F1-F5 (or alternatively F2-F5). Since the CRC value is generated in the transmitter of the message U and is transmitted together in the CAN message to the receiver, an end-to-end protection takes place. Special security functions are therefore no longer required in the CAN / UART converter.

[0033] In order to enable an analysis of the communication by means of standardized analysis tools (vector tools, such as CANalyzer, CANoe, etc.), the remaining seven bits of the basic ID are used for transmitting meta data. For example, the address of the battery cell (content of the address frame F3) and further information about the transmitted data can be stored in the basic ID. For example, information about the type of the data in the frames F4 and F5 (such as a temperature value or a voltage value) can also be stored. Furthermore, the basic ID can comprise the direction of the communication (from BMU or to BMU). For example, the direction of the communication can be indicated by the bit of the basic ID having the highest bit value (most significant bit, bit 10). Further information can for example be encoded by means of a look-up table LUT and stored in the subfield having bits 4-9. As mentioned, bits 0-3 of the basic ID characterize the identifier of the relevant CSC module. According to an embodiment, the further information encoded by means of the look-up table comprises the address contained in the address frame. In this case, the content of the address frame does not necessarily need to be transmitted in the CAN data field (this would be redundant).

[0034] Figure 8 An example of a basic ID of a CAN message "filled" with information from a UART frame is schematically shown. On the left is the bit having the highest bit value (MSB, bit 10). This indicates the direction of the communication, wherein in the shown example "0" indicates that the message is transmitted from the CSC module (bus slave) to the BMU (bus master). In contrast, "1" indicates that the message is transmitted from the BMU to the CSC module. The next six bits (bits 4-9) characterize the address of the battery cell and, if necessary, further information (meta data), such as the type of the transmitted data (temperature, voltage, etc.). As mentioned, the four bits having the lowest bit value (bits 0-3) are the identifier of the CSC module. This identifier can be directly extracted from the ID frame F1 (see Figure 6 ).

[0035] Figure 9 Reconstruction of a UART frame from a CAN message is schematically shown. The content of the data field (in the present example 32 bits) can be directly distributed over the frames F3-F6 and supplemented with start and end bits. The content of the ID frame F2 can be directly obtained from the basic ID field of the CAN message. The synchronization frame F1 can simply be supplemented, since no information from the CAN message is required for this. As mentioned, the address does not necessarily need to be transmitted in the CAN data field, but the information can also (if necessary encoded by means of a look-up table LUT) be contained in the ID field. In this case, the address contained in the address frame F3 can also be reconstructed on the basis of the information contained in the ID field of the CAN message.

[0036] The receiver of the frames F1-F6 (message U) can check the CRC value transmitted in the CRC frame and thus determine whether the integrity of the data is given. The CRC value is generated directly in the transmitter and is not changed at the CAN / UART conversion and is simply passed to the receiver (in the CRC frame F6). No further functionality for data security is needed in the CAN / UART converter.

[0037] In the following, embodiments described herein and their working principles are summarized. Figure 10 is a flow chart illustrating an example of the method described herein for exchanging data between a CSC module (see Figure 2 , CSC modules M2, M3, etc.) and a BMU (see Figure 2 , BMU 20). According to Figure 10 , the method comprises providing a digital message U (see Figure 6 ) comprising a plurality of frames, wherein the plurality of frames comprises an ID frame F2, an address frame F3, at least one data frame F4, F5, and a checksum frame F6 comprising a checksum value calculated based on data contained in the other frames (see Figure 10 , step S1). The method further comprises generating a CAN message F (see Figure 7 ), wherein the data contained in the address frame F3, the data frames F4, F5, and the checksum frame F6 are inserted into a data field of the CAN message (see Figure 10 , step S2a), and wherein an identifier contained in the ID frame is inserted into an ID field of the CAN message (see Figure 10 , step S2b). The generation of the CAN message F from the UART message U has been set forth above with reference to Figure 7 and Figure 8 . As described, a CRC value is transmitted with the CAN message F, which fact enables an end-to-end protection of the transmitted data. Finally, the CAN message F is sent via a CAN bus line (see Figure 10 , step S3). The CAN message F is received by a receiver and therefrom the digital message U (or the data / information contained in this digital message) is reconstructed (see Figure 10 , step S4). Depending on the CRC value transmitted in the CAN message F, the integrity of the original message U can be checked.

[0038] In Figure 10The data transmission shown in Fig. 1 is possible in both directions, i.e. from the BMU 20 to the CSC modules M1, M2,..., M1 ', M2', etc. (downlink direction) and from the CSC modules to the BMU (uplink direction). In the uplink communication, the digital message U is provided by one of the CSC modules, i.e. step S1 is performed by the respective CSC module. The generation of the CAN message F (steps S2a and S2b) and the transmission of the CAN message F (step S3) are performed by the CAN / UART conversion module M0, M0' (see Fig. 1 ) to which the transmitting CSC module is coupled via the data line. In the BMU 20, the reception of the CAN message and the reconstruction of the original digital message U take place. Figure 2 ) are performed by the BMU. The transmitted CAN message is received (step S4) by one of the CAN / UART conversion modules M0, M0' (see Fig. 1 ). The CAN / UART conversion modules M0, M0' can identify from the ID field of the CAN message F to which CSC module the message is intended and reconstruct the original digital message U at least in that CAN / UART conversion module which is connected to the respective CSC module.

[0039] In the downlink communication, the digital message U is provided by the BMU 20, i.e. step S1 (including the calculation of the CRC value) is performed by the BMU. The generation of the CAN message F (steps S2a and S2b) and the transmission of the CAN message F (step S3) are also performed by the BMU. The transmitted CAN message is received (step S4) by one of the CAN / UART conversion modules M0, M0' (see Fig. 1 ). The CAN / UART conversion modules M0, M0' can identify from the ID field of the CAN message F to which CSC module the message is intended and reconstruct the original digital message U at least in that CAN / UART conversion module which is connected to the respective CSC module. Figure 2

[0040] According to the examples described herein, in the case of downlink communication, the method comprises forwarding the reconstructed digital message U via the data line by means of the serial data transmission to one or more CSC modules determined by an identifier included in the ID frame. The identifier can also characterize a broadcast, i.e. in this case all CSC modules are addressed. The CSC modules M1, M2,..., M1 ', M2', etc. can each be coupled to a plurality of battery cells. The addresses contained in the address frame F3 (cf. Fig. 2) indicate the specific battery cells to which the data contained in the at least one data frame F4, F5 relates. These data can characterize, inter alia in the case of uplink communication, the cell voltage and / or the cell temperature of the battery cells. In the case of downlink communication, the data contained in the data frame(s) F4, F5 can characterize, for example, control commands, configuration data and / or the like. Figure 7 ) are performed by the BMU. The transmitted CAN message is received (step S4) by one of the CAN / UART conversion modules M0, M0' (see Fig. 1 ). The CAN / UART conversion modules M0, M0' can identify from the ID field of the CAN message F to which CSC module the message is intended and reconstruct the original digital message U at least in that CAN / UART conversion module which is connected to the respective CSC module.

[0041] ​According to a specific embodiment, the mentioned generation of a CAN message F based on a digital message U further comprises encoding an address contained in the address frame F3 and inserting the encoded address into the ID field of the CAN message F. The encoding can for example be done by means of a look-up table (see Figure 7 , look-up table LUT). Furthermore, a bit can be set in the ID field of the CAN message F which shows whether the CAN message is transmitted to or from the battery monitoring unit (20) or vice versa (see Figure 8 ). Thus, this bit (direction bit) shows whether a specific message is an uplink or downlink communication.

[0042] A further embodiment relates to a battery management system (BMS) having a battery monitoring unit (BMU) which can for example be contained in an ECU of a vehicle, a conversion module (see Figure 2 , CAN / UART converter M0) which is connected with the BMU via a CAN bus line, and a plurality of daisy-chained CSC modules (see Figure 2 , for example CSC modules M1-M3) which are connected with the conversion module by means of data lines. The conversion module and the CSC modules are configured to exchange digital messages U via the data lines by means of an asynchronous serial data transmission, wherein the digital messages respectively comprise a plurality of frames (see Figure 6 ). The plurality of frames respectively comprises an ID frame, an address frame, one or more data frames, and a checksum frame (CRC frame). The checksum frame comprises a checksum value which is calculated based on the data contained in the other frames (which enables the mentioned end-to-end protection of the data). The conversion module is configured to generate a corresponding CAN message F (for uplink communication) based on a digital message U received from one of the CRC modules, wherein the data contained in the address frame, the data frame(s), and the checksum frame are inserted into the data field of the CAN message F, and wherein the identifier contained in the ID frame is inserted into the ID field of the CAN message. The ID field and the data field of the CAN message are standardized as set out in detail above. Subsequently, the conversion module can send the CAN message to the BMU via the CAN bus line. The BMU is configured to receive the CAN message F from the conversion module and to reconstruct the information contained in the digital message U which generated the CAN message.

[0043] The CAN / UART conversion can be implemented, for example, by a logic circuit comprised in the conversion module M0. The logic circuit can comprise, for example, a finite automaton (also referred to as a finite state machine, FSM). Furthermore, the logic circuit can comprise hard-wired or one-time programmable logic as well as a processor configured to execute software instructions and thereby provide the necessary functionality. It will be appreciated that various practically equivalent alternatives to implement the functionality of the embodiments described herein are known to the skilled person.

Claims

1. A method for a battery management system, the method having the steps of: providing a digital message (U) comprising a plurality of frames (F2, F3, F4, F5, F6), wherein the plurality of frames comprises an ID frame (F2), at least one data frame (F4, F5), and a checksum frame (F6) containing a checksum value computed based on data contained in the other frames; generating a CAN message, wherein the data contained in the data frames (F4, F5) and the checksum frame (F6) are inserted into a data field of the CAN message, and wherein an identifier contained in the ID frame is inserted into an ID field of the CAN message; sending the CAN message via a CAN bus line; receiving the CAN message; checking the integrity of the digital message (U) in dependence on the data of the checksum frame (F6) inserted into the data field of the CAN message; reconstructing the digital message (U) based on the CAN message.

2. The method according to claim 1, wherein the digital message (U) further comprises an address frame (F3).

3. The method according to claim 2, wherein the digital message (U) is provided by one of a plurality of battery cell monitoring modules (M1-M3) of a battery management system, which battery cell monitoring module has the identifier contained in the ID frame, and wherein the CAN message is received by a battery monitoring unit (20) of the battery management system.

4. The method according to claim 1 or 2, wherein the digital message (U) is provided by a battery monitoring unit (20) of a battery management system, and wherein the CAN message is received by a conversion module (M0) reconstructing the digital message (U).

5. The method according to claim 1, further comprising: forwarding the reconstructed digital message via a data line by means of a serial data transmission to one or more receivers determined by the identifier contained in the ID frame.

6. The method according to claim 5, wherein the receivers are battery cell monitoring modules (M1-M3) connected to the data line.

7. The method according to claim 6, wherein the battery cell monitoring modules (M1-M3) are connected in a daisy chain, and a first one of the battery cell monitoring modules (M1-M3) is connected to the data line.

8. The method according to claim 3, wherein the battery cell monitoring modules (M1-M3) are coupled to a plurality of battery cells, and an address contained in the address frame (F3) represents a particular battery cell, and data contained in the at least one data frame (F4, F5) is related to the particular battery cell.

9. The method according to claim 8, wherein the data contained in the at least one data frame (F4, F5) characterizes a cell voltage and / or a cell temperature of the battery cell.

10. The method according to claim 2, wherein generating the CAN message further comprises: encoding the address contained in the address frame (F3) and inserting the encoded address into the ID field of the CAN message, and / or wherein the data contained in the address frame (F3) is inserted into the data field of the CAN message.

11. The method according to claim 10, wherein the encoding is performed by means of a look-up table.

12. The method according to claim 4, wherein generating the CAN message further comprises: setting a bit in the ID field of the CAN message, the bit indicating whether the CAN message is transmitted by or to the battery monitoring unit (20).

13. A battery management system, the battery management system having: a battery monitoring unit (20), a conversion module (M0) connected with the battery monitoring unit (20) via a CAN bus line; a plurality of battery cell monitoring modules (M1-M3) connected in a daisy chain, the battery cell monitoring modules being connected with the conversion module (M0) by means of data lines, wherein the conversion module (M0) and the battery cell monitoring modules (M1-M3) are configured to exchange digital messages (U) via the data lines by means of asynchronous serial data transmission, wherein the digital messages (U) comprise a plurality of frames (F2, F3, F4, F5, F6) each, the plurality of frames comprising an ID frame (F2), at least one data frame (F4, F5), and a checksum frame (F6) each, the checksum frame containing a checksum value calculated based on data contained in the other frames; and wherein the conversion module (M0) is configured to: generate a CAN message based on a digital message (U) received by one of the battery cell monitoring modules (M1-M3), wherein the data contained in the data frames (F4, F5) and the checksum frame (F6) is inserted into the data field of the CAN message, and wherein an identifier contained in the ID frame is inserted into the ID field of the CAN message; and send the CAN message to the battery monitoring unit (20) via a CAN bus line.

14. The battery management system according to claim 13, wherein the battery monitoring unit (20) is configured to receive the CAN message from the conversion module (M0), the CAN message being generated from the digital message (U), and to reconstruct the information contained in the digital message (U).

15. A CAN / UART conversion module (M0), the CAN / UART conversion module having: a UART interface for connecting a plurality of battery cell monitoring modules (M1-M3) by means of data lines, the plurality of battery cell monitoring modules being connected in a daisy chain; a CAN transceiver for connecting a battery monitoring unit (20) by means of a CAN bus line; a logic circuit, the logic circuit being configured to: transmitting and receiving digital messages (U) via the data line by means of asynchronous serial data transmission, wherein the digital messages (U) each comprise a plurality of frames (F2, F3, F4, F5, F6), which each comprise an ID frame (F2), at least one data frame (F4, F5) and a checksum frame (F6) containing a checksum value calculated on the basis of the data contained in the other frames; generating a CAN message on the basis of the received digital message (U), wherein the data contained in the data frames (F4, F5) and the checksum frame (F6) are inserted into a data field of the CAN message, and wherein an identifier contained in the ID frame is inserted into an ID field of the CAN message; and sending the CAN message via the CAN bus line.

16. CAN / UART conversion module according to claim 15, wherein the logic circuit is further configured to receive a CAN message and to reconstruct the information contained in the digital message (U) from which the CAN message was generated and to send the reconstructed digital message via the data line.

Images