Cross-brand conference terminal fault detection method, device, equipment and medium

Abstract

The application provides a cross-brand conference terminal fault detection method, device, equipment and medium, the method comprises the following steps: obtaining a fault event of a conference terminal and a cross-brand feature set corresponding to the fault event; determining a candidate fault cause according to the fault matching degree of the cross-brand feature set and different fault causes in a preset fault knowledge graph; matching a verification logic chain of the candidate fault cause from a preset fault strategy library; determining a fault confidence of the candidate fault cause according to the cost information of each fault strategy in the cross-brand feature set and the verification logic chain; determining a target fault cause of the fault event according to the fault confidence; and processing the fault event of the conference terminal according to the verification logic chain of the target fault cause. By extracting the cross-brand feature set, the data fragmentation problem caused by brand barriers is eliminated; by calculating the fault confidence through the cross-brand feature set and the cost information, the target fault cause is located, the root cause misjudgment rate is reduced, the fault verification efficiency is improved, and invalid calculation is reduced.

Description

Technical Field

[0001] This application relates to the field of equipment monitoring technology, and in particular to a method, device, equipment and medium for fault detection of cross-brand conference terminals. Background Technology

[0002] With the increasing prevalence of smart conferencing and intelligent office scenarios, more and more enterprises and organizations are communicating through remote meetings. In these remote meetings, participants often use different brands of conferencing terminals. Therefore, enterprises are placing greater emphasis on the unified operation and maintenance management of multiple brands and models of conferencing terminals. They hope to quickly and automatically pinpoint the root cause of complex issues such as audio / video anomalies and connection failures, reduce manual troubleshooting costs, shorten business downtime, and ensure that the fault diagnosis system becomes increasingly accurate with the accumulation of maintenance case studies.

[0003] However, the relevant technical data processing only completed simple structuring, time-series extraction and normalization, without uniformly processing the data differences between different brands of conference terminals, and there are problems such as mismatch between fault detection and actual situation and rigid verification process. Summary of the Invention

[0004] The purpose of this application is to provide a method, apparatus, device, and medium for cross-brand conference terminal fault detection, which can solve the problems of traditional methods failing to uniformly process data differences between conference terminals of different brands, resulting in mismatch between fault detection and actual situation, and rigid verification process.

[0005] In a first aspect, embodiments of this application provide a cross-brand conference terminal fault detection method, applied to an operation and maintenance management platform, wherein the operation and maintenance management platform is communicatively connected to conference terminals of at least one brand; the method includes: Obtain the fault events of the conference terminal and the cross-brand feature set corresponding to the fault events; Candidate fault causes are determined based on the fault matching degree between the cross-brand feature set and different fault causes in the preset fault knowledge graph; The verification logic chain that matches the candidate fault causes from the preset fault strategy library; The fault confidence of the candidate fault cause is determined based on the cross-brand feature set and the cost information of each fault strategy in the verification logic chain; Determine the target cause of the fault event based on the fault confidence level; The fault event of the conference terminal is processed according to the verification logic chain of the target fault cause.

[0006] Optionally, the cross-brand feature set includes at least: cross-brand feature vectors, global timestamps, and data credibility weights; The acquisition of the fault events of the conference terminal and the cross-brand feature set corresponding to the fault events includes: Upon receiving a fault event from the conference terminal, the original conference data from each conference terminal is obtained. By mapping the raw conference data of different brand conference terminals to the same semantic space through a preset mapping function, the cross-brand feature vector of the fault event is obtained. The global timestamp is determined based on the clock drift coefficient of different brand conference terminals; The data credibility weight of the original meeting data is determined based on the data content of the original meeting data and the time delay of the meeting terminal.

[0007] Optionally, determining candidate fault causes based on the fault matching degree between the cross-brand feature set and different fault causes in the preset fault knowledge graph includes: A fault query vector for the fault event is generated based on the cross-brand feature set. Obtain the feature description vectors corresponding to each fault cause in the preset fault knowledge graph; The fault matching degree is determined based on the fault query vector and the feature description vector; The candidate fault cause is determined based on the fault matching degree.

[0008] Optionally, the formula for calculating the fault matching degree is as follows:

[0009] in, The fault events and their causes Fault matching degree between them; Preset weighting coefficients; This is a fault query vector; A feature description vector; A set of historically related paths; The number of paths in the historical associated path set that match the fault event.

[0010] Optionally, determining the fault confidence of the candidate fault cause based on the cross-brand feature set and the cost information of each fault strategy in the verification logic chain includes: The operation priority of each fault strategy in the verification logic chain is determined based on the data credibility weight in the cross-brand feature set and the cost information of each fault strategy in the fault strategy library. When one of the fault strategies is executed according to the operation priority, the verification result of the fault strategy is determined based on the feedback data of the conference terminal, and the fault confidence of the candidate fault cause is calculated based on the verification result and the historical effect weight of the fault strategy, until all fault strategies of the verification logic chain are executed.

[0011] Optionally, the formula for calculating the fault confidence is as follows:

[0012] in, The fault confidence level after executing t+1 fault strategies; This is the preset compression function; The fault confidence level after executing t fault strategies; The set of fault strategies contained in the verification logic chain; Fault strategy Historical effect weighting; Fault strategy The verification results.

[0013] Optionally, determining the target cause of the fault event based on the fault confidence level includes: The candidate fault causes are sorted in descending order according to their fault confidence to obtain a fault cause sequence list; The candidate fault cause that meets the preset conditions in the fault cause sequence list and is verified by each fault strategy in the verification logic chain is selected as the target fault cause.

