Multi-protocol self-adaptive BMS upper computer monitoring system and data interaction method

Abstract

The embodiment of the invention relates to a multi-protocol self-adaptive BMS upper computer monitoring system and a data interaction method, and the system comprises a device access layer which is used for establishing a communication link between any BMS device and a BMS upper computer, and enabling the original data of the BMS device to be transmitted to the BMS upper computer; the protocol analysis layer is used for receiving the original data transmitted by the BMS upper computer and analyzing the original data according to a specified rule to obtain standard data; the data service layer is used for receiving the standard data, integrating and packaging the standard data and then providing a data interface for calling; the application function layer is used for calling the data interface, so that the system can process data from any BMS equipment with a consistent interface and logic; wherein the protocol analysis layer is designed with a protocol driving library, and the protocol driving library comprises implementation of a driving library interface IMcuDriver and implementation of an abstraction class driver Abstraction McuDriver; according to the invention, plug-and-play and unified management of the heterogeneous BMS equipment can be realized.

Description

TECHNICAL FIELD

[0001] The embodiment of the application relates to the technical field of battery management system, and particularly relates to a multi-protocol adaptive BMS host computer monitoring system and a data interaction method. BACKGROUND

[0002] With the rapid development of new energy automobile, energy storage power station and other industries, the application scale of electrochemical energy storage systems such as lithium ion batteries is increasingly expanding, and the importance of safe, efficient and long-life operation is increasingly highlighted. As the core control unit of the battery pack, the battery management system (BMS) monitors the key parameters such as voltage, current and temperature of the battery in real time, and estimates the state of charge (SOC), diagnoses faults and protects, which is the key to ensuring the safety of the battery and prolonging the life of the battery.

[0003] The BMS host computer software is the key hub for human interaction with BMS, which receives, displays, stores and analyzes BMS data, and provides support for state monitoring, fault troubleshooting and operation decision of the battery system. However, the current BMS host computer software on the market has significant technical bottlenecks in protocol compatibility and data interaction.

[0004] At present, the general technical solution in the industry is that the BMS hardware establishes a connection with the host computer through CAN bus, Ethernet or RS485 and other physical interfaces, and periodically uploads data messages according to the pre-defined communication protocol. The host computer software decodes, checks and displays and stores the parsed data on the graphical user interface (GUI) according to the specific protocol content.

[0005] The above existing technical solution exposes the following main technical problems in actual application: Firstly, the protocol compatibility is poor and the generalization degree is low: different BMS manufacturers use private communication protocols, and their protocols have great differences in message structure, data byte order, and verification method. Most existing host computer software adopts a "one-to-one" hard coding development mode, that is, a set of software is developed for a specific protocol. When a new protocol needs to be accessed or the protocol version is updated, the source code must be modified, recompiled and a new software version must be released by the developer. This not only leads to long software development cycle and high cost, but also makes it extremely inconvenient for user-side software upgrade and maintenance, which seriously restricts the generalization and standardization process of the host computer software.

[0006] Secondly, the system lacks expansibility and flexibility. Since the protocol analysis logic is highly coupled with the main software program, the entire system becomes a rigid "black box". Users or integrators cannot extend support for new protocols without accessing the source code. When facing some non-mainstream or temporary demand BMS devices, they either give up access or pay high customization development fees. This architecture lacks scalability and flexibility, and cannot adapt to rapidly changing market demands and technology iterations.

[0007] Thirdly, the integration and operation efficiency is low. In a complex battery application scenario (such as a battery energy storage station or a battery swap station), there are often multiple brands and models of BMS devices coexisting. To monitor the entire system, the operation personnel have to install and run multiple different host computer software on the computer at the same time, and switch between different interfaces. This "one machine with multiple software" situation greatly reduces the monitoring efficiency, increases the operation complexity, and cannot perform unified data analysis and correlation judgment, making it difficult to grasp the overall operation status from the system level.

[0008] Fourthly, the data interaction process is complex and the reliability is poor. For private protocols, the data interaction process usually requires complex reverse engineering and repeated debugging. Even if the connection is successful, since the protocol analysis logic is fixed, when the BMS hardware causes minor changes in the protocol due to firmware upgrade, etc., the analysis process of the host computer software may fail, resulting in data analysis failure, monitoring screen stagnation, or even software crashes, which seriously affects the reliability and stability of the monitoring system.

