Data transmission method and system of energy storage BMS (Battery Management System)
By using data block processing, ECDH algorithm and AES-GCM encryption technology, the inconvenience and security issues of remote upgrades of BMS systems have been resolved, and an efficient and secure remote upgrade solution has been achieved.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-12-31
- Publication Date
- 2026-04-14
AI Technical Summary
Traditional BMS remote upgrade methods are inconvenient to operate and pose risks of device tampering or information leakage, making it difficult to achieve efficient and secure remote upgrades on a large scale of devices.
By employing data block processing, ECDH algorithm, and AES-GCM encryption technology, combined with TCP transmission protocol, data segment encryption, decryption, and verification are achieved, and data integrity and security are ensured through a synchronization mechanism.
It improves the efficiency and security of remote upgrades of the BMS system, ensures the high efficiency, reliability and flexibility of data transmission, and adapts to different network environments.
Smart Images
Figure CN121864413A_ABST
Abstract
Description
Technical Field
[0001] This application relates to the field of BMS system technology, and in particular to a method and system for data transmission in an energy storage BMS system. Background Technology
[0002] With the increasing global demand for renewable energy, battery management systems (BMS) are playing a crucial role in fields such as solar panels and electric vehicles. BMS is primarily responsible for key functions such as monitoring battery status, managing the charging and discharging process, and predicting residual life, ensuring the safety and efficiency of battery systems.
[0003] However, as equipment grows larger, the demand for remote upgrades also increases. This demand mainly manifests in software or firmware version updates, parameter configurations, and feature expansions. Traditional BMS remote upgrade methods typically rely on dedicated tools or physical connections, which not only limits user convenience but also carries the risk of device tampering or information leakage. Summary of the Invention
[0004] In view of this, embodiments of this application provide a method for data transmission in an energy storage BMS system. One or more embodiments of this application also relate to a system for data transmission in an energy storage BMS system, a computing device, a computer-readable storage medium, and a computer program, to address the technical deficiencies existing in the prior art.
[0005] According to a first aspect of the embodiments of this application, a method for data transmission in an energy storage BMS system is provided, comprising: The client segments the OTA firmware data used for remote upgrades in the energy storage BMS system to obtain multiple OTA firmware data fragments. The client encrypts each OTA firmware data segment to obtain an encrypted OTA firmware data segment, and then sends the encrypted OTA firmware data segment to the server. The server obtains the original data segment of each OTA firmware by decrypting and verifying each encrypted OTA firmware data segment. The server combines all OTA firmware raw data fragments to obtain OTA firmware raw data, and uses the OTA firmware raw data to remotely upgrade the energy storage BMS system.
[0006] Preferably, the client segments the OTA firmware data used for remote upgrades in the energy storage BMS system to obtain multiple OTA firmware data fragments, including: The client divides the OTA firmware data used for remote upgrades in the energy storage BMS system into fixed block sizes to obtain multiple OTA firmware data fragments, and records and saves the data number of each OTA firmware data fragment in sequence.
[0007] Preferably, it further includes: The client sends an initial synchronization packet containing local time, system time, total data file length, and fixed block size to the server, so that the server can generate and save an authentication code based on the initial synchronization packet, and return the authentication code to the client to complete the data synchronization between the client and the server.
[0008] Preferably, it further includes: Using the ECDH algorithm, the client and the server negotiate the same shared key.
[0009] Preferably, the client encrypts each OTA firmware data segment to obtain an encrypted OTA firmware data segment, and then sends the encrypted OTA firmware data segment to the server, including: The client uses the shared key to encrypt each OTA firmware data segment using AES-GCM, thereby obtaining each encrypted OTA firmware data segment. The client sends each encrypted OTA firmware data fragment to the server via TCP in the form of a binary stream, and records the data number corresponding to each encrypted OTA firmware data fragment. The client receives feedback information returned by the server within a set time, and determines whether the encrypted OTA firmware data fragment corresponding to the recorded data number is normal based on the feedback information. If it is determined that the encrypted OTA firmware data segment corresponding to the recorded data number is normal, the client sends the encrypted OTA firmware data segment corresponding to the next data number of the recorded data number to the server. If the encrypted OTA firmware data segment corresponding to the recorded data number is determined to be abnormal, the client resends the encrypted OTA firmware data segment corresponding to the recorded data number to the server.
[0010] Preferably, the server decrypts and verifies each encrypted OTA firmware data segment to obtain the original data segment of each OTA firmware, which includes: The server uses the shared key to perform AES-GCM decryption and verification on each encrypted OTA firmware data segment to obtain the AES-GCM decryption and verification result and each original OTA firmware data segment and its corresponding data number. The server determines whether the AES-GCM decryption and verification process is successful. If the AES-GCM decryption and verification process is successful, the server saves each OTA firmware original data segment and its corresponding data number, generates feedback information indicating that the data is normal, and sends the feedback information indicating that the data is normal to the client. If the AES-GCM decryption and verification process fails, the server discards the original data fragment of the OTA firmware and its corresponding data number, generates feedback information containing data anomalies, and sends the feedback information containing data anomalies to the client.
[0011] Preferably, the server combines all the original OTA firmware data fragments to obtain the original OTA firmware data, which includes: The server combines all OTA firmware raw data segments according to each OTA firmware raw data segment and its corresponding data number to obtain the OTA firmware raw data.
[0012] According to a second aspect of the embodiments of this application, a system for data transmission in an energy storage BMS system is provided, comprising: The client is configured to segment the OTA firmware data used for remote upgrades in the energy storage BMS system to obtain multiple OTA firmware data fragments; to encrypt each OTA firmware data fragment to obtain an encrypted OTA firmware data fragment, and to send each encrypted OTA firmware data fragment to the server. The server is configured to decrypt and verify each encrypted OTA firmware data segment to obtain each OTA firmware raw data segment; combine all OTA firmware raw data segments to obtain OTA firmware raw data; and use the OTA firmware raw data to remotely upgrade the energy storage BMS system.
[0013] According to a third aspect of the embodiments of this application, a computing device is provided, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions to implement any of the steps of the method for data transmission in the energy storage BMS system.
[0014] According to a fourth aspect of the present application, a computer-readable storage medium is provided that stores computer-executable instructions, which, when executed by a processor, implement the steps of the method for data transmission in any one of the energy storage BMS systems.
[0015] According to a fifth aspect of the present application, a computer program is provided, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described method for data transmission in an energy storage BMS system.
[0016] The data transmission scheme for an energy storage BMS system provided in this application embodiment involves the client segmenting OTA firmware data used for remote upgrades in the energy storage BMS system to obtain multiple OTA firmware data fragments. The client encrypts each OTA firmware data fragment to obtain encrypted OTA firmware data fragments and sends these encrypted fragments to the server. The server decrypts and verifies each encrypted OTA firmware data fragment to obtain the original OTA firmware data fragment. The server combines all the original OTA firmware data fragments to obtain the original OTA firmware data and uses this original data to remotely upgrade the energy storage BMS system. This scheme is suitable for remote updates and configurations over a network and offers the following advantages: High efficiency: Based on ECDH and AES-GCM algorithms, it maintains high efficiency during large-scale data transmission. Reliability: Multiple error detection mechanisms (timeout retransmission, packet loss notification, etc.) ensure data integrity. Security: Combined with ECDH key distribution, end-to-end encryption of data is achieved. Flexibility: It supports dynamic adjustment of block size and transmission rate, allowing the system to adapt to different network environments. Attached Figure Description
[0017] Figure 1 This is a flowchart illustrating a data transmission method for an energy storage BMS system according to one embodiment of this application; Figure 2 This is a flowchart illustrating client (BMS host computer) encryption according to one embodiment of this application; Figure 3 This is a flowchart illustrating server (BMS program) decryption according to one embodiment of this application; Figure 4 This is an overall flowchart of a data transmission method for an energy storage BMS system provided in one embodiment of this application; Figure 5 This is a structural block diagram of a computing device provided in one embodiment of this application. Detailed Implementation
[0018] Many specific details are set forth in the following description to provide a full understanding of this application. However, this application can be implemented in many other ways different from those described herein, and those skilled in the art can make similar extensions without departing from the spirit of this application; therefore, this application is not limited to the specific embodiments disclosed below.
[0019] The terminology used in one or more embodiments of this application is for the purpose of describing particular embodiments only and is not intended to limit the scope of one or more embodiments of this application. The singular forms “a,” “the,” and “the” used in one or more embodiments of this application and in the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” used in one or more embodiments of this application refers to and includes any or all possible combinations of one or more associated listed items.
[0020] It should be understood that although the terms first, second, etc., may be used to describe various information in one or more embodiments of this application, such information should not be limited to these terms. These terms are only used to distinguish information of the same type from one another. For example, first may also be referred to as second without departing from the scope of one or more embodiments of this application, and similarly, second may also be referred to as first. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to a determination."
[0021] This application provides a method for data transmission in an energy storage BMS system. It also relates to a system for data transmission in an energy storage BMS system, a computing device, a computer-readable storage medium, and a computer program, which will be described in detail in the following embodiments.
[0022] Figure 1 A flowchart illustrating a method for data transmission in an energy storage BMS system according to an embodiment of this application is shown, as follows: Figure 1 As shown, the specific steps include:
[0023] Step S101: The client segments the OTA firmware data used for remote upgrades in the energy storage BMS system to obtain multiple OTA firmware data fragments. In one embodiment of this application, the client segments the OTA firmware data used for remote upgrades in the energy storage BMS system to obtain multiple OTA firmware data fragments. This includes: the client segments the OTA firmware data used for remote upgrades in the energy storage BMS system into multiple OTA firmware data fragments according to a fixed block size, and records and saves the data number of each OTA firmware data fragment in sequence.
[0024] In one embodiment of this application, the method further includes: the client sending an initial synchronization package containing local time, system time, total length of data file and fixed block size to the server, so that the server generates and saves an authentication code based on the initial synchronization package, and returns the authentication code to the client to complete the data synchronization between the client and the server.
[0025] In one embodiment of this application, the method further includes: using the ECDH algorithm, the client and the server negotiate the same shared key.
[0026] Step S102: The client encrypts each OTA firmware data segment to obtain an encrypted OTA firmware data segment, and sends the encrypted OTA firmware data segment to the server. In one embodiment of this application, the client encrypts each OTA firmware data segment to obtain an encrypted OTA firmware data segment, and then sends the encrypted OTA firmware data segment to the server. This includes: the client using the shared key to encrypt each OTA firmware data segment using AES-GCM to obtain an encrypted OTA firmware data segment; the client sending the encrypted OTA firmware data segment to the server via TCP in the form of a binary stream, while simultaneously recording the data number corresponding to each encrypted OTA firmware data segment; the client receiving feedback information returned by the server within a set time, and determining whether the encrypted OTA firmware data segment corresponding to the recorded data number is normal based on the feedback information; if the encrypted OTA firmware data segment corresponding to the recorded data number is normal, the client sends the encrypted OTA firmware data segment corresponding to the next data number of the recorded data number to the server; if the encrypted OTA firmware data segment corresponding to the recorded data number is abnormal, the client resends the encrypted OTA firmware data segment corresponding to the recorded data number to the server.
[0027] Step S103: The server decrypts and verifies each encrypted OTA firmware data segment to obtain the original data segment of each OTA firmware. In one embodiment of this application, the server obtains each OTA firmware original data segment by decrypting and verifying each encrypted OTA firmware data segment, including: the server using the shared key to perform AES-GCM decryption and verification on each encrypted OTA firmware data segment, obtaining the AES-GCM decryption and verification result and each OTA firmware original data segment and its corresponding data number; the server determining whether the AES-GCM decryption and verification result is successful; if the AES-GCM decryption and verification result is successful, the server saves each OTA firmware original data segment and its corresponding data number, generates feedback information indicating that the data is normal, and sends the feedback information indicating that the data is normal to the client; if the AES-GCM decryption and verification result is unsuccessful, the server discards the OTA firmware original data segment and its corresponding data number, generates feedback information indicating that the data is abnormal, and sends the feedback information indicating that the data is abnormal to the client.
[0028] Step S104: The server combines all OTA firmware raw data fragments to obtain OTA firmware raw data, and uses the OTA firmware raw data to remotely upgrade the energy storage BMS system.
[0029] In one embodiment of this application, the server obtains OTA firmware raw data by combining all OTA firmware raw data segments: the server combines all OTA firmware raw data segments according to each OTA firmware raw data segment and its corresponding data number to obtain OTA firmware raw data.
[0030] The data transmission scheme for energy storage BMS systems provided in this application embodiment is suitable for remote updates and configurations via the network, providing a more efficient and reliable encryption and decryption solution for remote upgrades of BMS systems, while improving the efficiency and security of remote system upgrades.
[0031] The purpose of this application is to provide a more efficient and reliable encryption and decryption solution for remote upgrades of BMS systems, thereby improving the efficiency and security of remote system upgrades.
[0032] This application provides an encryption / decryption protocol suitable for low-computing-power environments, addressing the following issues: 1) Achieving efficient encryption for BMS in low-computing-power environments: Due to limited resources, traditional encryption algorithms (such as AES) are difficult to apply, thus requiring a lightweight encryption / decryption method. 2) Preventing OTA firmware tampering and man-in-the-middle attacks: OTA update processes are easily affected by the external environment, therefore a proper encryption / decryption mechanism is needed to protect data from being stolen or tampered with. 3) Preventing packet loss during data transmission: When data is transmitted over long distances via a network, it may experience packet loss due to external environmental factors.
[0033] To address the above issues, the core technical solution provided in this application includes the following: A. Data segmentation and encryption technology: To achieve frame-by-frame encryption and decryption of files, we need to segment the binary file into blocks. Each frame (Block) is an independent data segment, transmitted sequentially over the network, and encrypted and decrypted simultaneously on both the client and server sides. B. Synchronization mechanism: To ensure correct data transmission and decryption, a synchronization mechanism is introduced: the client sends an initial synchronization package containing the total file length, block size, and other necessary information. The server generates a unique authentication code based on the initial synchronization package and returns it to the client. C. Block encryption and decryption algorithm: Based on the ECDH (Elliptic Curve Diffie-Hellman) algorithm, combined with AES-GCM (prefixed XOR counter unicast) encryption, secure data transmission is achieved. Specifically: Client encryption process: Each block is encrypted using AES-GCM, and a key is generated using ECDH to ensure secure transmission. Server decryption process: The same ECDH parameters are used to decrypt and verify the ciphertext, ensuring integrity. D. Network Process Optimization: Considering the potential congestion issues with TCP, the data transmission process has been optimized: An automated encryption and decryption process based on flow control has been implemented. An error detection mechanism (such as timeout retransmission) has been added. Dynamic adjustment of chunk size is supported to improve transmission efficiency.
[0034] Figure 2 This is a flowchart of client (BMS host computer) encryption provided in one embodiment of this application, such as... Figure 2As shown, the client is a local BMS host computer. First, the client actively sends a Sync Package containing information such as local time, system time, and total file length. Then, it receives the binary file to be encrypted and divides the file into multiple equal blocks, each frame being a fixed-size data segment. Next, it uses ECDH to generate a symmetric key and combines it with the AES-GCM algorithm to encrypt each frame of data. Finally, it sends the encrypted binary stream to the remote server via TCP while maintaining a write state. Specific implementation steps include: Step 201: The client (host computer) reads the binary file (bin file) into the memory buffer; Step 202: Divide the data (binary file) into blocks of a specific size and generate a shared key according to the ECDH algorithm; Step 203: Encrypt each block using AES-GCM; By effectively combining ECDH with AES-GCM and integrating it with the TCP streaming protocol, efficient, reliable, and secure file block encryption and decryption are achieved. Specifically, ECDH technology allows both the client and server to generate their own keys (public key + private key). The client and server then use their respective private keys plus the other's public key to calculate a shared key. AES-GCM uses this shared key negotiated via ECDH to encrypt data blocks.
[0035] Step 204: Each encrypted data block is sent to the server via TCP in binary stream form, and the sending order is recorded. Step 205: Wait for the receiving server (BMS program) to receive feedback on the data block; Step 206: Judge the feedback from the server. If the feedback is abnormal, proceed to step 208; if the feedback is normal, proceed to step 207. Step 207: Send the next block of encrypted data; Step 208: If the number of retransmissions has not exceeded a certain number, retransmit the data block, and after retransmitting the data block, proceed to step 205.
[0036] Figure 3 This is a flowchart of server (BMS program) decryption provided in one embodiment of this application, as shown below. Figure 3As shown, the server is a BMS program. First, it receives the initial synchronization packet from the client (such as total file length, block size, etc.), generates a unique authentication code using a three-way handshake protocol, and returns a synchronization response packet. Second, it receives the encrypted binary stream according to the block size, decrypts each frame of data using the server's private key, and verifies data integrity. Finally, it concatenates the decrypted data into the original file. Specific implementation steps include: Step 301: Receive data blocks from the client; Step 302: Decrypt and perform CRC verification on the received data block; Step 303: Determine whether the decryption and verification were successful. If successful, proceed to step 304; otherwise, proceed to step 307. Step 304: Obtain the original data, reply to the client that the data block is normal, and receive the next data block; Step 305: Combine the normal data into the original data in a specific order; Step 306: Perform the corresponding operations on the original data; Step 307: The client receives an abnormal response and the system returns to step 301.
[0037] In this application, a synchronization mechanism is used between the client and server during the file transfer process: the client actively sends a SyncPackage containing information such as local time, system time, and total file length. The server generates an authentication code based on the Sync Package and returns an acknowledgment response. If the client does not receive an acknowledgment response, it will automatically retransmit the Sync Package. Client data is segmented and encrypted: the client divides the binary file into multiple frames of fixed block size (e.g., 1KB), and each frame is encrypted individually. Each frame uses an ECDH key pair combined with the AES-GCM algorithm for encryption. Server data decryption: after receiving each frame of encrypted stream data, the server decrypts it using the same key. The decrypted data is then verified for integrity using a CRC checksum; if invalid, the current frame is discarded and an error message is returned.
[0038] Figure 4 This illustration shows a schematic diagram of the structure of a data transmission system for an energy storage BMS system according to an embodiment of this application. Figure 4As shown, the system includes: a client configured to segment OTA firmware data used for remote upgrades in the energy storage BMS system to obtain multiple OTA firmware data fragments; to encrypt each OTA firmware data fragment to obtain encrypted OTA firmware data fragments, and to send each encrypted OTA firmware data fragment to a server; and a server configured to decrypt and verify each encrypted OTA firmware data fragment to obtain each original OTA firmware data fragment; to combine all the original OTA firmware data fragments to obtain original OTA firmware data, and to use the original OTA firmware data to remotely upgrade the energy storage BMS system.
[0039] The above is an illustrative scheme of a data transmission system for an energy storage BMS system according to this embodiment. It should be noted that the technical solution of this energy storage BMS system data transmission system belongs to the same concept as the technical solution of the energy storage BMS system data transmission method described above. Details not described in detail in the technical solution of the energy storage BMS system data transmission system can be found in the description of the technical solution of the energy storage BMS system data transmission method described above.
[0040] Figure 5 A structural block diagram of a computing device 500 according to an embodiment of this application is shown. The components of the computing device 500 include, but are not limited to, a memory 510 and a processor 520. The processor 520 is connected to the memory 510 via a bus 530, and a database 540 is used to store data.
[0041] The computing device 500 also includes an access device 540, which enables the computing device 500 to communicate via one or more networks 560. Examples of these networks include a Public Switched Telephone Network (PSTN), a Local Area Network (LAN), a Wide Area Network (WAN), a Personal Area Network (PAN), or a combination of communication networks such as the Internet. The access device 540 may include one or more of any type of wired or wireless network interface (e.g., a Network Interface Card (NIC)), such as an IEEE 802.11 Wireless Local Area Network (WLAN) interface, a Wi-MAX interface, an Ethernet interface, a Universal Serial Bus (USB) interface, a cellular network interface, a Bluetooth interface, a Near Field Communication (NFC) interface, and so on.
[0042] In one embodiment of this application, the aforementioned components of the computing device 500 and Figure 5 Other components, not shown, can also be connected to each other, for example, via a bus. It should be understood that... Figure 5The block diagram of the computing device shown is for illustrative purposes only and is not intended to limit the scope of this application. Those skilled in the art can add or replace other components as needed.
[0043] The computing device 500 can be any type of stationary or mobile computing device, including mobile computers or mobile computing devices (e.g., tablet computers, personal digital assistants, laptop computers, notebook computers, netbooks, etc.), mobile phones (e.g., smartphones), wearable computing devices (e.g., smartwatches, smart glasses, etc.) or other types of mobile devices, or stationary computing devices such as desktop computers or PCs. The computing device 500 can also be a mobile or stationary server.
[0044] The processor 520 is configured to execute the following computer-executable instructions, which, when executed by the processor, implement the steps of the above-described method for data transmission in the energy storage BMS system.
[0045] The above is an illustrative scheme of a computing device according to this embodiment. It should be noted that the technical solution of this computing device and the technical solution of the above-described method for data transmission in an energy storage BMS system belong to the same concept. For details not described in detail in the technical solution of the computing device, please refer to the description of the technical solution of the above-described method for data transmission in an energy storage BMS system.
[0046] An embodiment of this application also provides a computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the above-described method for data transmission in an energy storage BMS system.
[0047] The above is an illustrative scheme of a computer-readable storage medium according to this embodiment. It should be noted that the technical solution of this storage medium belongs to the same concept as the technical solution of the above-described method for data transmission in an energy storage BMS system. Details not described in detail in the technical solution of the storage medium can be found in the description of the technical solution of the above-described method for data transmission in an energy storage BMS system.
[0048] An embodiment of this application also provides a computer program, wherein when the computer program is executed in a computer, it causes the computer to perform the steps of the above-described method for data transmission in an energy storage BMS system.
[0049] The above is an illustrative scheme of a computer program according to this embodiment. It should be noted that the technical solution of this computer program and the technical solution of the above-described method for data transmission in an energy storage BMS system belong to the same concept. For details not described in detail in the technical solution of the computer program, please refer to the description of the technical solution of the above-described method for data transmission in an energy storage BMS system.
[0050] The foregoing has described specific embodiments of this application. Other embodiments are within the scope of the appended claims. In some cases, the actions or steps recited in the claims may be performed in a different order than that shown in the embodiments and may still achieve the desired results. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to achieve the desired results. In some embodiments, multitasking and parallel processing are also possible or may be advantageous.
[0051] The computer instructions include computer program code, which may be in the form of source code, object code, executable file, or certain intermediate forms. The computer-readable medium may include any entity or device capable of carrying the computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc. It should be noted that the content included in the computer-readable medium may be appropriately added to or subtracted according to the requirements of legislation and patent practice in the jurisdiction. For example, in some jurisdictions, according to legislation and patent practice, computer-readable media may not include electrical carrier signals and telecommunication signals.
[0052] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions and modules involved are not necessarily essential to the embodiments of this application.
[0053] In the above embodiments, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.
[0054] The preferred embodiments disclosed above are merely illustrative of this application. The optional embodiments do not exhaustively describe all details, nor do they limit the invention to the specific implementations described. Clearly, many modifications and variations can be made based on the embodiments of this application. These embodiments are selected and specifically described in this application to better explain the principles and practical applications of the embodiments of this application, thereby enabling those skilled in the art to better understand and utilize this application. This application is limited only by the claims and their full scope and equivalents.
Claims
1. A method for data transmission in an energy storage BMS system, characterized in that, include: The client segments the OTA firmware data used for remote upgrades in the energy storage BMS system to obtain multiple OTA firmware data fragments. The client encrypts each OTA firmware data segment to obtain an encrypted OTA firmware data segment, and then sends the encrypted OTA firmware data segment to the server. The server obtains the original data segment of each OTA firmware by decrypting and verifying each encrypted OTA firmware data segment. The server combines all OTA firmware raw data fragments to obtain OTA firmware raw data, and uses the OTA firmware raw data to remotely upgrade the energy storage BMS system.
2. The method according to claim 1, characterized in that, The client segments the OTA firmware data used for remote upgrades in the energy storage BMS system to obtain multiple OTA firmware data fragments, including: The client divides the OTA firmware data used for remote upgrades in the energy storage BMS system into fixed block sizes to obtain multiple OTA firmware data fragments, and records and saves the data number of each OTA firmware data fragment in sequence.
3. The method according to claim 2, characterized in that, Also includes: The client sends an initial synchronization packet containing local time, system time, total length of data files, and fixed block size to the server, so that the server can generate and save an authentication code based on the initial synchronization packet, and return the authentication code to the client to complete the data synchronization between the client and the server.
4. The method according to claim 3, characterized in that, Also includes: Using the ECDH algorithm, the client and the server negotiate the same shared key.
5. The method according to claim 4, characterized in that, The client encrypts each OTA firmware data fragment to obtain an encrypted OTA firmware data fragment, and then sends each encrypted OTA firmware data fragment to the server, including: The client uses the shared key to encrypt each OTA firmware data segment using AES-GCM, thereby obtaining each encrypted OTA firmware data segment. The client sends each encrypted OTA firmware data fragment to the server via TCP in the form of a binary stream, and records the data number corresponding to each encrypted OTA firmware data fragment. The client receives feedback information returned by the server within a set time, and determines whether the encrypted OTA firmware data fragment corresponding to the recorded data number is normal based on the feedback information. If it is determined that the encrypted OTA firmware data segment corresponding to the recorded data number is normal, the client sends the encrypted OTA firmware data segment corresponding to the next data number of the recorded data number to the server. If the encrypted OTA firmware data segment corresponding to the recorded data number is determined to be abnormal, the client resends the encrypted OTA firmware data segment corresponding to the recorded data number to the server.
6. The method according to claim 5, characterized in that, The server decrypts and verifies each encrypted OTA firmware data segment to obtain the original data segment of each OTA firmware, which includes: The server uses the shared key to perform AES-GCM decryption and verification on each encrypted OTA firmware data segment to obtain the AES-GCM decryption and verification result and each original OTA firmware data segment and its corresponding data number. The server determines whether the AES-GCM decryption and verification process is successful. If the AES-GCM decryption and verification process is successful, the server saves each OTA firmware original data segment and its corresponding data number, generates feedback information indicating that the data is normal, and sends the feedback information indicating that the data is normal to the client. If the AES-GCM decryption and verification process fails, the server discards the original data fragment of the OTA firmware and its corresponding data number, generates feedback information containing data anomalies, and sends the feedback information containing data anomalies to the client.
7. The method according to claim 6, characterized in that, The server combines all the raw OTA firmware data fragments to obtain the raw OTA firmware data, which includes: The server combines all OTA firmware raw data segments according to each OTA firmware raw data segment and its corresponding data number to obtain the OTA firmware raw data.
8. A data transmission system for an energy storage BMS system, characterized in that, include: The client is configured to segment the OTA firmware data used for remote upgrades in the energy storage BMS system to obtain multiple OTA firmware data fragments. Each OTA firmware data segment is encrypted to obtain an encrypted OTA firmware data segment, and the encrypted OTA firmware data segment is sent to the server. The server is configured to obtain the original data segment of each OTA firmware by decrypting and verifying each encrypted OTA firmware data segment. By combining all the original OTA firmware data fragments, the original OTA firmware data is obtained, and the original OTA firmware data is used to remotely upgrade the energy storage BMS system.
9. A computing device, comprising: Memory and processor; The memory is used to store computer-executable instructions, and the processor is used to execute the computer-executable instructions, which, when executed by the processor, implement the steps of the data transmission method of the energy storage BMS system according to any one of claims 1 to 7.
10. A computer-readable storage medium storing computer-executable instructions that, when executed by a processor, implement the steps of the method for data transmission in an energy storage BMS system according to any one of claims 1 to 7.