Event processing method, apparatus and device in vehicle operation, and storage medium

Abstract

Embodiments of the present disclosure disclose a method and device for processing events in vehicle operation, equipment and storage medium, wherein the method comprises: in response to obtaining an abnormal event reported by an event vehicle, generating at least one work order for processing the abnormal event based on an abnormal code of the abnormal event and a work order configuration table, the abnormal code being used to identify the event type of the abnormal event; sending each work order in the at least one work order to a corresponding processing platform; updating the work order status of each work order based on the response message returned by the processing platform corresponding to each work order; and in response to the work order status of the at least one work order all indicating that the corresponding work order has been completed, performing a processing completion operation of the abnormal event. The present disclosure can automatically generate a work order according to the abnormal event reported by the vehicle, and implement the processing of the event by the corresponding processing platform, thereby realizing the timely processing of the event in the full unmanned driving mode.

Description

Technical Field

[0001] This disclosure relates to autonomous driving technology and information processing technology, and more particularly to a method, apparatus, device, and storage medium for handling events during vehicle operation. Background Technology

[0002] With the introduction of fully driverless driving mode, vehicles rely entirely on the autonomous driving system for operation and control during operation. In fully driverless driving mode, various abnormal events frequently occur, such as vehicle dirt, vehicle exceeding the parking time limit, and vehicle collisions.

[0003] How to handle various abnormal events encountered by vehicles in fully driverless mode and ensure the safe and stable operation of vehicles in this mode is a technical issue that deserves attention. Summary of the Invention

[0004] To address the aforementioned technical problems, embodiments of this disclosure provide a method, apparatus, device, and storage medium for handling events during vehicle operation.

[0005] According to one aspect of the present disclosure, an event handling method for vehicle operation is provided, comprising: in response to receiving an abnormal event reported by an event vehicle, generating at least one work order for handling the abnormal event based on an abnormal code of the abnormal event and a work order configuration table, wherein the abnormal code is used to identify the event type of the abnormal event; sending each work order in the at least one work order to a corresponding processing platform; updating the work order status of each work order based on a response message returned by the processing platform corresponding to each work order; and in response to the work order status of the at least one work order indicating that the at least one work order has been completed, performing an abnormal event handling completion operation, wherein the abnormal event handling completion operation includes at least one of the following: setting the status of the abnormal event to completed, and deleting at least one work order of the abnormal event from a resource pool, wherein the resource pool is used to store incomplete work orders.

[0006] According to another aspect of the present disclosure, an event processing device for vehicle operation is provided, comprising: a work order generation module, configured to, in response to receiving an abnormal event reported by an event vehicle, generate at least one work order for processing the abnormal event based on an abnormal code of the abnormal event and a work order configuration table, wherein the abnormal code is used to identify the event type of the abnormal event; a sending module, configured to send each of the at least one work order to a corresponding processing platform; an updating module, configured to update the work order status of each work order based on a response message returned by the processing platform corresponding to each work order; and a processing completion module, configured to, in response to the work order status of at least one work order indicating that at least one work order has been completed, perform an abnormal event processing completion operation, wherein the abnormal event processing completion operation includes at least one of the following: setting the status of the abnormal event to completed, and deleting at least one work order of the abnormal event from a resource pool, wherein the resource pool is used to store incomplete work orders.

[0007] According to another aspect of the present disclosure, an event handling system for vehicle operation is provided, comprising: at least one processing platform, at least one client connected to the at least one processing platform, and the aforementioned event handling device; the event handling device is configured to, in response to receiving an abnormal event reported by an event vehicle, generate at least one work order for handling the abnormal event based on an abnormal code of the abnormal event, wherein the abnormal code is used to identify the event type of the abnormal event; send each of the at least one work order to the corresponding processing platform; update the work order status of each work order based on a response message returned by the processing platform corresponding to each work order; and, in response to the work order status of at least one work order indicating that at least one work order has been completed, perform an abnormal event handling completion operation, wherein the abnormal event handling completion operation includes at least one of the following: setting the status of the abnormal event to completed, and deleting at least one work order of the abnormal event from a resource pool, wherein the resource pool is used to store incomplete work orders; at least one processing platform is configured to, upon receiving a work order sent by the event handling device, send the abnormal event to the corresponding client respectively, and return a response message to the event handling device when the client returns a processing result; the client is configured to, upon receiving an abnormal event sent by the processing platform, output the abnormal event, and have the user of the client handle the abnormal event.

[0008] According to another aspect of the present disclosure, a computer-readable storage medium is provided, which stores computer program instructions that, when executed, implement the above-described method.

[0009] According to another aspect of the present disclosure, an electronic device is provided, the electronic device comprising:

[0010] Memory, used to store computer program products;

[0011] A processor is used to execute a computer program product stored in memory, and when the computer program product is executed, it implements the above method.

[0012] According to another aspect of the present disclosure, a computer program product is provided, including computer program instructions, characterized in that, when executed by a processor, the computer program instructions implement the above-described method.

[0013] Based on the vehicle operation event handling method, apparatus, device, and storage medium provided in the above embodiments of this disclosure, when an abnormal event reported by an event vehicle is obtained, at least one work order for handling the abnormal event is automatically generated according to the abnormal code of the abnormal event, and each of the at least one work order is sent to the corresponding processing platform. Based on the response message returned by the processing platform corresponding to each work order, the work order status of each work order is updated. When the work order status of at least one work order indicates completion, the processing completion operation of the abnormal event is executed. Therefore, the technical solution of this disclosure can automatically generate work orders based on abnormal events reported by event vehicles, and have the corresponding processing platform handle the events, achieving timely handling of vehicle events in fully autonomous driving mode. The collaborative processing of events by various platforms can improve the efficiency of abnormal event handling, thereby ensuring the safe and stable operation of vehicles in fully autonomous driving mode.

[0014] The technical solutions of this disclosure will be further described in detail below with reference to the accompanying drawings and embodiments. Attached Figure Description

[0015] The above and other objects, features, and advantages of this disclosure will become more apparent from the more detailed description of the embodiments thereof in conjunction with the accompanying drawings. The drawings are provided to further illustrate the embodiments of this disclosure and form part of the specification. They are used together with the embodiments of this disclosure to explain the disclosure and do not constitute a limitation thereof. In the drawings, the same reference numerals generally represent the same components or steps.

[0016] This disclosure will become clearer with reference to the accompanying drawings and the following detailed description, wherein:

[0017] Figure 1 A schematic diagram of the system architecture applicable to the incident handling method in vehicle operation disclosed herein;

