Vehicle theft prevention system and vehicle theft prevention method

Abstract

A vehicle theft prevention system and method are provided. The vehicle theft prevention system includes a master node disposed on a vehicle and at least two groups of slave nodes in communication connection with the master node. Each group of slave nodes includes two or more slave nodes. The master node is configured to generate an unlock request after receiving an unlock signal from an external node of the vehicle via a keyless entry and start system of the vehicle. At least one slave node of at least one group of slave nodes is configured to generate a challenge message after receiving the unlock request from the master node, and perform an unlock security check after receiving a response message corresponding to the challenge message from the at least one master node; and in the event that the unlock security check passes, the at least one slave node performs the unlock security check with other slave nodes of the group as a new master node.

Description

Technical Field

[0001] This invention relates to a vehicle anti-theft system and a vehicle anti-theft method. Background Technology

[0002] Car thefts are frequent occurrences. Early methods to prevent vehicle theft included mechanical anti-theft measures, such as using various mechanical locks to lock the clutch, brakes, accelerator, or steering wheel. Later, electronic anti-theft measures were adopted, which involved cutting off the vehicle's ignition coil or fuel / electricity supply circuits. However, with car thieves employing increasingly sophisticated and varied methods, there is an urgent need to research new technologies for vehicle anti-theft. Summary of the Invention

[0003] Against this backdrop, embodiments of the present invention provide an in-vehicle anti-theft system and a vehicle anti-theft method, which can prevent the vehicle's engine or main power source and the vehicle's braking system from being illegally started. According to embodiments of the present invention, unlocking or locking at the vehicle's functional level can be implemented in software, thereby effectively preventing vehicle theft without increasing vehicle hardware costs.

[0004] According to one embodiment of the present invention, a vehicle anti-theft system is provided, comprising a master node disposed on the vehicle and at least two sets of slave nodes communicatively connected to the master node, each set of slave nodes comprising two or more slave nodes. The master node is configured to generate an unlock request. At least one slave node in at least one group of slave nodes is configured to: generate a challenge message after receiving an unlock request from a master node, and perform an unlock security check after the at least one master node receives a response message corresponding to the challenge message, wherein the challenge message includes the current state of the at least one slave node and a random number for the current unlock request, the response message includes encrypted information obtained by encrypting the random number, and the unlock security check includes: a check on the random number or the encrypted information; and if the unlock security check passes, the at least one slave node is designated as the new master node and the unlock security check is performed on the other slave nodes in the group of slave nodes; wherein if all unlock security checks related to the at least one group of slave nodes pass, the functionality of all slave nodes in the at least one group of slave nodes is unlocked; if at least one unlock security check related to the at least one group of slave nodes fails, the functionality of all slave nodes in the at least one group of slave nodes is disabled.

[0005] According to another aspect of the present invention, a vehicle anti-theft method is provided. The vehicle includes a master node and at least two sets of slave nodes communicatively connected to the master node, each set of slave nodes including two or more slave nodes. The method includes: a master node generating an unlock request; at least one slave node in at least one group of slave nodes generating a challenge message after receiving the unlock request from the master node, wherein the challenge message includes the current state of the at least one slave node and a random number for the current unlock request; after the at least one slave master node receives a response message corresponding to the challenge message, performing an unlock security check, wherein the response message includes encrypted information obtained by encrypting the random number, and the unlock security check includes: checking the random number or the encrypted information; and if the unlock security check passes, at the at least one slave node, the at least one slave node is designated as the new master node and the unlock security check is performed with the other slave nodes in the group of slave nodes; if all unlock security checks related to the at least one group of slave nodes pass, the functionality of all slave nodes in the at least one group of slave nodes is unlocked; and if at least one unlock security check related to the at least one group of slave nodes fails, the functionality of all slave nodes in the at least one group of slave nodes is disabled.

[0006] According to another aspect of the present invention, a vehicle control unit is provided, including one or more processors configured to perform the vehicle anti-theft method as described above.

[0007] According to another aspect of the present invention, a machine-readable storage medium is provided that stores executable instructions, which, when executed, cause one or more processors to perform the vehicle anti-theft method as described above.

[0008] The foregoing provides a summary of the main aspects of the invention in order to provide a basic understanding of these aspects and serves as an introduction to the detailed description that follows. Attached Figure Description

[0009] The technical solution of the present invention will become clearer from the following detailed description taken in conjunction with the accompanying drawings. It is to be understood that these drawings are for illustrative purposes only and are not intended to limit the scope of protection of the present invention.

[0010] Figure 1 This is a schematic block diagram of a vehicle anti-theft system according to one embodiment of the present invention.

[0011] Figure 2A and Figure 2B It shows Figure 1 Some embodiments of the first group of slave nodes in the vehicle anti-theft system.

[0012] Figure 3 It shows Figure 1 Another way to implement vehicle anti-theft systems.

[0013] Figures 4A-4C It shows Figure 1 Some examples of master-slave node deployment in vehicle anti-theft systems.

[0014] Figure 5 This is a flowchart of a vehicle anti-theft method according to an embodiment of the present invention.

[0015] Figure 6 It is used for illustration Figure 5 A schematic diagram illustrating the principle of the Chinese method.

[0016] Figures 7A-7D The schematic illustrations depict chained verification, parallel verification, and hybrid verification according to embodiments of the present invention. Detailed Implementation