[0009] In summary, the BMS host computer software of the prior art has become a key technical bottleneck restricting the efficient integration and intelligent operation of the battery management system due to its inherent protocol rigidity and poor expansibility. SUMMARY

[0010] In view of the above problems, the present application provides a multi-protocol adaptive BMS host computer monitoring system and a data interaction method, which has high flexibility and expansibility, and can realize plug-and-play and unified management of heterogeneous BMS devices.

[0011] According to one aspect of the present application, a multi-protocol adaptive BMS host computer monitoring system is provided, comprising: A device access layer is configured to establish a communication link between any BMS device and a BMS host computer, so that the raw data of the BMS device is transmitted to the BMS host computer; A protocol analysis layer is configured to receive the raw data transmitted by the BMS host computer, analyze the raw data according to predetermined rules, and obtain standard data; a data service layer receiving the standard data, integrating and packaging the standard data, and providing a data interface for calling; and an application function layer calling the data interface, so that the system can process data from any BMS device with consistent interface and logic; The protocol analysis layer is designed with a protocol driver library, and the protocol driver library includes a driver library interface IMcuDriver and an implementation of an abstract class driver AbstractMcuDriver.

[0012] In some implementations, the protocol driver library further includes a plug-in base class.

[0013] In some implementations, the device access layer is designed with a connection manager. The connection manager is used to support automatic identification and parameter configuration of multiple communication interfaces.

[0014] In some implementations, the data service layer is designed with a unified data model and an internal data bus. The standard data is converted into standardized data following the unified data model and is published to the internal data bus. Other functional modules of the data service layer subscribe to associated data from the internal data bus.

[0015] In some implementations, the unified data model takes (DisPlayId, Name, Value, Address, Units) as a core structure, where the Name is a globally unique data point identifier. Other functional modules of the data service layer obtain the associated data by subscribing to the relevant DisPlayId.

[0016] According to an aspect of an example of the present application, a multi-protocol adaptive data interaction method is provided, comprising: A protocol driver library is designed in the protocol analysis layer of the BMS host computer software, and the protocol driver library includes a driver library interface IMcuDriver and an implementation of an abstract class driver AbstractMcuDriver. The abstract class driver AbstractMcuDriver implements the driver library interface IMcuDriver. The abstract class driver AbstractMcuDriver defines a virtual method that can be overridden according to its own needs during different protocol analysis.

[0017] In some implementations, the AbstractMcuDriver defined by the abstract class driver defines a virtual method that can be overridden by each protocol as needed.

[0018] In some implementations, each protocol customizes the frame structure used for protocol parsing, specifically including: Defining a message structure, including specifying a frame header, a frame tail, a communication address ID, a data length, and a check code; Defining a parsing rule, including defining byte order (big-endian / small-endian), offset, parsing length, and event response; Mapping data points: associating specific bytes in the message with a unified data point identifier according to the parsing rule.

[0019] In some implementations, the protocol driver library further includes a plug-in base class, which includes a data structure, read-write methods, a polling thread, and historical record reading.

[0020] In some implementations, it further includes: According to the pre-set plug-in document, develop, write the related dll file of the plug-in communication protocol generation, and place the file in the specified folder; The host computer software dynamically loads the protocol library according to the specified folder path to perform communication connection and data parsing.

[0021] The beneficial effects of the multi-protocol adaptive BMS host computer monitoring system and data interaction method are as follows: the protocol driver library is designed in the protocol parsing layer, the protocol driver library includes the implementation of the driver library interface IMcuDriver and the abstract class driver AbstractMcuDriver, the functions of the protocol are forcedly limited, the uniformity between protocols is maintained, the user can extend the function support for new protocols, the true multi-protocol adaptation is realized, the adaptation cost and period of the software to different BMS devices are greatly reduced; the layered and decoupled architecture design makes the system easy to extend and maintain, the administrative function module only needs to subscribe to the internal data bus without modifying the underlying parsing code; a set of software integrates all device monitoring, provides a unified man-machine interface and data analysis platform, completely eliminates the cumbersome of multiple software switching, improves the operation and maintenance efficiency and the overall insight of the system; the unified error handling and data verification mechanism ensures the stability and reliability of the data interaction process, even when the protocol is fine-tuned, the protocol parsing content can be modified by quickly updating the formula to restore the function, avoiding the risk of software collapse. BRIEF DESCRIPTION OF DRAWINGS

