Method for identifying anomalies of vehicle service tasks and electronic device

Abstract

The application provides a method for identifying an exception of a vehicle service task, which is applied to a background server and comprises the following steps: establishing and / or updating a time length distribution model of a vehicle service task according to a historical execution time length of the vehicle service task in a case that the vehicle service task is successfully completed, the vehicle service task comprising an activation task of a vehicle service and / or a deactivation task of the vehicle service; performing the vehicle service task in response to a triggering request of the vehicle service task; determining an actual execution time length of the vehicle service task after the vehicle service task is successfully completed; and identifying whether the vehicle service task has an exception based on the time length distribution model according to the actual execution time length of the vehicle service task. The application also relates to a corresponding computer program product and an electronic device. According to the application, the running condition of the background server can be accurately monitored, and the possible exception can be timely identified.

Description

Technical Field

[0001] This application relates to the field of vehicles, and more particularly to a method for identifying anomalies in vehicle service tasks, a computer program product, and an electronic device. Background Technology

[0002] With the rapid development of intelligent connected vehicles, the interaction between vehicles and backend servers (such as cloud service platforms) is becoming increasingly frequent. Users can trigger the activation and / or deactivation of various vehicle services, such as air conditioning and charging management, through mobile terminals or in-vehicle terminals. The backend server can respond to the trigger command and execute the triggered vehicle service tasks accordingly, that is, the activation and / or deactivation of vehicle services.

[0003] Existing technologies still have shortcomings in identifying anomalies during the activation and / or deactivation processes of vehicle services. When a vehicle service activation or deactivation task is triggered, if it ultimately fails, operations personnel receive feedback indicating the failure. Based on this "failed" result, they can troubleshoot the problem. However, when a vehicle service activation or deactivation task is triggered and ultimately succeeds, operations personnel often only receive the "successful" result and cannot promptly and effectively detect intermediate anomalies that occurred during execution. Even if some vehicle service activation / deactivation tasks experience anomalies during execution, these intermediate anomalies are difficult to detect and handle in a timely manner once the activation and / or deactivation of the vehicle service is ultimately successful. This leads to the continuous accumulation of potential fault risks.

[0004] Therefore, the existing technical solutions still need further improvement. Summary of the Invention

[0005] The purpose of this application is to provide an improved method for identifying anomalies in vehicle service tasks, as well as corresponding computer program products and electronic devices, to overcome at least one of the shortcomings of the prior art.

[0006] According to a first aspect of this application, a method for identifying anomalies in vehicle service tasks is provided, which is applied to a backend server, the method comprising the following steps: -Based on the historical execution duration of vehicle service tasks when they are successfully completed, establish and / or update the duration distribution model of vehicle service tasks, which include vehicle service activation tasks and / or vehicle service deactivation tasks. - In response to a trigger request for a vehicle service task, execute the vehicle service task; - After successfully completing the vehicle service task, determine the actual execution time of the vehicle service task; and -Based on the actual execution time of the vehicle service task, an anomaly can be identified in the vehicle service task using a duration distribution model.

[0007] Therefore, it is possible to identify whether a vehicle service task has anomalies by utilizing the actual execution time of the vehicle service task. This is particularly helpful in identifying hidden anomalies that are otherwise difficult to detect. Compared to judging the existence of anomalies solely based on the execution result (success or failure) of the vehicle service task, the method for identifying anomalies in vehicle service tasks according to this application can more comprehensively monitor the execution status of vehicle service tasks. In particular, it can effectively identify intermediate process anomalies (such as retries, functional failures) in vehicle service tasks. Thus, it is possible to accurately monitor the operation of the backend server and promptly identify potential anomalies. Establishing and / or updating the duration distribution model based on historical execution times can provide a criterion for accurately identifying anomalies without relying on the experience of technical personnel. The concept of this application focuses on the difficult-to-identify intermediate process anomalies in vehicle service tasks. Using only the historical execution times of successfully completed vehicle service tasks helps prevent anomalous data from contaminating the duration distribution model.

[0008] According to an optional embodiment of this application, determining the actual execution time of the vehicle service task includes: determining the actual execution time of the vehicle service task based on the dwell time of all sub-task functions experienced by the background server during the execution of the vehicle service task.