[0017] The specific embodiments of the present invention will now be described with reference to the accompanying drawings.

[0018] Figure 1 A vehicle anti-theft system 100 according to an embodiment of the present invention is shown. It is installed in a vehicle and is therefore an in-vehicle system. Figure 1 As shown, the vehicle anti-theft system 100 includes: a master node (N Master )10 and at least two groups of slave nodes, for example, the first group of slave nodes (N) Slave_11 and N Slave_12 )20 and the second group of slave nodes (N) Slave_21 and N Slave_22 30.

[0019] Master node 10 receives the unlock signal (S) from the vehicle's keyless entry and start (PEPS: Passive Entry Passive Start) system. unlock The unlock signal is the vehicle's external node (N). external The signal is sent wirelessly to PEPS, for example, by the vehicle user's mobile app or the vehicle user's key. After receiving the unlock signal, the master node 10 sends an unlock request to each group of slave nodes and performs an unlock security verification based on challenge and response messages with at least one slave node in each group.

[0020] If the verification based on challenge and response messages between the master node and a slave node passes, the handshake between the master node and the slave node is successful. If the verification based on challenge and response messages (i.e., unlock security verification) between the master node and a slave node fails, the handshake between the master node and the slave node is unsuccessful. Additionally, according to the present invention, the process includes designating a slave node as the new master node and performing unlock security verification based on challenge and response messages on the other slave nodes in the group. If all unlock security verifications pass, each group of slave nodes can unlock, i.e., the function of each group of slave nodes can be triggered (activated). In this case, the vehicle can start. If at least one unlock security verification fails, none of the groups of slave nodes can unlock, i.e., the function of each group of slave nodes cannot be triggered (activated). In this case, the vehicle cannot start.

[0021] A failure to pass the unlock security check indicates a risk of vehicle theft. This could be caused by a thief monitoring the vehicle's bus and issuing a "fake unlock request." The unlock security check according to embodiments of the present invention can effectively detect such risks and, by disabling unlocking from slave nodes, prevents the slave nodes from functioning, thereby achieving vehicle anti-theft at the functional level.

[0022] In embodiments of the present invention, the master node 10 is located in the vehicle's ECU (Electronic Control Unit), domain controller, central controller, or body controller. The master node 10 can also be referred to as the master node ECU. The master node 10 is capable of communicating directly or indirectly with multiple domain networks of the vehicle (e.g., functional domains such as the body domain and chassis domain). Each slave node can be located in the vehicle's ECU, domain controller, central controller, or body controller. Slave nodes can also be referred to as slave node ECUs. Multiple slave nodes in each group can be located in different domain networks of the vehicle, or they can be located in the same domain network of the vehicle.

[0023] The upstream side of master node 10 can communicate with the vehicle's PEPS system, and the downstream side of master node 10 can communicate with each group of slave nodes. In one embodiment, the vehicle ECU where the master node is located is at a higher level in the vehicle's E / E architecture than the vehicle ECUs where the slave node groups are located. In another embodiment, the master node is located in a domain controller, and the slave nodes are located in vehicle ECUs at a lower level than the domain controller.

[0024] The following describes some examples of deploying master and slave node groups.

[0025] In one embodiment, see Figure 1The first set of nodes 20 is located in the vehicle's powertrain system, for example, in the vehicle's powertrain electronic control unit (powertrain ECU). The second set of nodes 30 is located in the vehicle's braking system, for example, in the vehicle's braking system electronic control unit (braking system ECU).

[0026] In one embodiment of this example, see Figure 2A The vehicle is implemented with split-axle control, meaning the vehicle's powertrain includes a front axle motor and a rear axle motor. In this embodiment, the first group of slave nodes 20 includes two slave nodes, namely, slave node (N) Slave_11 )21 and slave node (N) Slave_12 )22. The two slave nodes 21 and 22 are respectively set in the controller of the front axle motor (front axle motor ECU) and the controller of the rear axle motor (rear axle motor ECU).

[0027] In another implementation of this embodiment, see Figure 2B The vehicle is implemented with wheel-by-wheel control, meaning the vehicle's power system includes four motors, each coupled to one of the vehicle's four wheels (i.e., two wheels coupled to the front axle and two wheels coupled to the rear axle). In this embodiment, the first group of slave nodes 20 includes four slave nodes, namely, slave node (N) Slave_11 21. From node (N) Slave_12 22. From node (N) Slave_13 )23 and from node (N) Slave_14 )24. The four slave nodes 21 to 24 are respectively set in the controller of one of the four motors.