[0022] The accompanying drawings are included to provide a further understanding of the application and are incorporated in and constitute a part of this specification. In the drawings: Figure 1 A structure diagram of the BMS host computer monitoring system of embodiment 1 provided by the application is shown; Figure 2 A structure diagram of the device access layer and the protocol driver library of embodiment 2 provided by the application is shown; Figure 3 A flow diagram of the data interaction method of embodiment 3 provided by the application is shown. DETAILED DESCRIPTION

[0023] Exemplary embodiments of the application will be described in greater detail below with reference to the accompanying drawings. While exemplary embodiments of the application are shown in the drawings, it is understood that the application can be embodied in various forms and should not be limited by the embodiments set forth herein.

[0024] Embodiment 1: Figure 1 A multi-protocol adaptive BMS host computer monitoring system provided by the application is shown, which comprises: A device access layer 100, which is used to establish a communication link between any BMS device and a BMS host computer, so that the original data of the BMS device is transmitted to the BMS host computer.

[0025] The device access layer 100 is a bridge connecting the BMS device and the BMS host computer, and realizes the unified access, data acquisition and instruction issuing of any BMS device.

[0026] Specifically, the operation data of the BMS device is collected according to the demand, and the control instructions of the BMS host computer monitoring system are received, such as starting, stopping and parameter adjustment, etc., while the instruction execution structure is fed back to form a closed loop.

[0027] Here, any BMS device refers to a BMS device using any communication protocol.

[0028] A protocol analysis layer 200, which receives the original data transmitted by the BMS host computer, analyzes the original data according to the specified rules, and obtains standard data.

[0029] Any BMS device is connected to the device access layer through a physical interface, and the BMS device is confirmed to be in an online state. The original data of the BMS device is transmitted to the BMS host computer. After the BMS host computer receives the original data, it is sent to the protocol analysis layer. The protocol analysis layer analyzes the original data according to the specified rules, such as extracting the valid information in the original data according to the preset protocol rules, and completing data verification.

[0030] The data service layer 300 receives the standard data, integrates and packages the standard data, and provides a data interface for calling.

[0031] The protocol analysis layer converts heterogeneous data of different BMS devices into standard data in a unified format to eliminate data format differences. The protocol analysis layer outputs single and scattered standard data, and the data service layer further integrates and packages these data, such as integrating multi-device data, calculating derived indicators, and caching historical data. The integrated and packaged data are provided to the application function layer in the form of a data interface. For example, a BMS device sends raw data to a BMS host computer through a CAN bus, the BMS host computer transmits the raw data to the protocol analysis layer, the protocol analysis layer parses the standard data such as single cell voltage and temperature according to the CAN protocol rules, and eliminates invalid data with failed verification. The data service layer integrates the voltage and temperature data of all single cells in the same battery pack into a battery pack status data set, calculates derived indicators such as the SOC and voltage balance degree of the battery pack based on the integrated data, and finally synchronizes the battery pack status data set and the derived indicators to the application function layer through the data interface.

[0032] The application function layer 400 calls the data interface, so that the system can process data from any BMS device with consistent interface and logic.

[0033] The application function layer receives the data integrated and packaged by the data service layer and performs secondary integration and processing by calling the data interface. For example, the voltage and temperature data in the BMS device are integrated into a battery health (SOH) report, and the originally abstract data becomes intuitive and easy to understand through data visualization such as dashboards, curve charts, digital scoreboards, or data statistical analysis. The terminal user is provided with a visual operation interface such as a Web page or a desktop client, supports parameter configuration and instruction issuance, and provides data graphs, historical records, serial port debugging, and other application functions.

[0034] In one example, the BMS device transmits the original data to the BMS host computer through the device access layer, and the BMS host computer provides the received original data to the protocol analysis layer for processing, i.e., processing the original data through a specified rule, including analyzing the byte offset, length, decimal point, and display unit of the data, which are referred to as (o, l, d, u) model. The BMS host computer can configure the specific meaning of each field variable through the model, for example, (0, 2, 0, mV) represents a variable with mV as the unit and is parsed into a short type data; and a plurality of single field variables form a large data service layer, and each field is also mapped to a UI display position and an event response mechanism is added to facilitate the notification of custom controls to display data.

