Electric vehicle trinity safety binding system and method

Abstract

This application provides a three-in-one security binding system and method for electric vehicles. Through unique hardware identification and two-way binding between key components, it can address safety risks such as battery theft, mixed charger use, and illegal modification during the use of electric vehicles.

Description

Technical Field

[0001] The present application relates to a three-in-one safety binding system and method for electric vehicles, and belongs to the field of electric vehicle safety control technology. Background Art

[0002] Summarizing and analyzing the safety issues in the electric vehicle industry, the following are the main issues:

[0003] 1. Illegal battery replacement

[0004] Current situation overview: In 2024, 53% of electric bicycle fires in Beijing were caused by non-certified batteries.

[0005] 60% of stolen batteries evade supervision by replacing TBOX.

[0006] Problem Analysis: The quality, performance and safety of non-certified batteries cannot be guaranteed, and they are very likely to cause safety accidents such as fire.

[0007] The act of replacing TBOX to evade supervision seriously undermines the safety management mechanism of electric bicycles, allowing stolen batteries to continue to circulate and use, increasing safety risks.

[0008] 2. Risk of charger misuse

[0009] Current situation overview: The probability of thermal runaway caused by overcharging of non-original chargers increases by 8.2 times (data source: China Quality Certification Center).

[0010] Problem Analysis: Non-original chargers may not have overcharge protection, over-temperature protection and other functions, which can easily lead to overcharging of the battery, and then cause thermal runaway and fire.

[0011] Abuse of charger not only affects the service life and safety performance of the battery, but may also cause damage to the entire vehicle system.

[0012] 3. Component tampering vulnerability

[0013] Current situation overview: Existing technologies only support single-point binding (such as battery-TBOX), and cannot achieve closed-loop verification of the charger and the entire vehicle system.

[0014] Problem Analysis: Single-point binding technology has limitations and can be easily exploited by criminals to tamper with and illegally replace components.

[0015] The lack of a closed-loop verification mechanism between the charger and the vehicle system allows non-original chargers to be easily used, increasing safety risks.

[0016] In summary, illegal battery replacement, charger misuse risks, and component tampering vulnerabilities are significant safety issues facing the e-bike industry. Addressing these issues requires joint efforts from businesses and society at large to strengthen oversight, enhance technical expertise, and improve safety awareness to ensure the safety and reliability of e-bikes. Summary of the Invention

[0017] The present application provides a three-in-one safety binding system and method for electric vehicles to address safety hazards such as battery theft, mixed use of chargers, and illegal modification during the use of electric vehicles.

[0018] In a first aspect, an embodiment of the present application provides a three-in-one safety binding system for electric vehicles, comprising:

[0019] TBOX, the control core of electric vehicles;

[0020] Battery management system, used to manage the battery charging and discharging process;

[0021] a charger for charging the battery;

[0022] The TBOX, battery management system and charger all contain unique hardware identifiers and are mutually authenticated and bound through a pre-established multi-node two-way binding protocol;

[0023] The cloud server is used to store the binding relationship and send a dynamic verification strategy to the TBOX. The dynamic verification strategy is used to verify whether the TBOX, battery management system and charger of the electric vehicle meet the pre-set binding relationship when the electric vehicle is used. If the verification is successful, normal use is allowed. If the verification fails, the function restriction of the entire vehicle is triggered.

[0024] The multi-node two-way binding protocol includes:

[0025] Challenge-response mechanism during initial binding;

[0026] An algorithm for dynamically generating a joint key; wherein the joint key includes K1=SM3(ID_TBOX||ID_BAT||timestamp) and K2=SM3(ID_TBOX||ID_CHG||timestamp); ID_TBOX represents the unique hardware identifier of the TBOX, ID_BAT represents the unique hardware identifier of the battery, and ID_CHG represents the unique hardware identifier of the charger.

[0027] Based on the above system, optionally, the unique hardware identifier includes:

[0028] IMEI+SN dual-factor ID written into the eSIM chip in the TBOX;

[0029] The 128-bit fuse ID pre-programmed in the national secret level 2 security chip in the battery BMS;

[0030] The charger has a built-in ASIC chip with a globally unique ID generated by laser etching.

[0031] Based on the above system, optionally, the dynamic verification strategy includes:

[0032] When the ACC is powered on, the TBOX sends a heartbeat packet to the battery management system for verification. If no response is received within the set time, the abnormal state handling logic is triggered;

[0033] Before charging, the charger applies for a dynamic token from TBOX through the bus. If there is an abnormality, the abnormal state handling logic is triggered;

