Sensor data collection method of multi-board server and electronic device

Abstract

The application discloses a sensor data collection method of a multi-board server and electronic equipment, and relates to the technical field of server management. In order to solve the problems of untimely key sensor data acquisition and large communication and processing resource consumption, the baseboard management controller acquires sampling data of each sensor according to a basic collection frequency at the initial time, determines the current state of the corresponding sensor according to the current sampling data and the historical sampling data of each sensor, and updates the current collection frequency of the sensor to a preset hotspot collection frequency higher than the basic collection frequency when the current state of the sensor meets a preset hotspot condition, and acquires the sampling data of the sensor according to the preset hotspot collection frequency. Through timely acquisition of the data change of the key sensor, the current collection frequency of the sensor that does not meet the preset hotspot condition can still be maintained, and the resource consumption of inter-board communication and data processing is reduced.

Description

Technical Field

[0001] This application relates to the field of server management technology, and in particular to a sensor data acquisition method and electronic device for a multi-board server. Background Technology

[0002] Servers typically have multiple sensors on each board. Multi-board servers in related technologies usually use a Baseboard Management Controller (BMC) to poll all sensor data from each board at a fixed period to achieve system monitoring. However, all sensors use the same sampling period, making it impossible to distinguish between critical and non-critical sensors. This results in changes to important data not being captured in a timely manner, while many stable sensors are repeatedly sampled, leading to a continuous waste of communication links and processing resources. Furthermore, when the system experiences local anomalies or rapid fluctuations, due to the fixed sampling period, changes in critical sensor data may not be captured until after multiple sampling periods, causing alarm delays or untimely status awareness. The system cannot dynamically adjust the sampling frequency based on its operating status.

[0003] Therefore, how to improve the timeliness of acquiring key sensor data and reduce the consumption of communication and processing resources caused by repeated acquisition of stable sensors has become a problem that needs to be solved by those skilled in the art. Summary of the Invention

[0004] This application provides a sensor data acquisition method and electronic device for a multi-board server, which at least solves the problems of untimely acquisition of key sensor data and high consumption of communication and processing resources in related technologies.

[0005] This application provides a sensor data acquisition method for a multi-board server system. The multi-board server system includes a baseboard management controller, multiple boards, and multiple sensors disposed on each board. The method is applied to the baseboard management controller and includes: According to the current sampling frequency corresponding to each sensor, the current sampling data of each sensor is obtained; wherein, the initial sampling frequency of each sensor is the preset basic sampling frequency; For each sensor, determine the current state of the sensor based on the current sampling data and historical sampling data; If the current state of the sensor meets the preset hotspot condition and the current sampling frequency of the sensor is not the preset hotspot sampling frequency, the current sampling frequency of the sensor will be updated to the preset hotspot sampling frequency. The sensor's sampling data is acquired according to a preset hotspot acquisition frequency; where the preset hotspot acquisition frequency is higher than the basic acquisition frequency.

[0006] This application also provides a sensor data acquisition device for a multi-board server system. The multi-board server system includes a baseboard management controller, multiple boards, and multiple sensors disposed on each board. The device includes: The first acquisition module is used to acquire the current sampling data of each sensor according to the current acquisition frequency corresponding to each sensor; wherein the initial acquisition frequency of each sensor is a pre-set basic acquisition frequency; The determination module is used to determine the current state of each sensor based on its current and historical sampling data. The update module is used to update the current sampling frequency of the sensor to the preset hotspot sampling frequency when the current state of the sensor meets the preset hotspot conditions and the current sampling frequency of the sensor is not the preset hotspot sampling frequency. The second acquisition module is used to acquire sensor sampling data according to a preset hotspot acquisition frequency; wherein the preset hotspot acquisition frequency is higher than the basic acquisition frequency.

[0007] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the sensor data acquisition method of any of the above-described multi-board server systems.

[0008] This application also provides a computer-readable storage medium storing a computer program, wherein when the computer program is executed by a processor, it implements the steps of the sensor data acquisition method of any of the above-described multi-board server systems.

[0009] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the sensor data acquisition method for any of the above-described multi-board server systems.

[0010] As can be seen from the above technical solution, the beneficial effects of the present invention are as follows: The baseboard management controller in this application initially acquires sampling data from each sensor at a basic acquisition frequency. It then determines the current state of each sensor based on its current and historical sampling data. When a sensor's current state meets a preset hotspot condition, the controller updates the sensor's current acquisition frequency to a preset hotspot acquisition frequency higher than the basic acquisition frequency, and acquires the sensor's sampling data according to this preset hotspot acquisition frequency. This allows for increasing the data acquisition frequency of sensors whose operating states meet the preset hotspot condition, enabling more timely acquisition of data changes from those sensors. For sensors that do not meet the preset hotspot condition, their current acquisition frequency can be maintained, thus avoiding the need to uniformly increase the acquisition frequency of all sensors to improve the timeliness of data acquisition for some sensors, and reducing resource consumption for inter-board communication and data processing.

[0011] In addition, the present invention also provides a corresponding electronic device for the sensor data acquisition method of a multi-board server system, which has corresponding advantages. Attached Figure Description

[0012] To more clearly illustrate the embodiments of this application, the accompanying drawings used in the embodiments will be briefly introduced below. Obviously, the 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.

[0013] Figure 1 A flowchart illustrating a sensor data acquisition method for a multi-board server system provided in this application embodiment; Figure 2 A flowchart illustrating another sensor data acquisition method for a multi-board server system provided in this application embodiment; Figure 3 A flowchart illustrating the sensor acquisition frequency update provided in this application embodiment; Figure 4 A sensor query response flowchart is provided as an embodiment of this application; Figure 5 This is a structural diagram of a sensor data acquisition device for a multi-board server system provided in an embodiment of this application. Detailed Implementation

[0014] 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, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0015] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus 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 apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0016] With the rapid development of cloud computing and big data technologies, data centers, as key infrastructure supporting these technologies, are becoming increasingly larger and more complex. Data centers are not only hubs for information processing and storage but also powerful engines driving the development of modern information society. Furthermore, with the surge in data center workloads, ensuring high reliability, stability, and availability has become particularly crucial. Against this backdrop, the core out-of-band management unit of each server node in a data center, namely the baseboard management controller, plays a vital role.

[0017] As data center server architecture continues to evolve towards high density and multi-board form factors, a single server system often contains multiple universal base boards (UBBs). Each board integrates multiple hardware sensors to monitor operating status parameters such as temperature, voltage, current, and power consumption. This sensor data is an important basis for server health management, fault early warning, and remote operation and maintenance.

[0018] In current mainstream multi-board server architectures, a polling method based on Redfish (i.e., the Redfish interface) or the Intelligent Platform Management Interface (IPMI) protocol is typically used. The BMC of the compute node periodically obtains sensor data from each Micro Management Controller (MMC) or daughterboard BMC to achieve system monitoring and alarm functions. Each UBB board's MMC provides access to all sensor data of its board to the baseboard management controller via the standard Redfish interface. Redfish is an open standard developed by the Distributed Management Task Force (DMTF) and widely supported throughout the industry. Each board's micro management controller provides access to all sensor data of its board via the Redfish interface. However, with the increase in the number of sensors and the increasing demands for real-time data, the traditional fixed-period polling method has gradually revealed significant shortcomings, making it difficult to meet the monitoring needs of high-dynamic-load scenarios. Especially in scenarios such as sudden changes in GPU load, rapid increases in power consumption, or abnormal heat dissipation, some critical sensors require millisecond-level sampling capabilities. However, the traditional uniform periodic polling method cannot distinguish the importance of sensors, resulting in a lag in the update of critical data and affecting the system's rapid response capability.

