Agent-driven dispatch monitoring risk prediction and trace-back method and system

Abstract

The application discloses an agent-driven dispatching monitoring risk prediction and tracing method and system, relates to the technical field of dispatching monitoring, and comprises the following steps: constructing a vertical field model containing software risk knowledge and hardware risk knowledge based on software information and hardware information in a historical risk state of a dispatching system; constructing an operation prediction model based on time sequence correlation and action correlation according to historical software information, historical hardware information and historical dispatching events of the dispatching system; constructing a risk prediction model based on an agent architecture according to the operation prediction model and the vertical field model; taking real-time dispatching events as real-time input of the risk prediction model, outputting a risk prediction result by the risk prediction model, and obtaining a tracing result according to a cause-effect relationship in the risk prediction result. The application has the beneficial effects of improving the accuracy and intervention efficiency of risk prediction and tracing.

Description

Technical Field

[0001] This application relates to the field of scheduling and monitoring technology, and in particular to a method and system for risk prediction and tracing of scheduling and monitoring driven by intelligent agents. Background Technology

[0002] With the rapid development of cloud computing, distributed computing, and large-scale heterogeneous computing platforms, scheduling systems need to coordinate the management of massive hardware resources and complex software application stacks. They also need to identify and handle risks at both the software and hardware levels in a timely manner to avoid task execution delays or system crashes.

[0003] In related technologies, monitoring of scheduling systems relies on alarm mechanisms based on fixed thresholds and rule engines based on expert experience. This leads to a failure to identify and respond promptly to cascading or combined risks, a lack of predictive ability for potential risks, and low system maintenance efficiency. Furthermore, the maintenance of rule engines is highly dependent on the domain knowledge of operations personnel, making them unable to adapt to rapidly changing environments and resulting in low automation.

[0004] Therefore, related technologies for scheduling and monitoring risk prediction and tracing suffer from problems such as poor accuracy in risk prediction and low efficiency in intervention.

[0005] The patent "Dynamic Adjustment Method for Front-End Service Channel of Power Grid Monitoring System Based on Risk Prediction," publication number CN113411265A, published on September 17, 2021, specifically discloses a method where, within a first time period, if the current instance data upload volume of the first server instance exceeds a first preset data upload volume for the first server instance, a new second backup channel is established between the second remote terminal unit and the third server instance, and then the second backup channel between the second remote terminal unit and the first server instance is closed. Within a second time period following the first time period, if the current instance data upload volume of the first server instance is less than the second preset data upload volume for the first server instance, the second backup channel between the second remote terminal unit and the first server instance is restored, and then the new second backup channel between the second remote terminal unit and the third server instance is closed. This solution adjusts the monitoring system through real-time monitoring and prediction of server load, but risk prediction still relies on fixed preset values, failing to adapt to the actual state of the dispatching system. Summary of the Invention

[0006] This application addresses the problems of poor risk prediction accuracy and low intervention efficiency in scheduling monitoring risk prediction and tracing in related technologies. It provides an agent-driven scheduling monitoring risk prediction and tracing method and system. By constructing risk knowledge corresponding to different functional domains through vertical domain models, the system runs a prediction model to predict the response order and information level between software and hardware in advance based on real-time scheduling events. It compares risk values ​​with risk thresholds, so that the risk value changes with the changes in real-time scheduling events, and the risk threshold changes with the changes in different risk types. Through bidirectional dynamic changes, the risk value is made more consistent with the actual scheduling situation, and the risk threshold is made more consistent with the actual scenario, thereby improving the accuracy and intervention efficiency of risk prediction and tracing.

[0007] To achieve the aforementioned technical objectives, this application provides a technical solution: an agent-driven scheduling monitoring risk prediction and tracing method, comprising the following steps: constructing a vertical domain model containing software risk knowledge and hardware risk knowledge based on software and hardware information under historical risk states of the scheduling system; constructing an operation prediction model based on temporal correlation and action correlation according to historical software information, historical hardware information, and historical scheduling events of the scheduling system; constructing a risk prediction model based on the agent architecture, the operation prediction model, and the vertical domain model; using real-time scheduling events as real-time input to the risk prediction model, the risk prediction model outputs risk prediction results, and tracing results are obtained based on the causal relationships in the risk prediction results.

[0008] Furthermore, the construction of a vertical domain model containing software risk knowledge and hardware risk knowledge based on software and hardware information under historical risk states of the scheduling system includes: dividing the scheduling system into functional regions based on functional types; constructing functional region knowledge based on software and hardware information under historical risk states corresponding to the functional regions; constructing full-region knowledge based on the common knowledge in all functional region knowledge; and constructing a vertical domain model containing software risk knowledge and hardware risk knowledge using functional region knowledge and full-region knowledge.

