A vehicle trip plan updating method, device, equipment and storage medium

Abstract

This application provides a method, apparatus, device, and storage medium for updating vehicle trip plans, relating to the field of information technology. The method includes: receiving a first request from a first user, the first request requesting the updating of second trip data based on first trip data, the first request including the first trip data, and the second trip data being trip data submitted by the first user and stored in a vehicle trip management database. If there is a conflict between the trips corresponding to the second trip data and the first trip data, a first prompt message is generated, the first prompt message instructing the first user to modify the first trip data. If there is no conflict between the trips corresponding to the second trip data and the first trip data, the second trip data is updated according to the first trip data.

Description

Technical Field

[0001] This application relates to the field of information technology, and in particular to a method, apparatus, device and storage medium for updating vehicle travel plans. Background Technology

[0002] In civil aviation flight schedule management, the coordination between winter and summer flight seasons is a complex task involving multiple parties and processes. It mainly includes the confirmation and adjustment of historical schedules, the allocation of new schedules, the exchange of schedules and joint operation between airlines, etc. The core operations all revolve around a unified seasonal flight schedule database.

[0003] To prevent conflicts caused by multiple users or processes simultaneously modifying the same flight data, a locking mechanism is typically used. Specifically, when an application for a flight plan is submitted, the system locks all flight data involved in that application in the seasonal database until the application is approved and entered into the database, at which point the lock is released.

[0004] However, after data locking is implemented, the remaining unmodified flights cannot be submitted or processed by other processes, resulting in process blockage and low collaboration efficiency. Summary of the Invention

[0005] This application provides a method, apparatus, device, and storage medium for updating vehicle itinerary plans, which addresses the problems of process blockage and low collaborative efficiency in flight plan modifications.

[0006] Firstly, this application provides a method for updating a vehicle travel plan. This method is applied to an electronic device. The subject executing this method can be an electronic device, a component or device applied to the electronic device (e.g., a processor, chip, or chip system), or a logic module or software capable of implementing all or part of the functions of the electronic device, including: Receive a first request from a first user. The first request is used to request the update of second trip data based on first trip data. The first request includes the first trip data and the second trip data is trip data submitted by the first user and used to store in the vehicle trip management library. In the event of a conflict between the second trip data and the first trip data, a first prompt message is generated to instruct the first user to modify the first trip data. If there are no conflicts between the trips corresponding to the second trip data and the first trip data, update the second trip data based on the first trip data.

[0007] In the first aspect, the trip data submitted by the first user and stored in the vehicle trip management database is compared with the first trip data. When trip conflicts occur, a prompt message is generated to guide the user to make modifications, preventing conflicting data from entering subsequent processes from the source. When the trip data does not conflict, the request is allowed to proceed to review and ultimately update the second trip data. This effectively solves the technical problems of data inconsistency, confusion, and duplication that may occur when multiple users or multiple processes operate concurrently on the same data source, ensuring the accuracy of the final data entered into the database.

[0008] In conjunction with the first aspect, in one possible implementation, where there are no conflicts between the trips corresponding to the second trip data and the first trip data, updating the second trip data based on the first trip data includes: If there is no conflict between the trips corresponding to the second trip data and the first trip data, perform the addition, adjustment or cancellation operations on the second trip data based on the first trip data; Alternatively, if there are no conflicts between the trips corresponding to the second trip data and the first trip data, delete the second trip data and store the first trip data in the vehicle trip management library.

[0009] This implementation distinguishes between update requests that support adding, adjusting, or canceling individual operations, and those that support batch file import and overall replacement. This allows it to adapt to both refined single-point changes and large-scale overall replacements, thus enhancing the method's flexibility and practicality for different update needs and operational modes.

[0010] In conjunction with the first aspect, in one possible implementation, when deleting the second trip data and storing the first trip data in the vehicle trip management library, the method further includes: A second prompt message is generated, which is used to instruct the deletion of the second trip data.

[0011] In this implementation, when using the update method of clearing first and then inserting all data, a second prompt message is generated and issued to proactively notify the user of the data deletion operation. This allows users or administrators to clearly know that a major change has occurred in the vehicle trip management database, namely the clearing of existing data. This improves the transparency and traceability of the data change process, facilitating auditing or quickly locating the source of the operation when doubts arise.

[0012] In conjunction with the first aspect, in one possible implementation, the method further includes: performing conflict detection on the trips corresponding to the second trip data and the first trip data, respectively.

[0013] In this implementation, conflict detection is performed on the trips corresponding to the second trip data and the first trip data respectively. By streamlining the conflict detection process, duplicate data can be filtered out before data approval, thereby reducing the risk of data conflict.

[0014] In conjunction with the first aspect, in one possible implementation, conflict detection is performed on the trips corresponding to the second trip data and the first trip data, including: Based on the comparison of preset key fields in the first trip data and the second trip data, it is determined whether there is a situation where the trips corresponding to the second trip data and the first trip data cannot be executed simultaneously in terms of time and / or location. If such a situation exists, it is determined that there is a conflict between the trips corresponding to the second trip data and the first trip data.

[0015] In this implementation, by comparing the trip data to be detected with the second trip data and using preset key fields for duplicate judgment, it is possible to achieve efficient traversal and comparison of large-scale data sets, making the conflict detection process have high processing efficiency and response speed.

[0016] In conjunction with the first aspect, in one possible implementation, before updating the second travel data based on the first travel data, provided that there are no conflicts between the travel data corresponding to the second travel data and the first travel data, the method further includes: Initiate an approval process, which is used to determine whether it is permissible to update the second itinerary data based on the first itinerary data. The following access control operations are performed at each review stage of the approval process: Configure exclusive access permissions for the first review entity corresponding to the approval request in the review stage to perform review operations. During the period when the exclusive access permissions are in effect, prevent the second review entity from reviewing the approval request until the review stage is completed and the exclusive access permissions are released.

[0017] This implementation achieves access control for the review process by setting access permissions for the update request being processed at any stage of the review process and preventing other concurrent review operations on the same request while the permissions are in effect. This ensures that no update request is processed simultaneously or repeatedly by multiple people in a specific review stage, thereby preventing data inconsistencies or duplicate entries caused by concurrent operations during the review phase.

[0018] In conjunction with the first aspect, in one possible implementation, the method further includes: The first interface is displayed, which shows the update status of the second trip data based on the first trip data.

