Method, apparatus, controller and program product for a vehicle network

Abstract

The present disclosure relates to a method, a controller, a vehicle and a program product for an in-vehicle network. The in-vehicle network comprises a master node and a plurality of slave nodes. The method comprises verifying synchronization information from the master node in the in-vehicle network. The method further comprises sending, in response to the synchronization information being failed to be verified, a verification failure information to at least one slave node of the plurality of slave nodes. The method further comprises switching, in response to a number of the verification failure information satisfying a predetermined condition, one slave node of the plurality of slave nodes as a new master node. By the method, the master node of the in-vehicle network can be switched dynamically, and the damage caused by malicious attacks to the in-vehicle network can be avoided.

Description

Technical Field

[0001] This disclosure relates to the field of vehicular networks, and more specifically to methods, apparatus, controllers, and program products for use in vehicular networks. Background Technology

[0002] Secure Onboard Communication (SecOC) is a communication encryption and authentication standard developed by the AUTOSAR (AUTomotive Open System Architecture) organization for in-vehicle communication buses, aiming to improve the security of data transmission in in-vehicle networks. The SecOC standard provides an end-to-end secure communication mechanism for automotive electronic systems, ensuring data confidentiality, integrity, and authenticity. Its technical framework is based on a layered protocol stack, integrated into the AUTOSAR system, and establishes secure channels through two-way authentication and dynamic key negotiation, employing encryption algorithms to encrypt data and verify integrity. Typical applications include critical scenarios such as V2X (Vehicle-to-Everything) communication and autonomous driving sensor data protection. Summary of the Invention

[0003] In a first aspect of the embodiments of this disclosure, a method for an in-vehicle network is provided. The in-vehicle network includes a master node and a plurality of slave nodes. The method includes verifying synchronization information from the master node in the in-vehicle network. The method further includes sending verification failure information to at least one of the plurality of slave nodes in response to a failure to verify the synchronization information. The method further includes switching one of the plurality of slave nodes to a new master node in response to a number of verification failure messages satisfying a predetermined condition.

[0004] In a second aspect of the embodiments of this disclosure, an apparatus for an in-vehicle network is provided. The in-vehicle network includes a master node and a plurality of slave nodes. The apparatus includes an authentication unit configured to authenticate synchronization information from the master node in the in-vehicle network. The apparatus also includes a sending unit configured to send authentication failure information to at least one of the plurality of slave nodes in response to a synchronization information authentication failure. The apparatus further includes a switching unit configured to switch one of the plurality of slave nodes to a new master node in response to a number of authentication failure messages meeting the predetermined conditions.

[0005] In a third aspect of embodiments of this disclosure, a controller is provided. The controller includes at least one processor. The controller also includes memory coupled to the at least one processor and having instructions stored thereon, which, when executed by the at least one processor, cause the controller to perform a method for an in-vehicle network according to this disclosure. The in-vehicle network includes a master node and a plurality of slave nodes. The method includes verifying synchronization information from the master node in the in-vehicle network. The method further includes sending verification failure information to at least one of the plurality of slave nodes in response to a failure to verify the synchronization information. The method further includes switching one of the plurality of slave nodes to a new master node in response to a number of verification failure messages satisfying a predetermined condition.

[0006] In a third aspect of the embodiments of this disclosure, a computer program product is provided. The computer program product includes machine-executable instructions that, when executed, cause a machine to implement a method for an in-vehicle network. The in-vehicle network includes a master node and a plurality of slave nodes. The method includes verifying synchronization information from the master node in the in-vehicle network. The method further includes sending verification failure information to at least one of the plurality of slave nodes in response to a failure to verify the synchronization information. The method further includes switching one of the plurality of slave nodes to a new master node in response to a number of verification failure messages satisfying a predetermined condition.

[0007] In a fourth aspect of embodiments of this disclosure, a vehicle is provided, the vehicle including a controller configured to perform a method according to an in-vehicle network. The in-vehicle network includes a master node and a plurality of slave nodes. The method includes verifying synchronization information from the master node in the in-vehicle network. The method further includes sending verification failure information to at least one of the plurality of slave nodes in response to a failure of the synchronization information to be verified. The method further includes switching one of the plurality of slave nodes to a new master node in response to a number of verification failure messages satisfying the predetermined condition.

[0008] In a fifth aspect of embodiments of this disclosure, a computer-readable storage medium is provided. The computer-readable storage medium stores computer-executable instructions, which are executed by a processor to implement a method for an in-vehicle network. The in-vehicle network includes a master node and a plurality of slave nodes. The method includes verifying synchronization information from the master node in the in-vehicle network. The method further includes sending verification failure information to at least one of the plurality of slave nodes in response to a failure to verify the synchronization information. The method further includes switching one of the plurality of slave nodes to a new master node in response to a number of verification failure messages satisfying a predetermined condition.

[0009] It should be understood that the description in the Summary of the Invention section is not intended to limit the key or essential features of the embodiments of this disclosure, nor is it intended to restrict the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent from the accompanying drawings and the following detailed description. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0011] Figure 1 A schematic diagram of an example in-vehicle network in which several embodiments of the present disclosure may be implemented is shown;

