Flexible energy storage system bus debugging system and method

Abstract

The invention discloses a flexible energy storage system bus debugging system and method, and belongs to the technical field of industrial energy storage systems. Comprising a host and slaves, the host is sequentially divided into a first physical layer, a first universal driving interface layer, a first universal protocol processing layer, a first interface processing layer and a man-machine interaction layer from bottom to top; the slave is sequentially divided into a second physical layer, a second universal driving interface layer, a second universal protocol processing layer, a second interface processing layer and a system service layer from bottom to top; according to the debugging system provided by the invention, a uniform driving interface and a universal protocol processing layer are designed, so that on one hand, rapid transplantation of different buses is facilitated, and on the other hand, differences of the different buses in bottom transmission are faded and eliminated, so that the debugging system does not depend on constraints of protocols of the buses; and establishment of a unified debugging method on various buses (CAN / wireless / wired) is flexibly supported.

Description

Technical Field

[0001] This invention relates to the field of industrial energy storage system technology, and in particular to a flexible energy storage system bus debugging system and method. Background Technology

[0002] In the debugging and diagnosis of battery management systems (BMS), bus systems are often required. Typically, bus systems can use CAN / wireless / wired networks, transmitting data according to bus protocol definitions of data IDs and frame formats. However, different buses differ in their operating modes, transmission rates, and underlying message lengths. When the system bus changes, functional compatibility cannot be quickly achieved, often requiring redevelopment and increasing maintenance costs. This approach is complex, cumbersome, and inefficient when debugging BMS systems. Therefore, a flexible bus debugging method is needed to improve the maintainability of BMS systems. Summary of the Invention

[0003] To address the shortcomings of existing technologies, this invention provides a flexible energy storage system bus debugging system and method that is not dependent on the constraints of the bus protocol itself and supports the establishment of a unified debugging method on multiple buses (CAN / wireless / wired).

[0004] To achieve the above objectives, the present invention provides a flexible energy storage system bus debugging system, including a master and a slave;

[0005] The host comprises five layers, which are divided into the following layers from bottom to top: first physical layer, first general driver interface layer, first general protocol processing layer, first interface processing layer, and human-computer interaction layer.

[0006] The slave device comprises five layers, which are divided into the following layers from bottom to top: the second physical layer, the second general driver interface layer, the second general protocol processing layer, the second interface processing layer, and the system service layer.

[0007] The first physical layer and the second physical layer are the physical bus, used to connect the master and slave devices;

[0008] The first and second general-purpose driver interface layers unify the operation interface by defining a unified pointer, which facilitates bus switching.

[0009] Both the first and second general protocol processing layers include a general security protocol processing module to complete data interaction between the host and the slave. The data consists of a unified frame structure and defined instruction codes and response codes. The data interaction mechanism includes security authentication, control flow, and secure data exchange.

[0010] The first interface processing layer includes a graphics protocol parsing interface and a general processing module; the second interface processing layer includes a graphics protocol interface, a CLI interface, and a general processing module.

[0011] The human-computer interaction layer is used for human-computer information interaction, including image display, interactive terminal and simulation terminal;

[0012] The system service layer includes a debugging kernel, which is used to obtain debugging variables, debugging information, system status, and system service types.

[0013] Furthermore, the bus can be a CAN bus, a wireless bus, or a wired bus.

[0014] Furthermore, the general security protocol processing module includes:

[0015] Set the slave ID and master ID. The master ID needs to be registered with the slave device before it can be used.

[0016] Define short frame and long frame formats: The short frame consists of a short frame identifier, data, and a checksum. The short frame data contains instruction codes, and the entire frame data can be sent and received by calling the driver read / write interface once; The long frame consists of a long frame identifier, data, and a CRC, and the entire frame data can be sent and received by calling the driver read / write interface multiple times.

[0017] Set control flow control identifiers and data flow control identifiers, both of which are sent using the short frames to form control flow control short frames and data flow control short frames; the control flow control short frames are used for interaction between non-data frames, and the data flow control short frames are used for interaction between data streams.

[0018] Furthermore, before the host registers with the slave, it can only use the short frame for sending and receiving;

[0019] The long frame transmission process is as follows: the sending end sends the first frame of the long frame, the receiving end receives it and returns the control flow control short frame or data flow control short frame, and the sending end sends the subsequent frames of the long frame after receiving the response, without the need for a response from the receiving end.

[0020] Furthermore, the first and second general-purpose driver interface layers are designed with multiple driver interface pointers, including driver initialization interface pointer, driver open interface pointer, driver close interface pointer, driver set interface pointer, driver read interface pointer, and driver write interface pointer.

