A route data updating method and device and vehicle

Abstract

The application discloses a route data updating method and device and a vehicle, relates to the technical field of data processing, and can accurately identify node failure states by introducing multi-source dynamic data for cross verification and breaking through the dependence of a traditional static library. Based on the failure determination result and the validity state of the updated version, the threshold of route version access is established to prevent the possibility that an expired version is misused by a downstream system. Meanwhile, hierarchical return is performed in combination with node importance, and an alternative scheme is actively intercepted and recommended when a core node fails. Through the above technical means, the application realizes real-time dynamic verification and timely updating of route data, and greatly reduces navigation accidents and operating costs caused by information lag.

Description

Technical Field

[0001] This application relates to the field of data processing technology, and in particular to a method, apparatus and vehicle for updating route data. Background Technology

[0002] In scenarios such as smart mobility, logistics scheduling, and autonomous driving testing, route data (or road books) serves as the core operational carrier, carrying key information such as route planning, node information, and traffic restriction rules.

[0003] Currently, existing route data management systems generally adopt a static storage and manual periodic update model, lacking the ability to automatically respond to real-time environmental changes. When dynamic events such as road closures, changes in traffic restriction policies, or closure of service facilities occur, the system cannot automatically detect and verify the validity of the data, resulting in a large amount of outdated or erroneous information in the published route data.

[0004] This method of relying on manual inspection is not only inefficient and slow to respond, but also lacks a strong binding mechanism between version validity and content status. Expired route data versions may still be called by downstream systems, which may lead to navigation errors, trip delays or even safety risks.

[0005] Therefore, existing technologies suffer from problems such as route data becoming invalid due to dynamic environmental changes, delayed updates, and the easy misuse of outdated versions. Summary of the Invention

[0006] In view of the above problems, this application provides a method, apparatus, and vehicle for updating route data, so as to achieve real-time dynamic verification and timely updating of route data. The specific solution is as follows:

[0007] The first aspect of this application provides a method for updating route data, including:

[0008] Acquire multi-source dynamic data corresponding to route nodes in the target route data;

[0009] Cross-validation is performed based on multi-source dynamic data and preset spatiotemporal constraint rules to determine the failure status of route nodes in the target route data;

[0010] Update the version validity status of the target route data based on the failure status of route nodes;

[0011] In response to a query request for target route data, based on the version validity status and the importance of route nodes, a tiered return is performed to output the updated target route data.

[0012] In one possible implementation, the pre-defined spatiotemporal constraint rules include a time window and a spatial boundary region;

[0013] Cross-validation is performed based on multi-source dynamic data and preset spatiotemporal constraint rules to determine the failure status of route nodes in the target route data, including:

[0014] When the first data source in the multi-source dynamic data indicates that the status of the route node has changed, obtain the verification data from other independent data sources within the time window and spatial boundary area corresponding to the route node;

[0015] When the verification data meets the preset multi-source confirmation conditions, the route node is determined to be in a failed state.

[0016] In one possible implementation, the multi-source dynamic data includes at least two of the following: government open data sources, commercial map open data sources, vertical industry data sources, and user feedback data sources.

[0017] Acquire multi-source dynamic data corresponding to route nodes in the target route data, including:

[0018] In response to at least one of the following trigger signals: timed batch verification command, single-source event push signal, or user feedback signal, acquire at least two of the following data sources: government information disclosure data source, commercial map information disclosure data source, vertical industry data source, and user feedback data source.

[0019] In one possible implementation, the version validity status of the target route data is updated based on the failure status of route nodes, including:

[0020] Generate a unique version identifier for the target route data and bind the unique version identifier to the full node status snapshot of the target route data;

[0021] When there are core route nodes in the target route data that are in a failed state, the version validity status is updated to a frozen state to intercept calls to the current version of the target route data and trigger the closed-loop processing flow for failed nodes.

[0022] In one possible implementation, the closed-loop processing flow for failed nodes includes:

[0023] The reverse traversal includes the associated route data of core route nodes that are in a failed state;

[0024] Search for similar points of interest within a preset geographical area as alternative nodes;

[0025] If a compliant alternative node is found, the node data of the associated route data and the corresponding preset spatiotemporal constraint rules are updated using the alternative node, and the full node validity check is re-executed to generate a new version of the route data.

[0026] If no compliant alternative node is found, the associated route data will be marked as obsolete and archived.

[0027] In one possible implementation, in response to a query request for target route data, a tiered return is performed based on version validity status and the node importance of route nodes to output updated target route data, including:

[0028] If the version validity status is invalid, refuse to return the current version and guide the user to obtain the latest valid version;

[0029] If the version validity status is valid, then the node failure level is checked based on the node importance:

[0030] When a core route node fails, an invalid message and alternative route data are returned.

[0031] When a non-core route node fails, degraded route data is returned, and the failed node information is marked in the degraded route data;

[0032] When all route nodes are normal, return complete route data.

[0033] In one possible implementation, core route nodes include essential route nodes and critical supply nodes, while non-core route nodes include detour route nodes.

[0034] The downgraded route data includes the basic navigation path, as well as the location coordinates and risk warning labels corresponding to the failed nodes.

[0035] In one possible implementation, the entire lifecycle states of target route data include draft state, pending verification state, valid state, pending rights confirmation state, frozen state, and archived state;

[0036] The entire lifecycle state transition is automatically triggered based on the verification results and version release actions, and the query interface is only open to target route data that is in a valid state.

[0037] A second aspect of this application provides a route data updating device, comprising:

[0038] The acquisition unit is used to acquire multi-source dynamic data corresponding to the route nodes in the target route data;

[0039] The verification unit is used to perform cross-validation based on multi-source dynamic data and preset spatiotemporal constraint rules to determine the failure status of route nodes in the target route data.

[0040] The update unit is used to update the version validity status of the target route data based on the failure status of the route nodes;

[0041] The feedback unit is used to respond to the query request for target route data, and performs hierarchical return to output the updated target route data based on the version validity status and the node importance of the route nodes.

[0042] A third aspect of this application provides a vehicle including at least one processor and a memory connected to the processor, wherein:

[0043] Memory is used to store computer programs;

[0044] The processor is used to execute a computer program to enable the vehicle to implement the route data update method of the first aspect or any implementation thereof.

