Method and system for processing prompt information of vehicle

Abstract

The embodiment of the invention provides a prompt information processing method and system for a vehicle, and the method comprises the steps: obtaining a first prompt information set of the vehicle, and enabling the first prompt information set to comprise a plurality of prompt information; in response to the condition that the first prompt information set meets an aggregation condition, aggregating the first prompt information set according to an aggregation strategy to obtain a second prompt information set; according to the incidence relation between at least two kinds of prompt information in the second prompt information set, a third prompt information set is determined, the third prompt information set comprises target prompt information, and the target prompt information is one kind of prompt information in the at least two kinds of prompt information with the incidence relation in the second prompt information set; and switching the vehicle from the abnormal operation state to the normal operation state at least according to the third prompt information set. The technical problem that the prompt information processing effect of the vehicle is poor is solved.

Description

Vehicle alert information processing methods and systems Technical Field

[0001] This application relates to the field of computer monitoring technology, and more specifically, to a method and system for processing vehicle alert information. Background Technology

[0002] Currently, in the process of monitoring and alerting vehicle operating status, when faced with a storm of alert messages—that is, a large number of homogeneous alert messages emerging in a short period of time—the relevant technologies adopt a method of sending alert messages one by one. However, this method generates a "massive notification" with redundant information, which not only exacerbates the alert overload but also reduces the possibility of quickly locating abnormal vehicle operating states. Therefore, the technical problem of poor processing effect of vehicle alert messages still exists.

[0003] There is currently no good solution to the above problems. Summary of the Invention

[0004] This application provides a method and system for processing vehicle prompt information, so as to at least solve the technical problem of poor processing effect of vehicle prompt information.

[0005] According to one aspect of the embodiments of this application, a method for processing vehicle prompt information is provided, wherein: a first set of vehicle prompt information is obtained, wherein the first set of prompt information includes multiple prompt information, the prompt information being used to characterize that the vehicle is in an abnormal operating state under an evaluation dimension; in response to the first set of prompt information satisfying an aggregation condition, the first set of prompt information is aggregated according to an aggregation strategy to obtain a second set of prompt information, wherein the aggregation strategy is used to represent a rule for aggregating multiple prompt information under the same evaluation dimension into one prompt information; a third set of prompt information is determined according to the association relationship between at least two prompt information in the second set of prompt information, wherein the third set of prompt information includes target prompt information, the target prompt information being one of at least two prompt information with an association relationship in the second set of prompt information; and the vehicle is switched from an abnormal operating state to a normal operating state at least according to the third set of prompt information.

[0006] Furthermore, obtaining the first set of vehicle prompt information includes: in response to the vehicle being in an abnormal operating state, obtaining a set of vehicle prompt events, wherein the set of prompt events includes multiple prompt events; parsing the prompt events to obtain the feature information of the prompt events; and determining the feature information of the prompt events in the set of prompt events as the first set of prompt information.

[0007] Furthermore, the method parses the prompt events to obtain their feature information, including: parsing the prompt event's tag information, annotation information, and / or prompt content, wherein the tag information is used to indicate the source and / or attributes of the prompt event; extracting feature information from the tag information, annotation information, and / or prompt content; or, the method further includes: grouping the prompt information in the first prompt information set according to a grouping strategy based on the feature information to obtain at least two subsets of prompt information, wherein the grouping strategy is used to represent the rules for grouping the prompt information in the first prompt information set.

[0008] Furthermore, the grouping strategy includes a first grouping strategy and a second grouping strategy, and the prompt information subset includes a first prompt information subset and a second prompt information subset. According to the grouping strategy, based on the feature information, the prompt information in the first prompt information set is grouped to obtain at least two sets of prompt information, including: according to the first grouping strategy, prompt information in the first prompt information set whose feature information satisfies the task type condition and the exception type condition is determined as elements in the first prompt information subset, wherein the task type condition is used to characterize the task performed by the vehicle when it is in operation; according to the second grouping strategy, prompt information in the first prompt information set whose feature information satisfies the hardware device condition and the instance condition is determined as elements in the second prompt information subset, wherein the hardware device condition is used to represent the hardware resources that trigger the prompt information.

[0009] Furthermore, the method further includes: determining that a first set of prompt information satisfies the aggregation condition in response to the number of prompt information in the subset of prompt information being greater than a quantity threshold; determining that the first set of prompt information does not satisfy the aggregation condition in response to the number of prompt information in the subset of prompt information being less than or equal to the quantity threshold; or, in response to the first set of prompt information satisfying the aggregation condition, aggregating the first set of prompt information according to an aggregation strategy to obtain a second set of prompt information, including: in response to the subset of prompt information satisfying the aggregation condition, aggregating multiple prompt information under the same evaluation dimension in the subset of prompt information according to an aggregation strategy to obtain aggregated prompt information under the evaluation dimension; and determining the aggregated prompt information under multiple evaluation dimensions as the second set of prompt information.

[0010] Further, based on the correlation between the prompts in the second set of prompts, a third set of prompts is determined, including: determining a target prompt from the at least two types of prompts based on the correlation between the at least two types of prompts, wherein the target prompt is used to indicate the reason for triggering the prompts other than the target prompt among the at least two types of prompts; determining the target prompt as an element in the fourth set of prompts; and determining the prompts other than the target prompt among the at least two types of prompts as elements in the fifth set of prompts; and determining the subset of prompts in the first set that does not meet the aggregation condition, the fourth set of prompts, and the fifth set of prompts as the third set of prompts.

[0011] According to another aspect of the embodiments of this application, a vehicle prompt information processing device is also provided. The device may include: a first acquisition module, configured to acquire a first prompt information set of the vehicle, wherein the first prompt information set includes multiple prompt information, and the prompt information is used to characterize that the vehicle is in an abnormal operating state under an evaluation dimension; a first aggregation module, configured to aggregate the first prompt information set according to an aggregation strategy in response to the first prompt information set satisfying an aggregation condition, to obtain a second prompt information set, wherein the aggregation strategy is used to represent a rule for aggregating multiple prompt information under the same evaluation dimension into one prompt information; a first determination module, configured to determine a third prompt information set according to the association relationship between at least two prompt information in the second prompt information set, wherein the third prompt information set includes target prompt information, and the target prompt information is one of at least two prompt information with an association relationship in the second prompt information set; and a switching module, configured to switch the vehicle from an abnormal operating state to a normal operating state at least according to the third prompt information set.

[0012] According to another aspect of the embodiments of this application, a vehicle prompt information processing system is also provided. The system may include: a receiving unit, configured to receive a first set of vehicle prompt information, wherein the first set of prompt information includes multiple prompts, the prompts representing that the vehicle is in an abnormal operating state under an evaluation dimension; a rule engine, configured to determine whether the first set of prompt information satisfies an aggregation condition; an aggregation processor, configured to, in response to the first set of prompt information satisfying the aggregation condition, aggregate the first set of prompt information according to an aggregation strategy to obtain a second set of prompt information, wherein the aggregation strategy represents a rule for aggregating multiple prompts under the same evaluation dimension into one prompt; a relationship analyzer, configured to obtain the association relationship between at least two types of prompts in the second set of prompt information; and to determine a third set of prompt information based on the association relationship, wherein the third set of prompt information includes target prompt information, the target prompt information being one of at least two types of prompts in the second set of prompt information that have an association relationship.

[0013] Furthermore, the system may also include: a prompt forwarding module for forwarding a third prompt information set to a notification system; and / or a prompt adjustment module for switching the vehicle from an abnormal operating state to a normal operating state, at least according to the third prompt information set.

[0014] According to another aspect of the embodiments of this application, an alarm information processing method for an alarm source is also provided. The method may include: obtaining a first alarm information set of an alarm source to be processed, wherein the first alarm information set includes multiple alarm information, and the alarm information is used to characterize that the alarm source is in an abnormal operating state under the evaluation dimension; in response to the first alarm information set satisfying the aggregation condition, aggregating the first alarm information set according to the aggregation strategy to obtain a second alarm information set, wherein the aggregation strategy is used to represent the rule for aggregating multiple alarm information under the same evaluation dimension into one alarm information; determining a third alarm information set according to the correlation between at least two alarm information in the second alarm information set, wherein the third alarm information set includes target alarm information, and the target alarm information is one of the at least two alarm information with correlation in the second alarm information set.

[0015] Furthermore, the method may also include: converting the third alarm information set to the notification system; and / or, at least according to the third prompt information set, switching the alarm source from the abnormal operating state to the normal operating state.