[0009] The actual execution time obtained in this way can more accurately reflect the actual time spent by the backend server in executing each stage of the vehicle service task, and can provide more accurate data for subsequent anomaly localization. In addition, when the vehicle service task includes parallel processing sub-tasks, the actual execution time obtained in this way can more comprehensively reflect the execution process of the vehicle service task, which helps to accurately identify possible anomalies.

[0010] In particular, the actual execution time of a vehicle service task can be determined using the following formula: Where T represents the actual execution time of the vehicle service task, and n represents the number of all sub-task functions experienced by the vehicle service task. k This indicates the dwell time of the k-th subtask function.

[0011] According to an optional embodiment of this application, determining the actual execution time of the vehicle service task includes: - Determine the start time based on the timestamp of the trigger request for the vehicle service task; - Determine the termination time based on the timestamp of the completion feedback received for the received vehicle service task; and - Calculate the time difference between the start time and the end time as the actual execution time of the vehicle service task.

[0012] This allows for the determination of the actual execution time of vehicle service tasks in a convenient manner. The calculation of the actual execution time requires very few computing resources and does not affect the functionality of each subtask. Furthermore, this design is particularly conducive to lightweight and low-cost deployment, requiring no deep modification to the internal processes of each subtask, exhibiting minimal intrusion into existing business code, and facilitating rapid integration into existing backend servers.

[0013] According to an optional embodiment of this application, establishing and / or updating the duration distribution model of vehicle service tasks includes: establishing and / or updating a normal distribution model using the mean μ and standard deviation σ of the historical actual execution duration of vehicle service tasks as model parameters.

[0014] According to an optional embodiment of this application, identifying whether the vehicle service task is abnormal based on a duration distribution model according to the actual execution time used by the vehicle service task includes: - Determine the normal duration interval based on the normal distribution model; - Determine whether the actual execution time of the vehicle service task falls within the normal time range to determine whether there is an anomaly in the vehicle service task.

[0015] The normal duration interval is specifically defined as [μ, μ+2σ]. This normal duration interval setting can reduce false alarms and false negatives.

[0016] According to an optional embodiment of this application, if the actual execution time is not within the normal time range, an alarm notification is generated by calling the error log of the sub-task function experienced by the vehicle service task. The alarm notification specifically includes at least one of the following information: actual execution time, normal time range, identifier of the sub-task function that triggered the exception, exception type, and related error log.

[0017] Alarm notifications can remind maintenance personnel to investigate. Furthermore, alarm notifications can provide crucial information needed for troubleshooting and guide the investigation process.

[0018] According to an optional embodiment of this application, if the actual execution time exceeds the upper limit of the normal execution time range, the following steps are performed: - Error logs of subtasks encountered during the invocation of vehicle service tasks; - Check if the error logs of each subtask function include records of the retry mechanism being triggered; and - If at least one subtask function is detected to have triggered the retry mechanism, a first alarm notification containing the identifier of the at least one subtask function is generated.

[0019] Although the retry mechanism did not affect the execution result of the vehicle service task, it revealed a potential stability issue in that sub-task. Timely identification and resolution of this stability issue can prevent its accumulation and subsequent more severe service interruptions. Precisely pinpointing the specific sub-task that triggered the retry mechanism helps maintenance personnel quickly identify the cause of the anomaly, shortening fault location time.

[0020] According to an optional embodiment of this application, if the actual execution time is lower than the lower limit of the normal duration range, a second alarm notification indicating the risk of subtask function stopping operation is generated.

[0021] Identifying the second type of anomaly prevents incomplete vehicle service tasks from impacting vehicle safety and functional integrity. The second alarm notification guides the troubleshooting process, allowing maintenance personnel to quickly take appropriate measures without guessing the anomaly type.

[0022] According to a second aspect of this application, a computer program product is provided, comprising computer program instructions, wherein, when executed by one or more processors, the computer program instructions cause the one or more processors to perform a method for identifying anomalies in a vehicle service task according to an exemplary embodiment of this application.