[0045] By employing the aforementioned technical solutions, the route data update method, apparatus, and vehicle provided in this application, through the introduction of multi-source dynamic data for cross-validation, overcome the dependence on traditional static libraries and can accurately identify node failure states. Based on the failure determination results and the validity status of the updated version, an admission threshold for route versions is established, preventing the possibility of expired versions being misused by downstream systems. Simultaneously, tiered return is performed based on node importance, proactively intercepting and recommending alternative solutions when core nodes fail. Through these technical means, this application achieves real-time dynamic verification and timely updates of route data, significantly reducing navigation accidents and operational costs caused by information lag. Attached Figure Description

[0046] The above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent when taken in conjunction with the accompanying drawings and the following detailed description. Throughout the drawings, the same or similar reference numerals denote the same or similar elements. It should be understood that the drawings are schematic, and the originals and elements are not necessarily drawn to scale.

[0047] Figure 1 A flowchart illustrating a method for updating route data provided in this application;

[0048] Figure 2 Example diagram of the entire lifecycle of the route book version provided in this application;

[0049] Figure 3 Example flowchart of the route book verification and publication provided for this application;

[0050] Figure 4 A schematic diagram of the structure of the route data updating device provided in this application. Detailed Implementation

[0051] The embodiments of this application are described below with reference to the accompanying drawings. The terminology used in the implementation section of this application is for explaining specific embodiments only and is not intended to limit the scope of this application.

[0052] As will be known to those skilled in the art, with the development of technology and the emergence of new scenarios, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0053] The terms "first," "second," etc., used in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such terms are interchangeable where appropriate; this is merely a way of distinguishing objects with the same attributes in the embodiments of this application. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion, so that a process, method, system, product, or apparatus that comprises a series of elements is not necessarily limited to those elements, but may include other elements not explicitly listed or inherent to those processes, methods, products, or apparatuses.

[0054] In the field of smart mobility and logistics scheduling, existing route data management systems generally adopt a static storage and manual periodic inspection model. Once generated, route books are stored in a fixed version, lacking the ability to perceive dynamic changes in the environment. When events such as temporary road closures, adjustments to traffic restriction policies, or the shutdown of POI (Point of Interest) facilities, such as gas stations and charging stations, occur, the system cannot automatically capture these changes. Relying on manual inspection is not only slow in response but also has a high rate of missed detections.

[0055] Furthermore, even if the data has expired in the existing technology, the downstream system may still misuse the old version due to caching or calling logic errors, which may lead to navigation deviation, trip interruption or even safety accidents.

[0056] In view of this, this application provides a method, apparatus and vehicle for updating route data. By introducing multi-source dynamic data to perform real-time cross-validation of route nodes, the validity status of the version is automatically triggered based on the validation results, and hierarchical return is implemented in the query stage based on the importance of the nodes, thereby realizing automated management of the entire life cycle of route data and fundamentally solving the problems of untimely route data updates and misuse of expired versions.

[0057] See Figure 1 The present application provides a flowchart illustrating a method for updating route data, as shown below. Figure 1 As shown, the method for updating this route data includes the following steps:

[0058] Step 101: Obtain multi-source dynamic data corresponding to the route nodes in the target route data.

[0059] It should be noted that target route data usually refers to structured route data used in scenarios such as smart mobility, logistics scheduling, or autonomous driving testing. It includes route planning, node information, and traffic restriction rules.

[0060] Multi-source dynamic data is not limited to traditional commercial map data, but also includes comprehensive information flows covering heterogeneous data sources.

[0061] For example, multi-source dynamic data can include government information data sources, such as real-time traffic APIs and traffic restriction notices released by traffic management departments, public data sources of commercial maps, such as event push services from map service providers, vertical industry data sources, such as equipment status interfaces of charging pile operators, gas station operation system interfaces, and user feedback data sources, such as client-side anomaly reporting channels.

[0062] This step, by acquiring the aforementioned multiple types of data sources, breaks through the limitations of traditional solutions that rely solely on single map data or manual inspections. It fundamentally solves the problem of information update lag and coverage blind spots caused by a single data perception dimension, providing sufficient and multi-dimensional evidence for subsequent validity verification.

[0063] Step 102: Based on multi-source dynamic data and preset spatiotemporal constraint rules, cross-validation is performed to determine the failure status of route nodes in the target route data.

[0064] It should be noted that the core of cross-validation lies in using spatiotemporal constraint rules to align and filter multi-source data, rather than simply comparing text keywords.

[0065] The preset spatiotemporal constraint rules can be the time window and spatial boundary area for data to take effect. Only when multiple independent data sources indicate that the status of a certain route node has changed within the same time window and the same spatial range will the node be determined to be in a failed state.

[0066] For example, when a map service provider pushes information about the closure of a certain road segment, the system will not immediately accept it, but will further search for traffic control announcements or other user reports within the corresponding geofence of the road segment in the current time period to verify it.

[0067] This spatiotemporal cross-validation effectively filters out noise caused by sensor failures, temporary signal interference, or single-point data errors, significantly improving the accuracy and robustness of failure determination, avoiding frequent invalidation of route data due to misjudgment, and ensuring the reliability of data updates.

[0068] Step 103: Update the version validity status of the target route data based on the failure status of the route nodes.

[0069] It should be noted that the version validity status is a system-level attribute that is strongly tied to the route data content, rather than just a regular label or note attached to the data surface.

[0070] Specifically, when step 102 determines that there are route nodes in the target route data that are in a failed state, the route data management system (hereinafter referred to as the system) in this application will perform differentiated processing based on the importance of the failed nodes:

[0071] If the failed node is a core route node, such as a necessary route node or a critical supply node, the current version validity status will be automatically updated to a frozen or invalid state, directly blocking all requests for route data of that version, forcing downstream business systems to be unable to obtain expired data containing fatal risks; if the failed node is a non-core route node, such as a detour point node, the version validity status will not be adjusted for the time being, but only the node will be marked as abnormal and the closed-loop processing procedure for failed nodes will be triggered. The version status will be re-evaluated based on the repair results, taking into account both data security and service continuity.

[0072] When step 102 determines that there are core route nodes in the target route data that are in an invalid state, the system will automatically update the current version validity status of the target route data to a frozen or invalid state. This update directly intercepts requests to access the current version of the target route data, forcing downstream business systems to be unable to obtain expired data content.

[0073] Compared to existing technologies that rely solely on marking expired data but allow continued reading, this embodiment fundamentally blocks the flow path of expired versions in the production environment by hard-binding content validity with version availability. This completely solves the risk of misuse of expired data caused by chaotic version management, ensuring the security and data consistency of business operations.

[0074] Step 104: In response to the query request for target route data, based on the version validity status and the node importance of the route nodes, perform hierarchical return to output the updated target route data.