[0019] Therefore, in multi-board server architecture, how to achieve differentiated and high real-time acquisition of key sensors while ensuring global data consistency, and further reduce cross-board communication overhead and system resource consumption, has become the core technical problem that needs to be solved in the current multi-board server system architecture design.

[0020] In relevant multi-board server system architectures, the mainstream BMC sensor acquisition solutions in the industry mainly include the following methods: One approach is a fixed-period full-data collection and polling scheme, one of the most widely used implementations. In this scheme, the compute node's BMC (Browser Control Center) uses standard interfaces such as Redfish or IPMI to sequentially request data from each UBB board or its corresponding MMC at fixed intervals, obtaining the entire sensor data set and performing unified caching and status updates locally. Subsequently, the compute node's BMC provides the aggregated data to the upper-level management system or monitoring platform for subsequent monitoring and alarm judgment. This scheme has a simple structure, clear logic, and good versatility and compatibility, making it suitable for small to medium-sized systems. However, in scenarios with multiple UBBs and high-density sensors, its shortcomings become apparent. Using a uniform sampling period for all sensors fails to reflect the differences in importance between different sensors. To meet the real-time requirements of key indicators, it is often necessary to increase the overall polling frequency, but this leads to a synchronous increase in the communication frequency of all UBB boards, significantly increasing network bandwidth usage and MMC processing pressure. With a large number of sensors, repeated full-data collection also causes significant redundant communication and parsing overhead, reducing overall system efficiency and increasing MMC processing pressure and system resource consumption.

[0021] Another approach is a priority-based differentiated polling scheme. To address the shortcomings of fixed-period schemes, some systems introduce sensor priority grouping, classifying sensors into high-priority and low-priority categories and configuring different polling periods for each. For example, critical sensors are polled every 1 second, while ordinary sensors are polled every 5 or 10 seconds. This scheme improves the update frequency of critical data to some extent, but it still has significant limitations. Priorities are typically statically configured during system initialization, lacking the ability to dynamically adjust based on operational status. Furthermore, the acquisition method still relies on full-set polling or grouped-set polling, failing to achieve fine-grained control over individual hotspot sensors. When system operational status changes, the sampling strategy cannot be quickly readjusted, resulting in response lag.

[0022] The aforementioned technical solutions have the following drawbacks: Regarding the default acquisition cycle, the BMC of the compute node typically adopts a uniform periodic full acquisition method, that is, polling all sensors at fixed time intervals to obtain data. Although this method can ensure the integrity of data coverage, it has obvious shortcomings. Using the same sampling cycle for sensor data of all UBB boards makes it impossible to distinguish between critical and non-critical sensors, resulting in changes in important data not being captured at a higher frequency; a large number of sensors with long-term stable states or slow changes are still repeatedly acquired, causing a continuous waste of communication links and processing resources. In addition, the fixed acquisition strategy cannot dynamically adjust the sampling granularity when the system is abnormal or the load changes, resulting in a lack of flexibility and real-time performance.

[0023] Regarding the response to sensor data changes, all sensors collect full data at a fixed cycle, making it impossible to differentiate processing for key sensor indicators such as temperature and voltage. When a local anomaly or rapid fluctuation occurs on a GPU node, due to the fixed sampling cycle, changes in key sensor data may not be captured until after multiple sampling cycles, leading to alarm delays or untimely status awareness. Furthermore, the related technology lacks the ability to identify and enhance the acquisition of key sensor data, and cannot dynamically increase the sampling frequency of key sensors based on the system's operating status.

[0024] Regarding data change detection, while the centralized management solution establishes a data aggregation function on the BMC side of the control unit, it lacks a specific change detection method during data processing. Each time the BMC acquires sensor data, regardless of whether the data has changed, it directly writes it to its internal data structure or maps it to the DBus (Desktop Bus) data bus. This approach generates numerous repetitive write operations when sensor data changes infrequently, increasing CPU usage and memory access frequency. Frequent writes to the DBus or other internal buses may also trigger unnecessary event notifications, causing misjudgments in upper-layer applications or frequent interface refreshes, resulting in data jitter. Furthermore, when the number of UBB boards is large, the repetitive data updates significantly increase system resource consumption.

[0025] In view of this, this application provides a sensor data acquisition method for a multi-board server system. For ease of understanding, the system implementation environment used in the technical solution of this application is described below: It should be noted that the multi-board server system may include a board management controller, multiple universal base boards (UBBs), and multiple sensors mounted on each UBB. Each UBB can be configured with a micro-management controller to provide data access capabilities to its sensors. The board management controller can communicate with each micro-management controller via a management network and perform unified collection and processing of sensor data from each board. In this embodiment, the management network is an internally isolated virtual local area network (VLAN).

[0026] In practical applications, the sensors installed on various general-purpose boards can include temperature sensors, voltage sensors, current sensors, and power consumption sensors, etc. To facilitate accurate sensor location in a multi-board environment, the board management controller can maintain sensor resource information. This sensor resource information can include board identifier, sensor identifier, sensor type, access address, data access resources, and message bus object path. The message bus can utilize a desktop bus (DBus) for inter-process communication. To enable those skilled in the art to better understand the present application, the following detailed description, in conjunction with the accompanying drawings and specific embodiments, further illustrates this application.

[0027] This application provides a sensor data acquisition method for a multi-board server system. The multi-board server system includes a baseboard management controller, multiple boards, and multiple sensors mounted on each board. Please refer to... Figure 1 The method includes the following steps S110 to S140.

[0028] S110: Obtain the current sampling data of each sensor according to the current sampling frequency corresponding to each sensor; wherein, the initial sampling frequency of each sensor is the preset basic sampling frequency.

[0029] It should be noted that, in this embodiment of the application, after the multi-board server system is started, the baseboard management controller assigns an initial current acquisition frequency to each sensor. This initial current acquisition frequency is the base acquisition frequency, which can be a pre-set fixed value, such as once every 5 seconds.

[0030] Understandably, in practical applications, the baseboard management controller periodically sends data acquisition requests to the MMC of each board according to the current acquisition frequency corresponding to each sensor, in order to obtain the current sampling data of each sensor. For example, for a temperature sensor, the current sampling data is the temperature value detected by the temperature sensor at the current moment; for a voltage sensor, the current sampling data is the voltage value detected by the voltage sensor at the current moment. During the initial operation of the system, the current acquisition frequency of all sensors is the aforementioned basic acquisition frequency, that is, the baseboard management controller acquires the sampling data of all sensors from each board at a uniform period.

[0031] S120: For each sensor, determine the current state of the sensor based on the current sampling data and historical sampling data.

[0032] It should be noted that after acquiring the current sampling data from each sensor, the baseboard management controller compares and analyzes the current sampling data of each sensor with its historical sampling data to determine the current state of the sensor. The current state of a sensor can reflect the degree of change and the level of anomaly risk in the sensor data. For example, the current state of a sensor can include a stable state, a normal fluctuation state, and an abnormally active state. For sensors in different states, different sampling frequencies will be used for subsequent data acquisition to achieve differentiated monitoring.

[0033] S130: When the current state of the sensor meets the preset hot spot conditions and the current sampling frequency of the sensor is not the preset hot spot sampling frequency, update the current sampling frequency of the sensor to the preset hot spot sampling frequency.

[0034] It is understood that, after determining the current state of a sensor, the baseboard management controller in this embodiment can further determine whether the current state of the sensor meets the preset hotspot conditions. The preset hotspot conditions are used to determine whether a sensor needs to be given priority attention and high-frequency acquisition. If the current state of the sensor meets the preset hotspot conditions, and the current acquisition frequency of the sensor is not yet the preset hotspot acquisition frequency, the baseboard management controller updates the current acquisition frequency of the target sensor to the preset hotspot acquisition frequency. If the current acquisition frequency of the sensor is already the preset hotspot acquisition frequency, there is no need to update it repeatedly to avoid unnecessary operations.