[0009] Furthermore, the construction of functional area knowledge based on software and hardware information under historical risk states corresponding to functional areas includes: obtaining software and hardware information under historical risk states for each functional area; classifying software and hardware information based on risk types to obtain a risk set; performing causal analysis and risk degree analysis on the elements in the risk set to determine the weights of software and hardware information types; constructing a risk threshold based on the risk set, software and hardware information type weights; and constructing functional area knowledge using the risk threshold, software and hardware information type weights.

[0010] Furthermore, the step of determining the weights of software information types and hardware information types by performing causal analysis and risk level analysis on the elements in the risk set includes: constructing software information type risk trends based on the frequency of occurrence of each risk level of the software information type in the risk set; constructing hardware information type risk trends based on the frequency of occurrence of each risk level of the hardware information type in the risk set; constructing correction relationships based on the causal relationships between software information types, between hardware information types, and between software information types and hardware information types; constructing software information type weights based on software information type risk trends and correction relationships; and constructing hardware information type weights based on hardware information type risk trends and correction relationships.

[0011] Furthermore, the construction of a vertical domain model containing software risk knowledge and hardware risk knowledge based on software and hardware information under historical risk states of the scheduling system includes: dividing the scheduling system into functional regions based on functional types; constructing functional region knowledge based on software and hardware information under historical risk states corresponding to the functional regions; constructing full-region knowledge based on the risk transmission probability of all functional regions; wherein, the risk transmission probability represents the probability that both functional regions are at risk in the same scheduling event; and constructing a vertical domain model containing software risk knowledge and hardware risk knowledge using functional region knowledge and full-region knowledge.

[0012] Furthermore, the step of constructing an operation prediction model based on the historical software information, historical hardware information, and historical scheduling events of the scheduling system, according to temporal correlation and action correlation, includes: constructing the runtime sequence relationship corresponding to the scheduling events based on the temporal sequence of changes in historical software information and historical hardware information corresponding to the historical scheduling events in the scheduling system; constructing the action correlation relationship corresponding to the scheduling events based on the historical software actions and historical hardware actions corresponding to the historical scheduling events in the scheduling system; and constructing the operation prediction model based on the runtime sequence relationship and action correlation relationship.

[0013] Furthermore, the construction of action associations corresponding to scheduling events based on historical software actions and historical hardware actions corresponding to historical scheduling events in the scheduling system includes: obtaining theoretical change information of each software and theoretical change information of each hardware based on the scheduling events; obtaining software action thresholds based on the same software action according to the theoretical change information of each software and the software information of the previous time sequence of the software action; obtaining hardware action thresholds based on the same hardware action according to the theoretical change information of each hardware and the hardware information of the previous time sequence of the hardware action; and constructing action associations based on the software action thresholds and the hardware action thresholds.

[0014] Furthermore, the step of using real-time scheduling events as real-time input to the risk prediction model, outputting risk prediction results, and obtaining tracing results based on the causal relationships in the risk prediction results includes: outputting risk prediction results for each functional area and global risk prediction results based on real-time scheduling events and the risk prediction model; outputting corresponding software information type weights and hardware information type weights based on the risk prediction results for the corresponding functional areas; and obtaining the tracing order and tracing target based on the order of the software information type weights and hardware information type weights.

[0015] Furthermore, it also includes: retrieving the real-time risk status; if there is a difference between the real-time risk status and the risk prediction result, then judging whether there is a time series anomaly based on the comparison of the actual time series relationship and time series correlation; and judging whether there is an action threshold anomaly based on the actual software action situation and action correlation.

[0016] Another technical solution provided in this application is an agent-driven scheduling monitoring risk prediction and tracing system, used to implement the method described above, comprising: a data acquisition unit for collecting software information, hardware information, and scheduling events of the scheduling system; a vertical domain model construction unit for constructing a vertical domain model containing software risk knowledge and hardware risk knowledge based on software and hardware information under historical risk states of the scheduling system; an operation prediction model construction unit for constructing an operation prediction model based on historical software information, historical hardware information, and historical scheduling events of the scheduling system, using temporal correlation and action correlation; a fusion unit for constructing a risk prediction model based on the agent architecture, the operation prediction model, and the vertical domain model; and a prediction and tracing unit for using real-time scheduling events as real-time input to the risk prediction model, and the risk prediction model outputting risk prediction results and tracing results.

