A conflict-aware based vehicular network transactional reconstruction method and apparatus

Abstract

This invention provides a conflict-aware transactional reconstruction method and apparatus for vehicular networks, belonging to the field of vehicular network configuration and scheduling control technology. It solves problems such as multi-node time slot conflicts, cross-device submission asynchrony, and inability to quickly roll back after update failures in existing vehicular network transactional reconstruction processes. The method includes: upon receiving a reconstruction request, generating a set of scheduling update operations based on the reconstruction request and the latest scheduling status table of each device node in the vehicular network; establishing a conflict graph and a dependency graph based on the scheduling update operation set; determining a set of transaction execution layers and the corresponding hierarchical execution sets for each transaction execution layer based on the conflict graph and dependency graph; and performing transactional reconstruction on each device node based on the set of transaction execution layers and the corresponding hierarchical execution sets, including differential patch pre-writing, atomic pointer switching triggered by a unified timestamp, and distributed consistency monitoring.

Description

Technical Field

[0001] This invention relates to the field of vehicle network configuration and scheduling control technology, and in particular to a method and apparatus for transactional reconfiguration of vehicle networks based on conflict awareness. Background Technology

[0002] With the development of intelligent driving and integrated electronic systems, in-vehicle communication networks are gradually evolving from traditional distributed controller area bus architectures to centralized, high-speed, and deterministic communication architectures. To ensure real-time interaction and highly reliable data transmission between different functional domains, more and more in-vehicle systems are adopting communication mechanisms with periodic scheduling and precise time synchronization capabilities, enabling the network to have predictable latency and zero packet loss characteristics. However, in complex in-vehicle applications, network configurations and scheduling tables need to be dynamically updated as tasks change, nodes are added or removed, or security policies are adjusted. This makes maintaining network-wide configuration consistency without interrupting communication a critical issue.

[0003] In existing technologies, commonly used transactional update methods typically involve a central controller uniformly distributing configurations and switching network states through locking, configuring, committing, and unlocking steps. While this method can avoid configuration interruptions within a single device, it still has the following shortcomings in multi-device collaborative scenarios: First, it lacks the identification of dependencies between various atomic operations (such as adding streams, deleting streams, moving forward, and moving backward), which can easily lead to slot conflicts or misaligned slots within the same update cycle; Second, the commit process usually adopts synchronous or sequential commit strategies, which cannot effectively coordinate the execution delays and scheduling deviations of different nodes, resulting in short-term packet loss or transmission delays; Third, existing solutions often rely on overall rollback when updates fail, lacking fine-grained differential rollback mechanisms, making it difficult to maintain the atomicity and consistency of configuration while ensuring real-time performance.

[0004] Therefore, there is an urgent need for a technical solution that can perform conflict perception and dependency analysis on scheduling operations in multi-node vehicular networks, and support step-by-step transactional reconstruction and fast differential rollback, so as to ensure communication real-time performance, reliability and system maintainability during the dynamic update of tasks. Summary of the Invention

[0005] Based on the above analysis, the embodiments of the present invention aim to provide a conflict-aware vehicular network transactional reconfiguration method and apparatus to solve problems such as multi-node time slot conflicts, cross-device submission asynchrony, and inability to quickly roll back after update failure in the existing vehicular network transactional reconfiguration process.

[0006] On one hand, the present invention provides a conflict-aware transactional reconfiguration method for vehicular networks, the method comprising:

[0007] When a reconstruction request is received, a set of scheduling update operations is generated based on the reconstruction request and the latest scheduling status table of each device node in the vehicle network.

[0008] Based on the set of scheduled update operations, establish a conflict graph and a dependency graph;

[0009] Based on the conflict diagram and dependency diagram, determine the set of transaction execution layers and the corresponding hierarchical execution sets for each transaction execution layer;

[0010] Based on the transaction execution layer set and the corresponding layered execution set of each transaction execution layer, the transactional reconstruction of each device node is carried out by differential patch pre-writing, atomic pointer switching triggered by unified timestamp, and distributed consistency monitoring.

[0011] Based on the above solution, the present invention also makes the following improvements:

[0012] Furthermore, the set of scheduling update operations Represented as:

[0013] (1)

[0014] in,

[0015] Indicates the total number of scheduled update operations;

[0016] Indicates the first An instance of a scheduled update operation;

[0017] Indicates the first An operation instance identifier for a scheduled update operation;

[0018] Indicates the first The target time slot location for each scheduling update operation;

[0019] Indicates the first The operation type of each scheduled update operation;

[0020] Indicates the first A set of timing and resource constraint parameters for each scheduled update operation.

[0021] Furthermore, the establishment of the conflict graph and dependency graph involves the following steps:

[0022] Each scheduling update operation in the set of scheduling update operations is treated as an operation node. Based on each operation node and its instantaneous demand for link resources, conflict is determined between pairs of operation nodes, and a conflict graph is established.

[0023] Determine the dependencies between each pair of operation nodes and build a dependency graph.

[0024] Furthermore, the process of determining the set of transaction execution layers and the corresponding hierarchical execution sets for each transaction execution layer is as follows:

[0025] Perform a topological sort on the dependency graph to obtain the transaction execution layer set;

[0026] Each transaction execution layer is scheduled according to the conflict graph to obtain the corresponding layered execution set for the transaction execution layer.

[0027] Furthermore, the topological sorting of the dependency graph is performed by:

[0028] By performing a topological sort on the dependency graph, the execution order of all operation nodes is determined, and operation nodes that can be executed in parallel in the dependency graph are grouped into the same transaction execution layer. All transaction execution layers constitute a transaction execution layer set.

[0029] Furthermore, in each transaction execution layer, hierarchical scheduling is performed based on the conflict graph, and the following is executed:

[0030] In each transaction execution layer, graph coloring is performed based on the conflict graph. Operation nodes that cannot be executed in parallel in the conflict graph are assigned to different color groups to obtain the hierarchical execution set of the corresponding transaction execution layer.

[0031] In the hierarchical execution set, the operation nodes within each color group together constitute a cluster of operations that can be executed in parallel.