[0034] Abnormal state handling logic, including torque limitation, charging disconnection and standby certification.

[0035] Based on the above system, optionally, the dynamic token is specifically:

[0036] Token=SM3(ID_CHG||current battery level||geographic location).

[0037] Based on the above system, optionally, an ID dynamic update mechanism is further included to dynamically update the unique hardware identification of the battery, and the algorithm is Dynamic_ID = SM4_CTR (original ID, key = SM3 (accumulated number of cycles || temperature)).

[0038] Based on the above system, optionally, the update triggering conditions of the ID dynamic update mechanism include time-driven and event-driven;

[0039] The time-driven method includes: triggering an update every hour;

[0040] The event drive includes: triggering an update when the battery temperature change value is greater than a temperature threshold or the battery cumulative cycle count change value is greater than a count threshold.

[0041] Based on the above system, a dual-channel authentication system may also be included optionally:

[0042] The hardware layer transmits the basic ID via the Modbus-RTU protocol of the 485 bus;

[0043] The software layer is based on MQTT over TLS cloud secondary verification.

[0044] Based on the above system, optionally, an in-situ detection enhancement mechanism is also included:

[0045] The heartbeat packet verification mechanism is executed regularly during charging. If there is any abnormality, charging will be terminated.

[0046] Hard-wire signal detection is performed between the TBOX and the vehicle body controller. If the level is abnormal, it is determined to be illegal disassembly.

[0047] In a second aspect, an embodiment of the present application further provides a three-in-one safety binding method for an electric vehicle, which comprises the following steps:

[0048] Assign unique hardware identifiers to the TBOX, battery, and charger, and establish a three-party two-way dynamic authentication protocol;

[0049] Mutual authentication and binding of TBOX, battery and charger is carried out through a pre-established multi-node two-way binding protocol;

[0050] When using an electric vehicle, verify whether the electric vehicle's TBOX, battery management system, and charger meet the pre-set binding relationship. If the verification passes, normal use is allowed. If the verification fails, the vehicle's function restrictions are triggered;

[0051] The multi-node two-way binding protocol includes:

[0052] Challenge-response mechanism during initial binding;

[0053] An algorithm for dynamically generating a joint key; wherein the joint key includes K1=SM3(ID_TBOX||ID_BAT||timestamp) and K2=SM3(ID_TBOX||ID_CHG||timestamp); ID_TBOX represents the unique hardware identifier of the TBOX, ID_BAT represents the unique hardware identifier of the battery, and ID_CHG represents the unique hardware identifier of the charger.

[0054] The electric vehicle trinity security binding system and method provided in this application can achieve the following beneficial effects through electric vehicle security management through hardware-level unique identification, multi-node two-way binding, and cloud-based collaborative verification:

[0055] 1. Effectively prevent battery theft and replacement: Through unique hardware identification and two-way binding, stolen batteries can be prevented from being put into use again, and accurate battery tracking can also be achieved.

[0056] 2. Prevent mixed use of chargers: Through unique hardware identification and two-way binding, it can ensure strict matching of chargers and electric vehicles, avoiding the use of non-original chargers.

[0057] 3. Curb illegal modifications: Through unique hardware identification and two-way binding, the status changes of electric vehicle components can be monitored, and modification behaviors can be discovered and prevented in a timely manner. BRIEF DESCRIPTION OF THE DRAWINGS

[0058] The accompanying drawings are incorporated into and constitute a part of the specification, illustrate embodiments consistent with the present application, and together with the description, serve to explain the principles of the present application. In addition, these drawings and the description are not intended to limit the scope of the concept of the present application in any way, but rather to illustrate the concept of the present application for those skilled in the art by reference to specific embodiments.

[0059] Figure 1 A schematic diagram of the assembly of an electric vehicle according to an embodiment of the present application;

[0060] Figure 2 A system architecture diagram of an electric vehicle provided in accordance with one embodiment of the present application;

[0061] Figure 3 A schematic diagram of the interaction flow of various components of an electric vehicle provided in one embodiment of the present application;

[0062] Figure 4 The handling logic under abnormal conditions provided by one embodiment of the present application;

[0063] Figure 5 This is a basic ID encoding specification provided for one embodiment of this application;

[0064] Figure 6 A certificate system provided for one embodiment of this application;

[0065] Figure 7 An exception handling linkage mechanism provided in one embodiment of the present application;

[0066] Figure 8 A multi-level protection strategy provided for one embodiment of the present application;

[0067] Figure 9 Signal encoding rules provided for one embodiment of the present application;

[0068] Figure 10 A communication message structure (example) provided for one embodiment of the present application;