[0014] Secondly, embodiments of this application provide a cross-brand conference terminal fault detection device, applied to an operation and maintenance management platform, wherein the operation and maintenance management platform is communicatively connected to conference terminals of at least one brand; the device includes: The data acquisition module is used to acquire the fault events of the conference terminal and the cross-brand feature set corresponding to the fault events; The candidate fault cause analysis module is used to determine candidate fault causes based on the fault matching degree between the cross-brand feature set and different fault causes in the preset fault knowledge graph. The verification logic chain matching module is used to match the verification logic chain of the candidate fault cause from the preset fault strategy library; The fault confidence calculation module is used to determine the fault confidence of the candidate fault cause based on the cross-brand feature set and the cost information of each fault strategy in the verification logic chain. The target fault cause determination module is used to determine the target fault cause of the fault event based on the fault confidence level. The fault event handling module is used to process the fault events of the conference terminal according to the verification logic chain of the target fault cause.

[0015] Thirdly, embodiments of this application provide an electronic device, including: a memory, a processor, and a computer program stored in the memory, wherein the processor executes the computer program to implement the method described above.

[0016] Fourthly, embodiments of this application provide a computer-readable storage medium on which a computer program is stored, which, when executed by a processor, implements the method described above.

[0017] Compared with the prior art, the embodiments of this application have the following advantages: In this embodiment, the following steps are taken: First, obtain the fault events of the conference terminal and the corresponding cross-brand feature sets. Second, determine candidate fault causes based on the fault matching degree between the cross-brand feature sets and different fault causes in a preset fault knowledge graph. Third, match the verification logic chain of the candidate fault causes from a preset fault strategy library. Fourth, determine the fault confidence of the candidate fault causes based on the cost information of each fault strategy in the cross-brand feature sets and verification logic chains. Fifth, determine the target fault cause of the fault event based on the fault confidence. Sixth, process the fault events of the conference terminal based on the verification logic chain of the target fault cause. Extracting cross-brand feature sets eliminates the data fragmentation problem caused by brand barriers. Calculating the fault confidence using cross-brand feature sets and cost information to locate the target fault cause reduces the root cause misjudgment rate, improves fault verification efficiency, and reduces invalid calculations. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of this application, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of this application. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0019] Figure 1 This is a flowchart illustrating the steps of a cross-brand conference terminal fault detection method provided in an embodiment of this application; Figure 2 This is a schematic diagram of the structure of a cross-brand conference terminal fault detection device provided in an embodiment of this application; Figure 3 This is a schematic diagram of an electronic device provided in an embodiment of this application; Figure 4 This is a schematic diagram of a computer-readable storage medium provided in an embodiment of this application. Detailed Implementation

[0020] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, not all embodiments. Based on the embodiments 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.

[0021] The terms "first," "second," etc., used in this application are used to distinguish similar objects and not to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of this application can be implemented in orders other than those illustrated or described herein. Furthermore, in this application, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0022] The following description, in conjunction with the accompanying drawings, details a cross-brand conference terminal fault detection method, apparatus, electronic device, and storage medium provided in this application through specific embodiments and application scenarios.

[0023] With the increasing prevalence of smart conferencing and intelligent office scenarios, more and more enterprises and organizations are communicating through remote meetings. In these remote meetings, participants often use different brands of conferencing terminals. Therefore, enterprises are placing greater emphasis on the unified operation and maintenance management of multiple brands and models of conferencing terminals. They hope to quickly and automatically pinpoint the root cause of complex issues such as audio / video anomalies and connection failures, reduce manual troubleshooting costs, shorten business downtime, and ensure that the fault diagnosis system becomes increasingly accurate with the accumulation of maintenance case studies. For example, the prior art patent number CN119271393A discloses a hybrid echo cancellation method and system based on depth filtering and frequency band weighted loss. This technology solves the problems of target speech information loss, poor output speech quality, and excessive model parameters in dual-talk scenarios.

[0024] However, while the related technologies have enabled cross-platform data collection between AI smart devices and accompanying apps, as well as knowledge graph-based fault matching, the overall process still has significant limitations: 1. Data processing only performs simple structuring, time-series extraction and normalization. It does not perform global time-series correction and reliability weighting for clock deviations between devices and apps, data heterogeneity, and log format differences. This can easily introduce noisy data and cause feature distortion. 2. Fault matching relies solely on multi-hop graph traversal and path conformity scores, which can easily lead to mismatches where features are similar but the root causes are different. 3. The verification process uses fixed path rules for hard logic verification, which cannot dynamically adjust the verification structure according to the actual fault sequence and historical path, nor does it support the priority ranking of verification steps and the progressive update of confidence based on information gain. This results in a rigid verification process, a large amount of redundant computation, and an inability to converge in advance.

[0025] In summary, existing technologies do not address the data differences between different brands of conference terminals in a unified manner, resulting in issues such as mismatch between fault detection and actual conditions, and rigid verification processes.

[0026] Reference Figure 1 The diagram illustrates a flowchart of a cross-brand conference terminal fault detection method provided in this application embodiment, which may specifically include the following steps: Step 101: Obtain the fault events of the conference terminal and the cross-brand feature set corresponding to the fault events; In this embodiment, the cross-brand conference terminal fault detection method is applied to the operation and maintenance management platform. The operation and maintenance management platform is connected to the conference terminals of at least one brand, that is, there are conference terminals of different brands in the operation and maintenance management platform.

