A data transmission method between a battery swap station and a vehicle end

Abstract

The application provides a data transmission method for a battery swap station and a vehicle end, the vehicle end comprising a vehicle end Bluetooth module, the battery swap station comprising a station end Bluetooth module, a station control integrated machine and a snapshot machine. The method comprises the following steps: the vehicle end Bluetooth module collects vehicle battery swap data through a vehicle bus; the vehicle end Bluetooth module generates a resolvable private address and performs Bluetooth broadcasting, and updates the broadcasting every preset time; the snapshot machine obtains identity information of the battery swap vehicle; the station control obtains connection information from a cloud platform according to the identity information and sends the connection information to the station end Bluetooth module; the station end Bluetooth module finds the Bluetooth broadcasting of the vehicle end Bluetooth module according to the connection information and establishes Bluetooth connection; bidirectional identity authentication is performed; after the authentication is passed, bidirectional transmission of vehicle battery swap data and battery swap control data is performed. Through the communication mode of the vehicle bus-low power consumption Bluetooth-Ethernet, in combination with dynamic address broadcasting, bidirectional identity authentication and link encryption, the application realizes safe and efficient data transmission between the vehicle end and the station end in the battery swap process.

Description

Technical Field

[0001] This application relates to the field of battery swapping technology for new energy vehicles, specifically to a data transmission method between a battery swapping station and the vehicle. Background Technology

[0002] Currently, with the transformation of the global energy structure and the increasing awareness of environmental protection, the popularity of new energy vehicles continues to rise. Battery swapping, as a new method of energy replenishment for electric vehicles, is receiving increasing attention and application due to its speed and convenience. During the battery swapping process, information exchange between the vehicle and the swapping station is crucial, including battery status, vehicle identification information, and battery swapping instructions.

[0003] Traditional methods of information transmission between vehicles and stations often employ wired or Wi-Fi communication, which suffers from problems such as complex deployment, high cost, high communication latency, and insufficient security. Furthermore, the operating environment of battery swapping stations is complex, requiring equipment to operate stably under harsh conditions such as high vibration and high humidity, which places higher demands on the reliability of the information transmission system.

[0004] Meanwhile, existing vehicle-to-station communication solutions have certain security vulnerabilities. For example, traditional wireless communication technologies may lack effective data encryption and authentication mechanisms, making them susceptible to malicious attacks or data theft, leading to the leakage or tampering of sensitive information, thereby affecting the safety and reliability of the battery swapping process.

[0005] Therefore, how to efficiently, reliably, and securely transmit information between the vehicle and the station has become a pressing technical problem that needs to be solved in this field. Summary of the Invention

[0006] The purpose of this application is to provide a data transmission method between a battery swapping station and the vehicle, which can achieve efficient, reliable and secure information transmission, thereby improving the operational efficiency of the battery swapping station.

[0007] In a first aspect, embodiments of this application provide a data transmission method between a battery swapping station and a vehicle, wherein the vehicle includes a vehicle-side Bluetooth module, and the battery swapping station includes a station-side Bluetooth module, a station control unit, and a snapshot camera; the method includes:

[0008] The vehicle-mounted Bluetooth module collects vehicle battery swapping data via the vehicle bus.

[0009] The vehicle-mounted Bluetooth module generates a resolvable private address and broadcasts via Bluetooth using the resolvable private address. It also regenerates the resolvable private address and updates the broadcast every preset time interval.

[0010] The camera captures the identity information of the battery swapping vehicle;

[0011] The station control unit obtains the connection information of the vehicle-side Bluetooth module from the cloud platform based on the identity information, and sends the connection information to the station-side Bluetooth module;

[0012] The station-side Bluetooth module searches for the Bluetooth broadcast of the vehicle-side Bluetooth module based on the connection information, and establishes a Bluetooth connection with the vehicle-side Bluetooth module after finding it.

[0013] After the Bluetooth connection is established, the station-side Bluetooth module and the vehicle-side Bluetooth module perform two-way identity authentication.

[0014] After two-way authentication is successful, the vehicle-side Bluetooth module will transmit the collected vehicle battery swapping data to the station-side Bluetooth module via Bluetooth. The station-side Bluetooth module will then transmit the received vehicle battery swapping data to the station control unit via Ethernet, and transmit the battery swapping control data from the station control unit to the vehicle-side Bluetooth module via Bluetooth. The vehicle-side Bluetooth module will then transmit the battery swapping control data to the vehicle bus.