[0021] Based on the type of the physical bus, its corresponding driver interface is mapped to the driver interface pointer, thereby unifying the interface and facilitating switching between different physical buses.

[0022] Furthermore, the system service types include immediate command, variable debugging, memory debugging, curve debugging, real-time debugging, event and fault record query, virtual terminal, and script debugging.

[0023] Furthermore, the graphics protocol interface is responsible for parsing the feature code data of the image protocol into a parsing string that can be recognized and displayed;

[0024] The CLI interface is responsible for mapping specific feature codes to internal commands, executing internal commands, and obtaining the results of command execution.

[0025] The general processing module is responsible for handling requests for other feature codes, including issuing commands for packaging or parsing general commands.

[0026] Furthermore, the graphical display is used to display the data parsed by the graphical protocol interface;

[0027] The interactive terminal is a debugging interface used to set debugging commands and display feedback results;

[0028] The simulated terminal is a specific debugging interface used to graphically display the internal file structure of the slave device.

[0029] The present invention also provides a flexible energy storage system bus debugging method, based on the flexible energy storage system bus debugging system described above, comprising the following steps:

[0030] (1) Perform a secure access process to complete the registration from the host to the slave;

[0031] (1.1) The host uses the default ID and sends a short frame containing a login request identifier and key data to the slave. If the slave fails to verify, it responds with an error short frame; otherwise, it responds with a successful registration short frame.

[0032] (1.2) After successful registration, the host sends a short frame of communication configuration parameters to set the host ID, long frame length, short frame length and inter-frame delay, and the slave returns a short frame of successful configuration.

[0033] (1.3) The host sends a short frame requesting version features. The slave receives the host's request and returns a long frame containing the currently supported system service types, debugging variables, and a list of feature codes. The returned data is encrypted with a key. The host receives and decrypts the data and displays it on the interactive terminal.

[0034] (2) The host selects the debugging method to be performed based on the system service type returned by the slave, and sends the command string to the slave through the interactive terminal according to its corresponding format;

[0035] (3) The slave device distributes the host signature to the general security protocol processing module through the second general protocol processing layer. The general security protocol processing module parses the command and executes it to the system service. If there is a return, the return data is packaged and sent to the host.

[0036] (4) The host receives the data and parses it into the general security protocol processing module of the first general protocol processing layer. The data is distributed to the general processing module or the graphical protocol interface according to the debugging signature type, and then displayed through the interactive terminal or the graphical window.

[0037] (5) Debugging complete. Send the end signature command to terminate debugging.

[0038] The beneficial effects of this invention are:

[0039] The debugging system provided by this invention features a unified driver interface and a universal protocol processing layer. This facilitates rapid portability to different buses and minimizes or eliminates the differences in underlying transmission between different buses. As a result, the debugging system is not constrained by the bus's own protocol and can flexibly support the establishment of a unified debugging method on multiple buses (CAN / wireless / wired). Attached Figure Description

[0040] Figure 1 This is a schematic diagram of the flexible energy storage system bus debugging system structure according to an embodiment of the present invention.

[0041] Figure 2 This is a schematic diagram of the long frame transmission process according to an embodiment of the present invention.

[0042] Figure 3 This is a schematic diagram of the secure access process according to an embodiment of the present invention.

[0043] Figure 4 This is a schematic diagram of the flexible energy storage system bus debugging method according to an embodiment of the present invention. Detailed Implementation

[0044] The present invention will be further explained below with reference to the accompanying drawings and embodiments.

[0045] like Figure 1 As shown, this embodiment of the invention provides a flexible energy storage system bus debugging system, which designs a unified driver interface and a universal protocol processing layer, supporting the establishment of a unified debugging method on multiple buses (CAN / wireless / wired). The architecture is a client / server (C / S) model, specifically including:

[0046] The host architecture is divided into five layers, from bottom to top: the first physical layer, the first general driver interface layer, the first general protocol processing layer, the first interface processing layer, and the human-computer interaction layer.

[0047] The slave architecture is divided into five layers, from bottom to top: the second physical layer, the second general driver interface layer, the second general protocol processing layer, the second interface processing layer, and the system service layer.

[0048] The first and second physical layers constitute the physical bus, used to connect the master and slave devices. This physical bus can be a CAN bus, a wireless bus, or a wired bus.

[0049] The first and second general-purpose driver interface layers are used to unify the operation interface and facilitate bus switching. The designed driver interface pointers include the following six types:

[0050] Driver initialization interface drv_dev_init(void)