[0016] According to another aspect of the embodiments of this application, an alarm information processing device for an alarm source is also provided. The device may include: a second acquisition module, configured to acquire a first alarm information set of an alarm source to be processed, wherein the first alarm information set includes multiple alarm information, and the alarm information is used to characterize that the alarm source is in an abnormal operating state under the evaluation dimension; a second aggregation module, configured to aggregate the first alarm information set according to an aggregation strategy in response to the first alarm information set meeting the aggregation conditions, to obtain a second alarm information set, wherein the aggregation strategy is used to represent the rule for aggregating multiple alarm information under the same evaluation dimension into one alarm information; and a second determination module, configured to determine a third alarm information set according to the correlation between at least two alarm information in the second alarm information set, wherein the third alarm information set includes target alarm information, and the target alarm information is one of the at least two alarm information with correlation in the second alarm information set.

[0017] According to another aspect of the embodiments of this application, a vehicle is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0018] According to another aspect of the embodiments of this application, an alarm source is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0019] Embodiments of this application also provide an electronic device, including a memory storing an executable program; and a processor for running the program, wherein the program executes the methods of various embodiments of this application during runtime.

[0020] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0021] According to another aspect of the embodiments of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0022] According to another aspect of the embodiments of this application, a computer program product is also provided, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the methods in various embodiments of this application.

[0023] According to another aspect of the embodiments of this application, a computer program is also provided, which, when executed by a processor, implements the methods of the various embodiments of this application.

[0024] In this embodiment, if it is necessary to process the vehicle's prompt information, a first set of vehicle prompt information can be obtained. It can be determined whether the first set of prompt information meets the aggregation conditions. If the first set of prompt information meets the aggregation conditions, it can be aggregated according to the aggregation strategy to obtain a second set of prompt information. This allows prompt information under the same evaluation dimension to be aggregated into one type of prompt information. A third set of prompt information can be determined based on the correlation between at least two types of prompt information in the second set of prompt information. This allows only one type of the at least two correlated prompt information to be retained, avoiding excessively large amounts of prompt information data. The vehicle can be switched from an abnormal operating state to a normal operating state according to the third set of prompt information. In other words, in the above embodiment of this application, multiple homogeneous prompt information under the same evaluation dimension in the first set of prompt information that meets the aggregation conditions can be aggregated to form a more concise second set of prompt information, effectively avoiding redundancy and reducing the burden of prompt information processing. Based on the inherent relationships between the prompts, a key third set of prompts is extracted, ensuring that only one target prompt is retained among multiple related prompts. This significantly improves the efficiency of quickly locating and responding to abnormal vehicle operating states. This method not only avoids the chaos caused by "large notifications" but also optimizes the switching path of vehicle operating states. It achieves the technical effect of improving the processing efficiency of vehicle prompts and solves the technical problem of poor prompt processing effectiveness. Attached Figure Description

[0025] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, illustrate exemplary embodiments and are used to explain this application, but do not constitute an undue limitation of this application. In the drawings:

[0026] Figure 1 is a flowchart of a vehicle prompt information processing method according to an embodiment of this application;

[0027] Figure 2 is a flowchart of an alarm information processing method for an alarm source according to an embodiment of this application;

[0028] Figure 3 is a schematic diagram of a monitoring and alarm suppression architecture based on multidimensional grouping and dynamic aggregation according to an embodiment of this application;

[0029] Figure 4 is a flowchart of a dynamic aggregation and summary generation process according to an embodiment of this application;

[0030] Figure 5 is a schematic diagram of a vehicle prompt information processing system according to an embodiment of this application;

[0031] Figure 6 is a schematic diagram of a vehicle prompt information processing device according to an embodiment of this application;

[0032] Figure 7 is a schematic diagram of an alarm information processing device for an alarm source according to an embodiment of this application. Detailed Implementation

[0033] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of the present application.

[0034] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0035] According to an embodiment of this application, a method for processing vehicle prompt information is provided. It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions. Although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0036] This embodiment provides a method for processing vehicle prompt information. Figure 1 is a flowchart of a method for processing vehicle prompt information according to an embodiment of this application. As shown in Figure 1, the method may include the following steps.

[0037] Step S102: Obtain the first set of prompt information for the vehicle.

[0038] In the technical solution provided by step S102 of the embodiments of this application, the first set of prompt information includes multiple prompt information. The prompt information is used to characterize that the vehicle is in an abnormal operating state under the evaluation dimension.

[0039] Optionally, the first alert information set can represent the collection of unprocessed raw alerts received from the vehicle. If the severity of the abnormal operating state is high, the raw alert can also be called a raw alarm. The evaluation dimensions of different alerts in the first alert information set can be different aspects or standards used to assess the vehicle's operational health. For example, if the object to be evaluated is a vehicle, the evaluation dimensions can include, but are not limited to: engine performance, braking system status, tire pressure, battery charge, communication module connection quality, etc., without specific limitations.

[0040] Optionally, an abnormal operating state can be used to indicate that a component or system of the vehicle has deviated from its normal operating parameter range or has exhibited unexpected behavior. For example, the aforementioned abnormal operating state can be a low-severity operating state, such as a low battery charge in the vehicle; or it can be a high-severity operating state, such as an engine failure in the vehicle.

[0041] In this embodiment, if it is necessary to process the vehicle's prompt information, the vehicle's first prompt information set can be obtained.

[0042] Optionally, if it is necessary to monitor the operational status of various evaluation dimensions in the vehicle, it is possible to determine which components or systems in the vehicle are functioning normally, and what factors might be causing the vehicle to be in an abnormal operating state under the aforementioned evaluation dimensions. Therefore, monitoring sensors or modules for the corresponding evaluation dimensions can be deployed in the aforementioned parts or systems of the vehicle to ensure that the operational status of these parts or systems is monitored, thereby evaluating whether the vehicle's operational status is abnormal under that evaluation dimension.

[0043] Optionally, the monitoring sensors or modules deployed on the components or systems in the vehicle can continuously collect real-time operating data of these components or systems during vehicle operation. This operating data may include, but is not limited to, temperature, pressure, vibration, current, voltage, position, and speed. The collected real-time operating data is compared with preset normal operating parameter ranges or normal operating thresholds to obtain a comparison result. If the comparison result indicates that the operating data exceeds the normal operating parameter range or normal operating threshold, it indicates that the vehicle is in an abnormal operating state under this evaluation dimension, and a corresponding prompt message can be generated.

[0044] Optionally, if multiple evaluation dimensions simultaneously or successively determine that the working data exceeds the normal operating parameter range or normal operating threshold within a short period of time, the above-mentioned multiple prompts can be aggregated to form a first prompt information set.

[0045] In this embodiment of the application, the above method can not only monitor the vehicle's operating status in real time, but also accurately identify whether the vehicle's operating status is abnormal under multiple evaluation dimensions, and generate a first set of prompt information.

[0046] Step S104: In response to the first prompt information set satisfying the aggregation condition, the first prompt information set is aggregated according to the aggregation strategy to obtain the second prompt information set.

[0047] In the technical solution provided by step S104 in the embodiments of this application, the aggregation strategy can be used to represent the rule of aggregating multiple prompts under the same evaluation dimension into one prompt.

[0048] Optionally, the aggregation condition can be a logical criterion for triggering the aggregation of the first set of prompt information. It can be used to determine when to aggregate multiple original prompt information that are homogeneous or closely related in a specific evaluation dimension into a single prompt information. The aggregation condition can be triggered based on time (e.g., the number of similar alarms received within a certain time period), space (e.g., multiple related alarms within the same component or system), severity (e.g., low-level warnings accumulating to a certain level and converting to high-level alarms), or a specific abnormal operating state. The purpose of the aggregation condition design is to identify and address vehicle prompt storms, reduce prompt information redundancy, and improve operational efficiency. It should be noted that the factors considered in setting the aggregation condition above are merely illustrative examples and are not specifically limited here. Any aggregation condition that can measure whether the first set of prompt information needs to be aggregated to reduce the number of prompt information and avoid "massive notifications" is within the protection scope of this application's embodiments.

[0049] Optionally, the aggregation strategy can be a set of rules for how to perform aggregation operations on prompts that meet the aggregation conditions. The aggregation strategy can include logic for classifying, reorganizing, and summarizing prompts, aiming to refine scattered and detailed prompts into higher-level, more comprehensive, and action-guiding prompts. The aggregation strategy can be set dynamically, automatically adjusting the aggregation rules based on the real-time vehicle operating status, the scope of fault impact, or business needs, ensuring that the generated comprehensive alarms meet actual requirements. The aggregation strategy can also include details such as how to handle the priority of prompts and how to merge similar but not identical prompts; no specific limitations are imposed here. The aggregation strategy can be a dynamic aggregation rule.