[0015] Specifically, the station-side Bluetooth module re-initiates a connection when the Bluetooth connection fails to be established, actively searches for the Bluetooth broadcast of the vehicle-side Bluetooth module and re-establishes the Bluetooth connection when the Bluetooth connection is abnormally disconnected during data transmission, and actively disconnects the Bluetooth connection according to the instructions of the station control unit when the battery swapping ends.

[0016] Furthermore, the method for generating the resolvable private address is as follows:

[0017] Based on the unique identity resolution key stored in the vehicle-side Bluetooth module and a randomly generated random number, the resolvable private address is generated through a hash function.

[0018] The random number is updated periodically according to the preset time.

[0019] Furthermore, the two-way authentication process includes:

[0020] The station-side Bluetooth module obtains the temporary key issued by the station control integrated machine;

[0021] The station-side Bluetooth module generates a first random number, and the vehicle-side Bluetooth module generates a second random number.

[0022] A confirmation value is generated based on the temporary key, the first random number, and the second random number, and then exchanged and verified to confirm the legitimacy of both parties' identities.

[0023] Furthermore, after successful two-way authentication, the following steps are also included:

[0024] The Bluetooth communication link is encrypted using the AES-CCM algorithm to obtain an encrypted transmission channel;

[0025] The vehicle battery swapping data and the battery swapping control data are transmitted through the encrypted transmission channel.

[0026] Furthermore, the method also includes:

[0027] The vehicle-side Bluetooth module records pairing failure events from the same station-side Bluetooth module;

[0028] Based on the number of pairing failure events, the waiting time for the next pairing attempt is gradually increased until the preset maximum waiting time is reached.

[0029] Furthermore, the method also includes:

[0030] The vehicle-mounted Bluetooth module starts a pairing timer after the Bluetooth connection is established.

[0031] If pairing is not completed within the preset time, the Bluetooth connection will be forcibly disconnected.

[0032] Furthermore, the hardware security configuration of the vehicle-side Bluetooth module includes:

[0033] During the mass production phase, the JTAG connector is removed and the JTAG interface function is disabled, resulting in a non-debuggable hardware environment.

[0034] Configure the UART communication interface with a two-way authentication mechanism and use the AES128 encryption algorithm for data encapsulation to obtain a secure debugging communication channel.

[0035] Furthermore, the secure startup process of the vehicle-side Bluetooth module includes:

[0036] A root key is generated when the device is first booted, the password message authentication code value for the bootloader and applications is calculated, and stored in a protected Flash area;

[0037] Each time the system starts, the password message authentication code value is recalculated and compared with the stored password message authentication code value.

[0038] If they match, the system starts normally; if they don't match, it stops running to obtain a reliable boot chain.

[0039] Furthermore, the method also includes:

[0040] The server uses an RSA4096 private key to digitally sign the application firmware, generating a signed upgrade firmware.

[0041] The bootloader of the vehicle-mounted Bluetooth module uses a pre-stored public key to verify the signature of the upgraded firmware.

[0042] If the signature verification is successful, the firmware upgrade will be performed; if the signature verification fails, the firmware will be reverted to the original firmware.

[0043] Furthermore, the identity resolution key of the vehicle-side Bluetooth module is generated by the production testing computer during production testing, and stored in the on-chip Flash after being encrypted with AES128.

[0044] The temporary key used in the two-way authentication is sent from the cloud platform to the station control unit, and then from the station control unit to the station-side Bluetooth module for a single pairing process.