[0075] It should be noted that tiered return is a differentiated service based on node importance, which can balance the relationship between data security bottom line and service availability.

[0076] Optionally, upon receiving a query request, the validity status of the target route data version is first verified. Specifically, it determines whether the version of the target route data to be invoked is valid. If the version to be invoked is in a frozen, archived, or other invalid state, the specific content of the current version is directly refused to be returned. At the same time, the caller is actively guided to obtain the latest valid version, blocking the flow path of expired data from the service entry point. Specifically, when core route nodes, such as essential road segment nodes and critical supply nodes that play a decisive role in the basic traffic capacity of the route, fail, i.e., when the version to be invoked is invalid, an invalid prompt message and alternative route data in the same area are returned to avoid vehicles entering impassable sections or encountering the risk of supply interruption.

[0077] If the version to be invoked is in a valid state, the failure level is further determined based on the importance of the node. It can be understood that a valid state means that the target route data contains either non-core route nodes that are in a failed state or no route nodes that are in a failed state.

[0078] Specifically, the failure level of a node is determined based on its importance, and the response content is output differently accordingly:

[0079] When the target route data contains non-core route nodes that are in a failed state, the system returns degraded route data, marking the location coordinates and risk warning labels of the failed nodes, allowing upstream business systems to make autonomous decisions on whether to continue using the data based on the actual scenario. When all route nodes are in a normal state, the system returns complete route data containing all node information, spatiotemporal constraint rules, and version hashes, supporting the normal operation of downstream businesses.

[0080] In summary, the route data update method provided in this application, by introducing multi-source dynamic data for cross-validation, overcomes the dependence on traditional static libraries and can accurately identify node failure states. Based on the failure determination results and the validity status of the updated version, an admission threshold for route versions is established, preventing the possibility of expired versions being misused by downstream systems. Simultaneously, tiered return is performed based on node importance, proactively intercepting and recommending alternative solutions when core nodes fail. Through the above technical means, this application achieves real-time dynamic verification and timely updates of route data, significantly reducing navigation accidents and operational costs caused by information lag.

[0081] Based on the first embodiment described above, this embodiment further details the spatiotemporal constraint cross-validation and multi-source data acquisition process as a second embodiment.

[0082] As one implementation method, the preset spatiotemporal constraint rules include time windows and spatial boundary regions.

[0083] Specifically, time windows are used to limit the validity period of data. They can take the form of fixed start and end dates, such as a traffic restriction rule being valid from June 1 to June 30, 2024, or they can include cyclical periods, such as the morning rush hour from Monday to Friday, or temporary single periods, such as temporary control periods during events.

[0084] The spatial boundary area is constructed based on geofencing technology, supporting point, line, or polygonal areas to precisely define the physical influence range of route nodes.

[0085] By introducing dual constraints of time and space, the system can strictly lock the comparison range within a specific spatiotemporal context when performing cross-validation, thereby effectively filtering out invalid events that are similar in text but have expired in time or are unrelated in space, significantly reducing the misjudgment rate caused by environmental background noise.

[0086] As one implementation method, cross-validation is performed based on multi-source dynamic data and preset spatiotemporal constraint rules to determine the failure status of route nodes in the target route data, including:

[0087] When the first data source in the multi-source dynamic data indicates that the status of the route node has changed, verification data from other independent data sources are obtained within the time window and spatial boundary area corresponding to the route node; when the verification data meets the preset multi-source confirmation conditions, the route node is determined to be in an invalid state.

[0088] Specifically, the other independent data sources here emphasize the physical isolation of the data source and the heterogeneity of the collection methods to prevent the amplification of systematic biases in data from the same source.

[0089] Regarding the multi-source confirmation condition, although the preferred embodiment of this application stipulates that the change is deemed invalid only if at least two independent data sources confirm it, this is not the only implementation method. In other embodiments, this condition can also be extended to a comprehensive scoring model based on weighted confidence, that is, different weights are assigned according to the authority level of each data source, and the confirmation condition is considered to be met when the total weighted confidence score exceeds a preset threshold.

[0090] This approach ensures improved accuracy through multi-source verification in conventional scenarios while retaining the flexibility to adjust the judgment logic in specific high-trust source scenarios, thus enhancing the robustness and adaptability of the system.

[0091] As one implementation method, multi-source dynamic data includes at least two of the following: government information disclosure data sources, commercial map information disclosure data sources, vertical industry data sources, and user feedback data sources.

[0092] It should be noted that government data sources typically connect to the real-time traffic API or traffic restriction announcement interface of traffic management departments, possessing the highest authority and legal validity; commercial map data sources mainly connect to the event push service of map service providers, covering high-frequency dynamic information such as road construction, congestion, and POI operating status, with strong timeliness; vertical industry data sources target specific business scenarios, such as the equipment status interface of charging pile operators, gas station operation systems, or scenic spot ticketing interfaces, providing refined facility-level status data; user feedback data sources come from the client's anomaly reporting channel, serving as a supplement to the above structured data and capable of capturing long-tail or sudden non-standard issues.

[0093] This embodiment constructs a multi-dimensional perception network by combining at least two types of data sources mentioned above. By leveraging the complementary advantages of different data sources in terms of coverage, timeliness, and granularity, it solves the technical problem of blind spots or lag in single data sources.

[0094] As one implementation method, acquiring multi-source dynamic data corresponding to route nodes in the target route data includes:

[0095] In response to at least one of the following trigger signals: timed batch verification command, single-source event push signal, or user feedback signal, acquire at least two of the following data sources: government information disclosure data source, commercial map information disclosure data source, vertical industry data source, and user feedback data source.

[0096] It should be noted that these three trigger signals constitute a parallel triggering form that combines active sensing and passive response.

[0097] Specifically, scheduled batch verification commands can be automatically triggered during off-peak business periods, such as early morning each day, to perform a comprehensive inspection of all route data, ensuring that expired data is cleaned regularly even without external event input; single-source event push signals can be proactively sent by external data sources in real time, enabling a second-level response to sudden traffic incidents or facility failures; user feedback signals can be manually triggered by end users when they discover anomalies, incorporating human perception into the data update closed loop.

[0098] These three methods complement each other, ensuring the freshness of route data and enabling rapid response to emergencies, thereby achieving seamless monitoring and dynamic maintenance of route data throughout its entire lifecycle.

[0099] Based on the first embodiment, this embodiment further details the version identifier binding and freeze status update process as the third embodiment.

[0100] As one implementation method, updating the version validity status of the target route data based on the failure status of route nodes includes: generating a unique version identifier for the target route data and binding the unique version identifier to the full node status snapshot of the target route data.