[0012] Figure 2 A flowchart of a method for an in-vehicle network according to some embodiments of the present disclosure is shown;

[0013] Figure 3 A flowchart is shown of a method for switching master nodes in an in-vehicle network according to some embodiments of the present disclosure;

[0014] Figure 4 This diagram illustrates how the synchronization information of the master node in the vehicle network is successfully verified by each slave node.

[0015] Figure 5 This diagram illustrates how the synchronization information of the master node in a vehicle network fails to be verified by some slave nodes.

[0016] Figure 6 This diagram illustrates how the synchronization information of the master node in a vehicle network fails to be verified by a majority of slave nodes, leading to a switch of the master node.

[0017] Figure 7 An apparatus for an in-vehicle network is shown according to some embodiments of the present disclosure;

[0018] Figure 8 A schematic block diagram of a controller that can be used to implement several embodiments of the present disclosure is shown. Detailed Implementation

[0019] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure. The embodiments of this disclosure described below with reference to the accompanying drawings are for illustrative purposes only.

[0020] As mentioned above, SecOC is a communication encryption and authentication standard launched by the AUTOSAR organization for vehicular communication buses, aiming to improve the security of data transmission in vehicular networks. As a next-generation vehicular network security bus solution, it uses Message Authentication Code (MAC) codes for authentication to prevent bus data tampering. It also introduces dynamic identifier management (such as timestamps, serial numbers, or nonces) in its anti-replay mechanism, which is figuratively referred to as freshness management in the industry to prevent replay attacks. Replay attacks are a common type of attack in network security, where attackers intercept legitimate communication data packets and resend them to deceive the target system and achieve illegal purposes. Its core principle is to exploit the statelessness of the system or flaws in the authentication mechanism, causing older data packets to be mistakenly considered valid.

[0021] In relevant dynamic identifier management schemes, one or more fixed master nodes in the vehicular network periodically broadcast synchronization information to notify slave nodes in the network to trigger counters and reset dynamic identifier counters. When the master node is subjected to malicious attacks or node failures, the dynamic identifier update function is disrupted, and the system faces threats such as replay attacks.

[0022] Therefore, in traditional dynamic identifier management mechanisms, a fixed master node is responsible for generating and allocating the Trip Counter and Reset Counter in the dynamic identifier through synchronization information. Slave nodes receive the counter values ​​from the synchronization information for verification of security messages, such as SecOC security messages. One or more embodiments of this disclosure provide a method or system for dynamically switching master nodes and managing dynamic identifiers in vehicle networks with high fault tolerance, based on verifying this synchronization information. This method or system can dynamically select the master node in the vehicle network and quickly switch to a new master node when the master node suffers a malicious attack or failure, thereby ensuring the continuity and consistency of dynamic identifiers.

[0023] In summary, this disclosure provides a method for an in-vehicle network, including a master node and multiple slave nodes. The method includes verifying synchronization information from the master node in the in-vehicle network. The method further includes sending verification failure information to at least one of the multiple slave nodes in response to a failure in the verification of the synchronization information. Furthermore, the method includes switching one of the multiple slave nodes to a new master node in response to a predetermined condition being met by the number of verification failure messages. This method allows for dynamic selection of the master node in the vehicle network and rapid switching to a new master node when the master node suffers malicious attacks or failures, thereby ensuring the continuity and consistency of dynamic identifiers. This significantly improves the security of the in-vehicle network, protecting it from threats such as replay attacks. The following section combines... Figure 1 and Figure 2 Some embodiments of the method are described in detail.

[0024] Figure 1 A schematic diagram of an example in-vehicle network 100 in which several embodiments of this disclosure can be implemented is shown. An in-vehicle network mainly refers to a communication system within a vehicle used to connect various electronic control units (ECUs), sensors, actuators, and terminal devices. It is primarily built upon bus protocols such as CAN (Controller Area Network), LIN (Local Interconnect Network), FlexRay (Flexible Reliable Communication), and MOST (Multi-Service Transport) to achieve data exchange and collaborative control. Its core functions include command transmission (such as brake signals), status monitoring (such as tire pressure data), and fault diagnosis. Nodes in the in-vehicle network are functional units within the network, which can be ECUs (such as engine control units, electronic stability programs), sensors (such as cameras, radar), actuators (such as electric power steering motors), or terminal devices (such as central control screens). Each node has a unique identifier (address) and is responsible for sending or receiving specific types of data. Figure 1As shown, the vehicular network 100 may include an initial master node 110 and multiple slave nodes 120, 130, and 140, etc. Generally, the master node is the coordinator in the network, usually responsible for communication scheduling, such as allocating transmission timing and avoiding data conflicts (e.g., master node polling slave nodes in a LIN bus). It is also responsible for protocol management: controlling frame format, priority, and error handling rules (e.g., the multi-master arbitration mechanism of CAN), and initialization configuration, such as starting network communication and identifying slave node identities. To prevent malicious attacks such as replay attacks, the initial master node 110 can send synchronization information (111, 112, and 113) of the vehicular network 100 to multiple slave nodes 120, 130, and 140, etc. One or more embodiments of this disclosure provide a method or system for dynamically switching master nodes and managing dynamic identifiers in a vehicle network with high fault tolerance, based on verifying this synchronization information. This method or system can dynamically select the master node in the vehicle network and quickly switch to a new master node when the master node suffers a malicious attack or failure. Figure 1 As shown, when the initial master node 110 is attacked or fails (105), exemplarily, one or more embodiments of this disclosure can switch node 120 to a new master node. The new master node 120 can send synchronization information (121, 122 and 123) of the vehicle network 100 to other nodes 110, 130 and 140, thereby ensuring the continuity and consistency of the dynamic identifier and preventing malicious attacks such as replay attacks.