[0045] The data transmission method between the battery swapping station and the vehicle provided in this application involves the following steps: After the vehicle powers on its Bluetooth module, the module broadcasts a randomly changing, resolvable private address at regular intervals to prevent tracking. When a vehicle enters the battery swapping station, its license plate information is captured by the station's camera. The vehicle then automatically obtains Bluetooth information, including an identity resolution key and a temporary key, from the cloud platform and automatically sends a Bluetooth connection request. Upon receiving the Bluetooth connection request containing the identity resolution key and temporary key from the station control unit via Ethernet, the station's Bluetooth module first uses the identity resolution key to locate the resolvable private address broadcast by the vehicle's Bluetooth module. Then, it uses the pre-configured, high-efficiency Bluetooth connection parameters to establish a Bluetooth connection. Once the Bluetooth connection is successful, the vehicle's Bluetooth module initiates a pairing request to the station's Bluetooth module for mutual authentication. After pairing, the vehicle automatically encrypts the Bluetooth data transmitted over the air to prevent tampering and theft of battery swapping information. This application utilizes a communication method combining vehicle bus CAN, Bluetooth Low Energy (BLE), and Ethernet (ETH) to achieve safe and efficient battery swapping between vehicle-side information and battery swapping stations, ensuring the authenticity of the battery swapping service recipients and facilitating the management and maintenance of battery swapping stations. Attached Figure Description

[0046] Various other advantages and benefits will become apparent to those skilled in the art upon reading the following detailed description of preferred embodiments. The accompanying drawings are for illustrative purposes only and are not intended to limit the scope of this application. Furthermore, the same reference numerals denote the same parts throughout the drawings. In the drawings:

[0047] Figure 1 This paper presents a schematic diagram of a system structure for battery swapping communication interaction based on CAN-BLE-ETH, as provided in an embodiment of this application.

[0048] Figure 2 This application shows a schematic diagram of the internal structure of the vehicle-mounted Bluetooth module 10.

[0049] Figure 3 This application shows a schematic diagram of the internal structure of the station-side Bluetooth module 20;

[0050] Figure 4 A schematic diagram illustrating a resolvable private address format is shown;

[0051] Figure 5 This application shows a flowchart of the MCU debug port authentication process.

[0052] Figure 6 This application illustrates a flowchart regarding the generation of upgrade firmware with signature information;

[0053] Figure 7 A flowchart regarding the security upgrade in this application is shown;

[0054] Figure 8 This application illustrates a flowchart regarding upgrade protection against version rollback.

[0055] Figure 9 A schematic diagram of the system architecture related to information security in this application is shown. Detailed Implementation

[0056] Exemplary embodiments of the present disclosure will now be described in more detail with reference to the accompanying drawings. While exemplary embodiments of the present disclosure are shown in the drawings, it should be understood that the present disclosure may be implemented in various forms and should not be limited to the embodiments set forth herein. Rather, these embodiments are provided so that this disclosure will be thorough and complete, and will fully convey the scope of the disclosure to those skilled in the art.

[0057] It should be noted that, unless otherwise stated, the technical or scientific terms used in this application shall have the ordinary meaning as understood by one of ordinary skill in the art to which this application pertains.

[0058] Furthermore, the terms "first" and "second," etc., are used to distinguish different objects, not to describe a specific order. Additionally, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the listed steps or units, but may optionally include steps or units not listed, or may optionally include other steps or units inherent to those processes, methods, products, or apparatuses.

[0059] This application provides a data transmission method between a battery swapping station and a vehicle. The vehicle includes a vehicle-mounted Bluetooth module (VBLE), and the battery swapping station includes a station-mounted Bluetooth module (SBLE), a station control unit (hereinafter referred to as station control), and a snapshot camera. This battery swapping data interaction system can be referenced. Figure 1 The diagram shows the structure of a battery swapping data interaction system based on CAN-BLE-ETH.

[0060] Please refer to Figure 1 The battery swapping data interaction system includes a vehicle-side Bluetooth module 10 and a station-side Bluetooth module 20. The vehicle-side Bluetooth module 10 is installed on the vehicle and connected to the battery management system (BMS) via a CAN bus; the station-side Bluetooth module 20 is installed at the battery swapping station. Figure 2 As shown, the vehicle-mounted Bluetooth module 10 is equipped with an MCU main control unit, a BLE (Bluetooth Low Energy) communication unit, and a CAN unit. Figure 3 As shown, the station-side Bluetooth module 20 is equipped with an MCU main control unit, a BLE communication unit, and an ETH (Ethernet) communication unit. The vehicle-side Bluetooth module 10 and the station-side Bluetooth module 20 exchange data through their respective BLE communication units.

[0061] The above method specifically includes the following steps:

[0062] Step S1: The vehicle-side Bluetooth module collects vehicle battery swapping data through the vehicle bus.