[0027] Specifically, after receiving fault events reported by various conference terminals, the operation and maintenance management platform performs unified feature mapping, global time correction, and data credibility weighting on the raw conference data from conference terminals of different brands to generate a cross-brand feature set. This set can then connect downwards to conference terminals, network devices, and application services of various brands to achieve concurrent collection of fault data, and provide standardized input upwards for subsequent fault matching, adapting to complex conference system fault scenarios involving multiple devices and multiple links.

[0028] Step 102: Determine candidate fault causes based on the fault matching degree between the cross-brand feature set and different fault causes in the preset fault knowledge graph; In this embodiment, a fault knowledge graph and a fault strategy library are pre-set based on historical data of faults in each conference terminal. The fault knowledge graph contains various fault causes and corresponding fault features. By comparing each feature in the cross-brand feature set with the fault features corresponding to the fault causes, the fault matching degree between the cross-brand feature set and the fault features corresponding to different fault causes is calculated to screen candidate fault causes and perform preliminary tracing of fault causes.

[0029] Step 103: Match the verification logic chain of the candidate fault cause from the preset fault strategy library; In this embodiment, the fault policy library includes various fault causes and corresponding verification logic chains. Each verification logic chain contains a series of fault policies for resolving the corresponding fault cause. In other words, a verification logic chain contains various operations for resolving the corresponding fault cause.

[0030] Specifically, after selecting candidate fault causes, the verification logic chain corresponding to each candidate fault cause is matched in the preset fault strategy library to provide verification content for subsequent fault verification.

[0031] Step 104: Determine the fault confidence of the candidate fault cause based on the cross-brand feature set and the cost information of each fault strategy in the verification logic chain; In this embodiment, the operation priority of the verification logic chain corresponding to different candidate fault causes is calculated based on the cost information of each fault strategy in the verification logic chain and each feature in the cross-brand feature set. Then, based on the operation priority, each verification logic chain is verified in sequence, and the fault confidence of each candidate fault cause is calculated.

[0032] Specifically, existing technologies typically employ fixed path rules for hard logic verification during the fault verification phase, making it impossible to dynamically adjust the verification structure based on the actual fault timing and historical paths. The fault verification phase in this application is not a one-time verification but a dynamic convergence process. That is, each time a fault strategy in a verification logic chain is executed, the fault confidence of the candidate fault cause is updated, and a decision is made accordingly to continue verification or terminate early.

[0033] Step 105: Determine the target fault cause of the fault event based on the fault confidence level; After performing fault verification on each verification logic chain, the fault confidence of each candidate fault cause can be determined. Based on this, the fault cause with the highest fault confidence can be selected as the target fault cause of the current fault event, thus completing the fault tracing of cross-brand conference terminals.

[0034] Step 106: Process the fault event of the conference terminal according to the verification logic chain of the target fault cause.

[0035] After locating the cause of the target failure, the operation and maintenance management platform executes the failure strategy contained in the verification logic chain corresponding to the cause of the target failure to resolve the failure event of the conference terminal.

[0036] In this embodiment, the following steps are taken: First, obtain the fault events of the conference terminal and the corresponding cross-brand feature sets. Second, determine candidate fault causes based on the fault matching degree between the cross-brand feature sets and different fault causes in a preset fault knowledge graph. Third, match the verification logic chain of the candidate fault causes from a preset fault strategy library. Fourth, determine the fault confidence of the candidate fault causes based on the cost information of each fault strategy in the cross-brand feature sets and verification logic chains. Fifth, determine the target fault cause of the fault event based on the fault confidence. Sixth, process the fault events of the conference terminal based on the verification logic chain of the target fault cause. Extracting cross-brand feature sets eliminates the data fragmentation problem caused by brand barriers. Calculating the fault confidence using cross-brand feature sets and cost information to locate the target fault cause reduces the root cause misjudgment rate, improves fault verification efficiency, and reduces invalid calculations.

[0037] In one embodiment of this application, the cross-brand feature set includes at least: a cross-brand feature vector, a global timestamp, and a data credibility weight; The acquisition of the fault events of the conference terminal and the cross-brand feature set corresponding to the fault events includes: Upon receiving a fault event from the conference terminal, the original conference data from each conference terminal is obtained. By mapping the raw conference data of different brand conference terminals to the same semantic space through a preset mapping function, the cross-brand feature vector of the fault event is obtained. The global timestamp is determined based on the clock drift coefficient of different brand conference terminals; The data credibility weight of the original meeting data is determined based on the data content of the original meeting data and the time delay of the meeting terminal.

[0038] In this embodiment of the application, the raw conference data of each conference terminal can be represented as: ; in, This indicates the data source identifier, corresponding to the various brands of conference terminals; This is the original timestamp; This is the original indicator vector, such as CPU, packet loss rate, bit rate, and other feature indicators; The protocol or format tags adopted by each brand of conference terminals are used for subsequent standardized mapping; based on this, a cross-brand unified feature mapping function is predefined to transform the raw conference data from each brand's conference terminals into a unified feature space:

[0039] in, For cross-brand feature vectors; A mapping function for unified characteristics across brands; This is the original index vector; Protocol or format labels used for conference terminals of various brands; In response to the agreement A predefined or learned mapping matrix; In response to the agreement Predefined or learned bias terms; By mapping different brands of devices to the same semantic space, it is possible to ensure that metrics such as "network jitter" and "audio latency" have consistent numerical meanings across different devices. After achieving semantic unification, the issue of time misalignment needs to be addressed. Since different brands of conference terminals have varying clock drift and sampling frequencies, the operation and maintenance management platform pre-sets a global event time correction function based on the device information of each connected brand of conference terminal. This global event time correction function aligns all data to the same fault timeline, ensuring the accuracy of causal relationship analysis. The formula for calculating the global timestamp is as follows:

[0040] in, This is the corrected global timestamp; The original timestamp before correction; This is a global event timing correction function; Data source identifier The corresponding clock drift coefficient of the conference terminal; This serves as a reference time point for the triggering of the fault event. Data source identifier The corresponding conference terminal's fixed delay correction, such as network transmission or buffering delay, can be unified to the same time base through this mechanism, thus correcting the originally biased data.

[0041] After achieving semantic and temporal consistency, it is also necessary to address the issue of inconsistent data quality. For example, missing logs from some conference terminals or network jitter can cause abnormal fluctuations in metrics. Therefore, a data credibility weighting metric is introduced to assign weights to each piece of original conference data to form a final standardized fault data set. The purpose is to reduce the interference of noisy data on subsequent inference. The formula for calculating the data credibility weight is as follows:

[0042] in, For raw meeting data Data credibility weight; Score the data integrity. Scoring for data consistency, such as original meeting data. The degree of deviation from historical statistical distribution; For the time delay of the conference terminal; Adjustment parameters for data integrity scoring; Adjustment parameters for data consistency scoring; This is an adjustment parameter for the time delay. , and It can be set according to experimental data.

[0043] The multidimensional quality indicators are integrated into a unified weight value in the range [0,1] by using the calculation formula of data credibility weight. The higher the data integrity score and data consistency score, the closer they are to 1, while the greater the delay, the lower the weight.

[0044] By unifying the feature extraction of conference terminals from different brands, the data fragmentation problem caused by brand barriers is eliminated; based on the fault matching degree of cross-brand feature sets, candidate fault causes are screened from the preset fault knowledge graph to reduce the root cause misjudgment rate; and by combining cost information to calculate fault confidence, the efficiency of fault verification is greatly improved and invalid calculations are reduced.

[0045] This embodiment constructs a cross-brand feature set based on cross-brand feature vectors, global timestamps, and data credibility weights. In subsequent processing, high-quality data will dominate the analysis results, while low-quality or abnormal data will be suppressed. Finally, a standardized cross-brand feature set with time alignment and controllable quality is constructed. This cross-brand feature set is not only structurally unified, but also corrected in terms of time and credibility dimensions, providing high-quality input for subsequent candidate fault cause matching and significantly improving the compatibility and universality of cross-brand operation and maintenance.

[0046] In one embodiment of this application, determining candidate fault causes based on the fault matching degree between the cross-brand feature set and different fault causes in a preset fault knowledge graph includes: A fault query vector for the fault event is generated based on the cross-brand feature set. Obtain the feature description vectors corresponding to each fault cause in the preset fault knowledge graph; The fault matching degree is determined based on the fault query vector and the feature description vector; The candidate fault cause is determined based on the fault matching degree.

[0047] In this embodiment, the cross-brand feature set includes at least: 1) Standardized unified feature vector , used to express the objective characteristics of faults in different dimensions; 2) Corrected global timestamp Used to recover the temporal relationship of fault evolution; 3) Data credibility weight It is used to distinguish high-quality evidence from noisy data during the matching process; The above data together constitute the basic data for querying and inferring candidate fault causes. In specific implementation, this embodiment first aggregates all data points under the same fault event using time windows to form a weighted time series feature set. The weighted time series feature set is then mapped to a composite query vector that can be queried by the knowledge graph. This compresses the discrete multi-source data into a structured fault query vector that can represent the overall state of the current fault. The fault query vector can be determined by the following formula:

[0048] in, This is a fault query vector; For raw meeting data Data credibility weight; To unify the feature vectors; The preset time decay coefficient; The maximum timestamp within the current window; This is the corrected global timestamp.

[0049] In the fault query vector, data that is closer to the maximum timestamp within the current window, as well as data with higher data credibility weight, contribute more to the final query vector. This makes the query results closer to the current actual fault state and avoids misleading matching results from early or low-quality data.

[0050] After obtaining the fault query vector, multi-hop traversal matching is performed in the preset fault knowledge graph. Each potential root cause node (i.e., fault cause) in the graph is associated with a feature description vector and a set of contextual relationship paths. Candidate fault causes are filtered by calculating the fault matching degree between the fault query vector and the feature description vector. At the same time, the graph structure relationship is combined for expansion, thereby avoiding the omission of topological information by simply using vector similarity. The feature description vector is generated by the fault knowledge graph based on standardized data of historical fault cases through statistics and aggregation. In this embodiment, the formula for calculating the fault matching degree is as follows:

[0051] in, The fault events and their causes Fault matching degree between them; Preset weighting coefficients; This is a fault query vector; A feature description vector; A set of historically related paths; The number of paths in the historical associated path set that match the fault event.

[0052] Specifically Cosine similarity is used to measure the degree of similarity between the current fault query vector and the feature description vector corresponding to the fault cause. The path matching rate represents the set of historical associated paths of the cause of the fault in the fault knowledge graph, such as different historical associated paths such as "network jitter - audio stuttering - increased packet loss rate"; This indicates the number of paths that are satisfied or partially satisfied in the current fault data. Its purpose is to measure whether the current fault conforms to the typical path evolution pattern of the fault cause. For example, the historical correlation path "network jitter - audio stuttering - increased packet loss rate" contains three path nodes. This indicates the number of path nodes that satisfy the criteria of "network jitter - audio stuttering - increased packet loss rate".

