Heterogeneous computing state data acquisition method, system and device for cloud edge end collaboration

Abstract

The application provides a heterogeneous computing power state data acquisition method, system and device facing cloud edge end cooperation. The method is executed in a terminal device or an edge node in a cloud edge end cooperation architecture system, and includes: obtaining original running state data of a target heterogeneous computing power device; performing standardized processing on the original running state data based on an XPU abstract data model issued by a cloud end in the cloud edge end cooperation architecture system, to obtain standardized state data; dynamically determining a current sampling frequency corresponding to the standardized state data by an adaptive variable frequency acquisition strategy; adjusting the sampling frequency based on a real-time evaluation result of a running risk of the heterogeneous computing power device by the adaptive variable frequency acquisition strategy; and collecting state data of the target heterogeneous computing power device according to the current sampling frequency, to obtain target state data conforming to the XPU abstract data model. The application can overcome the problems that heterogeneous computing power is difficult to monitor uniformly and existing acquisition methods are difficult to support fault judgment.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a method, system and device for acquiring heterogeneous computing power status data for cloud-edge-device collaboration. Background Technology

[0002] With the continuous expansion of the Internet of Things (IoT), cloud-edge-device collaborative architecture has become the mainstream technology supporting large-scale device access and business operations. Under this architecture, computing power is gradually shifting from centralized cloud computing to edge nodes and field terminals to meet the real-time, reliability, and system resilience requirements of the power industry. Simultaneously, the system widely deploys various types of heterogeneous computing power, including CPUs, GPUs, and other XPUs, to handle tasks such as data processing, edge analysis, and intelligent decision-making.

[0003] In existing industrial IoT systems, the perception and management of computing power operation status typically involves deploying monitoring components in the cloud or at the edge to collect and report the resource usage of computing nodes. These methods often operate on a device or node-by-device basis, periodically collecting operational metrics such as processor utilization, load, temperature, and power consumption, and then centrally displaying or analyzing these metrics on a cloud platform to achieve basic monitoring of the system's operational status.

[0004] However, with the widespread application of heterogeneous computing power in cloud-edge-device architectures, existing methods have gradually revealed significant shortcomings. On the one hand, different types of computing power vary considerably in hardware structure, performance indicators, and operational characteristics. Existing data collection methods are often implemented for specific devices or vendors, lacking a unified data model to abstractly describe the operational status of computing power. This makes it difficult to uniformly monitor and manage heterogeneous computing power operational data at the system level. On the other hand, heterogeneous computing power is prone to performance anomalies or failures under complex loads and operating environments. Fault diagnosis heavily relies on high-quality operational status data. Existing data collection methods based on fixed periods generate a large amount of redundant data during stable system operation, while the collection frequency is insufficient during anomaly or fault occurrence, resulting in low-quality datasets that cannot accurately identify and resolve faults. Summary of the Invention

[0005] In view of this, embodiments of this application provide a method, system, and device for collecting heterogeneous computing power status data for cloud-edge-device collaboration, to eliminate or improve one or more defects existing in the prior art. It can solve the problems of difficulty in unified monitoring of heterogeneous computing power and the inability of existing collection methods to support fault diagnosis.

[0006] One aspect of this application provides a method for collecting heterogeneous computing power status data for cloud-edge-device collaboration. This method is executed in a terminal device or edge node within a cloud-edge-device collaborative architecture system, and includes the following steps: Acquire raw operating status data of the target heterogeneous computing power device; Based on the XPU abstract data model issued by the cloud in the cloud-edge-device collaborative architecture system, the original operating status data is standardized to obtain standardized status data; wherein, the XPU abstract data model is used to define a unified field system for the status of heterogeneous computing power devices. An adaptive frequency conversion acquisition strategy dynamically determines the current sampling frequency corresponding to the standardized state data; the adaptive frequency conversion acquisition strategy adjusts the sampling frequency based on the real-time assessment results of the operational risks of the heterogeneous computing power equipment; Based on the current sampling frequency, status data is collected from the target heterogeneous computing device to obtain target status data that conforms to the XPU abstract data model.

[0007] In some embodiments of this application, the adaptive frequency conversion acquisition strategy dynamically determines the current sampling frequency corresponding to the standardized state data; the adaptive frequency conversion acquisition strategy adjusts the sampling frequency based on the real-time assessment result of the operational risk of the heterogeneous computing power device, including: The standardized state data is subjected to online baselineization and feature construction processing to obtain standardized offset data and change rate data; Multidimensional risk calculations are performed on the standardized offset data and the rate of change data to obtain multiple risk component data; wherein, the risk component data includes anomaly degree, mutation degree, stress degree and drift degree; Risk fusion is performed on multiple risk component data to obtain the overall risk score; Based on the overall risk score, the current sampling frequency is dynamically determined using an adaptive frequency conversion acquisition strategy based on a frequency mapping function.

[0008] In some embodiments of this application, the online baselineization and feature construction processing based on the standardized state data to obtain standardized offset data and rate of change data includes: For each dynamic indicator in the standardized state data, calculate the corresponding dynamic mean and dynamic scale; Based on the dynamic mean and the dynamic scale, the standardized offset of the current indicator value relative to the historical baseline is calculated to obtain the standardized offset data; The change in the dynamic indicator is calculated for two consecutive data collections, and the short-term rate of change characteristics of the dynamic indicator are calculated based on the change to obtain the rate of change data.

[0009] In some embodiments of this application, the step of performing risk fusion on multiple risk component data to obtain an overall risk score includes: Preset weighting coefficients are assigned to the degree of anomaly, degree of mutation, degree of stress, and degree of drift, respectively; The overall risk score is obtained by multiplying each risk component data by its corresponding weight coefficient and then summing the results.

[0010] In some embodiments of this application, the step of dynamically determining the current sampling frequency based on the overall risk score using an adaptive frequency conversion acquisition strategy via a frequency mapping function includes: Based on the overall risk score, an initial sampling frequency between a preset minimum sampling frequency and a preset maximum sampling frequency is obtained through the frequency mapping function; The initial sampling frequency is time-smoothed to obtain the actual sampling frequency; Based on the hysteresis state machine, the actual sampling frequency is dynamically adjusted according to the overall risk score, preset high and low thresholds, and minimum dwell time, and the final effective actual sampling frequency is determined as the current sampling frequency.

[0011] In some embodiments of this application, the XPU abstract data model is also used for: The original operational status data is standardized based on attribute dimensions and generality dimensions to obtain standardized status data. The attribute dimensions include static information and dynamic indicators. The static information describes the inherent attributes of the target heterogeneous computing power device. The dynamic indicators describe the runtime sequence changes of the target heterogeneous computing power device. The generality dimensions include general fields and specific fields. The general fields include common fields shared by all target heterogeneous computing power devices. The specific fields include specific fields defined for a particular type of target heterogeneous computing power device.

[0012] In some embodiments of this application, the general fields include all XPU general fields and accelerator general fields; the all XPU general fields include device unique identifier, device type, architecture, manufacturer, model, driver version, firmware version, number of computing units, computing core utilization, real-time power consumption, current clock frequency, chip temperature, motherboard temperature, frequency limiting flag, frequency limiting reason, most recent error code, most recent error timestamp, sliding window average load percentage, acquisition timestamp, and sampling period; the accelerator general fields include total dedicated storage, used storage, storage utilization, PCIe receive throughput, PCIe transmit throughput, performance status, power limit, error-correctable error rate, error-uncorrectable error rate, device runtime, and device reset count.

[0013] In some embodiments of this application, the unique fields include CPU-specific fields and GPU-specific fields; the CPU-specific fields include the number of active threads, context switching rate, L3 cache capacity, and I / O device utilization; the GPU-specific fields include fan speed, energy efficiency ratio, NV frequency limiting reason string, ECC error correction accumulation, ECC non-error correction accumulation, video memory frequency, and core graphics frequency.