[0019] This implementation provides review users with an intuitive data comparison view by offering a primary interface that displays changes in travel itineraries before and after the initial data update. This allows review users to clearly and quickly assess the impact of the update on resource consumption, thereby assisting them in making more accurate review decisions and improving the efficiency and quality of the review process.

[0020] Secondly, this application provides a vehicle trip plan updating device, comprising: The request receiving module is used to receive a first request from a first user. The first request is used to request the update of second trip data based on first trip data. The first request includes the first trip data and the second trip data is the trip data submitted by the first user and used to store the trip data in the vehicle trip management library. The prompt generation module is used to generate a first prompt message when there is a conflict between the second trip data and the first trip data. The first prompt message is used to instruct the first user to modify the first trip data. The trip update module is used to update the second trip data based on the first trip data, provided that there are no conflicts between the trips corresponding to the second trip data and the first trip data.

[0021] In conjunction with the second aspect, in one possible implementation, the trip update module is also used to perform add, adjust, or cancel trip data operations on the second trip data based on the first trip data, provided that there are no conflicts between the trips corresponding to the second trip data and the first trip data. Alternatively, if there are no conflicts between the trips corresponding to the second trip data and the first trip data, delete the second trip data and store the first trip data in the vehicle trip management library.

[0022] In conjunction with the second aspect, in one possible implementation, the prompt generation module is also used to generate a second prompt message, which is used to instruct the deletion of the second trip data.

[0023] In conjunction with the second aspect, in one possible implementation, the vehicle trip plan update device further includes a conflict detection module for performing conflict detection on the trips corresponding to the second trip data and the first trip data, respectively.

[0024] In conjunction with the second aspect, in one possible implementation, the conflict detection module is also used to compare the preset key fields in the first trip data and the second trip data, and determine whether there is a situation where the trips corresponding to the second trip data and the first trip data cannot be executed simultaneously in terms of time and / or location based on the comparison result. If such a situation exists, it is determined that there is a conflict between the trips corresponding to the second trip data and the first trip data.

[0025] In conjunction with the second aspect, in one possible implementation, the vehicle trip plan update device further includes a trip approval module for initiating an approval process, which determines whether to allow updating the second trip data based on the first trip data. The following access control operations are performed at each review stage of the approval process: Configure exclusive access permissions for the first review entity corresponding to the approval request in the review stage to perform review operations. During the period when the exclusive access permissions are in effect, prevent the second review entity from reviewing the approval request until the review stage is completed and the exclusive access permissions are released.

[0026] In conjunction with the second aspect, in one possible implementation, the trip approval module is also used to display a first interface, which displays the update status of the second trip data based on the first trip data.

[0027] Thirdly, this application provides an electronic device comprising: a processor and a memory; the memory storing processor-executable instructions; when the processor is configured to execute the instructions, causing the electronic device to implement the method of the first aspect described above.

[0028] Fourthly, this application provides a computer-readable storage medium comprising: computer software instructions; which, when executed in an electronic device, cause the electronic device to implement the method described in the first aspect.

[0029] Fifthly, this application provides a computer program product comprising a computer program; when the computer program is run in an electronic device, it causes the electronic device to implement the method described in the first aspect.

[0030] The beneficial effects of the second to fifth aspects mentioned above are described in the corresponding description of the first aspect and will not be repeated here. Attached Figure Description

[0031] Figure 1 This is a schematic diagram illustrating the application environment of a vehicle trip plan update method provided in an embodiment of this application. Figure 2 A schematic diagram of a vehicle trip plan update system architecture provided in this application embodiment; Figure 3 A flowchart illustrating a vehicle trip plan update method provided in this application embodiment; Figure 4 This application provides a schematic diagram of a flight seasonal update process. Figure 5 A schematic diagram illustrating the composition of a vehicle trip plan updating device provided in this application embodiment; Figure 6This is a schematic diagram of the composition of an electronic device provided in an embodiment of this application. Detailed Implementation

[0032] The following is a detailed description, with reference to the accompanying drawings, of a vehicle trip plan updating method, apparatus, device, and storage medium provided in this application.

[0033] In this article, the term "and / or" is merely a description of the relationship between related objects, indicating that there can be three relationships. For example, A and / or B can represent three situations: A exists alone, A and B exist simultaneously, and B exists alone.

[0034] The terms "first" and "second," etc., used in the specification and drawings of this application are used to distinguish different objects or to distinguish different treatments of the same object, rather than to describe a specific order of objects.

[0035] Furthermore, the terms "comprising" and "having," and any variations thereof, used in the description of this application are intended to cover non-exclusive inclusion. For example, a process, method, system, product, or apparatus that includes a series of steps or units is not limited to the steps or units listed, but may optionally include other steps or units not listed, or may optionally include other steps or units inherent to such process, method, product, or apparatus.

[0036] It should be noted that in the embodiments of this application, the words "exemplary" or "for example" are used to indicate examples, illustrations, or explanations. Any embodiment or design scheme described as "exemplary" or "for example" in the embodiments of this application should not be construed as being more preferred or advantageous than other embodiments or design schemes. Specifically, the use of the words "exemplary" or "for example" is intended to present the relevant concepts in a specific manner.

[0037] To facilitate a clear description of the technical solutions of the embodiments of this application, the terms "first" and "second" are used in the embodiments of this application to distinguish the same or similar items with essentially the same function and effect. Those skilled in the art can understand that the terms "first" and "second" are not intended to limit the quantity or execution order.

[0038] In the description of this application, unless otherwise stated, "a plurality of" means two or more.

[0039] In the civil aviation sector, flight schedules are a core operational resource for airlines. Their efficient and accurate configuration and management are crucial for ensuring normal flight operations and improving airspace resource utilization. Especially during the transition between the winter and summer flight seasons each year, a large number of flight schedules are adjusted, added, and canceled. This necessitates systematic and collaborative planning and filing, a process commonly referred to as seasonal flight schedule changes. During this period, airlines must submit data to a unified flight schedule database through various processes such as filing, submission, and data transfer. This involves multiple parties and complex data coordination, placing high demands on the system's collaborative processing capabilities and data consistency.

[0040] Currently, to ensure that data conflicts do not occur when multiple people operate on the same flight plan database, a data locking mechanism is often used in practice. That is, when an application is submitted for a certain process, the system locks the relevant flight data in the database until the process is reviewed and the data is entered into the database. This approach is effective in preventing data corruption caused by concurrent modifications.