[0025] It is worth noting that the aforementioned vehicle network 100 may include an initial master node 110 and multiple slave nodes 120, 130, and 140, which is merely an example. The vehicle network 100 may include more or fewer master and slave nodes. One or more embodiments of this disclosure do not impose any limitation on the number of nodes, and any number of master or slave nodes suitable for this invention should be within the scope of protection of this disclosure.

[0026] Figure 2A flowchart of a method 200 for an in-vehicle network according to some embodiments of the present disclosure is shown. In some embodiments, method 200 may be implemented by a vehicle having an in-vehicle network. At block 210, synchronization information from a master node in the in-vehicle network is verified. In some embodiments, the in-vehicle network includes a master node 110 and a plurality of slave nodes 120, 130, and 140. In some embodiments, an initial master node 110 may send synchronization information (111, 112, and 113) of the in-vehicle network 100 to the plurality of slave nodes 120, 130, or 140. In some embodiments, the plurality of slave nodes 120, 130, or 140 may receive the synchronization information (111, 112, and 113) sent by the initial master node 110. In some embodiments, the plurality of slave nodes 120, 130, or 140 receive synchronization information from the initial master node 110 at predetermined time intervals. In some embodiments, verifying the synchronization information from the master node in the in-vehicle network may include checking the correctness of dynamic identifiers in the synchronization information. If the dynamic identifier is incorrect—for example, if the dynamic identifier is a previous dynamic identifier value or the dynamic identifier value is incorrect—verifying the synchronization information from the master node in the vehicular network may include checking the correctness of the dynamic identifier in the synchronization information, and may further include determining that the synchronization information has failed to be verified in response to an incorrect dynamic identifier in the synchronization information. Conversely, if the dynamic identifier is correct, the synchronization information is determined to have been successfully verified. It is worth noting that one or more embodiments of this disclosure do not impose any limitations on how synchronization information is verified. Any method suitable for verifying synchronization information according to this disclosure should be within the scope of protection of this disclosure.

[0027] At block 220, in response to a synchronization information verification failure, a verification failure message (220) is sent to at least one of the plurality of slave nodes. In some embodiments, if slave node 120 verifies that the synchronization information is invalid, slave node 120 may send a verification failure message indicating that the synchronization information has failed to be verified to slave nodes 130 or 140. Conversely, slave node 130 may send a verification failure message indicating that the synchronization information has failed to be verified to slave nodes 120 or 140, or slave node 140 may send a verification failure message indicating that the synchronization information has failed to be verified to slave nodes 120 or 130. In some embodiments, slave nodes 120, 130, or 140 may also send a verification failure message indicating that the synchronization information has failed to be verified or a verification success message indicating that the synchronization information has been successfully verified to the initial master node 110. In some embodiments, sending a verification failure message (220) to at least one of the plurality of slave nodes in response to a synchronization information verification failure may include broadcasting the verification failure message to all other slave nodes in response to the synchronization information verification failure. As an example, slave node 120 can send a verification failure message indicating that the synchronization information failed to be verified to slave nodes 130 and 140, slave node 130 can send a verification failure message indicating that the synchronization information failed to be verified to slave nodes 120 and 140, or slave node 140 can send a verification failure message indicating that the synchronization information failed to be verified to slave nodes 120 and 130.

[0028] At block 230, in response to the number of verification failure messages meeting a predetermined condition, one of the multiple slave nodes is switched to become the new master node. In some embodiments, in response to the number of verification failure messages meeting the predetermined condition, for example, slave node 120 can switch or replace the potentially failed initial master node 110, thereby making slave node 120 the new master node. In some embodiments, after becoming the new master node, 120 can replace the initial master node 110 in sending synchronization information of the vehicular network 100 to other slave nodes. In some embodiments, other slave nodes 130 and 140 may have the opportunity to become the new master node. In some embodiments, the predetermined condition may be that the number of verification failure messages reaches a certain value. As to how the switch from one of the multiple slave nodes to the new master node in response to the number of verification failure messages meeting the predetermined condition will be described in detail in subsequent embodiments, it will not be repeated here.

[0029] Therefore, one or more embodiments of method 200 provide a dynamic, fault-tolerant method for managing dynamic identifiers in a vehicle network, based on verifying the synchronization information of the vehicular network. Method 200 can dynamically select the master node in the vehicular network and quickly switch to a new master node when the master node suffers a malicious attack or failure, thereby ensuring the continuity and consistency of dynamic identifiers, preventing malicious attacks such as replay attacks, and avoiding potential losses caused by these malicious attacks.