[0053] In actual execution, the first round of vector recall is performed to obtain the fault matching degree of each fault cause. The fault matching degree is sorted in descending order to select the Top-K candidate fault causes. For these fault causes, the causal links in the fault knowledge graph are traced down layer by layer to fully unfold the complete fault transmission chain, calculate and sort them to generate a set of candidate fault causes.

[0054] This embodiment performs multi-hop traversal matching in the fault knowledge graph based on fault query vectors, and combines feature similarity and historical correlation path matching rate for comprehensive scoring. This avoids misjudgment caused by relying solely on vector similarity and ignoring the fault evolution topology, and can accurately filter out the fault cause that best matches the actual fault propagation pattern from multiple fault causes. Compared with traditional single-dimensional analysis methods, it can effectively reduce the root cause misjudgment rate, and is especially suitable for complex conference system fault scenarios involving multiple devices and multiple links.

[0055] In one embodiment of this application, determining the fault confidence of the candidate fault cause based on the cross-brand feature set and the cost information of each fault strategy in the verification logic chain includes: The operation priority of each fault strategy in the verification logic chain is determined based on the data credibility weight in the cross-brand feature set and the cost information of each fault strategy in the fault strategy library. When one of the fault strategies is executed according to the operation priority, the verification result of the fault strategy is determined based on the feedback data of the conference terminal, and the fault confidence of the candidate fault cause is calculated based on the verification result and the historical effect weight of the fault strategy, until all fault strategies of the verification logic chain are executed.

[0056] In this embodiment, each candidate fault cause corresponds to a verification graph. ,in, It is a set of atomic operations (i.e., fault policies) selected from the fault policy library based on candidate fault causes; To verify the dependencies between atomic operations; Specifically, this embodiment introduces an information gain-driven verification priority calculation model to adaptively determine the execution order of each verification operation, thereby eliminating redundant verification processes, reducing ineffective computational overhead, and achieving rapid convergence of the root cause verification process. For example, when locating audio stuttering faults in a conference terminal, faced with multiple atomic operations such as network packet loss detection, device CPU usage detection, audio encoding format detection, and port status detection, it can automatically determine that network packet loss detection has the highest information gain and the lowest execution cost in distinguishing between "network anomaly" and "device performance anomaly," and therefore prioritizes this detection. If the result of this operation can significantly improve the confidence of the current candidate root cause, then the next-highest priority operation continues to be executed. If it is sufficient to exclude or confirm the root cause, then the subsequent verification process is terminated in advance, realizing dynamic scheduling and on-demand tailoring of the verification logic. The formula for calculating operation priority based on the information gain-driven verification priority calculation model is as follows:

[0057] in, In order to identify candidate fault causes Perform atomic operations (fault strategy) Operation priority; To assess the overall reliability of the data relied upon for this operation, it can be set to the original meeting data. Corresponding data credibility weight , that is, ; For this atomic operation Information gain for distinguishing the current candidate cause of failure from other candidate causes of failure; For this atomic operation The execution cost can be obtained by matching the cost information of each atomic operation in the fault policy library; The preset adjustment factor for execution cost can be adjusted according to the accuracy of fault tracing.

[0058] By calculating the operational priority of each fault strategy, the verification process is transformed from a full traversal to an optimal path search.

[0059] Furthermore, in this embodiment, the verification process cannot be completed in one go, but rather is a dynamic convergence process. Based on the operation priority, the confidence level of the candidate fault cause is updated for each fault policy executed in the verification logic chain. The formula for calculating the fault confidence level is as follows:

[0060] in, The fault confidence level after executing t+1 fault policies; This is the preset compression function; The fault confidence level after executing t fault policies; To verify the set of fault policies contained in the logic chain; Fault strategy The historical effect weights are obtained from historical success rates or knowledge graph statistics. Fault strategy The verification results.

[0061] In practical implementation, fault strategy The verification results can be used to implement the failure strategy. The feedback data from the conference terminal obtained after prediction determines whether a fault policy should be implemented. If a fault event in the conference terminal can be mitigated, then the fault strategy is considered to be effective. The verification result passed, and settings can be configured. If the failure events of the conference terminal cannot be improved, then the failure strategy is considered to be ineffective. The verification result passed, and settings can be configured. ; By updating the fault confidence of candidate fault causes in real time, discrete verification results are transformed into continuous confidence. Decisions can be made midway through the verification process. For example, if the current candidate fault cause being verified is significantly higher than other candidate fault causes, the verification can be terminated in advance. Alternatively, if the current fault confidence continues to decline, the verification of the candidate fault cause can be abandoned, thereby improving the efficiency of fault tracing. Optionally, in this embodiment, the verification priority calculation model and fault confidence update mechanism based on information gain are deployed in the operation and maintenance management platform as lightweight computing components. The computing context is provided based on standardized fault data and candidate fault cause set, and the operation priority and fault confidence are calculated in real time without the need for independent hardware deployment. The calculation process calls the data confidence weight, candidate faults and verification logic chain. The intermediate results are temporarily stored in the time series database and cache middleware. After the calculation is completed, the priority sequence, fault confidence update record and verification convergence result are persistently stored to support the generation of dynamic verification logic chain and root cause determination.

[0062] This embodiment employs an information gain-driven verification priority function and a fault confidence update mechanism, which can significantly improve fault verification efficiency and reduce invalid computation. Instead of using a fixed-order or full-scale verification approach, it dynamically sorts and prunes verification steps based on data credibility, information gain, and execution cost, prioritizing high-discrimination, low-cost operations. Furthermore, by updating fault confidence, it achieves early convergence or quickly abandons low-probability fault causes, significantly shortening fault location time and improving operational response speed and overall processing efficiency.