[0023] According to a third aspect of this application, an electronic device is provided, comprising a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, enables the processor to perform a method for identifying anomalies in vehicle service tasks according to exemplary embodiments of this application. Attached Figure Description

[0024] The principles, features, and advantages of this application will be better understood below with reference to the accompanying drawings. The drawings include: Figure 1 A vehicle service activation system according to an exemplary embodiment of this application is illustrated schematically; Figure 2 A flowchart illustrating a method for identifying anomalies in a vehicle service task according to an exemplary embodiment of this application is shown schematically. Figure 3 The probability density curve of the duration distribution model according to an exemplary embodiment of this application is schematically shown; Figure 4 A flowchart illustrating step S40 of a method for identifying anomalies in a vehicle service task according to an exemplary embodiment of this application is shown schematically. Figure 5 A flowchart illustrating step S40 of a method for identifying anomalies in a vehicle service task according to an exemplary embodiment of this application is shown schematically; and Figure 6 A flowchart illustrating a method for identifying anomalies in a vehicle service task according to an exemplary embodiment of this application is shown schematically.

[0025] List of reference numerals Detailed Implementation

[0026] To make the technical problems to be solved, the technical solutions, and the beneficial technical effects of this application clearer, the application will be further described in detail below with reference to the accompanying drawings and several exemplary embodiments. It should be understood that the specific embodiments described herein are only for explaining this application and are not intended to limit the scope of protection of this application.

[0027] Figure 1 A vehicle service activation system according to an exemplary embodiment of this application is illustrated schematically.

[0028] like Figure 1 As shown, the vehicle service activation system includes vehicle 1, backend server 2, and trigger terminal 3.

[0029] Vehicle 1 may include various types of vehicles, such as new energy vehicles (e.g., plug-in hybrid electric vehicles, range-extended electric vehicles, and / or pure electric vehicles) and / or gasoline vehicles, etc., and this application does not limit this. Vehicle 1 may be equipped with a control unit 11 (CU), which can be communicatively connected to the backend server 2. For example, the control unit 11 may be equipped with a SIM card module to communicate with the backend server 2 via SIM card data traffic.

[0030] The backend server 2 can be a cloud-based server. For example, the backend server 2 could be a vehicle manufacturer's cloud-based backend. The backend server 2 can communicate with the triggering terminal 3. The backend server can receive trigger requests from the triggering terminal 3 and execute corresponding vehicle service tasks. The vehicle service tasks may include vehicle service activation tasks and / or vehicle service deactivation tasks.

[0031] Trigger terminal 3 is a device that triggers the vehicle service task. Trigger terminal 3 is, for example, the mobile phone of the vehicle owner of vehicle 1. Optionally, trigger terminal 3 may include a smartwatch, personal computer, vehicle host, etc.

[0032] Before further describing the concept of this application, the activation / deactivation process of vehicle services will be presented as an example.

[0033] After vehicle 1 is delivered to the user, when the user needs to activate a certain vehicle service, an activation request for the vehicle service (i.e., a trigger request for the vehicle service activation task) can be triggered. For example, the user can click the "Activate Navigation Advanced Function Pack" button in the interactive interface of the mobile APP bound to vehicle 1. The triggering terminal 3 can submit an activation request for the vehicle service (Navigation Advanced Function Pack) to the backend server 2. The backend server 2 can then activate the vehicle service based on the trigger request.

[0034] Each vehicle service activation or deactivation task involves multiple sub-tasks. For example, during the vehicle service activation process, backend server 2 needs to identify the vehicle's identity information, verify the vehicle's certificate status, verify the user's permissions, issue activation commands, and / or receive execution result feedback. If backend server 2 receives a success feedback from the vehicle side, then backend server 2 can recognize that the vehicle service has been successfully activated, meaning that the vehicle service task has been successfully completed.

[0035] The vehicle services may include, for example, intelligent driving services, active safety services, cabin comfort services, audio-visual entertainment subscription services, vehicle remote control services, in-vehicle ETC services, and / or exclusive after-sales service packages for vehicle owners.

[0036] Figure 2 A flowchart illustrating a method for identifying anomalies in a vehicle service task according to an exemplary embodiment of this application is shown schematically. Figure 2 The method shown for identifying anomalies in vehicle service tasks can, for example, be applied to... Figure 1 The backend server 2 shown in the image.