[0069] Figure 11 A flowchart of a three-in-one safety binding method for an electric vehicle provided in one embodiment of the present application. DETAILED DESCRIPTION

[0070] To make the purpose, technical solutions and advantages of this application clearer, the technical solutions in the embodiments of this application will be clearly and completely described below in conjunction with the embodiments of this application. Obviously, the described embodiments are part of the embodiments of this application, not all of the embodiments. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative work are within the scope of protection of this application. In the absence of conflict, the following embodiments and features in the embodiments can be combined with each other.

[0071] This solution provides a three-in-one security binding system for electric vehicles. Through unique hardware identification and bidirectional binding between key components, it can address safety risks such as battery theft, charger misuse, and illegal modification during electric vehicle use. The following non-limiting examples illustrate the specific implementation scheme.

[0072] Reference Figure 1-Figure 3 , Figure 1 A schematic diagram of the assembly of an electric vehicle according to an embodiment of the present application is provided. Figure 2 This is a system architecture diagram of an electric vehicle provided in one embodiment of the present application. Figure 3 This is a schematic diagram of the interaction flow of various components of an electric vehicle provided in one embodiment of the present application. Figure 1-Figure 3 As shown, this embodiment provides a three-in-one safety binding system for electric vehicles, which includes:

[0073] TBOX, the intelligent central control unit of electric vehicles, is the control core of electric vehicles and is responsible for controlling various components of electric vehicles and communicating with external devices;

[0074] Battery Management System (BMS), used to manage the battery charging and discharging process;

[0075] a charger for charging the battery;

[0076] Among them, TBOX, battery management system and charger all contain unique hardware identification and are mutually authenticated and bound through a pre-established multi-node two-way binding protocol;

[0077] The cloud server is used to store the binding relationship and send the dynamic verification strategy to TBOX. The dynamic verification strategy is used to verify whether the TBOX, battery management system and charger of the electric vehicle meet the pre-set binding relationship when using the electric vehicle. If the verification is passed, normal use is allowed. If the verification fails, the function restriction of the entire vehicle is triggered.

[0078] Specifically, the electric vehicle three-in-one safety binding system provided in this embodiment adopts a three-in-one binding architecture:

[0079] Using a master-slave communication topology (such as Figure 2), with TBOX as the control core, a star network is established with the battery and charger through the 485 bus or similar methods to realize the three-in-one binding architecture, and the vehicle and the computer are interconnected, mutually recognized, and coordinated.

[0080] Data aggregation: TBOX integrates battery SOC, charger output parameters, and vehicle status, and uploads them to the cloud after unified encryption.

[0081] Policy execution: Control instructions (such as charging power limit) issued by the cloud are forwarded to each node through TBOX for execution.

[0082] The electric vehicle three-in-one safety binding system provided in this embodiment has the following technical features:

[0083] 1. Hardware-level unique identification: The system assigns unique hardware identifiers (such as QR codes and RFID tags) to electric vehicles and their key components (batteries and chargers), achieving a unique identifier for each item, ensuring the uniqueness and traceability of electric vehicles and their components. These hardware identifiers serve as the "identity cards" of electric vehicles and their components, facilitating registration, verification, and management in the cloud.

[0084] 2. Multi-node bidirectional binding: The system implements bidirectional binding between multiple nodes, including electric vehicles, batteries, and chargers. This means that each battery can only be paired with its corresponding electric vehicle and charger, and vice versa. This binding mechanism effectively prevents battery theft and mixed use of chargers, as unauthorized batteries or chargers will not be able to be properly paired with the electric vehicle.

[0085] 3. Cloud-based collaborative verification: The system utilizes cloud servers for real-time data synchronization and verification. Whenever an electric vehicle, battery, or charger is paired or used, the system sends a verification request to the cloud. The cloud server verifies the pairing based on stored hardware identifiers and binding relationships, ensuring only legitimate pairings are permitted. This mechanism further enhances system security and reliability.

[0086] In some embodiments, the multi-node two-way binding protocol includes:

[0087] 1. Challenge-response mechanism during the first binding;

[0088] 2. An algorithm for dynamically generating a joint key; the joint key includes K1=SM3(ID_TBOX||ID_BAT||timestamp) and K2=SM3(ID_TBOX||ID_CHG||timestamp); ID_TBOX represents the unique hardware identifier of the TBOX, ID_BAT represents the unique hardware identifier of the battery, and ID_CHG represents the unique hardware identifier of the charger.