[0051] The driver opens the interface drv_dev_open(void)

[0052] The driver closes the interface drv_dev_close(void).

[0053] The driver configuration interface is drv_dev_option(struct devInfo param).

[0054] The driver read interface is drv_dev_read(long id, char*buf, int len).

[0055] The driver write interface is drv_dev_write(long id, char*buf, int len).

[0056] The interface pointers described above are the same for CAN / wireless / wired buses. Their purpose is to mask bus characteristic information; these are referred to as bus device driver interface pointers. Based on the type of physical bus, its corresponding driver interface is mapped to the driver interface pointer, thus unifying the interface and facilitating switching between different physical buses.

[0057] Considering the differences between different buses (different operating modes, transmission rates, and underlying message lengths), a first general protocol processing layer and a second general protocol processing layer were designed. A general security protocol processing module was designed within both layers to complete data interaction between the master and slave devices. Data consists of a unified frame structure and defined instruction and response codes. The data interaction mechanism includes security authentication, control flow, and secure data exchange, specifically:

[0058] 1. Define short frame and long frame formats

[0059] A short frame consists of a 1-byte or 2-byte short frame identifier, data, and checksum. The short frame data contains instruction codes, and the entire frame data can be sent and received by calling the driver read / write interface once.

[0060] A long frame consists of a 1-byte or 2-byte long frame identifier, data, and a 2-byte CRC. The entire frame of data is sent and received by calling the driver's read / write interface multiple times.

[0061] 2. Set slave ID and master ID

[0062] The host ID needs to be registered with the slave device before it can be used;

[0063] 3. Set control flow control identifier and data flow control identifier, both of which are sent using the aforementioned short frames to form control flow control short frames and data flow control short frames; control flow control short frames are used for interaction between non-data frames, and data flow control short frames are used for interaction between data streams.

[0064] Short frame transmission process:

[0065] The sending end sends short frames, and the receiving end receives and processes the short frames.

[0066] Long frame transmission process:

[0067] like Figure 2 As shown, the sending end sends the first frame of a long frame, and the receiving end returns a short control frame or a short data flow control frame after receiving the first frame. After receiving the response, the sending end sends subsequent frames of the long frame without requiring a response from the receiving end.

[0068] Examples of instruction codes are shown in the table below:

[0069] Table 1

[0070] Instruction code describe 0xA0 Handshake / Registration 0xA1 Set communication parameters 0xA2 Data transmission

[0071] Examples of response codes are shown in the table below:

[0072] Table 2

[0073] Response code describe 0x00 normal 0x01 Verification failed 0x02 Parameter setting failed. 0x03 Internal error 0x04 Waiting timeout 0x05 Execution failed 0x06 Single packet CRC check error 0x07 Multiple frame CRC check errors or multiple frame loss during reception 0x08 Cancel

[0074] The frame format is shown in the table below:

[0075] Table 3

[0076]

[0077] Wherein: Valid data bytes: The number of bytes excluding the checksum, FC defaults to 0.

[0078] The first and second interface processing layers process the feature codes parsed by the general security protocol processing module. The first interface processing layer includes a graphical protocol parsing interface and a general processing module; the second interface processing layer includes a graphical protocol interface, a CLI interface, and a general processing module. The graphical protocol interface is responsible for parsing the feature code data of the image protocol into a recognizable and displayable string; the CLI interface provides an interface for specific feature codes, which can be mapped to internal commands, executed, and the results obtained; the general processing module handles requests for other feature codes, including issuing command packaging or parsing general commands.

[0079] The human-computer interaction layer is used for human-computer information interaction, including image display, interactive terminal, and simulated terminal. The image display is used to display the data parsed by the image protocol interface; the interactive terminal is a debugging interface used to set debugging commands and display feedback results; the simulated terminal is a specific debugging interface that can graphically display the internal file structure of the remote slave device (here, graphical display refers to displaying the hierarchical relationship using a simplified ASCII code method).

[0080] The system service layer contains a debugging kernel used to acquire debug variables, debug information, system status, and system service types. Debug variables are internally named variables. The program collects debug variable information and displays it to the debugging client. The debugging client issues debug commands in a specified signature code format, which is done in conjunction with an interactive terminal and a graphical display interface. Debug information is the information returned after any signature code command is issued. System status is variable information reflecting the system state stored during current system runtime. Service types include: command type, variable debugging, memory debugging, curve debugging, event commands, fault logging, real-time debugging, virtual terminal, and debug scripts.