[0063] The vehicle-side Bluetooth module 10 collects specific CAN messages from the vehicle via the CAN bus, including key information such as battery status, vehicle identification code, and vehicle status.

[0064] Step S2: The vehicle-side Bluetooth module generates a resolvable private address and broadcasts it via Bluetooth.

[0065] The vehicle-side Bluetooth module 10 generates a resolvable private address (RPA) and broadcasts it via Bluetooth. It also regenerates the resolvable private address and updates the broadcast every preset time interval.

[0066] Specifically, this embodiment provides a method for generating a resolvable private address: the resolvable private address is generated by a hash function based on the unique identity resolving key (IRK) stored in the vehicle-side Bluetooth module 10 and a randomly generated random number; wherein the random number is updated periodically according to the preset time.

[0067] For the format of resolvable private addresses, please refer to [reference]. Figure 4 It contains a 24-bit random part (prand value) and a 24-bit hash part (hash value). To ensure vehicle-side privacy and prevent tracking or spoofing due to the vehicle-side Bluetooth module 10 using a fixed Bluetooth address for broadcasting, the Bluetooth address needs to change randomly over time and be recognizable by the station-side Bluetooth module 20 of the battery swapping station. By using a resolvable private address, identity tracking issues in information security are effectively prevented.

[0068] Step S3: The camera captures the identity information of the battery swapping vehicle.

[0069] When a vehicle enters the battery swapping station, the station's camera captures the vehicle's license plate as its unique identification information.

[0070] Step S4: The station control unit obtains the connection information of the vehicle-side Bluetooth module from the cloud platform based on the identity information, and sends the connection information to the station-side Bluetooth module.

[0071] The station control unit uses the identity information of the battery swapping vehicle obtained by the camera to retrieve the connection information of the vehicle's Bluetooth module 10 from the cloud platform. Specifically, this connection information includes the identity resolution key (IRK) and temporary key (TK) for pairing of the vehicle's Bluetooth module 10. The manufacturer binds the IRK and vehicle information to the cloud platform before the vehicle's Bluetooth module 10 leaves the factory to ensure information security and automation during the battery swapping process.

[0072] Step S5: The station-side Bluetooth module searches for the Bluetooth broadcast of the vehicle-side Bluetooth module based on the connection information, and establishes a Bluetooth connection with the vehicle-side Bluetooth module after finding it.

[0073] When the station control unit sends a Bluetooth connection request to the station-side Bluetooth module 20 via Ethernet, it includes the connection information of the vehicle-side Bluetooth module 10 of the battery swapping vehicle. The station-side Bluetooth module 20 uses the Identity Resolution Key (IRK) in the connection information to search for whether the vehicle-side Bluetooth module 10 of that vehicle is broadcasting in the surrounding Bluetooth broadcasts.

[0074] Specifically, the process by which the station-side Bluetooth module 20 identifies the vehicle-side Bluetooth module 10 via IRK is as follows: It extracts a 24-bit random portion (prand value) and a 24-bit hash portion (hash value) from the scanned resolvable private address. Then, it calculates the localHash using the hash function localHash = ah(IRK, prand) defined in the Bluetooth specification. The localHash is compared with the hash value extracted from the resolvable private address. If they are equal, it confirms that the current resolvable private address corresponds to the vehicle-side Bluetooth module 10 of the IRK, thus completing the identification of the vehicle-side Bluetooth module 10 of the battery swapping vehicle. When a battery swapping vehicle is found to be broadcasting, the station-side Bluetooth module 20 uses this address to initiate a Bluetooth connection.

[0075] Step S6: After the Bluetooth connection is established, the station-side Bluetooth module and the vehicle-side Bluetooth module perform two-way authentication.

[0076] Once the station-side Bluetooth module 20 and the vehicle-side Bluetooth module 10 establish a Bluetooth connection, a two-way authentication mechanism will be implemented to ensure the legitimate identities of the vehicle-side and station-side devices and prevent unauthorized devices from accessing the network.

[0077] This embodiment provides a specific process for two-way authentication: the station-side Bluetooth module 20 obtains the temporary key (TK) issued by the station control unit; the station-side Bluetooth module 20 generates a first random number (LP_RAND_I), and the vehicle-side Bluetooth module 10 generates a second random number (LP_RAND_R); confirmation values ​​(LP_CONFIRM_I and LP_CONFIRM_R) are generated based on the temporary key, the first random number, and the second random number, and exchanged for verification to confirm the legitimacy of both parties' identities.