[0030] Figure 3 The following is a flowchart of a method 300 for switching master nodes in a vehicular network according to some embodiments of the present disclosure. Method 300 is implemented in more detail. Figure 2 Method 200 illustrates a method for switching the master node. Method 300 may switch one of a plurality of slave nodes to a new master node in response to a predetermined condition being met by the number of verification failure messages. At block 310, at least one verification failure message is acquired. In some embodiments, the slave node itself may verify the synchronization information of the vehicular network and may send the verification failure result to other slave nodes. In some embodiments, the slave node may receive verification failure messages from other slave nodes. If multiple slave nodes exist, the slave node may receive multiple verification failure messages from other slave nodes. In some embodiments, the slave node may receive all other verification failure messages from all other slave nodes. In some embodiments, acquiring at least one verification failure message may include acquiring verification failure messages from all other slave nodes at predetermined time intervals.

[0031] At box 320, a failure counter is incremented in response to the number of verification failure messages being greater than or equal to a first predetermined threshold. In some embodiments, a failure counter is set at at least one slave node. This failure counter can be used to count the number of verification failures of synchronization messages sent by the master node. In some embodiments, a failure counter can be set at all slave nodes. In some embodiments, a failure counter can also be set at the master node and all slave nodes. In some embodiments, the failure counter is incremented in response to the number of verification failure messages being greater than or equal to the first predetermined threshold. In some embodiments, incrementing the failure counter in response to the number of verification failure messages being greater than or equal to the first predetermined threshold may include determining the number of verification failure messages from all other slave nodes. In some embodiments, incrementing the failure counter in response to the number of verification failure messages being greater than or equal to the first predetermined threshold may also include incrementing the failure counter in response to the number of verification failure messages being greater than or equal to the first predetermined threshold. In some embodiments, incrementing the failure counter in response to the number of verification failure messages being greater than or equal to the first predetermined threshold may also include treating the synchronization message as valid in response to the number of verification failure messages being less than the first predetermined threshold. In some embodiments, incrementing the failure counter in response to the number of verification failure messages being greater than or equal to the first predetermined threshold may also include maintaining the original count of the failure counter.

[0032] In some embodiments, method 300 may further include determining the total number of master nodes and all slave nodes, and determining a first predetermined threshold based on the total number of master nodes and all slave nodes. In some embodiments, the first predetermined threshold is any integer between half the total number of master nodes and all slave nodes and the total number of master nodes and all slave nodes.

[0033] At box 330, in response to a failure counter value being greater than or equal to a second predetermined threshold, one of the multiple slave nodes is switched to become the new master node. In some embodiments, the same master node switching order list can be configured for all slave nodes. In some embodiments, switching one of the multiple slave nodes to become the new master node in response to a failure counter value being greater than or equal to the second predetermined threshold may include determining the failure counter value and determining the master node as a failed master node in response to the failure counter value being greater than or equal to the second predetermined threshold. In some embodiments, switching one of the multiple slave nodes to become the new master node in response to a failure counter value being greater than or equal to the second predetermined threshold may further include switching one of the multiple slave nodes to become the new master node in response to the master node being a failed master node. In some embodiments, switching one of the multiple slave nodes to become the new master node in response to a failure counter value being greater than or equal to the second predetermined threshold may further include, based on the master node switching order list, switching the slave node that is directly after the failed master node in the master node switching order list to become the new master node.

[0034] In some embodiments, method 300 may further include determining the total number of master nodes and all slave nodes. In some embodiments, method 300 may further include determining a second predetermined threshold based on the total number of master nodes and all slave nodes. In some embodiments, method 300 may further reset a failure counter in response to switching master nodes. In the following embodiments, if all slave nodes or the new master node have failure counters set, then the failure counters are reset.

[0035] Therefore, one or more embodiments of method 300 provide a dynamic identifier management method for vehicle networks with dynamic master node switching and high fault tolerance, based on the verification failure information of the synchronization information of the vehicular network and the total number of master nodes and all slave nodes. Method 300 can dynamically select the master node in the vehicular network and quickly and dynamically switch the master node when it suffers malicious attacks or failures, thereby ensuring the continuity and consistency of dynamic identifiers and preventing malicious attacks such as replay attacks.

[0036] In summary, one or more embodiments of the present disclosure provide a dynamic identifier management method for vehicle networks with dynamic master node switching and high fault tolerance. One or more embodiments of the present disclosure mainly provide a plurality of key mechanisms to implement the dynamic identifier management method for vehicle networks with dynamic master node switching and high fault tolerance. By way of example, in some embodiments, each on-vehicle network node has both the functions of a master node and a slave node. In some embodiments, each network node is configured with the same master node switching sequence table. In some embodiments, when the master node fails and stops sending synchronization information, other slave nodes in the vehicle network can autonomously identify the failure and switch the master node. In some embodiments, when the master node broadcasts message content indicating synchronization abnormality, other nodes in the network acquire correct dynamic identifiers by adopting a Byzantine fault tolerance-like algorithm (or distributed decision-making). In some embodiments, if the number of abnormal synchronization information sent by the current master node exceeds a certain threshold, the slave nodes in the vehicle network can independently identify the failure and replace the master node.

