Battery test multiprotocol conversion terminal and method

Abstract

This invention discloses a multi-protocol conversion terminal and method for battery testing. The terminal includes a housing, a protocol conversion module, and a main control module. The housing has a slot in which the protocol conversion module is pluggably installed. This module receives raw physical layer signals from external batteries and transmits them through the internal bus. Different modules are used for batteries with different communication protocols. The main control module connects to the internal bus and stores a DBC file defining all individual cell signals according to the maximum number of batteries in series. All transmitted raw messages are normalized and decoded according to this DBC file and uniformly encapsulated into standard CAN 2.0 data frames for output. The total voltage, current, and temperature signals are fixedly mapped to preset CAN IDs and byte positions. This invention enables test equipment that only supports CAN 2.0 to uniformly receive multi-protocol battery data, eliminating the need for reconfiguration when changing battery types, and allowing for reuse of the test process.

Description

Technical Field

[0001] This invention relates to the field of battery testing technology, and in particular to a battery testing multi-protocol conversion terminal and method. Background Technology

[0002] In the field of battery charge and discharge testing, mainstream laboratory testing equipment (such as Arbin and Neware) typically only supports the standard CAN 2.0 protocol communication, while the BMS (Battery Management System) of the battery under test may use multiple communication protocols such as CAN FD, RS-485, and Bluetooth. When the battery protocol is incompatible with the testing equipment, the equipment cannot directly read the battery data. Existing solutions mainly fall into the following categories:

[0003] Firstly, the dedicated gateway solution. This involves purchasing or customizing a corresponding protocol gateway for each protocol, which then performs the protocol conversion and outputs the data. In this solution, each protocol requires a dedicated gateway, and the original gateway cannot be reused when switching protocols. Hardware costs increase linearly with the number of protocols.

[0004] Secondly, there's the general-purpose converter and host computer solution. This approach uses commercially available converters such as USB-to-CAN and USB-to-RS-485 to collect data, which is then decoded using DBC parsing software run on a host PC. In this solution, the converters are scattered and the wiring is disorganized; DBC files are stored on different PCs, making unified management impossible; and the data is only displayed or stored on the host computer, not directly usable by the testing equipment.

[0005] Thirdly, the Raspberry Pi or PC external relay solution. A Raspberry Pi or PC is deployed at the test site to run a DBC-based parsing script, outputting the parsed data in a specific format. In this solution, different relay devices output signal mapping formats differently (some output CAN 2.0, some Modbus, and some JSON), requiring the test equipment to configure separate signal channels for each solution; changing battery models necessitates manually switching the DBC file or modifying the script; the changeover process is cumbersome, and established test procedures cannot be reused.

[0006] In summary, the existing technical solutions have the following shortcomings: (1) They cannot adapt to battery access with multiple physical layer protocols with a unified hardware architecture; (2) The output formats of different solutions are not uniform, and the test equipment needs to repeatedly configure the signal channels; (3) The ID mapping of the output signals of each solution is arbitrarily defined, and the established test process cannot be reused across batteries; (4) The DBC file is maintained one by one according to the number of battery strings, and the file needs to be switched frequently when changing models. Summary of the Invention

[0007] To address the problems in existing battery testing equipment that cannot receive multi-protocol battery data in a unified and fixed signal format and that testing processes cannot be reused across batteries, this invention proposes a multi-protocol conversion terminal and method for battery testing.

[0008] The specific technical solution is as follows: A battery testing multi-protocol conversion terminal, comprising:

[0009] A housing, wherein the housing is provided with at least one slot;

[0010] The protocol conversion module is installed in the card slot in a pluggable manner. Different protocol conversion modules are replaced with batteries of different communication protocols. The protocol conversion module is used to receive the raw physical layer signal of the external battery and pass the raw message through to the internal bus. It does not perform protocol type identification and data field parsing.

[0011] The main control module is connected to the internal bus and stores a DBC file that defines all individual cell signals according to the maximum number of batteries supported by the terminal. It is used to normalize and decode the original messages transmitted by all the protocol conversion modules according to the DBC file, and encapsulate the decoded engineering values ​​into standard CAN 2.0 data frames for output.

[0012] In the output standard CAN 2.0 data frame, the total voltage, current, and temperature signals are fixedly mapped to preset CAN IDs and byte bits, and do not change with the type of the protocol conversion module. Hardware adaptation for multiple physical layer protocols is achieved through pluggable protocol conversion modules. Each module only transmits data without parsing; the main control module uniformly decodes the data according to the DBC file and outputs it as a fixed-mapped CAN 2.0 frame. This allows test equipment that only supports CAN 2.0 to receive data from batteries using multiple protocols such as CAN FD, RS-485, and Bluetooth with the same signal channel configuration, eliminating the need to reconfigure the test equipment when changing models.

[0013] Furthermore, the protocol conversion module is a USB interface protocol adapter, including any one or more of the following: USB to CAN adapter, USB to CAN FD adapter, USB to RS-485 adapter, and USB to Bluetooth adapter.

[0014] Furthermore, the main control module automatically identifies the type of the protocol conversion module and its corresponding communication parameters by reading the VID / PID of the protocol conversion module and comparing it with the pre-stored VID / PID-protocol type mapping table.

[0015] Furthermore, the main control module is also used to: extract frame features from the initial communication frame sequence of the accessed battery, compare them with the built-in battery model feature library, automatically identify the battery model, and select the corresponding parsing path; the frame features include at least one of arbitration ID, data field fixed bits, frame interval, and verification method. Based on automatic module type identification, automatic battery model identification and automatic parsing path selection are further achieved through frame feature comparison, enabling the terminal to automatically complete the entire link configuration from physical layer matching to protocol parsing after module insertion and battery access, without manual intervention.

[0016] Furthermore, the DBC file defines all individual cell signals according to the maximum number of cells supported by the terminal;