[0050] Optionally, the second set of alert information can be the aggregated result obtained by processing the first set of alert information according to an aggregation strategy. The aforementioned second set of alert information can consist of a set of streamlined and reorganized comprehensive alert information. Compared to the first set of alert information, the second set of alert information focuses more on key anomalies and risks in vehicle operation. Each key alert information item in the second set of alert information can represent a comprehensive description and assessment of one or more original alert information items, including the core information of the anomaly, its scope of impact, and suggested countermeasures.

[0051] In this embodiment, after obtaining the first set of prompt information for the vehicle, it can be determined whether the prompt information in the first set of prompt information meets the aggregation condition. If the first set of prompt information meets the aggregation condition, the prompt information in the first set of prompt information can be aggregated according to the aggregation strategy to obtain the second set of prompt information.

[0052] Optionally, a corresponding threshold can be set for each potential evaluation dimension that needs aggregation, representing the aggregation condition under that evaluation dimension. For example, "the same service receiving more than 5 instances of 'High CPU Usage' alerts within 5 minutes" can be set as one of the aggregation conditions. The first set of alert information can be continuously monitored to check whether any alert information meets the pre-set aggregation conditions. For example, multiple dimensions can be used to determine whether the alert information meets the aggregation conditions, including but not limited to: time window, alert type, severity level, and scope of impact.

[0053] Optionally, for each detected potential aggregation condition, it can be assessed whether there are a sufficient number of identical unexpected condition alerts in the first alert set to satisfy the aggregation condition. For example, if an instance of the same service receives more than 5 "HighCPUUsage" alerts within 5 minutes, the aggregation condition is considered satisfied.

[0054] Optionally, once the first set of alert information is detected to meet the aggregation conditions, the alert information meeting the aggregation conditions can be processed according to the aggregation strategy. Key information can be extracted from the alert information meeting the aggregation conditions according to the requirements of the aggregation strategy, such as the name of the abnormal service, the number of affected instances, and the times of the first and last alarms. Aggregated alarm information is generated using this key information. Based on the extracted key information, a second set of alert information can be created, which may contain the aggregated alert information. The aggregated alert information can be designed to be more concise and highly generalized to reduce redundancy and improve operability. The generated aggregated alert information is added to the second set of alert information, replacing or supplementing the original, more detailed alert information to reflect the latest and highest-level abnormal operating status of the vehicle.

[0055] In this embodiment of the application, the above method can intelligently determine when to aggregate multiple original prompts of the same type, and generate a more efficient and instructive second set of prompts through a customized aggregation strategy, thereby significantly improving the response speed and accuracy of abnormal operating states while ensuring the accuracy of the prompts.

[0056] Step S106: Determine the third set of prompt information based on the association between at least two types of prompt information in the second set of prompt information.

[0057] In the technical solution provided by step S106 of the embodiments of this application, the third set of prompt information includes target prompt information. The target prompt information is one of at least two types of prompt information that have a correlation within the second set of prompt information.

[0058] Optionally, the association can refer to the logical, functional, or causal relationship between different prompts. These associations can be used to reflect the interdependencies between the internal structures of a vehicle. For example, a "fuel pump malfunction" prompt can directly lead to an "engine start failure" prompt, thus there is a direct causal relationship between the two. Similarly, "wheel imbalance" and "suspension system malfunction" prompts are in different components but belong to the same system, exhibiting functional correlation. Associations can be used to accurately determine the root cause of an abnormal vehicle operating state, and to quickly locate the prompt causing the abnormal operating state from a large number of prompts. These associations can be represented as a service dependency graph.

[0059] Optionally, the third set of prompts may include target prompts that have undergone in-depth analysis and filtering, prompts from the first set of prompts that do not meet the aggregation criteria, and other prompts that are related to the target prompts. The goal of the aforementioned third set of prompts is to minimize redundant prompts and ensure that every prompt delivered to maintenance personnel or drivers is a well-thought-out, key prompt that directly addresses the core issue.

[0060] Optionally, the target alert information can refer to the most representative and root cause alert information retained from the third alert information set after in-depth understanding and analysis of the correlation. This target alert information can be a direct root cause alarm. The target alert information aims to provide a clear and direct overview of the abnormal operating state, enabling a quick grasp of the essence of the problem without being distracted by redundant alert information. For example, in a series of chain reactions triggered by "fuel pump failure," "fuel pump failure" is considered the target alert information, while "engine start failure" and "vehicle cannot start" can be derived alarms from the target alert information, that is, other alert information related to the target alert information.

[0061] In this embodiment, after aggregating the prompt information in the first prompt information set according to the aggregation strategy to obtain the second prompt information set, the third prompt information set can be determined based on the association relationship between at least two types of prompt information in the second prompt information set.

[0062] Optionally, before processing vehicle prompts, a detailed service dependency database can be imported or automatically generated. This database records the logical and physical dependencies between various systems and components within the vehicle; for example, the engine depends on the fuel pump, and tire balance depends on the suspension system status. As the vehicle operates, this database can be continuously updated to adapt to changes in vehicle configuration or the acquisition of new relationships, maintaining its accuracy and timeliness.

[0063] Optionally, key attributes of each message can be extracted from the second set of prompts. This allows for preliminary grouping of the second set of prompts according to these key attributes, facilitating subsequent correlation analysis. For each group of prompts within this preliminary grouping, a service dependency database is used to identify which prompts have causal relationships. For example, a fuel pump failure (root cause alarm) directly leads to engine start failure (derived alarm). Furthermore, the system can learn from historical data about common abnormal operating states, identifying which combinations of abnormal operating states frequently occur together, suggesting potentially deep correlations, even if the direct dependency between the two prompts is not obvious.

[0064] Optionally, after identifying related alerts, root cause alarms can be prioritized as target alerts. Alarms that are not directly root cause but have a wide impact can also be considered as target alerts to comprehensively understand the scope and severity of the vehicle's abnormal operating status. Based on the results of the correlation analysis, the alerts selected as target alerts are filtered to construct a third alert set. Simultaneously, alerts related to the target alerts—that is, those alerts already covered by the target alerts (root cause alarms)—can be suppressed to avoid duplicate alerts and reduce the burden on maintenance personnel or drivers.

[0065] In the embodiments of this application, the above method can greatly simplify the processing of vehicle prompt information through intelligent correlation identification and accurate positioning of target prompt information, ensuring that maintenance or drivers can quickly grasp the real operating status of the vehicle and make timely and effective response decisions.

[0066] Step S108: At least according to the third set of prompt information, switch the vehicle from the abnormal operating state to the normal operating state.

[0067] In the technical solution provided by step S108 in the embodiments of this application, the normal operating state can refer to the vehicle and its various systems and components being under the designed working conditions, and no abnormal situation exceeding the predetermined threshold or standard is detected.

[0068] In this embodiment, after determining the third set of prompt information based on the correlation between at least two types of prompt information in the second set of prompt information, the vehicle can be switched from abnormal operation state to normal operation state at least according to the third set of prompt information.

[0069] Optionally, the prompts in the third set of prompts can be categorized to distinguish between target prompts, aggregated prompts that are not related to other prompts, and prompts that do not meet the aggregation conditions. This allows for the development of targeted vehicle state switching strategies. The specific impact of these three types of prompts on the vehicle's operating state can be analyzed, for example, the degree of impact on vehicle performance, safety, and driving experience.

[0070] Optionally, based on the severity and urgency of the three types of alerts included in the third alert set, a processing priority order is determined. For example, the target alert can be processed first to eliminate the chain reaction caused by it. The resources required to repair each alert, such as maintenance personnel, spare parts, and special tools, are assessed to ensure reasonable allocation and efficient utilization of resources. Specific operation guidelines are generated for the three types of alerts. These operation guidelines may include, but are not limited to, fault location steps, solutions, and safe operating procedures to guide maintenance or on-site operations.

[0071] Optionally, following the above priority order, the faults indicated by the three types of prompts can be repaired separately. For example, the fault indicated by the target prompt can be repaired. This could involve replacing the damaged sensor, resetting the control system parameters, or performing a software upgrade to identify when the vehicle switches from an abnormal operating state to a normal operating state.

[0072] Optionally, after switching the vehicle from an abnormal operating state to a normal operating state, continuous monitoring of various systems and components within the vehicle can be conducted to collect operational data and ensure that no new faults have emerged. For each prompt message that has assisted the vehicle in completing the state switch, the entire process from the occurrence of the prompt message to its resolution can be recorded for subsequent data analysis and the development of preventative measures.