[0035] The protocol analysis layer is designed with a protocol driver library, and the protocol driver library includes a driver library interface IMcuDriver 210 and an implementation of an abstract class driver AbstractMcuDriver 220.

[0036] The driver library interface IMcuDriver 210: by defining the IMcuDriver interface, the design of the hardware abstraction layer (HAL) can be implemented, so that the upper application code is decoupled from the specific MCU hardware. When the MCU model is replaced, only the implementation class of the interface needs to be replaced, without the need to modify the upper business logic, improving the portability and maintainability of the code. The interface forces all drivers that implement the interface to uniformly implement interface attributes and methods, and effectively enforces the uniformity between protocols through the interface.

[0037] The abstract class driver AbstractMcuDriver 220: the abstract class driver AbstractMcuDriver implements the driver library interface IMcuDriver and defines some virtual methods for different protocol analysis that can be modified according to their own needs by overrider.

[0038] For example, when a new protocol BMS device needs to be accessed, the developer or code maintenance personnel only needs to inherit the abstract class driver AbstractMcuDriver and override the implementation of the specific function method according to the actual needs, and each protocol can customize its own frame structure for the analysis of the protocol.

[0039] Specifically, the abstract class driver AbstractMcuDriver encapsulates the common logic of BMS device access, and the new protocol driver can directly reuse it after inheritance, without the need to repeatedly develop device state management, communication reliability mechanism, and basic interface implementation, etc.

[0040] Among them, for device state management, the abstract class usually contains properties such as isConnected (connection state), lastCommTime (last communication time), and methods such as updateStatus (status update), isOffline (offline judgment), etc., which automatically maintain the online / offline state of the device.

[0041] For communication reliability mechanisms such as retryWhenFailed (retry when failed), validateChecksum (checksum verification general logic), timeoutControl (timeout control), etc., to ensure data interaction stability.

[0042] For the default logic of basic interface implementation such as connect (connection), disconnect (disconnection) (such as parameter verification, log recording), the new driver only needs to override when necessary (such as modifying the connection timeout time).

[0043] The unique logic of the new protocol is implemented by re-abstracting the method, that is, each protocol can customize its own frame structure for parsing of the protocol, including: Define message structure: specify frame header, frame tail, communication address ID, data length, checksum, etc.

[0044] Define parsing rules: define byte order (big-endian / little-endian), offset, parsing length, and event response, etc.

[0045] Map data points: according to the parsing rules, specific bytes in the message can be associated with a unified data point identifier. For example, the two bytes of a 32-byte array at offset 0, length 2 in the return message are parsed as a 16-bit signed integer and mapped to a unified data point identifier.

[0046] The multi-protocol adaptive BMS host computer monitoring system provided in the embodiment designs an extensible protocol driver library in the protocol parsing layer. The protocol driver library includes the implementation of the driver library interface IMcuDriver and the abstract class driver AbstractMcuDriver. When a new protocol BMS device needs to be accessed, the developer or code maintenance personnel only needs to inherit the abstract class driver AbstractMcuDriver and override the implementation of the specific function method according to actual needs. Each protocol can customize its own frame structure for parsing of the protocol. The protocol parsing logic is effectively separated from the rigid source code, making it configurable and external. This greatly improves the extensibility and flexibility of the system, realizes a revolutionary change from one-to-one hard coding to one-to-many adaptive adaptation, and completely solves the protocol compatibility problem.

[0047] Embodiment 2: This embodiment is based on the optimization of embodiment 1, as Figure 2 As shown in the embodiment, the protocol driver library also includes a plug-in base class 230.

[0048] The plug-in base class 230 is used to define the standardized development specification of the plug-in, provide common capability encapsulation, and realize decoupling connection of the plug-in and the main program, so that plug-ins with different functions can be uniformly loaded, run and managed in the main program.

[0049] The plug-in base class will define the core methods that the plug-in must implement in advance, and clearly define the interaction rules between the plug-in and the main program, so as to avoid the situation that the main program cannot be recognized due to the difference in the development style of the plug-in.