[0017] When a low-number-count battery is connected, the main control module only uses the ID and signal bits corresponding to the actual number of serial cells in the DBC file for decoding. Other signal bits that exceed the actual number of serial cells are automatically ignored and not decoded.

[0018] Furthermore, when the main control module extracts complete data frames from the raw byte stream transparently transmitted by the protocol conversion module:

[0019] For CAN or CAN FD protocols, the complete CAN message is read through the CAN protocol stack. The CAN message contains at least the arbitration ID, data field, and DLC.

[0020] For serial port protocols, application layer data frames are extracted from continuous byte streams according to preset frame delimiting rules, which include at least one of fixed frame length, start flag plus length field, or end flag plus checksum.

[0021] Furthermore, the main control module is also used to: perform validity verification on the decoded engineering values ​​according to the signal range predefined in the DBC file, mark data that exceeds the range as invalid, and process them according to a preset strategy;

[0022] The preset strategy includes at least one of discarding the current frame, maintaining the previous valid value, or setting the alarm flag.

[0023] Furthermore, it also includes a network interface, through which the main control module supports remote access to upload, replace, or update DBC files; and the changes to the DBC files support hot loading, that is, the changed DBC files take effect immediately without restarting the terminal or interrupting the test task.

[0024] Furthermore, the slot is provided with a guide rib and an elastic buckle locking mechanism; after the protocol conversion module is inserted into place along the guide rib, it is automatically locked by the elastic buckle, and pressing the elastic buckle releases the lock to pull out the protocol conversion module.

[0025] A method for multi-protocol conversion in battery testing includes the following steps:

[0026] S1: Based on the communication protocol type of the battery under test, select the corresponding protocol conversion module and install it in the slot of the terminal housing in a pluggable manner. The protocol conversion module sends the received raw physical layer signal to the internal bus in a transparent manner, without performing protocol type identification and data field parsing.

[0027] S2: The main control module of the terminal loads the DBC file defining all individual cell signals according to the maximum number of batteries supported by the terminal;

[0028] S3: The protocol conversion module receives the original physical layer signal of the battery under test and transmits the original message to the main control module;

[0029] S4: The main control module extracts complete data frames from the raw byte stream transmitted by the protocol conversion module;

[0030] S5: The main control module normalizes and decodes the extracted complete data frame according to the DBC file to obtain the engineering value;

[0031] S6: The main control module encapsulates the engineering values ​​into a standard CAN 2.0 data frame for output, wherein the total voltage, current, and temperature signals are fixedly mapped to a preset CAN ID and byte bits.

[0032] The above technical solution has the following advantages or technical effects:

[0033] 1. This invention combines a pluggable card slot structure with a USB protocol adapter, enabling the same terminal host to adapt to multiple physical layer protocols such as CAN FD, RS-485, and Bluetooth by replacing a low-cost module. The terminal host can be reused permanently, significantly reducing hardware investment costs and avoiding the high expenses of purchasing dedicated gateways for each protocol.

[0034] 2. This invention adopts an architecture design that separates protocol conversion modules for transparent transmission and main control modules for unified parsing, thus integrating data from different protocols into the same DBC parsing engine. This eliminates the problem of inconsistent output formats of various gateways / transfer devices in existing solutions. Adding new protocol types only requires adding a USB dongle, without the need to develop any parsing code.

[0035] 3. This invention adopts a management strategy that unifies the design of DBC files based on the maximum number of batteries and automatically reuses batteries with low battery counts, eliminating the need to change DBC files during routine model changes; at the same time, DBC changes support remote hot loading, and the configuration takes effect immediately without interrupting testing, eliminating the need for repetitive software configuration work during model changes.

[0036] 4. This invention encapsulates the parsed engineering values ​​into a standard CAN 2.0 data frame and maps key signals such as total voltage, current, and temperature to preset CAN IDs and byte bits. This enables downstream charge and discharge test equipment to complete the test with the exact same signal channel configuration and test procedure, regardless of the battery protocol it is dealing with, thus realizing the direct reuse of the test procedure across battery types. Attached Figure Description

[0037] Figure 1 This is a schematic diagram of the overall architecture of the battery testing multi-protocol conversion terminal of the present invention;

[0038] Figure 2 This is a schematic diagram of the system data flow of the terminal of the present invention. Detailed Implementation

[0039] To make the technical solution of the present invention clearer, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0040] Example 1

[0041] like Figure 1 As shown, a battery testing multi-protocol conversion terminal includes: a housing, a protocol conversion module, a main control module, an internal bus, a storage module, a power supply module, and a network interface.

[0042] The housing is an integrated portable shell, internally housing the main control module, internal bus, storage module, and power module. The housing has at least one slot for the protocol conversion module to be inserted in a pluggable manner, allowing the module to be recessed or flush with the housing surface. An electrical interface (USB Type-A female connector in this embodiment) is located inside the slot, which is electrically connected to the internal bus. When the protocol conversion module is inserted, it establishes a communication connection with the main control module through this interface. The slot also includes guide ribs and a spring-loaded locking mechanism. The guide ribs guide the protocol conversion module into the slot in the correct direction, preventing reverse insertion or misalignment. The spring-loaded locking mechanism automatically locks the module after insertion, preventing it from loosening due to vibration or accidental contact during use. To remove the module, pressing the spring-loaded locking mechanism releases the lock, allowing the module to be pulled out. This mechanical design of the slot makes changing the protocol conversion module simple and quick, suitable for laboratory testing scenarios with frequent module changes.

[0043] Preferably, when multiple card slots are provided, each card slot has the same size and is adapted to the size of a standard USB dongle, so that protocol conversion modules of different protocol types can be inserted into any card slot for use.

[0044] The protocol conversion module is installed in the card slot in a pluggable manner. The protocol conversion module uses a commercially available universal USB interface protocol adapter, i.e., a USB dongle. Specifically, the protocol conversion module includes, but is not limited to, any one or more of the following: USB to CAN adapter, USB to CAN FD adapter, USB to RS-485 adapter, and USB to Bluetooth adapter. All of the above-mentioned USB dongles are mature commercially available products in the prior art, and their internal firmware and hardware structure are publicly known technologies.