[0073] In steps S102 to S108 of this application embodiment, if it is necessary to process the vehicle's prompt information, a first set of vehicle prompt information can be obtained. It can be determined whether the first set of prompt information meets the aggregation conditions. If the first set of prompt information meets the aggregation conditions, it can be aggregated according to the aggregation strategy to obtain a second set of prompt information, thereby aggregating prompt information under the same evaluation dimension into one type of prompt information. A third set of prompt information can be determined based on the correlation between at least two types of prompt information in the second set of prompt information, thereby allowing only one type of the at least two correlated prompt information to be retained, avoiding excessively large amounts of prompt information data. The vehicle can be switched from an abnormal operating state to a normal operating state according to the third set of prompt information. In other words, in the above embodiment of this application, multiple homogeneous prompt information under the same evaluation dimension in the first set of prompt information that meets the aggregation conditions can be aggregated to form a more concise second set of prompt information, effectively avoiding redundancy in prompt information and reducing the burden of prompt information processing. Based on the inherent relationships between the prompts, a key third set of prompts is extracted, ensuring that only one target prompt is retained among multiple related prompts. This significantly improves the efficiency of quickly locating and responding to abnormal vehicle operating states. This method not only avoids the chaos caused by "large notifications" but also optimizes the switching path of vehicle operating states. It achieves the technical effect of improving the processing efficiency of vehicle prompts and solves the technical problem of poor prompt processing effectiveness.

[0074] The embodiments of this application will be described in detail below with reference to the steps described above.

[0075] As an optional implementation, step S102, obtaining the first set of prompt information for the vehicle, includes: in response to the vehicle being in an abnormal operating state, obtaining a set of prompt events for the vehicle, wherein the set of prompt events includes multiple prompt events; parsing the prompt events to obtain feature information of the prompt events; and determining the feature information of the prompt events in the set of prompt events as the first set of prompt information.

[0076] In this embodiment, during the acquisition of the vehicle's first set of alert information, if an abnormal operating state is detected, a set of alert events for the vehicle can be acquired. The alert event set can be parsed to obtain the characteristic information of the alert events. The characteristic information of the alert events in the alert event set can be determined as the first set of alert information. The alert event set can include various alert events. The aforementioned alert event set can refer to a series of alarms or alerts automatically or manually triggered when an abnormal operating state of the vehicle is detected. The alert events in the aforementioned alert event set can reflect the vehicle's operating status in real time, covering various situations from minor warnings to serious malfunctions. For example, the alert event set can include, but is not limited to, events such as: engine system alarm, decreased braking system performance, abnormal battery voltage, tire pressure below a safe threshold, and door not closed warning. Each alert event can carry information about the current state of a specific component or system of the vehicle.

[0077] Optionally, the characteristic information of a notification event can refer to a set of descriptive data obtained by parsing and analyzing the notification event. This characteristic information can be used to identify and analyze the nature, scope of impact, severity, and possible root causes of each notification event. For example, the characteristic information may include the type of notification event (e.g., "fuel pump failure"), the time of occurrence, the system or component involved (e.g., "left front tire pressure"), the specific value (e.g., "temperature abnormality reaches 100°C"), the geographical location, and a list of identified possible related events.

[0078] Optionally, once a signal indicating that the vehicle is in an abnormal operating state is detected or received, the acquisition of a set of alert events can be activated immediately. Real-time alert events can be acquired from multiple monitoring sources of the vehicle (e.g., sensors, in-vehicle networks, etc.). These alert events can be caused by various anomalies such as decreased engine efficiency, delayed braking system response, or malfunction of the vehicle stability control system. The collected alert events are recorded and formed into a set of alert events. Each alert event in the set is subjected to in-depth analysis; for example, metadata (e.g., event identifier, event time, event type, triggering conditions, location information, etc.) can be read to extract feature information. The extracted feature information is converted into a format that can be understood and processed; for example, data cleaning can be performed to remove noise or irrelevant data, resulting in processed feature information.

[0079] Optionally, the extracted feature information can be integrated to form a structured and well-organized database or dataset, resulting in the first set of prompt information. Each feature information is directly linked to the corresponding prompt event.

[0080] In this embodiment of the application, the above method can transform the original, chaotic prompt events into a structured, semantically rich set of first prompt information, laying the foundation for further intelligent processing of vehicle operating status.

[0081] As an optional implementation, the prompt event is parsed to obtain the feature information of the prompt event, including: parsing the label information, annotation information and / or prompt content of the prompt event from the prompt event, wherein the label information is used to indicate the source and / or attributes of the prompt event; and extracting feature information from the label information, annotation information and / or prompt content.

[0082] In this embodiment, during the parsing of the prompt event to obtain its feature information, the prompt event's tag information, annotation information, and / or prompt content can be extracted. Feature information can be extracted from the aforementioned tag information, annotation information, and / or prompt content. The tag information can be a structured data element used to accurately describe and classify the prompt information. The tag information can be in key-value pair form, allowing for highly granular identification of the prompt event's specific attributes and source. The tag information can include the prompt event's system name (e.g., "engine system"), subsystem or component (e.g., "fuel pump"), geographic location (e.g., "location"), vehicle type (e.g., "car"), fault code (e.g., "P0420"), etc. This content can be a feature component of the prompt event, facilitating intelligent grouping and aggregation.

[0083] Optionally, annotation information can be an unstructured descriptive supplement to the alert event, containing a deeper understanding or indication of the alert event, such as possible causes of the alert event, suggested handling steps, and related historical event identifiers. Annotation information can enrich the semantics of the alert event, providing additional troubleshooting guidance for operations and maintenance personnel.

[0084] Optionally, the prompt content can refer to the main description of the prompt event, that is, directly conveying specific information about what happened to the vehicle.

[0085] Optionally, the tag information in the received alert events can be parsed. For example, tag information in key-value pair form can be extracted from the alert events. Each tag and its corresponding value is recorded to obtain the tag information. The annotation information in the alert events can also be parsed. For example, free text or comment fields in the alert events used to describe possible causes of the alarm, suggested solutions, etc., can be found to obtain annotation information. The essence of the alert events can be understood and described. For example, the main information of the alarm can be read in depth to understand the direct cause and impact of the alert events, thus obtaining the alert content.

[0086] Optionally, the extracted tag information, annotation information, and prompt content are comprehensively analyzed to extract key features for intelligent alarm processing, thus obtaining feature information. For example, from the tag information, annotation information, and prompt content, key features such as the source, category, severity, scope of impact, and possible causes of the prompt event are identified and determined. These identified key features are organized into a structured information set to form feature information, facilitating subsequent intelligent processing of prompt information, such as grouping, aggregation, and root cause analysis.

[0087] As an optional implementation, the method further includes: grouping the prompt information in the first prompt information set according to a grouping strategy and based on feature information to obtain at least two subsets of prompt information, wherein the grouping strategy is used to represent the rules for grouping the prompt information in the first prompt information set.

[0088] In this embodiment, the prompts in the first set of prompts can be grouped based on feature information according to a grouping strategy, resulting in at least two subsets of prompts. The grouping strategy can be used to represent the rules for grouping the prompts in the first set of prompts. A grouping strategy is a set of rules used to logically categorize prompts with similar features. The rules in the grouping strategy are not limited to simple label matching; they can also be advanced rules based on complex logic and context analysis to understand the relationships between prompts, thereby managing and conveying prompts more effectively.

[0089] Optionally, standards and rules for grouping the prompts in the first set of prompts can be established in advance. These standards and rules can cover multiple dimensions and contexts of the prompts and formulate a grouping strategy.

[0090] Optionally, the original prompts are collected and organized to form a first set of prompts to be processed. A grouping strategy is applied to this first set of prompts, classifying them based on feature information. Each grouping strategy is traversed, comparing the feature information of each prompt with the conditions in the grouping strategy. The feature information of each prompt is evaluated to determine whether it satisfies the conditions of a particular grouping strategy. Prompts that satisfy the conditions of the same grouping strategy are grouped into the same subset of prompts.

[0091] In this embodiment, the above method not only effectively categorizes alert information based on predefined grouping strategies, improving the quality of alert information and operational efficiency, but also makes the processing suitable for handling large-scale, multi-dimensional monitoring alarms, helping operations teams focus on the issues that truly need attention and resolution.

