Three-in-one safe binding system and method for electric vehicle

Abstract

The invention provides a three-in-one safe binding system and method for an electric vehicle. By means of the unique hardware identification and bidirectional binding between key components, the potential safety hazards of battery stealing and replacement, mixed use of chargers, illegal modification and the like in the using process of the electric vehicle can be solved.

Description

Technical Field

[0001] The present application relates to a trinity safety binding system and method for electric vehicles, belonging to the technical field of electric vehicle safety control. Background Art

[0002] Summarizing and analyzing the safety issues in the electric vehicle industry, the main problem points are as follows: 1. Illegal battery replacement Current situation overview: In the electric bicycle fires in Beijing in 2024, 53% were caused by non-certified batteries.

[0003] 60% of the stolen and robbed batteries evade supervision by replacing the TBOX.

[0004] Problem analysis: The quality, performance, and safety of non-certified batteries cannot be guaranteed, and it is extremely easy to cause safety accidents such as fires.

[0005] The act of replacing the TBOX to evade supervision seriously disrupts the safety management mechanism of electric bicycles, enabling the stolen and robbed batteries to continue to be circulated and used, increasing potential safety hazards.

[0006] 2. Risk of charger abuse Current situation overview: The probability of thermal runaway caused by overcharging with non-original chargers is increased by 8.2 times (data source: China Quality Certification Center).

[0007] Problem analysis: Non-original chargers may not have functions such as overcharge protection and over-temperature protection, which easily lead to overcharging of the battery, and then cause thermal runaway and fires.

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

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

[0010] Problem analysis: Single-point binding technology has limitations and is easily exploited by criminals for component tampering and illegal replacement.

[0011] The lack of a closed-loop verification mechanism between the charger and the entire vehicle system enables non-original chargers to be easily used, increasing potential safety hazards.

[0012] In summary, illegal battery replacement, the risk of charger abuse, and component tampering vulnerabilities are important safety issues faced by the current electric bicycle industry. To solve these problems, enterprises and all sectors of society need to work together to strengthen supervision, improve technical levels and safety awareness, and ensure the safety and reliability of electric bicycles. Summary of the Invention

[0013] This application provides an electric vehicle three-in-one security binding system and method to solve potential safety hazards such as battery theft and replacement, charger mixing, and illegal modification during the use of electric vehicles.

[0014] In a first aspect, an embodiment of this application provides an electric vehicle three-in-one security binding system, including: TBOX, serving as the control core of the electric vehicle; Battery management system, used to manage the charging and discharging process of the battery; Charger, used to charge 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 bidirectional binding protocol; Cloud server, used to store the binding relationship and send a dynamic verification policy to the TBOX; the dynamic verification policy is used to verify whether the TBOX, battery management system, and charger of the electric vehicle meet the pre-established binding relationship when using the electric vehicle. If the verification passes, normal use is allowed. If the verification fails, vehicle function restrictions are triggered; The multi-node bidirectional binding protocol includes: Challenge-response mechanism during the first binding; Algorithm for dynamically generating a joint key; among them, 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.

[0015] Based on the above system, optionally, the unique hardware identifier includes: IMEI+SN dual-factor ID written into the eSIM chip in the TBOX; 128-bit fuse ID pre-burned in the national cryptographic level-two security chip in the battery BMS; Globally unique ID generated by laser etching of the built-in ASIC chip in the charger.

[0016] Based on the above system, optionally, the dynamic verification policy includes: When 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 disposal logic in the abnormal state is triggered; Before charging, the charger applies for a dynamic token from the TBOX through the bus. If it is abnormal, the disposal logic in the abnormal state is triggered; Disposal logic under abnormal conditions, including torque limit, charging disconnection, and backup authentication.

[0017] Based on the above system, optionally, the dynamic token is specifically: Token = SM3(ID_CHG || current battery level || geographical location).