[0014] Another aspect of this application provides a heterogeneous computing power status data acquisition system for cloud-edge-device collaboration, the system comprising: The data acquisition module is used to acquire the raw operating status data of the target heterogeneous computing power device; The standardization processing module is used to input the original operating status data into a preset XPU abstract data model so that the model can standardize the original operating status data to obtain standardized status data. An adaptive control module is used to dynamically determine the current sampling frequency corresponding to the standardized state data using an adaptive frequency conversion acquisition strategy; the adaptive frequency conversion acquisition strategy adjusts the sampling frequency based on the real-time assessment results of the operational risks of the heterogeneous computing power equipment. The status data acquisition module is used to acquire status data of the target heterogeneous computing power device according to the current sampling frequency, and obtain target status data that conforms to the XPU abstract data model.

[0015] A third aspect of this application provides an electronic device, including a processor and a memory, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the aforementioned heterogeneous computing power status data acquisition method for cloud-edge-device collaboration.

[0016] The fourth aspect of this application provides a computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the aforementioned heterogeneous computing power status data acquisition method for cloud-edge-device collaboration.

[0017] The fifth aspect of this application provides a computer program product comprising a computer program that, when executed by a processor, implements the described heterogeneous computing power status data acquisition method for cloud-edge-device collaboration.

[0018] This application discloses a method for acquiring heterogeneous computing power status data for cloud-edge-device collaboration. The method includes the following steps: acquiring raw operating status data of the target heterogeneous computing power device; standardizing the raw operating status data based on the XPU abstract data model issued by the cloud in the cloud-edge-device collaborative architecture system to obtain standardized status data; wherein, the XPU abstract data model is used to define a unified field system for the status of heterogeneous computing power devices; an adaptive frequency conversion acquisition strategy dynamically determines the current sampling frequency corresponding to the standardized status data; the adaptive frequency conversion acquisition strategy adjusts the sampling frequency based on the real-time assessment result of the operating risk of the heterogeneous computing power device; and, according to the current sampling frequency, acquires status data of the target heterogeneous computing power device to obtain target status data conforming to the XPU abstract data model. This method enables unified monitoring and management of heterogeneous computing power; and achieves deep collaboration between sampling strategies and fault evolution processes, improving the identifiability of key data and significantly reducing invalid data acquisition. It solves the problems of difficulty in unified monitoring of heterogeneous computing power and the inability of existing acquisition methods to support fault judgment, providing fundamental technical support for the reliable operation and intelligent maintenance of heterogeneous computing power in the power Internet of Things.

[0019] Additional advantages, objectives, and features of this application will be set forth in part in the description which follows, and will in part become apparent to those skilled in the art upon review of the following description, or may be learned by practice of the application. The objectives and other advantages of this application can be realized and obtained by means of the structures specifically pointed out in the specification and drawings.

[0020] Those skilled in the art will understand that the purposes and advantages that can be achieved with this application are not limited to those specifically described above, and that the above and other purposes that this application can achieve will be more clearly understood from the following detailed description. Attached Figure Description

[0021] The accompanying drawings, which are included to provide a further understanding of this application and form part of this application, do not constitute a limitation thereof. The components in the drawings are not drawn to scale but are merely for illustrating the principles of this application. For ease of illustration and description of certain parts of this application, corresponding portions in the drawings may be enlarged, i.e., may appear larger relative to other components in an exemplary device actually manufactured according to this application. In the drawings: Figure 1 This is a schematic diagram of the first process of a heterogeneous computing power status data acquisition method for cloud-edge-device collaboration in one embodiment of this application.

[0022] Figure 2 This is a schematic diagram of the second process of a heterogeneous computing power status data acquisition method for cloud-edge-device collaboration in one embodiment of this application.

[0023] Figure 3 This is a schematic diagram of the third process of a heterogeneous computing power status data acquisition method for cloud-edge-device collaboration in one embodiment of this application.

[0024] Figure 4 This is a schematic diagram of a heterogeneous computing power status data acquisition system for cloud-edge-device collaboration in one embodiment of this application.

[0025] Figure 5 This is a schematic diagram of the XPU abstract data model in a heterogeneous computing power status data acquisition method for cloud-edge-device collaboration, as described in a specific example of this application.

[0026] Figure 6 This is a flowchart illustrating an adaptive frequency conversion acquisition strategy in a heterogeneous computing power status data acquisition method for cloud-edge-device collaboration, as described in a specific example of this application.

[0027] Figure 7 This is a schematic diagram of the state transition process in the adaptive frequency conversion acquisition strategy of the heterogeneous computing power state data acquisition method for cloud-edge-device collaboration, as illustrated in a specific example of this application. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the embodiments and accompanying drawings. Here, the illustrative embodiments and their descriptions are used to explain this application, but are not intended to limit it.

[0029] It should also be noted that, in order to avoid obscuring this application with unnecessary details, only the structures and / or processing steps closely related to the solution according to this application are shown in the accompanying drawings, while other details that are not closely related to this application are omitted.

[0030] It should be emphasized that the term "including / comprises" as used herein refers to the presence of a feature, element, step, or component, but does not exclude the presence or addition of one or more other features, elements, steps, or components.

[0031] It should also be noted that, unless otherwise specified, the term "connection" in this article can refer not only to a direct connection, but also to an indirect connection involving an intermediary.

[0032] In the following description, embodiments of the present application will be illustrated with reference to the accompanying drawings. In the drawings, the same reference numerals represent the same or similar parts, or the same or similar steps.