[0035] S140: Acquire sensor sampling data according to a preset hotspot acquisition frequency; wherein, the preset hotspot acquisition frequency is higher than the basic acquisition frequency.

[0036] It should be noted that, in this embodiment, after updating the sensor's current acquisition frequency to a preset hotspot acquisition frequency, the baseboard management controller acquires the sensor's sampling data according to the preset hotspot acquisition frequency. Since the preset hotspot acquisition frequency is higher than the basic acquisition frequency, the sensor's sampling data will be acquired at a higher frequency, thereby enabling more timely capture of the sensor's data changes. Furthermore, once a sensor is identified as a hotspot sensor, acquisition at the basic acquisition frequency can be stopped to avoid duplicate acquisition of the same sensor at different acquisition frequencies.

[0037] Therefore, in this embodiment, the baseboard management controller initially acquires sampling data from each sensor according to the basic acquisition frequency, and determines the current state of the corresponding sensor based on the current and historical sampling data. When the current state of a sensor meets the preset hotspot condition, the current acquisition frequency of that sensor is updated to a preset hotspot acquisition frequency higher than the basic acquisition frequency, and the sampling data of that sensor is acquired according to the preset hotspot acquisition frequency. Thus, the data acquisition frequency can be increased for sensors whose operating state meets the preset hotspot condition, allowing for more timely acquisition of data changes from those sensors. For sensors that do not meet the preset hotspot condition, their current acquisition frequency can still be maintained, thereby avoiding the need to uniformly increase the acquisition frequency of all sensors to improve the timeliness of data acquisition for some sensors, and reducing the resource consumption of inter-board communication and data processing.

[0038] To better understand the sensor data processing procedure after basic acquisition, please refer to... Figure 2 After acquiring all sensor data from each general-purpose board according to the basic acquisition frequency, the board management controller summarizes the acquired sensor data and compares the current sampled data of each sensor with the corresponding historical cached data. When the current sampled data and the historical cached data are inconsistent, the board management controller updates the corresponding historical cached data and updates the sensor attribute values ​​in the corresponding message bus object; when the current sampled data and the historical cached data are consistent, neither the historical cached data nor the message bus object is updated.

[0039] It should be noted that, Figure 2 The diagram illustrates the basic data acquisition, cache comparison, and message bus object update process. The process of acquiring directional data at a preset hotspot acquisition frequency after the sensor meets the preset hotspot conditions can be handled according to the corresponding embodiments below, and will not be elaborated further here.

[0040] In one embodiment, the process of determining the current state of the sensor based on the current sampling data and historical sampling data in S120 may include: S21: Determine the dynamic sampling weight of the sensor based on the magnitude and rate of change between the current sampled data and the historical sampled data, as well as the number of abnormal triggers. It should be noted that the substrate management controller in this embodiment establishes a behavior cache model for each sensor to record the sensor's historical sampling data. Upon acquiring the current sampling data of a sensor, the substrate management controller compares the current sampling data with the sensor's historical sampling data, calculating the amplitude of change, the rate of change, and the number of abnormal triggers. The amplitude of change characterizes the absolute change in the sensor value between two adjacent samples; the rate of change characterizes the average speed of change in the sensor value per unit time; and the number of abnormal triggers characterizes the number of times the sensor triggers an abnormal threshold within a preset time window. The substrate management controller calculates the sensor's dynamic sampling weight by weighting and combining these three factors: amplitude of change, rate of change, and number of abnormal triggers.

[0041] S22: Determine the current state of the sensor based on the sensor's dynamic sampling weights.

[0042] In practical applications, the baseboard management controller can determine the current state of the sensor based on the calculated dynamic sampling weight. A higher dynamic sampling weight indicates more drastic changes in the sensor data or a higher risk of anomalies, requiring closer monitoring. It is understood that the dynamic sampling weight in this embodiment can be used to classify the sensor into different state levels, such as a stable state, a normal fluctuation state, and an abnormally active state.

[0043] As can be seen, by introducing dynamic sampling weights in this embodiment, the operating status of the sensor is quantitatively evaluated, making the determination of the sensor status more objective and accurate, which is beneficial to subsequent differentiated acquisition decisions.

[0044] In one implementation, the process of determining the dynamic sampling weight of the sensor based on the magnitude and rate of change of the current sampling data and historical sampling data, as well as the number of abnormal triggers, may include: S211: Determine the magnitude of change based on the difference between the current sampled data and the historical sampled data of the sensor.

[0045] It is understood that the substrate management controller in this application embodiment can read the historical sampling data of the sensor's last sampling from the behavior cache model, including the last sampling value, obtain the current sampling value based on the current sampling data, and then use the absolute value of the difference between the current sampling value and the last sampling value as the change amplitude.

[0046] In practical applications, the sensor's change amplitude ΔValue can be obtained based on the relationship between the change amplitudes, where the relationship is: ΔValue = |CurrentValue – LastValue|; where CurrentValue represents the current sampled value and LastValue represents the previous sampled value.

[0047] S212: Determine the rate of change based on the magnitude of the change and the time difference between the current sampling time and the historical sampling time.

[0048] In other words, the substrate management controller reads the sensor’s last sampling time from the behavior cache model, obtains the current sampling time from the current sampling data, takes the difference between the current sampling time and the last sampling time as the time difference ΔTime, and then takes the ratio of the change amplitude to the time difference as the change rate.

[0049] In practical applications, the rate of change of the sensor can be obtained from the rate of change relationship, where the rate of change relationship is: ChangeRate = ΔValue / ΔTime, where ΔTime = CurrentTimestamp – LastTimestamp, ChangeRate represents the rate of change, ΔTime represents the time difference, CurrentTimestamp represents the current sampling time, and LastTimestamp represents the last sampling time.

[0050] S213: Determine the number of times an exception is triggered based on the exception records within a preset time range.

[0051] In this embodiment, the baseboard management controller can count the number of abnormal trigger records of the sensor within a preset time range (i.e., a preset time window) from the abnormal records in the behavior cache model, thereby determining the number of abnormal triggers. For example, it can count the number of times the sensor value exceeds a preset abnormal threshold in the last 10 samples.

[0052] S214: Determine the dynamic sampling weight of the sensor based on the magnitude of change, the rate of change, and the number of abnormal triggers.

[0053] Understandably, the baseboard management controller can calculate the dynamic sampling weight of the sensor by weighting the three factors—variable magnitude, variable rate, and number of abnormal triggers—based on a dynamic sampling weight calculation formula. The dynamic sampling weight calculation formula is as follows: Weight = a × ΔValue + b × ChangeRate + c × AbnormalCount, where AbnormalCount represents the number of abnormal triggers within a preset time range, 'a' is the weighting coefficient for the magnitude of change, 'b' is the weighting coefficient for the rate of change, and 'c' is the weighting coefficient for the number of abnormal triggers. The specific values ​​of a, b, and c can be initialized according to the project's focus dimensions. For example, a = 30%, b = 50%, and c = 20%, with the sum of the three being 1.

[0054] For example, suppose the GPU temperature sensor on a certain UBB board rises from 70°C to 78°C within 2 seconds, and exceeds the temperature threshold 3 times in the last 10 samples. Then: ΔValue = |78–70| = 8; ΔTime=2; ChangeRate = 8 / 2 = 4; AbnormalCount=3; Weight=30%×8+50%×4+20%×3=5; The above calculations show that the current weight of the GPU temperature sensor is 5.

[0055] By clarifying the specific calculation method of the dynamic sampling weight in this embodiment, the quantitative evaluation of the sensor state is operable and repeatable, which is beneficial for accurately identifying hotspot sensors that need to be focused on in practical applications.