[0050] The plug-in base class will encapsulate the logic commonly required by all plug-ins into ready-to-use methods, including all possible data structures, read-write methods, polling threads and history record reading, etc. Users can develop according to the pre-set plug-in document, write the related dll file of the plug-in communication protocol, and place the file in the specified folder. The BMS host computer software dynamically loads the protocol library according to the specified folder path to perform communication connection and data analysis, without the need to modify the code of the main program, thereby reducing the dependence on the source code.

[0051] In some embodiments, the device access layer is designed with a connection manager; the connection manager is used to support automatic identification and parameter configuration of multiple communication interfaces.

[0052] For example, the connection manager can support automatic identification and parameter configuration of communication interfaces such as CAN, Ethernet and Serial Port. When a user configures the protocol for a BMS device, the user must also associate the hardware connection mode, such as the CAN channel, IP address, serial port number, baud rate, etc. When the system starts, the connection manager automatically initializes the hardware interface according to the configuration, establishes a physical connection, and continuously monitors the connection state and data flow during the communication process. An effective timeout mechanism is set, and if the parsing fails or is abnormal, the current error log is recorded and the user is notified, thereby ensuring the reliability of the communication link. This function can configure different communication protocols according to different models, avoiding the single configuration problem of a single software, and greatly solving the disadvantages of constantly switching configuration parameters due to different customer needs.

[0053] In some embodiments, the data service layer is designed with a unified data model and an internal data bus; The standard data conversion is converted into standardized data following the unified data model, and is published to the internal data bus; other functional modules of the data service layer subscribe to the associated data from the internal data bus.

[0054] Specifically, the unified data model takes (DisPlayId, Name, Value, Address, Units) as a core structure, wherein the Name is a globally unique data point identifier; other functional modules of the data service layer obtain the associated data by subscribing to the relevant DisPlayId.

[0055] The multi-protocol adaptive BMS host computer monitoring system provided in the embodiment realizes that all protocol drivers must convert data into internal data objects (see code snippet 1) complying with the unified data model after analyzing data, regardless of how the bottom protocol changes.

[0056] All parsed standardized data is published to an internal data bus (an abstract bus implemented in a process). Other functional modules of the system, such as interface display, data storage, and alarm judgment, can obtain associated data by subscribing to the DisPlayId they care about, without needing to care about where the data comes from and which device it comes from, thereby realizing complete decoupling of data and protocols. The application function layer functional modules are developed based on a unified data interface, so that the system can process data from any BMS device with consistent interfaces and logic, and an operator can monitor all devices with different protocols using a set of software. Data can be associated and managed in a unified platform, thereby greatly improving integration and operation efficiency.

[0057] Embodiment 3 Figure 3 A schematic diagram of an embodiment of the multi-protocol adaptive data interaction method is shown.

[0058] As shown in Figure 3 , the multi-protocol adaptive data interaction method comprises the following steps: 500. Design a protocol driver library in a protocol analysis layer of a BMS host computer software, wherein the protocol driver library comprises a driver library interface IMcuDriver and an implementation of an abstract class driver AbstractMcuDriver.

[0059] 600. The abstract class driver AbstractMcuDriver implements the driver library interface IMcuDriver.

[0060] 700、The abstract class driver AbstractMcuDriver defines a virtual method that can be overridden as needed for different protocol parsing.

[0061] Among them, the driver library interface IMcuDriver: by defining the IMcuDriver interface, the design of the hardware abstraction layer (HAL) can be realized, so that the upper application code is decoupled from the specific MCU hardware. When replacing the MCU model, only the implementation class of the interface needs to be replaced, without the need to modify the upper business logic, improving the portability and maintainability of the code. The interface forces all drivers that implement the interface to uniformly implement interface properties and methods, and effectively enforces uniformity between protocols.

[0062] Abstract class driver AbstractMcuDriver: The abstract class driver AbstractMcuDriver implements the driver library interface IMcuDriver and defines some virtual methods for different protocol parsing that can be overridden as needed for modification.

[0063] For example, when a new protocol BMS device needs to be accessed, the developer or code maintenance personnel only needs to inherit the abstract class driver AbstractMcuDriver and override the specific function method according to actual needs.

[0064] In some embodiments, the abstract class driver AbstractMcuDriver defines a virtual method that can be overridden as needed for different protocol parsing, and each protocol can customize the frame structure used for protocol parsing.