[0041] However, this mechanism also presents significant limitations. Since application forms or imported files often contain a large amount of flight data, if some flights are locked, other flights in the entire file, even without conflicts, cannot be submitted, leading to operational bottlenecks and decreased efficiency. Furthermore, the lack of proactive identification and alerts for conflicting data means users cannot anticipate potential conflicts with existing data in the database or with other processes before submission. This often necessitates repeated troubleshooting and adjustments after failed reviews, extending processing times and potentially causing data inconsistencies or loss due to repetitive operations. Moreover, when multiple processes run concurrently, without conflict pre-detection and coordination, data overwriting or matching errors can still cause subsequent operational chaos. Therefore, improving the efficiency and user-friendliness of multi-process collaboration while ensuring data consistency is a crucial aspect that urgently needs improvement in flight schedule seasonal management.

[0042] To address the aforementioned technical problems, this application provides a method, apparatus, device, and storage medium for updating vehicle trip plans. The approach involves comparing trip data submitted by a first user and stored in a vehicle trip management database with first trip data. When trip conflicts occur, a prompt message is generated to guide the user to make modifications, preventing conflicting data from entering subsequent processes. When trip data does not conflict, a request is allowed to proceed to review and ultimately update the second trip data. This effectively solves the technical problems of data inconsistency, confusion, and duplication that may occur when multiple users or multiple processes concurrently operate on the same data source, ensuring the accuracy of the final data stored.

[0043] The embodiments provided in this application will now be described in detail with reference to the accompanying drawings.

[0044] like Figure 1As shown, the application environment may include a first device and a second device.

[0045] For example, the first device can be a terminal device or a server, and the second device can be a server.

[0046] Terminal device 100 and server 101.

[0047] The terminal device 100 includes an application 102 that supports vehicle trip plan updates. The client of the application 102, which supports vehicle trip plan updates, is used in the terminal device 100 to visually display the update process during the execution of the vehicle trip plan update method according to this embodiment.

[0048] This client provides a user interface, which can take the form of a World Wide Web (Web) page accessed through a browser or a native application that needs to be downloaded and installed. The terminal is specifically a user equipment (UE), which includes, but is not limited to, smartphones, tablets, laptops, desktop computers, Internet of Things (IoT) terminals, and Vehicle-to-Everything (V2X) terminals. The terminal accesses the access network via a wireless air interface and has the capability to carry voice services, data transmission services, and multimedia services. It can also enable direct communication between different terminals based on device-to-device (D2D) direct connection technology or V2X technology.

[0049] This client is used to receive the user's first request and display prompts or interfaces to the user.

[0050] In another example, the vehicle trip plan update method provided in this application can be applied to server 101. Server 101 runs an application 102 that supports vehicle trip plan update functionality. This application is responsible for processing requests sent by clients and executing the vehicle trip plan update method, which includes receiving a first request from the user, performing conflict detection based on second trip data in the vehicle trip management library, generating prompt information, executing an approval process, and updating the second trip data according to the first trip data.

[0051] In one alternative embodiment, the terminal device 100 and the server 101 can be interconnected via a wired or wireless network.

[0052] Server 101 includes a first memory and a first processor. The first memory stores a vehicle trip plan update program; the vehicle trip plan update program is invoked and executed by the first processor to implement the vehicle trip plan update method provided in this application. The first memory may include, but is not limited to, the following: random access memory (RAM), read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), and electrically erasable programmable read-only memory (EEPROM). The first processor may consist of one or more integrated circuit chips. Optionally, the first processor may be a general-purpose processor, such as a central processing unit (CPU) or a network processor (NP). Optionally, the first processor can implement the vehicle trip plan update method provided in this application by running programs or code.

[0053] Database system 103 is deployed on a dedicated server to store trip data, including a vehicle trip management database, approval process status data, and operation logs. It can include various types of databases, such as relational databases and non-relational databases. Database system 103 can respond to events such as writes to the vehicle trip management database, changes in approval request status, or the acquisition and release of audit locks, by synchronously updating or invalidating relevant data in the cache.

[0054] This application embodiment also provides a vehicle trip plan update system, which can be set up in... Figure 1 In the application environment shown, such as Figure 2 As shown, the vehicle trip planning update system 200 may include: Vehicle trip planning update system front-end 201 is used for: Receives a first request from the user, including initial trip data. Displays a first prompt, a second prompt, or a first interface to the user; provides online editing functionality, allowing the user to modify the trip data based on the prompts; receives approval instructions from the reviewing user. Displays the first interface to the reviewing user during the approval process.

[0055] Vehicle trip planning update system backend 202 is used for: Responding to the user's first request; Conflict detection is performed on the first travel data based on the second travel data in the vehicle travel management library; In response to a trip conflict, a first prompt message is generated, which instructs the user to modify the first trip data; In response to the absence of a trip conflict, update the second trip data in the vehicle trip management database based on the first trip data; Implement multi-level approval logic and access control in the approval process; Perform the operation of updating the second trip data based on the first trip data.

[0056] The vehicle trip planning update system backend 202 further includes the following engines: The conflict detection engine 2021 is used to compare preset key fields in the first trip data and the second trip data. Based on the comparison results, it determines whether there is a trip conflict between the trips corresponding to the second trip data and the first trip data, in order to determine whether there is a trip conflict.

[0057] The Approval Management Engine 2022 is used to manage multi-level approval processes for different types of update requests. In any review stage of the approval process, a dedicated access permission is configured for the first review entity corresponding to the approval request at that stage to perform the review operation. During the period when the dedicated access permission is in effect, the second review entity is prevented from reviewing the same approval request. When the review stage is completed, the dedicated access permission is released.

[0058] The data update engine 2023 is used to perform update operations on the vehicle trip management library according to the type of the first request when the approval process is passed or no approval is required; for the request, it performs add, adjust, cancel or replace operations on the second trip data; when a replacement operation is required, it generates a second prompt message to indicate that the second trip data will be deleted or replaced.

[0059] The View Generation Engine 2024 is used to generate the data required for the first interface in the approval process. The first interface is used to display the update status of the second process data based on the first process data, including the changes in the planned quantity before and after the update, the comparison of the differences between the file and the library, and the time quantity information before and after the merger.