[0078] Specifically, this embodiment prioritizes the traditional OOB pairing method, and its process can refer to the existing BLE traditional OOB pairing method. When the battery swapping vehicle enters the station, the station control unit obtains the temporary key (TK) for OOB pairing from the cloud platform through the capture camera. Then, the station control unit sends the temporary key (TK) to the station-side Bluetooth module 20 in the connection request. After the station-side Bluetooth module 20 connects to the vehicle-side Bluetooth module 10, the vehicle-side Bluetooth module 10 initiates a security request to the station-side Bluetooth module 20. Upon receiving the security request, the station-side Bluetooth module 20 initiates a pairing request to the vehicle-side Bluetooth module 10. Upon receiving the pairing request, the vehicle-side Bluetooth module 10 responds to the station-side Bluetooth module 20 with a pairing response. The two parties ultimately agree to use the OOB pairing method for pairing. Next, both parties generate random numbers and use the temporary key (TK) and their respective generated random numbers and other parameters to generate an acknowledgment value and send it to each other. Then, the two parties exchange random numbers and verify the correctness of the acknowledgment value. Through the above steps, the identity information of both parties is verified, achieving the purpose of preventing man-in-the-middle attacks. The temporary key (TK) used for OOB pairing can be up to 128 bits long, which cannot be brute-forced with current and foreseeable technology, effectively ensuring the security of the pairing process.

[0079] After successful two-way authentication, this embodiment also provides a Bluetooth communication link encryption method: the Bluetooth communication link is encrypted using the AES-CCM algorithm to obtain an encrypted transmission channel. After the station-side Bluetooth module 20 and the vehicle-side Bluetooth module 10 complete two-way authentication during the Bluetooth OOB pairing process, they generate a temporary session key (STK) based on the information exchanged during the pairing process to encrypt the communication link. The Bluetooth encrypted link uses the AES-CCM algorithm, which can ensure the confidentiality, integrity, and protection against replay attacks.

[0080] Step S7: Data transmission.

[0081] After successful two-way authentication and the establishment of an encrypted transmission channel, the vehicle-side Bluetooth module 10 transmits the collected vehicle battery swapping data to the station-side Bluetooth module 20 via Bluetooth. The station-side Bluetooth module 20 then transmits the received vehicle battery swapping data to the station control unit via Ethernet, and transmits the battery swapping control data from the station control unit to the vehicle-side Bluetooth module 10 via Bluetooth. The vehicle-side Bluetooth module 10 then transmits the battery swapping control data to the vehicle bus (CAN bus). Transmitting the vehicle battery swapping data and the battery swapping control data through the encrypted transmission channel effectively prevents data tampering or theft.

[0082] Step S8: Handling connection errors.

[0083] The above methods also include various connection exception handling mechanisms:

[0084] (1) Reconnection mechanism: The station-side Bluetooth module 20 will re-initiate the connection when the Bluetooth connection fails to be established. Specifically, during the process of the station-side Bluetooth module 20 initiating the Bluetooth connection and completing the pairing process with the vehicle-side Bluetooth module 10, some unexpected events may occur that cause the Bluetooth communication to fail to be established. In order not to affect the battery swapping experience, the Bluetooth connection steps will be re-executed.

[0085] (2) Reconnection mechanism: When Bluetooth is abnormally disconnected during data transmission, the station Bluetooth module 20 actively searches for the Bluetooth broadcast of the vehicle Bluetooth module 10 and re-establishes the Bluetooth connection.

[0086] (3) Disconnection mechanism after power swapping ends: When the station control unit determines that the power swapping is over, the station control unit will send a Bluetooth disconnection request frame to the station Bluetooth module 20 via Ethernet. After receiving the frame, the station Bluetooth module 20 will actively initiate Bluetooth disconnection to the vehicle Bluetooth module 10 according to the instructions of the station control unit. After the Bluetooth disconnection is completed, the vehicle Bluetooth module 10 will re-enter the broadcast and wait for the next Bluetooth connection.

[0087] Further improvements to security measures