[0032] Furthermore, the following approach is used to refactor each device node into a transactional structure:

[0033] Based on the set of transaction execution layers and the corresponding hierarchical execution sets of each transaction execution layer, a transaction commit plan is generated for each transaction execution layer.

[0034] Based on the transaction commit plan of each transaction execution layer, the corresponding device nodes are reconstructed according to the hierarchical execution set, including differential patch pre-writing, atomic pointer switching triggered by unified timestamp, and transactional reconstruction of distributed consistency monitoring.

[0035] Furthermore, the following method is used to perform differential patch pre-writing and unified timestamp-triggered atomic pointer switching on the corresponding device nodes according to the hierarchical execution set:

[0036] Based on the start time of the write-ahead operation of the transaction execution layer, differential patch write-ahead and verification are performed on the corresponding device nodes;

[0037] Based on the effective time of the transaction execution layer switch, the corresponding device node performs an atomic pointer switch.

[0038] Furthermore, the following method is used to perform distributed consistency monitoring on the corresponding device nodes:

[0039] During the atomic pointer switching process, the device node synchronously performs distributed consistency monitoring and initiates a transaction rollback mechanism when an inconsistent state is detected.

[0040] On the other hand, the present invention also provides a conflict-aware vehicular network transactional reconfiguration device, the device comprising:

[0041] The scheduling update operation set generation module is used to generate a scheduling update operation set based on the reconstruction request and the latest scheduling status table of each device node in the vehicle network when a reconstruction request is received.

[0042] The conflict graph and dependency graph construction module builds conflict graphs and dependency graphs based on the set of scheduled update operations;

[0043] The hierarchical scheduling module is used to determine the set of transaction execution layers and the hierarchical execution set corresponding to each transaction execution layer based on the conflict graph and dependency graph.

[0044] The transaction control and rollback module is used to perform transactional reconstruction of each device node based on the transaction execution layer set and the corresponding layered execution set of each transaction execution layer, including differential patch pre-writing, atomic pointer switching triggered by unified timestamp, and distributed consistency monitoring.

[0045] Compared with the prior art, the present invention can achieve at least one of the following beneficial effects:

[0046] The conflict-aware vehicular network transactional reconfiguration method and apparatus provided by this invention have the following beneficial effects:

[0047] 1. Conflict perception and dependency analysis capabilities: By constructing conflict graphs and dependency graphs, it is possible to accurately identify resource conflicts (such as time slot overlap) and execution dependencies (such as operation order constraints) between scheduling update operations, avoiding time slot mismatch and resource contention caused by blind parallel or disordered execution, and providing a data foundation for hierarchical transaction scheduling.

[0048] 2. Layered transactional execution mechanism: The transaction execution layer is divided based on the dependency graph topology sorting, and the parallel scheduling of operation clusters is realized in each layer through the conflict graph coloring. This not only ensures the dependency constraints between operations, but also maximizes the use of the parallel processing capabilities of network resources, effectively improving reconstruction efficiency and shortening the total time of network-wide configuration updates.

[0049] 3. Refined Transaction Control Process: A three-step transaction commit process is adopted, consisting of "differential patch pre-writing - atomic pointer switching - distributed consistency monitoring". The pre-writing phase reduces redundancy overhead and performs verification through differential data transmission, ensuring the accuracy of configuration data; atomic pointer switching enables instantaneous switching between old and new configurations, avoiding intermediate states; and synchronous consistency monitoring can quickly trigger rollback in the event of anomalies, guaranteeing the atomicity and consistency of the reconstruction process.

[0050] 4. Efficient differential rollback mechanism: During the transactional refactoring process, once a distributed consistency anomaly is detected, fine-grained transaction rollback can be achieved based on pre-written differential patches and operation logs, without having to roll back the entire refactoring process. This minimizes the impact of update failures on network services and improves the system's fault tolerance and maintainability.

[0051] 5. Adapting to the dynamic characteristics of vehicular networks: The method design fully considers the mobility of device nodes, the dynamic changes in task load, and the real-time requirements in vehicular networks. Through the design of layered execution and parallel operation clusters, it can flexibly respond to reconstruction requests of different scales and complexities, ensuring that the real-time performance and reliability of communication are not significantly affected during the dynamic adjustment of network status.

[0052] In this invention, the above-described technical solutions can be combined with each other to achieve more preferred combinations. Other features and advantages of this invention will be set forth in the following description, and some advantages may become apparent from the description or be learned by practicing the invention. The objects and other advantages of this invention can be realized and obtained from what is particularly pointed out in the description and drawings. Attached Figure Description

[0053] The accompanying drawings are for illustrative purposes only and are not intended to limit the invention. Throughout the drawings, the same reference numerals denote the same parts.

[0054] Figure 1 A flowchart illustrating the conflict-aware transactional reconfiguration method for vehicular networks provided in this embodiment of the invention;

[0055] Figure 2 A schematic diagram of the structure of the conflict-aware in-vehicle network transactional reconfiguration device provided in an embodiment of the present invention;

[0056] Figure 3 This is another structural schematic diagram of the conflict-aware in-vehicle network transactional reconfiguration device provided in an embodiment of the present invention. Detailed Implementation

[0057] Preferred embodiments of the present invention will now be described in detail with reference to the accompanying drawings, which form part of this application and are used together with the embodiments of the present invention to illustrate the principles of the present invention, but are not intended to limit the scope of the present invention.

[0058] A specific embodiment of the present invention discloses a conflict-aware transactional reconfiguration method for vehicular networks, such as... Figure 1 As shown.

[0059] Step S1: When a reconstruction request is received, a set of scheduling update operations is generated based on the reconstruction request and the latest scheduling status table of each device node in the vehicle network.