[0018] Based on the above system, optionally, it further includes an ID dynamic update mechanism for dynamically updating the unique hardware identifier of the battery. The algorithm is Dynamic_ID = SM4_CTR(original ID, key = SM3(cumulative cycle count || temperature)).

[0019] Based on the above system, optionally, the update trigger conditions of the ID dynamic update mechanism include time-driven and event-driven; The time-driven includes: triggering an update once per hour; The event-driven includes: triggering an update when the change value of the battery temperature is greater than the temperature threshold or the change value of the battery cumulative cycle count is greater than the cycle threshold.

[0020] Based on the above system, optionally, it further includes a dual-channel authentication system: The hardware layer transmits the basic ID through the Modbus-RTU protocol of the 485 bus; The software layer performs secondary verification on the cloud based on MQTT over TLS.

[0021] Based on the above system, optionally, it further includes an in-position detection enhancement mechanism: During the charging process, the heartbeat packet verification mechanism is executed regularly. If an abnormality occurs, charging is aborted; Hardwired signal detection is performed between the TBOX and the vehicle body controller. If the level is abnormal, it is determined as an illegal disassembly.

[0022] In a second aspect, the embodiments of the present application further provide a three-in-one security binding method for electric vehicles, which includes the following steps: Assign unique hardware identifiers to the TBOX, battery, and charger, and establish a three-party two-way dynamic authentication protocol; Through the pre-established multi-node two-way binding protocol, mutual authentication and binding of the TBOX, battery, and charger are performed; When using an electric vehicle, verify whether the TBOX, battery management system, and charger of the electric vehicle meet the pre-established binding relationship. If the verification passes, normal use is allowed. If the verification fails, vehicle function restrictions are triggered; The multi-node two-way binding protocol includes: The challenge-response mechanism during the first 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 TBOX, ID_BAT represents the unique hardware identifier of the battery, and ID_CHG represents the unique hardware identifier of the charger.

[0023] In the electric vehicle trinity safety binding system and method provided in this application, the electric vehicle safety management through hardware-level unique identification, multi-node two-way binding and cloud-based collaborative verification can achieve the following beneficial effects: 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.

[0024] 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.

[0025] 3. Curbing 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

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

[0027] Figure 1 A schematic diagram of the whole vehicle assembly of an electric vehicle provided in one embodiment of the present application; Figure 2 A system architecture diagram of an electric vehicle provided for one embodiment of the present application; Figure 3 A schematic diagram of the interaction process of various components of an electric vehicle provided in one embodiment of the present application; Figure 4 The processing logic under abnormal conditions provided by one embodiment of the present application; Figure 5 A basic ID encoding specification provided for an embodiment of the present application; Figure 6 A certificate system provided for an embodiment of the present application; Figure 7 An exception handling linkage mechanism provided for an embodiment of the present application; Figure 8The multi-level protection strategy provided by an embodiment of the present application; Figure 9 The signal encoding rule provided by an embodiment of the present application; Figure 10 The communication message structure (example) provided by an embodiment of the present application; Figure 11 The flowchart of the three-in-one security binding method for electric vehicles provided by an embodiment of the present application. Detailed implementation manners

[0028] To make the objectives, technical solutions and advantages of the present application clearer, the technical solutions in the embodiments of the present application will be clearly and completely described below in conjunction with the embodiments of the present application. Obviously, the described embodiments are some but not all of the embodiments of the present application. All other embodiments obtained by those of ordinary skill in the art based on the embodiments of the present application without creative efforts shall fall within the protection scope of the present application. Without conflict, the following embodiments and the features in the embodiments may be combined with each other.

[0029] This solution provides a three-in-one security binding system for electric vehicles. Through the unique hardware identifier and the two-way binding between key components, potential safety hazards such as battery theft and replacement, charger mixing, and illegal modification during the use of electric vehicles can be solved. The following provides a non-limiting description of the specific implementation solutions through embodiments or examples.