[0018] Figure 2 A flowchart illustrating one embodiment of the incident handling method for vehicle operation disclosed herein;

[0019] Figure 3 A flowchart illustrating an embodiment of the incident handling method for vehicle operation disclosed herein, which generates work orders;

[0020] Figure 4 A flowchart illustrating another embodiment of the method for generating work orders in vehicle operation as disclosed herein;

[0021] Figure 5 A flowchart illustrating another embodiment of the incident handling method in vehicle operation disclosed herein;

[0022] Figure 6 This is a flowchart illustrating the workflow of work order status in the event handling method for vehicle operation disclosed herein.

[0023] Figure 7 This is a schematic diagram of the structure of one embodiment of the event handling device for vehicle operation disclosed herein;

[0024] Figure 8 This is a schematic diagram of the structure of yet another embodiment of the event handling device for vehicle operation disclosed herein;

[0025] Figure 9 This is a structural diagram of an electronic device provided as an illustrative embodiment of the present disclosure. Detailed Implementation

[0026] Hereinafter, exemplary embodiments according to the present disclosure will be described in detail with reference to the accompanying drawings. Obviously, the described embodiments are merely some embodiments of the present disclosure, and not all embodiments of the present disclosure, and it should be understood that the present disclosure is not limited to the exemplary embodiments described herein.

[0027] It should be noted that, unless otherwise specifically stated, the relative arrangement, numerical expressions, and values ​​of the components and steps set forth in these embodiments do not limit the scope of this disclosure.

[0028] Those skilled in the art will understand that the terms "first," "second," etc., in the embodiments of this disclosure are only used to distinguish different steps, devices, or modules, and do not represent any specific technical meaning, nor do they indicate a necessary logical order between them.

[0029] It should also be understood that in the embodiments disclosed herein, "a plurality of" may refer to two or more, and "at least one" may refer to one, two or more.

[0030] It should also be understood that any component, data or structure mentioned in the embodiments of this disclosure can generally be understood as one or more unless expressly defined or given to the contrary in the context.

[0031] Furthermore, the term "and / or" in this disclosure is merely a description of the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. Additionally, the character " / " in this disclosure generally indicates that the preceding and following related objects have an "or" relationship.

[0032] It should also be understood that the description of the various embodiments in this disclosure emphasizes the differences between the various embodiments, and the similarities or similarities can be referred to each other. For the sake of brevity, they will not be described in detail.

[0033] At the same time, it should be understood that, for ease of description, the dimensions of the various parts shown in the accompanying drawings are not drawn according to actual scale.

[0034] The following description of at least one exemplary embodiment is merely illustrative and is in no way intended to limit this disclosure or its application or use.

[0035] Techniques, methods, and equipment known to those skilled in the art may not be discussed in detail, but where appropriate, such techniques, methods, and equipment should be considered part of the specification.

[0036] It should be noted that similar labels and letters in the following figures indicate similar items; therefore, once an item is defined in one figure, it does not need to be discussed further in subsequent figures.

[0037] The embodiments disclosed herein can be applied to electronic devices such as terminal devices, computer systems, and servers, and can operate together with a wide range of other general-purpose or special-purpose computing system environments or configurations. Examples of well-known terminal devices, computing systems, environments, and / or configurations suitable for use with electronic devices such as terminal devices, computer systems, and servers include, but are not limited to: personal computer systems, server computer systems, thin clients, thick clients, handheld or laptop devices, microprocessor-based systems, set-top boxes, programmable consumer electronics, network PCs, minicomputer systems, mainframe computer systems, and distributed cloud computing environments including any of the above systems, etc.

[0038] Electronic devices such as terminal devices, computer systems, and servers can be described in the general context of computer system executable instructions (such as program modules) executed by a computer system. Typically, program modules can include routines, programs, object programs, components, logic, data structures, etc., which perform specific tasks or implement specific abstract data types. Computer systems / servers can be implemented in distributed cloud computing environments, where tasks are executed by remote processing devices linked through communication networks. In distributed cloud computing environments, program modules can reside on local or remote computing system storage media, including storage devices.

[0039] Exemplary System

[0040] The technical solution provided in this embodiment is used in a work order system. When an abnormal event occurs in a vehicle driving in fully autonomous driving mode, the abnormal event can be reported to the work order system. The work order system can then create a corresponding work order based on the event code of the abnormal event and automatically send each work order to the corresponding processing platform for processing, ensuring rapid processing of abnormal events.

[0041] Figure 1 A schematic diagram of the system architecture applicable to the incident handling method for vehicle operation disclosed herein, as shown in the figure. Figure 1As shown, the event handling system may include a vehicle 101 operating in fully autonomous driving mode, a network 102, a work order management platform 103, a work order processing platform 104, and a client 105. The network 102 serves as the medium for providing communication links between the vehicle 101 and the work order management platform 103, between the work order management platform 103 and the work order processing platform 104, and between the work order processing platform 104 and the client 105. The network 102 may include various connection types, such as wired or wireless communication links or fiber optic cables, etc.

[0042] Vehicle 101, which is driving in fully autonomous driving mode, can be equipped with a vehicle health status detection device. This device can automatically detect the vehicle's health status and automatically report abnormal events to the work order management platform 103 when such events occur, such as a collision, abnormal takeover of the vehicle, red light alarm during autonomous driving, dirt on the vehicle, or parking time exceeding the limit.

[0043] When the work order management platform 103 receives an abnormal event, it can determine the work order to be generated based on the abnormal event's exception code. After generating the work order, it sends the work order to the corresponding work order processing platform 104, so that the work order processing platform 104 can perform troubleshooting based on the event information. For example, when receiving a red light event for autonomous driving software, a trip service work order and a maintenance troubleshooting work order can be generated. The trip service work order is sent to the trip service processing platform, and the maintenance troubleshooting work order is sent to the maintenance troubleshooting processing platform. Alternatively, when receiving a vehicle collision event, a trip service work order, a ground rescue work order, and a remote assistance work order can be created. The trip service work order is sent to the trip service processing platform, the ground rescue work order is sent to the ground rescue processing platform, and the remote assistance work order is sent to the remote assistance processing platform.

[0044] When a work order is received, the work order processing platform 104 selects the person responsible for handling the abnormal event and sends an event handling message to the client 105 corresponding to that person.

[0045] After receiving an event processing message, the client 105 allows the user to perform event processing operations based on the message and return the processing result to the work order processing platform 104. The client 105 includes, but is not limited to, mobile terminals such as mobile phones, laptops, personal digital assistants (PDAs), portable Android devices (PADs), and portable media players (PMPs), as well as fixed terminals such as digital televisions, desktop computers, and smart home appliances.