[0060] Database system 203 is used for: The system stores vehicle trip management data, including trip plans; it also stores approval requests at each process stage and their associated trip data, which can also be stored in server memory; and it provides distributed locking support for the approval management engine to ensure data consistency for the same approval request during the review process.

[0061] It should be noted that the system architecture described in the embodiments of this application is for the purpose of more clearly illustrating the technical solutions of the embodiments of this application, and does not constitute a limitation on the technical solutions provided in the embodiments of this application. As those skilled in the art will know, with the evolution of system architecture, the technical solutions provided in the embodiments of this application are also applicable to similar technical problems.

[0062] See Figure 3 This is a flowchart illustrating a vehicle trip plan update method provided in an embodiment of this application. Figure 3 As shown, the vehicle trip plan update method provided in this application can be implemented through the aforementioned server 101, specifically including the following steps S300~S302.

[0063] S300, the server receives the first request from the first user.

[0064] The first user refers to an entity authorized to initiate data update operations to the vehicle trip management database corresponding to a specific trip management unit. For example, in an airline scenario, the first user could be the airline's flight schedule administrator; in a railway scenario, the first user could be the railway bureau's train timetable compiler. The first request is a trip update request initiated by the first user. The first request is used to request the update of second trip data based on the first trip data. The first request includes the first trip data, which is the trip data submitted by the first user and used to store in the vehicle trip management database. The first trip data specifically describes the vehicle trip information that the user intends to add, change, or cancel, such as flight numbers, train numbers, bus numbers, and their corresponding scheduled times and stations. The second trip data includes two aspects: first, existing trip data already stored in the vehicle trip management database, representing confirmed trip plans, stored in the database; and second, trip data received but not yet updated to the vehicle trip management database, stored in the database or server memory.

[0065] The vehicle trip management database stores and manages pending trip plans, with ownership and operational management authority belonging to a single trip management unit. A trip management unit is an entity responsible for coordinating, approving, and managing trip plans within a specific operating area or network. For example, it could represent an airline, managing its flight schedules; an airport, coordinating local flight resources; a railway bureau or station in a railway system, managing train schedules; or a bus group or bus station in a highway passenger transport system, managing long-distance bus or public bus schedules. Users, typically operators within or under these trip management units, send update requests to the server via client applications to add, adjust, or batch update trip data in the unit's vehicle trip management database.

[0066] S301. If there is a conflict between the second trip data and the first trip data, the server generates a first prompt message.

[0067] A trip conflict refers to an incompatibility between two trip plans in terms of resource or time attributes. For example, this can manifest as two trip plans being scheduled to use the same platform at the same time, or the same vehicle being assigned different tasks with overlapping times.

[0068] The first prompt message is used to instruct the first user to modify the first trip data. The first prompt message generated by the server guides the user to resolve identified data conflicts. This information provides explicit modification guidance. Typically, the first prompt message includes specific conflict details, such as the update request number (i.e., application number) of the conflicting party, the vehicle / train number involved in the conflict (e.g., flight number, train number), the specific station or area where the conflict occurred, and a description of the conflict type.

[0069] After generating this information, the server sends it to the user client that initiated the first request. The user client then displays the initial prompt information on its interface. By reading this information, the user can quickly locate the specific entry in the first trip data that caused the conflict and determine whether the root cause is a conflict with an existing plan in the database or with another pending modification request. Based on the prompt information, the user can make targeted adjustments to the first trip data, such as modifying the time, changing resources, or canceling the plan, thereby eliminating the conflict conditions. Automatically detected trip plan conflicts are transformed into specific problem descriptions that users can understand and act upon, avoiding invalid submissions and improving overall process efficiency.

[0070] S302. If there is no conflict between the trips corresponding to the second trip data and the first trip data, the server updates the second trip data according to the first trip data.

[0071] When the server determines that there is no trip conflict between the trips corresponding to the second trip data and the trip data corresponding to the first trip data, it performs an update operation on the second trip data based on the first trip data.

[0072] In the update operation, the server, based on the change intent carried by the first trip data, performs corresponding state changes on the second trip data stored in the vehicle trip management database. No update operation is performed on second trip data not stored in the vehicle trip management database. This ensures that the trip plan content maintained in the vehicle trip management database is consistent with the first trip data and corresponding operations carried in this first request.

[0073] By performing update operations, it is ensured that the latest itinerary plans submitted by users can be accurately and completely reflected in the central management database under conflict-free conditions. This achieves closed-loop management of itinerary data from submission to effectiveness, ensuring the consistency of plan data within the itinerary management unit and the correctness of the final execution basis.

[0074] In this embodiment, trip data submitted by a first user and stored in the vehicle trip management database is compared with first trip data. When trips conflict, a prompt message is generated to guide the user to make modifications, preventing conflicting data from entering subsequent processes from the source. When trip data does not conflict, a request is allowed to proceed to review and ultimately update the second trip data. This effectively solves the technical problems of data inconsistency, confusion, and duplication that may occur when multiple users or multiple processes operate concurrently on the same data source, ensuring the correctness of the final data entered into the database.

[0075] In one embodiment, step S302 includes: S3021. If there is no conflict between the trips corresponding to the second trip data and the first trip data, the server performs the addition, adjustment or cancellation operation on the second trip data based on the first trip data.

[0076] When the server determines that there is no conflict between the trips corresponding to the second trip data and the first trip data, it performs one or more of the following operations on the second trip data stored in the vehicle trip management library, based on the content of the first trip data: add, adjust, or cancel. However, it does not update the second trip data that is not stored in the vehicle trip management library.

[0077] The "add new" operation refers to the server adding certain trip plan entries contained in the first trip data to the vehicle trip management database when they are not present in the second trip data stored in the vehicle trip management database.

[0078] An adjustment operation refers to the process where, when the first trip data aims to modify certain existing second trip data entries in the vehicle trip management database, the server changes one or more attributes of the corresponding trip plan entry in the database according to the update information provided by the first trip data. These attributes include planned time, stations, or trip number, etc.

[0079] The cancellation operation refers to the server deleting the corresponding trip plan entry from the second trip data stored in the vehicle trip management library when the first trip data indicates that certain existing trip plans need to be removed.

[0080] S3022. If there is no conflict between the trips corresponding to the second trip data and the first trip data, delete the second trip data and store the first trip data in the vehicle trip management library.