[0089] That is, the joint key K1 is calculated based on the unique hardware identifier of the TBOX, the unique hardware identifier of the battery, and the timestamp using the SM3 national encryption algorithm. Similarly, the joint key K2 is calculated based on the unique hardware identifier of the TBOX, the unique hardware identifier of the charger, and the timestamp using the SM3 national encryption algorithm.

[0090] The first binding process based on the challenge-response mechanism is as follows:

[0091] Step 1: TBOX sends a challenge code to the battery management system (BMS). The BMS returns the code signed with a unique hardware identifier (128-bit fuse ID).

[0092] Step 2: After TBOX verifies the signature, it generates a joint key K1 = SM3 (ID_TBOX||ID_BAT||timestamp);

[0093] Step 3: The charger and TBOX execute the same process to generate the joint key K2;

[0094] Step 4: The cloud server (based on joint keys K1 and K2) records the triplet binding relationship and sends the dynamic verification policy to TBOX.

[0095] Furthermore, the unique hardware identifier includes:

[0096] IMEI+SN dual-factor ID written into the eSIM chip in the TBOX (compliant with YD / T 3627-2025 standard);

[0097] The 128-bit fuse ID pre-programmed with the national secret level 2 security chip in the battery BMS; and can support SM4 dynamic key derivation;

[0098] The charger's built-in ASIC chip has a globally unique ID generated by laser etching (compliant with ISO / IEC 29167-13 standards).

[0099] The unique hardware identification mentioned above can ensure the uniqueness and traceability of each key component of the electric vehicle.

[0100] In some embodiments, the dynamic verification strategy includes:

[0101] 1. When the ACC (key-operated door switch) is powered on, the TBOX sends a heartbeat packet to the battery management system for verification. If no response is received within a set time (e.g., 5 seconds), the abnormal state handling logic is triggered;

[0102] 2. Before charging, the charger requests a dynamic token from the TBOX via the bus. If an abnormality is detected, the abnormality handling logic is triggered. The dynamic token can be Token = SM3(ID_CHG||current battery level||geographic location). In other words, the dynamic token can be calculated based on the charger's unique hardware identifier, the battery's current battery level, and the location.

[0103] 3. When the communication between TBOX and the cloud server is interrupted or times out, the abnormal state handling logic is triggered.

[0104] Among them, Figure 4 As shown, the handling logic under abnormal conditions includes torque limitation, charging disconnection and backup authentication.

[0105] The above abnormal state processing mechanism can effectively solve the safety hazards such as battery theft, mixed use of chargers and illegal modification during the use of electric vehicles.

[0106] In some embodiments, to further enhance security and resistance to attacks, and prevent the cracking or illegal acquisition of each component's hardware unique identifier, a dynamic ID update mechanism can be configured to dynamically update the battery's unique hardware identifier. The algorithm is Dynamic_ID = SM4_CTR(Original ID, Key K3 = SM3(Accumulated Cycle Count || Temperature)).

[0107] Dynamic_ID represents the dynamically updated battery's hardware unique identifier (ID), which is calculated using the SM4_CTR encryption algorithm based on the original ID and the joint key K3. The joint key K3 is calculated based on the battery's cumulative cycle count and temperature.

[0108] In some embodiments, the update triggering conditions of the ID dynamic update mechanism include time-driven and event-driven;

[0109] Time-driven includes: triggering an update every hour;

[0110] Event driving includes: triggering an update when the battery temperature change value is greater than the temperature threshold or the battery cumulative cycle count change value is greater than the count threshold.

[0111] The anti-attack technology principles and design ideas are as follows:

[0112] 1. Dynamic ID Generation Mathematical Model

[0113] Based on the user-proposed algorithm framework Dynamic_ID = SM4_CTR (original ID, key = SM3 (cumulative number of cycles || temperature)), its mathematical essence is:

[0114] Assume the original ID is I, the cumulative number of cycles is N, and the temperature is T, then:

[0115] Key K3 = Hash(N || T)

[0116] Dynamic ID = Encrypt_CTR(I, K)

[0117] Among them, SM3 hash: generates a 256-bit collision-resistant key to ensure that slight changes in the input lead to huge changes in the output (avalanche effect).

[0118] SM4-CTR encryption: uses the counter mode of the block cipher to achieve streaming obfuscation of the original ID.

[0119] 2. Attack-resistant design dimensions

[0120] Time dimension: IDs are forced to be updated every hour (8,640 times per year), exceeding the time window of conventional attacks (statistics show that 99% of physical attacks take more than 2 hours), ensuring better security.

[0121] Environmental dimension: Integrates temperature variables (sampling accuracy ±0.5°C), allowing the same battery to generate different IDs under different climate conditions.