[0101] It should be noted that the unique version identifier can be used to accurately distinguish the digital fingerprints of different iterations of the target route data. It can be generated by using hash algorithms such as SHA-256 and MD5 to calculate the core content fields of the target route data, or it can be a globally unique serial number generated by the system according to preset encoding rules.

[0102] A full node status snapshot specifically refers to the set of status information of all route nodes in the target route data at the time the version identifier is generated, including but not limited to the geographical location, operating hours, traffic rules and current validity verification results of each node.

[0103] By binding and storing a unique version identifier with a full node state snapshot, a strong association is established between the version ID and the data content, so that each version identifier uniquely corresponds to a definite and tamper-proof data state.

[0104] This binding method ensures the traceability and integrity of route versions from the data structure level, preventing dirty data issues such as new version numbers but outdated content, or content that does not match the version number. It provides a reliable data benchmark for subsequent version verification and graded return.

[0105] As one implementation method, when there are core route nodes in the target route data that are in a failed state, the version validity status is updated to a frozen state to intercept calls to the current version of the target route data and trigger the closed-loop processing flow for failed nodes.

[0106] It should be noted that the freeze status is not merely a change in a status field in the database, but a control action with system-level mandatory force.

[0107] Optionally, when the system detects that any route node has failed and sets the version validity status to frozen, it will immediately intercept the request at the data access interface layer or gateway layer. Any request to read, download, or navigate planning for the target route data of that version will be directly rejected or redirected, and no data content containing the failed node will be returned.

[0108] This is fundamentally different from the traditional technical solution that simply labels data as expired but still allows downstream systems to read and make their own judgments.

[0109] Traditional technical solutions rely on all callers correctly implementing the filtering logic. If a caller fails to make a judgment, expired data will be misused. However, the freezing method used in this embodiment is a hard block implemented on the data server side. No matter how the downstream system requests, it cannot obtain the effective payload of the frozen version, thereby fundamentally eliminating the risk of expired data flow caused by client logic defects or cache delays.

[0110] Meanwhile, updating the version validity status to frozen is also a necessary prerequisite for triggering the closed-loop processing flow of failed nodes. Only when the version is officially frozen will the system start subsequent repair operations such as reverse traversal, replacement node retrieval and new version generation, ensuring the orderliness and atomicity of the data processing flow and avoiding concurrency conflicts or data inconsistency problems that may be caused by modifying the data while it is still available.

[0111] Through the collaborative work of the aforementioned version identifier binding and freeze status update methods, a complete defense line from data ownership confirmation to risk isolation is built to ensure the absolute security and real-time effectiveness of data circulating in the production environment.

[0112] Based on the third embodiment, when the version validity status of the target route data is updated to a frozen state, the system will automatically trigger the closed-loop processing flow for the failed node to achieve automated repair or safe offline removal of abnormal data, as the fourth embodiment.

[0113] As one implementation method, the closed-loop processing flow for failure nodes includes:

[0114] The reverse traversal includes the associated route data of core route nodes that are in a failed state.

[0115] It should be noted that in actual operation, the same route node, such as a highway service area or key intersection, is often referenced by multiple different target route data. Therefore, when the node is determined to be invalid, it is not enough to only process the single route that triggered the verification.

[0116] This application uses a pre-built inverted index of nodes and routes to quickly locate all associated route data that references the failed node, and then includes this associated route data in a queue to be processed.

[0117] This reverse traversal method ensures the comprehensiveness of data repair, avoiding the situation where some downstream businesses are still using old data containing failed nodes due to missing related routes, thus preventing global data inconsistency caused by partial repair.

[0118] As one implementation method, the closed-loop processing flow for failure nodes also includes:

[0119] Search for similar points of interest within a preset geographical area as alternative nodes.

[0120] It should be noted that the preset geographical range can be dynamically configured according to route type and business needs. For example, for urban delivery routes, the search radius can be set to 1 to 3 kilometers; for long-distance trunk logistics, the search radius can be extended to 5 to 10 kilometers or a buffer zone at a certain distance before and after the route.

[0121] Matching similar points of interest requires not only that the POI category labels be consistent, such as both being charging stations or gas stations, but also that the service attributes be similar, such as supporting the same charging interface standard or fuel grade.

[0122] This application, by accurately screening alternative candidate sets in the spatiotemporal dimensions, can maintain the rationality of route planning as much as possible while ensuring that the original service functions of the route are not lost, and avoid excessive detours or service degradation caused by blind replacement.

[0123] As one implementation method, after retrieving candidate alternative nodes, the system also needs to perform a compliance judgment, and only alternative nodes that are judged to be compliant will be adopted.

[0124] It should be noted that compliance means that the alternative node is in a normal and available state at the current point in time and has not been affected by any new restrictions or regulations.

[0125] For example, during implementation, multi-source dynamic data is called again to verify the real-time business status, equipment online rate, and recent user reviews of the replacement node, excluding nodes that, although geographically suitable, are actually closed or frequently malfunctioning. This secondary verification step effectively prevents a vicious cycle of invalid replacements of invalid nodes, ensuring the effectiveness of the repair.

[0126] As one implementation method, if a compliant alternative node is found, the node data of the associated route data and the corresponding preset spatiotemporal constraint rules are updated using the alternative node, and the full node validity check is re-executed to generate a new version of the route data.

[0127] Specifically, the replacement operation is not a simple coordinate point swapping, but rather a coordinated update of the entire data structure. Specifically, it writes the detailed information of the replacement node into the associated route data and automatically adjusts the relevant spatiotemporal constraint rules based on the new node's geographical location and attributes, such as updating the estimated arrival time window for routes passing through the node and adjusting the surrounding geofence range. Furthermore, after the replacement is completed, a new version is not released directly; instead, the full node validity verification process described in the second embodiment is forcibly re-executed.

[0128] The specific reason is that the introduction of new nodes may change the travel logic or timeliness characteristics of the entire route, and may even create new conflicts with other nodes. Only after a full re-verification confirms that all nodes on the entire route are valid and the rules are consistent under the new configuration will a new version identifier be generated and released online. This process effectively ensures the reliability of data quality after automatic repair.

[0129] As one implementation method, if no compliant alternative node is found, the associated route data is marked as obsolete and archived.

[0130] Specifically, if no usable alternative can be found within the preset range, or if all candidate nodes fail the compliance judgment, it means that the route is no longer repairable under the current environment.

[0131] At this point, this application will change the status of the associated route data to obsolete and move it to the historical archive for auditing and tracing. At the same time, it will immediately stop all external query and service interfaces for that route.