[0017] The beneficial effects of this application are as follows: 1. By constructing a vertical domain model, risk information can be extracted in accordance with the scheduling domain during the risk prediction process, making the extracted risk information more accurate. Furthermore, by analyzing the software and hardware operation changes triggered by scheduling events under the same time sequence, the future operation of the software and hardware can be predicted. Combined with the adapted risk information, the future operation of the scheduling system can be accurately predicted. At the same time, by tracing the causes of risk situations based on action correlation, automated scheduling monitoring and risk management can be achieved, improving the efficiency and accuracy of scheduling monitoring and risk response.

[0018] 2. By constructing the runtime sequence relationship corresponding to scheduling events through the response timing of various hardware and software in different scheduling events, and by predicting the software and hardware actions after the occurrence of future scheduling events through the corresponding software and hardware actions, such as whether the number of software processes increases or decreases, or whether there is task migration in the hardware, the prediction of software and hardware actions avoids ignoring the resource scheduling capabilities of software and hardware, which could lead to deviations in the final risk prediction. This enables the risk prediction model to assess the dynamic fault tolerance capability of the scheduling monitoring system, making the prediction results more consistent with the actual operating logic of the scheduling system.

[0019] 3. By first tracing the response sequence and actions of software and hardware to avoid vertical domain model updates caused by non-weight bias, the accuracy of vertical domain model updates is improved, the impact of occasional events on domain knowledge is avoided, and the accuracy and reliability of risk prediction and tracing are further improved. Attached Figure Description

[0020] Figure 1 This is a flowchart illustrating the agent-driven scheduling monitoring risk prediction and tracing method of this application. Detailed Implementation

[0021] To make the objectives, technical solutions, and advantages of this application clearer, the following detailed description of this application is provided in conjunction with the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely one preferred embodiment of this application and are only used to explain this application. They do not limit the scope of protection of this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0022] like Figure 1 As shown in the first embodiment of this application, a method for scheduling monitoring risk prediction and tracing driven by an intelligent agent is described.

[0023] A vertical domain model incorporating software risk knowledge and hardware risk knowledge is constructed based on software and hardware information under historical risk states of the scheduling system.

[0024] An operational prediction model is constructed based on the historical software information, historical hardware information, and historical scheduling events of the scheduling system, taking into account temporal correlation and action correlation.

[0025] Based on the intelligent agent architecture, a risk prediction model is constructed according to the operational prediction model and the vertical domain model.

[0026] Using real-time scheduling events as real-time input to the risk prediction model, the risk prediction model outputs risk prediction results, and the tracing results are obtained based on the causal relationships in the risk prediction results.

[0027] In this embodiment, by constructing a vertical domain model, risk information can be extracted in accordance with the scheduling domain during the risk prediction process, making the extracted risk information more accurate. By analyzing the software and hardware operation changes caused by scheduling events under the same time sequence, the future operation of the software and hardware can be predicted. Combined with the adapted risk information, the future operation of the scheduling system can be accurately predicted. At the same time, the causes of risk situations can be traced based on the correlation of actions, thereby realizing automated scheduling monitoring and risk management, and improving the efficiency and accuracy of scheduling monitoring and risk response.

[0028] Specifically, the construction of vertical domain models that incorporate software risk knowledge and hardware risk knowledge based on software and hardware information under historical risk states of the scheduling system includes:

[0029] The scheduling system is divided into functional areas based on functional type;

[0030] Functional area knowledge is constructed based on software and hardware information under historical risk states corresponding to functional areas.

[0031] Construct full-area knowledge based on the common knowledge in all functional areas;

[0032] A vertical domain model incorporating software risk knowledge and hardware risk knowledge is constructed using functional area knowledge and full-area knowledge.

[0033] A scheduling system may have multiple functional areas, such as a storage area for data storage, a transmission area for instruction transmission, and a computation area for resource allocation. Different functional areas may have different scheduling risk thresholds. For example, the computation area needs to allocate computing resources according to current demands, making CPU operation risks more likely to cause processing anomalies in this area. For each functional area, functional area knowledge is constructed based on its historical risk status software and hardware information. This ensures that each functional area has risk knowledge adapted to its own characteristics, further improving the adaptability of risk knowledge. Simultaneously, common knowledge across all functional areas is used to construct global knowledge, reflecting common risks between functional areas and ensuring comprehensive risk identification. When the risk knowledge of any functional area needs updating, only the corresponding functional area knowledge needs to be updated, without modifying the knowledge of other functional areas or the global knowledge, reducing the computational load during knowledge iteration and improving the update efficiency of the vertical domain model.

[0034] The software information includes at least software log text, and the hardware information includes at least CPU utilization, memory utilization, and hard disk utilization. The functional area knowledge is constructed based on the software and hardware information under historical risk states corresponding to the functional area, including:

[0035] Obtain software and hardware information under historical risk status for each functional area, classify software and hardware information based on risk type, and obtain a risk set;

[0036] Causal analysis and risk level analysis are performed on the elements in the risk set to determine the weights of software information type and hardware information type;

[0037] A risk threshold is constructed based on the risk set, the weight of software information type, and the weight of hardware information type.

[0038] Functional area knowledge is constructed using risk thresholds, software information type weights, and hardware information type weights.

[0039] In this embodiment, software information and hardware information are first categorized according to risk type, ensuring that both software and hardware information in the risk set are information that has historically appeared under the current risk type. Then, software information type weights and hardware information type weights are constructed based on the frequency of each information level in the risk set and the causal relationships between each information type. After weighting according to these weights, a risk threshold for that risk type under historical conditions is obtained. Functional region knowledge is then constructed based on the risk threshold, software information type weights, and hardware information type weights. This functional region knowledge encompasses the causal relationships and degree trends between software and hardware under that risk type in that region, improving the adaptability of the functional region knowledge. It is understood that risk types are constructed based on the different risks that may occur in the scheduling and monitoring system, such as system crashes and traffic peak risks.

[0040] Causal analysis and risk level analysis are performed on the elements in the risk set to determine the weights of software information types and hardware information types, including:

[0041] Construct a risk trend for software information types based on the frequency of occurrence of each risk level in the risk set;

[0042] Construct a hardware information type risk trend based on the frequency of occurrence of each risk level in the risk set for each hardware information type.

[0043] Construct correction relationships based on the causal relationships between software information types, between hardware information types, and between software information types and hardware information types;

[0044] Software information type weights are constructed based on risk trends and correction relationships of software information types.

[0045] Hardware information type weights are constructed based on hardware information type risk trends and correction relationships.

[0046] Risk trends are constructed by varying the frequency of occurrence of different risk levels. For example, the occurrence rate of CPU utilization at 70% is lower than that at 90%, thus the risk weight of CPU utilization at 90% is higher than that of CPU utilization at 70%. This constructs a risk trend in which risk weights change with the risk level of information type, avoiding the limitation that a single fixed weight cannot adapt to dynamic changes in features. In this embodiment, a nonlinear fitting algorithm can be used to construct the trend to express the situation where information type changes at different degrees.

[0047] An initial weight is assigned to the corresponding risk level based on the frequency of occurrence, and then this initial weight is adjusted according to the causal relationship, so that the weight of the information type obtained in the end includes information on the severity of different levels and information on the mutual influence between software and hardware, thereby improving the accuracy of risk prediction.

[0048] For example, in the risk of system crash, the frequency of CPU utilization greater than 90% is 90%, the frequency of CPU utilization greater than 80% is 8%, and the frequency of CPU utilization greater than 70% is 2%. At this time, the risk trend of hardware information type corresponding to CPU utilization is constructed based on the initial weight of CPU utilization greater than 90% as 0.9, the initial weight of CPU utilization greater than 80% as 0.08, and the initial weight of CPU utilization greater than 70% as 0.02.

[0049] Simultaneously, correction relationships are constructed based on the causal relationships between software information types, between hardware information types, and between software and hardware information types. Within software information types, different log texts exhibit corresponding causal relationships; for example, insufficient resources leading to process crashes result in the simultaneous existence of process crash logs and insufficient resource warning logs. Within hardware information types, different hardware components exhibit corresponding causal relationships; for example, process infinite loops leading to CPU exhaustion and CPU overload causing memory release delays result in the simultaneous existence of high CPU utilization and high memory utilization. A causal relationship also exists between software and hardware information types; for example, software memory leaks lead to insufficient hardware memory. Based on the causal relationships between information types, correction relationships for software information types are constructed to obtain the mutual influence relationships between features.

[0050] Specifically, corrected weights are constructed based on the proportion of each causal relationship within the risk set. These corrected weights, along with the initial weights, are used to determine the weights of software information types and hardware information. This reflects the potential interactions between software, hardware, and software / hardware components within the current functional area and risk type. For example, in the current risk, 70% of the logs simultaneously contain process crash logs and resource shortage warning logs, and these logs have a causal relationship. Therefore, the corrected weight for process crash logs is 0.3, and the corrected weight for resource shortage warning logs is 0.7, indicating that process crash logs are a root cause of the risk. It's understandable that corrected weights are only applied when a causal relationship exists between the information types, to avoid incorrectly correcting the weights of information types without a causal relationship. It's also understandable that within software information types, each log is considered a type, and its repetition frequency reflects the severity of the software information type; for example, a process crashing 10 times per second is far more serious than a process crashing once per second.