[0037] In some embodiments, it can be set that there are n nodes in the vehicle network, that is, one master node and n-1 slave nodes. The first predetermined threshold for determining the validity of synchronization information is N, where n / 2 < N < n. That is, when a slave node disagrees with the synchronization information from the master node, it will send or broadcast a rejection message to notify other nodes. When a majority (e.g., at least N) of slave nodes disagree with the synchronization information, the synchronization information is deemed invalid, and the master failure counter on each slave node is incremented by 1; otherwise, the synchronization information is deemed valid. When the value of the master failure counter reaches the second predetermined threshold (M), the current master node is considered invalid, and master node switching can be performed. Each slave node is configured with the same master node switching sequence table, and switching is performed according to the sequence recorded in the master node switching sequence table. In some embodiments, if valid synchronization information is received when the value of the master failure counter is less than M, the master failure counter is reset and restart counting. In some embodiments, the value of M can be determined by n, for example, n / 2 < M < n, or 3n / 4 < M < n. It is worth noting that the values of n, N and M in one or more embodiments of the present disclosure are exemplary, and are merely examples provided to help those skilled in the art understand the present invention. One or more embodiments of the present disclosure do not limit the specific values of n, N and M. All values of n, N and M suitable for the present disclosure shall fall within the protection scope of the present disclosure.

[0038] Further, in order to help those skilled in the art better understand the present invention, one or more embodiments of the present disclosure will be combined with Figure 4 , 5 and 6 to describe the present disclosure in more detail. By way of example, set n=4, N=3, M=3. Figure 4This diagram illustrates how the synchronization information of the master node in the vehicular network 400 is successfully verified by each slave node. The master node is initialized as node 410, and the slave nodes are 420, 430, and 440. The node switching order in the master node switching order table can be set to 410 -> 420 -> 430 -> 440. Figure 4 In this process, master node 410 broadcasts a new run counter and resets the synchronization information counter with FV (Full View) synchronization information (411, 412, and 413). Exemplarily, this synchronization information is verified and passed by all slave nodes 420, 430, and 440 (421, 431, and 441). Exemplarily, after receiving the synchronization information, each slave node 420, 430, and 440 does not receive a rejection message indicating a synchronization information verification failure from other slave nodes (420, 430, and 440) in the arbitration timer (405). Then, all slave nodes 420, 430, and 440 accept the new counter value (i.e., the new dynamic identifier value) in the FV synchronization information (422, 432, and 442). Since the synchronization information of master node 410 is successfully verified by each slave node 420, 430, and 440, master node 410 is valid and confirms the success of the synchronization information (414).

[0039] Figure 5 This diagram illustrates a scenario where synchronization information from the master node of the vehicular network 500 fails to be verified by some slave nodes. As an example, n=4, N=3, and M=3 can be set. The master node is initialized as node 510, and the slave nodes are 520, 530, and 540. The node switching order in the master node switching order table can be set to 510->520->530->540. Figure 5In the present invention, the master node 510 broadcasts a new trip counter and resets the synchronization information counter with FV (Full View) synchronization information (511, 512 and 513). Illustratively, the synchronization information is checked and passed by slave nodes 520 and 530 (521 and 531), but fails to be verified by slave node 540. Illustratively, the slave node 540 forwards or broadcasts a message indicating that the verification of the synchronization information fails to the entire vehicle-mounted network (541, 542 and 543). Then each of the nodes 510, 520, 530 and 540 sets its slave failure counter (decline_counter) to 1, but accepts the new counter value of the synchronization information in the FV synchronization information, because the value of the master failure counter is < M(3). In some embodiments, the slave failure counter on each node can be used to record the number of verification failures of the received synchronization information within a predetermined time interval (the corresponding predetermined threshold is N), and the master failure counter on each node can be used to record the number of confirmed verification failures of the synchronization information (the corresponding predetermined threshold is M). Illustratively, after receiving the synchronization information, each of the slave nodes 520, 530 and 540 does not receive a rejection message indicating that the verification of the synchronization information fails from other slave nodes (520 and 530) within an arbitration timer (505). Then all the slave nodes 520, 530 and 540 accept the new counter value of the synchronization information in the FV synchronization information (522, 532 and 544). Since the synchronization information of the master node 510 is verified successfully by most of the slave nodes 520 and 530, the master node 510 is still valid, and a message indicating that the synchronization information succeeds can be confirmed (514).