[0046] It should be noted that the event handling method for vehicle operation provided in the embodiments of this disclosure can be executed by the work order management platform 103, and correspondingly, the event handling device for vehicle operation can be set in the work order management platform 103.

[0047] It should be understood that Figure 1 The number of vehicles 101, networks 102, work order management platforms 103, work order processing platforms 104, and clients 105 operating in fully driverless mode is merely illustrative. Depending on implementation needs, any number of vehicles 101, networks 102, work order management platforms 103, work order processing platforms 104, and clients 105 operating in fully driverless mode can be included.

[0048] Exemplary methods

[0049] Figure 2 This is a flowchart illustrating an embodiment of the event handling method for vehicle operation disclosed herein; the event handling method can be applied to... Figure 1 On the illustrated work order management platform 103 (such as a computer system or server), such as Figure 2 As shown, the event handling method includes steps 201 to 204. Each step is explained below.

[0050] In step 201, in response to receiving an abnormal event reported by the event vehicle, at least one work order is generated for handling the abnormal event based on the abnormal event's abnormal code and the work order configuration table. The abnormal code is used to identify the event type of the abnormal event.

[0051] Abnormal events are those that affect the normal operation of vehicles. There are various types of abnormal events, and the handling methods differ depending on the type. Examples include safety-related events, trip assurance-related events, trip violation-related events, vehicle anomaly-related events, vehicle congestion-related events, operational support-related events, and vehicle-cloud anomaly-related events. Anomaly codes identify the type of abnormal event. When reporting an abnormal event, the vehicle also reports the anomaly code so that the vehicle management platform can identify the type of abnormal event. For example, anomaly code 101001001 is used to identify a vehicle collision event within a traffic accident category of safety-related events.

[0052] Among them, safety events are used to indicate high-risk emergencies such as traffic accidents, vehicle intrusion, and abnormal takeovers, for example, vehicle collisions. Trip assurance events are used to indicate events that are likely to generate public opinion and safety hazards, such as passenger emergency assistance inside the vehicle and police assistance outside the vehicle, for example, passenger SOS requests. Trip violation events are used to indicate non-compliant passenger behavior during the trip that is likely to lead to safety hazards, for example, passengers operating in-vehicle facilities that should not be operated. Vehicle anomaly events are used to indicate vehicle malfunction events that are likely to generate safety hazards and public opinion related to traffic congestion, for example, autonomous driving red light warnings and dirt incidents. Vehicle congestion events are used to indicate events that will cause traffic congestion, for example, parking in non-parking areas. Operational assurance events are used to indicate events that will affect operational efficiency, for example, substandard vehicle interior cleanliness and vehicle refueling incidents. Vehicle-to-cloud anomaly events are used to indicate anomalies in vehicle-to-cloud communication, for example, vehicles unable to connect, remote assistance lag or black screens.

[0053] In this embodiment, there are several ways to obtain abnormal events, including: automatic reporting of abnormal events by vehicles and entry of abnormal events into the platform. Among them, abnormal events entered into the platform can include events that vehicles cannot automatically recognize, such as vehicles receiving parking tickets. Such events can be reported by other personnel to the maintenance personnel of the work order management platform by telephone or the Internet, and the maintenance personnel of the work order management platform can then enter the abnormal event into the platform.

[0054] Work orders are used to instruct work documents, serving as work plans for handling the abnormal event. Work order types include: trip service work orders, remote assistance work orders, ground rescue work orders, vehicle service work orders, and maintenance work orders. When generating work orders for an abnormal event, at least one trip service work order must be generated as the master work order, and at least one of the following work orders must also be generated: remote assistance work order, ground rescue work order, vehicle service work order, and maintenance work order. The master work order is the trip service work order, used to monitor whether the abnormal event has been resolved. Sub-work orders can include remote assistance work orders, ground rescue work orders, vehicle service work orders, and maintenance work orders. Remote assistance work orders are used to handle the event through remote assistance; ground rescue work orders instruct work orders to handle the event through on-site rescue, such as towing or road repair; vehicle service work orders instruct work orders to handle the event through vehicle repair; and maintenance work orders instruct work orders to handle the event through remote troubleshooting.

[0055] It is understood that autonomous vehicles can operate in fully driverless mode or in autonomous driving mode with a safety driver in the vehicle. The abnormal events to be handled by the technical solution disclosed herein are abnormal events that occur when the vehicle is operating in fully driverless mode.

[0056] In this example, a work order configuration table can be created in advance, which records the work order types corresponding to each event code. When the work order management platform obtains an abnormal event, it can obtain the work order type corresponding to the abnormal code from the work order configuration table based on the abnormal code of the abnormal event, and generate at least one work order to handle the abnormal event based on the obtained work order type.

[0057] In step 202, each work order in at least one work order is sent to the corresponding processing platform.

[0058] The processing platform is used to process various work orders, with different types of work orders sent to different processing platforms. For example, the master trip service work order is sent to the trip service processing platform, the remote assistance work order is sent to the remote assistance processing platform, the ground rescue work order is sent to the ground rescue processing platform, the maintenance work order is sent to the maintenance work order processing platform, and so on.

[0059] In this embodiment, when the work order management platform sends a work order to the processing platform, it also sends the work order identification information of each work order and the event information of the abnormal event. The event information of the abnormal event includes the event vehicle identifier, the event type (abnormal code), and the event vehicle location information.

[0060] In step 203, the work order status of each work order is updated based on the response message returned by the processing platform corresponding to each work order.

[0061] In this embodiment, after receiving a work order, the processing platform selects the appropriate person in charge to handle the event based on the work order, and feeds back the corresponding processing results to the work order management platform through response messages during and after the event handling process.

[0062] The work order status indicates the current state of a work order. Work order statuses can include: Created, Queued, Accepted, Reassigned, Processing, Completed, and Closed. "Created" is the initial status of a work order; the work order management platform sets the status to "Created" after creating each work order. "Queued" indicates that the work order has not yet been assigned to any responsible party and is in a queue. After a work order is created and sent to the corresponding processing platform, the platform can insert the work order into the corresponding work order queue; at this time, the work order status is "Queued." "Accepted" indicates that the work order has been sent to the corresponding responsible party, and that responsible party has accepted the work order through the client. "Reassigned" indicates that after the work order was accepted by the responsible party, it could not be processed within the set time or could not be processed at all, and the processing platform has chosen to reassign it to another responsible party. "Processing" indicates that the work order is being processed but has not yet been completed. "Completed" indicates the status after the work order has been processed by the responsible person and the completion action has been performed. "Closed" indicates the status after the responsible person has confirmed that the abnormal event was a false alarm and performed the closure action.