[0081] If the server determines that there are no conflicts between the second trip data and the first trip data, it will delete the second trip data stored in the vehicle trip management database. Second trip data not yet stored in the vehicle trip management database will not be deleted. After deletion, the server will then store the first trip data in the vehicle trip management database.

[0082] The deletion operation performed by the server targets existing trip data within the vehicle trip management database that belongs to a trip management unit (e.g., a specific operator, a specific transportation hub, or a specific management area).

[0083] The subsequent storage operation stores the new trip plan entries contained in the first trip data. These two consecutive operations constitute a complete replacement process. The server, using the latest and most complete plan version represented by the first trip data, completely overwrites and replaces the original second trip data version in the vehicle trip management database by deleting first and then storing. This process aims to achieve a batch, overall update of trip plan data, ensuring that the data ultimately held in the vehicle trip management database is strictly consistent with the complete data packet submitted by the user in this request.

[0084] In one possible implementation, step S3022 includes: S30221. Generate a second prompt message, which is used to indicate that the second trip data should be deleted.

[0085] Before deleting the second trip data stored in the vehicle trip management database and storing the first trip data in the same database, the server generates a second notification message. This second notification message is a pre-notification message created by the server that announces in advance that the deletion operation on the second trip data stored in the vehicle trip management database is about to be performed.

[0086] The second notification message generated by the server includes key area identifiers associated with the second trip data that is about to be deleted, such as the affected trip management unit, the operating area to which the data belongs, or the transportation hub.

[0087] The second trip data that is about to be cleared from the vehicle trip management database may be being updated by other incomplete update processes (such as a new operation that is in the submission or review stage). If this deletion operation is performed, it will cause those updated trips in the database to become invalid or generate errors in update operation requests in other processes.

[0088] The second notification message is generated before the data change operation is executed, providing relevant users with a advance notice of the operation. By generating and sending this message in advance, the server publicizes the upcoming intention to replace batch data in the vehicle trip management database. This operation ensures the transparency and predictability of the data change process, allowing relevant parties to know in advance that the old data version will be cleared and replaced. It also allows users who may be affected and have other pending operation requests for the same database to be aware of the risks in advance, providing preliminary information for possible coordinated modifications or status confirmations.

[0089] In this embodiment, by specifically distinguishing update requests into those supporting single-item additions, adjustments, or cancellations, and those supporting batch file imports and overall replacements, the method can simultaneously adapt to two different business scenarios: refined single-point changes and large-scale overall replacements. This design improves the flexibility and practicality of the method for different update needs and operation modes.

[0090] When using the update method of clearing first and then inserting all data, a second prompt message is generated and issued to proactively notify the user of the data deletion operation. This allows users or administrators to clearly know that a major change has occurred in the vehicle trip management database, namely the deletion of existing data. This improves the transparency and traceability of the data change process, facilitating auditing or quickly locating the source of the operation when doubts arise.

[0091] In one embodiment, the vehicle trip update method further includes: S303. Detect conflicts between the trips corresponding to the second trip data and the first trip data respectively.

[0092] After receiving the first request from the first user, the server performs conflict detection on the trips corresponding to the second trip data and the first trip data, respectively. Conflict detection is a data comparison and logical judgment process performed by the server, aiming to identify whether there are any incompatible contradictions between the new plan represented by the first trip data and the existing plan represented by the second trip data.

[0093] The server performs conflict detection to proactively identify and flag potential resource contentions or timing inconsistencies before allowing any new schedule data to take effect. This pre-emptive automated check prevents conflicting schedules from being submitted to the vehicle schedule management database simultaneously, ensuring data consistency and executability from the outset and avoiding operational chaos caused by schedule conflicts.

[0094] In one possible implementation, step S303 includes: S3031. Compare the preset key fields in the first travel data and the second travel data.

[0095] When performing conflict detection, the server first prepares the data. The server places the first trip data included in the first request, the second trip data read from the vehicle trip management database, and the second trip data not yet updated in the vehicle trip management database into the same set. This ensures that the benchmark for conflict detection is all relevant plan information known to the server at that moment, thus guaranteeing the comprehensiveness and accuracy of the detection results.

[0096] After preparing the dataset, the server performs a duplicate check on the data in the dataset based on preset key fields. These preset key fields include trip identifiers, time information, and management information. For example, a trip identifier can be a unique number or code that identifies a trip plan, such as a flight number in the aviation industry or a train number in the railway industry. Time information includes the planned date, departure and arrival times, schedule, and time period identifier. Management unit information refers to the trip's management organization or resource jurisdiction unit, such as the airport code, station name, and operating company code.

[0097] The server iterates through and compares each trip data entry in the dataset. Specifically, it uses each plan entry in the first trip data as a benchmark and matches it against all other entries in the dataset (including itself, database data, and other requested data) for key fields to determine whether an entry in the first trip data has an entry with the same key field in other parts of the dataset.

[0098] By identifying preset key fields, the system efficiently, quickly, and accurately identifies whether there is a duplicate conflict between the first trip data and the second trip data. This judgment is the key basis for determining the process direction (generating prompts or submitting for review).

[0099] S3032. Based on the comparison results, determine whether there are situations where the trips corresponding to the second trip data and the first trip data cannot be executed simultaneously in terms of time and / or location.

[0100] If this situation exists, it is determined that there is a conflict between the second trip data and the trip corresponding to the first trip data.

[0101] After comparing the preset key fields in the first trip data and the second trip data, the server performs an operation to determine whether there are situations where the trips corresponding to the second trip data and the first trip data cannot be executed simultaneously in terms of time or location, based on the comparison results.

[0102] Situations where two plans cannot be executed simultaneously in terms of time or location, such as when two plans completely or partially overlap in time, or when the key resources they compete to use (such as the same runway, the same platform, or the same vehicle) are the same resource in terms of location or entity, resulting in the inability of both plans to be executed effectively.

[0103] When the server confirms the existence of this situation, it determines that there is a conflict between the second trip data and the trip corresponding to the first trip data.

[0104] In this embodiment of the application, conflict detection is performed on the trips corresponding to the second trip data and the first trip data respectively. By streamlining the conflict detection process, duplicate data can be screened before data approval, thereby reducing the risk of data conflict.