[0063] In one embodiment of this application, determining the target fault cause of the fault event based on the fault confidence level includes: The candidate fault causes are sorted in descending order according to their fault confidence to obtain a fault cause sequence list; The candidate fault cause that meets the preset conditions in the fault cause sequence list and is verified by each fault strategy in the verification logic chain is selected as the target fault cause.

[0064] In this embodiment, the preset condition can be set to the highest fault confidence and all fault strategies have been verified.

[0065] Specifically, after comprehensively comparing the dynamic verification results and fault confidence of all candidate fault causes, the candidate fault causes can be sorted in descending order according to their fault confidence to obtain a fault cause sequence list. From the fault cause sequence list, the fault cause that has passed verification and has the highest fault confidence, and whose verification logic chain has been verified by all fault strategies, is selected as the final target fault cause. The verification logic chain associated with the target fault cause is then used as the final target solution. Combined with the specific brand, model, and configuration parameters of the current fault conferencing terminal, an operable and precise repair solution instruction or guidance suggestion is generated and pushed to the administrator through the operation and maintenance management platform or executed automatically.

[0066] Specifically, if a company deploys 12 conference terminals from 3 brands (6 terminals from brand A, 4 terminals from brand B, and 2 terminals from brand C), and connects them to network and application devices such as access switches, MCU servers, and SIP servers, the operation and maintenance management platform will immediately initiate the S1-S5 full-process handling when it detects a combined fault event where terminal A experiences audio stuttering and terminal B experiences screen distortion, or when a user actively reports the fault. S1: Concurrently collects data from 12 cross-brand conference terminals, 2 access switches, and 1 MCU server, transforming the raw conference data from each device into a cross-brand feature set. ; in, These are labeled as follows: Brand A - Terminals 01~06; Brand B - Terminals 01~04; Brand C - Terminals 01~02; Switch - 01 / 02, MCU - 01; The original timestamps collected by each device; This is the original metric vector, which includes metrics such as CPU utilization, network packet loss rate, audio and video bitrate, network jitter, and latency. The protocol or format labels used for each brand's conference terminals, corresponding to each brand's proprietary protocol and standard RTP / RTCP protocol labels.

[0067] By using a unified feature mapping function, the "network jitter" and "audio latency" indicators of different brands are transformed into a unified feature space. The global event time correction function is used to align the data of each device with different clock drifts to the same fault time axis. Then, by calculating the data credibility weight, a weight value between 0 and 1 is calculated for each data point, and finally a standardized cross-brand feature set with time alignment and controllable quality is formed. Optionally, raw meeting data with a credibility weight below a preset weight threshold can be discarded to improve the verification efficiency of fault tracing.

[0068] S2: Aggregate standardized cross-brand feature sets within a time window, integrate data credibility and time decay factors to generate fault query vectors, and calculate the fault matching degree between the fault query vectors and each root cause node in the fault knowledge graph to filter candidate root cause faults; for example: select candidate root cause 1 - core switch port congestion, select candidate root cause 2 - MCU server encoding module abnormality, select candidate root cause 3 - terminal local hardware failure; S3: Dynamically generate a verification diagram for each candidate fault cause; generate verification logic chains one by one based on the atomic operations selected from the fault strategy library according to the candidate fault causes corresponding to brand A and brand B; and perform fault verification according to the operation priority of each atomic operation in the verification logic chain. For example, for a fault event of audio stuttering on Brand A terminal, the verification priority function driven by information gain prioritizes the execution of network detection, switch port congestion detection, and MCU audio stream status detection for Brand A terminal; for a screen flickering issue on Brand B terminal, the video decoding status detection, bitrate adaptation detection, and link packet loss detection for Brand B terminal are prioritized.

[0069] Subsequently, the serial / parallel verification structure is dynamically arranged according to the brand and fault type of the conference terminal, and the fault confidence of the candidate fault causes is calculated in real time through the fault confidence update mechanism. When the candidate fault cause "core switch port congestion" obtains the highest fault confidence in both brand A and brand B terminals and is significantly higher than other candidate fault causes, convergence is performed in advance and the verification of subsequent faults is stopped.

[0070] S4: Completely record the verification logic chain, execution order, and convergence results for Brand A and Brand B terminals. Abstract the effective path of "switch port congestion - abnormal network indicators across brands - audio stuttering in Brand A, video flickering in Brand B" into a general rule, incrementally update it to the fault knowledge graph, and supplement the fault propagation path for corresponding Brand A and Brand B devices. If subsequent verification failures occur for Brand C terminals, record the failure mode, optimize the operation priority and adjustment parameters in the verification logic chain for different brand terminals, and improve the accuracy of subsequent cross-brand fault verification. S5: Confirm that core switch port congestion is the target cause of the failure of Brand A and Brand B conference terminals. Based on the brand, model, deployment location, and network configuration of the faulty terminals, generate differentiated repair instructions adapted to different brands: issue a bandwidth priority upgrade instruction to Brand A terminals and a dynamic bitrate reduction adaptation instruction to Brand B terminals. At the same time, perform port rate limiting and abnormal traffic cleanup on the switch. The repair instructions are automatically issued and executed through the operation and maintenance platform to quickly restore the conference services of Brand A and Brand B terminals.