[0092] As an optional implementation, the grouping strategy includes a first grouping strategy and a second grouping strategy. The subset of prompt information includes a first subset of prompt information and a second subset of prompt information. According to the grouping strategy, based on feature information, the prompt information in the first subset of prompt information is grouped to obtain at least two sets of prompt information, including: according to the first grouping strategy, prompt information in the first subset of prompt information whose feature information satisfies both task type conditions and exception type conditions is determined as elements in the first subset of prompt information, wherein the task type condition is used to characterize the task performed by the vehicle when it is in operation; according to the second grouping strategy, prompt information in the first subset of prompt information whose feature information satisfies both hardware device conditions and instance conditions is determined as elements in the second subset of prompt information, wherein the hardware device condition is used to represent the hardware resources that trigger the prompt information.

[0093] In this embodiment, during the process of grouping the prompt information in the first prompt information set according to the grouping strategy and based on the feature information, if the grouping strategy is the first grouping strategy, the prompt information whose feature information in the first prompt information set satisfies the task type condition and the exception type condition can be determined as elements in the first prompt information subset.

[0094] Optionally, the aforementioned first grouping strategy can be a rule used to identify and separate specific types of alert messages generated by vehicles or services performing specific tasks in the running state from the first alert message set. This first grouping strategy focuses on the correlation between abnormal events and tasks, classifying alert messages by identifying task types and abnormality types to enable targeted resource allocation and fault response. Task type conditions can be used to define and describe the characteristics of a vehicle or service when performing a certain type of task. These task type conditions can also be referred to as business context. For example, for vehicles, the task type could be "high-speed driving," "autonomous driving," or "parking and charging," while for other alarm sources, the task type could be the "order-service" business namespace. Abnormality type conditions can refer to specific abnormal situations described in the alert messages, which may be related to the performance, safety, or other key indicators of the vehicle or service. For example, abnormality type conditions could include: "High CPU Usage."

[0095] Optionally, establish the various task types performed by the vehicle or service under normal operating conditions, and the correlation between these task types and the prompt information. Establish a mapping relationship between task types in the business scenario (such as order processing, data backup, user authentication, etc.) and the characteristic information of prompt events (such as CPU utilization, network latency, etc.). Clarify which combinations of characteristic information represent specific task types; for example, "job: order-service" represents an order processing task. Determine which abnormal fluctuations in monitoring indicators should be considered alarms for running tasks, and the corresponding anomaly types. Analyze commonly used indicators in the monitoring system to identify which indicator anomalies may affect task execution, such as excessively high CPU utilization, memory leaks, and increased latency. Set specific indicator thresholds or states; when these thresholds are reached or exceeded, generate corresponding type of anomaly alarms, such as defining "CPU utilization exceeding 90%" as a "HighCPUUsage" anomaly.

[0096] Optionally, using the task type conditions defined above, filter the first set of alert information to include alerts related to a specific task. Iterate through the first set of alert information, checking the characteristic information (e.g., job, namespace, service) of each alert to see if it matches the predefined task type conditions. Mark the alerts that match the task type conditions as related to that task, obtaining a list of alerts related to the specific task. From this list of alerts related to the specific task, further filter out alerts that simultaneously meet the exception type conditions, forming a subset of the first set of alert information.

[0097] In this embodiment, the above method enables the precise classification of complex, raw prompts into a first subset based on clearly defined task and exception types. This provides a more focused set of prompts for subsequent intelligent processing (such as aggregation and root cause identification). The grouping strategy based on business scenarios and performance metrics helps system operation and maintenance and fault management teams identify and respond to important prompts more quickly, improving operational efficiency and fault repair speed.

[0098] In this embodiment, during the process of grouping the prompt information in the first prompt information set according to the grouping strategy and based on the feature information, if the grouping strategy is the second grouping strategy, the prompt information in the first prompt information that meets the hardware device conditions and instance conditions, which is outside the first prompt information subset, can be determined as elements in the second prompt information subset.

[0099] Optionally, the second grouping strategy described above can be a rule used to process the remaining alert information after the filtering by the first grouping strategy. This second grouping strategy focuses on the relationship between alert events and hardware devices and instances. By identifying hardware device conditions and instance conditions, this second grouping strategy can further refine alert information, distinguishing which alerts are triggered by specific hardware resources and the specific instances or services affected by the alerts, thus helping to more accurately locate problems. Hardware device conditions can be used to define the physical resource or device type that triggers the alarm. For example, "device= / dev / sdb1" can indicate that a specific disk device is the source of the alarm. Instance conditions can be conditions used to distinguish specific instances or service units. For example, "instance starting with 'web-node-'" means alert information related to a specific set of network server nodes.

[0100] Optionally, the remaining alert messages, excluding the first subset, are filtered from the first alert message set and processed by the second grouping strategy. The entire first alert message set is traversed, excluding alert messages already categorized into the first subset by the first grouping strategy, leaving those ungrouped. Alert messages are then filtered based on the hardware device conditions of the second grouping strategy. For example, the "device / device" tag or similar identifier in the remaining alert messages is checked to see if it matches preset hardware device conditions. Alert messages are identified as involving the disk " / dev / sdb1". Alert messages related to specific instances are further filtered based on the instance conditions of the second grouping strategy. Device-related alarms filtered in the previous step are evaluated to determine if they also match instance conditions. For example, alert messages are identified as having an instance tag starting with "web-node-". Alert messages that meet both the hardware device and instance conditions are formally integrated into the second alert message subset.

[0101] In this embodiment, the above method effectively identifies and groups alarm information related to specific hardware devices and instances, forming a second subset of alert information. This second subset of alert information not only helps to quickly locate hardware-level problems but also reduces alarm noise and improves the efficiency of fault diagnosis and handling.

[0102] As an optional implementation, the method further includes: determining that the first set of prompt information satisfies the aggregation condition in response to the number of prompt information in the subset of prompt information being greater than a quantity threshold; and determining that the first set of prompt information does not satisfy the aggregation condition in response to the number of prompt information in the subset of prompt information being less than or equal to the quantity threshold.

[0103] In this embodiment, if the number of prompts in the subset of prompts is greater than a quantity threshold, it can be determined that the first set of prompts meets the aggregation condition. Conversely, if the number of prompts in the subset of prompts is less than or equal to the quantity threshold, it can be determined that the first set of prompts does not meet the aggregation condition.

[0104] Optionally, the quantity threshold can be a parameter used to determine when aggregation is triggered. It can be a predefined value used to measure whether the number of alerts in a subset of alert information meets the minimum requirement for aggregation. When the number of alerts in a subset of alert information exceeds the aforementioned quantity threshold, the alerts are considered a group with common characteristics, thus triggering the aggregation mechanism to merge the alerts into a higher-level, more generalized alert. For example, the quantity threshold can be pre-set to a threshold N.

[0105] Optionally, based on system policies and historical data, a reasonable quantity threshold N can be set as the baseline for triggering aggregation. For each subset of alert information filtered by the grouping strategy, the number of alarm messages within it is counted. This can be done, for example, using a simple counting function or a database query, ensuring the accuracy of the results. The number of alert messages in the subset is then checked to see if it exceeds the quantity threshold N. If the number exceeds the quantity threshold N, aggregation is triggered, indicating that the subset of alert information meets the aggregation criteria. If the number of alert messages in the subset is less than or equal to the quantity threshold N, the subset is considered not to meet the aggregation criteria, meaning that the current subset of alert information is insufficient to constitute a situation requiring aggregation.

[0106] In this embodiment, the above method automatically triggers an aggregation mechanism when a storm of notification messages or a large number of homogeneous notification messages are detected, generating more readable and operable aggregated notification messages, thereby improving the work efficiency of the operations and maintenance team. Simultaneously, by reasonably setting the quantity threshold, it ensures that only notification messages that truly require attention can be aggregated, avoiding unnecessary loss of notification messages.

[0107] As an optional implementation, step S104, in response to the first set of prompt information satisfying the aggregation condition, aggregates the first set of prompt information according to the aggregation strategy to obtain a second set of prompt information, including: in response to the subset of prompt information satisfying the aggregation condition, aggregating multiple prompt information under the same evaluation dimension in the subset of prompt information according to the aggregation strategy to obtain aggregated prompt information under the evaluation dimension; and determining the aggregated prompt information under multiple evaluation dimensions as the second set of prompt information.

[0108] In this embodiment, during the aggregation of the first set of prompt information, if a subset of prompt information meets the aggregation conditions, multiple prompt information items under the same evaluation dimension within the subset can be aggregated according to the aggregation strategy to obtain aggregated prompt information under the evaluation dimension. The aggregated prompt information under multiple evaluation dimensions can be determined as the second set of prompt information. The aggregated prompt information can be a type of intelligently processed prompt information, designed to convey large-scale faults or trend changes more efficiently and accurately, while reducing the redundancy and complexity of the original prompt information.