[0063] In this embodiment, the status transition of a work order is typically achieved by executing a key action. For example, if a user clicks the "Accept Order" button through the client interface, the work order status transitions to "Accepted." Alternatively, if ground rescue personnel click "Arrived at Scene" through the client interface after arriving at the scene, the work order status transitions to "Processing."

[0064] It should be noted that key actions corresponding to the flow of work order status can be preset. After receiving the corresponding key action, the corresponding change of work order status can be executed. After updating the work order status, the processing platform will synchronize the work order status to the work order management platform. Thus, the work order management platform can synchronously update the work order status and maintain the status of each work order for abnormal events.

[0065] In step 204, in response to the work order status indicating that at least one work order has been completed, an exception event handling completion operation is performed. The exception event handling completion operation includes at least one of the following: setting the status of the exception event to completed, and deleting at least one work order of the exception event from the resource pool, which is used to store incomplete work orders.

[0066] In this embodiment, after the processing platforms for each work order of the same abnormal event return a completed response message, the work order management platform can perform the processing completion operation for the abnormal event. The processing completion operation includes, but is not limited to, the following operations: setting the status of the abnormal event to completed, and deleting at least one work order of the abnormal event from the resource pool.

[0067] Through steps 201 to 204 above, when an abnormal event reported by an event vehicle operating in fully autonomous driving mode is obtained, at least one work order for handling the abnormal event is automatically generated based on the abnormal event's exception code. Each work order is sent to its corresponding processing platform for processing. When the work order status of at least one work order indicates completion, the processing completion operation for the abnormal event is executed. Therefore, the technical solution of this disclosure can automatically generate work orders for abnormal events reported by event vehicles in fully autonomous driving mode, and have the corresponding processing platform handle the events, achieving timely processing of events in fully autonomous driving mode. The collaborative processing of events by various platforms can also improve the efficiency of abnormal event processing, thereby ensuring the safe and stable operation of vehicles in fully autonomous driving mode.

[0068] Figure 3 This is a flowchart illustrating an embodiment of the event handling method for vehicle operation disclosed herein, specifically the generation of work orders. This embodiment uses the generation of work orders based on abnormal events as an example for illustrative purposes. Figure 3 As shown, the process includes steps 301 to 302. The following is a description of each step:

[0069] In step 301, the trigger frequency of the abnormal event is determined based on the abnormal code of the abnormal event and the event vehicle identifier of the event vehicle.

[0070] Each time an abnormal event is acquired, its abnormal code and the vehicle identifier are also obtained, thus identifying the vehicle that triggered the abnormal event. The trigger frequency indicates how often an abnormal event is triggered. For example, if the same vehicle triggers the abnormal event of a passenger not wearing a seatbelt 10 times consecutively within a set time period (such as half an hour), the corresponding trigger frequency is 10 times.

[0071] In this embodiment, each time the work order management platform receives an abnormal event, it will calculate the time and frequency at which the abnormal event represented by the abnormal code is triggered by the vehicle in question, based on the abnormal code and the vehicle identifier of the event.

[0072] In some implementations, a vehicle whitelist can be set up, which records the vehicle identifiers of vehicles that can handle abnormal events. When an abnormal event is detected, the vehicle identifier of the event can be queried from the vehicle whitelist. If it is found, a work order is generated for the abnormal event triggered by that vehicle according to the frequency control rules. If the vehicle identifier of the event is not found in the vehicle whitelist, it means that the vehicle that triggered the abnormal event is not a vehicle in the vehicle whitelist, and no work order is generated for that abnormal event. Therefore, it is not necessary to determine the triggering frequency of the abnormal event by the vehicle.

[0073] In step 302, in response to the trigger frequency meeting the frequency control rules, at least one work order is generated for handling the abnormal event based on the abnormal event's exception code and work order configuration table.

[0074] In this disclosure, frequency control rules are used to limit the frequency of generating work orders for abnormal events of event vehicles within a certain period of time, in order to prevent the generation of too many work orders for the same abnormal event, which would cause system overload and waste of resources. Frequency control rules typically include parameters such as defining the time interval and the number of frequency control operations.

[0075] In some implementations, for each type of abnormal event, the local database may store a frequency threshold that matches the type or priority of the abnormal event. For example, the frequency threshold for collision events in the safety category is 2 times per hour. That is, if two or one reported collision events are received within one hour, a corresponding work order is generated for both collision events and processed. However, if three reported collision events are received within one hour, no work order is generated for the last reported collision event. The frequency threshold for passenger violation events is 1 time per hour. If one reported passenger violation event is received within one hour, a corresponding work order is generated for that passenger violation event and processed. However, if more than two passenger violation events are received within one hour, a work order is generated only for the first passenger violation event.

[0076] In other implementations, when a different type of work order needs to be dispatched for the same event, if two or more dispatch requests are received, only one work order of that type will be generated. For example, for a red light event in autonomous driving software, a trip service work order and an operation and maintenance troubleshooting work order are generated. If the operation and maintenance troubleshooting platform finds that it cannot successfully troubleshoot the event during the process, it can report to the work order management platform, which will then generate a ground rescue work order for the same red light event in autonomous driving software. If the trip service work order also requests the work order management platform to generate a ground rescue work order for the same red light event in autonomous driving software, the work order management platform will only generate one ground rescue work order, and will not generate two ground rescue work orders.

[0077] In other implementations, if there are incomplete work orders for the same event and another report of the same event type is received, no further work order will be generated, even if the above frequency control rules are met. For example, the frequency control rule for collision events in the safety category is twice per hour. That is, if two reported collision events are received within one hour, and the work order for the first collision event has not yet been processed when the second collision event is received, no corresponding work order will be generated for the second collision event.

[0078] The rules for determining whether to generate a work order as defined in the above-described embodiments all belong to the frequency control rules defined in this embodiment. In order to ensure that the generation of work orders is more reasonable and effective, various frequency control rules can be defined in this embodiment, and there is no limitation on them.

[0079] Through steps 301 to 302 above, when an abnormal event is obtained, the system automatically determines whether to generate a corresponding work order for the abnormal event according to the frequency control rules. This helps to prevent the generation of too many work orders for the same abnormal event, which would cause system overload and waste of resources, and improve the efficiency of event handling in fully autonomous driving mode.

[0080] Figure 4 This is a flowchart illustrating another embodiment of the event handling method for vehicle operation disclosed herein, specifically the generation of work orders. This embodiment uses the generation of work orders based on abnormal events as an example for illustrative purposes. Figure 4 As shown, the process includes steps 401 to 402. The following is a description of each step:

[0081] In step 401, based on the event vehicle identifier of the event vehicle, the attribute information of the event vehicle is determined. The attribute information includes at least one of the following: road test vehicle, operation vehicle.

[0082] The attribute information of the event vehicle is used to indicate the vehicle's operational attributes. Specifically, road test vehicles refer to autonomous vehicles being tested on roads, while operational vehicles refer to vehicles participating in commercial operations, i.e., vehicles used to provide paid transportation services.

[0083] In this embodiment, the attribute information of the event vehicle can be determined based on the event vehicle identifier of the abnormal event. To achieve this disclosure, the correspondence between the attribute information of each vehicle and the event vehicle identifier can be stored in advance, so that when an abnormal event is received, the attribute information of the vehicle can be determined based on the event vehicle identifier.

[0084] It should be noted that the technical solution disclosed herein is intended to address the handling of abnormal events in vehicles operating in fully autonomous driving mode. Therefore, vehicles that have activated the autonomous link and have been normally shut down for less than a set time (such as less than 15 minutes, 30 minutes, etc.) can report abnormal events. If the vehicle has not activated the autonomous link or the shutdown time is longer than the set time, the vehicle will no longer report abnormal events.

[0085] Among them, the unmanned link refers to the vehicle operating in a fully unmanned driving mode. In addition to operating in a fully unmanned driving mode, the vehicle can also drive with a safety driver present. When driving with a safety driver present, it does not report abnormal events.

[0086] The shutdown time being longer than the set time is used to indicate that the vehicle is not currently in operation, and may be in a state of being stored or in the maintenance phase, so no abnormal events are reported.

[0087] In step 402, based on the exception code and the work order configuration table, at least one work order is generated in the resource pool that matches the attribute information.

[0088] Specifically, for event vehicles with different attribute information, corresponding work orders can be generated in different resource pools to enable different event processing procedures to be used for event vehicles with different attribute information.

[0089] In this disclosure, abnormal events of road test vehicles and abnormal events of operational vehicles can be handled by different event processing platforms, and the time limit requirements for handling abnormal events can also be different. Therefore, for event vehicles with different attribute information, corresponding work orders can be generated in different resource pools, and corresponding work processes can be used to process work orders in different resource pools.

[0090] In this context, the resource pool can be understood as a storage structure for storing work orders. This embodiment of the disclosure does not limit the form of the resource pool. For example, the resource pool can be a database, a data queue, etc.

[0091] Through steps 401 to 402 above, when an abnormal event is obtained, a work order is automatically generated in the matching resource pool based on the attribute information of the event vehicle. This helps to process abnormal events of event vehicles with different attribute information using different event handling processes, realize flexible event handling strategies, and improve the stability and reliability of the system.

[0092] Figure 5 A flowchart of another embodiment of the incident handling method in vehicle operation disclosed herein; as follows: Figure 5 As shown, the process includes steps 501 to 505. The following is a description of each step:

[0093] In step 501, in response to receiving an abnormal event reported by the event vehicle, at least one work order is generated for handling the abnormal event based on the abnormal event's abnormal code and the work order configuration table. The abnormal code is used to identify the event type of the abnormal event.

[0094] In step 502, each work order in at least one work order is sent to the corresponding processing platform.

[0095] In step 503, the work order status of each work order is updated based on the response message returned by the processing platform corresponding to each work order.

[0096] In this embodiment, the implementation of steps 501 to 503 can be found in [reference needed]. Figure 2The descriptions of steps 201 to 203 in the embodiment will not be detailed here.

[0097] Furthermore, after receiving the response messages returned by each processing platform and updating the work order status of each work order, the flow information of the work order status can be recorded by executing step 504, and step 505 can be executed when the work order status of each work order indicates that it has been completed.

[0098] In step 504, the work order status transition information of at least one work order corresponding to the abnormal event is stored in the work order record table. The work order status transition information includes the execution time and execution subject of the work order status transition action.

[0099] The work order record table is used to record the flow of information between different work order statuses after the work order is created. For example, for work order 1, if user 1 clicks the "Accept Order" button through the client operation interface at 13:15:42 on 2024-06-11, the work order status will change to "Accepted". The record entry for work order 1 in the work order record table can then record "User 1 clicked the Accept Order button at 13:15:42 on 2024-06-11, completing the acceptance operation". Alternatively, for work order 2, if ground rescue personnel 1 arrives at the scene and clicks "Arrived at Scene" through the client operation interface at 13:25:31 on 2024-06-11, the record entry for work order 1 in the work order record table can then record "Ground rescue personnel 1 clicked Arrived at Scene at 13:25:31 on 2024-06-11".

[0100] The work order status transition information includes the execution time and the executing entity of the work order status transition action. The executing entity is the client or client user that performs the action.

[0101] By recording the work order status transition information of each work order in the work order record table, it is possible to retrospectively review and analyze the work orders later. In specific implementation, in response to a work order query request, the work order status transition information of the work order to be queried can be obtained from the work order record table based on the work order identifier information in the work order query request; the work order status transition information of the work order to be queried is output, thereby allowing the user who triggered the work order query request to determine the handling status of the corresponding abnormal event of the query order based on the work order status transition information, realizing retrospective review and analysis of event handling.

[0102] In step 505, in response to the work order status indicating that at least one work order has been completed, an exception event handling completion operation is performed. The exception event handling completion operation includes at least one of the following: setting the status of the exception event to completed, and deleting at least one work order of the exception event from the resource pool, which is used to store incomplete work orders.

[0103] In this embodiment, the implementation of step 505 can be found in [reference needed]. Figure 2 The description of step 204 in the embodiment will not be detailed here.

[0104] Through steps 501 to 505 above, during the process of handling abnormal events based on work orders, the work order status flow information of each work order can be recorded in the work order record table. This helps to review and analyze the work orders, determine the handling of abnormal events during fully autonomous driving, and thus enable more reasonable decisions to be made when handling events, improve the accuracy and effectiveness of abnormal event handling, and promote the application and promotion of fully autonomous driving.

[0105] Figure 6 This is a flowchart illustrating the workflow of work order status in the event handling method for vehicle operation disclosed herein; such as Figure 6 As shown, the process includes steps 601 to 602. The following is a description of each step:

[0106] In step 601, the work order status flow information of each work order is obtained from the response message.

[0107] The work order status flow information includes the execution time and the person responsible for the work order status flow action.