[0040] Further, Figure 6 a schematic diagram that the synchronization information of a master node of a vehicle-mounted network 600 fails to be verified by most slave nodes and the master node is switched is shown. As an example, n=4, N=3, and M=3 can be set. The initial master node is node 610, and the slave nodes are 620, 630 and 640. A node switching sequence in a master node switching sequence table can be set as 610→620→630→640. In Figure 6In this process, the master node 610 broadcasts a new trip counter and resets the synchronization information counter (611, 612, and 613) with FV (Full View) synchronization information. Exemplarily, this synchronization information is verified as failed by slave nodes 620, 630, and 640. Exemplarily, slave nodes 620, 630, and 640 then forward or broadcast the message indicating that the synchronization information was verified as failed to the entire vehicular network (621, 622, and 623; 631, 632, and 633; ​​641, 642, and 643). Each node 620, 630, and 640 sets the failure counter to 3, and increments the master failure counter by 1 when the slave failure counter reaches N(3). For example, when synchronization information fails 3 (M) consecutive times and the master failure counter reaches M, if no rejection message indicating synchronization information verification failure is received from other slave nodes (620 and 630) in the arbitration timer (605), then each node accepts the master node 610's failure information (614, 624, 634, and 644). At 607, each node acknowledges that the master failure counter has reached M and that the master node 610 has failed. Then, each slave node 610, 630, and 640 sets the new master node as node 620 according to the switching order of the master node switching order table (610 -> 620 -> 630 -> 640) (615, 635, and 645). As the new master node, node 620 can broadcast a new run counter and reset the synchronization information counter with FV (Full View) synchronization information (627, 625, and 626). In some embodiments, each node resets its slave failure counter and master failure counter, thereby starting a new dynamic master node switching cycle.

[0041] In some embodiments, extreme situations may occur, such as the master node 610 encountering an extreme failure, which may prevent it from sending synchronization information to each slave node for more than two consecutive time intervals. In such cases, if each slave node fails to obtain synchronization information from the master node 610 for more than two consecutive time intervals, it can directly determine that the value of M(3) has been reached, and the master node 610 is considered to have failed. Slave nodes 620, 630, and 640 can directly set node 620 as the new master node according to the switching order of the master node switching order table (610—>620—>630—>640). As the new master node, node 620 can send synchronization information to other nodes and start a new dynamic master node switching cycle. This can avoid extreme harmful situations. In some embodiments, only N can be considered as the threshold for triggering a new master node switch, without considering the value of M. That is, if a synchronization information verification failure is determined, a new master node switch can be performed.

[0042] Therefore, in combination with the above... Figure 4 , 5The embodiments of this disclosure described in section 6 provide various methods for dynamically switching master nodes and managing dynamic identifiers in vehicle networks with high fault tolerance. These methods can dynamically select the master node in the vehicular network and quickly and dynamically switch the master node when it suffers malicious attacks or failures, thereby ensuring the continuity and consistency of dynamic identifiers and preventing malicious attacks such as replay attacks. This avoids one or more drawbacks of traditional fixed master node methods, ensuring the normal operation of the vehicular network and providing normal security protection capabilities even under malicious attacks such as replay attacks.

[0043] Figure 7 An apparatus 700 for an in-vehicle network according to some embodiments of the present disclosure is shown. The in-vehicle network includes a master node and a plurality of slave nodes. The apparatus 700 includes an authentication unit 710 configured to authenticate synchronization information from the master node in the in-vehicle network. The apparatus also includes a sending unit 720 configured to send authentication failure information to at least one of the plurality of slave nodes in response to authentication failure of the synchronization information. The apparatus 700 further includes a switching unit 730 configured to switch one of the plurality of slave nodes to a new master node in response to a number of authentication failure messages meeting predetermined conditions.

[0044] In some embodiments, verifying synchronization information from a master node in the vehicular network includes checking the correctness of a dynamic identifier in the synchronization information, and determining that the synchronization information has failed to be verified if the dynamic identifier in the synchronization information is incorrect. In some embodiments, sending verification failure information to at least one of a plurality of slave nodes in response to the synchronization information failing to be verified includes one of the slave nodes broadcasting the verification failure information to all other slave nodes in response to the synchronization information failing to be verified.

[0045] In some embodiments, switching one of the multiple slave nodes to a new master node in response to the number of verification failure messages meeting a predetermined condition includes obtaining at least one verification failure message, incrementing a failure counter in response to the number of verification failure messages being greater than or equal to a first predetermined threshold, and switching one of the multiple slave nodes to a new master node in response to the value of the failure counter being greater than or equal to a second predetermined threshold.

[0046] In some embodiments, obtaining at least one verification failure message includes obtaining verification failure messages from all other slave nodes at predetermined time intervals. In some embodiments, incrementing a failure counter in response to the number of verification failure messages being greater than or equal to a first predetermined threshold includes determining the number of verification failure messages from all other slave nodes, and incrementing the failure counter in response to the number of verification failure messages being greater than or equal to the first predetermined threshold. In some embodiments, incrementing the failure counter in response to the number of verification failure messages being greater than or equal to the first predetermined threshold further includes treating the synchronization information as valid and maintaining the original count of the failure counter in response to the number of verification failure messages being less than the first predetermined threshold.

[0047] In some embodiments, the total number of master nodes and all slave nodes may be determined, and a first predetermined threshold may be determined based on the total number of master nodes and all slave nodes. In some embodiments, the first predetermined threshold is any integer between half the total number of master nodes and all slave nodes and the total number of master nodes and all slave nodes.