[0037] like Figure 2 As shown, the method for identifying anomalies in vehicle service tasks may include steps S10, S20, S30, and S40.

[0038] In step S10, a duration distribution model for vehicle service tasks is established and / or updated based on the historical execution duration of vehicle service tasks when they are successfully completed. As mentioned above, vehicle service tasks include vehicle service activation tasks and / or vehicle service deactivation tasks. Although in Figure 1Although not shown, it should be understood that the backend server can communicatively connect to multiple vehicles and perform vehicle service tasks for said multiple vehicles. For example, the backend server can record the duration spent executing activation and / or deactivation tasks when a vehicle service activation task is successfully completed. After collecting sufficient duration data, a duration distribution model for vehicle service tasks can be established. Optionally, after establishing the duration distribution model, if the backend server obtains new data on the historical execution duration of vehicle service tasks when they are successfully completed, it can update the duration distribution model based on the new data.

[0039] In step S20, in response to a trigger request for a vehicle service task, the vehicle service task is executed. If the received trigger request is an activation request for a vehicle service, the activation task for that vehicle service is executed. If the received trigger request is a deactivation request for a vehicle service, the deactivation task for that vehicle service is executed.

[0040] In step S30, after the vehicle service task is successfully completed, the actual execution time of the vehicle service task is determined.

[0041] In step S40, based on the actual execution time of the vehicle service task, an anomaly is identified in the vehicle service task according to the duration distribution model.

[0042] Therefore, it is possible to identify whether a vehicle service task has any anomalies by utilizing the actual execution time of the vehicle service task. This is particularly helpful in identifying previously difficult-to-detect hidden anomalies. Compared to judging the existence of anomalies solely based on the execution result (success or failure) of the vehicle service task, the method for identifying anomalies in vehicle service tasks according to this application can more comprehensively monitor the execution status of vehicle service tasks. In particular, it can effectively identify intermediate process anomalies in vehicle service tasks (such as multiple retries, functional failures). Therefore, it is possible to accurately monitor the operation of the backend server and promptly identify potential anomalies.

[0043] Building and / or updating the duration distribution model based on historical execution durations provides a criterion for accurately identifying anomalies without relying on the experience of technical personnel. This application focuses on difficult-to-identify intermediate process anomalies in vehicle service tasks. Using only the historical execution durations of successfully completed vehicle service tasks helps prevent anomalous data from contaminating the duration distribution model.

[0044] Optionally, step S30 includes: determining whether the vehicle service task was successfully executed; if yes, determining the actual execution time of the vehicle service task and continuing to step S40; if no, generating a task failure notification. The task failure notification may, for example, be communicated to operations personnel.

[0045] In an exemplary embodiment according to this application, the duration of a vehicle service task can be determined by: determining the actual execution duration of the vehicle service task based on the dwell time of all sub-task functions experienced by the backend server during the execution of the vehicle service task.

[0046] Typically, during the activation / deactivation process of a vehicle service, the backend server needs to execute multiple sub-tasks (also known as cloud-based functional modules). Upon receiving a trigger request for a vehicle service task, the backend server can coordinate the sequential execution of these sub-tasks to complete the activation or deactivation process. During the execution of the vehicle service task, the backend server can record the dwell time of all sub-tasks to determine the actual execution time of the vehicle service task.

[0047] The actual execution time for a vehicle service task can be determined, for example, by the following formula: Where T represents the actual execution time of the vehicle service task, and n represents the number of all sub-task functions experienced by the vehicle service task. k This indicates the dwell time of the k-th subtask function.

[0048] The actual execution time obtained in this way can more accurately reflect the actual time spent by the backend server in executing each stage of the vehicle service task, and can provide more accurate data for subsequent anomaly localization. In addition, when the vehicle service task includes parallel processing sub-tasks, the actual execution time obtained in this way can more comprehensively reflect the execution process of the vehicle service task, which helps to accurately identify possible anomalies.