[0045] In this invention, the protocol conversion module is only used to receive the raw physical layer signals from the external battery and transparently transmit the raw messages to the internal bus. Transparent transmission means that the protocol conversion module does not modify, parse, identify the protocol type, or perform data field parsing on the received raw messages; it directly forwards the byte stream of the raw messages to the internal bus unchanged. In this invention, the protocol conversion module only performs signal conversion and transport functions at the physical layer or data link layer, and does not involve any application layer data processing.

[0046] Different communication protocols require different protocol conversion modules. For example, when the battery BMS under test uses the CAN 2.0 protocol, select the USB to CAN adapter and insert it into the slot; when the battery BMS under test uses the CAN FD protocol, select the USB to CAN FD adapter and insert it into the slot; when the battery BMS under test uses the RS-485 protocol, select the USB to RS-485 adapter and insert it into the slot; when the battery BMS under test uses the Bluetooth protocol (such as BLE broadcast packets), select the USB to Bluetooth adapter and insert it into the slot. Since the protocol conversion modules have a unified USB interface and similar external dimensions, they can be interchangeably inserted into the same slot for use.

[0047] In this embodiment, the protocol conversion module uses a USB interface protocol adapter, which has the following advantages: First, the USB interface is a universal standard interface, and no additional adapter is needed to connect it to the main control module; second, commercially available USB dongles are inexpensive, significantly reducing the hardware cost of multi-protocol adaptation; third, the USB interface supports hot-swapping, which, combined with the plug-and-play design of the card slot, enables quick replacement of the protocol conversion module. Compared with the existing technology that requires purchasing or customizing a dedicated gateway for each protocol, this invention uses a USB dongle as the protocol conversion module, significantly reducing hardware costs.

[0048] The main control module is located inside the casing and uses a single-board computer (such as a Raspberry Pi) running a general-purpose operating system (such as Linux). Since version 2.6.25, the Linux kernel natively supports the SocketCAN protocol stack, enabling the transmission and reception of CAN / CAN FD frames via the standard socket() / bind() / read() / write() APIs. The main control module connects to the electrical interface of the card slot (such as a USB Type-A female connector) via an internal bus, thereby establishing data communication with the protocol conversion module inserted into the card slot.

[0049] The internal bus is located inside the housing and connects the main control module to each card slot. In this embodiment, the internal bus adopts a USB Hub bus topology. Specifically, the internal bus includes a USB Hub chip. The upstream port of the USB Hub chip connects to the USB host interface of the main control module, and the downstream ports connect to the USB interfaces of each card slot. When the protocol conversion module is inserted into a card slot, the main control module automatically detects the access of the new device through this USB Hub bus topology and performs USB enumeration on the protocol conversion module.

[0050] The main control module stores a DBC (Database CAN File). A DBC file is an industry-standard CAN database file used to define the ID, signal name, physical unit, scaling factor, and offset of messages in the CAN network. In this invention, the DBC file serves as the sole protocol configuration source; all original messages connected to the battery are parsed based on this DBC file.

[0051] Specifically, the main control module's non-volatile memory stores a DBC file that defines all individual cell signals according to the maximum number of battery cells supported by the terminal. Defining all individual cell signals according to the maximum number of battery cells means that the DBC file pre-defines all individual cell voltages, temperatures, and status signals for the maximum number of battery cells the terminal can support. For example, if the terminal is designed to support a maximum of 52 cells, the DBC file defines the individual cell voltage signals (e.g., IDs 0x100 to 0x10C, carrying 4 individual cell voltages per frame), the temperature signals, and other status signals for all 52 cells. When the number of battery cells connected is lower than this maximum (e.g., 14S or 16S batteries), the DBC file is still usable. The parsing engine only uses the IDs and signal bits corresponding to the actual number of cells in the DBC file for decoding; the remaining signal bits outside the actual number of cells are automatically ignored by the parsing engine since the BMS does not assign values ​​to them. This design of the DBC file allows one DBC file to cover all battery models not exceeding the maximum number of cells, eliminating the need to change the DBC file when changing battery models.

[0052] The main control module is also used to normalize and decode the original messages transmitted by all protocol conversion modules according to the aforementioned DBC file. Normalization decoding means that regardless of the physical layer protocol from which the original message originates (CAN 2.0, CAN FD, RS-485, Bluetooth, etc.), it completes the conversion from raw bytes to engineered values ​​through the same set of parsing rules (i.e., the signal start bit, data length, byte order, scaling factor, and offset defined in the same DBC file), thereby ensuring that all data connected to the battery is output in a unified physical quantity format (voltage, current, temperature, SOC, etc.).

[0053] The main control module is also used to encapsulate the decoded engineering values ​​into standard CAN 2.0 data frames for output. A standard CAN 2.0 data frame includes an 11-bit or 29-bit arbitration segment and a data field of up to 8 bytes. In the output standard CAN 2.0 data frame, key signals such as total voltage, current, and temperature are fixedly mapped to preset CAN IDs and byte positions. That is, the total voltage signal is always mapped to a specific byte position of the preset CAN ID X, the current signal is always mapped to a specific byte position of the preset CAN ID X+1, and the temperature signal is always mapped to a specific byte position of the preset CAN ID X+2. The mapping relationship between the above signals and CAN IDs and byte positions is fixed and does not change with the type of protocol conversion module. For example, the total voltage signal can be mapped to bytes 0-1 of CAN ID 0x200, the current signal to bytes 0-1 of CAN ID 0x201, and the temperature signal to bytes 0-1 of CAN ID 0x202. Regardless of whether a CAN FD battery, RS-485 battery, or Bluetooth battery is connected, the total voltage, current, and temperature signals always appear in the same CAN ID and the same byte positions in the standard CAN 2.0 data frame output by the terminal, so that downstream charge and discharge test equipment or host computer do not need to reconfigure the signal channel due to changes in battery protocol.