[0033] It's important to note that in the early stages of the Internet of Things (IoT), data processing and analysis tasks primarily relied on centralized computing. However, with the rapid increase in the number of terminals and the growing demands for real-time response capabilities in field operations, simply relying on centralized cloud processing has become insufficient to meet the low-latency and high-reliability business requirements. This has led to the evolution of a cloud-edge-device collaborative system architecture, which deploys computing capabilities at different levels to achieve layered processing and collaborative operation of computing tasks. In this cloud-edge-device architecture, to adapt to different business scenarios and performance requirements, nodes at each level are typically configured with various types of computing resources, such as heterogeneous computing power including CPUs and GPUs. The widespread application of heterogeneous computing power has effectively improved the computing efficiency and resource utilization of the power IoT, but it has also made the types of computing power more diverse and their distribution more dispersed, bringing new challenges to the unified management and control of computing power operation status. Existing technologies for unified management and control of heterogeneous computing power mainly suffer from the following problems: On the one hand, different types of heterogeneous computing power have significant differences in hardware architecture, performance indicators, and operating characteristics. The lack of a unified data model to abstract and express their operating status leads to scattered and incomparable computing power operating status data, making unified monitoring and management difficult under a cloud-edge-device architecture. On the other hand, heterogeneous computing power is prone to performance anomalies or failures under complex operating environments and dynamic load conditions. Fault diagnosis relies on high-quality, representative operating status data. Existing data acquisition methods mostly adopt fixed-period acquisition strategies, collecting a large amount of redundant data during the stable operation phase of computing power, while the acquisition frequency is insufficient during fault occurrence or near-fault phases, making it difficult to form data that effectively supports fault analysis and judgment. While some exploration has been made in the acquisition and monitoring of status data for distributed systems, cloud-edge-device collaborative architectures, and heterogeneous resources in existing technologies, there are still significant differences compared to the goals of unified monitoring and management of heterogeneous computing power and high-quality data support for fault analysis addressed in this application. Some research has analyzed the practice of monitoring systems for heterogeneous artificial intelligence computing power platforms, discussing the challenges of monitoring indicators, data acquisition, and status awareness for heterogeneous computing power. This work emphasizes the differences in observation data patterns among different computing powers and the complexity of monitoring system architecture in heterogeneous environments, but mainly focuses on platform-level monitoring strategies and system architecture practices, without proposing a unified abstract data model or adaptive acquisition strategy. Related researchers have proposed an AI-based telemetry analysis framework for reliability prediction and privacy observation of enterprise-level systems. This framework improves monitoring efficiency by correlating cross-layer indicators and logs and using machine learning for anomaly detection. While this approach offers some insights into large-scale monitoring and dynamic analysis, its core remains focused on machine learning-enhanced analysis rather than a unified modeling and adaptive acquisition mechanism for heterogeneous computing power operational status data.Other studies have proposed a modular data integration and monitoring architecture for IoT (Internet of Things) systems. Its core is the unified collection and storage of metrics from multiple heterogeneous data sources, and the visualization of cross-system performance and status through time-series databases and other means. This method can effectively integrate multiple data collectors and support real-time monitoring, but it primarily focuses on sensor or node-level metric collection and display, without deeply addressing the technical issues of a unified abstract model at the computing power level or adaptively adjusting collection strategies based on operational risks. Researchers have also proposed a virtualized network vision architecture (VINEVI), which uses node-embedded agents to achieve real-time traffic classification and monitoring of physical and virtual resources. This framework leverages monitoring components such as Prometheus (a service monitoring system) to achieve a unified monitoring view in a multi-layered environment. This type of work shows a trend towards unified collection and aggregation of heterogeneous components, but it mainly focuses on network traffic and performance metrics, without covering the details of abstracting the operational status of heterogeneous computing power and optimizing strategies based on collection efficiency. Furthermore, some solutions address data acquisition and allocation for edge computing scenarios. These solutions mine and aggregate information from edge and terminal devices to form vector representations, then match them to determine which edge device is responsible for sampling and acquisition, thereby improving the reliability and efficiency of edge-side acquisition and processing. However, their focus remains on "terminal-edge allocation and matching," failing to provide a unified abstract data model for heterogeneous computing power or propose a data quality-oriented acquisition strategy for fault diagnosis, addressing the issue of "redundancy during stable periods versus insufficient frequency during failure periods." In summary, while existing solutions have conducted extensive research in distributed monitoring, edge telemetry acquisition, cross-layer system observability, and large-scale telemetry analysis, they have not fundamentally solved the problems of: unified abstract modeling and standardized representation of heterogeneous computing power operational status data; and the design of efficient and adjustable acquisition frequency strategies based on computing power operational status risks and dynamic changes. Therefore, the inventors of this application first conceived of an efficient heterogeneous computing power status data acquisition framework for cloud-edge-device collaboration, specifically for CPU and GPU heterogeneous computing power. This framework includes unified modeling and adaptive acquisition control of heterogeneous computing power operational status data. The framework operates collaboratively under a cloud, edge, and terminal collaborative architecture. The terminal and edge sides are responsible for the real-time collection and preliminary processing of the heterogeneous computing power operation status, while the cloud side uniformly manages and distributes the XPU abstract data model and the Heterogeneous Adaptive Variable-Frequency Sampling (HAVFS) strategy, and summarizes, displays, and analyzes the data.The XPU abstract data model aims to unify the data structure and indicator meaning of heterogeneous computing power devices, and realize unified monitoring and management of heterogeneous computing power; HAVFS aims to achieve deep synergy between sampling strategies and fault evolution processes, improve the identifiability of key data and significantly reduce invalid data collection, and provide a more representative and time-series data foundation for subsequent fault detection models.

[0034] The following examples will provide a detailed description.

[0035] This application provides a method for collecting heterogeneous computing power status data for cloud-edge-device collaboration. See [link to relevant documentation]. Figure 1 The method includes the following steps: Step 100: Obtain the raw operating status data of the target heterogeneous computing power device; In step 100, the raw operating status data can be operating status information collected from the target heterogeneous computing power device that has not undergone unified abstraction and standardization processing, including at least one or more of the following: processor or accelerator utilization information, computing load information, power consumption information, temperature information, frequency information, memory or video memory usage information, bandwidth usage information, hardware error or anomaly count information, and status monitoring data directly reported by the device driver layer, operating system layer or runtime environment.

[0036] Step 200: Based on the XPU abstract data model issued by the cloud in the cloud-edge-device collaborative architecture system, the original operating status data is standardized to obtain standardized status data; wherein, the XPU abstract data model is used to define a unified field system for the status of heterogeneous computing power devices. In step 200, the standardized state data can be structured state data obtained by performing field mapping, semantic alignment, and scale unification processing on the original operating state data based on the XPU abstract data model. This standardized state data uses a unified field system to describe the operating state of different types of heterogeneous computing power devices. The standardized state data includes at least device attribute fields and operating indicator fields. Device attribute fields characterize the type, architecture, or resource specifications of the heterogeneous computing power devices, while operating indicator fields characterize the device's operating load, performance, power consumption, or temperature at the current data collection time. By constructing the XPU abstract data model, the operating state of different types of heterogeneous computing power devices is uniformly described. The XPU abstract data model abstracts data from two dimensions: device attributes and operating indicators. It structurally organizes the static information, dynamic operating indicators, and architecture-related features of heterogeneous computing power, achieving cross-device and cross-architecture indicator alignment while preserving the differentiated characteristics of heterogeneous computing power itself. This provides a standardized data foundation for unified data collection and subsequent analysis in a cloud-edge-device environment.

[0037] Step 300: The adaptive frequency conversion acquisition strategy dynamically determines the current sampling frequency corresponding to the standardized state data; the adaptive frequency conversion acquisition strategy adjusts the sampling frequency based on the real-time assessment results of the operational risks of the heterogeneous computing power equipment; In step 300, the sampling frequency is dynamically adjusted by continuously evaluating the operating status of the heterogeneous computing power. The adaptive frequency conversion acquisition strategy is based on the state changes and potential risks during computing power operation. When the equipment is operating stably, the sampling frequency is reduced to decrease redundant data, while the sampling frequency is increased when abnormal fluctuations occur or risks rise, focusing on capturing high-value data during critical periods. In this way, the data sampling process can be matched with the computing power's operating status, achieving a balance between sampling frequency and data quality.

[0038] Step 400: Based on the current sampling frequency, collect status data from the target heterogeneous computing device to obtain target status data that conforms to the XPU abstract data model.

[0039] In step 400, the target state data can be the running state data collected from the target heterogeneous computing power device at the current sampling frequency, which conforms to the field definition of the XPU abstract data model. The target state data uses a unified field structure to characterize the running state of the heterogeneous computing power device at the corresponding sampling time.

[0040] In one or more embodiments of this application, the edge and terminal sides are responsible for the real-time acquisition and preliminary processing of the heterogeneous computing power operating status, while the cloud side uniformly manages and distributes the adaptive frequency conversion acquisition strategy and the XPU abstract data model, and summarizes, displays, and analyzes the data. By combining the XPU abstract data model with the adaptive frequency conversion acquisition strategy, the problems of difficult unified monitoring of heterogeneous computing power and the inability of existing acquisition methods to support fault diagnosis can be solved, providing fundamental technical support for the reliable operation and intelligent maintenance of heterogeneous computing power in the power Internet of Things.

[0041] As can be seen from the above description, the heterogeneous computing power status data acquisition method for cloud-edge-device collaboration provided in this application unifies the data structure and indicator meaning of heterogeneous computing power devices through the XPU abstract data model, enabling unified monitoring and management of heterogeneous computing power; and achieves deep collaboration between sampling strategy and fault evolution process through adaptive frequency conversion acquisition strategy, improving the identifiability of key data and significantly reducing invalid data acquisition, which can solve the problems of difficulty in unified monitoring of heterogeneous computing power and the inability of existing acquisition methods to support fault judgment, providing basic technical support for the reliable operation and intelligent operation and maintenance of heterogeneous computing power in the power Internet of Things.