[0060] In this embodiment, system and time modeling is performed first. In this embodiment, the vehicular network refers to the network of the vehicular communication system, and the network topology of the vehicular network... Each end system node and switching node in the vehicle communication system is treated as a device node. For the set of all device nodes, This refers to the set of links between all device nodes. In this embodiment, all device nodes in the vehicular network maintain time synchronization through a global clock (which can be achieved by IEEE 802.1AS, GNSS, or IRIG-B signals), and the unified time base is denoted as [reference needed]. In practice, the system operates at a fixed cycle. As the global scheduling unit, all communication tasks are allocated to a discrete time slot set. Above, among which, This is the smallest time slot granularity.

[0061] In practical implementation, each network node maintains its own scheduling status table and periodically sends it to the controller. The scheduling status table is a logical representation of the scheduling table in different scenarios, comprising two types: the main control table and the shadow control table. The types of scheduling status information stored in both are completely identical; the only difference lies in whether they are in effect: the main control table stores currently effective scheduling status information, directly driving the node's real-time communication and gating behavior, covering flow identifiers, port link mapping results, time slot allocation results, gating switch status, priority queue binding relationships, etc.; the shadow control table temporarily stores scheduling status information that is about to take effect, and is not visible to the main control table before the transaction is committed. Before the switch takes effect, it neither participates in scheduling execution nor affects real-time services. The main control table and the shadow control table are mirror images of each other, and atomic replacement of the scheduling table can be achieved through pointer switching. For example, a device node... The saved master control table and shadow control table are represented as follows: , .

[0062] It should be noted that in this embodiment, the communication task, as the scheduled object, includes types such as service flow, periodic control messages, and video streams. The scheduling table is the current mapping result of the communication task, which can be specifically understood as: in which time slot of a certain link a certain communication task is sent. The scheduling update request is a request to change the scheduling table, such as adding a communication task, deleting a communication task, or migrating the time slot of a communication task (i.e., changing the sending time slot).

[0063] In practice, the controller periodically retrieves the latest scheduling status table from each device node to achieve periodic status awareness and operational monitoring. When it receives a reconstruction request (such as adding a flow, deleting a flow, adjusting bandwidth, or migrating a time slot) from the upper-layer system, the controller generates a corresponding set of scheduling update operations based on the reconstruction request and the latest scheduling status table of each device node in the vehicular network. This supports the generation of scheduling update operations and transactional reconstruction. In this embodiment, each scheduling update operation in the set includes a target time slot, an operation type, and additional constraints, as detailed below.

[0064] Set of scheduled update operations Represented as:

[0065] (1)

[0066] in, This indicates the total number of scheduled update operations.

[0067] Indicates the first An instance of a scheduled update operation.

[0068] Indicates the first An operation instance identifier for each scheduling update operation is used to uniquely identify a specific scheduling change operation. It remains unique within the same transaction and is used to perform consistency association and tracking of operations during conflict detection, hierarchical scheduling, transaction commit, and differential rollback.

[0069] Indicates the first The target time slot location for each scheduling update operation; As relative to the scheduling period The discrete-time identifier indicates the specific time slot interval targeted by the current scheduling update operation within the period. Specifically, it corresponds to a starting time slot identifier in the discrete time slot set, but semantically, it can be associated with a continuous time slot interval—this is a conventional understanding in time-division multiplexing scheduling tables. It is regarded as the "anchor of the interval", and the length of the interval is implicitly determined by the scheduling parameters or rules associated with the operation.

[0070] Indicates the first The operation type of each scheduling update operation describes the specific changes that the scheduling update operation makes to the scheduling table. Operation types include adding scheduling items, deleting scheduling items, shifting time slots forward, and shifting time slots backward.

[0071] (2)

[0072] in, , , , These represent, in order, adding a scheduling item, deleting a scheduling item, shifting a time slot forward, and shifting a time slot backward.

[0073] Indicates the first The timing and resource constraint parameter set for each scheduling update operation. This set mainly comprises three parts: the current scheduling state table (i.e., the system status), the refactoring request (i.e., the target constraint), and the inherent capabilities and operational constraints of the network and devices (i.e., the rule base). This set is used to limit the allowed effective time range of this operation, the applicable device nodes or link resources, and the transaction binding or mutual exclusion relationships with other operations. It should be noted that the target time slot position is a specific location, such as slot 3; the effective time range is a range of slots 1-5; if slot 3 conflicts during the operation, it is delayed to another feasible time slot within the effective time range, or a rollback / delayed commit is triggered; this is the significance of conflict awareness + transactionalization.

[0074] Step S2: Based on the set of scheduled update operations, establish a conflict graph and a dependency graph.

[0075] Step S21: Treat each scheduling update operation in the set of scheduling update operations as an operation node, and determine the conflict between pairs of operation nodes based on each operation node and its instantaneous demand for link resources, and establish a conflict graph.

[0076] In practice, the controller iterates through the operation set, determining time slot intervals, resource overlap, and type exclusivity for any two operations to construct a conflict graph. To characterize resource usage, an occupancy function is defined. ,express In the time slot For the link The instantaneous demand for link resources, link This represents the communication link connecting two adjacent device nodes in the network topology of the vehicular network. It also defines the available capacity. , indicating link In the time slot The total resource limit and available capacity provided are descriptions of the link resources themselves, while multiple operations... Whether they can be executed simultaneously depends on all of them. The determination is based on aggregation, as explained below.

[0077] Specifically, conflict determination is performed on each pair of operation nodes, and the following is executed: For operation nodes... , If a link exists With time slot make ,or If it belongs to a mutually exclusive combination (e.g., the same flow "moves forward + moves backward" within the same period), then the operation node is determined. , There are conflicts between the operation nodes. , Conflict between In this embodiment, This means that using the two operations together will exceed the total resource limit; The statement that moving one operation forward and moving the second operation backward would "move to the same time slot" is clearly unacceptable, hence the conflict.

[0078] Step S22: Determine the dependencies between each pair of operation nodes and establish a dependency graph.

[0079] In this embodiment, based on " "and other rules construction" And topological sorting. For example, perform dependency determination on each pair of operation nodes, and execute: if operation node... Examples Execution depends on the operation node Example Execute first, then establish The directed dependency edges. For example, if the operating node... Examples The execution depends on the operation node Example If resources are released first or the time sequence is rearranged, then a directed dependency edge is defined. For example, scenarios such as "delete the old stream before adding the new stream" or "release resources before reallocating them".