[0054] As a preferred implementation, the main control module also runs a Unified Parsing Engine (UPE) software module. The input to this unified parsing engine is the raw packets transparently transmitted by different protocol conversion modules, and the output is engineering values ​​with clear physical meaning. All access data is normalized and decoded by this engine by querying the DBC file. The unified parsing engine adopts a modular design; its core decoding logic is independent of specific protocols. When adding a new protocol type, only the corresponding preprocessing logic needs to be added in the frame extraction stage; the core decoding does not need to be modified.

[0055] The storage module, located inside the casing, uses non-volatile storage media to store DBC files and system configuration files, ensuring that DBC files and configuration data are not lost after the terminal is powered off. Preferably, the storage module can also store multiple copies of DBC files, allowing users to select and load the appropriate DBC file according to the needs of the test task. Loading and switching of DBC files is accomplished through file system operations on the main control module.

[0056] The power module, located inside the housing, provides operating power to all modules within the terminal. The power module includes a power conversion circuit that converts externally input DC power into the operating voltage required by each module. Preferably, the power module also includes overvoltage protection, overcurrent protection, and reverse connection protection circuits to ensure the terminal's operational safety in complex laboratory power supply environments.

[0057] The network interface, located on the casing, connects to the local area network (LAN) for remote configuration and script updates. An Ethernet interface (RJ45) is preferred, supporting the TCP / IP protocol. The main control module connects to the laboratory LAN via the network interface. Operators can remotely access the main control module from any networked terminal using a browser or SSH (Secure Shell) protocol to upload, replace, or update DBC files, as well as update the adapter layer scripts.

[0058] Preferably, the main control module runs a configuration service, allowing operators to access the configuration interface by visiting the terminal's IP address through a browser, and perform operations such as uploading, switching, and viewing DBC files.

[0059] Changes to DBC files support hot loading. Hot loading means that changes to the DBC file take effect immediately, without requiring a terminal restart or interruption of the test task. Specifically, when an operator uploads a new DBC file or switches to an active DBC file via remote access, the main control module immediately loads the new DBC file into memory. Subsequent received raw messages are then decoded according to the definition of the new DBC file, while the ongoing test task remains unaffected.

[0060] The terminal in this embodiment has a dual automatic identification mechanism: automatic identification of module type and automatic identification of battery model.

[0061] (i) Automatic identification of module type based on VID / PID

[0062] Different protocol conversion modules return a fixed combination of Vendor ID (VID) and Product ID (PID) during USB enumeration. This VID / PID combination remains consistent across all individuals of the same model. The main control module's non-volatile memory pre-stores a mapping table of VID / PID to protocol types and communication parameters. This mapping table records the protocol types (e.g., CAN FD, CAN 2.0, RS-485, Bluetooth, etc.) and communication parameters (e.g., CAN bit rate, RS-485 baud rate, etc.) corresponding to various USB dongle VID / PID combinations. When a protocol conversion module is inserted into the card slot, the main control module detects the new device access via the internal bus, automatically performs USB enumeration, reads the protocol conversion module's VID / PID, compares it with the pre-stored mapping table, automatically determines the type of protocol conversion module and its corresponding communication parameters, and automatically configures the communication parameters. This automatic identification process requires no manual intervention, achieving plug-and-play (PnP) functionality for the protocol conversion module.

[0063] (ii) Automatic identification of battery models based on frame feature comparison

[0064] After the protocol conversion module type is identified and communication parameters are configured, the battery under test is connected to the terminal (via the external interface of the protocol conversion module). The main control module listens to the initial communication frame sequence received by the corresponding protocol module. For CAN / CAN FD protocols, the first few messages with different IDs are retrieved; for serial / wireless protocols such as RS-485 or Bluetooth, the first few complete broadcast or response frames are retrieved. The main control module extracts frame features from the above initial communication frame sequence. Frame features include, but are not limited to, at least one of the following: arbitration ID (identifier of CAN / CAN FD message), data field fixed bit (fixed value at a specific position in the data field), frame interval (time interval between adjacent frames), and verification method (such as CRC check, checksum, etc.).

[0065] The main control module compares the extracted frame features with a built-in battery model feature library. This library contains pre-stored frame feature templates for various battery BMS communications, each template corresponding to a battery model and its parsing path (i.e., a pre-written parsing code block or a specific signal mapping relationship in a DBC file). When the extracted frame features match a template in the feature library, the main control module automatically identifies the battery model and selects the corresponding parsing path. If no match is found in the feature library, the user manually adds a parsing module through a remote configuration interface. The terminal then records the battery's features in the feature library, allowing for automatic selection when the same battery model is connected again. Through this frame feature comparison mechanism, the present invention achieves automatic battery model identification and automatic parsing path selection, further reducing manual configuration.

[0066] like Figure 2 As shown, the process by which the main control module extracts a complete data frame from the raw byte stream passed through by the protocol conversion module is as follows:

[0067] For CAN or CAN FD protocols:

[0068] The protocol conversion module is a USB-to-CAN or USB-to-CAN FD adapter. Commercially available USB-CAN adapters have pre-packaged CAN protocol stack drivers in their firmware. When the adapter is inserted into the slot, the main control module recognizes it as a standard CAN network interface via its internal bus. The main control module directly reads the complete CAN message through the CAN protocol stack. The read CAN message contains at least an arbitration ID, a data field, and a DLC (Data Length Code). The arbitration ID distinguishes different message types, the data field contains the specific signal data, and the DLC indicates the number of bytes in the data field (0-8 bytes for classic CAN 2.0B, and 0-64 bytes for CAN FD). After reading the complete CAN message, the main control module buffers it for subsequent parsing.

[0069] For serial port protocols:

[0070] The protocol conversion module is either a USB to RS-485 adapter or a USB to Bluetooth adapter. After being inserted into the card slot, these adapters are recognized as serial devices by the main control module. The main control module receives data from a continuous byte stream via the serial port driver. Because serial communication is a frameless continuous byte stream, the main control module needs to extract complete application layer data frames one by one from the continuous byte stream according to preset frame delimitation rules.

[0071] Frame delimitation rules include, but are not limited to, the following methods: First, fixed frame length: The application layer protocol specifies that each data frame has a fixed byte length, and the master control module segments the data frame from the byte stream according to the fixed length; Second, start flag plus length field: The data frame begins with a specific start flag, followed by a length field indicating the total number of bytes in the frame. The master control module extracts the complete data frame by detecting the start flag and reading the length field; Third, end flag plus checksum: The data frame ends with a specific end flag, or the frame tail contains a checksum. The master control module confirms the frame boundary by detecting the end flag or the checksum.

[0072] After extracting the complete application layer data frame, the main control module caches it for later use in the parsing engine.

[0073] Based on the loaded DBC file, the main control module normalizes and decodes the extracted complete data frame, parsing it into engineering values ​​(voltage, current, temperature, SOC, etc.) with clear physical meaning.

[0074] The DBC file defines the following parsing parameters for each signal: the message ID of the signal, the start bit of the signal in the data field, the bit length occupied by the signal, the byte order (Motorola or Intel format), the scaling factor, and the offset. During parsing, the parsing engine looks up the corresponding signal definition in the DBC file based on the message ID, then extracts the original value from the specified bit in the data field, and converts it into an engineered value using the following formula: Engineered value = Original value × Scaling factor + Offset.

[0075] For example, suppose a specific byte in a message ID defined in the DBC file represents the unit voltage, with a scaling factor of 0.1mV and an offset of 0. When the parsing engine receives the data frame corresponding to this message ID, it extracts the original value from the specified byte, multiplies it by the scaling factor of 0.1mV, and obtains the engineered value of the unit voltage. This parsing process is executed uniformly on all original messages passed through by the protocol conversion modules, regardless of whether the original message originates from CAN FD, CAN 2.0, RS-485, or Bluetooth protocols. Decoding is performed based on the same DBC file and the same set of parsing rules, thus ensuring the consistency of the output physical quantities.

[0076] The main control module verifies the validity of the parsed engineering values ​​based on the predefined signal ranges in the DBC file. In addition to defining the signal parsing parameters, the DBC file can also define reasonable value ranges for each signal (e.g., single-unit voltage 2.5V~4.35V, temperature -40℃~150℃, current -500A~500A, etc.). During verification, the main control module compares the parsed engineering values ​​with the aforementioned ranges. If the engineering value is within the range, it is considered valid; if it exceeds the range, it is considered invalid.

[0077] For data marked as invalid, the main control module processes it according to preset strategies. These preset strategies include, but are not limited to, the following: First, discard the current frame: directly discard the data in this frame and do not output the abnormal value to downstream devices; Second, retain the previous valid value: use the valid value of the previous frame as the output value of the current frame to prevent data jumps from affecting the test equipment's judgment; Third, set an alarm flag in the output data: set a specific alarm bit in the output CAN 2.0 data frame to indicate that the current value of the signal is an abnormal value, which is then handled by the downstream test equipment.

[0078] As a preferred implementation, the above-mentioned validity verification function supports two working states: debug mode and silent mode. During the debugging phase, the verification function outputs detailed logs to help developers locate problems; in mass production applications, the verification function can run silently as configured, only marking invalid data and processing it according to a preset strategy, without outputting debug logs.

[0079] The main control module repackages the verified engineering value (or the valid value processed by the preset strategy) into a standard CAN2.0 data frame and sends it to the downstream charge and discharge test equipment or host computer through the terminal's output interface.

[0080] A standard CAN 2.0 data frame includes an 11-bit or 29-bit arbitration segment and a data field of up to 8 bytes. During encapsulation, the main control module fills the corresponding CAN ID and byte positions with key signals such as total voltage, current, and temperature according to a preset fixed mapping rule. This mapping relationship remains fixed and does not change with the type of protocol conversion module. Therefore, regardless of whether the battery under test uses CAN FD, CAN 2.0, RS-485, or Bluetooth protocols, the terminal always outputs a CAN 2.0 frame with a consistent format, and key signals such as total voltage, current, and temperature always appear in the same CAN ID and the same byte positions.

[0081] With the unified output design of the above fixed mapping, the downstream charge and discharge test equipment or host computer only needs to perform signal channel configuration once (mapping each CAN ID and byte bit to the corresponding physical quantity). No matter what protocol or battery model is changed, there is no need to reconfigure the signal channel. The established test process can be directly reused.

[0082] The complete workflow of this embodiment is described in detail below:

[0083] Step 1: Module Installation and Identification

[0084] The operator selects the appropriate protocol conversion module from multiple options based on the BMS communication protocol type of the battery under test. For example, if the battery's BMS uses the CAN FD protocol, a USB to CAN FD adapter is selected; if it uses the RS-485 protocol, a USB to RS-485 adapter is selected. The operator aligns the selected protocol conversion module with the opening of the slot, inserts it into the slot of the housing along the guide rib, and continues pushing until the elastic latch locks in place. At this point, the body of the protocol conversion module sinks into or is flush with the surface of the housing, and the module's interface connects with the electrical interface at the bottom of the slot.

[0085] The main control module detects the access of a new module via the internal bus, automatically performs USB enumeration, and reads the VID / PID of the protocol conversion module. The main control module compares the read VID / PID with the pre-stored VID / PID-protocol type mapping table, automatically identifies the type of the currently inserted protocol conversion module and its corresponding communication parameters, and automatically completes the configuration of the communication parameters.