[0042] To further achieve deep synergy between sampling strategies and fault evolution processes, improve the identifiability of key data, and significantly reduce invalid data collection, this application provides a heterogeneous computing power status data collection method for cloud-edge-device collaboration, see [link to relevant documentation]. Figure 2 Step 300 includes: Step 310: Perform online baselineization and feature construction processing on the standardized state data to obtain standardized offset data and change rate data; In step 310, since the monitoring indicators of heterogeneous computing power differ significantly in terms of dimensions, value range, and fluctuation characteristics, directly using absolute values ​​for subsequent risk calculations would lead to incomparability between different indicators and between different devices, thereby affecting the accuracy of risk assessment and the effectiveness of sampling frequency adjustment. Therefore, it is necessary to establish a "dynamic normal reference" (i.e., baseline and fluctuation scale) for each heterogeneous computing power device online, and convert the standardized state data into standardized offset data and change rate data on a unified relative scale, so that subsequent risk components can be calculated under a consistent dimension, achieving comparability across indicators and devices. The standardized offset data can be the deviation of the standardized state data from the dynamic normal reference of the corresponding heterogeneous computing power device, used to characterize the relative difference between the current state and its historical normal level. The change rate data can be the change amplitude or trend data of the standardized state data between adjacent sampling times, used to characterize the speed of change or fluctuation intensity of the operating state of the heterogeneous computing power device.

[0043] Step 320: Perform multidimensional risk calculation on the standardized offset data and the rate of change data to obtain multiple risk component data; wherein, the risk component data includes anomaly degree, mutation degree, stress degree and drift degree; In step 320, heterogeneous computing power may exhibit anomalies or degradation in various forms during operation. Relying on a single indicator or risk metric is insufficient to comprehensively reflect the health status of the equipment. Therefore, HAVFS defines four risk components: anomaly degree. degree of mutation Stress level degree of drift This study quantifies the operational status of heterogeneous computing power from multiple complementary perspectives, characterizing whether it is currently abnormal, whether a sudden change has occurred, whether it is approaching the safety boundary, and whether there is a long-term degradation trend. Each component's output value is in the range [0,1], with larger values ​​indicating higher risk. (Abnormality level) This reflects the deviation of the current indicator from its historical stable range, focusing on whether the current indicator is in an abnormal state. To avoid extreme value interference, a robust metric is constructed using the median and median absolute deviation (MAD), as shown in formula (1): (1) in, Indicates time t; This represents the operating metric of the j-th XPU; This represents the set of indicators used to calculate outlier components; Indicates the time window range; This represents the original value of the j-th XPU's operating metric; Display window The median of this indicator is used to describe the historical center of normality; Display window The median absolute deviation within the range is used to describe the historical fluctuation range; This represents the sensitivity coefficient, used to control sensitivity. This represents a very small constant. The larger the value, the greater the difference from the normal.

[0044] degree of mutation This is used to measure whether the operating status within a short time window deviates significantly from the long-term operating trend, focusing on whether the operating status has undergone sudden changes. The calculation process for the degree of sudden change is shown in formula (2): (2) in, Indicates a short time window; This represents the vector of index mean values ​​within a short window, used to characterize short-term operating conditions. Indicates a long-term window; This represents the average value of indicators within a long window, used to depict long-term trends. It represents the long-term fluctuation scale and serves a normalization function; This represents a very small constant. A larger value indicates more drastic short-term changes.

[0045] stress level Used to assess whether the equipment's operating status is approaching the safe operating boundary, or whether there is an excessively rapid upward trend, and to impose additional risk penalties when frequency limiting, power limiting, or other throttling behaviors are detected. The calculation process is shown in formulas (3) to (6): (3) (4) (5) (6) in, This represents the weighting factor between the maximum pressure and the average pressure; Indicates the weight of the speed term; Indicates the throttling penalty coefficient; , This indicates taking the maximum value and the arithmetic mean of the selected set of evaluation indicators respectively; Indicates the normalized stress level. The larger the value, the more dangerous it is. The smaller the value, the more dangerous it is; Indicates the safety threshold. Critical threshold; Indicates the rate of ascent; Represents the scale factor, which combines different dimensions. Standardize to a comparable range. When the value approaches 1, it indicates that the indicator is too high or changing too rapidly.

[0046] Drift degree Used to characterize the long-term changing trend of the heterogeneous computing power operating baseline, reflecting chronic risks such as hardware aging and performance degradation, the calculation process is shown in formulas (7) and (8): (7) (8) in, It is a vector of recent means; This indicates the time window scale identifier used for drift risk assessment, which is used to distinguish statistical characteristics at different time scales; It is the vector of the index mean values ​​of the long window; Length of the time window used for drift assessment; This is the normalization constant; This represents the drift risk weight parameter; Indicates the GPU memory error correction rate; Indicates the upper limit of GPU memory error correction rate; Indicates the statistical drift result; This represents a very small constant. The larger the value, the higher the risk of long-term degradation.

[0047] Step 330: Perform risk fusion on the multiple risk component data to obtain the overall risk score; In step 330, the risk component data characterizes the potential risks of the heterogeneous computing power operation status from different perspectives. However, a single component is difficult to directly use for the adjustment and control of the sampling frequency. Therefore, the overall risk score is used to integrate the four risk components to describe the health status of the heterogeneous computing power.

[0048] Step 340: Based on the overall risk score, dynamically determine the current sampling frequency using an adaptive frequency conversion acquisition strategy based on a frequency mapping function.

[0049] In step 340, the overall risk is mapped to the corresponding data collection frequency, so that the collection behavior can dynamically change with the risk of computing power operation.

[0050] To further achieve deep synergy between sampling strategies and fault evolution processes, improve the identifiability of key data, and significantly reduce invalid data collection, this application provides a heterogeneous computing power status data collection method for cloud-edge-device collaboration, see [link to relevant documentation]. Figure 3 Step 310 includes: Step 311: For each dynamic indicator in the standardized state data, calculate the corresponding dynamic mean and dynamic scale; In step 311, the dynamic mean and dynamic scale of each indicator are calculated using the exponential moving average method to form the online baseline of the equipment itself, and to grasp the recent stable level of heterogeneous computing power. The calculation process is shown in formulas (9) and (10): (9) (10) in, This represents the raw value of the j-th monitoring indicator at time t; This represents the dynamic mean of the indicator, i.e., the recent baseline; This indicates the dynamic scale of the indicator, i.e., the recent range of fluctuations; This represents the smoothing coefficient. A larger coefficient indicates greater sensitivity to the latest observations, while a smaller coefficient indicates a smoother baseline and better resistance to short-term noise.

[0051] Step 312: Calculate the standardized offset of the current index value relative to the historical baseline based on the dynamic mean and the dynamic scale, and obtain the standardized offset data; In step 312, a standardized offset calculation is performed on each indicator to obtain the volatility multiple of the indicator. The deviation values ​​of different indicators are converted to a unified dimension to facilitate risk calculation. The calculation process is shown in formula (11): (11) in, This represents the standardized deviation of the current indicator from the normal state. The larger the absolute value, the more serious the deviation of the indicator from the normal state. This represents a very small constant and serves to prevent division by zero.

[0052] Step 313: Calculate the change in the dynamic indicator collected in two consecutive collections, and calculate the short-term change rate characteristics of the dynamic indicator based on the change to obtain the change rate data.