[0049] In an exemplary embodiment according to this application, step S30 may include: - Determine the start time based on the timestamp of the trigger request for the vehicle service task; - Determine the termination time based on the timestamp of the completion feedback received for the received vehicle service task; and - Calculate the time difference between the start time and the end time as the actual execution time of the vehicle service task.

[0050] The actual execution time for a vehicle service task can be determined, for example, by the following formula: Where T represents the actual execution time of the vehicle service task. Indicates the end time of the vehicle service task. Indicates the start time of the vehicle service task.

[0051] This allows for the determination of the actual execution time of vehicle service tasks in a convenient manner. The calculation of the actual execution time requires very few computing resources and does not affect the functionality of each subtask. Furthermore, this design is particularly conducive to lightweight and low-cost deployment, requiring no deep modification to the internal processes of each subtask, exhibiting minimal intrusion into existing business code, and facilitating rapid integration into existing backend servers.

[0052] To establish and / or update the duration distribution model of vehicle service tasks, the backend server can establish a duration database that stores the historical execution duration of vehicle service tasks. Specifically, the duration database only stores the historical execution duration of successfully completed vehicle service tasks.

[0053] The duration database can store data according to service type, independently maintain historical execution duration records for different service types, and independently establish duration distribution models for each. Duration distribution models can be, for example, normal distribution models, gamma distribution models, or Weibull distribution models.

[0054] Optionally, the steps of establishing and / or updating the duration distribution model of vehicle service tasks may include: establishing and / or updating a normal distribution model using the mean μ and standard deviation σ of the historical actual execution duration of vehicle service tasks as model parameters.

[0055] Figure 3 The probability density curve of the duration distribution model according to an exemplary embodiment of this application is schematically shown, where the horizontal axis represents the historical execution duration T and the vertical axis represents the probability p. Figure 4 A flowchart illustrating step S40 of a method for identifying anomalies in a vehicle service task according to an exemplary embodiment of this application is shown schematically.

[0056] exist Figure 3 In the example shown, the vehicle service task involves 5 sub-tasks. If each sub-task executes successfully, the vehicle service task will take approximately 60 seconds. Each sub-task has a retry mechanism. The retry mechanism for each sub-task is configured to allow a maximum of 3 retries, each lasting 5 seconds. Therefore, the maximum retry time for each sub-task is 15 seconds. The total maximum additional time for the 5 sub-tasks is 75 seconds. Theoretically, the maximum time for this vehicle service task is 135 seconds.

[0057] Statistical analysis of the historical execution time of vehicle service tasks reveals that the majority of historical execution times fall between 60 and 135 seconds. Historical execution times below 60 seconds and above 135 seconds are extremely rare.

[0058] The duration distribution model can be expressed as: T∼N(60,15) 2 ).like Figure 3 As shown, the mean μ of this duration distribution model is 60s, and the standard deviation σ is 15s. The mean μ reflects the typical execution time of a vehicle service task under normal operating conditions (i.e., the time consumed when no sub-task function malfunctions).

[0059] like Figure 4 As shown, step S40 may include steps S41 and S42.

[0060] In step S41, the normal duration interval is determined based on the established normal distribution model.

[0061] The normal duration interval is specifically defined as [μ, μ+2σ]. This interval essentially covers the duration required for a vehicle service task to be executed normally. Setting the lower limit of the normal duration interval to the mean μ, rather than symmetrically setting it to μ-2σ, is particularly advantageous because, under normal operating conditions, the execution time of a vehicle service task will not be less than the necessary basic processing time. Setting the lower limit of the normal duration interval to the mean μ helps to accurately identify the specific anomaly of vehicle service tasks executing too quickly, avoiding missed detections.

[0062] exist Figure 3 In the embodiment shown, the normal duration interval can be determined as [60s, 90s].

[0063] In step S42, it can be determined whether there is an anomaly in the vehicle service task based on whether the actual execution time of the vehicle service task falls within the normal time range.

[0064] Step S42 may include steps S421, S422 and S423.

[0065] In step S421, the actual execution time used for the vehicle service is compared with the normal execution time range. If the actual execution time falls within the normal execution time range, step S422 is executed; if the actual execution time does not fall within the normal execution time range, step S423 is executed.