[0081] Based on the flexible energy storage system bus debugging system described above, this embodiment of the invention also provides a flexible energy storage system bus debugging method, such as... Figure 4 As shown, it includes the following steps:

[0082] S101. Perform the secure access process and complete the registration from host to slave.

[0083] like Figure 3 As shown, specifically:

[0084] (1) The host uses the default ID and sends a short frame containing the login request identifier and key data to the slave. If the slave fails to verify, it responds with an error short frame; otherwise, it responds with a successful registration short frame.

[0085] (2) The host sends a short frame of communication configuration parameters to set the host ID, long frame length, short frame length and inter-frame delay.

[0086] (3) The host sends a short frame requesting version features. The slave receives the host requesting a long frame of data on the system service types supported by the current service. The returned data is encrypted with a key. After the host receives the long frame of version features and successfully verifies it, it decrypts the data with its local private key to obtain the plaintext feature code, function usage, and feature description, and then displays it on the interactive terminal.

[0087] S102. The host selects the debugging mode to be performed based on the system service type returned by the slave, and sends the command string to the slave through the interactive terminal according to its corresponding format.

[0088] System service types include immediate command, variable debugging, memory debugging, curve debugging, real-time debugging, event and fault log query, virtual terminal, and script debugging.

[0089] S103. The slave device distributes the host signature to the general security protocol processing module through the second general protocol processing layer. The general security protocol processing module parses the command and executes it to the system service. If there is a return, the return data is packaged and sent to the host.

[0090] S104. The host receives data and parses it into the general security protocol processing module of the first general protocol processing layer. According to the debugging signature type, the data is distributed to the general processing module or the graphical protocol interface, and then displayed through the interactive terminal or the graphical window.

[0091] S105. Debugging complete. Send the end signature command to terminate debugging.

[0092] The following example uses variable / curve debugging to illustrate the specific debugging process:

[0093] Step 1: The host configures communication parameters (long frame length, short frame length, frame delay, key, host ID) and sends a registration frame to the slave. The slave accepts the frame and registers successfully.

[0094] Step 2: The host sends a version feature request frame to obtain the currently available debugging commands. After receiving the data returned by the slave, the host decodes the feature characters and displays them as a visual string in the interactive terminal.

[0095] Step 3: The host finds the variable debugging list feature code based on the feature command table sent by the slave, and edits the command string through the interactive terminal and sends it to the slave.

[0096] Step 4: The slave device receives the variable debugging list request command sent by the master device, packages the variable list and sends it to the master device for display.

[0097] Step 5: The host machine views the variable debugging list, and according to the variable debugging distribution format in the feature command, edits the debugging variable command string through the interactive terminal and sends it to the slave machine.

[0098] Step 6: After receiving the variable debugging command, the slave device registers the debugging variables. Repeat steps 5-6, or register a group of variables using the multi-variable registration method. The system periodically collects variable data based on the registered variable information, packages each variable according to a predetermined format (see the format description section), and inserts the packaged string into the cache. The debugging kernel periodically checks the cache and packages the cached data to send to the host.

[0099] Step 7: The host receives data and parses it into the general protocol module. Based on the type of the received feature code, it forwards the data to the general data processing module or the graphics protocol interface. The former decrypts the data and displays it directly on the interactive terminal, while the latter decrypts the data and then parses the graphics format to display the data in the graphics window.

[0100] Step 8: After debugging is complete, terminate debugging by sending the debug variable cancellation command.

[0101] The preferred embodiments of the present invention have been described in detail above. It should be understood that those skilled in the art can make numerous modifications and variations based on the concept of the present invention without creative effort. Therefore, all technical solutions that can be obtained by those skilled in the art based on the concept of the present invention through logical analysis, reasoning, or limited experimentation on the basis of existing technology should be within the scope of protection defined by the claims.

Claims

1. A flexible energy storage system bus debugging system, comprising a host and a slave; characterized in that: The host comprises five layers, which are divided into: a first physical layer, a first general driver interface layer, a first general protocol processing layer, a first interface processing layer, and a human-computer interaction layer from bottom to top; The slave includes five layers, which are divided into: a second physical layer, a second general driver interface layer, a second general protocol processing layer, a second interface processing layer, and a system service layer from bottom to top; The first physical layer and the second physical layer are physical buses, which are used to connect the host and the slave; The first universal driver interface layer and the second universal driver interface layer unify the operation interface by defining a unified pointer, so as to facilitate bus switching; The first general protocol processing layer and the second general protocol processing layer both include a general security protocol processing module to complete data interaction between the host and the slave, the data is composed of a unified frame structure and defined instruction codes and response codes, and the data interaction mechanism includes security authentication, control flow, and data security exchange; The first interface processing layer includes a graphics protocol parsing interface and a general processing module; the second interface processing layer includes a graphics protocol interface, a CLI interface and a general processing module; the human-computer interaction layer is used for human-computer information interaction, including image display, interactive terminal and simulation terminal; The system service layer includes a debugging kernel for obtaining debugging variables, debugging information, system status and system service types.