[0109] Optionally, aggregation is performed on a subset of alert messages that meet the aggregation criteria to generate higher-level aggregated alert messages. A new, more descriptive alert name is created for the subset of alerts that meet the criteria. High-level tags most relevant to the aggregated alerts, such as cluster and service name, are retained, while instance-level tags, such as pod_id, are removed. Key information about the alerts within the subset is collected and summarized, such as the number of alerts, the list of affected core instances, and the first and last trigger times. The severity level of the alerts within the subset is increased to reflect the cumulative impact of a large number of alerts. The aggregated alert messages are then integrated to form a second alert message set.

[0110] As an optional implementation, step S106, determining a third set of prompt information based on the association between prompt information in the second set of prompt information, includes: determining a target prompt information from at least two types of prompt information based on the association between at least two types of prompt information, wherein the target prompt information is used to indicate the reason for triggering prompt information other than the target prompt information among the at least two types of prompt information; determining the target prompt information as an element in a fourth set of prompt information, and determining the prompt information other than the target prompt information among the at least two types of prompt information as an element in a fifth set of prompt information; and determining the subset of prompt information in the first set of prompt information that does not meet the aggregation condition, the fourth set of prompt information, and the fifth set of prompt information as the third set of prompt information.

[0111] In this embodiment, during the process of determining the third set of prompt information based on the correlation between prompt information in the second set of prompt information, the target prompt information can be determined from at least two types of prompt information according to the correlation. The target prompt information can be determined as the fourth prompt information, and the prompt information other than the fourth prompt information in the at least two sets of prompt information can be determined as elements in the fifth set of prompt information. The fourth set of prompt information can be a set of prompt information that, after analysis and identification, is considered to be the target prompt information (root cause fault alarm). The prompt information in the fourth set of prompt information can represent the cause of one or more types of derived alarms. The fifth set of prompt information can include derived or directly related prompt information other than the root cause fault alarm. For example, if alarm A for network outage is the root cause fault, then all service unavailability alarms caused by node network problems will be included in the fifth set of prompt information. The prompt information in the fifth set of prompt information can include a large amount of specific instance information, such as the affected Pods and service names. However, since the above prompt information is directly caused by alarm A, it is not necessary to inform all of it to the operations and maintenance personnel during processing to avoid prompt information overload.

[0112] Optionally, a deeper correlation analysis is performed on the alarms in the second alert information set to identify the root cause alarm—the target alert information. The target alert information (root cause alarm) is separated from the remaining derived or directly related alarms; the target alert information constitutes the fourth alert information set, and the remaining derived or directly related alarms constitute the fifth alert information set. The original alarms in the first alert information set that do not meet the aggregation conditions are merged with the fourth and fifth alert information sets to form the final third alert information set, which is used for subsequent alarm management and notification.

[0113] For example, analyze the alarms in the second alert set to identify potential dependencies. Apply a service dependency graph to assess which alarms might be indirectly caused by other alarms. Determine the target alert, the most likely "root cause alarm," which can explain or cause at least two other alarms. A list of target alerts represents candidate elements for the fourth alert set. Compare the second alert set with the target alert list to determine which elements are root cause alarms. Remove all root cause alarms from the second alert set; the remaining elements are derived alarms. Add root cause alarm elements to the fourth alert set, and assign derived alarm elements to the fifth alert set. Collect all alarm subsets from the first alert set that do not meet the aggregation criteria. Combine the fourth alert set (root cause alarms) with the unaggregated subset of original alarms. Add the fifth alert set (suppressed derived alarms) to the combination. Construct the third alert set, ensuring it contains all necessary alarm information, regardless of whether it has been aggregated or suppressed.

[0114] In this embodiment, the core of the method is to identify and separate the root cause of the fault from the resulting alert information. By clearly marking and prioritizing the root cause alarms, while suppressing or aggregating derived alarms, key information can be conveyed more effectively, information overload can be avoided, and maintenance personnel can locate and resolve problems more quickly. By integrating unaggregated original alarms, root cause alarms, and their derived alarms, the third alert information set provides a comprehensive and efficient solution for alarm management.

[0115] The following explanation will further illustrate the method of this application embodiment, using the prompt information as the alarm information and taking alarm sources that require status detection and alarming, including vehicles, as an example.

[0116] Figure 2 is a flowchart of an alarm information processing method for an alarm source according to an embodiment of this application. As shown in Figure 2, the method may include the following steps.

[0117] Step S202: Obtain the first alarm information set of the alarm source to be processed.

[0118] In the technical solution provided by step S202 in the embodiments of this application, the first alarm information set includes a variety of alarm information, which is used to characterize that the alarm source is in an abnormal operating state under the evaluation dimension.

[0119] Step S204: In response to the first alarm information set meeting the aggregation conditions, the first alarm information set is aggregated according to the aggregation strategy to obtain the second alarm information set.

[0120] In the technical solution provided by step S204 of the embodiments of this application, the aggregation strategy is used to represent the rule of aggregating multiple alarm information under the same evaluation dimension into one alarm information.

[0121] Step S206: Determine the third alarm information set based on the correlation between at least two types of alarm information in the second alarm information set.

[0122] In the technical solution provided by step S206 in the embodiments of this application, the third alarm information set includes target alarm information, which is one of at least two alarm information that are related in the second alarm information set.

[0123] In steps S202 to S206 of this application embodiment, a first alarm information set of the alarm source to be processed is obtained; in response to the first alarm information set satisfying the aggregation condition, the first alarm information set is aggregated according to the aggregation strategy to obtain a second alarm information set; based on the correlation between at least two types of alarm information in the second alarm information set, a third alarm information set is determined, thereby achieving the technical effect of improving the alarm information processing efficiency of the alarm source and solving the technical problem of poor alarm information processing effect of the alarm source.

[0124] The embodiments of this application will be described in detail below with reference to the steps described above.

[0125] As an optional implementation, the third alarm information set is converted to the notification system; and / or, at least according to the third prompt information set, the alarm source is switched from the abnormal operating state to the normal operating state.

[0126] In this embodiment, the notification system serves as a bridge for communication between alarm information and key operations and maintenance personnel. The notification system is used to promptly and accurately convey the third alarm information set from detected alarm sources to relevant personnel or systems, ensuring that alarm information is neither missed nor delayed. For example, the aforementioned notification system can be an application such as electronic mail (Email for short), and no specific limitations are made here.

[0127] The technical solutions of the embodiments of this application will be illustrated below with reference to preferred embodiments.

[0128] With the widespread adoption of cloud-native and microservice architectures, Prometheus has become a leading open-source monitoring system. The core component of Prometheus, Alertmanager, handles alerts generated by the Prometheus Server, performing grouping, suppression, silencing, and routing. In related technologies, Alertmanager's existing grouping functionality is based on the `group_by` configuration option, merging alerts with the same label into a single notification. However, this becomes less effective when dealing with large-scale, multi-layered infrastructure monitoring (e.g., monitoring CPU, memory, disk I / O, and other metrics for thousands of containers).

[0129] The methods described above have significant drawbacks: 1) Alarm storm problem: When a wide-area failure occurs in the underlying infrastructure (such as a power outage in a physical rack or a network anomaly in an availability zone), a massive number of homogeneous alarms will be triggered instantly (e.g., hundreds of containers simultaneously reporting "high CPU utilization"). Although Alertmanager can group these alarms, the recipients (such as operations personnel and on-call systems) will still receive a "large notification" containing a large number of alarm instances, resulting in severe information overload and making it impossible to quickly locate the root cause of the failure. 2) Root cause failure masking: The relevant grouping mechanism is flat and lacks the identification of causal relationships among alarms. For example, the failure of a node is the "root cause failure," while the unavailability of all services running on that node is a "derived alarm." Existing technologies will group these alarms together equally, failing to automatically identify and prioritize the "node failure" as the root cause, forcing operations personnel to manually search for the root cause among a large number of alarms, resulting in low efficiency. 3) Rigid aggregation dimension: The relevant group_by configuration is static and cannot dynamically adjust the aggregation strategy according to the real-time context of the alarms. For example, it is not possible to implement intelligent logic such as "when the error rate alarms for the same service exceed 10, automatically aggregate them into a summary alarm of 'service as a whole'".

[0130] Therefore, there is an urgent need for a technical solution that can more intelligently and deeply group and aggregate basic monitoring alarms, and automatically identify and suppress derivative alarms, thereby significantly improving alarm readability and operational efficiency.