[0048] In some embodiments, switching one of the multiple slave nodes to a new master node in response to a failure counter value being greater than or equal to a second predetermined threshold includes determining the failure counter value, determining the master node as a failed master node in response to the failure counter value being greater than or equal to the second predetermined threshold, and switching one of the multiple slave nodes to a new master node in response to the master node being a failed master node. In some embodiments, the same master node switching order table may also be configured for all slave nodes. In some embodiments, switching one of the multiple slave nodes to a new master node in response to a failure counter value being greater than or equal to the second predetermined threshold also includes, based on the master node switching order table, selecting the slave node directly following the failed master node in the master node switching order table to switch the failed master node and become the new master node.

[0049] This disclosure also provides a computer program product. The computer program product includes machine-executable instructions that, when executed, cause a machine to implement a method for an in-vehicle network. The in-vehicle network includes a master node and a plurality of slave nodes. The method includes verifying synchronization information from the master node in the in-vehicle network. The method further includes sending verification failure information to at least one of the plurality of slave nodes in response to a failure to verify the synchronization information. The method further includes switching one of the plurality of slave nodes to a new master node in response to a predetermined number of verification failure messages.

[0050] This disclosure also provides a vehicle including a controller configured to perform a method according to an in-vehicle network. The in-vehicle network includes a master node and a plurality of slave nodes. The method includes verifying synchronization information from the master node in the in-vehicle network. The method further includes sending verification failure information to at least one of the plurality of slave nodes in response to a failure to verify the synchronization information. The method further includes switching one of the plurality of slave nodes to a new master node in response to a number of verification failure messages satisfying a predetermined condition.

[0051] This disclosure also provides a computer-readable storage medium. The computer-readable storage medium stores computer-executable instructions, which are executed by a processor to implement a method for an in-vehicle network. The in-vehicle network includes a master node and a plurality of slave nodes. The method includes verifying synchronization information from the master node in the in-vehicle network. The method further includes sending verification failure information to at least one of the plurality of slave nodes in response to a failure to verify the synchronization information. The method further includes switching one of the plurality of slave nodes to a new master node in response to a predetermined condition being met by a number of verification failure messages.

[0052] Figure 8 A schematic block diagram of a controller 800 that can be used to implement various embodiments of the present disclosure is shown. As shown, the electronic device 800 includes a processor 801 that can perform various appropriate actions and processes according to computer program instructions loaded into random access memory (RAM) 803 based on computer program instructions stored in read-only memory (ROM) 802. Various programs and data required for the operation of the electronic device 800 may also be stored in RAM 803. The processor 801, ROM 802, and RAM 803 are interconnected via a bus 804. An input / output (I / O) interface 805 is also connected to the bus 804.

[0053] Processor 801 can be a variety of general-purpose and / or special-purpose processing components with processing and computing capabilities. Some examples of processor 801 include, but are not limited to, a central processing unit (CPU), a graphics processing unit (GPU), various special-purpose artificial intelligence (AI) computing chips, various computing units running machine learning model algorithms, a digital signal processor (DSP), and any suitable processor, controller, microcontroller, etc. Processor 801 performs the various methods and processes described above, such as method 200, etc. For example, in some embodiments, method 200, etc., may be implemented as a computer software program tangibly contained in a machine-readable medium. In some embodiments, part or all of the computer program may be loaded and / or installed on electronic device 800 via ROM 802. When the computer program is loaded into RAM 803 and executed by processor 801, one or more steps of method 200, etc., described above may be performed. Alternatively, in other embodiments, processor 801 may be configured to perform method 200, etc., by any other suitable means (e.g., by means of firmware).

[0054] The functions described above in this document can be performed at least in part by one or more hardware logic components. For example, exemplary types of hardware logic components that can be used, without limitation, include: field programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), systems-on-a-chip (SoCs), payload programmable logic devices (CPLDs), and so on.

[0055] The program code used to implement the methods of this disclosure may be written in any combination of one or more programming languages. This program code may be provided to a processor or controller of a general-purpose computer, special-purpose computer, or other programmable data processing apparatus, such that when executed by the processor or controller, the program code causes the functions / operations specified in the flowcharts and / or block diagrams to be implemented. The program code may be executed entirely on a machine, partially on a machine, as a standalone software package partially on a machine and partially on a remote machine, or entirely on a remote machine or server.

[0056] In the context of this disclosure, a machine-readable medium can be a tangible medium that may contain or store a program for use by or in conjunction with an instruction execution system, apparatus, or device. A machine-readable medium can be a machine-readable signal medium or a machine-readable storage medium. Machine-readable media can be, but is not limited to, electronic, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatus, or devices, or any suitable combination of the foregoing. More specific examples of machine-readable storage media include electrical connections based on one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination of the foregoing. Furthermore, although operations are depicted in a specific order, this should be understood as requiring that such operations be performed in the specific order shown or in sequential order, or requiring that all illustrated operations be performed to achieve the desired result. In certain environments, multitasking and parallel processing may be advantageous. Similarly, while several specific implementation details are included in the foregoing discussion, these should not be construed as limiting the scope of this disclosure. Certain features described in the context of individual embodiments may also be implemented in combination in a single implementation. Conversely, various features described in the context of a single implementation may also be implemented individually or in any suitable sub-combination in multiple implementations.