[0071] This application embodiment obtains fault events of the conference terminal and corresponding cross-brand feature sets; determines candidate fault causes based on the fault matching degree between the cross-brand feature sets and different fault causes in a preset fault knowledge graph; matches the verification logic chain of candidate fault causes from a preset fault strategy library; determines the fault confidence of candidate fault causes based on the cost information of each fault strategy in the cross-brand feature sets and verification logic chains; determines the target fault cause of the fault event based on the fault confidence; and processes the fault events of the conference terminal based on the verification logic chain of the target fault cause. By extracting cross-brand feature sets, the data fragmentation problem caused by brand barriers is eliminated; by calculating the fault confidence using cross-brand feature sets and cost information, the target fault cause is located, reducing the root cause misjudgment rate, improving fault verification efficiency, and reducing invalid calculations.

[0072] It should be noted that, for the sake of simplicity, the method embodiments are all described as a series of actions. However, those skilled in the art should understand that the embodiments of this application are not limited to the described order of actions, because according to the embodiments of this application, some steps can be performed in other orders or simultaneously. Secondly, those skilled in the art should also understand that the embodiments described in the specification are all preferred embodiments, and the actions involved are not necessarily required by the embodiments of this application.

[0073] Reference Figure 2 The diagram shows a structural schematic of a cross-brand conference terminal fault detection device provided in an embodiment of this application, which may specifically include the following modules: Data acquisition module 201 is used to acquire the fault events of the conference terminal and the cross-brand feature set corresponding to the fault events; The candidate fault cause analysis module 202 is used to determine the candidate fault cause based on the fault matching degree between the cross-brand feature set and different fault causes in the preset fault knowledge graph. The verification logic chain matching module 203 is used to match the verification logic chain of the candidate fault cause from the preset fault strategy library; The fault confidence calculation module 204 is used to determine the fault confidence of the candidate fault cause based on the cross-brand feature set and the cost information of each fault strategy in the verification logic chain. The target fault cause determination module 205 is used to determine the target fault cause of the fault event based on the fault confidence level. The fault event handling module 206 is used to process the fault event of the conference terminal according to the verification logic chain of the target fault cause.

[0074] In one embodiment of this application, the cross-brand feature set includes at least: a cross-brand feature vector, a global timestamp, and a data credibility weight; the data acquisition module 201 includes: The raw meeting data acquisition submodule is used to acquire the raw meeting data of each meeting terminal when a fault event is received from the meeting terminal. The cross-brand feature vector generation submodule is used to map the original conference data of different brand conference terminals to the same semantic space through a preset mapping function to obtain the cross-brand feature vector of the fault event. The global timestamp generation submodule is used to determine the global timestamp based on the clock drift coefficient of different brands of conference terminals; The data credibility weight generation submodule is used to determine the data credibility weight of the original meeting data based on the data content of the original meeting data and the time delay of the meeting terminal.

[0075] In one embodiment of this application, the candidate fault cause analysis module 202 includes: The fault query vector generation submodule is used to generate a fault query vector for the fault event based on the cross-brand feature set. The feature description vector matching submodule is used to obtain the feature description vectors corresponding to each fault cause in the preset fault knowledge graph; The fault matching degree calculation submodule is used to determine the fault matching degree based on the fault query vector and the feature description vector; The candidate fault cause selection submodule is used to determine the candidate fault cause based on the fault matching degree.

[0076] In one embodiment of this application, the formula for calculating the fault matching degree is as follows:

[0077] in, The fault events and their causes Fault matching degree between them; Preset weighting coefficients; This is a fault query vector; A feature description vector; A set of historically related paths; The number of paths in the historical associated path set that match the fault event.

[0078] In one embodiment of this application, the fault confidence calculation module 204 includes: The operation priority calculation submodule is used to determine the operation priority of each fault strategy in the verification logic chain based on the data credibility weight in the cross-brand feature set and the cost information of each fault strategy in the fault strategy library. The fault verification submodule is used to determine the verification result of the fault strategy based on the feedback data of the conference terminal when one of the fault strategies is executed according to the operation priority, and to calculate the fault confidence of the candidate fault cause based on the verification result and the historical effect weight of the fault strategy, until all fault strategies of the verification logic chain are executed.

[0079] In one embodiment of this application, the formula for calculating the fault confidence level is as follows:

[0080] in, The fault confidence level after executing t+1 fault strategies; This is the preset compression function; The fault confidence level after executing t fault strategies; The set of fault strategies contained in the verification logic chain; Fault strategy Historical effect weighting; Fault strategy The verification results.

[0081] In one embodiment of this application, the target fault cause determination module 205 includes: The fault cause sequence list generation submodule is used to sort the candidate fault causes in descending order according to the fault confidence of each candidate fault cause to obtain the fault cause sequence list; The target fault cause determination module is used to select candidate fault causes that meet preset conditions in the fault cause sequence list and are verified by each fault strategy in the verification logic chain as target fault causes.

[0082] As the apparatus embodiment is basically similar to the method embodiment, it is described in a relatively simple manner. For relevant details, please refer to the description of the method embodiment.

[0083] like Figure 3 As shown, in another embodiment provided in this application, an electronic device 500 is also provided, including a memory 510 and a processor 520. The memory 510 and the processor 520 are connected via a bus for communication. The memory 510 stores a computer program, which can run on the processor 520 to implement the above steps.

[0084] like Figure 4 As shown, in another embodiment provided in this application, a computer-readable storage medium 601 is also provided, which stores a computer program that implements the methods described in the above embodiments when executed by a processor.