[0088] This embodiment also provides a variety of security protection mechanisms to further enhance the security of the battery swapping communication process.

[0089] (a) Anti-pairing attack mechanism

[0090] This embodiment provides a method to prevent repeated pairing attacks: the vehicle-side Bluetooth module 10 records pairing failure events from the same station-side Bluetooth module 20; based on the number of pairing failure events, the waiting time for the next pairing attempt is gradually increased until a preset maximum waiting time is reached. For example, after each pairing failure of the same device, the waiting time is doubled until the maximum time of 640 seconds is reached. In this way, attackers cannot attempt to brute-force pairing by continuously connecting to the vehicle-side Bluetooth module 10.

[0091] This embodiment also provides a method for preventing denial-of-service attacks: the vehicle-side Bluetooth module 10 starts a pairing timer after the Bluetooth connection is established; if pairing is not completed within a preset time, the Bluetooth connection is forcibly disconnected. This method prevents attackers from connecting to the vehicle-side Bluetooth module 10 and then failing to pair for an extended period, thus preventing the Bluetooth link from being occupied and preventing normal communication with the station-side Bluetooth module 20.

[0092] (ii) Hardware security configuration

[0093] In this embodiment, the hardware security configuration of the vehicle-side Bluetooth module 10 includes:

[0094] First, during mass production, the JTAG connector is removed and the JTAG interface function is disabled, resulting in a non-debuggable hardware environment. Specifically, the JTAG function is enabled or disabled by writing specific data to the FSEC register using the chip's security features. When the device boots up, the pre-written SEC value from the FLASH memory is loaded into the FSEC register. Loading a specific SEC value into the FSEC register encrypts the chip, preventing JTAG access. Furthermore, the communication lines between the external FLASH memory and the MCU are routed through the middle layer of a multi-layer PCB, concealing the interface. Additionally, no silkscreen markings or labels are left on the motherboard, preventing the exposure of readable silkscreens.

[0095] Second, configure the UART communication interface with a two-way authentication mechanism and use the AES128 encryption algorithm for data encapsulation to obtain a secure debugging communication channel. Specifically, the MCU and PC communication process can be found in [reference needed]. Figure 5 The flowchart shown illustrates the MCU debug port authentication process, which mimics the UDS 27 service method to authenticate the legitimacy of production line PC tools. The MCU generates two sets of random numbers using internal hardware and sends them to the PC via obfuscation. The security algorithm uses AES128 encryption. The PC then encrypts the two sets of random numbers and the key using AES128 and sends them to the MCU. The MCU uses the same security algorithm to calculate and compare the results. Only after successful verification can subsequent interactive communication proceed.

[0096] (III) Safe Start

[0097] In this embodiment, the secure boot process of the vehicle-side Bluetooth module 10 includes: generating a root key when the device is first booted, calculating the password message authentication code (CMAC) value of the bootloader and application (app), and storing it in a protected Flash area; recalculating the password message authentication code value each time the device is booted, and comparing it with the stored password message authentication code value; if they match, the system boots normally; if they do not match, the system stops running to obtain a trusted boot chain.

[0098] Specifically, upon its first boot, the bootloader randomly generates a root key for secure device boot. This root key is obfuscated and stored in flash memory, with the flash protect register set to read-only. The CMAC values ​​for the bootloader and application are calculated using the root key and stored in flash. During subsequent secure boots, the length of the application area and its initial CMAC value are retrieved from a specific flash region. The obfuscated root key is read, and the CMAC values ​​for the bootloader and application are calculated using the same method. The calculated CMAC values ​​are then compared to the stored CMAC values. If the two values ​​are equal, the files are considered intact and untampered, and the normal boot process is executed. If the comparison fails, the MCU program has been tampered with, verification fails, and program execution stops. This process ensures secure boot, guaranteeing program integrity and preventing tampering.

[0099] (iv) Security Upgrade

[0100] This embodiment provides a secure upgrade method: the server uses an RSA4096 private key to digitally sign the application firmware, generating a signed upgrade firmware; the bootloader of the vehicle-side Bluetooth module 10 uses a pre-stored public key to verify the signature of the upgrade firmware; if the signature verification is successful, the firmware upgrade is executed; if the signature verification fails, the firmware is rolled back to the original firmware.