[0056] In one implementation, the current state of the sensor includes a stable state, a normal fluctuation state, and an abnormally active state. The process of determining the current state of the sensor based on its dynamic sampling weights can include: S221: When the dynamic sampling weight is less than the first preset threshold, the sensor is determined to be in a stable state.

[0057] It should be noted that after calculating the dynamic sampling weight of the sensor, the baseboard management controller can compare the dynamic sampling weight with a preset threshold. When the dynamic sampling weight is less than the first preset threshold, it indicates that the sensor data is changing smoothly and has not triggered any anomalies, thus determining that the sensor is in a stable state. In a stable state, the sensor can maintain its current sampling frequency, and can even extend the sampling interval under certain conditions to reduce resource consumption.

[0058] S222: When the dynamic sampling weight is greater than or equal to the first preset threshold and less than the second preset threshold, the sensor is determined to be in a normal fluctuation state.

[0059] Understandably, when the dynamic sampling weight is determined to be greater than or equal to the first preset threshold and less than the second preset threshold through comparison, it indicates that the sensor exhibits a certain degree of fluctuation, but the risk is controllable. Therefore, the sensor is determined to be in a normal fluctuation state. In a normal fluctuation state, the sensor only needs to maintain a standard sampling frequency. In practical applications, this standard sampling frequency can be the base sampling frequency.

[0060] S223: When the dynamic sampling weight is greater than or equal to the second preset threshold, it is determined that the sensor is in an abnormally active state, wherein the second preset threshold is greater than the first preset threshold.

[0061] Furthermore, when it is determined that the dynamic sampling weight is greater than or equal to the second preset threshold, it indicates that the sensor data is changing drastically or frequently triggering anomalies. Therefore, it is determined that the sensor is in an abnormally active state, and this sensor is a key sensor that needs to be focused on.

[0062] For example, assuming the first preset threshold = 2 and the second preset threshold = 5, then when the dynamic sampling weight of a sensor is less than 2, the sensor is determined to be in a stable state; when the dynamic sampling weight of the sensor is greater than or equal to 2 and less than 5, the sensor is determined to be in a normal fluctuation state; and when the dynamic sampling weight of the sensor is greater than or equal to 5, the sensor is determined to be in an abnormally active state. The specific values ​​of the first preset threshold and the second preset threshold can be adjusted according to the actual application scenario, and this application does not limit them.

[0063] The initial state of each sensor can be set to a normal fluctuation state. A stable state corresponds to a 5-second sampling period, a normal fluctuation state corresponds to a 2-second sampling period, and an abnormally active state corresponds to a 500-millisecond sampling period. In one example, when the sensor's state changes from a normal fluctuation state to an abnormally active state, the target sensor's acquisition period is shortened from 2 seconds to 500 milliseconds, thus reducing the data acquisition interval of the target sensor to one-tenth of its original value. When the sensor is in a stable state, the board management controller can appropriately extend the sampling interval (e.g., extend the sampling period to 10 seconds) to reduce the inter-board communication load. The correspondence between dynamic sampling weights and sampling periods is shown in Table 1 below. Table 1. Correspondence between dynamic sampling weights and sampling periods

[0064] In this embodiment, by setting two preset thresholds, the sensor is divided into three different state levels, which realizes a fine division of the sensor's operating state and provides a clear basis for subsequent differentiated data acquisition.

[0065] In one implementation, the preset hotspot condition includes the sensor being in an abnormally active state.

[0066] It should be noted that when a sensor is identified as being in an abnormally active state, the board management controller determines that the sensor meets the preset hotspot conditions; that is, only sensors in an abnormally active state will be identified as hotspot sensors and require high-frequency data acquisition. For sensors in a stable state or with normal fluctuations, since their data changes are gradual or within an acceptable range, no additional attention is required, and their current acquisition frequency can be maintained.

[0067] In another implementation, when the sensor temperature exceeds a preset temperature threshold, it can be determined that the sensor meets a preset hotspot condition. The preset temperature threshold can be set according to the sensor type, device specifications, or heat dissipation requirements. Furthermore, after the sensor meets the preset hotspot condition, the process of updating the sensor's current sampling frequency to the preset hotspot sampling frequency and adding the sensor to the hotspot sampling set, as described above, will not be elaborated further here.

[0068] In this embodiment, by using an abnormally active state as a preset hotspot condition, the sensor's acquisition frequency can be increased when the sensor data changes significantly.

[0069] In one implementation, updating the sensor's current sampling frequency to a preset hotspot sampling frequency includes: Add the sensor to the hotspot acquisition set, and the sensors in the hotspot acquisition set are acquired at a preset hotspot acquisition frequency.

[0070] It should be noted that when the baseboard management controller determines that a certain sensor meets the preset hotspot conditions, it only updates the current sampling frequency of that sensor to the preset hotspot sampling frequency; for other sensors that do not meet the preset hotspot conditions, their respective current sampling frequencies are maintained. After the current sampling frequency of the target sensor is updated to the preset hotspot sampling frequency, the baseboard management controller acquires the sampling data of the target sensor according to the preset hotspot sampling frequency, instead of acquiring the sampling data of the target sensor according to the basic sampling frequency.

[0071] It is understood that, in this embodiment, when the baseboard management controller determines that a sensor meets the preset hotspot conditions and its current sampling frequency is not the preset hotspot sampling frequency, it adds the sensor to the hotspot sampling set. This hotspot sampling set is a high-priority sampling queue, and all sensors in this set are sampled at the preset hotspot sampling frequency. The baseboard management controller creates independent sampling tasks for the hotspot sampling set and periodically sends data acquisition requests to the boards containing each sensor in the set at the preset hotspot sampling frequency. Each entry in the hotspot sampling set in this embodiment may include a sensor identifier, the board identifier, the current sampling frequency, the most recent sampling time, and anomaly records. Sensors already in the hotspot sampling set do not need to be added back to the set.

[0072] For example, assuming a base acquisition frequency of once every 5 seconds and a preset hotspot acquisition frequency of once every 500 milliseconds, when a GPU temperature sensor is added to the hotspot acquisition set due to a rapid temperature rise, the board management controller will acquire the sensor's temperature data from the board containing the GPU temperature sensor at a frequency of once every 500 milliseconds. Furthermore, for sensors not added to the hotspot acquisition set, acquisition will still be performed at the base acquisition frequency (once every 5 seconds). This method achieves high-frequency acquisition of hotspot sensor data.

[0073] In this embodiment, the hotspot sensors are managed in a unified manner through a hotspot acquisition set, which facilitates the independent scheduling and high-frequency acquisition of the hotspot sensors by the baseboard management controller, thereby improving acquisition efficiency and management convenience.

[0074] In one embodiment, the method may further include: When the sensor meets the preset recovery conditions, the sensor's current sampling frequency is updated from the preset hotspot sampling frequency to the base sampling frequency; Alternatively, the sensor's current sampling frequency can be updated from the preset hotspot sampling frequency to a sampling frequency that corresponds to the sensor's current state.

[0075] It should be noted that this application provides two optional methods for the sensor to exit the hotspot acquisition mode. When a sensor is added to the hotspot acquisition set and acquired at a preset hotspot acquisition frequency, if the sensor's operating status gradually returns to normal, it needs to be exited from the high-frequency acquisition mode to release system resources.

[0076] The first approach is to directly restore the sensor to the base acquisition frequency. That is, when the sensor meets the preset recovery conditions, the baseboard management controller directly restores the sensor's current acquisition frequency from the preset hotspot acquisition frequency to the base acquisition frequency. This method is simple to implement and suitable for scenarios where the sensor's state has clearly returned to normal. In another implementation, when the sensor meets the preset recovery conditions, the baseboard management controller removes the sensor from the hotspot acquisition set and restores the sensor's current acquisition frequency from the preset hotspot acquisition frequency to the base acquisition frequency. This way, the sensor can resume using the base acquisition frequency after the hotspot state is eliminated, and it no longer occupies the resources of the hotspot acquisition set.