[0053] In step 313, it is difficult to capture short-term dynamic phenomena such as "sudden change / surge" using only the offset amplitude. Therefore, it is necessary to construct features that reflect the rate of change. The first-order difference and the sliding amplitude are used for calculation to reflect the rate of change of the index and capture short-term fluctuation features. The calculation process of the rate of change data is shown in formulas (12) and (13): (12) (13) in, This indicates the change in an indicator between two consecutive samples; This indicates the rate of fluctuation of the indicator; the larger the value, the more volatile the indicator has been recently. This represents the short-term smoothing coefficient.

[0054] To further achieve deep synergy between sampling strategies and fault evolution processes, improve the identifiability of key data, and significantly reduce invalid data collection, in a heterogeneous computing power status data collection method for cloud-edge-device collaboration provided in this application embodiment, step 330 includes: Step 331: Assign preset weighting coefficients to the degree of anomaly, degree of mutation, degree of stress, and degree of drift, respectively; Step 332: Multiply each of the risk component data with its corresponding weight coefficient and sum them to obtain the overall risk score.

[0055] In one or more embodiments of this application, the overall risk score By assigning weights to different risk components, the system can emphasize different types of risks according to actual operational needs. The calculation formula is shown in (14): (14) in, These represent the weighting parameters for the four risk components mentioned above: degree of anomaly, degree of mutation, degree of stress, and degree of drift. Finally... It is a value in the range [0, 1].

[0056] To further achieve deep synergy between sampling strategies and fault evolution processes, improve the identifiability of key data, and significantly reduce invalid data collection, in a heterogeneous computing power status data collection method for cloud-edge-device collaboration provided in this application embodiment, step 340 includes: Step 341: Based on the overall risk score, obtain an initial sampling frequency between the preset minimum sampling frequency and the maximum sampling frequency through the frequency mapping function; In step 341, the initial sampling frequency It is obtained by mapping from the overall risk score, as shown in formula (15): (15) in, Indicates the upper and lower limits of the sampling frequency; Indicates the steepness of the Sigmoid curve; This indicates the midpoint of risk, used to control the starting position of frequency increases.

[0057] Step 342: Perform time smoothing processing on the initial sampling frequency to obtain the actual sampling frequency; In step 342, to avoid frequent changes in the sampling frequency due to risk fluctuations between adjacent time steps, a smoothing mechanism is introduced to ensure that the actual sampling frequency remains constant. The sampling frequency is gradually approached from the initial sampling frequency, thereby improving the stability of the sampling strategy. The actual sampling frequency is shown in formula (16): (16) in, This represents the time smoothing coefficient.

[0058] Step 343: Based on the hysteresis state machine, the actual sampling frequency is dynamically adjusted according to the overall risk score, the preset high and low thresholds, and the minimum dwell time, and the final effective actual sampling frequency is determined as the current sampling frequency.

[0059] In step 343, since the heterogeneous computing power metrics may change frequently, to avoid frequent fluctuations in the sampling frequency near the boundaries, which would increase system load and generate data noise, HAVFS uses a hysteresis state machine and a dwell mechanism to constrain the sampling frequency adjustment process. This ensures that the system only undergoes a state transition when the risk crosses high / low thresholds and meets the minimum dwell time requirement, thereby guaranteeing the stability and controllability of the sampling strategy. When the overall risk score... and exceeds the high threshold When this happens, the system does not immediately enter alarm state. Instead, it requires that the condition of "the minimum dwell time since the last switch" be met simultaneously, thus avoiding false triggering caused by short-term spikes. Alarm state exit uses a low threshold. The decision is made that an alarm can only exit the alarm state when the risk drops below a low threshold and the minimum dwell time after entering the alarm is met. Once the hysteresis state machine is determined, the states need to be mapped to the final effective sampling frequency: when in the ALERT or EXPLORE state, the sampling frequency is directly increased to the upper limit to capture critical anomalies. When in STABLE state, maintain the current frequency. This yields the final effective current sampling frequency. The state transitions are shown in equations (17) to (19): (17) (18) (19) in, This indicates the high and low thresholds for the overall risk score; Indicates the minimum stay time; Indicates the time when the state transition last occurred; Indicates the moment of entering the ALERT state; The three states of the state machine are STABLE, EXPLORE, and ALERT.

[0060] In one or more embodiments of this application, relying solely on a deterministic sampling strategy based on historical risks during actual operation may lead to a lag in the perception of novel anomalies or sudden failures. To ensure coverage of rare or unknown risks in heterogeneous computing power, HAVFS uses the exploration state in the state machine to randomly perform high-frequency checks during long-term stability. Simultaneously, to provide high-quality sample support for subsequent fault judgment, HAVFS uses a buffering mechanism to save the window data before and after entering the ALERT state, ensuring that key fault segments are completely recorded, as shown in formula (20): (20) in, This is the moment when the ALERT state is entered; Indicates the buffer time before and after the fault.

[0061] To further achieve unified monitoring and management of heterogeneous computing power, in the heterogeneous computing power status data acquisition method for cloud-edge-device collaboration provided in this application embodiment, the XPU abstract data model is also used for: The original operational status data is standardized based on attribute dimensions and generality dimensions to obtain standardized status data. The attribute dimensions include static information and dynamic indicators. The static information describes the inherent attributes of the target heterogeneous computing power device. The dynamic indicators describe the runtime sequence changes of the target heterogeneous computing power device. The generality dimensions include general fields and specific fields. The general fields include common fields shared by all target heterogeneous computing power devices. The specific fields include specific fields defined for a particular type of target heterogeneous computing power device.

[0062] In one or more embodiments of this application, the inherent attributes of the target heterogeneous computing power device include its basic configuration and operating environment, such as device identification, type, chip architecture, driver and firmware version, etc. This information typically remains unchanged during device operation and is used to uniquely identify and classify the device. Dynamic indicators are used to describe the temporal changes in the device's operating status, including operating load data, power consumption data, temperature data, communication data, logs, and system event data. The general dimension includes general fields and specific fields; general fields are core indicators shared by all XPUs, further subdivided into general fields for all XPUs and general fields for the accelerator; specific fields are differentiated indicators defined for heterogeneous computing power, used to preserve architectural characteristics. This "dual-dimensional model" can achieve cross-architecture indicator alignment while preserving architecture-specific characteristics, allowing subsequent fault detection models to learn general rules under a unified input format while maintaining the ability to identify device characteristics. The XPU abstract data model can establish a unified and scalable indicator abstraction system for describing the operating status of heterogeneous computing power across devices. This model ensures the semantic integrity of the indicators while achieving structural alignment of monitoring data from different devices, thus enabling unified status monitoring of heterogeneous computing power.

[0063] To further achieve unified monitoring and management of heterogeneous computing power, in a heterogeneous computing power status data acquisition method for cloud-edge-device collaboration provided in this application embodiment, the general fields include all XPU general fields and accelerator general fields; the all XPU general fields include device unique identifier, device type, architecture, manufacturer, model, driver version, firmware version, number of computing units, computing core utilization, real-time power consumption, current main frequency, chip temperature, motherboard temperature, frequency limiting flag, frequency limiting reason, recent error code, recent error timestamp, sliding window average load ratio, collection timestamp, and sampling period; the accelerator general fields include total dedicated storage, used storage, storage utilization, PCIe receive throughput, PCIe transmit throughput, performance status, power limit, correctable error rate, non-correctable error rate, device runtime, and device reset count.

[0064] To further achieve unified monitoring and management of heterogeneous computing power, in a heterogeneous computing power status data acquisition method for cloud-edge-device collaboration provided in this application embodiment, the unique fields include CPU-specific fields and GPU-specific fields; the CPU-specific fields include the number of active threads, context switching rate, L3 cache capacity, and I / O device utilization; the GPU-specific fields include fan speed, energy efficiency ratio, NV frequency limiting reason string, ECC error correction accumulation, ECC non-error correction accumulation, memory frequency, and core graphics frequency.