[0065] Specifically, the abstract class driver AbstractMcuDriver encapsulates the common logic of BMS device access, and the new protocol driver can directly reuse it after inheritance, without the need to repeatedly develop device state management, communication reliability mechanism, and basic interface implementation, etc.

[0066] Among them, for device state management, the abstract class usually contains properties such as isConnected (connection state), lastCommTime (last communication time), and methods such as updateStatus (status update), isOffline (offline judgment), etc., to automatically maintain the online / offline state of the device.

[0067] For communication reliability mechanisms, such as retryWhenFailed (retry when failed), validateChecksum (checksum verification general logic), timeoutControl (timeout control), etc., to ensure data interaction stability.

[0068] For the default logic of the basic interface implementation, such as connect (connection), disconnect (disconnection) (such as parameter verification, log recording), the new driver only needs to override when necessary (such as modifying the connection timeout).

[0069] Further, each of the protocols can customize the frame structure used for the protocol parsing, specifically including: Defining the message structure, including specifying the frame header, frame tail, communication address ID, data length, and checksum; Defining the parsing rules, including defining the byte order (big-endian / little-endian), offset, parsing length, and event response; Mapping data points: according to the parsing rules, associating specific bytes in the message with a unified data point identifier. For example, the two bytes at offset address 0, length 2 in a 32-byte array of return messages are parsed as a 16-bit signed integer and mapped to a unified data point identifier.

[0070] The multi-protocol adaptive BMS host computer data interaction method provided in the embodiment is designed with an extensible protocol driver library in the protocol parsing layer. The protocol driver library includes the implementation of the driver library interface IMcuDriver and the abstract class driver AbstractMcuDriver. When a new protocol BMS device needs to be accessed, the developer or code maintenance personnel only needs to inherit the abstract class driver AbstractMcuDriver and override the implementation of the specific function method according to actual needs. Each protocol can customize its own frame structure for the protocol parsing, effectively separating the protocol parsing logic from the rigid source code, making it configurable and external. This greatly improves the scalability and flexibility of the system, realizes a revolutionary change from one-to-one hard coding to one-to-many adaptive adaptation, and completely solves the protocol compatibility problem.

[0071] In some embodiments, the protocol driver library further includes a plug-in base class, which includes a data structure, read-write methods, a polling thread, and historical record reading.

[0072] Specifically, the plug-in base class is used to define the standardized development specification of the plug-in, provide general capability encapsulation, and realize decoupling of the plug-in and the main program, so that plug-ins with different functions can be uniformly loaded, run, and managed in the main program.

[0073] The plug-in base class defines the core methods that the plug-in must implement, and specifies the interaction rules between the plug-in and the main program, so as to avoid the situation that the main program cannot recognize the plug-in due to the difference in the development style of the plug-in.

[0074] In some embodiments, the method further comprises: According to the pre-set plug-in document, the plug-in communication protocol is written, the related dll file is generated, and the file is placed in the specified folder. The host computer software dynamically loads the protocol library according to the specified folder path to perform communication connection and data analysis.

[0075] The plug-in base class encapsulates the logic required by all plug-ins into a ready-made method, including all possible data structures, read-write methods, polling threads, and history record reading, etc. According to the pre-set plug-in document, the plug-in communication protocol is written, the related dll file is generated, and the file is placed in the specified folder. The host computer software dynamically loads the protocol library according to the specified folder path to perform communication connection and data analysis, without the need to modify the code of the main program, thereby reducing the dependence on the source code.

[0076] In the specification provided herein, a large number of specific details are described. However, it can be understood that the embodiments of the application can be practiced without these specific details. Similarly, in order to simplify the application and help understand one or more of the various inventive aspects, in the above description of the exemplary embodiments of the application, various features of the embodiments of the application are sometimes grouped together into a single embodiment, figure, or description thereof. Among them, the claims following the detailed description are thus expressly incorporated into the detailed description, wherein each claim itself is a separate embodiment of the application.

[0077] Those skilled in the art can understand that the modules in the device in the embodiments can be adaptively changed and arranged in one or more devices different from the embodiments. The modules or units or components in the embodiments can be combined into one module or unit or component, and in addition, they can be divided into multiple sub-modules or sub-units or sub-components. Except that at least some of such features and / or processes or units are mutually exclusive.