[0051] Then, based on the weights of software information type and hardware information type, the risk value of each risk state in the risk set is calculated, and the lowest risk value is used as the risk threshold. Thus, when there are changes in software or hardware in this functional area, the risk threshold can also be output based on the dynamically changing weights of software information type and hardware information type, without human intervention, thereby improving the efficiency of risk identification.

[0052] In practice, a single threshold is set for each type of software information and hardware information for each functional area. The single threshold and the risk threshold are used together to conduct risk assessment for the scheduling system monitoring.

[0053] The construction of full-area knowledge based on the common knowledge in all functional areas includes:

[0054] Knowledge of the entire region is constructed based on the similarity of a single threshold in each functional region.

[0055] The thresholds for software and hardware information types corresponding to each functional area may differ. When the threshold for a certain information type is the same across all functional areas, this threshold is considered to be of high importance. That is, once this threshold is exceeded, it may trigger anomalies in most areas. Therefore, the threshold corresponding to this information type is taken as the knowledge of the entire area.

[0056] Thus, a vertical domain model incorporating software risk knowledge and hardware risk knowledge is constructed using functional area knowledge and full-area knowledge. It should be noted that although this embodiment first describes how functional area knowledge and full-area knowledge are constructed, in practical applications, a base model can be selected first, and the construction of functional area knowledge and full-area knowledge can be included as part of model training. That is, during training, the identification of risk trends, correction of relationships, and the similarity of single thresholds can be performed.

[0057] In other embodiments, since constructing functional area knowledge and full area knowledge requires processing a large amount of data, recalculating all data during each update would reduce risk identification efficiency. Therefore, constructing a vertical domain model incorporating software risk knowledge and hardware risk knowledge using functional area knowledge and full area knowledge also includes:

[0058] Construct the first MLP layer corresponding to each functional area, with the number of the first MLP layers corresponding to the number of functional areas;

[0059] Construct a second MLP layer corresponding to the knowledge of the entire region;

[0060] A vertical domain model is built based on the first MLP layer and the second MLP layer.

[0061] Therefore, when new risk states arise, the vertical domain model can be fine-tuned:

[0062] Based on the functional area corresponding to the new risk status, perform fine-tuning of the corresponding first MLP layer.

[0063] The MLP layer is a multilayer perceptron layer. Although fine-tuning of a single layer can reduce the computational cost of model updates, it may weaken the risk correlation between regions. Therefore, another improvement is to replace the process of constructing full-region knowledge based on the same knowledge in all functional regions with constructing full-region knowledge based on the risk transmission probability of all functional regions.

[0064] The construction of full-area knowledge based on the risk transmission probability of all functional areas includes:

[0065] Time-series alignment based on the historical risk status of the same scheduling event execution functional area;

[0066] Construct the risk transmission probability based on the frequency of change in risk status of each functional area;

[0067] Construct full-area knowledge based on the probability of risk transmission.

[0068] In this embodiment, the probability that both functional areas are at risk in the same scheduling event is used. For example, if functional area A experiences a risk in 100 of the same scheduling events, functional area B also experiences a risk in 85 of them. Therefore, functional areas A and B are considered to have an 85% risk transmission probability under the same scheduling event.

[0069] Therefore, when new information arises that needs to be learned, the corresponding MLP layer is invoked to adjust parameters, improving the model update efficiency. Furthermore, cross-regional chain reaction prediction is performed using the MLP layer corresponding to knowledge across the entire region, enhancing the risk correlation between regions.

[0070] Based on historical software information, historical hardware information, and historical scheduling events of the scheduling system, an operational prediction model is constructed based on temporal correlation and action correlation, including:

[0071] Based on the historical software information change sequence and historical hardware information change sequence corresponding to historical scheduling events in the scheduling system, construct the runtime sequence relationship corresponding to the scheduling events;

[0072] Based on the historical software actions and historical hardware actions corresponding to historical scheduling events in the scheduling system, construct the action association relationship corresponding to the scheduling events;

[0073] A runtime prediction model is constructed based on runtime sequence relationships and action association relationships.

[0074] In this embodiment, the runtime sequence relationship corresponding to the scheduling events is constructed by the response timing of various hardware and software in different scheduling events. At the same time, the software and hardware actions corresponding to the scheduling events are used to predict the software and hardware actions after the future scheduling events occur, such as whether the number of software processes increases or decreases, or whether there is task migration in the hardware. By predicting the software and hardware actions, the deviation of the final risk prediction is avoided due to the neglect of the resource scheduling capabilities of software and hardware. Thus, the risk prediction model can evaluate the dynamic fault tolerance capability of the scheduling monitoring system, and the prediction results are more consistent with the actual operating logic of the scheduling system.