[0028] In another embodiment, see Figure 3 The vehicle anti-theft system 100 includes one or more additional sets of slave nodes. That is, in addition to the first set of slave nodes 20 and the second set of slave nodes 30 mentioned above, it may also include one or more additional sets of slave nodes, for example, a slave node group (N). Slave 40. From the node group (N) Slave )50 and slave node group (N Slave One or more of the nodes 40 to 60. In this embodiment, the nodes 40 to 60 are respectively disposed in the vehicle's steering system (e.g., steering system ECU), transmission system (e.g., transmission system ECU), and shift system (e.g., shift system ECU).

[0029] Figures 4A to 4C by Figure 1 The example of master and slave node groups illustrates some implementations of master and slave node group deployment.

[0030] See Figure 4AThe master node 10, along with the first group of slave nodes 20 and the second group of slave nodes 30, resides in the same domain network as the vehicle and communicates directly with them. Here, "direct communication" means that the master node and the slave node groups, being in the same domain network of the vehicle, do not need to send or receive information through other nodes in the vehicle. See also... Figure 4B The master node 10 and the first group of slave nodes 20 are located in different domain networks of the vehicle and communicate with the first group of slave nodes 20 via the domain controller (D). The master node 10 and the second group of slave nodes 30 are located in the same domain network of the vehicle and communicate directly with each other. See also Figure 4C The master node 10, the first group of slave nodes 20, and the second group of slave nodes 30 are located in different domain networks of the vehicle. The master node 10 communicates with the first group of slave nodes 20 via a domain controller (D), and the master node 10 also communicates with the second group of slave nodes 30 via a domain controller (D). It is understood that the domain controller coupled to the first group of slave nodes 20 and the domain controller coupled to the second group of slave nodes 30 can be the same domain controller or different domain controllers.

[0031] According to an embodiment of the present invention, the vehicle unlocking security verification includes two methods: chain verification between nodes and parallel verification.

[0032] "Chained verification" refers to multiple nodes verifying data sequentially. For example, a master node performs a verification based on challenge and response messages with one of the slave nodes in a group. Then, after passing this verification, that slave node becomes the new master node and performs a verification based on challenge and response messages with another slave node in the same group. This process continues until the last slave node in the group.

[0033] In a chain-verification embodiment, the order of slave nodes (i.e., the first slave node to be verified with the master node first, up to the last slave node to be verified last) can be based on the functional priority of each slave node in the group (e.g., the master functional node takes precedence over the backup functional node), or it can be based on the proximity of each slave node in the group on the communication link (e.g., the slave node closest to the master node on the communication link is the first slave node).

[0034] "Parallel verification" refers to verification by multiple nodes simultaneously. For example, a master node and multiple slave nodes from a group of slave nodes simultaneously perform verification based on challenge and response messages.

[0035] According to embodiments of the present invention, chained verification and parallel verification can be implemented in combination. For example, a master node performs verification based on challenge and response messages with one of the slave nodes in a group of slave nodes. After the verification passes, the slave node is then used as a new master node to perform parallel verification with multiple other slave nodes in the group, that is, to perform verification based on challenge and response messages simultaneously with multiple other slave nodes in the group.

[0036] Figure 5 This is a swimlane diagram of a vehicle anti-theft method 500 according to an embodiment of the present invention. The method 500 employs the aforementioned chain-checking mechanism. Figure 6 by Figure 1 The chained verification in method 500 is illustrated using the example of master node 10, slave node 31 in the second group of slave nodes, and slave node 32 in the second group of slave nodes. The following section combines... Figure 5 and Figure 6 Let's introduce method 500. For clarity, we will describe slave node 31 as the first slave node and slave node 32 as the second slave node.

[0037] In box 502, master node 10 receives an unlock signal from the PEPS system.

[0038] The PEPS system can wirelessly communicate with external nodes of the vehicle. In one embodiment, the external node is the car key. When the driver approaches the vehicle with the car key, the PEPS system receives a wireless signal from the car key and sends an unlock signal to the master node 10 in response to the wireless signal. In another embodiment, the external node is a vehicle app installed on the vehicle user's smart device (e.g., a smartphone or smartwatch). When the user approaches the vehicle with the smart device and the vehicle app open, the PEPS system receives a wireless signal from the vehicle app and sends an unlock signal to the master node 10 in response to the wireless signal.

[0039] After receiving a wireless signal from an external node, the PEPS system determines whether the wireless signal originates from an authorized object (legitimate object). The PEPS system will only send an unlock signal to the master node 10 if it determines the wireless signal originates from an authorized object. If the PEPS system determines the wireless signal originates from an unauthorized object (illegal object), it will not send an unlock signal to the master node 10. This invention does not limit the specific implementation method by which the PEPS system determines whether a wireless signal originates from an authorized object.

[0040] In box 504, master node 10 generates an unlock request in response to receiving an unlock signal from the PEPS system. This unlock request is used to request the vehicle to be unlocked so that the vehicle can be functionally unlocked and started.

[0041] In box 506, master node 10 sends an unlock request to first slave node 31.

[0042] In one embodiment, the master node 10 sends an unlock-related message to the first slave node 31 at predetermined time intervals. This message follows the vehicle network communication protocol. The message contains one bit of unlock request information, where "1" indicates an unlock request and "0" indicates no request.

[0043] In box 508, the first slave node 31 receives an unlock request from the master node 10.

[0044] In box 510, the first slave node 31 generates a challenge message in response to receiving the unlock request. The challenge message includes the current state of the first slave node 31 and a random number for this unlock request. A specific example of the challenge message is shown below.

[0045] In one embodiment, the first slave node 31 generates a challenge message after receiving an unlock request from the master node 10. The challenge message includes the current state of the first slave node 31 and a random number.

[0046] The current state of the first slave node 31 is one of 1) locked, 2) unlocking, or 3) unlocked. "Locked" indicates that the slave node is in a locked state; this unlocking operation can only be performed while the slave node is in this state, as a slave node can only be unlocked when it is locked. "Unlocking" indicates that the slave node is being unlocked; this unlocking operation cannot be performed while the slave node is in this state, as it is currently in another unlocking process. "Unlocked" indicates that the slave node has already been unlocked; this unlocking operation cannot be performed while the slave node is in this state, as it has already been unlocked.