[0030] Refer to Figures 1 - 3 , Figure 1 The overall vehicle assembly diagram of the electric vehicle provided by an embodiment of the present application, Figure 2 The system architecture diagram of the electric vehicle provided by an embodiment of the present application, Figure 3 The interaction process diagram of each component of the electric vehicle provided by an embodiment of the present application. As Figures 1 - 3 shown, a three-in-one security binding system for electric vehicles provided by this embodiment includes: TBOX, that is, the intelligent central control of the electric vehicle, which serves as the control core of the electric vehicle and is responsible for controlling each component of the electric vehicle and communicating with external devices; Battery Management System (BMS), used to manage the charging and discharging process of the battery; Charger, used to charge the battery; Among them, TBOX, the battery management system, and the charger all contain unique hardware identifiers and are mutually authenticated and bound through a pre-established multi-node two-way binding protocol; 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-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 whole vehicle is triggered.

[0031] Specifically, the electric vehicle three-in-one safety binding system provided in this embodiment adopts a three-in-one binding architecture: 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 car and the computer are interconnected, mutually recognized, and coordinated.

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

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

[0034] The electric vehicle trinity safety binding system provided in this embodiment has the following technical features: 1. Hardware-level unique identification: The system can achieve one-to-one identification by assigning unique hardware identification (such as QR code, RFID tag, etc.) to electric vehicles and their key components (batteries, chargers), ensuring the uniqueness and traceability of electric vehicles and their components. These hardware identifications can be used as the "identity cards" of electric vehicles and their components, facilitating registration, verification and management in the cloud.

[0035] 2. Multi-node two-way binding: The system implements two-way binding between multiple nodes such as electric vehicles, batteries, and chargers. This means that each battery can only be paired with its matching electric vehicle and charger, and vice versa. This binding mechanism effectively prevents the problem of battery theft and mixed use of chargers, because unauthorized batteries or chargers will not be able to be paired with electric vehicles normally.

[0036] 3. Cloud-based collaborative verification: The system uses 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 based on the stored hardware identification and binding relationship to ensure that only legal pairings are allowed to be used. This mechanism further enhances the security and reliability of the system.

[0037] In some embodiments, the multi-node bidirectional binding protocol includes: 1. Challenge-response mechanism during the first binding; 2. Algorithm for dynamically generating combined keys; wherein, the combined keys include 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.

[0038] That is, the combined key K1 is calculated through the SM3 national cryptography algorithm based on the unique hardware identifier of the TBOX, the unique hardware identifier of the battery, and the timestamp. Similarly, the combined key K2 is calculated through the SM3 national cryptography algorithm based on the unique hardware identifier of the TBOX, the unique hardware identifier of the charger, and the timestamp.

[0039] Among them, the first binding process based on the challenge - response mechanism is as follows: Step 1: The TBOX sends a challenge code to the battery BMS, and the battery BMS signs and returns it using the unique hardware identifier (128 - bit fuse ID). Step 2: After the TBOX verifies the signature, it generates the combined key K1 = SM3(ID_TBOX||ID_BAT||timestamp). Step 3: The charger and the TBOX execute the same process to generate the combined key K2. Step 4: The cloud server records the triple binding relationship (based on the combined key K1 and the combined key K2) and issues a dynamic verification policy to the TBOX.

[0040] Furthermore, the unique hardware identifier includes: The IMEI + SN dual - factor ID (compliant with the YD / T 3627 - 2025 standard) written into the eSIM chip in the TBOX; The 128 - bit fuse ID pre - burned into the national cryptography level - two security chip in the battery BMS; and it supports SM4 dynamic key derivation; The globally unique ID (compliant with the ISO / IEC 29167 - 13 standard) laser - etched on the built - in ASIC chip of the charger.

[0041] Through the above - mentioned unique hardware identifier, the uniqueness and traceability of each key component of the electric vehicle can be ensured.