[0108] In this disclosure, after the work order management platform sends a work order to each processing platform, each processing platform will synchronously update the work order status flow information during the process of handling the event, and send the work order status flow information to the work order management platform through a response message.

[0109] In step 602, the work order status of each work order is updated based on the work order status flow information of each work order.

[0110] In this disclosure, in response to the abnormal event indicated by the work order status flow information, which requires offline processing, a ground rescue work order is generated and sent to the ground rescue processing platform.

[0111] In this example, when remote maintenance cannot resolve the same abnormal event, the processing platform can indicate in a response message to the work order management platform that the abnormal event needs to be transferred to offline processing. The work order management platform can then generate a ground rescue work order and send it to the ground rescue processing platform. For example, for a red light event in autonomous driving software, a trip service work order and an operation and maintenance troubleshooting work order are generated. If the operation and maintenance troubleshooting platform finds that it cannot successfully troubleshoot the event during the process, it can report to the work order management platform, which will then generate a ground rescue work order for the same red light event in autonomous driving software.

[0112] Through steps 601 to 602 above, during the process of the processing platform handling abnormal events based on work orders, the work order status flow information can be synchronized to the work order management platform. This enables the work order management platform to generate ground rescue work orders in a timely manner when an event requires offline processing, thereby improving the timeliness and effectiveness of abnormal event handling and promoting the application and promotion of fully autonomous driving mode.

[0113] Corresponding to the embodiments of the aforementioned event handling method, this disclosure also provides embodiments of the event handling apparatus.

[0114] Exemplary device

[0115] Figure 7 This is a schematic diagram of the structure of one embodiment of the event handling device for vehicle operation disclosed herein. This device is applied to electronic devices (such as computer systems, servers, etc.). Figure 7 As shown, the device includes:

[0116] The work order generation module 71 is used to respond to the abnormal event reported by the event vehicle, and generate at least one work order for handling the abnormal event based on the abnormal event's abnormal code and the work order configuration table. The abnormal code is used to identify the event type of the abnormal event.

[0117] The sending module 72 is used to send each work order in at least one work order to the corresponding processing platform;

[0118] The update module 73 is used to update the work order status of each work order based on the response message returned by the processing platform corresponding to each work order.

[0119] The processing completion module 74 is used to respond to the work order status indication that at least one work order has been completed, and to perform an exception event processing completion operation. The exception event processing completion operation includes at least one of the following: setting the status of the exception event to completed, and deleting at least one work order of the exception event from the resource pool, which is used to store incomplete work orders.

[0120] Figure 8 This is a schematic diagram of another embodiment of the event handling device for vehicle operation disclosed herein, as shown below. Figure 8 As shown, in Figure 7 Based on the illustrated embodiment, in some optional implementations, the work order generation module 71 includes:

[0121] The frequency determination submodule 711 is used to determine the trigger frequency of an abnormal event triggered by an event vehicle based on the abnormal code of the abnormal event and the event vehicle identifier of the event vehicle.

[0122] The first generation submodule 712 is used to generate at least one work order for handling abnormal events based on the abnormal event's exception code and work order configuration table, in response to the trigger frequency meeting the frequency control rules.

[0123] In some alternative implementations, the work order generation module 71 includes:

[0124] The attribute determination submodule 713 is used to determine the attribute information of the event vehicle based on the event vehicle identifier of the event vehicle. The attribute information includes at least one of the following: road test vehicle, operation vehicle.

[0125] The second generation submodule 714 is used to generate at least one work order from a resource pool that matches the attribute information, based on the exception code and the work order configuration table.

[0126] In some alternative implementations, the work order generation module 71 includes:

[0127] The first acquisition submodule 715 is used to obtain the work order type corresponding to the exception code from the work order configuration table. The work order type includes at least two of the following: trip service work order, remote assistance work order, ground rescue work order, vehicle service work order, and maintenance work order.

[0128] The third generation submodule 716 is used to generate at least one work order for handling abnormal events based on the work order type, wherein the at least one work order includes at least one trip service work order.

[0129] In some alternative embodiments, the apparatus further includes:

[0130] The storage module 75 is used to store the work order status flow information of at least one work order corresponding to the abnormal event in the work order record table. The work order status flow information includes the execution time and execution subject of the work order status flow action.

[0131] In some alternative embodiments, the apparatus further includes:

[0132] The acquisition module 76 is used to obtain the work order status flow information of the work order to be queried from the work order record table based on the work order identification information in the work order query request.

[0133] Output module 77 is used to output the work order status flow information of the work order to be queried, so that the user who triggers the work order query request can determine the handling status of the abnormal event corresponding to the order to be queried based on the work order status flow information of the work order to be queried.

[0134] In some alternative implementations, the update module 73 includes:

[0135] The second acquisition submodule 731 is used to obtain the work order status flow information of each work order from the response message;

[0136] The update submodule 732 is used to update the work order status of each work order based on the work order status flow information of each work order.

[0137] In some optional implementations, the work order generation module 71 is further configured to, after obtaining the work order status flow information of each work order from the response message, generate a ground rescue work order in response to the work order status flow information indicating that an abnormal event needs to be transferred to offline processing, and send the ground rescue work order to the ground rescue processing platform.

[0138] The modules and units in this disclosed device can be further divided into finer-grained units according to actual needs, and the specific configuration can be set according to actual needs.

[0139] The apparatus of this disclosure embodiment can be used to implement the methods of the above embodiments of this disclosure. The two correspond to each other in specific implementation, and the specific implementation of related parts can be referred to each other, which will not be repeated here.

[0140] Exemplary systems, electronic devices, computer program products, and computer-readable storage media

[0141] This disclosure also provides an event processing system, including: at least one processing platform, at least one client connected to the at least one processing platform, and the aforementioned event processing device. The event processing device is configured to, in response to receiving an abnormal event reported by an event vehicle, generate at least one work order for processing the abnormal event based on the abnormal code of the abnormal event, where the abnormal code identifies the event type of the abnormal event; send each work order in the at least one work order to its corresponding processing platform; update the work order status of each work order based on the response message returned by the processing platform corresponding to each work order; and, in response to the work order status of the at least one work order indicating that the at least one work order has been completed, perform an abnormal event processing completion operation, which includes at least one of the following: setting the status of the abnormal event to completed, and deleting the at least one work order of the abnormal event from a resource pool, where the resource pool stores incomplete work orders; at least one processing platform is configured to, upon receiving a work order from the event processing device, send the abnormal event to its corresponding client, and return a response message to the event processing device when the client returns a processing result; and the client is configured to, upon receiving an abnormal event from the processing platform, output the abnormal event, which is then processed by the user of the client.