[0065] This application also provides a heterogeneous computing power status data acquisition system for cloud-edge-device collaboration, see [link to relevant documentation]. Figure 4 The system includes: Data acquisition module 10 is used to acquire the original operating status data of the target heterogeneous computing power device; The standardization processing module 20 is used to input the original operating status data into a preset XPU abstract data model so that the model can standardize the original operating status data to obtain standardized status data. The adaptive control module 30 is used to dynamically determine the current sampling frequency corresponding to the standardized state data using an adaptive frequency conversion acquisition strategy; the adaptive frequency conversion acquisition strategy adjusts the sampling frequency based on the real-time assessment results of the operational risks of the heterogeneous computing power equipment. The status data acquisition module 40 is used to acquire status data of the target heterogeneous computing power device according to the current sampling frequency, and obtain target status data that conforms to the XPU abstract data model.

[0066] In a specific example of the heterogeneous computing power status data acquisition method for cloud-edge-device collaboration proposed in this application, the method includes: First, constructing an XPU abstract data model to uniformly describe the operating status of different types of computing power devices. This model abstracts data from two dimensions: device attributes and operating indicators. It structures and organizes the static information, dynamic operating indicators, and architecture-related features of heterogeneous computing power, achieving cross-device and cross-architecture indicator alignment while preserving the differentiated characteristics of heterogeneous computing power itself, thus providing a standardized data foundation for unified acquisition and subsequent analysis in a cloud-edge-device environment. Based on this, an adaptive frequency conversion acquisition strategy is further proposed. By continuously evaluating the operating status of heterogeneous computing power, the data acquisition frequency is dynamically adjusted. This strategy is based on the state changes and potential risks during computing power operation. When the device is operating stably, the acquisition frequency is reduced to decrease redundant data, while the acquisition frequency is increased when the operating status fluctuates abnormally or the risk increases, focusing on capturing high-value data during critical periods. In this way, the data acquisition process can be matched with the computing power operating status, achieving a balance between acquisition efficiency and data quality. The aforementioned framework operates collaboratively within a cloud-edge-device collaborative architecture. The device and edge sides are responsible for real-time collection and preliminary processing of the operational status of heterogeneous computing power, while the cloud side provides unified management and distribution of collection strategies and data models, and aggregates, displays, and analyzes the data. By combining a unified data model with an adaptive collection mechanism, this application effectively addresses the challenges of unified monitoring of heterogeneous computing power and the inadequacy of existing collection methods to support fault diagnosis, providing fundamental technical support for the reliable operation and intelligent maintenance of heterogeneous computing power in the power Internet of Things.

[0067] The XPU Abstract Data Model aims to establish a unified and scalable indicator abstraction system for describing the operational status of heterogeneous computing power across devices. This model ensures the semantic integrity of the indicators while achieving structural alignment of monitoring data from different devices, thus completing unified status monitoring of heterogeneous computing power. For example... Figure 5 As shown, the XPU abstract data model follows a "two-dimensional partitioning, hierarchical abstraction" design, including attribute dimensions and generality dimensions. Attribute dimensions are divided into static information and dynamic metrics. Static information describes the device's basic configuration and operating environment, including device identifier, type, chip architecture, driver and firmware version, etc. This information typically remains unchanged during device operation and is used to uniquely identify and classify devices. Dynamic metrics describe the temporal changes in the device's operating status, including operating load data, power consumption data, temperature data, communication data, logs, and system event data, etc. Generality dimensions are divided into general fields and specific fields. General fields are core metrics shared by all XPUs, further subdivided into general fields for all XPUs and general fields for accelerators. Specific fields are differentiated metrics defined for heterogeneous computing power, used to preserve architectural characteristics. This two-dimensional model enables cross-architecture metric alignment while preserving architecture-specific characteristics, allowing subsequent fault detection models to learn general patterns under a unified input format while maintaining the ability to identify device characteristics. Tables 1 to 4 show the general fields for all XPUs, general fields for accelerators, CPU-specific fields, and GPU-specific fields, respectively.

[0068] Table 1. Common Fields for All XPUs Table 2 General Fields for Accelerators Table 3 CPU-specific fields table Table 4 GPU-specific fields The adaptive frequency conversion acquisition strategy dynamically adjusts the sampling frequency by assessing equipment operational risks in real time, achieving adaptive sampling control of "low-risk frequency reduction and throttling, high-risk frequency increase and acquisition". See also Figure 6The adaptive frequency conversion acquisition strategy includes: online baselineization and feature construction to establish a dynamic "normal reference" for each device; multi-dimensional risk calculation, including calculation of four risk components: anomaly, mutation, stress, and drift; risk fusion and frequency mapping to obtain the overall risk and smoothly map it to the sampling frequency; hysteresis state machine control to prevent frequency jitter and maintain sampling stability; and exploration and buffering mechanisms to preserve critical windows during high-risk phases and support subsequent learning. Specifically, since the monitoring indicators of heterogeneous computing power differ significantly in terms of dimensions, value range, and fluctuation characteristics, directly using absolute values ​​for subsequent risk calculations would lead to incomparability between different indicators and between different devices, thus affecting the accuracy of risk assessment and the effectiveness of sampling frequency adjustment. Therefore, it is necessary to establish a "dynamic normal reference" (baseline and fluctuation scale) for each device online and convert the original indicators into deviation and change characteristics on a unified relative scale, so that subsequent risk components can be calculated under a consistent dimension, achieving comparability across indicators and devices. First, the dynamic mean and dynamic scale of each indicator are calculated using the exponential moving average method to form the online baseline of the equipment itself, and to grasp the recent stable level of heterogeneous computing power, as shown in formulas (9) to (10): (9) (10) in, This represents the raw value of the j-th monitoring indicator at time t; This represents the dynamic mean of the indicator, i.e., the recent baseline; This indicates the dynamic scale of the indicator, i.e., the recent range of fluctuations; The coefficient represents the smoothing factor; a larger coefficient indicates greater sensitivity to the latest observations, while a smaller coefficient indicates a smoother baseline and better resistance to short-term noise. Secondly, a standardized offset calculation is performed on each indicator to obtain the fluctuation multiple of the indicator. The deviation values ​​of different indicators are then converted to a unified dimension for easier risk calculation, as shown in formula (11). (11) in, This represents the standardized deviation of the current indicator from the normal state. The larger the absolute value, the more serious the deviation of the indicator from the normal state. It serves to prevent division by zero. Finally, it is difficult to capture short-term dynamic phenomena such as "sudden change / surge" using only the offset amplitude. Therefore, it is necessary to construct a feature that reflects the rate of change, and use the first-order difference and the sliding amplitude to calculate and reflect the rate of change of the index, and capture short-term fluctuation characteristics, as shown in formulas (12) to (13): (12) (13) in, This indicates the change in an indicator between two consecutive samples; This indicates the rate of fluctuation of the indicator; the larger the value, the more volatile the indicator has been recently. This represents the short-term smoothing coefficient.

[0069] Heterogeneous computing power may exhibit anomalies or degradation in various forms during operation. Relying on a single indicator or risk metric is insufficient to comprehensively reflect the health status of the equipment. Therefore, HAVFS defines four risk components: anomaly degree. degree of mutation Stress level degree of drift The system quantifies the operation status of heterogeneous computing power from multiple complementary perspectives, respectively characterizing whether it is currently abnormal, whether a sudden change has occurred, whether it is close to the safety boundary, and whether there is a long-term degradation trend. The output value of each component is in the range of [0,1], and the larger the value, the higher the risk.