[0047] In addition, the current state of the slave node may also be a fault state, indicating that there is a fault in the slave node. The slave node cannot perform this unlocking when it is in this state, because if the vehicle is unlocked and started at this time, there may be a safety hazard.

[0048] The random number is generated for each unlock request; that is, when a new unlock request arrives, the slave node generates a new random number for that request. This improves the reliability of vehicle anti-theft measures. For example, to prevent car thieves from continuously monitoring information on the vehicle's bus (e.g., the CAN bus), and detecting a challenge message generated for an unlock request at 3 PM, then another unlock request at 5 PM. In this scenario, if no new random number is generated, the challenge message for the 5 PM unlock request will be the same as the challenge message for the 3 PM unlock request, allowing the car thief to use the previously detected challenge message to trigger vehicle unlocking.

[0049] In one embodiment, the random number is an unpredictable and non-repeating sequence of random numbers generated using a dedicated algorithm and / or a dedicated chip.

[0050] In one embodiment, the random number has a data length of 120 bits or more. This helps prevent replay attacks.

[0051] Additionally, the first slave node 31 can count the number of failed unlock requests to obtain a count value, and generate an alarm message indicating that the vehicle is at risk of being stolen when the count value exceeds a counting threshold. This alarm message can be presented to the vehicle user in one or more ways, including voice, text, vibration, and horn.

[0052] In one embodiment, the challenge message has a predetermined format and is included in the data segment of a message transmitted on the vehicle bus. According to embodiments of the present invention, the challenge message with the predetermined format is applicable to various vehicle network protocols (e.g., CAN, CANFD, FlexRay, MOST, LIN), exhibiting versatility.

[0053] Table 1 below shows an example of a predefined format for a challenge message. In the example in Table 1, the challenge message contains three fields with a preset data length range: a slave node current status field of 2 to 8 bytes, a random number field of 15 to 64 bytes, and an additional information field of 0 to 56 bytes (the content of which can be filled and adjusted according to the specific application scenario and / or the needs of the vehicle user).

[0054] Table 1: Challenge Messages

[0055] Data segment information Data segment length Current status 2 to 8 bytes random numbers 15~64 bytes Additional Information 0~56 bytes

[0056] Additionally, in box 510, if the current state of the first slave node 31 is not locked (e.g., in the process of unlocking or already unlocked), then the slave node does not generate a random number, but instead fills the random number field in the challenge message with a default value. In other words, in this case, the random number field in the challenge message uses the default value.

[0057] In box 512, the first slave node 20 sends the generated challenge message to the master node 10.

[0058] In one embodiment, a response interval duration is preset. Here, "response interval duration" refers to the interval between two consecutive challenge messages sent by the slave node, that is, the interval between two consecutive unlock requests from the master node received by the slave node. Presetting this interval duration is advantageous because if the duration is too short, it will cause frequent generation of random numbers, resulting in collisions and replays between the frequently generated random numbers; if the duration is too long, the vehicle user will perceive that the vehicle is not responding to the user's unlocking request in a timely manner, which will lead to a poor user experience. Therefore, according to an embodiment of the present invention, the interval duration is preset to a suitable value. For example, a duration can be selected within the recommended interval duration range (e.g., 1s to 3s), and the selected duration can be set as the response interval duration.

[0059] In box 514, master node 10 receives a challenge message from first slave node 31.

[0060] In box 516, the master node determines whether the current state of the first slave node 31 is locked based on the received challenge message. If the current state of the first slave node 31 is locked, the subsequent steps continue (box 518). If the current state of the first slave node 31 is determined to be unlocking or unlocked (e.g., the challenge message from the first slave node 31 contains the current state as unlocking or unlocked, and the random number field is a default value), the subsequent steps are not executed, and the master node generates an alarm message indicating that the vehicle may be stolen. This alarm message may be presented to the vehicle user in one or more ways, including voice, text, vibration, and horn.

[0061] In box 518, master node 10 generates a response message in response to the challenge message from first slave node 31. The response message includes encrypted information obtained by encrypting the random number contained in the challenge message. Some embodiments of the encryption method and the corresponding encrypted information obtained are described below.

[0062] In one embodiment, the master node signs the random number using the private key from the public / private key pair to obtain the encrypted information of the random number. In another embodiment, the master node uses a shared symmetric key to calculate the Message Authentication Code (MAC) of the random number to obtain the encrypted information of the random number.

[0063] In one embodiment, the response message has a predetermined format and is included in the data segment of a message transmitted on the vehicle bus. According to embodiments of the present invention, the response message with the predetermined format is applicable to various vehicle network protocols (e.g., CAN, CANFD, FlexRay, MOST, LIN), exhibiting versatility.

[0064] Table 2 below shows an example of a predefined format for a response message. In the example in Table 2, the response message contains two fields with a preset data length range: an encrypted information field of 8 to 64 bytes and an additional information field of 0 to 56 bytes (the content of which can be filled and adjusted according to the specific application scenario and / or the needs of the vehicle user).

[0065] Table 2: Response Messages

[0066] Data segment information Data segment length Encrypted information 8~64 bytes Additional Information 0~56 bytes