[0077] The second approach is to adjust the sampling frequency to correspond to the current state. That is, when the sensor meets the preset recovery conditions, the baseboard management controller recalculates the sensor's dynamic sampling weights to determine the sensor's current accurate state (stable state or normal fluctuation state), and then adjusts the sensor's sampling frequency to correspond to the current state. For example, when the sensor recovers from an abnormally active state to a normal fluctuation state, the sampling period can be adjusted from 500 milliseconds to two seconds; when the sensor recovers to a stable state, the sampling period can be adjusted to five seconds.

[0078] This application provides two exit methods, allowing the sensor to flexibly choose a recovery path according to actual needs when exiting the hotspot acquisition mode, which is beneficial for further optimizing system resource utilization.

[0079] In one implementation, the preset recovery conditions in this application embodiment may include: The dynamic sampling weight of the sensor is lower than the preset exit threshold in the sampling period corresponding to multiple consecutive preset hot spot acquisition frequencies, and no abnormality is triggered in multiple sampling periods; wherein, the preset exit threshold is less than or equal to the second preset threshold.

[0080] It should be noted that, in order to prevent the sensor from frequently switching between hot spot and normal states, this application embodiment introduces an exit hysteresis method. When the sensor is sampled at a preset hot spot sampling frequency, the substrate management controller continuously monitors the dynamic sampling weight of the sensor. Only when the dynamic sampling weight of the sensor is lower than the preset exit threshold for multiple consecutive sampling periods (e.g., M periods), and no abnormality is triggered within these sampling periods, does the substrate management controller determine that the sensor meets the preset recovery conditions.

[0081] For example, assuming a preset exit threshold of 3 and a continuous sampling period M of 5, if a hotspot sensor has a dynamic sampling weight of less than 3 in each of 5 consecutive sampling periods (i.e., 5 high-frequency acquisitions), and no anomaly is triggered in any of these 5 acquisitions, the baseboard management controller determines that the sensor meets the preset recovery condition and removes the sensor from the hotspot acquisition set. The preset exit threshold is less than or equal to a second preset threshold (i.e., the threshold for entering an abnormally active state). For example, when the second preset threshold is 5, the exit threshold can be set to 3 or 4.

[0082] M is a pre-set positive integer. The specific value of M can be set according to the sampling period and the expected recovery time. This will not be described in detail in the embodiments of this application.

[0083] In this embodiment, by introducing an exit hysteresis method (i.e., the entry threshold is higher than the exit threshold), the sensor can be effectively prevented from repeatedly entering and exiting the hot spot collection set near the threshold, thus avoiding unnecessary fluctuations in system resources and improving system stability.

[0084] It should also be noted that during the process of the sensor collecting data at the preset hotspot collection frequency, the baseboard management controller continuously acquires the sensor's sampling data and determines the dynamic sampling weight based on the sampling data. When the sampling period corresponding to multiple consecutive preset hotspot collection frequencies meets the above-mentioned preset recovery conditions, the current collection frequency can be restored to the base collection frequency or updated to the collection frequency corresponding to the current state, as described above. This will not be elaborated further here.

[0085] Additionally, to better understand the update process of the sensor's current sampling frequency, please refer to... Figure 3 The initial acquisition frequency of each sensor is the base acquisition frequency. When the baseboard management controller determines that the current state of a sensor meets the preset hotspot conditions and the current acquisition frequency is not the preset hotspot acquisition frequency, it updates the current acquisition frequency of the sensor to the preset hotspot acquisition frequency and adds the sensor to the hotspot acquisition set. Subsequently, the baseboard management controller acquires the sampling data of the sensor according to the preset hotspot acquisition frequency. When the sensor meets the preset recovery conditions, the baseboard management controller removes the sensor from the hotspot acquisition set and restores the current acquisition frequency of the sensor to the base acquisition frequency, or updates it to the acquisition frequency corresponding to the current state of the sensor.

[0086] In one embodiment, the method may further include: S31: Maintain historical cache data for each sensor.

[0087] It should be noted that the substrate management controller in this embodiment can also maintain a copy of historical cache data for each sensor locally to store the sensor’s most recent sampling value. The historical cache data can be stored in the memory of the substrate management controller for fast reading and writing.

[0088] For example, the baseboard management controller establishes an independent behavior cache model for each sensor on each UBB board to record the sensor's most recent N sampling history data. The structure of this sensor data behavior cache model is as follows: SensorState:{ CurrentValue, / / Current sampled value; LastValue, / / The last sampled value; LastTimestamp, / / last sampling time; DeltaHistory[], / / The magnitude of change in the most recent N sample values; AbnormalHistory[], / / The most recent N outlier records; CurrentPollingInterval / / Current sensor sampling period; }; SensorIndex: SensorState; In other words, the sensor state includes: the current sampled value (CurrentValue), the last sampled value (LastValue), the last sampled time (LastTimestamp), the record of the magnitude of change of the last N sampled values ​​(DeltaHistory[]), the record of the last N abnormal values ​​(AbnormalHistory[]), and the current sensor sampling period (CurrentPollingInterval). In practical applications, the substrate management controller can obtain the behavior cache model of the sensor through the sensor's unique index value (SensorIndex).

[0089] Wherein, N is the preset historical data window length, and its value needs to take into account both system memory overhead and statistical significance of weight calculation. Preferably, the value of N ranges from 10 to 30. In one embodiment, N can be set to 15, that is, the system retains the change amplitude data and anomaly records of the most recent 15 samples for each sensor, which are used to calculate its dynamic weight and change trend.

[0090] S32: Compare the acquired current sampling data with the historical cache data of the corresponding sensor.

[0091] It should be noted that whenever the baseboard management controller obtains the current sampling data of a sensor from the board, it does not immediately write it to the cache. Instead, it first compares the current sampling data with the historical cache data of the sensor in the local cache.

[0092] S33: When the current sampled data is inconsistent with the corresponding historical cached data, update the corresponding historical cached data using the current sampled data.

[0093] Understandably, if the current sampled data is inconsistent with the historical cached data (e.g., the values ​​are different), it indicates that the state of the sensor has changed. In this case, the board management controller uses the current sampled data to update the corresponding historical cached data. If the current sampled data is consistent with the historical cached data (e.g., the values ​​are the same), it indicates that the state of the sensor has not changed. In this case, the board management controller abandons the update operation and does not perform any write operation on the historical cached data.

[0094] When the sensor's current sampling data is acquired for the first time, since the sensor's historical cache data is empty, the board management controller writes the first acquired current sampling data into the sensor's historical cache data as a comparison benchmark for subsequent change detection.

[0095] The above method can effectively reduce invalid write operations and memory access frequency. Especially when a large number of sensors are stable for a long time, the baseboard management controller only needs to perform a comparison operation once after each data acquisition, and can skip the subsequent update steps, thereby significantly reducing system resource consumption.

[0096] In this embodiment, by introducing a change detection method, cache updates are only performed when data changes, which effectively reduces invalid write operations, lowers CPU and memory access frequency, avoids data jitter, and improves the overall stability and data quality of the system.

[0097] In one implementation, when the current sampled data is inconsistent with the corresponding historical cached data, the corresponding historical cached data is updated using the current sampled data. This process may include: If the difference between the current sampled data and the corresponding historical cached data is greater than a preset change threshold, it is determined that the current sampled data and the corresponding historical cached data are inconsistent. Update the corresponding historical cache data using the current sampled data.