[0070] abnormality This reflects the deviation of the current indicator from its historical stable range, focusing on whether the current indicator is in an abnormal state. To avoid extreme value interference, a robust metric is constructed using the median and median absolute deviation (MAD), as shown in formula (1): (1) in, This represents the set of indicators used to calculate outlier components; Display window The median of this indicator is used to describe the historical normal center; Display window The median absolute deviation within the range is used to describe the historical fluctuation range; This represents the sensitivity coefficient, which controls the sensitivity. The larger the value, the greater the difference from the normal.

[0071] degree of mutation This is used to measure whether the operating status within a short time window deviates significantly from the long-term operating trend, and focuses on reflecting whether the operating status has undergone sudden changes, as shown in formula (2): (2) in, Indicates a short time window; This represents the vector of index mean values ​​within a short window, used to characterize short-term operating conditions. Indicates a long-term window; This represents the average value of indicators within a long window, used to depict long-term trends. It represents the long-term fluctuation scale and serves a normalization function; stress level Used to assess whether the equipment's operating status is approaching the safe operating boundary or whether there is an excessively rapid upward trend, and to impose additional risk penalties when frequency limiting, power limiting, or other throttling behaviors are detected, as shown in formulas (3) to (6): (3) (4) (5) (6) in, This represents the weighting factor between the maximum pressure and the average pressure; Indicates the weight of the speed term; Indicates the throttling penalty coefficient; , This indicates taking the maximum value and the arithmetic mean of the selected set of evaluation indicators respectively; Indicates the normalized stress level. The larger the value, the more dangerous it is. The smaller the value, the more dangerous it is; Indicates the safety threshold. Critical threshold; Indicates the rate of ascent; Represents the scale factor, which combines different dimensions. Standardize to a comparable range. When the value approaches 1, it indicates that the indicator is too high or changing too rapidly.

[0072] Drift degree Used to characterize the long-term changing trend of the heterogeneous computing power operating baseline, reflecting chronic risks such as hardware aging and performance degradation, as shown in formulas (7) to (8): (7) (8) in, It is a vector of recent means; It is the vector of the index mean values ​​of the long window; Length of the time window used for drift assessment; This is the normalization constant; This represents the drift risk weight parameter; Indicates the GPU memory error correction rate; This indicates the upper limit of GPU memory error correction rate. The larger the value, the higher the risk of long-term degradation.

[0073] The aforementioned risk components characterize the potential risks of heterogeneous computing power operation from different perspectives. However, a single component is difficult to directly use for adjusting and controlling the sampling frequency. Therefore, the overall risk score is used instead. The four risk components are unified and integrated to describe the health status of heterogeneous computing power, and the overall risk is mapped to the corresponding data collection frequency, so that the collection behavior can dynamically change with the risk of computing power operation.

[0074] Overall Risk Score By assigning weights to different risk components, the system can emphasize different types of risks according to actual operational needs. The calculation formula is shown in (14): (14) in, These represent the weight parameters for the four risk components mentioned above. Finally... It is a value in the range [0, 1].

[0075] Target sampling frequency The sampling frequency is obtained by mapping from the overall risk score. To prevent frequent changes in the sampling frequency between adjacent time steps due to risk fluctuations, a smoothing mechanism is introduced to ensure the actual sampling frequency remains consistent. By gradually approaching the target sampling frequency, the stability of the sampling strategy is improved. The frequency mapping formulas are shown in formulas (15) to (16): (15) (16) in, Indicates the upper and lower limits of the sampling frequency; Indicates the steepness of the Sigmoid curve; This indicates the midpoint of risk, used to control the starting position of frequency increases; This represents the time smoothing coefficient.

[0076] Since the metrics of heterogeneous computing power may change frequently, in order to avoid the sampling frequency fluctuating frequently near the boundary, increasing the system burden and generating data noise, HAVFS uses a hysteresis state machine and a dwell mechanism to constrain the sampling frequency adjustment process. This ensures that the system only undergoes a state transition when the risk crosses the high / low threshold and meets the minimum dwell time, thereby ensuring the stability and controllability of the sampling strategy.

[0077] When the overall risk score and exceeds the high threshold When this happens, the system does not immediately enter alarm state. Instead, it requires that the condition of "the minimum dwell time since the last switch" be met simultaneously, thus avoiding false triggering caused by short-term spikes. Alarm state exit uses a low threshold. The determination is that an alarm can only be exited when the risk drops below a low threshold and the "stay time after entering the alarm reaches the minimum stay time".

[0078] Once the state machine is determined, the states need to be mapped to the final effective sampling frequency: when in the ALERT or EXPLORE state, the sampling frequency is directly increased to the upper limit to capture critical exception segments. When in STABLE state, maintain the current frequency. This yields the final effective sampling frequency. .

[0079] State transitions are shown in equations (17) to (19) and Figure 7 As shown: (17) (18) (19) in, This indicates the high and low thresholds for the overall risk score; Indicates the minimum stay time; Indicates the time when the state transition last occurred; Indicates the moment of entering the ALERT state; The three states of the state machine are STABLE, EXPLORE, and ALERT.

[0080] In actual operation, relying solely on deterministic sampling strategies based on historical risks may lead to a lag in the perception of new anomalies or sudden failures. To ensure coverage of risks that are rare or unknown in heterogeneous computing power, HAVFS uses exploratory states in a state machine to randomly perform high-frequency checks during long-term stability.

[0081] Meanwhile, in order to provide high-quality sample support for subsequent fault diagnosis, HAVFS uses a buffering mechanism to save the window data before and after entering the ALERT state, ensuring that key fault segments are completely recorded, as shown in formula (20): (20) in, This is the moment when the ALERT state is entered; Indicates the buffer time before and after the fault.

[0082] This application also provides an electronic device, which may include a processor, a memory, a receiver, and a transmitter. The processor is used to execute the heterogeneous computing power status data acquisition method for cloud-edge-device collaboration mentioned in the above embodiments. The processor and memory can be connected via a bus or other means, taking a bus connection as an example. The receiver can be connected to the processor and memory via wired or wireless means.

[0083] The processor can be a central processing unit (CPU). The processor can also be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, or combinations of the above types of chips.

[0084] Memory, as a non-transitory computer-readable storage medium, can be used to store non-transitory software programs, non-transitory computer-executable programs, and modules, such as the program instructions / modules corresponding to the heterogeneous computing power status data acquisition method for cloud-edge-device collaboration described in the embodiments of this application. The processor executes various functional applications and data processing by running the non-transitory software programs, instructions, and modules stored in the memory, thereby realizing the heterogeneous computing power status data acquisition method for cloud-edge-device collaboration described in the above method embodiments.

[0085] The memory may include a program storage area and a data storage area. The program storage area may store the operating system and applications required for at least one function; the data storage area may store data created by the processor, etc. Furthermore, the memory may include high-speed random access memory and non-transitory memory, such as at least one disk storage device, flash memory device, or other non-transitory solid-state storage device. In some embodiments, the memory may optionally include memory remotely located relative to the processor, which can be connected to the processor via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0086] The one or more modules are stored in the memory, and when executed by the processor, the heterogeneous computing power status data acquisition method for cloud-edge-device collaboration described in the embodiment is executed.

[0087] In some embodiments of this application, the user equipment may include a processor, a memory, and a transceiver unit. The transceiver unit may include a receiver and a transmitter. The processor, memory, receiver, and transmitter may be connected via a bus system. The memory is used to store computer instructions, and the processor is used to execute the computer instructions stored in the memory to control the transceiver unit to send and receive signals.

[0088] As one implementation method, the functions of the receiver and transmitter in this application can be implemented by transceiver circuits or dedicated transceiver chips, and the processor can be implemented by dedicated processing chips, processing circuits or general-purpose chips.