[0142] This disclosure also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program stored in the memory, wherein when the computer program is executed, it implements the event handling method for vehicle operation according to any of the above embodiments of this disclosure.

[0143] Below, for reference Figure 9This describes an electronic device according to embodiments of the present disclosure, wherein apparatus for implementing methods according to embodiments of the present disclosure may be integrated. Figure 9 This is a structural diagram of an electronic device provided in an illustrative embodiment of the present disclosure, such as... Figure 9 As shown, the electronic device includes one or more processors 91, one or more memory 92s of computer-readable storage media, and a computer program stored in the memory and executable on the processor. When the program in the memory 92 is executed, the aforementioned event handling method for vehicle operation can be implemented.

[0144] Specifically, in practical applications, the electronic device may also include components such as an input device 93 and an output device 94, which are interconnected via a bus system and / or other forms of connection mechanisms (not shown). Those skilled in the art will understand that... Figure 9 The structure of the electronic device shown does not constitute a limitation on the electronic device and may include more or fewer components than shown, or certain components, or different component arrangements.

[0145] in:

[0146] The processor 91 may be a central processing unit (CPU) or other form of processing unit with event processing and / or instruction execution capabilities. It performs various functions and processes data by running or executing software programs and / or modules stored in memory 92 and calling data stored in memory 92, thereby providing overall monitoring of the electronic device.

[0147] The memory 92 can store one or more computer program products. The memory can include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may include, for example, random access memory (RAM) and / or cache memory. The non-volatile memory may include, for example, read-only memory (ROM), hard disk, flash memory, etc. One or more computer program products can be stored on the computer-readable storage medium, and the processor 91 can run the computer program products to implement the event handling methods in vehicle operation and / or other desired functions according to the various embodiments of this disclosure described above.

[0148] The input device 93 can be used to receive input numeric or character information. The input device 93 may include a keyboard, mouse, joystick, etc., related to user settings and function control.

[0149] The output device 94 can output various information to the outside, including determined distance information, direction information, etc. The output device 94 may include, for example, a display, a speaker, a printer, and a communication network and its connected remote output devices, etc.

[0150] Electronic devices may also include a power supply for powering various components, which can be logically connected to the processor 91 through a power management system, thereby enabling functions such as charging, discharging, and power consumption management through the power management system. The power supply may also include one or more DC or AC power sources, recharging systems, power fault detection circuits, power converters or inverters, power status indicators, and any other components.

[0151] Of course, for the sake of simplicity, Figure 9 Only some of the components of the electronic device relevant to this disclosure are shown, omitting components such as buses, input / output interfaces, etc. In addition, the electronic device may include any other suitable components depending on the specific application.

[0152] In addition to the methods and apparatus described above, embodiments of this disclosure may also be computer program products comprising computer program instructions that, when executed by a processor, cause the processor to perform the steps of the event handling methods in vehicle operation according to various embodiments of this disclosure as described in the "Exemplary Methods" section of this specification.

[0153] Computer program products can be written in any combination of one or more programming languages ​​to perform the operations of embodiments of this disclosure. The programming languages ​​include object-oriented programming languages ​​such as Java and C++, as well as conventional procedural programming languages ​​such as C or similar languages. The program code can be executed entirely on a user's computing device, partially on a user's computing device, as a standalone software package, partially on a user's computing device and partially on a remote computing device, or entirely on a remote computing device or server.

[0154] Furthermore, embodiments of this disclosure may also be computer-readable storage media storing computer program instructions that, when executed by a processor, cause the processor to perform the steps of the event handling methods in vehicle operation according to various embodiments of this disclosure as described in the "Exemplary Methods" section above.

[0155] Computer-readable storage media may take the form of any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may, for example, include, but is not limited to, electrical, magnetic, optical, electromagnetic, infrared, or semiconductor systems, apparatuses, or devices, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fibers, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0156] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0157] The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to interchangeably. For system embodiments, since they largely correspond to method embodiments, the description is relatively simple; relevant parts can be referred to the descriptions in the method embodiments.

[0158] Those skilled in the art will understand that all or part of the steps of the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, it performs the steps of the above method embodiments. The aforementioned storage medium includes various media that can store program code, such as ROM, RAM, magnetic disk, or optical disk.

[0159] The methods and apparatus of this disclosure may be implemented in many ways. For example, they may be implemented by software, hardware, firmware, or any combination of software, hardware, and firmware. The above-described order of steps for the method is for illustrative purposes only, and the steps of the method of this disclosure are not limited to the order specifically described above, unless otherwise specifically stated. Furthermore, in some embodiments, this disclosure may also be implemented as a program recorded on a recording medium, the program including machine-readable instructions for implementing the method according to this disclosure. Thus, this disclosure also covers recording media storing programs for performing the method according to this disclosure.

[0160] The description in this disclosure is provided for illustrative and descriptive purposes only and is not intended to be exhaustive or to limit the disclosure to its forms. Many modifications and variations will be apparent to those skilled in the art. The embodiments were chosen and described in order to better illustrate the principles and practical application of this disclosure and to enable those skilled in the art to understand this disclosure and to design various embodiments with various modifications suitable for a particular purpose.

Claims

1. A method for handling incidents during vehicle operation, characterized in that, include: In response to receiving an abnormal event reported by the incident vehicle, at least one work order is generated for handling the abnormal event based on the abnormal event's exception code and work order configuration table, wherein the exception code is used to identify the event type of the abnormal event. Send each work order in the at least one work order to the corresponding processing platform; Based on the response messages returned by the processing platform corresponding to each work order, update the work order status of each work order; In response to the work order status indicating that the at least one work order has been completed, the abnormal event handling completion operation is performed. The abnormal event handling completion operation includes at least one of the following: setting the status of the abnormal event to completed, and deleting the at least one work order of the abnormal event from the resource pool, the resource pool being used to store incomplete work orders.

2. The method according to claim 1, characterized in that, The process of generating at least one work order for handling the abnormal event based on the abnormal event's exception code and work order configuration table includes: Based on the exception code of the abnormal event and the event vehicle identifier of the event vehicle, determine the trigger frequency of the abnormal event triggered by the event vehicle; In response to the trigger frequency satisfying the frequency control rules, at least one work order is generated to handle the abnormal event based on the abnormal event's exception code and work order configuration table.

3. The method according to any one of claims 1-2, characterized in that, The process of generating at least one work order for handling the abnormal event based on the abnormal event's exception code and work order configuration table includes: Based on the event vehicle identifier of the event vehicle, the attribute information of the event vehicle is determined, and the attribute information includes at least one of the following: road test vehicle, operation vehicle; Based on the exception code and the work order configuration table, at least one work order is generated in the resource pool that matches the attribute information.