[0098] It should be noted that, considering the potential for minor measurement errors or numerical fluctuations in sensor sampling values ​​(e.g., temperature values ​​fluctuating between 70.0℃ and 70.1℃), triggering cache updates for every minor numerical change would still result in numerous invalid write operations. To further optimize the change detection method, this embodiment can pre-set a preset change threshold. When the substrate management controller compares the current sampled data with historical cached data, it calculates the difference between the two. If the difference is greater than the preset change threshold, it is determined that the current sampled data and the historical cached data are inconsistent.

[0099] Furthermore, after determining that the current sampled data is inconsistent with the historical cached data, the baseboard management controller can use the current sampled data to update the corresponding historical cached data.

[0100] For example, suppose the temperature value stored in the historical cache data is 70.0℃, the current sampled data is 70.1℃, and the preset change threshold is 0.5℃. Since the difference is 0.1℃, which is less than 0.5℃, the substrate management controller determines that the two are consistent and does not update the historical cache data. Only when the temperature change exceeds 0.5℃ (for example, from 70.0℃ to 70.8℃) will the cache update be triggered.

[0101] In practical applications, the specific value of the preset change threshold can be set according to the sensor type. For example, temperature sensors, voltage sensors, and power consumption sensors can each be set with different preset change thresholds to adapt to the numerical range and normal fluctuations of different sensors.

[0102] In this embodiment, by introducing a preset change threshold, minute fluctuations in sensor sample values ​​can be filtered out, further reducing invalid cache update operations and optimizing system resource utilization.

[0103] In one implementation, the method further includes: When the current sampled data is inconsistent with the corresponding historical cached data, the message bus object corresponding to the sensor is determined based on the board identifier and sensor identifier of the board where the sensor is located. Update the sensor attribute values ​​in the message bus object using the current sampled data.

[0104] It is understood that the baseboard management controller in this embodiment maintains a standardized message bus DBus object path for uniformly presenting sensor data externally. Each board maintains a DBus bus name, and each bus name maintains the sensor data of that board. When the baseboard management controller determines that the current sampled data of a sensor is inconsistent with the historical cached data through change detection, it needs to synchronize the updated data to DBus. The baseboard management controller first determines the DBus object path corresponding to the sensor based on the board identifier of the board where the sensor is located and the sensor identifier of the sensor. The board identifier is used to uniquely identify a board (e.g., UBB0, UBB1, etc.), and the sensor identifier is used to uniquely identify a sensor on a board (e.g., gpu0_temp0).

[0105] Furthermore, after determining the message bus object, the baseboard management controller updates the sensor attribute values ​​in the message bus object using the current sampled data.

[0106] For example, the bus name corresponding to the board with the board identifier UBB0 is: xyz.openbmc_project.UBB0; The object path corresponding to the sensor identified as gpu0_temp0 is: / xyz / openbmc_project / sensors / temperature / gpu0_temp0; The interface name is: xyz.openbmc_project.Sensor.Value; The attribute name is: Value; The attribute type is: double.

[0107] In practical applications, after the baseboard management controller determines the message bus object according to the above path, it updates the sensor attribute values ​​in the message bus object using the current sampled data.

[0108] This application embodiment achieves standardized external presentation of sensor data by synchronizing the changed sensor data to the message bus, making it easier for upper-layer applications to obtain sensor data through a unified interface.

[0109] In one embodiment, the method may further include: Receive sensor query requests sent by the client; Based on the sensor query request, read the sensor attribute values ​​from the message bus object; The read sensor attribute values ​​are returned to the client; however, when responding to a sensor query request, sensor sampling data is not obtained from any board.

[0110] It should be noted that when a client (such as an upper-level management system or monitoring platform) accesses the head unit's BMC, it can send a sensor query request to the baseboard management controller via the Redfish interface or the IPMI SDR command. Upon receiving the query request, the baseboard management controller directly reads the corresponding sensor attribute values ​​from its local DBus object based on the sensor information specified in the query request. Since the latest data from all sensors has already been stored locally in the DBus through the aforementioned acquisition and update process, the baseboard management controller does not need to send data acquisition requests to any board.

[0111] After reading the sensor attribute value, the baseboard management controller returns the sensor attribute value to the client. Throughout the entire response process, the baseboard management controller does not need to obtain the sensor sampling data from the MMC of any board. The access latency depends only on the local data reading time and does not involve inter-board communication.

[0112] For example, in the Redfish access scenario, after receiving a Redfish request from the client, the board management controller directly reads the sensor data from its local DBus, encapsulates the sensor data into JSON (JavaScript Object Notation) format according to the Redfish specification, and returns it to the client. At this point, the UBB board's MMC is no longer accessed, and the access latency depends only on the local data read time. In the IPMI access scenario, the board management controller converts the sensor data from the DBus into the corresponding Sensor Data Record (SDR) format and returns it. Since the data is already cached locally, the IPMI access process also does not trigger inter-board communication. Throughout the entire data interaction process, the board's MMC is not visible to the client, and the client does not need to know the number of boards or their internal structure.

[0113] Understandably, to facilitate understanding of the process of a client querying sensor data, please refer to... Figure 4 The client can send sensor query requests to the baseboard management controller via the Redfish interface or the Intelligent Platform Management Interface (IPMI). After receiving the sensor query request, the baseboard management controller reads the sensor attribute values ​​of the corresponding sensor from the message bus object, without obtaining sensor sampling data from any board during the entire response process. For sensor query requests sent via the Redfish interface, the baseboard management controller encapsulates the read sensor attribute values ​​according to the Redfish specification and returns a Redfish response. For sensor query requests sent via the Intelligent Platform Management Interface (IPMI), the baseboard management controller converts the read sensor attribute values ​​into a sensor data record format and returns an IPMI response.

[0114] In this embodiment, sensor data is read directly from the local DBus to respond to client queries, eliminating the need to trigger inter-board communication and significantly reducing query latency and system resource consumption.

[0115] In one implementation, after updating the sensor attribute values ​​in the message bus object using the current sampled data, the method may further include: The message bus object sends notifications of changes in sensor attribute values ​​so that applications subscribing to the message bus object can obtain the updated sensor attribute values.

[0116] It should be noted that DBus can automatically trigger a signal notification after receiving a property change. That is, when the baseboard management controller updates the sensor property value in the message bus object using the current sampled data, the message bus object will automatically send a property value change notification (PropertiesChanged signal). Upper-layer applications that have subscribed to the message bus object can receive this change notification through subscription, thereby passively sensing the data change of the sensor without actively polling.

[0117] When the current sampled data is consistent with the historical cached data, the corresponding message bus object is not updated, and sensor attribute value change notifications are not sent. In this embodiment, following the above method can avoid repeated notifications triggered by unchanged data.

[0118] For example, when the temperature value of the GPU temperature sensor is updated from 70°C to 78°C, the corresponding DBus object automatically sends a PropertiesChanged signal after the property value is updated. When the upper-layer monitoring application that has subscribed to the DBus object receives the signal, it can know that the GPU temperature has changed and can take corresponding measures (such as alarms, fan speed adjustment, etc.).

[0119] In this embodiment, the automatic notification method of the message bus object enables the proactive push of sensor data changes. The upper-layer application can perceive data changes in real time without polling, thus improving the system's response efficiency.

[0120] In one embodiment, the process of acquiring sensor sampling data according to a preset hotspot acquisition frequency in step S140 may include: Based on the board identifier of the board where the sensor is located and the sensor identifier, determine the data access resources corresponding to the sensor; Send a data acquisition request for data access resources to the board where the sensor is located; Receive the sensor sampling data returned by the board where the sensor is located.