[0067] In box 520, master node 10 sends a response message generated in response to the challenge message from first slave node 31 to first slave node 31.

[0068] In box 522, the first slave node 31 receives a response message from the master node 10.

[0069] In box 524, the first slave node 31 performs a vehicle unlock security check based on the received response message, which includes: a check on a random number or on encrypted information generated based on the random number. A specific example of the vehicle unlock security check is shown below.

[0070] In one embodiment, if encryption is performed using private key signing at the master node 10, the first slave node 31 decrypts the encrypted information using the public key from the private / public key pair to obtain a decrypted random number. Then, the first slave node 31 compares the decrypted random number with the random number in the previous challenge message. If they match, the verification passes. If they do not match, the verification fails.

[0071] In another embodiment, if a shared symmetric key is used for encryption at the master node 10, the first slave node 31 uses the shared symmetric key to calculate new encrypted information from the random number in the previous challenge message. Then, the first slave node 31 compares the encrypted information in the response message with the new encrypted information. If they match, the verification passes. If they do not match, the verification fails.

[0072] In box 526, the first slave node 31 sends the verification result to the master node 10.

[0073] In box 528, master node 10 receives the verification result from first slave node 31.

[0074] In box 530, the master node 10 determines whether to continue the unlock security verification or discontinue subsequent verification based on the verification result from the first slave node 31 and generates an alarm message.

[0075] For example, if the verification result from the first slave node 31 fails, the master node determines that it will not continue with subsequent verification and generates an alarm message indicating that the vehicle may be being stolen. This alarm message can be presented to the vehicle user in one or more ways, including voice, text, vibration, and horn.

[0076] If the verification result from the first slave node 31 is successful, the master node 10 sends a message (box 532) to the first slave node 31 indicating that the unlock security verification should continue.

[0077] In box 534, the first slave node 31 receives a message from the master node 10 indicating that the unlock security check should continue.

[0078] In box 536, in response to receiving a message from master node 10 indicating that the unlock security check should continue, first slave node 31, as the new master node, performs the unlock security check with second slave node 32. For example, first master node 31 sends an unlock request to second slave node 32.

[0079] In box 538, the second slave node 32 receives an unlock request from the first slave node 31.

[0080] In box 540, the second slave node 32 generates a challenge message in response to receiving the unlock request. The specific instances of challenge messages described above also apply here and will not be repeated.

[0081] In box 542, the second slave node 32 sends the generated challenge message to the first slave node 31.

[0082] In box 544, the first slave node 31 receives a challenge message from the second slave node 32.

[0083] In box 546, the first slave node 31 determines whether the current state of the second slave node 32 is locked based on the received challenge message. If the current state of the second slave node 32 is determined to be locked, the subsequent steps continue (box 548). If the current state of the second slave node 32 is determined to be unlocking or unlocked (e.g., the challenge message from the second slave node 32 contains the current state as unlocking or unlocked, and the random number field is a default value), the subsequent steps are not performed, and the first slave node 31 generates an alarm message indicating that the vehicle may be stolen. This alarm message may be presented to the vehicle user in one or more of the following ways: voice, text, vibration, and horn.

[0084] In box 548, the first slave node 31 generates a response message based on the challenge message from the second slave node 32. The specific instances of the response messages described above also apply here and will not be repeated.

[0085] In box 550, the first slave node 31 generates a response message in response to the challenge message from the second slave node 32 and sends it to the second slave node 32.

[0086] In box 552, the second slave node 32 receives a response message from the first slave node 31.

[0087] In box 554, the second slave node 32 performs a vehicle unlock security check based on the received response message, which includes: verification of a random number or encrypted information generated based on the random number. For specific examples of vehicle unlock security checks, please refer to the relevant descriptions above, which will not be repeated here.

[0088] In box 556, the second slave node 32 sends the verification result to the first slave node 31.

[0089] In box 558, the first slave node 31 sends the verification result between itself and the second slave node 32 to the master node 10.

[0090] In box 560, master node 10 receives the verification result from first slave node 31.

[0091] In box 562, master node 10 determines whether the functionality of each slave node can be unlocked based on all the verification results, thereby unlocking the group of slave nodes.

[0092] For example, if the verification results from each slave node (e.g., the verification results from the first slave node 31 and the second slave node 32) are all successful, the master node 10 sends a message to the first slave node 31 allowing the function to be activated, so that the function of the first slave node 31 is activated. Furthermore, in response to receiving the message from the master node 10 allowing the function to be activated, the first slave node 31 sends a message (box 564) allowing the function to be activated to the second slave node. In response to receiving (box 566) the message from the first slave node 31 allowing the function to be activated, the second slave node 32 unlocks its function.

[0093] In one embodiment, the activation-allowing message includes authentication information. The authentication information may include information indicating the party requesting unlocking. For example, if the master node 10 sends an unlock request to the first slave node 31, the requesting party is the master node. If the first slave node 31 sends an unlock request to the second slave node 32, the requesting party is the first slave node 31. The authentication information may also include an cryptographic signature of at least a portion of the data in the sent message, for verification and decryption at the recipient. The advantage of this approach is that if a car thief sends an unlock request message to a slave node via the vehicle bus, the slave node will authenticate the message instead of immediately unlocking it upon receiving the request, thus further enhancing vehicle anti-theft capabilities.