[0132] In addition, a detailed report containing the cause of the failure, attempted retrieval records, and the final handling result will be generated and notified to operations management personnel via message queues or emails.

[0133] It is understandable that, although this embodiment emphasizes automated processing, in practical applications, manual intervention can exist in parallel as a fallback measure. For example, before or after the system determines that the system should be discarded, operators can still manually specify special alternatives or decide to force retention. The system will receive the manual instructions and trigger the subsequent re-verification process.

[0134] The above approach ensures both efficiency in processing massive amounts of data and flexibility in handling extremely complex scenarios, achieving the best balance between overall robustness and business continuity.

[0135] Based on the first embodiment, this embodiment further details the specific implementation of the hierarchical return strategy and node importance, as the fifth embodiment.

[0136] As one implementation method, in response to a query request for target route data, a tiered return is performed based on the version validity status and the node importance of the route nodes to output the updated target route data.

[0137] Specifically, this tiered return method is not a simple Boolean value judgment, but provides differentiated service responses based on data health, aiming to solve the rigid service defects in traditional solutions.

[0138] Optionally, when performing hierarchical return, this application first checks the version validity status. If the version validity status is determined to be invalid, such as expired, frozen, or archived, the application refuses to return the specific content of the current version and actively guides the caller to obtain the latest valid version.

[0139] This redirection process can be achieved by including a redirection flag in the API response header or returning the latest version index in the response body. This prevents downstream businesses from continuously requesting invalid data due to holding old cached versions, and also prevents invalid data from flowing into the production environment and causing security risks.

[0140] It should be noted that determining the version validity status as invalid specifically means that there are invalid route nodes in the target route data, and the invalid route nodes are core route nodes.

[0141] The core route nodes here refer to nodes whose absence or failure would render route planning impossible or pose significant safety hazards. For example, core route nodes can include essential road segment nodes, such as the only accessible bridge, tunnel, highway entrance / exit, and critical supply nodes, such as designated gas / charging stations in long-haul freight transport and compliant parking points in hazardous materials transport.

[0142] Understandably, the criteria for determining core route nodes are not static but can be dynamically configured based on business scenarios. For example, in autonomous driving testing scenarios, a specific sensor-calibrated road segment might be configured as a core node; while in tourism scenarios, the same node might only be marked as a non-core waypoint. When such a core node fails, it means the original route has lost its basic service capabilities. Therefore, it is necessary not only to return a clear invalidation message but also to simultaneously recommend alternative route data in the same area or with the same function, helping upstream businesses quickly restore service and reducing business interruption time caused by single-point failures.

[0143] As one implementation method, if the version validity status is valid, the node failure level is checked based on the node importance.

[0144] Specifically, when a non-core route node fails, degraded route data is returned, and the failed node information is marked in the degraded route data.

[0145] Non-core route nodes here usually refer to detour points or non-critical service facilities, such as scenic photo spots, alternative rest areas, or non-mandatory checkpoints.

[0146] While the failure of these nodes reduces the overall experience of the route, it does not affect travel safety or the completion of basic tasks. In this case, the application will not directly reject the service, but will instead return degraded route data.

[0147] Specifically, the downgraded route data includes the basic navigation path, as well as the location coordinates and risk warning labels corresponding to the failed nodes.

[0148] In the above process, the basic navigation path ensures that vehicles or users can still travel along legal roads; the accurate coordinates of the failure location enable upstream terminals to intuitively display abnormal points on the map; risk warning labels, such as charging pile offline, scenic spot closed, and construction slow-moving, provide semantic decision-making basis for upper-layer applications.

[0149] Upstream business systems can independently determine the UI rendering method based on these structured fields, such as graying out, pop-up warnings, or interactive logic, such as asking the user whether to continue, thereby decoupling server-side data risk control from client-side experience flexibility.

[0150] As one implementation method, when all route nodes are normal, complete route data is returned.

[0151] This is the default optimal response mode in this application, returning a complete dataset containing full node details, spatiotemporal rules, and version hashes for downstream use.

[0152] This tiered return method can significantly reduce the waste rate of route data, improve the utilization efficiency of operational resources, and empower upstream businesses to make informed decisions through standardized risk warnings, thus avoiding user complaints or security incidents caused by a lack of transparency.

[0153] Based on the first to fifth embodiments, this embodiment further details the full lifecycle status management process of target route data as the sixth embodiment.

[0154] As one implementation method, the full lifecycle status of target route data includes draft status, pending verification status, valid status, pending authority status, frozen status, and archived status.

[0155] Specifically, these six states constitute the complete trajectory of the target route data from creation, verification, service to decommissioning, and each state represents the data's quality confidence and service availability level at the current moment.

[0156] The draft state refers to the initial stage where route data is initially generated but has not yet completed rule binding and integrity checks. At this time, the data is only used for editing and previewing and has no business validity. The pending verification state refers to the transitional stage where the data has completed basic construction and bound spatiotemporal constraint rules, and is undergoing automated system verification. This state ensures that unverified data will not enter the production environment. The valid state refers to the formal service state where all nodes have passed verification and the version identifier has been bound. This is the only state that allows navigation or planning services to be provided externally. The pending authorization state refers to the temporary suspension state where published valid data has received a single-source anomaly signal or user feedback during operation and is in the process of multi-source cross-validation. This state retains the temporary availability of the data to avoid frequent service interruptions and marks potential risks for subsequent decision-making. The frozen state refers to the version state where cross-validation has confirmed that there are node failures and that have not yet been repaired. At this time, the data is forcibly blocked from being accessed. The archived state refers to the final storage state of historical expired versions or completely abandoned routes. It is only used for auditing and traceability and does not participate in any business calculations.

[0157] This application incorporates data quality control actions scattered across various processing stages into a unified state management system by defining the aforementioned standardized state set, ensuring that every change to the data is traceable and verifiable.

[0158] As one implementation method, the entire lifecycle state transition is automatically triggered based on the verification results and version release actions.

[0159] It should be noted that automatic triggering here means that the state change is automatically executed by the system's internal event-driven engine according to preset logic, rather than relying on operators to manually modify database records or click the state switch button.

[0160] For example, when the system completes full-node cross-validation in the pending verification state and all results are passed, it will automatically transition to the valid state and generate a version snapshot; when the valid state data receives a road closure push from the government API, it will automatically transition to the pending rights confirmation state and start the verification timer; when the pending rights confirmation state data is verified and confirmed to be invalid, it will automatically transition to the frozen state and trigger the closed-loop processing flow described in the fourth embodiment; when a new version is released and launched, the valid state of the old version will automatically transition to the archived state.