[0131] Figure 3 is a schematic diagram of a monitoring and alarm suppression architecture based on multi-dimensional grouping and dynamic aggregation according to an embodiment of this application. As shown in Figure 3, the architecture may include an existing monitoring stack 31, the intelligent alarm aggregation system 32 of this application, and an external data source 33. The existing monitoring stack 31 may include a Prometheus Server 311, an alarm receiver 312, an Alertmanager 313, and a notification channel 314. The intelligent alarm aggregation system 32 of this application may include an aggregation processor 321, an alarm transmitter 322, a root cause analyzer 323, and a rule engine 324. The notification channel 314 may include Email / DingTalk, etc., without specific limitations. The external data source 33 may include a service dependency graph, a configuration management database (CMDB), and a service mesh, etc.

[0132] Alarm receiver 312 receives and caches raw alarms from Prometheus Server 311. Rule engine 324 stores and manages multidimensional grouping rules, dynamic aggregation thresholds, and service dependency graphs. Aggregator processor 312 can be the core processing module, performing operations including calling the feature extraction module and parsing alarms. Based on the rules in rule engine 324, it matches and groups alarms, executes aggregation logic, determines whether the summary generation threshold has been reached, and generates aggregated summary alarms. Root cause analyzer 323 works in conjunction with aggregation processor 321 to query the dependency graph, identify root cause alarms, and execute suppression logic. Alarm sender 322 forwards processed alarms (aggregated alarms and unsuppressed root cause alarms) to downstream Alertmanager 314.

[0133] Figure 4 is a flowchart of a dynamic aggregation and summary generation process according to an embodiment of this application. As shown in Figure 4, the method may include the following steps.

[0134] Step S401: Receive the original alarm queue.

[0135] In this embodiment, raw alerts from Prometheus or other alert sources are received. The tag set, annotation set, and alert content of each alert are parsed to extract key features. For example, the extracted key features may include: job, instance, cluster, namespace, pod, device, alert name, and severity.

[0136] Optionally, the following original alerts were received: NodeDown (instance=node-01), KubePodNotReady (pod=svc-a-1234,node=node-01), KubePodNotReady (pod=svc-b-5678,node=node-01), HighCPUUsage (pod=svc-c-9012,node=node-01), and other false alarms caused by NodeDown... (a total of 50 Pod-related alerts).

[0137] Step S402: Group according to multidimensional rules.

[0138] In this embodiment, during the multidimensional grouping matching process, alarms can be matched against predefined multidimensional grouping rules. These multidimensional grouping rules go beyond simple `group_by` and are sets of rules that include logical judgments. For example:

[0139] Rule 1: Alerts with alertname="HighCPUUsage", cluster="prod", and namespace="order-service" are grouped together.

[0140] Rule 2: Group all alerts with device=" / dev / sdb1" and instance starting with "web-node-" into one group.

[0141] Step S403: Check whether the polymerization conditions are met.

[0142] In this embodiment, if the aggregation condition is met, step S404 can be executed; otherwise, if the aggregation condition is not met, step S405 can be executed.

[0143] Optionally, rule three (dynamic aggregation rule) can be: when the number of alarms in a group exceeds the threshold N, trigger the aggregation summary.

[0144] Step S404: Generate an aggregated summary alarm.

[0145] In this embodiment, for alarm groups that trigger aggregation conditions, the system does not issue all original alarms within the group, but instead generates a new aggregated summary alarm. This new alarm has: a new alarm name, such as aggregating from "High Container CPU Utilization" to "Surge in CPU Load of Order Service Cluster"; a summary label, retaining the core dimensions of the group (such as cluster, service) and removing instance-level labels (such as pod_id); critical annotations, including the number of original alarms, a list of affected core instances (such as the top 5), and the first and last trigger times; and a higher severity level (optional), which can aggregate a large number of low-level warnings into a single high-level critical alarm.

[0146] Optionally, rule matching: The system rule includes a clause: "Group all alarms with node=node-01 into one group." Dynamic triggering occurs when the number of alarms in this group quickly exceeds a preset threshold (e.g., 5), triggering aggregation. Summary generation: The aggregation processor creates a new alarm.

[0147] name:"NodeFailureDerivedAlerts";

[0148] Summary: "Node-01 is abnormal, resulting in 52 related alarms";

[0149] labels:{cluster=prod, node=node-01, aggregated="true"};

[0150] annotations:{root_cause: NodeDown",alert_count:"52",affected_services:"svc-a, svc-b, ..."}.

[0151] Step S405: Follow the original alarm normal route.

[0152] Step S406: Replace the original alarm group with aggregated alarms.

[0153] Step S407: Send to the root cause analyzer.

[0154] In this embodiment, the system maintains a service dependency graph (which can be statically configured or dynamically discovered). This dependency graph is used for root cause analysis before and after generating aggregated alerts. When an alert A (e.g., "NodeNetworkDown") is detected as a potential root cause of another alert B (e.g., "PodUnreachable"), the system will suppress alert B and only issue alert A. The aggregated summary alert can explicitly state that "this aggregated alert may have been caused by [root cause alert ID]".

[0155] Optionally, the root cause analyzer identifies NodeDown as the root cause alarm based on Kubernetes dependencies (Pod depends on Node). It then issues a root cause alarm, NodeDown. An aggregate summary alarm, NodeFailureDerivedAlerts, is also issued to describe the scope of impact. Finally, all 50 original, specific Pod and business alarms are suppressed to prevent them from being sent to operations personnel.

[0156] Step S408: The alarm transmitter sends the final alarm.

[0157] In this embodiment, the final generated aggregated summary alarms and the independent root cause alarms that were not aggregated / suppressed are sent to Alertmanager for subsequent routing and notification.

[0158] Optionally, operations and maintenance personnel will only receive two alerts on DingTalk / Lark / WeChat Work:

[0159] [CRITICAL] NodeDown on node-01;

[0160] [WARNING] [Aggregated] NodeFailureDerivedAlerts: Node node-01 is abnormal, affecting 52 services.

[0161] Using the above method, operations and maintenance personnel can immediately see "what problem has occurred and how much impact it has" and start fixing node-01, instead of being overwhelmed by a large number of irrelevant derivative alarms.

[0162] It should be noted that the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, data stored, data displayed, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. Furthermore, the collection, use and processing of the relevant data must comply with the relevant laws, regulations and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0163] According to another aspect of the embodiments of this application, corresponding to the embodiments of the above-described vehicle prompt information processing method, this specification also provides a vehicle prompt information processing system.

[0164] Figure 5 is a schematic diagram of a vehicle prompt information processing system according to an embodiment of this application. As shown in Figure 5, the vehicle prompt information processing system 50 may include: a receiving unit 502, a rule engine 504, an aggregation processor 506, and a relationship analyzer 508. The receiving unit 502 is used to receive a first set of vehicle prompt information; the rule engine 504 is used to determine whether the first set of prompt information meets the aggregation conditions; the aggregation processor 506 is used to aggregate the first set of prompt information according to an aggregation strategy in response to the first set of prompt information meeting the aggregation conditions, to obtain a second set of prompt information; the relationship analyzer 508 is used to obtain the association relationship between at least two types of prompt information in the second set of prompt information; and determine a third set of prompt information based on the association relationship.

[0165] The embodiments of this application will be described in detail below with reference to the steps described above.

[0166] As an optional implementation, the system may further include: a prompt forwarding module for forwarding a third prompt information set to a notification system; and / or a prompt adjustment module for switching the vehicle from an abnormal operating state to a normal operating state, at least according to the third prompt information set.

[0167] According to another aspect of the embodiments of this application, corresponding to the embodiments of the above-described vehicle prompt information processing method, this specification also provides a vehicle prompt information processing device.

[0168] Figure 6 is a schematic diagram of a vehicle prompt information processing device according to an embodiment of this application. As shown in Figure 6, the vehicle prompt information processing device 60 may include: a first acquisition module 602, a first aggregation module 604, a first determination module 606, and a switching module 608. The first acquisition module 602 is used to acquire a first set of vehicle prompt information; the first aggregation module 604 is used to aggregate the first set of prompt information according to an aggregation strategy in response to the first set of prompt information meeting aggregation conditions, to obtain a second set of prompt information; the first determination module 606 is used to determine a third set of prompt information based on the association relationship between at least two types of prompt information in the second set of prompt information; and the switching module 608 is used to switch the vehicle from an abnormal operating state to a normal operating state, at least according to the third set of prompt information.