[0094] It is worth noting that, according to embodiments of the present invention, the function unlocking time interval between multiple slave nodes in the same group is less than a predetermined unlocking time interval. For example, as described above, the first slave node 31 receives the message allowing function unlocking before the second slave node 32; however, the time interval between the unlocking time of the first slave node 31 and the unlocking time of the second slave node 32 should be less than the predetermined unlocking time interval.

[0095] Additionally, if the verification results of the first slave node 31 and the second slave node 32 fail, the master node sends a message (box 568) to the first slave node 31 to disable the function activation, so that the function of all slave nodes in the group cannot be unlocked.

[0096] According to one embodiment of the present invention, a second set of slave nodes 30 is disposed in the vehicle's braking system, and the braking system includes a main braking system and an auxiliary braking system (also referred to as a backup braking system). In this embodiment, a first slave node 31 is disposed in the controller of the main braking system, and a second slave node 32 is disposed in the controller of the auxiliary braking system. Thus, the second set of slave nodes 30 in this embodiment is suitable for chain verification with the master node 10 in the above-described method 500. For example, the master node 10 first verifies with the slave nodes in the main braking system, and then the slave nodes in the main braking system verify with the slave nodes in the auxiliary braking system.

[0097] According to another embodiment of the vehicle anti-theft method of the present invention, the above-described parallel verification can be used. For example, see... Figure 2AParallel verification is performed among master node 10, slave node 21 in the first group of slave nodes, and slave node 22 in the first group of slave nodes. The master node determines whether the functionality of each slave node can be unlocked based on all verification results, thereby unlocking the vehicle. For example, if the verification result from each slave node is successful, it means that the master node has successfully handshaked with all slave nodes. In this case, master node 10 sends a message allowing function activation to each slave node, thus unlocking the functionality of each slave node. If the verification result from at least one slave node is unsuccessful, it means that the master node has failed to handshake with at least one slave node. In this case, the master node sends a message disabling function activation to each slave node, so that the functionality of all slave nodes cannot be unlocked.

[0098] Additionally, if the master node fails to handshake with at least one slave node, it can retry unlocking. For example, the master node resends unlock requests to each slave node and performs the handshake verification again. If the master node successfully hands off all slave nodes, it unlocks the functionality of each slave node, thus unlocking the vehicle. If the master node fails to handshake with at least one slave node, it retryes unlocking. This process repeats until the number of unsuccessful handshakes between the master node and at least one slave node exceeds a predetermined number. In this case, the master node generates an alarm message indicating that the vehicle may be being stolen. This alarm message can be presented to the vehicle user in one or more ways: voice, text, vibration, and horn.

[0099] According to one embodiment of the present invention, a first set of slave nodes 20 is disposed in the powertrain of a vehicle, and the powertrain includes two motors (e.g., a front axle motor or a rear axle motor). In this embodiment, a first slave node 21 is disposed in a controller controlling one motor, and a second slave node 22 is disposed in a controller controlling the other motor. Thus, the first set of slave nodes 20 in this embodiment is suitable for parallel verification with the master node 10 in the method 700 described above. For example, the master node 10, the first slave node 21 in the controller of the front axle motor, and the second slave node 22 in the controller of the rear axle motor are verified simultaneously (in parallel).

[0100] It is worth noting that, in this embodiment, the following condition must still be met: the function unlocking time interval between multiple slave nodes in the same group of slave nodes is less than a predetermined unlocking time interval. For example, if the first slave node 21 and the second slave node 22 in the first group of slave nodes simultaneously receive a message allowing function unlocking, the time interval between the unlocking time of the first slave node 21 and the unlocking time of the second slave node 22 should be less than the predetermined unlocking time interval.

[0101] According to one embodiment of the present invention, a first set of slave nodes 20 is disposed in the vehicle's power system, and a second set of slave nodes is disposed in the vehicle's braking system. Parallel verification, as described in method 700 above, is performed between the first set of slave nodes and the master node. Chained verification, as described in method 500 above, is performed between the second set of slave nodes and the master node. If all verifications pass, the master node first sends a function activation permission message to the second set of slave nodes, and then sends a function activation permission message to the first set of slave nodes, so that the vehicle's braking function is unlocked before the driving function. This prevents the vehicle from being dragged.

[0102] According to embodiments of the present invention, vehicle unlocking security verification may include chained verification, parallel verification, and a combination of chained verification and parallel verification. For example, in the verification between the master node and a group of slave nodes, chained verification, parallel verification, or a combination of chained verification and parallel verification may be used. See below. Figures 7A to 7D Taking the master node 10 and a group of slave nodes 21-24 as an example, we will introduce some implementation methods of this embodiment.

[0103] It is worth noting that the above description refers to an embodiment where the group of slave nodes are located in a single motor controller containing multiple motor controllers. According to embodiments of the present invention, the multiple slave nodes in this group can also be located in different functional modules of the vehicle's ECU or VCU, thereby ensuring, through the unlocking security verification according to embodiments of the present invention, that the function of each functional module is only unlocked when the unlocking request originates from the correct node (i.e., not from a "fake unlocking request" from a car thief).

[0104] In one implementation, see Figure 7A The master node performs unlock security checks on each slave node in the group (i.e., checks based on challenge and response messages). In this implementation, parallel checks are used. If all checks pass, each slave node can unlock. If at least one check fails, all slave nodes are prohibited from unlocking.