[0161] This event-driven, automated workflow fundamentally eliminates the inconsistency between state and content caused by delays or negligence in manual operations. For example, in traditional manual management, data content may be updated but the state may still show as draft, or a node may be invalid but the state may still be marked as valid. This embodiment, by embedding the state transition logic into the system code, ensures that the state always accurately reflects the intrinsic quality of the data, improving the system's robustness and reliability.

[0162] As one implementation method, the query interface is only open to target route data that is in a valid state.

[0163] Specifically, this hard constraint is a mandatory access control method implemented in the API gateway or data access layer.

[0164] When an external system initiates a query request for target route data, this application first reads the current lifecycle status of the data. Only when the status is clearly valid will the subsequent node importance judgment and hierarchical return logic be executed. If the status is any of the draft, pending verification, pending authorization, frozen, or archived status, the query interface will directly refuse to return the specific route content data and return a specific standardized error code or prompt message according to the status type.

[0165] For example, for data in the pending verification state, a prompt indicating data preparation can be returned; for data in the frozen state, a redirection guide indicating that the version is outdated and to obtain the latest version can be returned; for data in the archive state, a standard response indicating that the resource does not exist or has been taken offline can be returned.

[0166] This approach physically isolates non-ready data at the service entry point, completely eliminating the possibility of test data, dirty data, or expired data accidentally flowing into the production environment and being used by end users.

[0167] For example, see Figure 2 This application provides an example diagram of the entire lifecycle of the route book version.

[0168] This diagram illustrates the entire lifecycle management process of the roadmap version from creation to final decommissioning, including five core status nodes:

[0169] Initial stage: Starting from the draft state, after binding the spatiotemporal rules and submitting for verification, it enters the pending verification state.

[0170] Effective Phase: In the pending verification state, it transitions to the effective state after cross-validation of all nodes. If an anomaly is detected in the first round, it enters the pending weight confirmation state; if manual correction is successful or anomalies are eliminated through cross-validation, it will return to the effective state.

[0171] Abnormalities and Freezes: In the pending confirmation state, if there is no alternative plan, it will enter the frozen invalid state; if a new version is released or the road map is taken offline, it will be directly archived to the archived state.

[0172] End phase: The frozen invalid state can be manually abandoned and transferred to the archive state, and the valid state can also be directly transferred to the archive state due to the offline command, thus completing the closed loop.

[0173] This process ensures the validity and security of route data through multiple rounds of verification and status transitions.

[0174] It is understandable that while this embodiment emphasizes strict access control for the query interface, in specific operation and maintenance or auditing scenarios, an internal management interface independent of the business query interface can also be provided. This allows authorized personnel to view invalid data for troubleshooting or historical backtracking, but it does not change the core technical characteristic that the business-oriented query interface is only open to valid data. By constructing the aforementioned full lifecycle state machine and interface access constraints, this embodiment provides a global view and institutional safeguards for the governance of route data, enabling the cross-validation, version binding, and hierarchical return techniques in the aforementioned embodiments to operate in an orderly manner on a standardized track, jointly supporting a highly reliable and secure route data update system.

[0175] This embodiment is based on the route data update method in the previous embodiments, and provides a specific application scenario for the route book operation management system.

[0176] In this scenario, the target route data is specifically represented as a road book. The system verifies the feasibility and superiority of the technical solution in a real-world environment by integrating real-world business processes such as timed batch verification, user feedback triggering, and upstream query response.

[0177] In one specific implementation, the route book operation management system performs a scheduled batch verification process every morning at midnight to achieve a comprehensive inspection of the existing route book data.

[0178] Specifically, the system automatically triggers timed batch verification commands during off-peak business hours, first performing a batch verification phase of spatiotemporal rules. The system performs a full scan of all valid route nodes, strictly comparing the current system time with the time window bound to each node.

[0179] For example, if a travel itinerary contains a traffic restriction rule B with a preset time constraint of June 1, 2024 to June 30, 2024, when the system performs verification at midnight on July 1, it detects that the current date has exceeded the time window, and immediately marks traffic restriction rule B as invalid, and automatically changes the validity status of the itinerary version containing the rule to the pending confirmation status.

[0180] The system then enters a dynamic event cross-validation phase. It pulls event push information from government data sources, commercial map data sources, and vertical industry data sources within the past 24 hours and performs spatial matching based on geofencing. If a road closure event is detected during this process, and this event is simultaneously confirmed by two independent data sources—the traffic management department's API and the map service provider's event stream—then the multi-source confirmation condition is met. The system then determines the corresponding roadbook node for that road segment to be invalid and further updates the roadbook version's validity status to a frozen state, thereby blocking subsequent calls to that version.

[0181] This timed inspection method ensures that even without external real-time trigger signals, the system can periodically clean up expired data and maintain the overall health of the road book database.

[0182] In another specific implementation, the route book operation management system supports a real-time verification process triggered by user feedback.

[0183] Specifically, when an end user discovers during navigation that a charging station is actually closed but the route book still shows it as open, they can submit a feedback signal through the client's abnormal reporting channel.

[0184] Upon receiving the user's feedback signal, the system does not directly accept single-source information. Instead, it first marks the relevant route book's status as pending confirmation and retains the feedback record for traceability. Next, the system automatically invokes a multi-source cross-validation layer to retrieve validation data from other independent data sources for the charging station location within the current time window and spatial boundary area.

[0185] For example, the system queries the charging station operator's equipment status interface and finds that the equipment at the site is offline. At the same time, it queries the commercial map data and finds that the POI has been marked as temporarily closed. At this time, both independent high-confidence sources confirm the anomaly, which meets the preset multi-source confirmation conditions. The system then determines that the charging station node is in a failed state and updates the route book version to a frozen state.

[0186] Conversely, if it is verified that the high-reliability source display device is online and operating normally, or if it is invalid due to a lack of sufficient independent source evidence, the system will remove the pending rights mark, restore the road book to a valid state, and feed back the verification results to the reporting user.

[0187] This process leverages the long-tail coverage capabilities perceived by users while avoiding data pollution caused by malicious feedback or false alarms through a strict multi-source rights confirmation mechanism.

[0188] In scenarios where upstream systems query route data, the route operation and management system strictly implements version access and hierarchical return strategies.

[0189] Specifically, when a navigation app or logistics dispatch platform initiates a route query request, the feedback unit first verifies the validity of the specified version or the latest version. If the requested version is in a frozen or archived state, the system directly refuses to return that version's content and guides the caller to obtain the latest valid version in the response, thus preventing the circulation of expired route books from the source.