[0080] By constructing a conflict diagram Dependency graph The system obtains the complete topological relationships between operations, clarifying the order and mutual exclusion constraints between different update operations. The conflict graph established in this embodiment... Dependency graph , , Let these represent the set of conflicting relationships and the set of dependent relationships, respectively. (Set of conflicting edges) Each edge in This indicates that the two operation nodes have a conflict relationship that cannot be executed in parallel on the same time slot or the same link resource, so an undirected conflict edge is drawn between them; Represents the set of dependent edges, where each edge... Indicates the operation node Execution depends on The preliminary completion.

[0081] Step S3: Based on the conflict graph and dependency graph, determine the set of transaction execution layers and the corresponding hierarchical execution set for each transaction execution layer.

[0082] Step S31: Perform topological sorting on the dependency graph to obtain the transaction execution layer set.

[0083] Specifically, the controller determines the execution order of all operation nodes by performing topological sorting on the dependency graph, and classifies operation nodes in the dependency graph that can be executed in parallel (i.e. have the conditions for parallel execution) into the same transaction execution layer. All transaction execution layers constitute a transaction execution layer set.

[0084] Transaction execution layer collection Represented as:

[0085] (3)

[0086] in, Indicates the first Each transaction execution layer contains a set of scheduled update operations that can be executed in parallel based on a dependency graph; Indicates the total number of transaction execution layers; This indicates that the operation nodes between different transaction execution layers do not overlap, and each operation node belongs to only one transaction execution layer.

[0087] Step S32: Perform hierarchical scheduling based on the conflict graph at each transaction execution layer to obtain the hierarchical execution set of the corresponding transaction execution layer.

[0088] Specifically, the controller performs graph coloring based on the conflict graph at each transaction execution layer, assigning operation nodes that cannot be executed in parallel to different color groups, thereby obtaining a hierarchical execution set for the corresponding transaction execution layer. In this hierarchical execution set, the operation nodes within each color group together constitute a cluster of operations that can be executed in parallel.

[0089] In subsequent processing, operation nodes within the same transaction execution layer can be written and committed in parallel, with strict serial execution between layers. The complexity of the above graph construction and coloring in a typical vehicular network scale can reach [value missing]. It can support online transaction planning.

[0090] Step S4: Based on the transaction execution layer set and the corresponding layered execution set of each transaction execution layer, perform transactional reconstruction of each device node, including differential patch pre-writing, atomic pointer switching triggered by unified timestamp, and distributed consistency monitoring.

[0091] Step S41: Generate a transaction commit plan for each transaction execution layer based on the transaction execution layer set and the corresponding hierarchical execution set.

[0092] This step is used to implement commit timestamps and transaction control, as explained below.

[0093] Define a commit epoch for each transaction execution layer, which represents the corresponding commit timestamp interval. This epoch is used to coordinate the write-ahead and effective times of all operation nodes (i.e., the corresponding scheduled update operations) within the transaction execution layer.

[0094] Specifically, no. Transaction execution layer Submission Era Represented as:

[0095] (4)

[0096] in, For the first Transaction execution layer The pre-write start time is used to indicate the first... Transaction execution layer Each operation node begins writing the scheduling update operation corresponding to the operation node within the current transaction execution layer into the shadow control table of the corresponding device node, but it has not yet taken effect. For the first Transaction execution layer The switching take effect time (i.e., the global commit time) indicates the time when the switch takes effect. Transaction execution layer Each operation node writes the scheduling update operation corresponding to the operation node within the current transaction execution layer into the shadow control table of the corresponding device node. At this time, each device node completes the synchronization operation of switching the pointers between the shadow control table and the main control table, causing the scheduling update to take effect atomically. The time consistency and atomicity guarantee mechanism of transactional refactoring solves the problems of: when these operations take effect together, and how to ensure that all nodes take effect or fail simultaneously as if executing a transaction.

[0097] (5)

[0098] in, It indicates the starting reference time of the transactional refactoring process, which is used to uniformly calculate the commit timestamps of subsequent transaction execution layers. For the first The buffer time between transaction execution layers is used to absorb clock jitter and asymmetric propagation delay (i.e., to absorb clock jitter, management channel asymmetric propagation delay and device execution time deviation, and to ensure that there is no time overlap or commit contention between adjacent transaction execution layers). Indicates the first The maximum device write latency of the transaction execution layer indicates the maximum device write latency of the transaction. The controller calculates the pre-write time for each layer (i.e., the maximum estimated latency required to complete the shadow control table write and confirmation among all involved device nodes, ensuring that all device nodes are ready before the switchover for the scheduling update operation of this transaction execution layer). With submission time It also generates a unified commit timestamp based on global clock synchronization.

[0099] (6)

[0100] in, For device nodes The estimated latency required for writing and acknowledging is the comprehensive estimated latency required for a device node to complete the scheduled update writing, status verification, and acknowledgment feedback in a single transaction execution layer. It serves as the upper bound for the estimated completion time of device-level transactions. Indicates participation in the A collection of device nodes corresponding to each transaction execution layer. The controller broadcasts a unified timestamp to ensure that devices complete the commit within a strict synchronization window.

[0101] (7)

[0102] in, Represents device node Network transmission latency between the controller and the network is used to distribute configuration patches; Represents device node Local processing latency required to perform scheduling configuration write (shadow control table update); Represents device node The delay in returning confirmation information to the controller after the configuration is written.

[0103] (8)

[0104] in, This represents the maximum clock jitter, used to characterize the upper bound of time synchronization errors between distributed devices. The 95th percentile round-trip delay for the southbound channel is used to reflect the communication delay characteristics under high confidence levels. , All of these are safety margins, used to introduce redundancy margins for clock jitter and communication latency, thereby improving the robustness of transaction commits.