[0042] In some embodiments, the dynamic verification policy includes: 1. When the ACC (key - door switch) 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 (e.g., 5 seconds), the disposal logic in the abnormal state is triggered. 2. Before charging, the charger applies for a dynamic token from the TBOX via the bus. If an exception occurs, the disposal logic in the abnormal state is triggered. Among them, the dynamic token can be Token = SM3(ID_CHG || current battery level || geographical location); that is, the dynamic token can be calculated based on the unique hardware identifier of the charger, the current battery level, and the geographical location where it is located. 3. When the communication between the TBOX and the cloud server is interrupted or times out, the disposal logic in the abnormal state is triggered.

[0043] Among them, as Figure 4 shown, the disposal logic in the abnormal state includes torque limitation, charging disconnection, and alternative authentication.

[0044] Through the above abnormal state handling mechanism, potential safety hazards such as battery theft and replacement, charger mixing, and illegal modification during the use of electric vehicles can be effectively solved.

[0045] In some embodiments, in order to further improve safety, enhance the anti-attack ability, and prevent the unique hardware identifiers of each component from being cracked or illegally obtained. An ID dynamic update mechanism can also be set up, which is used to dynamically update the unique hardware identifier of the battery. The algorithm is Dynamic_ID = SM4_CTR(original ID, key K3 = SM3(cumulative cycle count || temperature)).

[0046] Among them, Dynamic_ID represents the unique hardware identifier (ID) of the battery after dynamic update, which is calculated based on the original ID and the combined key K3 through the SM4_CTR encryption algorithm. The combined key K3 is calculated based on the cumulative cycle count and temperature of the battery.

[0047] In some embodiments, the update trigger conditions of the ID dynamic update mechanism include time-driven and event-driven; Time-driven includes: triggering an update once per hour; Event-driven includes: triggering an update when the change value of the battery temperature is greater than the temperature threshold or the change value of the cumulative cycle count of the battery is greater than the cycle count threshold.

[0048] The anti-attack technical principle and design idea are as follows: 1. Dynamic ID generation mathematical model Based on the algorithm framework proposed by the user, Dynamic_ID = SM4_CTR(original ID, key = SM3(cumulative cycle count || temperature)), its mathematical essence is: Let the original ID be I, the cumulative cycle count be N, and the temperature be T, then: Key K3 = Hash(N || T) Dynamic ID = Encrypt_CTR(I, K) Among them, the SM3 hash: generates a 256-bit collision-resistant key, ensuring that a slight change in the input leads to a huge change in the output (avalanche effect).

[0049] SM4-CTR encryption: adopts the counter mode of the block cipher to achieve the streaming confusion of the original ID.

[0050] 2. Anti-attack design dimensions Time dimension: Force the ID to be updated every hour (8640 times / year), exceeding the time window of conventional attacks (statistics show that more than 99% of physical attacks take more than 2 hours), better ensuring security.

[0051] Environmental dimension: Incorporate the temperature variable (sampling accuracy ±0.5°C), and the same battery generates different IDs under different climate conditions.

[0052] Lifetime dimension: The cumulative number of cycles is used as an input parameter, so that the ID evolves dynamically during the battery aging process.

[0053] 1. Key generation engine # Pseudocode example (based on the national cryptography algorithm library) def generate_dynamic_key(orig_id, cycle_count, temperature): # Data preprocessing entropy_source = struct.pack('>I',cycle_count) + struct.pack('>f',temperature) # Generate key using SM3 hash key = sm3_hash(entropy_source).digest()[:16] # Take the first 128 bits as the SM4 key # SM4-CTR encryption cipher = SM4.new(key,SM4.MODE_CTR,counter=bytes_to_long(os.urandom(16))) dynamic_id = cipher.encrypt(orig_id) return dynamic_id The key parameters among them include: Sampling interval of the number of cycles: Update the count every time 1% of the charge-discharge cycle is completed.

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

[0055] The triggering conditions for dynamic updates in the ID dynamic update mechanism include time-driven and event-driven.

[0056] Time-driven includes: triggering an update once per hour. Automatic update at the whole hour (with a random offset of ±5 minutes to prevent prediction).