[0190] If the version is valid, the system further verifies the failure level of nodes based on their importance. For example, when a core route node such as a mandatory highway intersection or a key supply point in the route book is detected as invalid, the system returns a clear invalidation message and simultaneously recommends alternative route book data with similar functions in the same area to prevent vehicles from entering impassable sections or running out of energy. When a non-core route node such as a scenic spot or a non-mandatory rest area is detected as invalid, the system does not remove the entire route book but instead returns downgraded route data.

[0191] The downgraded route data includes a complete basic navigation path, and risk warning labels, such as attraction closure notices, are embedded at the location coordinates of the failed nodes. This allows upstream applications to decide whether to continue using the route book or display risk warnings to users based on actual business needs, while ensuring traffic safety.

[0192] This refined, tiered service approach ensures that core security boundaries are not breached while maximizing the usability of route data and avoiding resource waste caused by the failure of non-critical information in certain areas, which could lead to overall service interruptions.

[0193] If a node fails and causes a version freeze in any of the above scenarios, the system will automatically execute a closed-loop processing procedure for the failed node.

[0194] Specifically, the update unit first iterates backward through all associated route data containing the failed node to ensure that all affected versions are included in the processing scope.

[0195] Subsequently, the system searches for similar points of interest within a preset geographical range, such as a radius of 5 kilometers, as alternative nodes.

[0196] Taking the failure of charging pile A as an example, the system finds another brand of charging pile C 3 kilometers away. After compliance assessment confirms that its business status is normal and there are no new traffic restriction rules, the original route book data is updated using charging pile C, and the full node validity verification is re-executed.

[0197] Only after a new version of the route book passes full verification will the system generate a new unique version identifier and release it online, while automatically archiving the old version. If no compliant replacement node is found, the system will mark the relevant route book as obsolete and archive it, while notifying operations personnel for manual intervention. Through the above-mentioned automated closed-loop operation, the route book operation management system achieves seamless integration from change detection, cross-validation, version freezing, replacement repair to tiered services, significantly improving the timeliness and accuracy of route book data, greatly reducing manual operation and maintenance costs, and providing a secure and reliable route data foundation for downstream businesses.

[0198] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

[0199] For example, see Figure 3 The flowchart for route book verification and publication provided in this application is shown in the example diagram.

[0200] like Figure 3 As shown, after the initial draft of the route book is generated, the basic attributes such as nodes, time windows and geofences are first bound in batches through the spatiotemporal rule verification engine. Then, the multi-source cross-validation layer is called to perform the first round of full node validity verification.

[0201] After verification, the process is divided into two paths: if the entire node is valid, the system will directly generate a unique business version number and content hash at the version control layer, bind the current state snapshot and mark it as valid, and then officially put it into the database for open access.

[0202] If a faulty node is found, the system will automatically search for similar POIs within a 3-5 kilometer radius and match them according to their scores. If a compliant alternative node is found, the route data and spatiotemporal rules will be automatically updated, and the system will re-enter the cross-validation layer for verification. If no alternative node is found, the route will be marked for manual processing and pushed to the operations backend.

[0203] After manual intervention by operations personnel, and the designated alternative or forced online implementation, the route guide will also be rolled back to the verification layer for final confirmation, thus forming a closed-loop management system to ensure that the published route guide is both timely and accurate.

[0204] See Figure 4 The present application provides a schematic diagram of the structure of the route data updating device.

[0205] like Figure 4 As shown, the device includes an acquisition unit 10, a verification unit 20, an update unit 30, and a feedback unit 40; wherein:

[0206] Acquisition unit 10 is used to acquire multi-source dynamic data corresponding to the route nodes in the target route data;

[0207] The verification unit 20 is used to perform cross-validation based on multi-source dynamic data and preset spatiotemporal constraint rules to determine the failure status of route nodes in the target route data.

[0208] Update unit 30 is used to update the version validity status of the target route data based on the failure status of the route nodes;

[0209] Feedback unit 40 is used to respond to the query request for target route data, and perform hierarchical return based on the version validity status and the node importance of the route nodes to output the updated target route data.

[0210] In one implementation, the preset spatiotemporal constraint rules in the verification unit 20 include a time window and a spatial boundary region;

[0211] The verification unit 20 is specifically used for:

[0212] When the first data source in the multi-source dynamic data indicates that the status of the route node has changed, obtain the verification data from other independent data sources within the time window and spatial boundary area corresponding to the route node;

[0213] When the verification data meets the preset multi-source confirmation conditions, the route node is determined to be in a failed state.

[0214] In one implementation, the multi-source dynamic data in the verification unit 20 includes at least two of the following: government open data sources, commercial map open data sources, vertical industry data sources, and user feedback data sources.

[0215] Unit 10 is specifically used for:

[0216] In response to at least one of the following trigger signals: timed batch verification command, single-source event push signal, or user feedback signal, acquire at least two of the following data sources: government information disclosure data source, commercial map information disclosure data source, vertical industry data source, and user feedback data source.

[0217] In one embodiment, the updating unit 30 is specifically used for:

[0218] Generate a unique version identifier for the target route data and bind the unique version identifier to the full node status snapshot of the target route data;

[0219] When there are core route nodes in the target route data that are in a failed state, the version validity status is updated to a frozen state to intercept calls to the current version of the target route data and trigger the closed-loop processing flow for failed nodes.

[0220] In one implementation, the closed-loop processing flow for the failed node in the update unit 30 includes:

[0221] The reverse traversal includes the associated route data of core route nodes that are in a failed state;

[0222] Search for similar points of interest within a preset geographical area as alternative nodes;

[0223] If a compliant alternative node is found, the node data of the associated route data and the corresponding preset spatiotemporal constraint rules are updated using the alternative node, and the full node validity check is re-executed to generate a new version of the route data.

[0224] If no compliant alternative node is found, the associated route data will be marked as obsolete and archived.

[0225] In one embodiment, the feedback unit 40 is specifically used for:

[0226] If the version validity status is invalid, refuse to return the current version and guide the user to obtain the latest valid version;

[0227] If the version validity status is valid, then the node failure level is checked based on the node importance:

[0228] When a core route node fails, an invalid message and alternative route data are returned.

[0229] When a non-core route node fails, degraded route data is returned, and the failed node information is marked in the degraded route data;

[0230] When all route nodes are normal, return complete route data.

[0231] In one implementation, the core route nodes in the feedback unit 40 include essential route nodes and critical supply nodes, while the non-core route nodes include detour route nodes.