[0105] Step S42: Based on the transaction commit plan of each transaction execution layer, perform transactional reconstruction of the corresponding device nodes according to the hierarchical execution set, including differential patch pre-writing, atomic pointer switching triggered by unified timestamp, and distributed consistency monitoring.

[0106] During the transactional reconstruction of corresponding device nodes based on the commit epoch of each transaction execution layer, differential patch pre-writing and verification are performed on the corresponding device nodes according to the pre-write start time of the transaction execution layer; atomic pointer switching is performed on the corresponding device nodes according to the switch effective time of the transaction execution layer to achieve transactional reconstruction. It should be noted that, in this embodiment, the transaction execution layer serves as the atomic commit unit in the scheduling reconstruction process, and the operation clusters within the transaction execution layer serve as the smallest parallel execution unit; operation clusters within the same transaction execution layer can be executed sequentially or in parallel, while different transaction execution layers are strictly executed serially.

[0107] Step S421: Based on the write-begin time of the transaction execution layer, perform differential patch write-beginning and verification on the corresponding device nodes.

[0108] It should be noted that in this embodiment, each device node needs to maintain a dual-table structure: a main scheduling table (currently effective configuration) and a shadow scheduling table (new configuration to be effective soon). The controller only issues differential patches to the devices, not the complete configuration, to improve efficiency. In practice, the controller generates a differential patch set based on the operation set of each transaction execution layer and issues it to the corresponding device node through a management interface (such as NETCONF or RESTCONF). Each device node performs hash verification upon receiving the patch and sends back confirmation information. The write-ahead phase does not affect existing communication.

[0109] Specifically, each device node maintains a dual table. Based on the scheduling update operation corresponding to the operation node, differential patches are only sent to the device nodes. Differential patch Represented as:

[0110] (9)

[0111] in, , Representing device nodes The currently active main scheduling table and shadow scheduling table (which store the new configurations that will soon take effect). After the pre-write is completed, the device sends back a checksum to confirm consistency.

[0112] In this embodiment, a structure for the differential patch item is also defined, including a unique identifier for the scheduling table item, the target timeslot location, a mask field (indicating the field to be updated), an operation type field (add, delete, or modify), and a scheduling table version number or transaction version number (used to distinguish transaction stages and prevent duplicate or out-of-order updates), along with a hash check to ensure patch integrity. Next, the controller generates the corresponding differential patch set based on the operation set of each transaction execution layer and distributes it to the corresponding nodes through a management interface (such as NETCONF or RESTCONF). After receiving the patch, the device performs a hash check and sends the check value back to the controller to confirm patch consistency. This write-ahead phase does not affect currently running real-time services.

[0113] In practice, the differential patch item adopts a structure. It also includes a hash verification: the first item is the unique identifier of the scheduling table entry, used to locate the specific scheduling rule or flow; the second item is the target time slot location corresponding to the scheduling table entry, used to determine the effective time of the rule within the scheduling period; the third item is a mask field, used to indicate which fields in the patch entry need to be updated, supporting partial field modification; the fourth item is an operation type field, used to indicate the operation method of the patch entry, including adding, deleting, or modifying; the fifth item is the scheduling table version number or transaction version number, used to distinguish different transaction commit stages and prevent duplicate execution or out-of-order updates.

[0114] Step S422: Based on the effective time of the transaction execution layer switch, the corresponding device node performs an atomic pointer switch.

[0115] When the switch takes effect at the transaction execution layer (global commit time), each node performs an atomic pointer switch, pointing the main scheduling table pointer to the original shadow scheduling table (making it the new effective configuration), then clears the original shadow scheduling table and increments the version number. The entire process is transparent to the running real-time business.

[0116] Specifically, when arriving At that time, the device node performs an atomic pointer switch:

[0117] (10)

[0118] in, Indicates the version number.

[0119] Step S423: During the atomic pointer switching process, the device node synchronously performs distributed consistency monitoring and initiates the transaction rollback mechanism when an inconsistent state is detected.

[0120] Specifically, during the atomic pointer switching operation performed by the device nodes, the controller continuously monitors distributed consistency and enables the rollback mechanism. If any node is detected to experience queue overflow, a surge in packet loss, or a gating anomaly, a differential rollback mechanism is triggered: the node performs a reverse patch operation, restoring to the previous stable version. If no anomaly is detected, the process proceeds to the next commit level. The specific implementation is explained below.

[0121] In the consistency monitoring window Internally, the controller continuously collects health vectors from the device nodes. Device Nodes Health Vector Represented as:

[0122] (11)

[0123] in, Represents device node The port queue is at a high water level; For device nodes The packet loss count increment represents the device node's... The cumulative number of packet loss events occurring on all ports within the consistency monitoring window.

[0124] (12)

[0125] in, Represents device node At the port Packet loss count; Represents device node The total number of ports.

[0126] This indicates a gating anomaly. If any metric goes out of bounds or a cross-device timing misalignment occurs, a differential rollback is triggered, targeting only changes at the execution layer of this transaction.

[0127] (13)

[0128] In practice, to ensure the idempotency of transaction processing and avoid system state disorder caused by repeated execution, all transactions carry a unique transaction identifier (txid) and a version number (ver) used to distinguish different commit stages within the same transaction.

[0129] When the global clock precisely reaches the designated switchover effective time, all device nodes in the network will synchronously execute pointer switching operations at the hardware level, atomically replacing the shadow control table with the master control table. The latency of the entire switchover process is strictly controlled within 10 microseconds, thus achieving atomic effectiveness of configuration updates and ensuring the consistency and reliability of transactional reconfiguration of the vehicular network. That is, when the global clock reaches the designated... At the same time, each node performs a pointer switching operation, changing the shadow control table. Replace with the main control table This process is completed at the hardware level, with a switching latency of less than 10 microseconds, achieving atomic activation of the configuration.

[0130] It should be noted that this step is the core component of the "conflict awareness → transactional refactoring" process. Its role is to solve the problem of how to generate a transaction execution sequence that is "parallelizable, committable, and rollbackable" after conflict detection. Through the above process, the system can achieve synchronous updates and consistency refactoring of multiple nodes without interrupting communication.