[0122] Lifespan dimension: The cumulative number of cycles is used as an input parameter to enable the ID to evolve dynamically as the battery ages.

[0123] 1. Key Generation Engine

[0124] # Pseudocode example (based on the national cryptographic algorithm library) def generate_dynamic_key(orig_id, cycle_count, temperature):

[0125] Data preprocessing

[0126] entropy_source = struct.pack('>I',cycle_count) + struct.pack('>f',temperature)

[0127] # SM3 hash key generation

[0128] key = sm3_hash(entropy_source).digest()[:16]

[0129] # Take the first 128 bits as the SM4 key

[0130] # SM4-CTR encryption

[0131] cipher = SM4.new(key,SM4.MODE_CTR,counter=bytes_to_long(os.urandom(16)))

[0132] dynamic_id = cipher.encrypt(orig_id)

[0133] return dynamic_id

[0134] The key parameters include:

[0135] Cycle number sampling interval: The count is updated every time 1% of the charge and discharge cycles are completed.

[0136] Temperature sampling frequency: 10Hz real-time monitoring (to prevent short-term temperature deception).

[0137] The triggering conditions for the dynamic update of the ID dynamic update mechanism include time-driven and event-driven.

[0138] Time-driven features include: triggering an update every hour, and automatically updating at the top of the hour (with a ±5-minute random offset to prevent prediction).

[0139] Event-driven includes: when the battery temperature change value is greater than the temperature threshold (for example, ΔT ≥ 5°C) or the battery cumulative cycle change value is greater than the number threshold (for example, 3 times), an update is forced to be triggered (even if the time since the last update is less than 1 hour).

[0140] In addition, to ensure update fault tolerance, the previous valid ID can be retained for 30 seconds to avoid system misjudgment caused by communication interruption.

[0141] In addition, some embodiments also include a dual-channel authentication system:

[0142] Hardware layer: transmit basic ID via Modbus-RTU protocol of 485 bus;

[0143] Software layer: Secondary cloud authentication based on MQTT over TLS to prevent man-in-the-middle attacks.

[0144] The technical description of the dual-channel authentication system is as follows:

[0145] 1. Technical Architecture Design Principles

[0146] Dual-channel authentication builds a defense-in-depth system through the synergy of physical-layer identity verification and application-layer encryption verification. Its core logic lies in:

[0147] 1. Layered defense: The hardware layer performs preliminary device identity screening, and the software layer completes deep encryption authentication, creating a cost-multiplying effect for attack breakthroughs.

[0148] 2. Protocol complementarity: Modbus-RTU ensures real-time performance, while MQTT over TLS enhances security, balancing the needs of industrial control and Internet communications.

[0149] 3. Attack surface segmentation: Isolate the physical bus from the network channel to block the spread of single-point attack paths.

[0150] 2. Hardware layer authentication implementation details

[0151] 1. Modbus-RTU protocol enhancement design

[0152] Basic ID encoding specifications are as follows Figure 5 As shown, it includes information such as fields, length and encoding rules.

[0153] Among them, data transmission adopts anti-interference mechanism:

[0154] RS-485 differential signals (±2V to ±6V voltage range) are used, and the bus terminals are loaded with 120Ω impedance matching resistors.

[0155] The data frame interval is forced to be ≥ 3.5 character times (about 4ms at a baud rate of 9600 bps) to prevent frame adhesion.

[0156] 2. Security Enhancements

[0157] Dynamic address mapping: When the device is powered on, a temporary communication address (0x01 to 0xF7) is assigned through a broadcast command to avoid the risk of fixed address exposure.

[0158] Physical layer fingerprint recognition: Analyzes signal rise time (typical value 10ns~100ns) and waveform characteristics to identify illegally connected devices.

[0159] 3. Software Layer Authentication Implementation Solution

[0160] 1. MQTT over TLS protocol stack optimization

[0161] Certificate system design Figure 6 As shown, it includes information such as certificate type, issuing authority, key length and update cycle.

[0162] Handshake process enhancement:

[0163] sequenceDiagram

[0164] Device->Cloud: ClientHello (including device SN extension field)

[0165] Cloud-->>Device: ServerHello (OCSP stapling required)

[0166] Device->>OCSP: Certificate Status Query (via HTTP / 2)

[0167] OCSP-->>Device: Valid Response (Signature Timestamp)

[0168] Device->Cloud: Finished (with heartbeat binding parameters)

[0169] 2. Anti-man-in-the-middle attack technology

[0170] Two-way certificate verification: The device verifies that the DN field of the cloud certificate contains CN=iot-*.company.com, and the cloud verifies the production line number in the extension field of the device certificate.