[0105] By comparing the trip data to be detected with the second trip data and using preset key fields for duplicate judgment, it is possible to achieve efficient traversal and comparison of large-scale datasets, making the conflict detection process highly efficient and responsive.

[0106] In one embodiment, step S302 further includes: S3023. Initiate an approval process. The approval process is used to determine whether to allow updating the second trip data based on the first trip data. After determining that there are no conflicts between the trips corresponding to the second trip data and the first trip data, the server initiates an approval process. The approval process is a control process created and managed by the server, which performs serialization review and decision-making on the first request. Its functional goal is to make a final decision on whether to allow the update of the second trip data based on the first trip data.

[0107] The server-initiated approval process consists of one or more sequential review stages. Each review stage is associated with a review entity with corresponding review authority, representing responsible personnel or departments at different levels within the trip management unit. For example, these stages could correspond sequentially to the review responsibilities of different levels, such as grassroots operating agencies, regional management team leaders, and the central dispatch office.

[0108] The following access control operations are performed at each review stage of the approval process: S3024. Configure exclusive access permissions for the first reviewing entity corresponding to the approval request in the review stage to perform review operations. During the period when the exclusive access permissions are in effect, prevent the second reviewing entity from performing review operations on the approval request until the review stage is completed and the exclusive access permissions are released.

[0109] Once the review process begins, the server implements access control at each specific review stage. A review stage refers to an independent phase in the process where a specific role reviews and makes decisions. The server sets an access permission for update requests currently in that review stage. This access permission specifically refers to a temporary, exclusive permission to perform the review at that stage, granting or associating it with a specific review user. This can be represented by setting a lock icon in the database to indicate that the request is being processed.

[0110] An access control mechanism was established for each review stage to ensure that at any given time, for a specific update request, only one valid review operation is allowed within the same review stage.

[0111] During the period when access permissions are in effect—that is, from the time permissions are successfully set until they are revoked—the server will proactively block any other audit attempts that occur within the same audit phase and target the same update request.

[0112] Other review operations refer to actions initiated by other review users to review the same request (such as viewing, approving, or rejecting). The server prevents requests by verifying the access permission status of the current request. For example, if the request is detected to be in a "locked" or "processing" state, the server will reject the new review operation request.

[0113] The purpose of preventing concurrent operations is to force the serialization of operations within the review process, preventing data update logic confusion, decision conflicts, or errors in the final data entered into the database due to multiple people reviewing at the same time or a single person submitting review decisions repeatedly.

[0114] When an update request at a certain review stage completes all the necessary review operations at that stage, such as when the reviewing user makes a clear approval or rejection decision and successfully submits the request, the server will remove the access permissions set for that request at that stage.

[0115] The release operation means clearing or invalidating previously set exclusive identifiers, such as deleting expired lock identifiers in the database.

[0116] Once the review process is completed legally, the resource lock should be released promptly so that the update request can flow normally to the next stage (such as the next review level or execution update) according to the process rules, or the same stage can be allowed to process it again when necessary (such as resubmission after rejection), thereby ensuring the smooth progress of the review process.

[0117] In this embodiment, access control for the review process is achieved by setting access permissions for an update request being processed at any stage of the review process and preventing other concurrent review operations on the same request while the permissions are in effect. This ensures that no update request is processed simultaneously or repeatedly by multiple people in a specific review stage, thereby preventing data inconsistency or duplicate entries caused by concurrent operations during the review phase.

[0118] In one embodiment, the vehicle trip update method further includes: S304, The terminal device displays the first interface.

[0119] The first interface displays the updates to the second trip data stored in the vehicle trip management database based on the first trip data. During the review process, the server provides this first interface to the reviewing user. This first interface is a graphical interactive page specifically designed to assist in review decisions. It visually displays the changes in planned volume within a specified time period before and after the first trip data update. Planned volume refers to the number of vehicle trips (such as flights or train services) scheduled within a specific time unit (e.g., one hour, one day, or one week) at a particular trip management unit (e.g., an airport or train station). The specified time period is the time range that the review rules or the reviewing user focus on, such as a 24-hour period within a day.

[0120] To achieve this functionality, the server performs data integration and comparison calculations in the background. It retrieves the trip data included in the currently pending update requests and simulates the planned volume distribution that would occur within a specified time period if this data were approved and added to the database. Simultaneously, the server retrieves the original planned volume distribution from the vehicle trip management database for the same specified time period under the current state. The server then logically compares the updated simulated data with the existing data before the update.

[0121] The server then generates a comparison view and displays it on the first interface. This view, in the form of a chart (e.g., a bar chart or line graph), clearly shows the planned volume values ​​for each sub-period (e.g., each hour) before and after the simulated update. By observing the first interface, the reviewing user can intuitively determine whether the update will cause the planned volume in any time period to exceed the preset capacity threshold.

[0122] It provides auditing users with an intuitive, data-driven decision support tool. By displaying a comparison of planned volume changes before and after the update, auditing users can efficiently and accurately assess the impact of this update on overall resource consumption or network traffic, thereby making more scientific and compliant auditing decisions and ensuring the stability and optimization of the vehicle trip management database.

[0123] In this embodiment, a first interface is provided to display the changes in the itinerary before and after the update of the first itinerary data, offering an intuitive data comparison view to the reviewing user. This allows the reviewing user to clearly and quickly assess the impact of the update on resource consumption, thereby assisting them in making more accurate review decisions and improving the efficiency and quality of the review process.

[0124] The following section, using a specific example from an aviation scenario, further explains the vehicle journey plan update method of this application. Figure 4 This is a schematic diagram of a flight schedule seasonal update process, such as... Figure 4 As shown: The following section, using a specific example and a user as an example, further introduces the vehicle trip plan update method of this application. Figure 4 This is a schematic diagram of a flight schedule seasonal update process, such as... Figure 4 As shown: S400, the first user submitted a seasonal update request.

[0125] The first user (e.g., an employee of an airline) uploads a file containing batch itinerary planning data (first itinerary data) through the client interface, initiating a first request to the server. This request aims to completely replace and update the plans in the seasonal flight plan management database (vehicle itinerary management database). The first itinerary data file includes complete itinerary planning data, covering key information such as flight number, origin and destination airports, scheduled times, and execution cycle.

[0126] S401, The server parses the file content and performs conflict detection.

[0127] After receiving the file, the server parses the data within as the first pass data. Subsequently, the server performs conflict detection.