[0131] It should be noted that in this embodiment, the main control table and shadow control table within each device node are stored in independent storage areas. The main control table corresponds to the currently executing scheduling plan, while the shadow control table stores newly written configurations. When the controller issues a differential patch, the shadow control table updates item by item, but the updated content is not yet activated. Upon reaching the preset commit timestamp, the node switches via hardware pointers, mapping the starting address of the shadow control table to the entry address of the main control table, thus making the new configuration effective immediately within a single clock edge. This mechanism eliminates the need to reload data, achieving nanosecond-level switching latency. If an anomaly is detected after switching, the controller issues a rollback command to the node. The node locates the corresponding differential patch based on the transaction number (txid) and performs reverse operations—specifically, deleting newly added items, restoring deleted items, and reversing forward and backward migrations. Since the rollback process only affects changes at this layer, the entire process has extremely short latency and will not affect other layers or unmodified scheduling items.

[0132] During the execution of step S4, the control interface and communication mechanism are set up in the following manner.

[0133] Northbound interface receive intent set The controller has completed its task.

[0134] (14)

[0135] An executable transaction plan is generated. The southbound interface transmits patches and version confirmations via NETCONF / RESTCONF, and OpenFlow / PTS distributes a small number of matching items and enable bits; telemetry (Telemetry / gNMI) feedback is also provided. Gating events and queuing statistics. Before switching, the device completes relative clock deviation calibration; if the deviation exceeds the limit, the controller dynamically delays the switch. And broadcast updates.

[0136] After submission and approval, the vehicle network must meet the instantaneous feasibility constraints:

[0137] (15)

[0138] in The updated resource usage of flow f indicates the resource usage or bandwidth usage of service flow f on link e and time slot τ, and is used to characterize the instantaneous demand of traffic on network resources after scheduling update. This represents the available capacity.

[0139] The upper bound of end-to-end delay is satisfied as follows:

[0140] (16)

[0141] in, This represents the upper bound of the end-to-end latency of the service flow after the scheduling reconfiguration is completed. This represents the upper bound of the end-to-end latency of the business flow before the scheduling refactoring. m represents the number of transaction execution layers involved in this transactional refactoring process. Additional latency perturbation term introduced for the k-th transaction execution layer.

[0142] To achieve low latency switching for devices, through proper configuration. With engineering parameters, it can be made (Typical value) P represents the cycle length of the business flow or scheduling system.

[0143] If the device fails verification during the pre-write phase, the controller postpones its related operations to a new layer. If the operation is successful, other devices will not be affected. If individual devices do not execute the command... Once the switchover is complete, a partial rollback will be triggered only on the relevant nodes based on the conflict domain relationships, avoiding a full network rollback. In the event of a sudden link failure, the system will mark the relevant operations as "delayed commit," temporarily preserving the old configuration and replanning. Temporary protection paths or redundant queues are enabled for critical flows to ensure service continuity. Periodic synchronization and determinism are maintained even in multi-domain control scenarios. After adopting a conflict-aware transactional reconfiguration mechanism, the vehicular network still meets instantaneous feasibility and end-to-end latency constraints on any time slot and link, thus achieving a reconfiguration process with controllable performance and guaranteed determinism.

[0144] In addition, this embodiment also provides the following adaptive optimization strategy.

[0145] Statistical measurements within w consecutive transactions Jitter and queue fluctuations, updated online:

[0146] (17)

[0147] in The observed maximum queue growth is used to quantify the impact of scheduling updates on the system's transient load. This is a gain coefficient used to control the response of inter-layer buffer time to queue growth, preventing parameter oscillations. The system also adaptively adjusts batch size and layer interval based on transaction success rate and rollback frequency to improve convergence speed and robustness.

[0148] As can be seen from the above, under the conflict-aware vehicular network transactional reconfiguration framework, the controller can adaptively adjust the transaction parameters online according to the feedback of the device's operating status, so as to improve the convergence speed, stability and robustness of the system under dynamic conditions.

[0149] This invention proposes a conflict-aware network transactional reconfiguration method. By collecting scheduling information from various end systems and switching nodes in the vehicular network, a time-slot conflict graph and commit dependencies are established to identify sets of operations with mutual exclusion or delay propagation risks within the same update cycle. The controller performs topology sorting and grouping scheduling on atomic operations such as adding, deleting, moving forward, and moving backward to be executed based on conflict relationships, and generates a globally synchronized transaction commit plan. During configuration, each node internally sets up a shadow control table, loads parameters through pre-writing, and achieves seamless activation through pointer switching at specified times. When cross-node latency deviations or slot errors are detected, the system automatically triggers differential rollback and patch replay mechanisms to maintain zero packet loss and timing consistency across the entire network.

[0150] The network transactional reconstruction mechanism proposed in this invention can perform global dependency analysis and orderly submission of operations such as adding, deleting, moving forward, and moving backward without interrupting real-time communication, realize atomic and consistent switching of multi-node configurations, and achieve precise rollback based on differential patching when anomalies occur, thereby improving the determinism and reliability of dynamic scheduling of vehicular networks.

[0151] First, this invention establishes a time-slot conflict graph and dependency graph model on the controller side to formally describe the relationships between various atomic operations, achieving global conflict awareness and visual management of the network scheduling update process. This mechanism can predict potential mutual exclusion or timing risks during the operation generation stage and complete ordered hierarchical scheduling at the orchestration layer through topology sorting and graph coloring. This fundamentally eliminates time-slot conflicts and link misalignment problems caused by overlapping operations among multiple nodes in the same cycle, ensuring the continuity of real-time and critical flows during the update process.

[0152] Secondly, the dual-table shadow structure and global synchronous commit mechanism proposed in this invention enable atomic switching of configurations during scheduling table updates in the vehicular network. The controller calculates the global commit timestamp based on the write and propagation delays of each node, broadcasts a trigger signal under a unified clock reference, and all nodes complete pointer switching simultaneously, thereby achieving instantaneous and consistent switching of network states. Compared with traditional sequential or asynchronous commit methods, this scheme can reduce cross-node latency deviation to within 5% of the original, significantly improving the system's time determinism and synchronization accuracy.