[0057] Event-driven includes: when the change value of the battery temperature is greater than the temperature threshold (e.g., ΔT≥5°C) or the change value of the cumulative battery charge and discharge cycles is greater than the cycle threshold (e.g., 3 times), force a trigger for an update (even if the time since the last update has not reached 1 hour).

[0058] 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.

[0059] In addition, in some embodiments, it further includes a dual-channel authentication system: Hardware layer: Transmit the basic ID through the Modbus-RTU protocol of the 485 bus; Software layer: Secondary verification in the cloud based on MQTT over TLS to prevent man-in-the-middle attacks.

[0060] The technical description of the dual-channel authentication system is as follows: I. Technical architecture design principle The dual-channel authentication builds a depth defense system through the coordinated action of physical layer identity verification and application layer encryption verification. Its core logic lies in: 1. Hierarchical defense: The hardware layer realizes the preliminary screening of device identities, and the software layer completes the deep encryption authentication, forming an effect of doubling the cost of attack breakthrough.

[0061] 2. Protocol complementarity: Modbus-RTU ensures real-time performance, and MQTT over TLS strengthens security, taking into account the requirements of industrial control and Internet communication.

[0062] 3. Attack surface cutting: Isolate the physical bus and the network channel to block the spread of single-point attack paths.

[0063] II. Implementation details of hardware layer authentication 1. Enhanced design of the Modbus-RTU protocol The basic ID coding specification is as Figure 5 shown, including information such as fields, lengths, and coding rules.

[0064] Among them, anti-interference mechanisms are adopted for data transmission: Adopt RS-485 differential signals (voltage range of ±2V~±6V), and load a 120Ω impedance matching resistor at the bus terminal.

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

[0066] 2. Security Enhancements Dynamic address mapping: When the device is powered on, a temporary communication address (0x01~0xF7) is assigned through a broadcast instruction to avoid the risk of fixed address exposure.

[0067] Physical layer fingerprint recognition: Analyze the signal rise time (typical value 10ns~100ns) and waveform characteristics to identify illegal access devices.

[0068] 3. Software Layer Authentication Implementation Solution 1. MQTT over TLS protocol stack optimization The certificate system is designed as Figure 6 As shown, it includes information such as certificate type, issuing authority, key length and update cycle.

[0069] Handshake process enhancement: sequenceDiagram Device->>Cloud: ClientHello (including device SN extension field) Cloud-->>Device: ServerHello (OCSP stapling required) Device->>OCSP: Certificate Status Query (via HTTP / 2) OCSP-->>Device: Valid Response (Signature Timestamp) Device->>Cloud: Finished (with heartbeat binding parameters) 2. Anti-man-in-the-middle attack technology 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 extended field of the device certificate.

[0070] 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 forward secrecy of up to 128 bits.

[0071] Quantum security enhancement: Preset X25519_KYBER_LEVEL3 mixed mode in TLS 1.3 to resist quantum computing attacks.

[0072] 4. Dual-channel collaborative working mechanism 1. Certification process sequence Phase 1: Hardware-level certification 1.1 The host sends a Modbus command: 01 03 00 00 00 01 84 0F 1.2 The slave returns the basic ID: 01 03 02 48 57 7B 3A Phase 2: Software layer authentication 2.1 The device sends a CONNECT message via MQTT, and the payload contains the Modbus ID hash value 2.2 The cloud compares the hash chain to verify the correlation between the hardware layer ID and the digital certificate Phase 3: Dynamic policy execution 3.1 After successful authentication, the device-specific Topic is issued: / devices / {SN} / command 3.2 Enable message level QoS 2 (exactly one transmission) and enable the monitoring of the Last Will message 2. Abnormal handling linkage The abnormal handling linkage mechanism is as Figure 7 shown, including information such as attack types, hardware layer responses, and software layer responses.