[0232] The downgraded route data includes the basic navigation path, as well as the location coordinates and risk warning labels corresponding to the failed nodes.

[0233] In one implementation, the full lifecycle status of the target route data in the acquisition unit 10 includes draft status, pending verification status, valid status, pending rights confirmation status, frozen status, and archived status;

[0234] The entire lifecycle state transition is automatically triggered based on the verification results and version release actions, and the query interface is only open to target route data that is in a valid state.

[0235] This embodiment provides a vehicle that serves as the terminal execution carrier for the aforementioned route data update method, and realizes localized processing and dynamic updating of route data through an on-board hardware architecture.

[0236] In one implementation, the vehicle includes at least one processor and a memory connected to the processor, wherein: the memory is used to store a computer program; and the processor is used to execute the computer program to enable the vehicle to implement a route data update method as described in any of the foregoing embodiments.

[0237] Through the above description of the embodiments, those skilled in the art can clearly understand that this application can be implemented by means of software plus necessary general-purpose hardware, or it can be implemented by special-purpose hardware including application-specific integrated circuits, special-purpose CPUs, special-purpose memory, special-purpose components, etc. Generally, any function performed by a computer program can be easily implemented by corresponding hardware, and the specific hardware structure used to implement the same function can be diverse, such as analog circuits, digital circuits, or special-purpose circuits. However, for this application, software program implementation is more often the preferred implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a readable storage medium, such as a computer floppy disk, USB flash drive, mobile hard disk, ROM, RAM, magnetic disk, or optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, training equipment, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0238] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product.

[0239] The computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions described in the embodiments of this application are generated. The computer may be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions may be stored in a computer-readable storage medium or transmitted from one computer-readable storage medium to another. For example, the computer instructions may be transmitted from one website, computer, training device, or data center to another website, computer, training device, or data center via wired (e.g., coaxial cable, fiber optic, digital subscriber line (DSL)) or wireless (e.g., infrared, wireless, microwave, etc.) means. The computer-readable storage medium may be any available medium that a computer can store or a data storage device such as a training device or data center that integrates one or more available media. The available media may be magnetic media (e.g., floppy disks, hard disks, magnetic tapes), optical media (e.g., DVDs), or semiconductor media (e.g., solid-state drives (SSDs)).

Claims

1. A method for updating route data, characterized in that, include: Acquire multi-source dynamic data corresponding to route nodes in the target route data; Cross-validation is performed based on the multi-source dynamic data and preset spatiotemporal constraint rules to determine the failure status of route nodes in the target route data; Based on the failure status of the route nodes, update the version validity status of the target route data; In response to the query request for the target route data, based on the version validity status and the node importance of the route nodes, a hierarchical return is performed to output the updated target route data.

2. The method for updating route data according to claim 1, characterized in that, The preset spatiotemporal constraint rules include time windows and spatial boundary regions; The step of determining the failure status of route nodes in the target route data by performing cross-validation based on the multi-source dynamic data and preset spatiotemporal constraint rules includes: When the first data source in the multi-source dynamic data indicates that the status of the route node has changed, verification data from other independent data sources are obtained within the time window and spatial boundary area corresponding to the route node; When the verification data meets the preset multi-source confirmation conditions, the route node is determined to be in a failed state.

3. The method for updating route data according to claim 2, characterized in that, The multi-source dynamic data includes at least two of the following: government open data sources, commercial map open data sources, vertical industry data sources, and user feedback data sources; The acquisition of multi-source dynamic data corresponding to route nodes in the target route data includes: In response to at least one of the following trigger signals: a timed batch verification instruction, a single-source event push signal, or a user feedback signal, at least two of the following data sources are obtained: government information disclosure data source, commercial map information disclosure data source, vertical industry data source, and user feedback data source.

4. The method for updating route data according to claim 1, characterized in that, The step of updating the version validity status of the target route data based on the failure status of the route nodes includes: Generate a unique version identifier for the target route data, and bind the unique version identifier to the full node state snapshot of the target route data; When there are core route nodes in the target route data that are in a failed state, the version validity status is updated to a frozen state to intercept the call to the current version of the target route data and trigger the closed-loop processing flow for failed nodes.

5. The method for updating route data according to claim 4, characterized in that, The closed-loop processing procedure for the failed node includes: The associated route data containing the core route nodes that are in a failed state is traversed in reverse. Search for similar points of interest within a preset geographical area as alternative nodes; If a compliant alternative node is found, the node data of the associated route data and the corresponding preset spatiotemporal constraint rules are updated using the alternative node, and the full node validity check is re-executed to generate a new version of the route data. If no compliant alternative node is found, the associated route data will be marked as obsolete and archived.

6. The method for updating route data according to claim 1, characterized in that, In response to the query request for the target route data, based on the version validity status and the node importance of the route nodes, a tiered return is performed to output the updated target route data, including: If the version validity status is invalid, then refuse to return the current version and guide the user to obtain the latest valid version; If the version validity status is valid, then the node failure level is checked based on the node importance: When a core route node fails, an invalid message and alternative route data are returned. When a non-core route node fails, degraded route data is returned, and the failed node information is marked in the degraded route data; When all route nodes are normal, return complete route data.

7. The method for updating route data according to claim 6, characterized in that, The core route nodes include essential route nodes and critical supply nodes, while the non-core route nodes include detour points. The downgraded route data includes the basic navigation path, as well as the location coordinates and risk warning labels corresponding to the failed node information.

8. The method for updating route data according to claim 1, characterized in that, The target route data's full lifecycle status includes draft, pending verification, valid, pending rights confirmation, frozen, and archived states; The entire lifecycle state transition is automatically triggered based on the verification results and version release actions, and the query interface is only open to target route data that is in the valid state.

9. A route data updating device, characterized in that, include: The acquisition unit is used to acquire multi-source dynamic data corresponding to the route nodes in the target route data; The verification unit is used to perform cross-validation based on the multi-source dynamic data and preset spatiotemporal constraint rules to determine the failure status of the route nodes in the target route data. An update unit is used to update the version validity status of the target route data based on the failure status of the route nodes; The feedback unit is used to respond to the query request for the target route data, and perform hierarchical return based on the version validity status and the node importance of the route nodes to output the updated target route data.

10. A vehicle, characterized in that, It includes at least one processor and a memory connected to the processor, wherein: The memory is used to store computer programs; The processor is used to execute the computer program to enable the vehicle to implement the route data update method as described in any one of claims 1 to 8.

Images