[0078] It should be noted that the above-mentioned embodiments illustrate rather than limit the application, and that those skilled in the art will be able to design many alternative embodiments without departing from the scope of the appended claims. In the claims, any reference signs placed between parentheses shall not be construed as limiting the claim. The word 'comprising' does not exclude the presence of elements or steps other than those listed in a claim. The word 'a' or 'an' preceding an element does not exclude the presence of a plurality of such elements. The application can be implemented by means of both hardware and software, and any combination thereof. In a unitary claim, several devices, apparatuses or means can be listed, comprising means for carrying out a certain task. The use of the term'means' in a claim is intended to refer to a combination of devices, apparatuses or means for carrying out a task. The word 'first','second', 'third', etc. do not imply any order. The use of these terms is to be construed as an indication of particular embodiments. Steps in the above-described embodiments, unless otherwise specified, are not to be construed as necessarily limiting the order in which the steps are performed.

Claims

1. A multi-protocol adaptive BMS host computer monitoring system, characterized in that, Comprise: Device access layer, for the establishment of communication link between any BMS device and BMS host computer, so that the raw data of the BMS device is transmitted to the BMS host computer; Protocol analysis layer, receiving the raw data transmitted by the BMS host computer, analyzing the raw data according to the specified rules to obtain standard data; Data service layer, receiving the standard data, providing data interface for calling after integrating and packaging the standard data; And Application function layer, calling the data interface, so that the system can process data from any BMS device with consistent interface and logic; Wherein, the protocol analysis layer is designed with protocol driver library, and the protocol driver library comprises driver library interface IMcuDriver and implementation of abstract class driver AbstractMcuDriver.

2. The multi-protocol adaptive BMS host computer monitoring system of claim 1, wherein, The protocol driver library further comprises a plug-in base class.

3. The multi-protocol adaptive BMS host computer monitoring system of claim 1, wherein, The device access layer is designed with a connection manager; The connection manager is used to support automatic identification and parameter configuration of multiple communication interfaces.

4. The multi-protocol adaptive BMS host computer monitoring system of claim 1, wherein, The data service layer is designed with a unified data model and an internal data bus; The standard data is converted into standardized data following the unified data model and is published to the internal data bus; Other functional modules of the data service layer subscribe to associated data from the internal data bus.

5. The multi-protocol adaptive BMS host computer monitoring system of claim 4, wherein, The unified data model takes (DisPlayId, Name, Value, Address, Units) as the core structure, wherein the Name is a globally unique data point identifier; Other functional modules of the data service layer obtain the associated data by subscribing to the relevant DisPlayId.

6. A multi-protocol adaptive data interaction method, characterized in that, Comprise: Designing a protocol driver library in the protocol analysis layer of the BMS host computer software, the protocol driver library comprises driver library interface IMcuDriver and implementation of abstract class driver AbstractMcuDriver; The abstract class driver AbstractMcuDriver implements the driver library interface IMcuDriver; The abstract class driver AbstractMcuDriver defines a virtual method that can be overridden according to its own needs during different protocol analysis.

7. The multi-protocol adaptive data interaction method of claim 6, wherein, In the virtual method defined by the abstract class driver AbstractMcuDriver, each protocol can customize the frame structure used for protocol analysis.

8. The multi-protocol adaptive data interaction method of claim 7, wherein, Each of the frame structures used for protocol analysis by each protocol specifically comprises: Defining message structure, including specifying frame header, frame tail, communication address ID, data length and check code; Defining analysis rules, including defining byte order (big endian / little endian), offset, analysis length and event response; Mapping data points: according to the analysis rules, the specific bytes in the message are associated with the unified data point identifier.

9. The multi-protocol adaptive data interaction method of claim 6, wherein, The protocol driver library further comprises a plug-in base class, and the plug-in base class comprises data structure, read-write method, polling thread and history record reading.

10. The multi-protocol adaptive data interaction method of claim 9, wherein, Further comprise: According to the preset plug-in document, a plug-in communication protocol is developed, a related dll file is written, and the dll file is placed into a specified folder; The host computer software dynamically loads a protocol library according to a specified folder path to perform communication connection and data analysis.

Images