[0086] The operator connects the BMS communication interface of the battery under test to the external interface of the protocol conversion module via a communication cable. After connection, the battery under test begins sending communication frames to the terminal. The main control module listens to the initial communication frame sequence received by the protocol conversion module—for CAN / CAN FD protocols, it takes the first few messages with different IDs; for RS-485 or Bluetooth serial / wireless protocols, it takes the first few complete broadcast frames. The main control module extracts frame features (including at least one of arbitration ID, data field fixed bits, frame interval, and verification method) from the above initial communication frame sequence and compares them with the built-in battery model feature library. If a match is successful, the main control module automatically identifies the current battery model and selects the corresponding parsing path; if a match fails, the main control module prompts the operator to manually add a parsing module through the remote configuration interface. The operator uploads the corresponding DBC file and configures the parsing rules, and the terminal records the battery's features into the feature library for subsequent automatic identification.

[0087] Step 2: Loading the DBC file

[0088] Operators remotely access the terminal via the local area network to load the DBC file. Specifically, operators access the terminal's configuration interface from any networked terminal via a browser or SSH, and select or upload the DBC file corresponding to the battery model being tested. If the number of strings in the battery under test does not exceed the maximum number of strings defined in the currently loaded DBC file, there is no need to change the DBC file; simply confirm that the current DBC file is loaded. If the number of strings in the battery under test exceeds the maximum number of strings defined in the current DBC file, the operator uploads a DBC file with a larger number of strings through the remote configuration interface. The terminal's main control module stores the DBC file in a non-volatile storage module and immediately loads it into memory to take effect, without requiring a terminal restart or interruption of the test task.

[0089] The DBC file defines all individual cell signals according to the maximum number of cells supported by the terminal. For example, if the terminal supports a maximum of 52 cells, the DBC file defines the individual cell voltage, temperature, and other status signals for all 52 cells. When the tested battery has 14 cells, the main control module only uses the ID and signal bits corresponding to the actual 14 cells in the DBC file for decoding; the remaining signal bits are automatically ignored because they are not assigned values ​​by the BMS. This design allows a single DBC file to cover all battery models up to the maximum number of cells, eliminating the need to change the DBC file or modify the parsing script during routine battery model changes.

[0090] Step 3: Data Frame Extraction

[0091] The protocol conversion module receives raw physical layer signals from the battery management system (BMS) of the battery under test in real time. For CAN or CAN FD protocols, the module converts the received CAN / CAN FD differential signals into USB data packets, which are then transmitted to the main control module via the card slot's electrical interface and internal bus. The main control module directly reads the complete CAN message (including arbitration ID, data field, and DLC) through the CAN protocol stack. For serial protocols such as RS-485 or Bluetooth, the module converts the received signals into a serial byte stream, which is then transmitted to the main control module via the internal bus. The main control module extracts complete application layer data frames one by one from the continuous byte stream according to preset frame delimitation rules (such as fixed frame length, start flag plus length field, or end flag plus checksum). The extracted complete data frames are cached in the main control module's memory, awaiting processing by the parsing engine.

[0092] Step 4: DBC Parsing

[0093] The unified parsing engine of the main control module reads complete data frames sequentially from the cache and performs normalized decoding based on the currently loaded DBC file. The parsing engine automatically converts the raw byte stream into engineered values ​​according to the message ID, signal start bit, data length, byte order, scaling factor, and offset defined in the DBC file. After all signals are parsed, a complete battery state dataset for the current moment is obtained (including individual cell voltages, total voltage, current, temperature at various points, SOC, etc.).

[0094] Step 5: Data Validation

[0095] The main control module verifies the validity of the parsed engineering values ​​based on the predefined signal range in the DBC file. For example, if the DBC file defines the range of a single-unit voltage as 2.5V to 4.35V, and the parsed single-unit voltage exceeds this range, the data is marked as invalid. For data marked as invalid, the main control module processes it according to a preset strategy, which includes, but is not limited to, discarding the current frame, retaining the previous valid value, or setting an alarm flag in the output data.

[0096] For example, if the current value of the current frame is marked as invalid and the preset strategy is "keep the previous valid value", the main control module will use the current value of the previous frame as the output value of the current frame to prevent the test equipment from malfunctioning due to the current value jump; at the same time, the abnormal event will be recorded in the log of the main control module for subsequent analysis.

[0097] Step Six: Unified Output

[0098] The main control module repackages the verified (or pre-processed) valid engineering values ​​into standard CAN 2.0 data frames and sends them to downstream charge / discharge test equipment or a host computer via the terminal's CAN output interface. During encapsulation, key signals such as total voltage, current, and temperature are filled with preset CAN IDs and byte bits according to a fixed mapping rule. This fixed mapping rule is independent of the protocol type of the connected battery; that is, regardless of whether the battery BMS under test uses CAN FD, CAN 2.0, RS-485, or Bluetooth, the terminal outputs CAN 2.0 frames with the exact same format. The downstream charge / discharge test equipment completes the signal channel mapping configuration during initial configuration, and subsequent tests do not require repeated configuration due to battery replacement.

[0099] Step 7: Changeover Operation

[0100] When it is necessary to change the model of the battery being tested, the operator shall proceed as follows:

[0101] If the communication protocol of the new battery is the same as that of the old battery, and the number of strings in the new battery does not exceed the maximum number of strings defined in the current DBC file, then there is no need to replace the protocol conversion module or the DBC file. It is only necessary to confirm that the current DBC is loaded, and the terminal will continue to work normally.

[0102] If the new battery uses a different communication protocol, the operator presses the elastic latch to unlock it, pulls out the original protocol conversion module, selects the USB dongle corresponding to the new protocol, inserts it along the guide rib into the same slot, and pushes it in until it is fully inserted, at which point the elastic latch automatically locks it in place. The main control module automatically identifies the type and communication parameters of the new module and automatically completes the reconfiguration.

[0103] If a new battery model is introduced on-site that exceeds the range of the original DBC defined number of strings, the operator can remotely access the terminal via the local area network, upload the corresponding DBC file with a larger range, and the main control module will hot-load the new DBC file, which will take effect immediately and will not interrupt the test task.

[0104] Throughout the entire replacement process, operators do not need to rewire, restart terminals, or reconfigure the signal channels of test equipment.