[0085] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0086] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0087] Those skilled in the art will understand that embodiments of this application can be provided as methods, apparatus, or computer program products. Therefore, embodiments of this application can take the form of entirely hardware embodiments, entirely software embodiments, or embodiments combining software and hardware aspects. Furthermore, embodiments of this application can take the form of computer program products implemented on one or more computer-usable storage media (including but not limited to disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0088] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, terminal devices (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing terminal device to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing terminal device, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0089] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing terminal device to operate in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0090] These computer program instructions can also be loaded onto a computer or other programmable data processing terminal equipment, causing a series of operational steps to be performed on the computer or other programmable terminal equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable terminal equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0091] Although preferred embodiments of the present application have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present application.

[0092] It should also be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0093] The present invention provides a detailed description of a cross-brand conference terminal fault detection method. Specific examples have been used to illustrate the principle and implementation of the present invention. The description of the above embodiments is only for the purpose of helping to understand the method and core idea of ​​the present invention. At the same time, for those skilled in the art, there will be changes in the specific implementation and application scope based on the idea of ​​the present invention. Therefore, the content of this specification should not be construed as a limitation of the present invention.

Claims

1. A method for fault detection in cross-brand conference terminals, characterized in that, The method is applied to an operation and maintenance management platform, which communicates with at least one brand of conference terminal; the method includes: Obtain the fault events of the conference terminal and the cross-brand feature set corresponding to the fault events; Candidate fault causes are determined based on the fault matching degree between the cross-brand feature set and different fault causes in the preset fault knowledge graph; The verification logic chain that matches the candidate fault causes from the preset fault strategy library; The fault confidence of the candidate fault cause is determined based on the cross-brand feature set and the cost information of each fault strategy in the verification logic chain; Determine the target cause of the fault event based on the fault confidence level; The fault event of the conference terminal is processed according to the verification logic chain of the target fault cause.

2. The method according to claim 1, characterized in that, The cross-brand feature set includes at least: cross-brand feature vectors, global timestamps, and data credibility weights; The acquisition of the fault events of the conference terminal and the cross-brand feature set corresponding to the fault events includes: Upon receiving a fault event from the conference terminal, the original conference data from each conference terminal is obtained. By mapping the raw conference data of different brand conference terminals to the same semantic space through a preset mapping function, the cross-brand feature vector of the fault event is obtained. The global timestamp is determined based on the clock drift coefficient of different brand conference terminals; The data credibility weight of the original meeting data is determined based on the data content of the original meeting data and the time delay of the meeting terminal.

3. The method according to claim 1, characterized in that, The step of determining candidate fault causes based on the fault matching degree between the cross-brand feature set and different fault causes in the preset fault knowledge graph includes: A fault query vector for the fault event is generated based on the cross-brand feature set. Obtain the feature description vectors corresponding to each fault cause in the preset fault knowledge graph; The fault matching degree is determined based on the fault query vector and the feature description vector; The candidate fault cause is determined based on the fault matching degree.

4. The method according to claim 3, characterized in that, The formula for calculating the fault matching degree is as follows: in, The fault events and their causes Fault matching degree between them; Preset weighting coefficients; This is a fault query vector; A feature description vector; A set of historically related paths; The number of paths in the historical associated path set that match the fault event.

5. The method according to claim 1, characterized in that, The step of determining the fault confidence of the candidate fault cause based on the cross-brand feature set and the cost information of each fault strategy in the verification logic chain includes: The operation priority of each fault strategy in the verification logic chain is determined based on the data credibility weight in the cross-brand feature set and the cost information of each fault strategy in the fault strategy library. When one of the fault strategies is executed according to the operation priority, the verification result of the fault strategy is determined based on the feedback data of the conference terminal, and the fault confidence of the candidate fault cause is calculated based on the verification result and the historical effect weight of the fault strategy, until all fault strategies of the verification logic chain are executed.

6. The method according to claim 5, characterized in that, The formula for calculating the fault confidence level is as follows: in, The fault confidence level after executing t+1 fault strategies; This is the preset compression function; The fault confidence level after executing t fault strategies; The set of fault strategies contained in the verification logic chain; Fault strategy Historical effect weighting; Fault strategy The verification results.

7. The method according to claim 1, characterized in that, Determining the target fault cause of the fault event based on the fault confidence level includes: The candidate fault causes are sorted in descending order according to their fault confidence to obtain a fault cause sequence list; The candidate fault cause that meets the preset conditions in the fault cause sequence list and is verified by each fault strategy in the verification logic chain is selected as the target fault cause.

8. A cross-brand conference terminal fault detection device, characterized in that, An application in an operation and maintenance management platform, wherein the operation and maintenance management platform is communicatively connected to at least one brand of conference terminal; the device includes: The data acquisition module is used to acquire the fault events of the conference terminal and the cross-brand feature set corresponding to the fault events; The candidate fault cause analysis module is used to determine candidate fault causes based on the fault matching degree between the cross-brand feature set and different fault causes in the preset fault knowledge graph. The verification logic chain matching module is used to match the verification logic chain of the candidate fault cause from the preset fault strategy library; The fault confidence calculation module is used to determine the fault confidence of the candidate fault cause based on the cross-brand feature set and the cost information of each fault strategy in the verification logic chain. The target fault cause determination module is used to determine the target fault cause of the fault event based on the fault confidence level. The fault event handling module is used to process the fault events of the conference terminal according to the verification logic chain of the target fault cause.

9. An electronic device, characterized in that, include: A memory, a processor, and a computer program stored on the memory, wherein the processor executes the computer program to implement the method of any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the method as described in any one of claims 1-7.

Images