[0075] Specifically, constructing runtime sequence relationships corresponding to scheduling events based on the historical software information change sequence and historical hardware information change sequence corresponding to historical scheduling events in the scheduling system includes:

[0076] The timing of changes in software information is taken as the timing of software information changes, and the timing of changes in hardware information is taken as the timing of hardware information changes.

[0077] Using the initial timing sequence of scheduling events as the baseline timing sequence, software and hardware are arranged sequentially according to the order of software information change timing sequence and hardware information change timing sequence to construct the runtime timing relationship between each software and each hardware.

[0078] It is understandable that when the same scheduling event exists in multiple orders at different times, the order influence relationship caused by the difference in information is obtained based on the previous timing information and change information corresponding to the software and hardware with different orders, and this is incorporated into the runtime sequence relationship.

[0079] Based on the historical software and hardware actions corresponding to historical scheduling events in the scheduling system, the action relationships corresponding to scheduling events are constructed, including:

[0080] Based on the scheduling events, obtain information on changes in various software theories and hardware theories;

[0081] Based on the same software action, the threshold of the software action is obtained by considering the changes in software theory and the software information of the previous time sequence of the software action.

[0082] Based on the same hardware action, the hardware action threshold is obtained by combining the theoretical change information of each hardware action with the hardware information of the previous time sequence of the hardware action.

[0083] Action relationships are constructed based on software action thresholds and hardware action thresholds.

[0084] Corresponding to different scheduling events and initial conditions, software and hardware have different response actions. Based on the scheduling event, the theoretical degree of change in software load and hardware load required for that event is calculated. Combined with the actual state before the action is executed, software action thresholds and hardware action thresholds are established respectively. For example, the specific proportion of process addition or reduction, the triggering conditions for service start-up and shutdown, the load threshold for task migration, and the response time of resource switching. This quantifies the response action thresholds of software and hardware to load changes in actual applications, avoiding errors in risk prediction caused by deviations between software and hardware and preset response action thresholds during operation. The action thresholds can be dynamically updated according to software iteration, equipment aging, etc., ensuring that the action correlation always matches the actual operating state of the system and improving the accuracy of risk monitoring in the scheduling system.

[0085] Furthermore, the runtime prediction model constructed based on runtime sequence relationships and action correlation relationships includes:

[0086] Based on historical software and hardware change information for each scheduling event, a runtime prediction model is trained using runtime sequence relationships and action correlations.

[0087] Based on the historical actual changes in software and hardware for each scheduling event, the order influence weights of runtime sequence relationships, the dynamic weights of software action thresholds changing over time, and the dynamic weights of hardware action thresholds changing over time are trained. This enables the prediction of the software and hardware response sequence triggered by scheduling events and the actual information after software and hardware actions.

[0088] Based on the agent architecture, a risk prediction model is constructed using both operational prediction models and vertical domain models, including:

[0089] A risk prediction model is obtained by merging the operational prediction model and the vertical domain model based on the fusion model.

[0090] In this embodiment, the output of the running prediction model is used as the input of the vertical domain model. Based on the prediction results of the actual information after the software and hardware actions output by the running prediction model, the vertical domain model calculates the risk value according to the software information type weight and hardware information type weight of each functional domain. The risk value is compared with the risk threshold to determine whether there is a risk corresponding to the functional domain. Based on the order of software and hardware actions and the risk transmission probability, it is calculated whether there is risk transmission between functional areas, thereby realizing the risk prediction of local functional areas and the risk transmission prediction of the whole area.

[0091] It is understood that the real-time scheduling event in this embodiment can be a scheduling strategy that has been issued but not yet fully executed, thereby enabling the corresponding risk prediction to be performed in advance based on the real-time scheduling event. Alternatively, it can be a scheduling strategy in the queue, enabling the risk prediction of the scheduling strategy in advance, which can prevent actual scheduling system monitoring anomalies and improve maintenance efficiency.

[0092] Specifically, real-time scheduling events are used as real-time input to the risk prediction model. The risk prediction model outputs risk prediction results, and tracing results are obtained based on the causal relationships in the risk prediction results, including:

[0093] Based on real-time scheduling events and risk prediction models, the risk prediction results for each functional area and the global risk prediction results are output.

[0094] Based on the risk prediction results of the corresponding functional areas, output the corresponding software information type weights and hardware information type weights;

[0095] The tracing order and tracing target are obtained by ranking the software information type weight and the hardware information type weight.