[0121] It should be noted that when the baseboard management controller needs to acquire sampling data from a certain sensor according to a preset hotspot acquisition frequency, it uses a precise query method instead of acquiring all data and then parsing it. Understandably, the baseboard management controller first determines the data access resource corresponding to the sensor based on the board identifier and sensor identifier of the board where the sensor is located. This data access resource may include the sensor's Uniform Resource Identifier (URI) or resource path in the Redfish protocol.

[0122] Furthermore, the baseboard management controller sends a Redfish GET request for the data access resource to the MMC of the board where the sensor is located. The request carries a specific resource path. After receiving the request, the MMC only needs to read the current value of the specific sensor from the local cache or hardware register and return it. The baseboard management controller receives the sampling data of the sensor returned by the MMC.

[0123] The method provided in this application embodiment reduces the data packet size and MMC processing overhead for each interaction, enabling incremental data acquisition. This application embodiment employs a precise directional data acquisition method for hotspot sensors, acquiring data from only a single sensor at a time, avoiding data redundancy and communication overhead caused by full data acquisition, and improving communication efficiency in high-frequency acquisition scenarios.

[0124] In one implementation, the board management controller can obtain the management address and sensor resource information of the board management controller during the initialization phase, and update the sensor resource information when a board is added, replaced, or when the sensor resources change.

[0125] In practical applications, the basic acquisition frequency, preset hotspot acquisition frequency, first preset threshold, second preset threshold, preset exit threshold, preset change threshold, preset time range, and number of continuous sampling cycles involved in the embodiments of this application can all be pre-configured by the baseboard management controller, and different sensor types can correspond to different configuration parameters.

[0126] It should also be noted that, in addition to numerical data, the current sampled data may also include health status, fault identifiers, or alarm identifiers. When the health status, fault identifiers, or alarm identifiers change, it can be determined that the current sampled data is inconsistent with the historical cached data, and the cached data and message bus object can be updated in accordance with the methods of Embodiments 9 to 13.

[0127] Furthermore, the substrate management controller in this embodiment introduces a local cache comparison at the data processing layer to perform difference analysis on new and old sensor data, triggering subsequent update and mapping operations only when the data changes. Finally, the DBus data mapping module uniformly converts multi-source sensor data into a standardized system data model and provides an access interface to the outside world.

[0128] Embodiments of this application also provide a sensor data acquisition device for a multi-board server system. The multi-board server system includes a baseboard management controller, multiple boards, and multiple sensors disposed on each board. Please refer to... Figure 5 The device is applied to the baseboard management controller and includes: The first acquisition module 11 is used to acquire the current sampling data of each sensor according to the current acquisition frequency corresponding to each sensor; wherein the initial acquisition frequency of each sensor is a preset basic acquisition frequency; The determination module 12 is used to determine the current state of each sensor based on the current sampling data and historical sampling data of the sensor. The update module 13 is used to update the current sampling frequency of the sensor to the preset hot spot sampling frequency when the current state of the sensor meets the preset hot spot conditions and the current sampling frequency of the sensor is not the preset hot spot sampling frequency. The second acquisition module 14 is used to acquire sensor sampling data according to a preset hotspot acquisition frequency; wherein the preset hotspot acquisition frequency is higher than the basic acquisition frequency.

[0129] In one implementation, the determining module includes: The first determining unit is used to determine the dynamic sampling weight of the sensor based on the change magnitude, change rate, and number of abnormal triggers between the current sampling data and historical sampling data of the sensor. The second determining unit is used to determine the current state of the sensor based on the sensor's dynamic sampling weights.

[0130] In one embodiment, the first determining unit includes: The first determining subunit is used to determine the magnitude of change based on the difference between the current sampled data and the historical sampled data of the sensor. The second determining subunit is used to determine the rate of change based on the magnitude of change and the time difference between the current sampling time and the historical sampling time. The third determining subunit is used to determine the number of times an exception is triggered based on the exception records within a preset time range; The fourth determination subunit is used to determine the dynamic sampling weight of the sensor based on the change amplitude, change rate, and number of abnormal triggers.

[0131] In one implementation, the current state of the sensor includes a stable state, a normal fluctuation state, and an abnormally active state. The second determining unit includes: The fifth determining subunit is used to determine that the sensor is in a stable state when the dynamic sampling weight is less than the first preset threshold. The sixth determining subunit is used to determine that the sensor is in a normal fluctuation state when the dynamic sampling weight is greater than or equal to the first preset threshold and less than the second preset threshold. The seventh determining subunit is used to determine that the sensor is in an abnormally active state when the dynamic sampling weight is greater than or equal to the second preset threshold, wherein the second preset threshold is greater than the first preset threshold.

[0132] In one implementation, the preset hotspot condition includes the sensor being in an abnormally active state.

[0133] In one implementation, the update module is specifically used for: Add the sensor to the hotspot acquisition set, and the sensors in the hotspot acquisition set are acquired at a preset hotspot acquisition frequency.

[0134] In one embodiment, the device may further include: The first update unit is used to update the sensor's current acquisition frequency from the preset hotspot acquisition frequency to the base acquisition frequency when the sensor meets the preset recovery conditions; or to update the sensor's current acquisition frequency from the preset hotspot acquisition frequency to the acquisition frequency corresponding to the sensor's current state.

[0135] In one implementation, the preset recovery conditions include: The dynamic sampling weight of the sensor is lower than the preset exit threshold in the sampling period corresponding to multiple consecutive preset hot spot acquisition frequencies, and no abnormality is triggered in multiple sampling periods; wherein, the preset exit threshold is less than or equal to the second preset threshold.

[0136] In one embodiment, the device may further include: A maintenance unit is used to maintain historical cached data for each sensor; The comparison unit is used to compare the acquired current sampled data with the historical cached data of the corresponding sensor; The second update unit is used to update the corresponding historical cache data using the current sampled data when the current sampled data is inconsistent with the corresponding historical cache data.

[0137] In one implementation, the second updating unit includes: The eighth determining subunit is used to determine that the current sampled data and the corresponding historical cached data are inconsistent when the difference between the current sampled data and the corresponding historical cached data is greater than a preset change threshold. The first update subunit is used to update the corresponding historical cache data using the current sampled data.

[0138] In one embodiment, the device may further include: The third determining unit is used to determine the message bus object corresponding to the sensor based on the board identifier and sensor identifier of the board where the sensor is located when the current sampled data is inconsistent with the corresponding historical cached data. The third update unit is used to update the sensor attribute values ​​in the message bus object using the current sampled data.

[0139] In one embodiment, the device may further include: The first receiving unit is used to receive sensor query requests sent by the client; The reading unit is used to read sensor attribute values ​​from the message bus object according to the sensor query request; The return unit is used to return the read sensor attribute values ​​to the client; however, when responding to a sensor query request, it does not obtain sensor sampling data from any board.

[0140] In one embodiment, the device may further include: The first sending unit is used to send sensor attribute value change notifications from the message bus object so that applications subscribing to the message bus object can obtain the updated sensor attribute values.

[0141] In one implementation, the second acquisition module includes: The fourth determining unit is used to determine the data access resources corresponding to the sensor based on the board identifier of the board where the sensor is located and the sensor identifier of the sensor. The second sending unit is used to send a data acquisition request for data access resources to the board where the sensor is located; The second receiving unit is used to receive the sensor sampling data returned by the board where the sensor is located.

[0142] It should be noted that the description of the features of the sensor data acquisition device of the multi-board server system in the embodiments of this application can be found in the relevant description of the sensor data acquisition method of the multi-board server system, and will not be repeated here.

[0143] Embodiments of this application also provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to run the computer program to perform the steps in any of the above embodiments of the sensor data acquisition method for a multi-board server system.