[0105] In another implementation, see Figure 7B The master node and multiple slave nodes in the group sequentially perform unlock security checks. That is, in this implementation, chained verification is used. For example... Figure 7BAs shown, firstly, the master node performs an unlock security check with slave node 21 in the group. If the check passes, slave node 21 is then used as the new master node and performs an unlock security check with another slave node 22 in the group. If this check passes, slave node 22 is then used as the new master node and performs an unlock security check with yet another slave node 23 in the group. If this check passes, slave node 23 is then used as the new master node and performs an unlock security check with yet another slave node 24 in the group. If all checks pass, each slave node can unlock. If at least one check fails, all slave nodes are disabled from unlocking.

[0106] In yet another implementation, see Figure 7C The master node and multiple slave nodes in the group undergo hybrid verification, which includes both chained and parallel verification. For example... Figure 7C As shown, firstly, the master node performs an unlock security check with slave node 21 in the group (i.e., the master node and slave node 21 perform chained checks). If this check passes, slave node 21 is then designated as the new master node and its unlock security is checked separately with the other slave nodes 22-24 in the group (i.e., slave node 21 and slave nodes 22-24 perform parallel checks). If all checks pass, each slave node can unlock. If at least one check fails, all slave nodes are disabled from unlocking.

[0107] In another embodiment, see Figure 7D The master node and multiple slave nodes in the group undergo hybrid verification, which includes both chained and parallel verification. For example... Figure 7D As shown, firstly, the master node performs an unlock security check with slave node 21 in the group (i.e., the master node performs a chain check with slave node 21). If this check passes, slave node 21 is then used as the new master node and performs an unlock security check with another slave node 22 in the group (i.e., slave node 21 performs a chain check with another slave node 22). If this check passes, slave node 22 is then used as the new master node and performs unlock security checks with the other slave nodes 23 and 24 in the group (i.e., slave node 22 performs parallel checks with the other slave nodes 23 and 24). If all checks pass, each slave node can unlock. If at least one check fails, all slave nodes are disabled from unlocking.

[0108] It should be understood, with reference Figures 7A-7DThe described implementation methods are merely examples and are not intended to exhaustively cover all possible implementation methods. Furthermore, in cases involving more slave nodes, such as verification of the master node and more than four slave nodes, more combined verification methods may be included, which will not be listed here.

[0109] Embodiments of the present invention also provide a vehicle control unit including one or more processors configured to perform the vehicle anti-theft method 500 or 700 as described above.

[0110] Embodiments of the present invention also provide a machine-readable storage medium storing executable instructions that, when executed, cause one or more processors to perform the vehicle anti-theft method 500 or 700 as described above.

[0111] It is understandable that the master node and each slave node can be implemented in hardware, software, or a combination of both. For the hardware implementation, it can be implemented in one or more application-specific integrated circuits (ASICs), digital signal processors (DSPs), data signal processing devices (DSPDs), programmable logic devices (PLDs), field-programmable gate arrays (FPGAs), processors, controllers, microcontrollers, microprocessors, electronic units designed to perform their functions, or combinations thereof. For the software implementation, it can be implemented using microcode, program code, or code segments, and can also be stored in machine-readable storage media such as storage components.

[0112] It is understood that all operations in the processes and methods described above are merely exemplary, and the present invention is not limited to any operation in the methods or the order of such operations, but should be covered by all other equivalent transformations under the same or similar concept.

[0113] It is understood that software can be broadly considered as representing instructions, instruction sets, code, code segments, program code, programs, subroutines, software modules, applications, software applications, software packages, routines, subroutines, objects, running threads, procedures, functions, etc. Software can reside on a computer-readable medium. A computer-readable medium can include, for example, memory, which can be, for example, magnetic storage devices (e.g., hard disks, floppy disks, magnetic stripes), optical disks, smart cards, flash memory devices, random access memory (RAM), read-only memory (ROM), programmable ROM (PROM), erasable PROM (EPROM), electrically erasable PROM (EEPROM), registers, or removable disks. Although memory is shown as separate from the processor in several aspects of the invention, memory can also reside within the processor (e.g., in caches or registers).

[0114] The above description is provided to enable any person skilled in the art to implement the various aspects described herein. Various modifications to these aspects will be apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects. Therefore, the claims are not intended to be limited to the aspects shown herein. All structural and functional equivalents of the elements of the various aspects described herein that are known or would be apparent to those skilled in the art are expressly incorporated herein by reference and are intended to be covered by the claims.

Claims

1. A vehicle anti-theft system, comprising a master node installed on the vehicle and at least two sets of slave nodes communicatively connected to the master node, each set of slave nodes comprising two or more slave nodes. The master node is configured to generate an unlock request; At least one slave node in at least one set of slave nodes is constructed as follows: After receiving the unlock request from the master node, a challenge is generated. Battle messages, and the corresponding messages received from at least one master node The unlock security check is performed after the response message to the challenge message. in, The challenge message includes the current state of at least one slave node. The response message packet includes the status and a random number for this unlock request. This includes encrypted information obtained by encrypting the random number, and the The unlock security verification includes: checking the random number or the encryption... Information verification; and If the unlock security verification passes, the [unlocked device] will be [accessed / transferred]. One less slave node becomes the new master node and is no longer needed in this group of slave nodes. He performs the unlock security verification from the node; Wherein, if all unlock security checks associated with the at least one group of slave nodes pass, the functionality of all slave nodes in the at least one group of slave nodes is unlocked; if at least one unlock security check associated with the at least one group of slave nodes fails, the functionality of all slave nodes in the at least one group of slave nodes is disabled.