4. The method according to any one of claims 1-3, characterized in that, The process of generating at least one work order for handling the abnormal event based on the abnormal event's exception code and work order configuration table includes: Obtain the work order type corresponding to the exception code from the work order configuration table. The work order type includes at least two of the following: trip service work order, remote assistance work order, ground rescue work order, vehicle service work order, and maintenance work order. Based on the work order type, at least one work order is generated for handling the abnormal event, and the at least one work order includes at least one trip service work order.

5. The method according to any one of claims 1-4, characterized in that, After updating the work order status based on the response message returned by the processing platform corresponding to each work order, the process further includes: The work order record table stores the work order status transition information of at least one work order corresponding to the abnormal event, and the work order status transition information includes the execution time and execution subject of the work order status transition action.

6. The method according to claim 5, characterized in that, In response to receiving a work order query request, the following also applies: Based on the work order identifier information in the work order query request, the work order status flow information of the work order to be queried is obtained from the work order record table; Output the work order status flow information of the work order to be queried, so that the user who triggered the work order query request can determine the handling status of the abnormal event corresponding to the work order to be queried based on the work order status flow information of the work order to be queried.

7. The method according to any one of claims 1-6, characterized in that, The step of updating the work order status based on the response message returned by the processing platform corresponding to each work order includes: Obtain the work order status flow information of each work order from the response message; Based on the work order status flow information of each work order, update the work order status of each work order.

8. The method according to claim 7, characterized in that, After obtaining the work order status flow information for each work order from the response message, the method further includes: In response to the work order status flow information indicating that the abnormal event needs to be transferred to offline processing, a ground rescue work order is generated and sent to the ground rescue processing platform.

9. An event handling device for vehicle operation, characterized in that, Applications to work order management platforms include: The work order generation module is used to respond to the abnormal event reported by the event vehicle, and generate at least one work order for processing the abnormal event based on the abnormal code of the abnormal event and the work order configuration table. The abnormal code is used to identify the event type of the abnormal event. The sending module is used to send each work order in the at least one work order to the corresponding processing platform; The update module is used to update the work order status of each work order based on the response message returned by the processing platform corresponding to each work order. The processing completion module is used to respond to the work order status indicating that the at least one work order has been completed, and to perform the processing completion operation of the abnormal event. The processing completion operation of the abnormal event includes at least one of the following: setting the status of the abnormal event to completed, and deleting the at least one work order of the abnormal event from the resource pool, wherein the resource pool is used to store incomplete work orders.

10. The apparatus according to claim 9, characterized in that, The work order generation module includes: The frequency determination submodule is used to determine the trigger frequency of the abnormal event triggered by the event vehicle based on the abnormal code of the abnormal event and the event vehicle identifier of the event vehicle. The first generation submodule is used to generate at least one work order for handling the abnormal event based on the abnormal event's exception code and work order configuration table, in response to the trigger frequency meeting the frequency control rules.

11. The apparatus according to any one of claims 9-10, characterized in that, The work order generation module includes: The attribute determination submodule is used to determine the attribute information of the event vehicle based on the event vehicle identifier of the event vehicle. The attribute information includes at least one of the following: road test vehicle, operation vehicle; The second generation submodule is used to generate at least one work order from a resource pool that matches the attribute information, based on the exception code and the work order configuration table.

12. The apparatus according to any one of claims 9-11, characterized in that, The work order generation module includes: The first acquisition submodule is used to obtain the work order type corresponding to the exception code from the work order configuration table. The work order type includes at least two of the following: trip service work order, remote assistance work order, ground rescue work order, vehicle service work order, and maintenance work order. The third generation submodule is used to generate at least one work order for handling the abnormal event based on the work order type, wherein the at least one work order includes at least one trip service work order.

13. The apparatus according to any one of claims 9-12, characterized in that, The device further includes: The storage module is used to store the work order status transition information of at least one work order corresponding to the abnormal event in the work order record table. The work order status transition information includes the execution time and execution subject of the work order status transition action.

14. The apparatus according to claim 13, characterized in that, The device further includes: The acquisition module is used to obtain the work order status flow information of the work order to be queried from the work order record table based on the work order identification information in the work order query request; The output module is used to output the work order status flow information of the work order to be queried, so that the user who triggered the work order query request can determine the handling status of the abnormal event corresponding to the work order to be queried based on the work order status flow information of the work order to be queried.

15. The apparatus according to any one of claims 9-14, characterized in that, The update module includes: The second acquisition submodule is used to acquire the work order status flow information of each work order from the response message; The update submodule is used to update the status of each work order based on the work order status flow information.

16. The apparatus according to claim 15, characterized in that, The work order generation module is further configured to obtain the work order status flow information of each work order from the response message, and in response to the work order status flow information indicating that the abnormal event needs to be transferred to offline processing, generate a ground rescue work order and send the ground rescue work order to the ground rescue processing platform.

17. An event handling system for vehicle operation, characterized in that, The system includes at least one processing platform, at least one client connected to the at least one processing platform, and an event processing device for vehicle operation as described in any one of claims 8-14; The event processing device is configured to, in response to receiving an abnormal event reported by an event vehicle, generate at least one work order for processing the abnormal event based on the abnormal code of the abnormal event, wherein the abnormal code is used to identify the event type of the abnormal event; and send each of the at least one work order to the corresponding processing platform. Based on the response message returned by the processing platform corresponding to each work order, the work order status of each work order is updated. In response to the work order status of at least one work order indicating that at least one work order has been completed, the processing completion operation of the abnormal event is executed. The processing completion operation of the abnormal event includes at least one of the following: setting the status of the abnormal event to completed, and deleting at least one work order of the abnormal event from the resource pool, wherein the resource pool is used to store incomplete work orders. The at least one processing platform is configured to send the abnormal events to the corresponding clients respectively when it receives the work order sent by the event processing device, and return a response message to the event processing device when the client returns the processing result; The client is configured to output the abnormal event when it receives an abnormal event sent by the processing platform, and the abnormal event is handled by the user of the client.

18. A computer-readable storage medium storing computer program instructions that, when executed, implement the method described in any one of claims 1-8.

19. An electronic device, the electronic device comprising: Memory, used to store computer program products; A processor for executing a computer program product stored in the memory, wherein when the computer program product is executed, it implements the method described in any one of claims 1-8.

20. A computer program product comprising computer program instructions, characterized in that, When the computer program instructions are executed by the processor, they implement the method described in any one of claims 1-8.

Images