[0073] In addition, in some embodiments, it also includes an in-position detection enhancement mechanism: During the charging process, the heartbeat packet verification mechanism is executed regularly. If an abnormality occurs, the charging is aborted; for example, the charger sends a "heartbeat packet" to the TBOX every 30 seconds. If it is lost continuously for 3 times, the charging is aborted.

[0074] Hardwired signal detection (12V level detection) is performed between the TBOX and the vehicle body controller (VCU). If the level is abnormal, it is determined as illegal disassembly.

[0075] In addition, the specific implementation details of the software and hardware are as follows: (I) Hardware implementation details TBOX security module: Main control chip: Huawei MH5000-31 module (supporting 4G Cat.1 + Beidou positioning); Secure storage: Equipped with Fudan Microelectronics FM1280 security chip to store the root key; Interface design: RS-485 isolation interface (ADM2587E chip, withstand voltage 2500V).

[0076] Battery BMS encryption design: Dynamic key generator: Updates the key once per charge and discharge cycle, algorithm flow: Input: Original ID, cycle number N, current temperature T Process: K_new = SM4(SM3(N || T) XOR K_old) Output: 256-bit session key Charger security authentication: Hardware latching design: When ID mismatch is detected, trigger the one-way fuse (PTC resettable fuse) to disconnect the main circuit.

[0077] In-place detection enhancement scheme technology: I. Charging process verification: Dynamic heartbeat monitoring and intelligent fusing 1. Heartbeat protocol design Communication parameters: 1. Period: Fixed interval of 30 seconds (±500ms random jitter for anti-prediction) 2. Message format: Includes charger ID, current output voltage, temperature, and SM3 hash signature 3. Payload example: {ID:0xA1B2, Vout:54.3V, Temp:35℃, Sig:89c3d7...} Abnormality determination logic: graph LR A[Heartbeat lost once] --> B[Record abnormal log] B --> C{Continuous loss 3 times?} C -->|Yes| D[Send charging abort instruction] C -->|No| E[Reset counter] D --> F[Trigger fuse fusing] 2. Safety abort mechanism Hardware fuse: Use TE Connectivity's 219 series resettable fuse, response time ≤ 20ms.

[0078] Multi-level protection strategy as Figure 8 shown, including trigger conditions, handling measures, and recovery conditions, etc.

[0079] II. Hardware in-place signal detection: Multi-dimensional physical verification 1. Hardwired signal topology design 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.

[0080] Signal encoding rules as Figure 9 shown, including level status, logical meaning, and abnormal scenario mapping, etc.

[0081] 2. Joint Verification Strategy Three-factor Cross-verification: 1. Duration of Level: The normal signal needs to be maintained for ≥500ms 2. Ripple Characteristic: The detected signal fluctuation amplitude ≤100mVpp 3. Timing Feature: Synchronized with the 485 bus status (error ±10ms) Anti-spoofing Design: Inject a 1kHz sine wave modulation signal (amplitude 50mV) to detect the loop impedance characteristic Dynamic Impedance Matching Formula: Z_expected = (R_source + R_load) || C_parasitic If |Z_measured - Z_expected|>10% → Determine tampering (2) Software Protocol Stack Design The communication message structure (example) is as Figure 10 shown, including fields, lengths, and corresponding description information.

[0082] Cloud Interaction Logic: Data Upload Frequency: Report every 5 minutes in the normal state and report in real time in the abnormal state; Cloud Strategy Example: If a charger is bound to more than 3 different vehicles within 24 hours, it is marked as a high-risk device.

[0083] In addition, referring to Figure 11 , this embodiment of the present application also provides a three-in-one safety binding method for electric vehicles, which includes the following steps: S101: Assign unique hardware identifiers to the TBOX, battery, and charger, and establish a three-party two-way dynamic authentication protocol; S102: Through the pre-established multi-node two-way binding protocol, perform mutual authentication and binding of the TBOX, battery, and charger; S103: When using an electric vehicle, verify whether the TBOX, battery management system, and charger of the electric vehicle meet the pre-established binding relationship. If the verification passes, normal use is allowed. If the verification fails, the vehicle function is restricted.