[0128] The server creates a data collection (e.g., a List) to integrate the following two types of data: First trip data: the trip plan parsed from the file.

[0129] Second trip data: Currently stored trip plans read from the trip plan management library, as well as trip plans included in other submitted but not yet approved update requests.

[0130] Subsequently, the server uses data processing techniques (e.g., the Java Stream API) to traverse and compare the aforementioned collection. For each plan in the first itinerary data, based on preset key fields (such as plan identifier, time, and location), it determines whether there are duplicate entries in other parts of the collection (i.e., the second itinerary data).

[0131] S402. The server generates corresponding prompts or submits approval processes based on the test results.

[0132] If duplicate data is detected (i.e., a travel plan conflict exists), the server generates an initial notification message, indicating which specific plans in the user's file are conflicting, along with information about the conflicting parties. The user can then modify the file content according to the notification and resubmit.

[0133] The server generates a second prompt message, clearly informing the user that after the current overall replacement update request is executed, the data in the database on which the aforementioned incremental request is based will be cleared, causing it to fail to match and take effect, prompting the user to coordinate.

[0134] If no conflict is detected, the server automatically submits the first request to the approval process. The approval process consists of multiple levels of review, conducted sequentially by different levels of review bodies.

[0135] S403. The server performs concurrency control and provides an auxiliary analysis interface during the approval process.

[0136] At any stage of the review process, the server uses a distributed locking mechanism (e.g., Redis-based setnx or expire commands) to set exclusive access permissions for the update request currently being reviewed, preventing the same request from being processed simultaneously or repeatedly by multiple review subjects.

[0137] During the review process, the server provides the reviewing entity with a primary interface to visually compare the planned changes in volume over a specific time dimension before and after the batch update and data merging, thus assisting in review decisions.

[0138] S404. After the server is approved, a complete replacement update will be performed.

[0139] Once the entire approval process is complete, the server will perform an update operation.

[0140] First, the server deletes all existing trip data (second trip data) within the target range from the trip planning management database.

[0141] Subsequently, the server stores the complete itinerary plan (first itinerary data) in this file, completing the overall data replacement and update.

[0142] As can be seen, the above mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, the embodiments of this application provide corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the modules and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed by hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this invention.

[0143] This application embodiment can divide a vehicle trip plan updating device into functional modules based on the above method example. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated module can be implemented in hardware or as a software functional module. Optionally, the module division in this application embodiment is illustrative and only represents a logical functional division; other division methods may be used in actual implementation.

[0144] In some embodiments, this application also provides a vehicle trip plan updating device. This vehicle trip plan updating device may include one or more functional modules for implementing the vehicle trip plan updating method of the above method embodiments.

[0145] For example, Figure 5 This is a schematic diagram illustrating the composition of a vehicle trip plan updating device provided in an embodiment of this application. Figure 5 As shown, the vehicle trip plan update device 500 includes: a request receiving module 501, a prompt generation module 502, and a trip update module 503.

[0146] The request receiving module 501 is used to receive a first request from a first user. The first request is used to request the update of second trip data based on first trip data. The first request includes the first trip data and the second trip data is trip data submitted by the first user and used to store in the vehicle trip management library. The prompt generation module 502 is used to generate a first prompt message when there is a conflict between the second trip data and the first trip data. The first prompt message is used to instruct the first user to modify the first trip data. The trip update module 503 is used to update the second trip data based on the first trip data when there is no conflict between the trips corresponding to the second trip data and the first trip data.

[0147] In one embodiment, the trip update module 503 is further configured to perform add, adjust or cancel trip data operations on the second trip data based on the first trip data, provided that there is no conflict between the trips corresponding to the second trip data and the first trip data. Alternatively, if there are no conflicts between the trips corresponding to the second trip data and the first trip data, delete the second trip data and store the first trip data in the vehicle trip management library.

[0148] In one embodiment, the prompt generation module 502 is further configured to generate a second prompt message, which is used to instruct the deletion of the second trip data.

[0149] In one embodiment, the vehicle trip plan update device 500 further includes a conflict detection module 504, which is used to perform conflict detection on the trips corresponding to the second trip data and the first trip data, respectively.

[0150] In one embodiment, the conflict detection module 504 is further configured to compare the preset key fields in the first trip data and the second trip data, and determine whether there is a situation where the trips corresponding to the second trip data and the first trip data cannot be executed simultaneously in terms of time and / or location based on the comparison result. If such a situation exists, it is determined that there is a conflict between the trips corresponding to the second trip data and the first trip data.

[0151] In one embodiment, the vehicle trip plan update device 500 further includes a trip approval module 505 for initiating an approval process, the approval process being used to determine whether to allow updating the second trip data based on the first trip data; The following access control operations are performed at each review stage of the approval process: Configure exclusive access permissions for the first review entity corresponding to the approval request in the review stage to perform review operations. During the period when the exclusive access permissions are in effect, prevent the second review entity from reviewing the approval request until the review stage is completed and the exclusive access permissions are released.

[0152] In one embodiment, the trip approval module 505 is further configured to display a first interface, which displays the update status of the second trip data based on the first trip data.

[0153] In the case of implementing the functions of the integrated modules described above in hardware, this embodiment of the invention provides a possible structural schematic diagram of the electronic device involved in the above embodiments. For example... Figure 6 As shown, the electronic device 600 includes: a processor 602, a communication interface 603, and a bus 604. Optionally, the electronic device 600 may also include a memory 601.

[0154] Processor 602 may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 602 may be a central processing unit, a general-purpose processor, a digital signal processor, an application-specific integrated circuit (ASIC), a field-programmable gate array (FPGA), or other programmable logic devices, transistor logic devices, hardware components, or any combination thereof. It may implement or execute various exemplary logic blocks, modules, and circuits described in conjunction with the disclosure of this application. Processor 602 may also be a combination that implements computing functions, such as including one or more microprocessor combinations, a combination of a DSP and a microprocessor, etc.

[0155] Communication interface 603 is used to connect to other devices via a communication network. This communication network can be Ethernet, wireless access network, wireless local area network (WLAN), etc.

[0156] The memory 601 may be a read-only memory (ROM) or other type of static storage device capable of storing static information and instructions, random access memory (RAM) or other type of dynamic storage device capable of storing information and instructions, or electrically erasable programmable read-only memory (EEPROM), disk storage medium or other magnetic storage device, or any other medium capable of carrying or storing desired program code in the form of instructions or data structures and accessible by a computer, but is not limited thereto.