[0101] Specifically, the security upgrade uses RSA4096 for signature verification and SHA256 for hashing. The RSA private key is stored on the firmware signing server, and the RSA public key is stored in the bootloader of the vehicle's Bluetooth module 10. Figure 6 As shown, the MCU upgrade firmware signing process is as follows: the application firmware is uploaded to the server, the server uses sha256 to perform a hash operation on the application firmware to obtain a digest, the server then uses an RSA private key to encrypt the digest to obtain a signature, firmware information is added to the firmware signature in a certain format to generate a signature header with firmware information, and finally the signature header and the application firmware are integrated to generate a signed upgrade firmware.

[0102] like Figure 7As shown, the secure flashing process for the MCU system is as follows: The signature header and app firmware are written to the external flash memory. The MCU is then rebooted to enter the bootloader. The bootloader uses the SHA256 hash algorithm to calculate the digest of the app firmware stored in the external flash memory, extracts the signature information from the signature header in the external flash memory, verifies the integrity of the RSA public key stored in the bootloader using the CRC check, and verifies the firmware digest and signature using the RSA public key in the bootloader. If the verification is successful, the upgrade firmware in the external flash memory is copied to the internal flash memory, completing the upgrade process. If the verification fails, the original app firmware is run.

[0103] like Figure 8 As shown, the MCU upgrade anti-rollback mechanism works as follows: the software version is stored at an offset of n bytes from the start of the application. During the upgrade, the old and new software versions are retrieved from both the internal and external flash memory, and their major and minor version numbers are compared sequentially. If the new software version is greater than the old software version, the upgrade process continues; otherwise, the upgrade fails, and an error code indicating that the upgrade version is too old is recorded. This mechanism prevents the system from being maliciously refreshed to an older version.

[0104] (v) Key Security

[0105] In this embodiment, the Identity Resolution Key (IRK) of the vehicle-side Bluetooth module 10 is generated by the production testing computer during production testing and stored in the on-chip Flash after being encrypted with AES128. The temporary key (TK) used in the two-way identity authentication is sent from the cloud platform to the station control unit, and then from the station control unit to the station-side Bluetooth module 20 for a single pairing process.

[0106] Different protection methods are used for different types of keys: keys that do not need to be stored are temporarily generated; keys that need to be stored are stored in the software using an obfuscated segmentation method; and the private key in a key pair is stored on the server. Through these methods, the security of the key data is fully guaranteed, because the security of the key data determines the security of the entire system. In particular, communication and data storage all involve keys; once compromised, the system is no longer secure.

[0107] For ease of understanding, Figure 9 A schematic diagram of the system architecture related to information security in this application is shown.

[0108] Compared to existing technologies, the data transmission method between the battery swapping station and the vehicle provided in this application, through CAN-BLE-ETH communication, achieves secure and efficient battery swapping between vehicle-side information and the battery swapping station during the swapping process. The vehicle-side Bluetooth module uses a resolvable private address for dynamic broadcasting to prevent identity tracking; the station automatically acquires connection information through a camera and cloud platform to automate the battery swapping process; OOB pairing enables two-way authentication to prevent unauthorized device access; AES-CCM encryption ensures the confidentiality and integrity of data transmission; multiple reconnection and reconnection mechanisms ensure the stability and reliability of the battery swapping process; and a multi-layered security protection system, including hardware security, secure startup, secure upgrade, and key security, comprehensively enhances the security of the battery swapping communication process, ensures the authenticity of the battery swapping service recipients, and facilitates the management and maintenance of battery swapping stations.

[0109] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although this application has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some or all of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of this application, and they should all be covered within the scope of the claims and specification of this application.

Claims