[0169] Figure 7 is a schematic diagram of an alarm information processing device for an alarm source according to an embodiment of this application. As shown in Figure 7, the alarm information processing device 70 for the alarm source may include: a second acquisition module 702, a second aggregation module 704, and a second determination module 706. The second acquisition module 702 is used to acquire a first alarm information set of the alarm source to be processed; the second aggregation module 704 is used to aggregate the first alarm information set according to an aggregation strategy in response to the first alarm information set meeting the aggregation conditions, to obtain a second alarm information set; and the second determination module 706 is used to determine a third alarm information set based on the correlation between at least two types of alarm information in the second alarm information set.

[0170] Embodiments of this application also provide a vehicle, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods described in various embodiments of this application when it runs.

[0171] According to another aspect of the embodiments of this application, an alarm source is also provided, including: a memory storing an executable program; and a processor for running the program, wherein the program executes the methods in various embodiments of this application when it runs.

[0172] Embodiments of this application also provide an electronic device, including a memory storing an executable program; and a processor for running the program, wherein the program executes the methods of various embodiments of this application during runtime.

[0173] Embodiments of this application also provide a computer-readable storage medium including a stored executable program, wherein, when the executable program is running, it controls the device where the computer-readable storage medium is located to perform the methods of various embodiments of this application.

[0174] Embodiments of this application also provide a computer program product, including a computer program that, when executed by a processor, implements the methods of various embodiments of this application.

[0175] Embodiments of this application also provide a computer program product, including a non-volatile computer-readable storage medium for storing a computer program that, when executed by a processor, implements the methods in various embodiments of this application.

[0176] Embodiments of this application also provide a computer program that, when executed by a processor, implements the methods described in the various embodiments of this application.

[0177] In the above embodiments of this application, the descriptions of each embodiment have different focuses. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments.

[0178] In the several embodiments provided in this application, it should be understood that the disclosed technical content can be implemented in other ways. The device embodiments described above are merely illustrative; for example, the division of units can be a logical functional division, and in actual implementation, there may be other division methods. For instance, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the displayed or discussed mutual couplings, direct couplings, or communication connections may be through some interfaces; indirect couplings or communication connections between units or modules may be electrical or other forms.

[0179] The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple units. Some or all of the units can be selected to achieve the purpose of this embodiment according to actual needs.

[0180] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0181] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, read-only memory (ROM), random access memory (RAM), portable hard drives, magnetic disks, or optical disks.

[0182] The above description is only a preferred embodiment of this application. It should be noted that for those skilled in the art, several improvements and modifications can be made without departing from the principle of this application, and these improvements and modifications should also be considered within the scope of protection of this application.

Claims

1. A method for processing vehicle notification information, characterized in that, include: A first set of prompt information for the vehicle is obtained, wherein the first set of prompt information includes multiple prompt information, which indicates that the vehicle is in an abnormal operating state under the evaluation dimension; in response to the first set of prompt information satisfying the aggregation condition, the first set of prompt information is aggregated according to the aggregation strategy to obtain a second set of prompt information, wherein the aggregation strategy represents a rule for aggregating multiple prompt information under the same evaluation dimension into one prompt information; a third set of prompt information is determined based on the correlation between at least two prompt information in the second set of prompt information, wherein the third set of prompt information includes target prompt information, which is one of at least two prompt information in the second set of prompt information that has the correlation; the vehicle is switched from the abnormal operating state to a normal operating state at least according to the third set of prompt information.

2. The method according to claim 1, characterized in that, Obtaining a first set of prompt information for the vehicle includes: in response to the vehicle being in the abnormal operating state, obtaining a set of prompt events for the vehicle, wherein the set of prompt events includes multiple prompt events; parsing the prompt events to obtain feature information of the prompt events; and determining the feature information of the prompt events in the set of prompt events as the first set of prompt information.

3. The method according to claim 2, characterized in that, Parsing the prompt event to obtain its feature information includes: parsing the prompt event's tag information, annotation information, and / or prompt content, wherein the tag information is used to indicate the source and / or attribute of the prompt event; extracting the feature information from the tag information, the annotation information, and / or the prompt content; or, the method further includes: grouping the prompt information in the first prompt information set according to a grouping strategy based on the feature information to obtain at least two subsets of prompt information, wherein the grouping strategy is used to represent the rules for grouping the prompt information in the first prompt information set.

4. The method according to claim 3, characterized in that, The grouping strategy includes a first grouping strategy and a second grouping strategy. The subset of prompt information includes a first subset of prompt information and a second subset of prompt information. According to the grouping strategy, based on the feature information, the prompt information in the first subset of prompt information is processed to obtain at least two sets of prompt information, including: according to the first grouping strategy, determining the prompt information in the first subset of prompt information whose feature information satisfies the task type condition and the exception type condition as elements in the first subset of prompt information, wherein the task type condition is used to characterize the task performed by the vehicle in the operating state; according to the second grouping strategy, determining the prompt information in the first subset of prompt information whose feature information satisfies the hardware device condition and the instance condition, excluding the first subset of prompt information, as elements in the second subset of prompt information, wherein the hardware device condition is used to represent the hardware resources that trigger the prompt information.

5. The method according to claim 4, characterized in that, The method further includes: determining that the first set of prompt information satisfies the aggregation condition in response to the number of prompt information in the subset of prompt information being greater than a quantity threshold; determining that the first set of prompt information does not satisfy the aggregation condition in response to the number of prompt information in the subset of prompt information being less than or equal to the quantity threshold; or, in response to the first set of prompt information satisfying the aggregation condition, aggregating the first set of prompt information according to an aggregation strategy to obtain a second set of prompt information, including: in response to the subset of prompt information satisfying the aggregation condition, aggregating multiple prompt information under the same evaluation dimension in the subset of prompt information according to the aggregation strategy to obtain aggregated prompt information under the evaluation dimension; and determining the aggregated prompt information under the multiple evaluation dimensions as the second set of prompt information.

6. The method according to any one of claims 1 to 5, characterized in that, Determining a third set of prompt information based on the relationships between the prompt information in the second set of prompt information includes: determining a target prompt information from at least two types of prompt information based on the relationships between them, wherein the target prompt information is used to indicate the reason for triggering the prompt information other than the target prompt information in the at least two types of prompt information; determining the target prompt information as an element in a fourth set of prompt information, and determining the prompt information other than the target prompt information in the at least two types of prompt information as an element in a fifth set of prompt information; and determining the subset of prompt information in the first set of prompt information that does not satisfy the aggregation condition, the fourth set of prompt information, and the fifth set of prompt information as the third set of prompt information.

7. A vehicle notification information processing system, characterized in that, include: A receiving unit is configured to receive a first set of prompt information for the vehicle, wherein the first set of prompt information includes multiple prompt information, the prompt information being used to characterize that the vehicle is in an abnormal operating state under the evaluation dimension; a rule engine is configured to determine whether the first set of prompt information satisfies an aggregation condition; an aggregation processor is configured to, in response to the first set of prompt information satisfying the aggregation condition, aggregate the first set of prompt information according to an aggregation strategy to obtain a second set of prompt information, wherein the aggregation strategy is used to represent a rule for aggregating multiple prompt information under the same evaluation dimension into one prompt information; a relationship analyzer is configured to obtain the association relationship between at least two types of prompt information in the second set of prompt information; and determine a third set of prompt information based on the association relationship, wherein the third set of prompt information includes target prompt information, the target prompt information being one of at least two types of prompt information in the second set of prompt information that have the association relationship.

8. The system according to claim 7, characterized in that, The system further includes: a prompt forwarding module, used to forward the third prompt information set to the notification system; and / or, a prompt adjustment module, used to switch the vehicle from the abnormal operating state to the normal operating state at least according to the third prompt information set.

9. A method for processing alarm information from an alarm source, characterized in that, include: A first alarm information set of the alarm source to be processed is obtained, wherein the first alarm information set includes multiple alarm information, and the alarm information is used to characterize that the alarm source is in an abnormal operating state under the evaluation dimension; in response to the first alarm information set satisfying the aggregation condition, the first alarm information set is aggregated according to the aggregation strategy to obtain a second alarm information set, wherein the aggregation strategy is used to represent the rule for aggregating multiple alarm information under the same evaluation dimension into one alarm information; a third alarm information set is determined according to the correlation between at least two alarm information in the second alarm information set, wherein the third alarm information set includes target alarm information, and the target alarm information is one of the at least two alarm information in the second alarm information set that has the correlation relationship.

10. The method according to claim 9, characterized in that, The method further includes: converting the third alarm information set to a notification system; and / or, at least according to the third prompt information set, switching the alarm source from the abnormal operating state to the normal operating state.

Images