[0066] In step S422, it is determined that there are no abnormalities in the execution process of the vehicle service task. In this case, the background server will not trigger the exception handling process.

[0067] In step S423, an anomaly can be determined in the execution process of the vehicle service task. The error logs of the sub-task functions experienced by the vehicle service task are then invoked to generate an alarm notification. The alarm notification specifically includes at least one of the following information: actual execution time, normal execution time range, identifier of the sub-task function that triggered the anomaly, anomaly type, and relevant error logs. The alarm notification can be sent to the maintenance equipment operated by maintenance personnel. For example, the alarm notification can be delivered to maintenance personnel via email.

[0068] Figure 5 A flowchart illustrating step S40 of a method for identifying anomalies in a vehicle service task according to an exemplary embodiment of this application is shown schematically.

[0069] and Figure 4 The illustrated embodiments are similar, in Figure 5 In the illustrated embodiment, step S40 of the method for identifying anomalies in vehicle service tasks may include steps S41 and S42.

[0070] In step S41, the normal duration interval is determined based on the established normal distribution model. The normal duration interval is, for example, determined to be [60s, 90s].

[0071] In step S42, it can be determined whether there is an anomaly in the vehicle service task based on whether the actual execution time of the vehicle service task falls within the normal time range.

[0072] Step S42 may include steps S421, S422, S424 and S425.

[0073] In step S421, the actual execution time used for the vehicle service is compared with the normal execution time range. If the actual execution time falls within the normal execution time range, step S422 is executed; if the actual execution time exceeds the upper limit of the normal execution time range, step S424 is executed; if the actual execution time is lower than the lower limit of the normal execution time range, step S425 is executed.

[0074] In step S422, it is determined that there are no abnormalities in the execution process of the vehicle service task. In this case, the background server will not trigger the exception handling process.

[0075] In step S424, it can be determined that a first type of exception exists in the execution process of the vehicle service task. This first type of exception is typically caused by the retry mechanism of a sub-task function. At least some sub-task functions of the vehicle service task can be equipped with a retry mechanism, which can automatically initiate a retry operation when a temporary error occurs in that sub-task function. The retry mechanism of a sub-task function can be set such that: if the retry operation is successful, the vehicle service task can continue to execute; if the number of retries reaches a predetermined number and all retries fail, the vehicle service task fails. Each retry operation consumes a certain amount of time. If a sub-task function is successfully executed only after multiple retries, it will cause the vehicle service task to take a long time to complete.

[0076] Although the retry mechanism did not affect the execution result of the vehicle service task, it revealed a potential stability issue in this subtask. Timely identification and resolution of this stability issue can prevent the problem from accumulating and causing more severe service interruptions.

[0077] In response to the detection of the first type of exception, the backend server may perform the following steps: - Error logs of subtasks encountered during the invocation of vehicle service tasks; - Check if the error logs of each subtask function include records of the retry mechanism being triggered; and - If at least one subtask function is detected to have triggered the retry mechanism, a first alarm notification containing the identifier of the at least one subtask function is generated.

[0078] The first alarm notification includes at least one of the following: actual execution time, normal duration range, identifier of the subtask function that triggered the retry mechanism, exception type (e.g., "retry mechanism triggered"), and related error logs.

[0079] By precisely locating the specific subtask function that triggered the retry mechanism, operations and maintenance personnel can quickly find the cause of the anomaly and shorten the fault location time.

[0080] In step S425, it can be determined that a second type of anomaly exists in the execution process of the vehicle service task. This second type of anomaly is typically caused by the cessation of operation of a subtask function.

[0081] An actual execution time lower than the lower limit of the normal time range (mean μ in this example) indicates that the vehicle service task is completed abnormally quickly. This is likely because a subtask function has stopped running and been skipped, causing the vehicle service task to return to a success state without fully undergoing the required process. In this case, although the vehicle service task appears to have been successfully executed, there is actually a risk of backend server malfunction. For example, when a subtask function involving data record types in the vehicle service activation task stops running and is skipped, the vehicle service may still be successfully activated. However, the skipped data record type subtask function may pose a hidden danger in the subsequent application of the vehicle service. By identifying this type of anomaly, it is possible to prevent such incomplete vehicle service tasks from affecting vehicle safety and functional integrity.