[0089] As another implementation approach, the server provided in this application embodiment can be implemented using a general-purpose computer. That is, the program code implementing the processor, receiver, and transmitter functions is stored in memory, and the general-purpose processor implements the processor, receiver, and transmitter functions by executing the code in memory.

[0090] This application also provides a computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements the steps of the aforementioned heterogeneous computing power status data acquisition method for cloud-edge-device collaboration. The computer-readable storage medium can be a tangible storage medium, such as random access memory (RAM), main memory, read-only memory (ROM), electrically programmable ROM, electrically erasable programmable ROM, registers, floppy disks, hard disks, removable storage disks, CD-ROMs, or any other form of storage medium known in the art.

[0091] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the aforementioned heterogeneous computing power status data acquisition method for cloud-edge-device collaboration.

[0092] Those skilled in the art will understand that the exemplary components, systems, and methods described in conjunction with the embodiments disclosed herein can be implemented in hardware, software, or a combination of both. Whether implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application. When implemented in hardware, it can be, for example, electronic circuits, application-specific integrated circuits (ASICs), appropriate firmware, plug-ins, function cards, etc. When implemented in software, the elements of this application are programs or code segments used to perform the required tasks. The programs or code segments can be stored on a machine-readable medium or transmitted over a transmission medium or communication link via data signals carried on a carrier wave.

[0093] It should be clarified that this application is not limited to the specific configurations and processes described above and shown in the figures. For the sake of brevity, detailed descriptions of known methods are omitted here. In the above embodiments, several specific steps are described and shown as examples. However, the method process of this application is not limited to the specific steps described and shown. Those skilled in the art can make various changes, modifications, and additions, or change the order of steps, after understanding the spirit of this application.

[0094] In this application, features described and / or illustrated for one embodiment may be used in the same or similar manner in one or more other embodiments, and / or combined with or in place of features of other embodiments.

[0095] The above description is merely a preferred embodiment of this application and is not intended to limit this application. Various modifications and variations can be made to the embodiments of this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for acquiring heterogeneous computing power status data for cloud-edge-device collaboration, characterized in that, The method, executed on a terminal device or edge node in a cloud-edge-device collaborative architecture system, includes: Acquire raw operating status data of the target heterogeneous computing power device; Based on the XPU abstract data model issued by the cloud in the cloud-edge-device collaborative architecture system, the original operating status data is standardized to obtain standardized status data; wherein, the XPU abstract data model is used to define a unified field system for the status of heterogeneous computing power devices. An adaptive frequency conversion acquisition strategy dynamically determines the current sampling frequency corresponding to the standardized state data; the adaptive frequency conversion acquisition strategy adjusts the sampling frequency based on the real-time assessment results of the operational risks of the heterogeneous computing power equipment; Based on the current sampling frequency, status data is collected from the target heterogeneous computing device to obtain target status data that conforms to the XPU abstract data model.

2. The method according to claim 1, characterized in that, The adaptive frequency conversion acquisition strategy dynamically determines the current sampling frequency corresponding to the standardized state data; The adaptive frequency conversion acquisition strategy adjusts the sampling frequency based on the real-time assessment results of the operational risks of the heterogeneous computing power equipment, including: The standardized state data is subjected to online baselineization and feature construction processing to obtain standardized offset data and change rate data; Multidimensional risk calculations are performed on the standardized offset data and the rate of change data to obtain multiple risk component data; wherein, the risk component data includes anomaly degree, mutation degree, stress degree and drift degree; Risk fusion is performed on multiple risk component data to obtain the overall risk score; Based on the overall risk score, the current sampling frequency is dynamically determined using an adaptive frequency conversion acquisition strategy based on a frequency mapping function.

3. The method according to claim 2, characterized in that, The online baselineization and feature construction processing based on the standardized state data yields standardized offset data and rate of change data, including: For each dynamic indicator in the standardized state data, calculate the corresponding dynamic mean and dynamic scale; Based on the dynamic mean and the dynamic scale, the standardized offset of the current indicator value relative to the historical baseline is calculated to obtain the standardized offset data; The change in the dynamic indicator is calculated for two consecutive data collections, and the short-term rate of change characteristics of the dynamic indicator are calculated based on the change to obtain the rate of change data.

4. The method according to claim 2, characterized in that, The process of fusing multiple risk component data to obtain an overall risk score includes: Preset weighting coefficients are assigned to the degree of anomaly, degree of mutation, degree of stress, and degree of drift, respectively; The overall risk score is obtained by multiplying each risk component data by its corresponding weight coefficient and then summing the results.

5. The method according to claim 2, characterized in that, The step of dynamically determining the current sampling frequency based on the overall risk score using an adaptive frequency conversion acquisition strategy via a frequency mapping function includes: Based on the overall risk score, an initial sampling frequency between a preset minimum sampling frequency and a preset maximum sampling frequency is obtained through the frequency mapping function; The initial sampling frequency is time-smoothed to obtain the actual sampling frequency; Based on the hysteresis state machine, the actual sampling frequency is dynamically adjusted according to the overall risk score, preset high and low thresholds, and minimum dwell time, and the final effective actual sampling frequency is determined as the current sampling frequency.

6. The method according to claim 1, characterized in that, The XPU abstract data model is also used for: The original operational status data is standardized based on attribute dimensions and generality dimensions to obtain standardized status data. The attribute dimensions include static information and dynamic indicators. The static information describes the inherent attributes of the target heterogeneous computing power device. The dynamic indicators describe the runtime sequence changes of the target heterogeneous computing power device. The generality dimensions include general fields and specific fields. The general fields include common fields shared by all target heterogeneous computing power devices. The specific fields include specific fields defined for a particular type of target heterogeneous computing power device.

7. The method according to claim 6, characterized in that, The general fields include all XPU general fields and accelerator general fields; the all XPU general fields include device unique identifier, device type, architecture, manufacturer, model, driver version, firmware version, number of compute units, compute core utilization, real-time power consumption, current clock frequency, chip temperature, motherboard temperature, frequency limiting flag, frequency limiting reason, most recent error code, most recent error timestamp, sliding window average load percentage, acquisition timestamp, and sampling period; the accelerator general fields include total dedicated storage, used storage, storage utilization, PCIe receive throughput, PCIe transmit throughput, performance status, power limit, error-correctable error rate, error-uncorrectable error rate, device runtime, and device reset count.

8. The method according to claim 6, characterized in that, The unique fields include CPU-specific fields and GPU-specific fields; the CPU-specific fields include the number of active threads, context switching rate, L3 cache capacity, and I / O device utilization; the GPU-specific fields include fan speed, energy efficiency ratio, NV frequency limiting reason string, ECC error correction accumulation, ECC non-error correction accumulation, memory frequency, and core graphics frequency.

9. A heterogeneous computing power status data acquisition system for cloud-edge-device collaboration, characterized in that, The system includes: The data acquisition module is used to acquire the raw operating status data of the target heterogeneous computing power device; The standardization processing module is used to input the original operating status data into a preset XPU abstract data model so that the model can standardize the original operating status data to obtain standardized status data. An adaptive control module is used to dynamically determine the current sampling frequency corresponding to the standardized state data using an adaptive frequency conversion acquisition strategy; the adaptive frequency conversion acquisition strategy adjusts the sampling frequency based on the real-time assessment results of the operational risks of the heterogeneous computing power equipment. The status data acquisition module is used to acquire status data of the target heterogeneous computing power device according to the current sampling frequency, and obtain target status data that conforms to the XPU abstract data model.

10. An electronic device, characterized in that, It includes a processor and a memory, the memory storing a computer program, which, when executed by the processor, implements the heterogeneous computing power status data acquisition method for cloud-edge-device collaboration as described in any one of claims 1 to 8.

Images