[0105] Specifically, this embodiment provides a battery testing multi-protocol conversion terminal using the above-described terminal structure for use in laboratory multi-protocol battery testing scenarios.

[0106] The laboratory needs to perform charge-discharge tests on three battery packs using different communication protocols: Battery A is a 14-cell ternary lithium battery with a BMS using the CAN FD protocol; Battery B is a 16-cell lithium iron phosphate battery with a BMS using the RS-485 Modbus protocol; and Battery C is a 12-cell lithium titanate battery with a BMS using the Bluetooth BLE protocol. The available charge-discharge testing equipment in the laboratory is a test cabinet that only supports the standard CAN 2.0 protocol.

[0107] Using the battery testing multi-protocol conversion terminal provided by this invention, along with three low-cost USB dongles: USB to CAN FD adapter, USB to RS-485 adapter, and USB to Bluetooth adapter, the total hardware investment is approximately 150 yuan.

[0108] The test was conducted in three phases. Phase 1 involved testing battery A. The operator inserted the USB-to-CAN FD adapter into the terminal's slot. The main control module automatically identified the module type and configured the CAN FD communication parameters. The operator remotely accessed the terminal via a browser to confirm that the currently loaded DBC file was designed for a maximum of 52 strings (14 strings were already covered). The BMS communication interface of battery A under test was connected to the USB-to-CAN FD adapter via a CAN cable. The terminal automatically extracted the frame features of the CAN FD messages, compared them with the battery model feature library, identified the battery model as a 14-string ternary lithium battery, and selected the corresponding parsing path. The test cabinet was connected to the terminal's CAN output interface via the CAN bus. The terminal received CAN FD messages from battery A in real time and transmitted them to the main control module. The main control module decoded the DBC file and encapsulated the decoded 14 strings of individual cell voltage, total voltage, current, temperature, and other engineering values ​​into a standard CAN 2.0 data frame for output. The total voltage, current, and temperature were fixedly mapped to preset CANID and byte positions. The test cabinet reads the CAN ID and byte bits according to the configured signal channel to obtain the real-time status data of battery A and performs charge and discharge tests.

[0109] In the second phase, battery B is tested. After battery A is tested, the operator presses the spring clip to remove the USB to CANFD adapter and inserts the USB to RS-485 adapter into the same slot. The main control module automatically recognizes the new module type and configures the RS-485 communication parameters. Since battery B is a 16-cell battery, it is still within the maximum range of 52 cells defined in the DBC file, so the operator does not need to change the DBC file. The BMS communication interface of battery B is connected to the USB to RS-485 adapter via an RS-485 cable. The terminal automatically extracts the RS-485 frame features, identifies the battery model as a 16-cell lithium iron phosphate battery, and selects the corresponding parsing path. The terminal transmits the RS-485 Modbus data of battery B to the main control module. After decoding with the same DBC file, the total voltage, current, temperature, and other engineering values ​​are encapsulated into standard CAN 2.0 data frames with the same fixed mapping relationship and output. Since the CAN signal mapping relationship received by the test cabinet is exactly the same as in the first phase, there is no need to reconfigure the signal channel. Operators only need to modify the protection threshold parameters according to the battery chemistry system to directly use the existing test procedures.

[0110] The third stage involves testing battery C. After battery B testing is complete, the operator removes the USB-to-RS-485 adapter and inserts the USB-to-Bluetooth adapter into the slot. The main control module automatically recognizes the new module type and configures the Bluetooth parameters. Battery C is a 12-cell battery, still within the maximum range of 52 cells defined in the DBC file, so no DBC file replacement is required. The Bluetooth BLE broadcast signal of battery C is paired and connected to the USB-to-Bluetooth adapter. The terminal automatically extracts the Bluetooth broadcast frame characteristics, identifies the battery model as a 12-cell lithium titanate battery, and selects the corresponding parsing path. The terminal transmits the Bluetooth broadcast data of battery C through to the main control module, which decodes it using the same DBC file and outputs standard CAN 2.0 data frames with the same fixed mapping relationship. The signal channel configuration of the test cabinet remains completely unchanged; the operator only needs to modify the protection threshold parameters to begin testing.

[0111] All three phases of testing were completed on schedule. The total hardware investment was approximately 150 yuan, far lower than the cost of a customized dedicated gateway. The total time for the three battery type changes was approximately 20 minutes (approximately 5-7 minutes each time). Only the USB dongle needed to be plugged in and out, and the DBC file needed to be loaded; no rewiring, terminal restart, or test software reconfiguration was required. Because the CAN 2.0 signals output by the terminal of this invention for the three types of batteries are completely identical (total voltage, current, and temperature are all mapped to the same CAN ID and byte bits), the signal channel configuration of the charge / discharge test equipment only needs to be completed once. The established test procedure can be directly reused; only the protection threshold parameters need to be modified according to the chemical system of each battery, saving approximately 30-60 minutes of process configuration time for each battery type change.

[0112] This embodiment verifies the practical effectiveness of the present invention in R&D testing scenarios involving multiple protocols, small batches, and frequent model changes: First, by using a pluggable protocol conversion module, multi-protocol hardware adaptation is achieved, and the terminal host can be permanently reused, significantly reducing hardware costs; Second, by using an architecture of "modules only transmitting data and the main control unit uniformly parsing data," normalization processing of different protocol data is achieved; Third, by designing the DBC based on the maximum number of strings and reusing low-string-count data, daily model changes do not require changing the DBC file; Fourth, by using a unified CAN 2.0 output with fixed mapping, cross-protocol reuse of the testing process is achieved.

[0113] Example 2

[0114] A method for multi-protocol conversion in battery testing includes the following steps:

[0115] The operator selects the corresponding protocol conversion module according to the communication protocol type of the battery being tested, inserts the module into the slot in the terminal housing, and the main control module automatically identifies the module type and completes the communication parameter configuration.