[0096] Since the software information type weights and hardware information type weights corresponding to different risk types in the same functional area are not the same, and since the software information type weights and hardware information type weights are constructed in advance according to the causal relationship, the information type weights can show the main and secondary causes of the risk. Thus, the tracing order can be obtained according to the order of the information type weights, and the tracing can be carried out based on the relationship between the main and secondary causes, thereby improving the investigation efficiency of operators.

[0097] Among them, agent-driven scheduling monitoring risk prediction and tracing methods also include:

[0098] Retrieve real-time risk status, and based on the discrepancy between the real-time risk status and the risk prediction results, investigate the causes of software or hardware risks based on temporal correlation and action correlation.

[0099] If the risk prediction result is no risk, but the real-time risk status indicates the presence of software risk, then the actual timing relationship and timing correlation are compared to determine whether there is a timing anomaly that causes the software to receive too much information. At the same time, the actual software action and action correlation are compared to determine whether there is an abnormal action threshold that causes the software to malfunction, thus facilitating the operator to perform software or hardware maintenance.

[0100] In other cases, if none of the above anomalies exist, the weights of the corresponding functional domains are updated according to the current risk status to avoid incorrect weight updates caused by other anomalies, thereby improving the accuracy of the model's risk prediction and tracking.

[0101] As a second embodiment of this application, an agent-driven scheduling monitoring risk prediction and tracing system includes:

[0102] The data acquisition unit is used to collect software information, hardware information, and scheduling events from the scheduling system.

[0103] The vertical domain model building unit is used to build a vertical domain model containing software risk knowledge and hardware risk knowledge based on software and hardware information under the historical risk status of the scheduling system.

[0104] The runtime prediction model building unit is used to build runtime prediction models based on the scheduling system's historical software information, historical hardware information, and historical scheduling events, according to temporal correlation and action correlation.

[0105] The fusion unit is used to build a risk prediction model based on the intelligent agent architecture, the operational prediction model, and the vertical domain model.

[0106] The prediction and tracing unit is used to take real-time scheduling events as real-time input to the risk prediction model, and the risk prediction model outputs risk prediction results and tracing results.

[0107] In this embodiment, the vertical domain model building unit and the operation prediction model building unit are connected to the data acquisition unit, the fusion unit is connected to both the vertical domain model building unit and the operation prediction model building unit, and the prediction and tracing unit is connected to both the data acquisition unit and the fusion unit. The vertical domain model constructs risk knowledge corresponding to different functional domains. The operation prediction model compares risk values ​​with risk thresholds based on the response order and information level between software and hardware in real-time scheduling events. This allows the risk value to change with real-time scheduling events, and the risk threshold to change with different risk types. Through bidirectional dynamic changes, the risk value better reflects the actual scheduling situation, and the risk threshold better matches the actual scenario. Furthermore, by first tracing the response order and actions of software and hardware to avoid updates to the vertical domain model caused by non-weighted biases, the accuracy of vertical domain model updates is improved. This also avoids the impact of occasional events on domain knowledge, further improving the accuracy and reliability of risk prediction and tracing.

[0108] The specific embodiments described above are preferred embodiments of the intelligent agent-driven scheduling monitoring risk prediction and tracing method and system of this application, and are not intended to limit the specific implementation scope of this application. The scope of this application includes but is not limited to the specific embodiments described above. All equivalent changes made in accordance with the shape and structure of this application are within the protection scope of this application.

Claims