[0084] The specific implementation methods of the above steps can refer to the previous description and will not be elaborated here.

[0085] Based on the above solution, through the unique hardware identifier and the two-way binding between key components, potential safety hazards such as battery theft, charger mixing, and illegal modification during the use of electric vehicles can be solved. Specifically as follows: 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.

[0086] 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.

[0087] 3. Curbing 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.

[0088] 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.

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

[0090] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code that includes 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 not be performed in 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 belong.

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

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

[0093] In addition, in each embodiment of the present invention, each functional unit may be integrated into a processing module, may exist physically alone for each unit, or two or more units may be integrated into one module. The above integrated module may be implemented in the form of hardware or in the form of a software functional module. When the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium. The above-mentioned storage medium may be a read-only memory, a magnetic disk or an optical disc, etc.

[0094] In the description of this specification, the descriptions with reference to the terms "one embodiment", "some embodiments", "example", "specific example" or "some examples", etc. mean that the specific features, structures, materials or characteristics described in connection with the embodiment or example are included in at least one embodiment or example of the present invention. In this specification, the schematic representations of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner.

[0095] Although the embodiments of the present invention have been shown and described above, it can be understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those of ordinary skill in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention.

Claims

1. A three-in-one safety binding system for an electric vehicle, characterized in that, Including: TBOX, serving as the control core of the electric vehicle; Battery management system, used to manage the charging and discharging process of the battery; Charger, used to charge 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; Cloud server, used to store the binding relationship and send dynamic verification policies to the TBOX; The dynamic verification policy is used to verify whether the TBOX, battery management system, and charger of the electric vehicle meet the pre-established binding relationship when using the electric vehicle. If the verification passes, normal use is allowed. If the verification fails, vehicle function restrictions are triggered; The multi-node two-way binding protocol includes: Challenge-response mechanism during the first binding; Algorithm for dynamically generating a joint key; where 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 in the eSIM chip in the TBOX; 128-bit fuse ID pre-burned in the national cryptographic level 2 security chip in the battery BMS; Globally unique ID generated by laser etching of the built-in ASIC chip in the charger.

3. The system according to claim 1, characterized in that, The dynamic verification policy includes: When 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 disposal logic in the abnormal state is triggered; Before charging, the charger applies for a dynamic token to the TBOX through the bus. If abnormal, the disposal logic in the abnormal state is triggered; The disposal logic in the abnormal state includes torque limitation, charging disconnection, and alternative authentication.

4. The system according to claim 3, characterized in that, The dynamic token is specifically: Token = SM3(ID_CHG||current battery level||geographical location).

5. The system according to claim 1, characterized in that It also includes an ID dynamic update mechanism for dynamically updating the unique hardware identifier of the battery. The algorithm is Dynamic_ID = SM4_CTR(original ID, key = SM3(cumulative cycle count||temperature)).

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

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

8. The system according to claim 1, characterized in that, It also includes an in-position detection enhancement mechanism: During the charging process, the heartbeat packet verification mechanism is executed regularly. If abnormal, charging is aborted; Hardwire signal detection is performed between the TBOX and the body controller. If the level is abnormal, illegal disassembly is determined.

9. A three-in-one safety binding method for an electric vehicle, characterized in that, Including the following steps: Assign unique hardware identifiers to the TBOX, battery, and charger, and establish a three-party two-way dynamic authentication protocol; Through a pre-established multi-node two-way binding protocol, perform mutual authentication and binding of the TBOX, battery, and charger; When using an electric vehicle, verify whether the TBOX, battery management system, and charger of the electric vehicle meet the pre-established binding relationship. If the verification passes, normal use is allowed. If the verification fails, the vehicle function is restricted; The multi-node two-way binding protocol includes: A challenge-response mechanism for the first binding; An algorithm for dynamically generating a joint key; where 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