1. A data transmission method between a battery swapping station and a vehicle, wherein the vehicle includes a vehicle-side Bluetooth module, and the battery swapping station includes a station-side Bluetooth module, a station control unit, and a snapshot camera, characterized in that, The method includes: The vehicle-mounted Bluetooth module collects vehicle battery swapping data via the vehicle bus. The vehicle-mounted Bluetooth module generates a resolvable private address and broadcasts via Bluetooth using the resolvable private address. It also regenerates the resolvable private address and updates the broadcast every preset time interval. The camera captures the identity information of the battery swapping vehicle; The station control unit obtains the connection information of the vehicle-side Bluetooth module from the cloud platform based on the identity information, and sends the connection information to the station-side Bluetooth module; The station-side Bluetooth module searches for the Bluetooth broadcast of the vehicle-side Bluetooth module based on the connection information, and establishes a Bluetooth connection with the vehicle-side Bluetooth module after finding it. After the Bluetooth connection is established, the station-side Bluetooth module and the vehicle-side Bluetooth module perform two-way identity authentication. After two-way authentication is successful, the vehicle-side Bluetooth module will transmit the collected vehicle battery swapping data to the station-side Bluetooth module via Bluetooth. The station-side Bluetooth module will then transmit the received vehicle battery swapping data to the station control unit via Ethernet, and transmit the battery swapping control data from the station control unit to the vehicle-side Bluetooth module via Bluetooth. The vehicle-side Bluetooth module will then transmit the battery swapping control data to the vehicle bus. Specifically, the station-side Bluetooth module re-initiates a connection when the Bluetooth connection fails to be established, actively searches for the Bluetooth broadcast of the vehicle-side Bluetooth module and re-establishes the Bluetooth connection when the Bluetooth connection is abnormally disconnected during data transmission, and actively disconnects the Bluetooth connection according to the instructions of the station control unit when the battery swapping ends.

2. The method according to claim 1, characterized in that, The method for generating the resolvable private address is as follows: Based on the unique identity resolution key stored in the vehicle-side Bluetooth module and a randomly generated random number, the resolvable private address is generated through a hash function. The random number is updated periodically according to the preset time.

3. The method according to claim 1, characterized in that, The two-way authentication process includes: The station-side Bluetooth module obtains the temporary key issued by the station control integrated machine; The station-side Bluetooth module generates a first random number, and the vehicle-side Bluetooth module generates a second random number. A confirmation value is generated based on the temporary key, the first random number, and the second random number, and then exchanged and verified to confirm the legitimacy of both parties' identities.

4. The method according to claim 1, characterized in that, After successful two-way authentication, the following is also included: The Bluetooth communication link is encrypted using the AES-CCM algorithm to obtain an encrypted transmission channel; The vehicle battery swapping data and the battery swapping control data are transmitted through the encrypted transmission channel.

5. The method according to claim 1, characterized in that, Also includes: The vehicle-side Bluetooth module records pairing failure events from the same station-side Bluetooth module; Based on the number of pairing failure events, the waiting time for the next pairing attempt is gradually increased until the preset maximum waiting time is reached.

6. The method according to claim 1, characterized in that, Also includes: The vehicle-mounted Bluetooth module starts a pairing timer after the Bluetooth connection is established. If pairing is not completed within the preset time, the Bluetooth connection will be forcibly disconnected.

7. The method according to claim 1, characterized in that, The hardware security configuration of the vehicle-mounted Bluetooth module includes: During the mass production phase, the JTAG connector is removed and the JTAG interface function is disabled, resulting in a non-debuggable hardware environment. Configure the UART communication interface with a two-way authentication mechanism and use the AES128 encryption algorithm for data encapsulation to obtain a secure debugging communication channel.

8. The method according to claim 1, characterized in that, The secure startup process of the vehicle-mounted Bluetooth module includes: A root key is generated when the device is first booted, the password message authentication code value for the bootloader and applications is calculated, and stored in a protected Flash area; Each time the system starts, the password message authentication code value is recalculated and compared with the stored password message authentication code value. If they match, the system starts normally; if they don't match, it stops running to obtain a reliable boot chain.

9. The method according to claim 1, characterized in that, Also includes: The server uses an RSA4096 private key to digitally sign the application firmware, generating a signed upgrade firmware. The bootloader of the vehicle-mounted Bluetooth module uses a pre-stored public key to verify the signature of the upgraded firmware. If the signature verification is successful, the firmware upgrade will be performed; if the signature verification fails, the firmware will be reverted to the original firmware.

10. The method according to claim 1, characterized in that, The identity resolution key of the vehicle-side Bluetooth module is generated by the production testing computer during production testing, and stored in the on-chip Flash after being encrypted with AES128. The temporary key used in the two-way authentication is sent from the cloud platform to the station control unit, and then from the station control unit to the station-side Bluetooth module for a single pairing process.

Images