[0082] In response to the identification of a second type of anomaly, the backend server may perform the following steps: generate a second alarm notification indicating that there is a risk of subtask functionality stopping.

[0083] Before generating the second alarm notification, the error logs of all sub-task functions involved in the vehicle service task can also be invoked. The second alarm notification may include at least one of the following information: actual execution time, normal duration range, exception type (e.g., "function failure triggered"), and related error logs.

[0084] The second alarm notification can guide the direction of anomaly investigation, allowing maintenance personnel to quickly take corresponding measures without guessing the type of anomaly.

[0085] In an exemplary embodiment according to this application, it is particularly advantageous to set the lower limit of the normal duration interval to the average value μ of the historical actual execution duration of the vehicle service task, which helps to identify anomalies in which the subtask function stops operating.

[0086] In an exemplary embodiment according to this application, the duration distribution model is a log-normal distribution model. Since all historical execution durations are positive and exhibit right skewness, a log-normal distribution model is well-suited for evaluating duration distribution characteristics. In this case, the step of establishing and / or updating the duration distribution model of vehicle service tasks may include: taking the natural logarithm of all historical execution durations to calculate the mean μ of the logarithmic data. ln and standard deviation σ ln This leads to the establishment of a log-normal distribution model ln(T)∼N(μ) ln ,σ ln 2 Based on this duration distribution model, the normal duration interval can be set as []. , +2 ].

[0087] Figure 6 A flowchart illustrating a method for identifying anomalies in a vehicle service task according to an exemplary embodiment of this application is shown schematically. Figure 2 The illustrated embodiments are similar, in Figure 6 In the illustrated embodiment, the method for identifying anomalies in vehicle service tasks may include steps S10, S20, S30, and S40.

[0088] In step S10, a duration distribution model for vehicle service tasks is established and / or updated based on the historical execution duration of vehicle service tasks when they are successfully completed.

[0089] In step S20, in response to a trigger request for a vehicle service task, the vehicle service task is executed. If the received trigger request is an activation request for a vehicle service, the activation task for that vehicle service is executed. If the received trigger request is a deactivation request for a vehicle service, the deactivation task for that vehicle service is executed.

[0090] In step S30, after the vehicle service task is successfully completed, the actual execution time of the vehicle service task is determined.

[0091] In step S40, based on the actual execution time of the vehicle service task, an anomaly is identified in the vehicle service task according to the duration distribution model.

[0092] exist Figure 6 In the illustrated embodiment, the method for identifying anomalies in vehicle service tasks may further include step S50. Step S50 may be executed after step S30. In step S50, the actual execution duration determined in step S30 is used as one of the historical execution durations. Then, step S10 may be executed again to update the duration distribution model of the vehicle service task based on the historical execution duration. The updated duration distribution model can be used to identify whether anomalies exist when subsequently executing vehicle service tasks.

[0093] It should be understood that, in describing exemplary embodiments, the specification may describe the method for identifying anomalies in a vehicle service task in a specific order of steps, or the flowchart may present the method for identifying anomalies in a vehicle service task in a specific order of steps. However, the method for identifying anomalies in a vehicle service task should not be limited to the specific order of steps described herein, where the method for identifying anomalies in a vehicle service task does not depend on the specific order of steps described herein. As will be understood by those skilled in the art, other orders of steps are also possible. For example, step S50 may be performed at least partially simultaneously with step S40, before step S40, or after step S40. Therefore, the specific order of steps set forth in the specification should not be construed as a limitation of the claims. Furthermore, the claims for the method for identifying anomalies in a vehicle service task should not be limited to the steps performed in the order they are written, and those skilled in the art will readily understand that these orders may be varied and still fall within the scope of this application.

[0094] This application also relates to an electronic device. The electronic device may include a memory and a processor, wherein the memory stores a computer program, and when the computer program is executed by the processor, the processor is capable of performing a method for identifying anomalies in a vehicle service task according to exemplary embodiments of this application. The processor may be a central processing unit, or other general-purpose processors, digital signal processors, application-specific integrated circuits, off-the-shelf programmable gate arrays, or other programmable logic devices, etc.