[0153] Furthermore, this invention introduces differential patching and layered rollback mechanisms during transactional updates, enabling fine-grained recovery in case of update failures. The system performs differential rollback only on the layer or node where the anomaly occurred, eliminating the need for overall recovery. This ensures the atomicity of the update operation while significantly reducing recovery time. Experimental and simulation results show that this mechanism can complete a full network rollback within one scheduling cycle (less than 1 ms), reducing recovery latency by approximately 80% compared to traditional overall rollback schemes.

[0154] Furthermore, this invention proposes an adaptive parameter optimization and fault tolerance mechanism. The controller automatically adjusts the inter-layer buffer time and safety margin coefficient by statistically analyzing the results of multiple transaction executions, achieving online parameter optimization. When a local node deviation or sudden link failure is detected, the system can only perform a local rollback or delay commit within the relevant conflict domain, ensuring the overall stable operation of the network. This mechanism significantly enhances the robustness and engineering maintainability of transactional refactoring, enabling the system to maintain a highly reliable operating state in complex automotive scenarios.

[0155] In summary, this invention, through conflict-aware modeling, hierarchical transaction control, dual-table atomic switching, and differential rollback, forms a highly deterministic dynamic reconfiguration scheme for vehicular high-speed networks. It can complete multi-node synchronous updates without interrupting communication, achieving a network configuration reconfiguration effect of "zero packet loss, low latency, and high consistency," demonstrating outstanding technological advancement and application promotion value.

[0156] Embodiment 2 of the present invention provides a conflict-aware vehicular network transactional reconfiguration device, the structural schematic diagram of which is shown below. Figure 2 As shown, the device includes a scheduling update operation set generation module, a conflict graph and dependency graph construction module, a hierarchical scheduling module, and a transaction control and rollback module; wherein,

[0157] The scheduling update operation set generation module is used to generate a scheduling update operation set based on the reconstruction request and the latest scheduling status table of each device node in the vehicle network when a reconstruction request is received.

[0158] The conflict graph and dependency graph construction module builds conflict graphs and dependency graphs based on the set of scheduled update operations;

[0159] The hierarchical scheduling module is used to determine the set of transaction execution layers and the hierarchical execution set corresponding to each transaction execution layer based on the conflict graph and dependency graph.

[0160] The transaction control and rollback module is used to perform transactional reconstruction of each device node based on the transaction execution layer set and the corresponding layered execution set of each transaction execution layer, including differential patch pre-writing, atomic pointer switching triggered by unified timestamp, and distributed consistency monitoring.

[0161] The specific implementation process of this invention can be found in the above method embodiments, and will not be repeated here.

[0162] Since this embodiment is based on the same principle as the above-described method embodiments, this system also has the corresponding technical effects of the above-described method embodiments.

[0163] Another structural diagram of the conflict-aware in-vehicle network transactional reconfiguration device is shown below. Figure 3 As shown, the device includes the following structure: a controller 1, multiple switching nodes 2, and end system nodes 3. The controller 1 is connected to each switching node 2 via a management network and is responsible for global scheduling table planning, conflict detection, transaction layering, and time synchronization control. The switching nodes 2 are interconnected via a data plane to form an in-vehicle Ethernet backbone for forwarding service flows between the end system nodes 3. The end system nodes 3 can be vehicle control units, cameras, radars, or domain controllers, etc., each equipped with a programmable gating scheduling unit to execute the time slot scheduling table issued by the controller.

[0164] Controller 1 internally consists of the aforementioned scheduling update operation set generation module, conflict graph and dependency graph construction module, hierarchical scheduling module, and transaction control and rollback module. Both exchange node 2 and end system node 3 contain a dual-table structure, namely the master control table. and shadow control table The two tables are stored in separate storage areas, and the scheduling table is replaced instantaneously through hardware pointer switching. Each node also includes a monitoring module to collect status information such as port queue depth, packet loss count, and gating events, and reports it to the controller in real time through a telemetry channel.

[0165] At the hardware level, the switching equipment stores data in dual-port BRAM / TCAM. and Pointer switching is synchronized across clock domains via single-cycle registers. The monitoring module records data using counters / event sampling. It controls gating and packet loss, and reports periodically with no more than 5% of the bandwidth. The controller can be deployed in a central gateway or area control unit, and implements a high-precision clock through a high-speed backplane. This framework can be migrated to systems with periodic / gated characteristics, such as automotive Ethernet, industrial Ethernet, or Fibre Channel, supports multi-granular management of ports / queues / streams, and has good scalability and versatility.

[0166] In this embodiment, the device node has the following built-in modules:

[0167] Scheduling and execution module: according to the main control table Control the output of the gated queue;

[0168] Shadow control table storage module: saves write-ahead configurations;

[0169] Pointer switching module: Receives the synchronization signal from the controller and completes the table switching;

[0170] Rollback module: Performs reverse patching operations;

[0171] Monitoring module: Collects and reports queue depth, number of lost packets and gating events.

[0172] In terms of hardware implementation, table data can be stored in dual-port RAM, and pointer switching is implemented by synchronous flip-flops; the monitoring module is implemented using FPGA logic counters, and periodically uploads status information through the management channel. The controller can be implemented based on a general-purpose server or embedded platform, or it can be integrated into the vehicle domain controller.

[0173] The working principle of this invention can be summarized as "layering first, then committing, then monitoring, and rollback capability." By implementing global conflict awareness and dependency modeling in the controller, the feasibility and execution order of all operations are ensured; atomic updates of network state are achieved through unified timestamps and dual-table switching; and a differential rollback mechanism guarantees the speed and locality of anomaly recovery. Simulation results show that this invention can improve the transaction commit success rate to 99.8% in typical automotive Ethernet scenarios, control cross-node latency deviation within 5 microseconds, and achieve an average rollback time of less than 0.8 milliseconds.