1. An agent-driven dispatch monitoring risk prediction and traceability method, characterized in that: comprising the following steps: constructing a vertical domain model containing software risk knowledge and hardware risk knowledge based on software information and hardware information in historical risk states of the dispatch system; constructing a running prediction model based on time sequence correlation and action correlation according to historical software information, historical hardware information and historical dispatch events of the dispatch system; constructing a risk prediction model based on the running prediction model and the vertical domain model according to an agent architecture; taking real-time dispatch events as real-time input of the risk prediction model, outputting a risk prediction result by the risk prediction model, and obtaining a traceability result according to a cause-effect relationship in the risk prediction result; the constructing a vertical domain model containing software risk knowledge and hardware risk knowledge based on software information and hardware information in historical risk states of the dispatch system comprises: dividing functional areas of the dispatch system based on function types; constructing functional area knowledge based on software information and hardware information in historical risk states corresponding to the functional areas; constructing all-area knowledge based on the same knowledge in all functional area knowledge; constructing a vertical domain model containing software risk knowledge and hardware risk knowledge based on the functional area knowledge and the all-area knowledge. 2.The agent-driven dispatch monitoring risk prediction and traceability method of claim 1, wherein: the constructing functional area knowledge based on software information and hardware information in historical risk states corresponding to the functional areas comprises: obtaining software information and hardware information in historical risk states of each functional area, dividing the software information and the hardware information based on risk types, and obtaining a risk set; determining software information type weights and hardware information type weights by performing cause-effect analysis and risk degree analysis on elements in the risk set; constructing a risk threshold according to the risk set, the software information type weights and the hardware information type weights; constructing the functional area knowledge based on the risk threshold, the software information type weights and the hardware information type weights. 3.The agent-driven dispatch monitoring risk prediction and traceability method of claim 2, wherein: the determining software information type weights and hardware information type weights by performing cause-effect analysis and risk degree analysis on elements in the risk set comprises: constructing software information type risk trends according to occurrence frequencies of each risk degree of the software information type in the risk set; constructing hardware information type risk trends according to occurrence frequencies of each risk degree of the hardware information type in the risk set; constructing correction relationships according to cause-effect relationships among the software information types, among the hardware information types, and between the software information types and the hardware information types; constructing the software information type weights based on the software information type risk trends and the correction relationships; constructing the hardware information type weights based on the hardware information type risk trends and the correction relationships. 4.The agent-driven dispatch monitoring risk prediction and traceability method of claim 1, wherein: the constructing a vertical domain model containing software risk knowledge and hardware risk knowledge based on software information and hardware information in historical risk states of the dispatch system comprises: dividing functional areas of the dispatch system based on function types; constructing function area knowledge based on software information and hardware information under historical risk state corresponding to the function area; constructing whole area knowledge based on risk transmission probability of all function areas, wherein the risk transmission probability represents probability that two function areas both exist risk in the same dispatching event; constructing vertical domain model containing software risk knowledge and hardware risk knowledge based on function area knowledge and whole area knowledge. 5.The agent-driven dispatching monitoring risk prediction and tracing method according to claim 1, wherein: the constructing operation prediction model based on time sequence correlation and action correlation according to historical software information, historical hardware information and historical dispatching events in the dispatching system comprises: constructing operation time sequence relationship corresponding to the dispatching event according to historical software information change time sequence and historical hardware information change time sequence corresponding to the historical dispatching event in the dispatching system; constructing action correlation relationship corresponding to the dispatching event based on historical software action and historical hardware action corresponding to the historical dispatching event in the dispatching system; constructing operation prediction model based on operation time sequence relationship and action correlation relationship. 6.The agent-driven dispatching monitoring risk prediction and tracing method according to claim 5, wherein: the constructing action correlation relationship corresponding to the dispatching event based on historical software action and historical hardware action corresponding to the historical dispatching event in the dispatching system comprises: obtaining each software theoretical change information and each hardware theoretical change information according to the dispatching event; obtaining software action threshold value based on each software theoretical change information and software information at previous time sequence of the software action according to the same software action; obtaining hardware action threshold value based on each hardware theoretical change information and hardware information at previous time sequence of the hardware action according to the same hardware action; constructing action correlation relationship based on software action threshold value and hardware action threshold value. 7.The agent-driven dispatching monitoring risk prediction and tracing method according to claim 1, wherein: the taking real-time dispatching event as real-time input of the risk prediction model, the risk prediction model outputting risk prediction result, and obtaining tracing result according to cause-effect relationship in the risk prediction result comprises: outputting risk prediction result of each function area and global risk prediction result based on real-time dispatching event and the risk prediction model; outputting software information type weight and hardware information type weight corresponding to the function area based on risk prediction result of the corresponding function area; obtaining tracing order and tracing target according to size order of the software information type weight and the hardware information type weight.

8. The agent-driven dispatch monitoring risk prediction and retroactivity method of claim 1, wherein: further comprising: calling real-time risk state, if there is difference between the real-time risk state and the risk prediction result, judging whether there is time sequence abnormality according to actual time sequence relationship and time sequence correlation comparison, and judging whether there is action threshold value abnormality according to actual software action and action correlation.

9. An agent-driven dispatch monitoring risk prediction and traceability system for implementing the method of any one of claims 1 to 8, characterized in that: comprising: a data collection unit configured to collect software information, hardware information and dispatching events of the dispatching system; a vertical domain model construction unit configured to construct vertical domain model containing software risk knowledge and hardware risk knowledge based on software information and hardware information under historical risk state of the dispatching system; The operation prediction model construction unit is configured to construct an operation prediction model based on time sequence correlation and action correlation according to historical software information, historical hardware information and historical scheduling events of the scheduling system; The fusion unit is configured to construct a risk prediction model based on the operation prediction model and the vertical field model according to the agent architecture; The prediction and tracing unit is configured to take a real-time scheduling event as a real-time input of the risk prediction model, and the risk prediction model outputs a risk prediction result and a tracing result.

Images