[0095] The electronic device may, for example, be integrated into, implemented as, or include a backend server.

[0096] This application also relates to a computer program product comprising computer program instructions. When executed by one or more processors, the computer program instructions cause the one or more processors to perform a method for identifying anomalies in a vehicle service task according to exemplary embodiments of this application.

[0097] Computer program instructions may be stored in a computer-readable storage medium. Such a medium may include, for example, high-speed random access memory, and may also include non-volatile memory or volatile solid-state storage devices.

[0098] Although specific embodiments of this application are described in detail herein, they are given for illustrative purposes only and should not be construed as limiting the scope of this application. Various substitutions, modifications, and alterations can be conceived without departing from the spirit and scope of this application.

Claims

1. A method for identifying anomalies in vehicle service tasks, applied to a backend server, wherein, The method includes the following steps: Based on the historical execution duration of vehicle service tasks when they are successfully completed, establish and / or update the duration distribution model of vehicle service tasks, wherein the vehicle service tasks include vehicle service activation tasks and / or vehicle service deactivation tasks. In response to a trigger request for a vehicle service task, execute the vehicle service task; After successfully completing the vehicle service task, determine the actual execution time of the vehicle service task; and Based on the actual execution time of the vehicle service task, an anomaly can be identified using a duration distribution model.

2. The method according to claim 1, wherein, The actual execution time used to determine the vehicle service task includes: The actual execution time of the vehicle service task is determined based on the dwell time of all sub-task functions experienced by the backend server during the execution of the vehicle service task. In particular, the actual execution time of vehicle service tasks is determined using the following relationship: Where T represents the actual execution time of the vehicle service task, and n represents the number of all sub-task functions experienced by the vehicle service task. k This indicates the dwell time of the k-th subtask function.

3. The method according to claim 1, wherein, The actual execution time used to determine the vehicle service task includes: The start time is determined based on the timestamp of the trigger request for the vehicle service task; The termination time is determined based on the timestamp of the completion feedback received for the received vehicle service task; and The time difference between the start time and the end time is calculated as the actual execution time of the vehicle service task.

4. The method according to any one of claims 1-3, wherein, Establishing and / or updating the duration distribution model of vehicle service tasks includes: The mean μ and standard deviation σ of the historical actual execution time of vehicle service tasks are used as model parameters to establish and / or update the normal distribution model.

5. The method according to claim 4, wherein, Based on the actual execution time of the vehicle service task and using a duration distribution model, identify whether the vehicle service task has any anomalies, including: Based on the normal distribution model, the normal duration interval is determined, wherein the normal duration interval is specifically defined as [μ, μ+2σ]; and Determine whether the actual execution time of the vehicle service task falls within the normal time range to determine if there is any abnormality in the vehicle service task.

6. The method according to claim 5, wherein, If the actual execution time is not within the normal time range, an alarm notification is generated by calling the error log of the sub-task function experienced by the vehicle service task. The alarm notification specifically includes at least one of the following information: actual execution time, normal time range, identifier of the sub-task function that triggered the abnormality, abnormality type, and related error log.

7. The method according to claim 5, wherein, If the actual execution time exceeds the upper limit of the normal execution time range, then the following steps are performed: Error logs of subtasks encountered during the invocation of vehicle service tasks; Check if the error logs of each subtask function include records of the retry mechanism being triggered; as well as If at least one subtask function is detected to have triggered the retry mechanism, a first alarm notification containing the identifier of the at least one subtask function is generated.

8. The method according to claim 5, wherein, If the actual execution time is lower than the lower limit of the normal execution time range, a second alarm notification is generated indicating that there is a risk that the subtask function will stop running.

9. A computer program product comprising computer program instructions, wherein, When executed by one or more processors, the computer program instructions enable the one or more processors to perform the method for identifying anomalies in vehicle service tasks according to any one of claims 1-8.

10. An electronic device, wherein, The electronic device includes a memory and a processor, wherein the memory stores a computer program that, when executed by the processor, enables the processor to perform a method for identifying anomalies in vehicle service tasks according to any one of claims 1-8.

Images