[0171] Session key binding: A temporary key pair is generated for each handshake, and ECDHE key exchange is implemented using the NIST P-256 curve with 128-bit forward secrecy.

[0172] Quantum security enhancements: The X25519_KYBER_LEVEL3 mixed mode is pre-installed in TLS 1.3 to resist quantum computing attacks.

[0173] 4. Dual-channel collaborative working mechanism

[0174] 1. Authentication process sequence

[0175] Phase 1: Hardware-layer certification

[0176] 1.1 The host sends a Modbus command: 01 03 00 00 00 01 84 0F

[0177] 1.2 Slave returns basic ID: 01 03 02 48 57 7B 3A

[0178] Phase 2: Software Layer Certification

[0179] 2.1 The device sends a CONNECT message via MQTT, with the payload containing the Modbus ID hash value

[0180] 2.2 Compare the hash chain in the cloud to verify the association between the hardware layer ID and the digital certificate

[0181] Phase 3: Dynamic Strategy Execution

[0182] 3.1 After authentication is passed, the device-specific topic is issued: / devices / {SN} / command

[0183] 3.2 Enable message level QoS 2 (exactly once delivery) and enable Last Will monitoring

[0184] 2. Exception handling linkage

[0185] Abnormal handling linkage mechanism such as Figure 7 The displayed information includes attack type, hardware layer response, software layer response, etc.

[0186] In addition, some embodiments also include an in-situ detection enhancement mechanism:

[0187] During the charging process, the heartbeat packet verification mechanism is executed periodically. If an abnormality is detected, charging is terminated. For example, the charger sends a "heartbeat packet" to the TBOX every 30 seconds. If the heartbeat packet is lost three times in a row, charging is terminated.

[0188] A hard-wired signal detection (12V level detection) is performed between the TBOX and the vehicle body controller (VCU). If the level is abnormal, it is considered illegal disassembly.

[0189] In addition, the specific implementation details of software and hardware are as follows:

[0190] (1) Hardware implementation details

[0191] TBOX safety module:

[0192] Main control chip: Huawei MH5000-31 module (supports 4G Cat.1+ Beidou positioning);

[0193] Secure storage: Equipped with Fudan Microelectronics FM1280 security chip to store root keys;

[0194] Interface design: RS-485 isolation interface (ADM2587E chip, withstand voltage 2500V).

[0195] Battery BMS encryption design:

[0196] Dynamic key generator: updates the key every charge and discharge cycle. Algorithm flow:

[0197] Input: original ID, number of cycles N, current temperature T

[0198] Process: K_new = SM4(SM3(N || T) XOR K_old)

[0199] Output: 256-bit session key

[0200] Charger safety certification:

[0201] Hardware latch design: When an ID mismatch is detected, the one-way fuse (PTC resettable fuse) is triggered to disconnect the main circuit.

[0202] In-situ detection enhancement solution technology:

[0203] 1. Charging process verification: dynamic heartbeat monitoring and intelligent fuse

[0204] 1. Heartbeat protocol design

[0205] Communication parameters:

[0206] 1. Cycle: 30 seconds fixed interval (±500ms random jitter to prevent prediction)

[0207] 2. Message format: includes charger ID, current output voltage, temperature and SM3 hash signature

[0208] 3. Load example: {ID:0xA1B2, Vout:54.3V, Temp:35°C, Sig:89c3d7...}

[0209] Abnormal judgment logic:

[0210] graph LR

[0211] A[Heartbeat lost once] --> B[Record abnormality log]

[0212] B -->C{lost 3 times in a row?}

[0213] C --> |Yes| D[Send charging stop command]

[0214] C -->|No| E[Resume counter]

[0215] D -->F [trigger fuse blown]

[0216] 2. Safe Termination Mechanism

[0217] Hardware fuse: TE Connectivity's 219 series resettable fuse with a response time of ≤20ms.

[0218] Multi-level protection strategies such as Figure 8 As shown, it includes information such as triggering conditions, disposal measures and recovery conditions.

[0219] 2. Hardware In-Place Signal Detection: Multi-Dimensional Physical Verification

[0220] 1. Hard-wire signal topology design

[0221] Level detection circuit: Voltage range: 9-15V (compatible with 12V system ±25% fluctuation); Comparator chip: TITLV7031 (response time 1μs); Interference design: Add RC filtering (τ=10ms) to suppress transient pulses.

[0222] Signal encoding rules such as Figure 9As shown, it includes information such as level status, logical meaning and abnormal scenario mapping.