2. The vehicle anti-theft system as described in claim 1, wherein, If the master node determines that the current state of at least one slave node is in the process of unlocking or has been unlocked, no further steps will be performed, and the master node will generate an alarm message indicating that the vehicle may be stolen.

3. The vehicle anti-theft system as described in claim 1, wherein, If the vehicle unlock security verification fails at at least one slave node, the master node sends an unlock request to the at least one slave node again and performs the vehicle unlock security verification again at the at least one slave node. Furthermore, if the number of times the vehicle unlock security verification fails at at least one slave node exceeds a predetermined number, the master node generates an alarm message indicating that the vehicle may be being stolen.

4. The vehicle anti-theft system as described in claim 1, wherein, The at least two sets of slave nodes include a first set of slave nodes and a second set of slave nodes, the first set of slave nodes being located in the vehicle's power system and the second set of slave nodes being located in the vehicle's braking system.

5. The vehicle anti-theft system as described in claim 4, wherein, If all unlock security checks associated with at least one group of slave nodes pass, the master node first sends a permission message to the second group of slave nodes, and then sends a permission message to the first group of slave nodes, so that the vehicle's braking function is unlocked before the driving function.

6. The vehicle anti-theft system as described in claim 4, wherein, The braking system includes a main braking system and an auxiliary braking system, and the second group of slave nodes includes two slave nodes, located in the main braking system and the slave braking system respectively. Furthermore, the slave node located in the main braking system receives the unlocking request from the master node. After the master node and the slave node pass the unlocking security verification, the slave node is designated as the new master node and performs unlocking security verification with the slave node located in the auxiliary braking system.

7. The vehicle anti-theft system as described in claim 4, wherein, The power system includes a front axle motor and a rear axle motor, and the first group of slave nodes includes two slave nodes, which are respectively set in the controller of the front axle motor and the controller of the rear axle motor; or The power system includes four motors, each coupled to one of the four wheels of the vehicle, and the first set of slave nodes includes four slave nodes, each set in the controller of one of the four motors.

8. The vehicle anti-theft system as described in claim 7, wherein, The master node performs the unlock security check in parallel with all slave nodes in the first group of slave nodes.

9. The vehicle anti-theft system as described in claim 1, wherein, The interval between the unlocking times of each slave node in the same group is less than the predetermined unlocking time interval.

10. The vehicle anti-theft system as claimed in claim 1, wherein, One of the at least two sets of slave nodes is disposed in the vehicle's power system, and the other set is disposed in the vehicle's braking system or in one of the vehicle's braking system, steering system, transmission system, shifting system and braking system.

11. The vehicle anti-theft system as claimed in claim 1, wherein, The vehicle anti-theft system includes a first set of slave nodes, a second set of slave nodes, and one or more additional slave node sets. The first set of slave nodes is installed in the vehicle's power system, the second set of slave nodes is installed in the vehicle's braking system, and one or more additional slave node sets are installed in one or more of the vehicle's steering system, transmission system, shifting system, and braking system.

12. The vehicle anti-theft system as described in claim 1, wherein, Performing the unlock security verification between the at least one slave node as the new master node and the other slave nodes in the group includes: The at least one slave node performs the unlock security verification with each of the other slave nodes in the group; or The at least one slave node performs the unlock security verification with another slave node in the group. After the verification passes, the other slave node is designated as the new master node and performs the unlock security verification with yet another slave node in the group; or The at least one slave node performs the unlock security verification with another slave node in the group of slave nodes. After the verification is passed, the other slave node is used as the new master node and performs the unlock security verification with one or more more slave nodes in the group of slave nodes respectively.

13. A vehicle anti-theft method, wherein the vehicle includes a master node and at least two sets of slave nodes communicatively connected to the master node, each set of slave nodes including two or more slave nodes, the method comprising: The master node generates an unlock request; At at least one of the at least one slave nodes in a group of slave nodes, a challenge message is generated after receiving an unlock request from the master node, wherein the challenge message includes the current state of the at least one slave node and a random number for this unlock request; After receiving at least one response message corresponding to the challenge message from the master node, an unlock security check is performed, wherein the response message includes encrypted information obtained by encrypting the random number, and the unlock security check includes: a check on the random number or the encrypted information; and If the unlock security verification passes, at the at least one slave node, the at least one slave node is designated as the new master node and the unlock security verification is performed with the other slave nodes in the group. If all unlock security checks associated with the at least one group of slave nodes pass, the functionality of all slave nodes in the at least one group of slave nodes is unlocked; and If at least one unlock security check associated with the at least one group of slave nodes fails, all slave nodes in the at least one group of slave nodes are disabled from unlocking.

14. A vehicle control unit, including one or more processors, configured to perform the vehicle anti-theft method as claimed in claim 13.

15. A machine-readable storage medium storing executable instructions that, when executed, cause one or more processors to perform the vehicle anti-theft method as described in claim 13.

Images