[0144] Embodiments of this application also provide a computer-readable storage medium storing a computer program, wherein the computer program is configured to execute the steps in any of the above embodiments of the sensor data acquisition method for a multi-board server system.

[0145] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0146] The embodiments of this application also provide a computer program product, which includes a computer program that, when executed by a processor, implements the steps in any of the above embodiments of the sensor data acquisition method for a multi-board server system.

[0147] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps in any of the above embodiments of the sensor data acquisition method for a multi-board server system.

[0148] Any of the components, modules, units, parts, methods, and operations described herein can be implemented using software, firmware, hardware (e.g., fixed logic circuitry), manual processing, or any combination thereof. Alternatively or additionally, any functionality described herein can be executed at least in part by one or more hardware logic components, such as, but not limited to, a central processing unit (CPU), a field-programmable gate array (FPGA), an application-specific integrated circuit (ASIC), an application-specific standard product (ASSP), a system-on-a-chip (SoC), a complex programmable logic device (CPLD), a microprocessor (MCU), etc. The terms "system," "computing device," or "apparatus" as used herein encompass various means, devices, and machines for processing data, including, for example, one or more programmable processors, computers, SoCs, or combinations thereof. The apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, a protocol stack, a database management system, an operating system, a cross-platform runtime environment, a virtual machine, or one or more combinations thereof. The aforementioned computer program (also known as a program, software, software application, app, script, or code) can be written in any form of programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as a standalone program or as a module, component, subroutine, object, or other unit suitable for a computing environment.

[0149] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are 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.

[0150] The foregoing has provided a detailed description of the sensor data acquisition method and electronic device for a multi-board server system provided in this application. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are merely for the purpose of helping to understand the method and its core ideas. It should be noted that those skilled in the art can make various improvements and modifications to this application without departing from its principles, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A sensor data acquisition method for a multi-board server system, characterized in that, The multi-board server system includes a baseboard management controller, multiple boards, and multiple sensors disposed on each of the boards. The method is applied to the baseboard management controller and includes: According to the current sampling frequency corresponding to each sensor, the current sampling data of each sensor is obtained; wherein, the initial sampling frequency of each sensor is a preset basic sampling frequency; For each sensor, the current state of the sensor is determined based on the current sampling data and historical sampling data of the sensor; When the current state of the sensor meets the preset hotspot condition and the current sampling frequency of the sensor is not the preset hotspot sampling frequency, the current sampling frequency of the sensor is updated to the preset hotspot sampling frequency. The sensor's sampling data is acquired according to the preset hotspot acquisition frequency; wherein the preset hotspot acquisition frequency is higher than the basic acquisition frequency.

2. The sensor data acquisition method for a multi-board server system according to claim 1, characterized in that, Based on the current sampling data and historical sampling data of the sensor, the current state of the sensor is determined, including: The dynamic sampling weight of the sensor is determined based on the magnitude and rate of change of the current sampling data and historical sampling data of the sensor, as well as the number of abnormal triggers. The current state of the sensor is determined based on the sensor's dynamic sampling weights.

3. The sensor data acquisition method for a multi-board server system according to claim 2, characterized in that, The dynamic sampling weight of the sensor is determined based on the magnitude, rate of change, and number of abnormal triggers between the current sampling data and historical sampling data of the sensor, including: determining the magnitude of change based on the difference between the current sampling data and historical sampling data of the sensor; The rate of change is determined based on the magnitude of the change and the time difference between the current sampling time and the historical sampling time. The number of times an exception is triggered is determined based on the exception records within a preset time range; The dynamic sampling weight of the sensor is determined based on the magnitude of the change, the rate of change, and the number of abnormal triggers.

4. The sensor data acquisition method for a multi-board server system according to claim 2, characterized in that, The current state of the sensor includes a stable state, a normal fluctuation state, and an abnormally active state; The current state of the sensor is determined based on its dynamic sampling weights, including: When the dynamic sampling weight is less than a first preset threshold, the sensor is determined to be in a stable state. When the dynamic sampling weight is greater than or equal to a first preset threshold and less than a second preset threshold, the sensor is determined to be in a normal fluctuation state. When the dynamic sampling weight is greater than or equal to the second preset threshold, the sensor is determined to be in an abnormally active state, wherein the second preset threshold is greater than the first preset threshold.

5. The sensor data acquisition method for a multi-board server system according to claim 4, characterized in that, The preset hotspot condition includes the sensor being in an abnormally active state.

6. The sensor data acquisition method for a multi-board server system according to claim 1, characterized in that, Updating the current sampling frequency of the sensor to the preset hotspot sampling frequency includes: The sensor is added to a hotspot acquisition set, and the sensors in the hotspot acquisition set are acquired at the preset hotspot acquisition frequency.

7. The sensor data acquisition method for a multi-board server system according to claim 4, characterized in that, Also includes: When the sensor meets the preset recovery conditions, the current sampling frequency of the sensor is updated from the preset hotspot sampling frequency to the basic sampling frequency; Alternatively, the current sampling frequency of the sensor can be updated from a preset hotspot sampling frequency to a sampling frequency corresponding to the current state of the sensor.

8. The sensor data acquisition method for a multi-board server system according to claim 7, characterized in that, The preset recovery conditions include: The sensor's dynamic sampling weight is lower than a preset exit threshold in multiple consecutive sampling periods corresponding to preset hotspot collection frequencies, and no abnormality is triggered in multiple sampling periods; wherein, the preset exit threshold is less than or equal to a second preset threshold.

9. The sensor data acquisition method for a multi-board server system according to any one of claims 1 to 8, characterized in that, Also includes: Maintain historical cache data for each of the aforementioned sensors; The acquired current sampling data is compared with the historical cache data of the corresponding sensor; When the current sampled data is inconsistent with the corresponding historical cached data, the corresponding historical cached data is updated using the current sampled data.

10. The sensor data acquisition method for a multi-board server system according to claim 9, characterized in that, When the current sampled data is inconsistent with the corresponding historical cached data, the corresponding historical cached data is updated using the current sampled data, including: When the difference between the current sampled data and the corresponding historical cached data is greater than a preset change threshold, it is determined that the current sampled data and the corresponding historical cached data are inconsistent. The corresponding historical cache data is updated using the current sampled data.

11. The sensor data acquisition method for a multi-board server system according to claim 9, characterized in that, Also includes: When the current sampled data is inconsistent with the corresponding historical cached data, the message bus object corresponding to the sensor is determined according to the board identifier and sensor identifier of the board where the sensor is located; Update the sensor attribute values ​​in the message bus object using the current sampled data.

12. The sensor data acquisition method for a multi-board server system according to claim 11, characterized in that, Also includes: Receive sensor query requests sent by the client; Based on the sensor query request, read the sensor attribute values ​​from the message bus object; The read sensor attribute values ​​are returned to the client; however, when responding to the sensor query request, sensor sampling data is not obtained from any board.

13. The sensor data acquisition method for a multi-board server system according to claim 11, characterized in that, After updating the sensor attribute values ​​in the message bus object using the current sampled data, the method further includes: The message bus object sends a notification of sensor attribute value changes so that applications subscribing to the message bus object can obtain the updated sensor attribute values.

14. The sensor data acquisition method for a multi-board server system according to claim 1, characterized in that, Acquiring the sensor's sampling data according to the preset hotspot acquisition frequency includes: Based on the board identifier of the board where the sensor is located and the sensor identifier of the sensor, determine the data access resources corresponding to the sensor; Send a data acquisition request for the data access resource to the board where the sensor is located; Receive the sampling data of the sensor returned by the board where the sensor is located.

15. An electronic device, characterized in that, include: Memory, used to store computer programs; A processor, configured to execute the computer program to implement the steps of the sensor data acquisition method for a multi-board server system as described in any one of claims 1 to 14.

Images