[0174] The conflict-aware vehicular network transactional reconfiguration device provided in this invention can achieve multi-node collaborative updates without interrupting communication, significantly improving the determinism, reliability, and maintainability of the vehicular network during dynamic task reconfiguration. It is suitable for high real-time scenarios such as intelligent driving, integrated electronic systems, and industrial control. It is applicable to scenarios requiring dynamic updates and consistency control of scheduling configurations in multi-node vehicular Ethernet or other high real-time bus networks.

[0175] Those skilled in the art will understand that all or part of the processes of the methods described in the above embodiments can be implemented by a computer program instructing related hardware, and the program can be stored in a computer-readable storage medium. The computer-readable storage medium may be a disk, optical disk, read-only memory, or random access memory, etc.

[0176] The above description is only a preferred embodiment of the present invention, but the scope of protection of the present invention is not limited thereto. Any changes or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in the present invention should be included within the scope of protection of the present invention.

Claims

1. A conflict-aware transactional reconfiguration method for vehicular networks, characterized in that, The method includes: When a reconstruction request is received, a set of scheduling update operations is generated based on the reconstruction request and the latest scheduling status table of each device node in the vehicle network. Based on the set of scheduled update operations, establish a conflict graph and a dependency graph; Based on the conflict diagram and dependency diagram, determine the set of transaction execution layers and the corresponding hierarchical execution sets for each transaction execution layer; Based on the transaction execution layer set and the corresponding layered execution set of each transaction execution layer, the transactional reconstruction of each device node is carried out by differential patch pre-writing, atomic pointer switching triggered by unified timestamp, and distributed consistency monitoring. The following method is used to perform distributed consistency monitoring on the corresponding device nodes: During the atomic pointer switching process, the device node synchronously performs distributed consistency monitoring and initiates a transaction rollback mechanism when an inconsistent state is detected.

2. The conflict-aware transactional reconfiguration method for vehicular networks according to claim 1, characterized in that, The set of scheduling update operations Represented as: （1） in, Indicates the total number of scheduled update operations; Indicates the first An instance of a scheduled update operation; Indicates the first An operation instance identifier for a scheduled update operation; Indicates the first The target time slot location for each scheduling update operation; Indicates the first The operation type of each scheduled update operation; Indicates the first A set of timing and resource constraint parameters for each scheduled update operation.

3. The conflict-aware transactional reconfiguration method for vehicular networks according to claim 2, characterized in that, To establish the conflict graph and dependency graph, execute: Each scheduling update operation in the set of scheduling update operations is treated as an operation node. Based on each operation node and its instantaneous demand for link resources, conflict is determined between pairs of operation nodes, and a conflict graph is established. Determine the dependencies between each pair of operation nodes and build a dependency graph.

4. The conflict-aware transactional reconfiguration method for vehicular networks according to claim 3, characterized in that, The process involves determining the set of transaction execution layers and the corresponding hierarchical execution sets for each transaction execution layer, and then executing: Perform a topological sort on the dependency graph to obtain the transaction execution layer set; Each transaction execution layer is scheduled according to the conflict graph to obtain the corresponding layered execution set for the transaction execution layer.

5. The conflict-aware transactional reconfiguration method for vehicular networks according to claim 4, characterized in that, The topological sorting of the dependency graph is performed as follows: By performing a topological sort on the dependency graph, the execution order of all operation nodes is determined, and operation nodes that can be executed in parallel in the dependency graph are grouped into the same transaction execution layer. All transaction execution layers constitute a transaction execution layer set.

6. The conflict-aware transactional reconfiguration method for vehicular networks according to claim 5, characterized in that, The process involves hierarchical scheduling at each transaction execution layer based on the conflict graph, and execution as follows: In each transaction execution layer, graph coloring is performed based on the conflict graph. Operation nodes that cannot be executed in parallel in the conflict graph are assigned to different color groups to obtain the hierarchical execution set of the corresponding transaction execution layer. In the hierarchical execution set, the operation nodes within each color group together constitute a cluster of operations that can be executed in parallel.

7. The conflict-aware transactional reconfiguration method for vehicular networks according to claim 6, characterized in that, The following method was used to refactor each device node into a transactional structure: Based on the set of transaction execution layers and the corresponding hierarchical execution sets of each transaction execution layer, a transaction commit plan is generated for each transaction execution layer. Based on the transaction commit plan of each transaction execution layer, the corresponding device nodes are reconstructed according to the hierarchical execution set, including differential patch pre-writing, atomic pointer switching triggered by unified timestamp, and transactional reconstruction of distributed consistency monitoring.

8. The conflict-aware transactional reconfiguration method for vehicular networks according to claim 7, characterized in that, The following method is used to perform differential patch pre-writing and unified timestamp-triggered atomic pointer switching on the corresponding device nodes according to the hierarchical execution set: Based on the start time of the write-ahead operation of the transaction execution layer, differential patch write-ahead and verification are performed on the corresponding device nodes; Based on the effective time of the transaction execution layer switch, the corresponding device node performs an atomic pointer switch.

9. A conflict-aware vehicular network transactional reconfiguration device, characterized in that, The device includes: The scheduling update operation set generation module is used to generate a scheduling update operation set based on the reconstruction request and the latest scheduling status table of each device node in the vehicle network when a reconstruction request is received. The conflict graph and dependency graph construction module builds conflict graphs and dependency graphs based on the set of scheduled update operations; The hierarchical scheduling module is used to determine the set of transaction execution layers and the hierarchical execution set corresponding to each transaction execution layer based on the conflict graph and dependency graph. The transaction control and rollback module is used to perform transactional reconstruction of each device node based on the transaction execution layer set and the corresponding layered execution set of each transaction execution layer, including differential patch pre-writing, atomic pointer switching triggered by unified timestamp, and distributed consistency monitoring. Among them, the distributed consistency monitoring of the corresponding device nodes is performed in the following way: the device node performs distributed consistency monitoring synchronously during the atomic pointer switching process, and initiates the transaction rollback mechanism when an inconsistent state is detected.

Images