[0223] 2. Joint Verification Strategy

[0224] Three-factor cross validation:

[0225] 1. Level duration: Normal signal needs to be maintained ≥500ms

[0226] 2. Ripple characteristics: detection signal fluctuation amplitude ≤ 100mVpp

[0227] 3. Timing characteristics: Synchronous with 485 bus status (error ±10ms)

[0228] Anti-fraud design:

[0229] Inject a 1kHz sine wave modulation signal (amplitude 50mV) to detect the loop impedance characteristics

[0230] Dynamic impedance matching formula:

[0231] Z_expected = (R_source + R_load) || C_parasitic

[0232] If |Z_measured - Z_expected|>10% → determine tampering

[0233] (2) Software protocol stack design

[0234] Communication message structure (example) Figure 10 As shown, it includes fields, lengths, and corresponding description information.

[0235] Cloud interaction logic:

[0236] Data upload frequency: Normal status is reported every 5 minutes, and abnormal status is reported in real time;

[0237] Cloud policy example: If the same charger is bound to more than three different vehicles within 24 hours, it will be marked as a high-risk device.

[0238] In addition, refer to Figure 11 , the embodiment of the present application also provides a three-in-one safety binding method for electric vehicles, which includes the following steps:

[0239] S101: Assign unique hardware identifiers to the TBOX, battery, and charger, and establish a three-party two-way dynamic authentication protocol;

[0240] S102: Mutual authentication and binding of the TBOX, battery, and charger are performed through a pre-established multi-node two-way binding protocol;

[0241] S103: When using an electric vehicle, verify whether the electric vehicle's TBOX, battery management system, and charger meet the pre-set binding relationship. If the verification is successful, normal use is allowed. If the verification fails, the vehicle function restriction is triggered.

[0242] The specific implementation methods of the above steps can be referred to the previous description and will not be repeated here.

[0243] Based on the above solution, through unique hardware identification and two-way binding between key components, it is possible to solve the safety risks such as battery theft, mixed use of chargers, and illegal modification during the use of electric vehicles. The details are as follows:

[0244] 1. Effectively prevent battery theft and replacement: Through unique hardware identification and two-way binding, stolen batteries can be prevented from being put into use again, and accurate battery tracking can also be achieved.

[0245] 2. Prevent mixed use of chargers: Through unique hardware identification and two-way binding, it can ensure strict matching of chargers and electric vehicles, avoiding the use of non-original chargers.

[0246] 3. Curb illegal modifications: Through unique hardware identification and two-way binding, the status changes of electric vehicle components can be monitored, and modification behaviors can be discovered and prevented in a timely manner.

[0247] It can be understood that the same or similar parts of the above embodiments can be referenced to each other, and the contents not described in detail in some embodiments can refer to the same or similar contents in other embodiments.

[0248] It should be noted that, in the description of the present invention, the terms "first", "second", etc. are used for descriptive purposes only and should not be understood as indicating or implying relative importance. In addition, in the description of the present invention, unless otherwise specified, the meaning of "plurality" is at least two.

[0249] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code comprising one or more executable instructions for implementing the steps of a specific logical function or process, and the scope of the preferred embodiments of the present invention includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present invention pertain.

[0250] It should be understood that various parts of the present invention can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having a logic gate circuit for implementing a logic function on a data signal, an application-specific integrated circuit having a suitable combination of logic gate circuits, a programmable gate array (PGA), a field programmable gate array (FPGA), etc.

[0251] Those skilled in the art will understand that all or part of the steps carried out in the method for implementing the above-mentioned embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one of the steps of the method embodiment or a combination thereof.

[0252] Furthermore, the functional units in the various embodiments of the present invention may be integrated into a single processing module, each unit may exist physically separately, or two or more units may be integrated into a single module. The aforementioned integrated modules may be implemented in either hardware or software functional modules. If the integrated modules are implemented as software functional modules and sold or used as standalone products, they may also be stored in a computer-readable storage medium. The aforementioned storage medium may be a read-only memory, a magnetic disk, or an optical disk, etc.

[0253] Throughout this specification, references to terms such as "one embodiment," "some embodiments," "examples," "specific examples," or "some examples" indicate that the specific features, structures, materials, or characteristics described in conjunction with that embodiment or example are included in at least one embodiment or example of the present invention. In this specification, schematic representations of these terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in any one or more embodiments or examples.

[0254] Although the embodiments of the present invention have been shown and described above, it will be understood that the above embodiments are illustrative and are not to be construed as limitations on the present invention. A person skilled in the art may change, modify, replace and modify the above embodiments within the scope of the present invention.