[0057] Although the subject matter has been described using language specific to structural features and / or methodological logic, it should be understood that the subject matter defined in the appended claims is not necessarily limited to the specific features or actions described above. Rather, the specific features and actions described above are merely illustrative examples of implementing the claims.

[0058] The various embodiments of this disclosure have been described above. These descriptions are exemplary and not exhaustive, and are not limited to the disclosed embodiments. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described embodiments. The terminology used herein is chosen to best explain the principles, practical application, or technical improvements to the embodiments in the market, or to enable others skilled in the art to understand the embodiments disclosed herein.

Claims

1. A method (200) for an in-vehicle network, the in-vehicle network comprising a master node and a plurality of slave nodes, the method comprising: Verify (210) the synchronization information from the master node in the vehicle network; In response to the failure of the synchronization information to be verified, a (220) verification failure message is sent to at least one of the plurality of slave nodes; In response to the number of verification failure messages meeting a predetermined condition, one of the plurality of slave nodes is switched (230) to become the new master node.

2. The method (200) according to claim 1, wherein the verification (210) from the synchronization information of the master node in the vehicle network includes: Check the correctness of the dynamic identifier in the synchronization information; as well as If the dynamic identifier in the synchronization information is incorrect, it is determined that the synchronization information has failed to be verified.

3. The method (200) according to claim 1, wherein sending (220) verification failure information to at least one of the plurality of slave nodes in response to the failure of the synchronization information verification comprises: In response to the failure of the synchronization information to be verified, one of the multiple slave nodes broadcasts the verification failure information to all other slave nodes.

4. The method (200) according to claim 1, wherein switching (230) one of the plurality of slave nodes to a new master node in response to the number of verification failure messages satisfying a predetermined condition comprises: Obtain at least one of the aforementioned verification failure messages; In response to the number of verification failure messages being greater than or equal to a first predetermined threshold, the failure counter is incremented; In response to the failure counter value being greater than or equal to a second predetermined threshold, one of the plurality of slave nodes is switched to become the new master node.

5. The method (200) according to claim 4, wherein obtaining at least one of the verification failure messages comprises: The verification failure information is obtained by one of the multiple slave nodes from all other slave nodes at predetermined time intervals.

6. The method (200) according to claim 5, wherein incrementing the failure counter in response to the number of verification failure messages being greater than or equal to a first predetermined threshold comprises: Determine the number of verification failure messages from all other slave nodes; In response to the number of verification failure messages being greater than or equal to the first predetermined threshold, the failure counter is incremented.

7. The method (200) according to claim 6, wherein the incrementing failure counter in response to the number of verification failure messages being greater than or equal to a first predetermined threshold further comprises: If the number of verification failure messages is less than the first predetermined threshold, the synchronization message is considered valid; Maintain the original count of the failure counter.

8. The method (200) according to claim 4, wherein the method further comprises: Determine the total number of the master node and all slave nodes; as well as The first predetermined threshold is determined based on the total number of master nodes and all slave nodes.

9. The method (200) according to claim 8, wherein the first predetermined threshold is any integer between half of the total number of master nodes and all slave nodes and the total number of master nodes and all slave nodes.

10. The method (200) according to claim 4, wherein switching one of the plurality of slave nodes to a new master node in response to the value of the failure counter being greater than or equal to a second predetermined threshold comprises: Determine the value of the failure counter; In response to the failure counter value being greater than or equal to a second predetermined threshold, the master node is determined to be a failed master node; In response to the master node being a failed master node, one of the multiple slave nodes is switched to become the new master node.

11. The method (200) according to claim 10, further comprising: Configure the same master node switchover order table for all slave nodes.

12. The method (200) according to claim 11, wherein switching one of the plurality of slave nodes to a new master node in response to the value of the failure counter being greater than or equal to a second predetermined threshold further comprises: Based on the master node switching order table, the slave node that is directly ranked after the failed master node in the master node switching order table will switch the failed master node and become the new master node.

13. An apparatus (700) for an in-vehicle network, the in-vehicle network including a master node and a plurality of slave nodes, the apparatus comprising: The verification unit (710) is configured to verify synchronization information from the master node in the vehicle network; The sending unit (720) is configured to send verification failure information to at least one of the plurality of slave nodes in response to the failure of the synchronization information to be verified; The switching unit (730) is configured to switch one of the plurality of slave nodes to a new master node in response to a predetermined condition being met by the number of verification failure messages.

14. A controller (800), comprising: At least one processor; as well as A memory coupled to the at least one processor and having instructions stored thereon, which, when executed by the at least one processor, cause the controller to perform the method according to any one of claims 1-12.

15. A computer program product comprising machine-executable instructions that, when executed, cause a machine to perform the method according to any one of claims 1-12.

Images