[0116] Operators can remotely access or upload the DBC file designed according to the maximum number of strings.

[0117] The protocol conversion module receives the raw physical layer signals from the battery management system (BMS) under test in real time and transmits the raw messages to the internal bus. The main control module extracts complete data frames from the transmitted raw byte stream: for CAN / CAN FD protocols, it reads the complete CAN message through the CAN protocol stack; for serial protocols, it extracts application layer data frames according to frame delimitation rules.

[0118] The main control module normalizes and decodes the extracted complete data frame according to the DBC file to obtain the engineering value. Then, it verifies the validity of the decoded engineering value according to the predefined signal range in the DBC file. Data that exceeds the range is marked as invalid and processed according to the preset strategy.

[0119] The main control module encapsulates the verified engineering values ​​into a standard CAN 2.0 data frame for output, with total voltage, current, and temperature fixedly mapped to preset CAN IDs and byte bits.

[0120] When switching batteries, if the new battery protocol is the same and the number of strings does not exceed the current DBC definition range, no operation is required; if the protocol is different, the module is replaced and the system automatically identifies it; if the number of strings exceeds the range, a larger range of DBC files is uploaded remotely, and hot loading takes effect.

[0121] The embodiments described above are merely illustrative of several implementations of the present invention, and while the descriptions are specific and detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention. Therefore, the scope of protection of this patent should be determined by the appended claims.

Claims

1. A battery testing multi-protocol conversion terminal, characterized in that, include: A housing, wherein the housing is provided with at least one slot; The protocol conversion module is installed in the card slot in a pluggable manner. Different protocol conversion modules are replaced with batteries of different communication protocols. The protocol conversion module is used to receive the raw physical layer signal of the external battery and pass the raw message through to the internal bus. It does not perform protocol type identification and data field parsing. The main control module is connected to the internal bus and stores a DBC file that defines all individual cell signals according to the maximum number of batteries supported by the terminal. It is used to normalize and decode the original messages transmitted by all the protocol conversion modules according to the DBC file, and encapsulate the decoded engineering values ​​into standard CAN 2.0 data frames for output. In the output standard CAN 2.0 data frame, the total voltage, current, and temperature signals are fixedly mapped to preset CANID and byte bits, and do not change with the type of the protocol conversion module.

2. The battery testing multi-protocol conversion terminal according to claim 1, characterized in that, The protocol conversion module is a USB interface protocol adapter, including any one or more of the following: USB to CAN adapter, USB to CAN FD adapter, USB to RS-485 adapter, and USB to Bluetooth adapter.

3. A battery testing multi-protocol conversion terminal according to claim 1, characterized in that, The main control module reads the VID / PID of the protocol conversion module and compares it with the pre-stored VID / PID-protocol type mapping table to automatically identify the type of the protocol conversion module and its corresponding communication parameters.

4. A battery testing multi-protocol conversion terminal according to claim 1, characterized in that, The main control module is also used to: extract the frame features of the initial communication frame sequence of the access battery, compare them with the built-in battery model feature library, automatically identify the battery model and select the corresponding parsing path; the frame features include at least one of arbitration ID, data field fixed bit, frame interval, and verification method.

5. A battery testing multi-protocol conversion terminal according to claim 1, characterized in that, The DBC file defines all individual cell signals according to the maximum number of batteries supported by the terminal. When a low-number-count battery is connected, the main control module only uses the ID and signal bits corresponding to the actual number of serial cells in the DBC file for decoding. Other signal bits that exceed the actual number of serial cells are automatically ignored and not decoded.

6. A battery testing multi-protocol conversion terminal according to claim 1, characterized in that, When the main control module extracts a complete data frame from the raw byte stream passed through by the protocol conversion module: For CAN or CAN FD protocols, the complete CAN message is read through the CAN protocol stack. The CAN message contains at least the arbitration ID, data field, and DLC. For serial port protocols, application layer data frames are extracted from continuous byte streams according to preset frame delimiting rules, which include at least one of fixed frame length, start flag plus length field, or end flag plus checksum.

7. A battery testing multi-protocol conversion terminal according to claim 1, characterized in that, The main control module is also used to: perform validity verification on the decoded engineering values ​​according to the signal range predefined in the DBC file, mark data that exceeds the range as invalid, and process them according to a preset strategy; The preset strategy includes at least one of discarding the current frame, maintaining the previous valid value, or setting the alarm flag.

8. A battery testing multi-protocol conversion terminal according to claim 1, characterized in that, It also includes a network interface, through which the main control module supports remote access to upload, replace or update DBC files; and the changes to the DBC files support hot loading, that is, the changes to the DBC files take effect immediately without restarting the terminal or interrupting the test task.

9. A battery testing multi-protocol conversion terminal according to claim 1, characterized in that, The slot is equipped with a guide rib and an elastic buckle locking mechanism; after the protocol conversion module is inserted into place along the guide rib, it is automatically locked by the elastic buckle, and pressing the elastic buckle releases the lock to pull out the protocol conversion module.

10. A method for multi-protocol conversion in battery testing, characterized in that, Includes the following steps: S1: Based on the communication protocol type of the battery under test, select the corresponding protocol conversion module and install it in the slot of the terminal housing in a pluggable manner. The protocol conversion module sends the received raw physical layer signal to the internal bus in a transparent manner, without performing protocol type identification and data field parsing. S2: The main control module of the terminal loads the DBC file defining all individual cell signals according to the maximum number of batteries supported by the terminal; S3: The protocol conversion module receives the original physical layer signal of the battery under test and transmits the original message to the main control module; S4: The main control module extracts complete data frames from the raw byte stream transmitted by the protocol conversion module; S5: The main control module normalizes and decodes the extracted complete data frame according to the DBC file to obtain the engineering value; S6: The main control module encapsulates the engineering values ​​into a standard CAN 2.0 data frame for output, wherein the total voltage, current, and temperature signals are fixedly mapped to a preset CAN ID and byte bits.

Images