2. The flexible energy storage system bus debugging system according to claim 1, characterized in that: The bus is a CAN bus, a wireless bus or a wired bus.

3. The flexible energy storage system bus debugging system according to claim 1, characterized in that: The general security protocol processing module includes: Set the slave ID and host ID. The host ID needs to be registered with the slave before it can be used; Define the short frame and long frame formats: the short frame consists of a short frame identifier, data and checksum, the short frame data contains an instruction code, and the entire frame data can be sent and received by calling the driver read / write interface once; the long frame consists of a long frame identifier, data and CRC, and the entire frame data can be sent and received by calling the driver read / write interface multiple times; The control flow control identifier and the data flow control identifier are set, and both are sent using the short frame to form a control flow control short frame and a data flow control short frame; the control flow control short frame is used for interaction between non-data frames, and the data flow control short frame is used for interaction between data streams.

4. The flexible energy storage system bus debugging system according to claim 3 is characterized in that: Before the host registers with the slave, only the short frame can be used for transceiver; The long frame sending process is: the sending end sends the long frame first frame, and the receiving end returns the control flow control short frame or data flow control short frame after receiving it. After receiving the response, the sending end sends the long frame subsequent frames without the need for the receiving end to respond.

5. The flexible energy storage system bus debugging system according to claim 1, characterized in that: The first universal driver interface layer and the second universal driver interface layer are designed with a plurality of driver interface pointers, including a driver initialization interface pointer, a driver opening interface pointer, a driver closing interface pointer, a driver setting interface pointer, a driver reading interface pointer, and a driver writing interface pointer; According to the type of the physical bus, the corresponding driver interface is mapped to the driver interface pointer, so that the interface is unified and the switching between different physical buses is convenient.

6. The flexible energy storage system bus debugging system according to claim 1, characterized in that: The system service types include immediate commands, variable debugging, memory debugging, curve debugging, real-time debugging, event and fault record query, virtual terminal, and script debugging.

7. The flexible energy storage system bus debugging system according to claim 1, characterized in that: The graphic protocol interface is responsible for parsing the data of the characteristic code of the image protocol into a parsing string that can be recognized and displayed; The CLI interface is responsible for mapping specific feature codes to internal commands, executing internal commands and obtaining command execution results; The general processing module is responsible for processing requests of other feature codes, including sending command packages or general command parsing.

8. The flexible energy storage system bus debugging system according to claim 1, characterized in that: The graphic display is used to display the data parsed by the graphic protocol interface; The interactive terminal is a debugging interface for setting debugging instructions and displaying feedback results; the simulation terminal is a specific debugging interface for graphically displaying the internal file structure of the slave.

9. A flexible energy storage system bus debugging method, based on the flexible energy storage system bus debugging system according to any one of claims 1 to 8, characterized in that: The steps include: (1) Perform a secure access process to complete the registration of the host to the slave; (1.1) The host uses the default ID to send a short frame with a login request identifier and secret key data to the slave. If the slave fails to verify, it responds with an error short frame, otherwise it responds with a successful registration short frame; (1.2) After successful registration, the host sends a short frame of communication configuration parameters to set the host ID, long frame length, short frame length and inter-frame delay, and the slave returns a short frame of successful configuration; (1.3) The host sends a short frame requesting the version feature, and the slave receives the request from the host and returns a long frame containing the currently supported system service type, debugging variables, and feature code list, and the returned data is encrypted by a secret key; After receiving and decrypting, the host displays it on the interactive terminal; (2) The host selects the current debugging mode according to the system service type returned by the slave, and edits the command string through the interactive terminal according to its corresponding format and sends it to the slave; (3) The slave distributes the host feature code to the general security protocol processing module through the second general protocol processing layer. The general security protocol processing module parses the command and executes it to the system service. If there is a return, the return data is packaged and sent to the host; (4) The host receives the data and parses it into the general security protocol processing module of the first general protocol processing layer, distributes the data to the general processing module or the graphic protocol interface according to the debugging feature code type, and then displays it through the interactive terminal or the graphic window; (5) After debugging is completed, send the end signature code command to terminate debugging.

Images