Claims

1. A three-in-one safety binding system for electric vehicles, characterized in that: include: TBOX, as the control core of electric vehicles; Battery management system, used to manage the battery charging and discharging process; a charger for charging the battery; The TBOX, battery management system and charger all contain unique hardware identifiers and are mutually authenticated and bound through a pre-established multi-node two-way binding protocol; A cloud server, used to store the binding relationship and send a dynamic verification strategy to the TBOX; The dynamic verification strategy is used to verify whether the electric vehicle's TBOX, battery management system and charger meet the pre-set binding relationship when using the electric vehicle. If the verification is passed, normal use is allowed. If the verification fails, the vehicle function restriction is triggered; The dynamic verification strategy includes: when the ACC is powered on, the TBOX sends a heartbeat packet to the battery management system for verification. If no response is received within a set time, the abnormal state handling logic is triggered; before charging, the charger applies for a dynamic token from the TBOX through the bus. If an abnormality occurs, the abnormal state handling logic is triggered; the abnormal state handling logic includes torque limitation, charging disconnection and standby authentication; The multi-node two-way binding protocol includes: Challenge-response mechanism during initial binding; An algorithm for dynamically generating a joint key; wherein the joint key includes K1=SM3(ID_TBOX||ID_BAT||timestamp) and K2=SM3(ID_TBOX||ID_CHG||timestamp); ID_TBOX represents the unique hardware identifier of the TBOX, ID_BAT represents the unique hardware identifier of the battery, and ID_CHG represents the unique hardware identifier of the charger.

2. The system according to claim 1, wherein: The unique hardware identifier includes: IMEI+SN dual-factor ID written into the eSIM chip in the TBOX; The 128-bit fuse ID pre-programmed in the national secret level 2 security chip in the battery BMS; The charger has a globally unique ID generated by laser etching on the built-in ASIC chip.

3. The system according to claim 1, wherein: The dynamic token is specifically: Token=SM3(ID_CHG||current battery level||geographic location).

4. The system according to claim 1, wherein: It also includes an ID dynamic update mechanism for dynamically updating the unique hardware identification of the battery. The algorithm is Dynamic_ID = SM4_CTR (original ID, key = SM3 (accumulated number of cycles || temperature)).

5. The system according to claim 4, characterized in that The update triggering conditions of the ID dynamic update mechanism include time-driven and event-driven; The time-driven method includes: triggering an update every hour; The event-driven method includes triggering an update when a battery temperature change value is greater than a temperature threshold or a battery cumulative cycle count change value is greater than a count threshold.

6. The system according to claim 1, wherein: It also includes a dual-channel authentication system: The hardware layer transmits the basic ID via the Modbus-RTU protocol of the 485 bus; The software layer is based on MQTT over TLS cloud secondary verification.

7. The system according to claim 1, wherein: Also includes in-place detection reinforcement mechanism: The heartbeat packet verification mechanism is executed regularly during charging. If there is any abnormality, charging will be terminated. A hard-wired signal detection is performed between the TBOX and the vehicle body controller. If the level is abnormal, it is determined to be illegal disassembly.

8. A three-in-one safety binding method for electric vehicles, characterized in that: The following steps are involved: Assign unique hardware identifiers to the TBOX, battery, and charger, and establish a three-party two-way dynamic authentication protocol; Mutual authentication and binding of TBOX, battery and charger is carried out through a pre-established multi-node two-way binding protocol; When using an electric vehicle, verify whether the electric vehicle's TBOX, battery management system, and charger meet the pre-set binding relationship. If the verification passes, normal use is allowed. If the verification fails, the vehicle's functional restrictions are triggered. When verifying the electric vehicle's TBOX, a dynamic verification strategy is used. The dynamic verification strategy includes: when the ACC is powered on, the TBOX sends a heartbeat packet to the battery management system for verification. If no response is received within a set time, the abnormal state handling logic is triggered. Before charging, the charger applies for a dynamic token from the TBOX through the bus. If an abnormality occurs, the abnormal state handling logic is triggered. The abnormal state handling logic includes torque limitation, charging disconnection, and standby authentication. The multi-node two-way binding protocol includes: Challenge-response mechanism during initial binding; An algorithm for dynamically generating a joint key; wherein the joint key includes K1=SM3(ID_TBOX||ID_BAT||timestamp) and K2=SM3(ID_TBOX||ID_CHG||timestamp); ID_TBOX represents the unique hardware identifier of the TBOX, ID_BAT represents the unique hardware identifier of the battery, and ID_CHG represents the unique hardware identifier of the charger.

Images