[0157] In one possible implementation, the memory 601 can exist independently of the processor 602. The memory 601 can be connected to the processor 602 via a bus 604 and is used to store instructions or program code. When the processor 602 calls and executes the instructions or program code stored in the memory 601, it can implement the vehicle trip plan update method provided in this embodiment of the invention.

[0158] In another possible implementation, the memory 601 can also be integrated with the processor 602.

[0159] Bus 604 can be an extended industry standard architecture (EISA) bus, etc. Bus 604 can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 6 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0160] Through the above description of the implementation methods, those skilled in the art can clearly understand that, for the sake of convenience and brevity, only the division of the above functional modules is used as an example. In actual applications, the above functions can be assigned to different functional modules as needed, that is, the internal structure of the service calling device can be divided into different functional modules to complete all or part of the functions described above.

[0161] This application also provides a computer-readable storage medium. All or part of the processes in the above method embodiments can be executed by computer instructions instructing related hardware. The program can be stored in the aforementioned computer-readable storage medium, and when executed, it can include the processes of the above method embodiments. The computer-readable storage medium can be any of the foregoing embodiments or memory. The aforementioned computer-readable storage medium can also be an external storage device of the aforementioned service invocation device, such as a plug-in hard drive, smart media card (SMC), secure digital (SD) card, flash card, etc., equipped on the aforementioned service invocation device. Further, the aforementioned computer-readable storage medium can include both internal storage units of the aforementioned service invocation device and external storage devices. The aforementioned computer-readable storage medium is used to store the aforementioned computer program and other programs and data required by the aforementioned service invocation device. The aforementioned computer-readable storage medium can also be used to temporarily store data that has been output or will be output.

[0162] This application also provides computer instructions. All or part of the processes in the above method embodiments can be executed by computer instructions to instruct related hardware (such as computers, processors, network devices, and terminals). The program can be stored in the aforementioned computer-readable storage medium.

[0163] This application also provides a computer program product that, when run on a computer, causes the above-described method embodiments to be executed.

[0164] This application also provides a chip system. The chip system may be composed of chips or may include chips and other discrete devices, without limitation. The chip system includes a processor and a transceiver. All or part of the processes in the above method embodiments can be completed by this chip system, such as the chip system being used to implement the functions performed by the network devices or terminals in the above method embodiments.

[0165] In one possible design, the chip system further includes a memory for storing program instructions and / or data. When the chip system is running, the processor executes the program instructions stored in the memory to enable the chip system to perform the functions performed by the network device or terminal in the above method embodiments.

[0166] The above are merely specific embodiments of this application, but the scope of protection of this application is not limited thereto. Any changes or substitutions 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.

Claims

1. A method for updating a trip plan of a vehicle, the method comprising: include: Receive a first request from the first user, the first request being used to request an update of the second trip data based on the first trip data, the first request including the first trip data, the second trip data being trip data submitted by the first user and used to store in the vehicle trip management library; In the event of a conflict between the second trip data and the first trip data, a first prompt message is generated, which instructs the first user to modify the first trip data. If there is no conflict between the trips corresponding to the second trip data and the first trip data, the second trip data is updated according to the first trip data.

2. The method of claim 1, wherein, The step of updating the second trip data based on the first trip data when there is no conflict between the trips corresponding to the second trip data and the first trip data includes: If there is no conflict between the trips corresponding to the second trip data and the first trip data, the second trip data is used to perform trip data addition, adjustment or cancellation operations based on the first trip data; Alternatively, if there is no conflict between the trips corresponding to the second trip data and the first trip data, the second trip data is deleted, and the first trip data is stored in the vehicle trip management library.

3. The method of claim 2, wherein, The method further includes, in the case of deleting the second trip data and storing the first trip data in the vehicle trip management library: A second prompt message is generated, which instructs the deletion of the second trip data.

4. The method of claim 1, wherein, The method further includes: performing conflict detection on the trips corresponding to the second trip data and the first trip data respectively.

5. The method according to claim 4, characterized in that, The conflict detection of the trips corresponding to the second trip data and the first trip data respectively includes: Based on the comparison of preset key fields in the first trip data and the second trip data, it is determined whether there is a situation where the trips corresponding to the second trip data and the first trip data cannot be executed simultaneously in terms of time and / or location. If such a situation exists, it is determined that there is a conflict between the trips corresponding to the second trip data and the first trip data.

6. The method according to claim 1, characterized in that, Before updating the second trip data based on the first trip data, when there is no conflict between the trips corresponding to the second trip data and the first trip data, the method further includes: Initiate an approval process, which is used to determine whether to allow updating the second trip data based on the first trip data. In this approval process, the following access control operations are performed at each review stage: Configure exclusive access permissions for the first reviewing entity corresponding to the approval request in the review stage to perform review operations. During the period when the exclusive access permissions are in effect, prevent the second reviewing entity from reviewing the approval request until the review stage is completed, at which point the exclusive access permissions are released.

7. The method according to any one of claims 1-6, characterized in that, The method further includes: displaying a first interface, the first interface being used to display the update status of the second trip data based on the first trip data.

8. A vehicle trip plan updating device, characterized in that, include: The request receiving module is used to receive a first request from the first user. The first request is used to request the update of the second trip data based on the first trip data. The first request includes the first trip data and the second trip data is trip data submitted by the first user and used to store in the vehicle trip management library. The prompt generation module is used to generate a first prompt message when there is a conflict between the second trip data and the first trip data, respectively. The first prompt message is used to instruct the first user to modify the first trip data. The trip update module is used to update the second trip data according to the first trip data when there is no conflict between the trips corresponding to the second trip data and the first trip data.

9. An electronic device, characterized in that, The device includes a processor and a memory, the processor being coupled to the memory; the memory is used to store computer instructions, which are loaded and executed by the processor to enable the computer device to implement the trip plan update method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium includes computer-executable instructions that, when executed on a computer, cause the computer to perform the trip plan update method according to any one of claims 1 to 7.

11. A computer program product, characterized in that, The computer program product includes a computer program that, when run on an electronic device, causes the electronic device to perform the trip plan update method as described in any one of claims 1 to 7.

Images