Display method and device of power value, storage medium, and electronic device

Abstract

The embodiment of the application provides a display method and device of an electric quantity value, a storage medium and an electronic device, wherein the method comprises the following steps: obtaining running data of a plurality of components of a server, and determining a health degree of each component according to the running data of the each component; determining a health degree of the server according to the health degree of the each component; controlling the USB Gadget driver to determine an electric quantity value of a battery device according to the health degree, and sending the electric quantity value to the server through the USB interface, so that the server displays the electric quantity value through a target icon, wherein the electric quantity value is used for indicating the health degree, and the USB Gadget driver is used for simulating the battery device.

Description

Technical Field

[0001] This application relates to the field of computers, and more specifically, to a method and apparatus for displaying battery levels, a storage medium, and an electronic device. Background Technology

[0002] With the rapid development of internet services, the demand for servers across various industries is gradually increasing, making the widespread application of servers inevitable. Servers typically operate for extended periods, and many of their peripherals, such as CPUs, memory, and hard drives, are also constantly powered on and running. Therefore, monitoring these peripherals and assessing the overall health of the server is a very meaningful task.

[0003] Server monitoring is typically handled by the Baseboard Management Controller (BMC) system. The BMC usually proactively reports alarm logs and provides a WebUI client software for users to actively query and view the server's operational status and the health of its various components. Using proactively reported alarm logs to determine server health is generally suitable for applications with a large number of servers. The WebUI also requires users to actively query the system and cannot provide real-time server status information.

[0004] Regarding the issue that related technologies require users to actively log in to client software such as WebUI to check server status, and there is a lack of a real-time, intuitive method for providing server health status prompts that does not require additional software environment, no effective solution has yet been proposed.

[0005] Therefore, it is necessary to improve the relevant technology to overcome the aforementioned defects. Summary of the Invention

[0006] This application provides a method and apparatus for displaying battery levels, a storage medium, and an electronic device, to at least address the problem in the related art of lacking a real-time, intuitive method for displaying server health status without requiring additional software.

[0007] According to one embodiment of this application, a method for displaying battery level is provided, comprising: a baseboard management controller applied to a server, the baseboard management controller being connected to the host of the server via a USB interface, wherein the baseboard management controller includes: a USB Gadget driver, comprising: acquiring operating data of multiple components of the server, and determining the health status of each component based on the operating data of each component; determining the health status of the server based on the health status of each component; controlling the USB Gadget driver to determine the battery level of a battery device based on the health status, and sending the battery level to the server via the USB interface, so that the server displays the battery level through a target icon, wherein the battery level is used to indicate the health status, and the USB Gadget driver is used to simulate the battery device.

[0008] In one exemplary embodiment, controlling the USB Gadget driver to determine the battery level of a battery device based on the health status includes: determining a mapping relationship between the health status and the battery level; and controlling the USB Gadget driver to map the health status to the battery level based on the mapping relationship.

[0009] In one exemplary embodiment, before acquiring the operating data of multiple components of the server, the method further includes: configuring a device descriptor for the battery device in the framework of the USB Gadget driver, wherein the device descriptor for the battery device includes a description of the battery function; and, when the baseboard management controller and the host of the server are connected via a USB interface, sending the device descriptor for the battery device to the server via the USB interface, so that the server loads the target icon corresponding to the battery device according to the device descriptor.

[0010] In one exemplary embodiment, determining the health of the server based on the health of each component includes: determining a weight value for each component; and determining the health of the server based on the weight value and the health of each component.

[0011] In one exemplary embodiment, determining the weight value of each component includes at least one of the following: determining the weight value of each component based on the hardware configuration of the server; determining the weight value of each component based on the application scenario of the server; or determining the weight value of each component based on the operating status of each component.

[0012] In an exemplary embodiment, when the plurality of components include a central processing unit (CPU), a hard disk, and memory, determining the health of each component based on the operating data of each component includes: determining a first duration for which the CPU's temperature is greater than a first temperature threshold, and determining a first percentage of the first duration to the CPU's operating time; determining a second duration for which the CPU's load utilization is greater than a load utilization threshold, and determining a second percentage of the second duration to the CPU's operating time; determining a first level for the number of alarm data for the CPU, and determining a second level for the operating time; and determining the health of the CPU based on the first percentage, the second percentage, the first level, and the second level.

[0013] Acquire monitoring data of the hard drive and determine the matching degree between the monitoring data and standard monitoring data; determine the third level of the hard drive's read / write speed, the fourth level of the hard drive's usage time, and the fifth level of the number of alarm data of the hard drive; determine the health of the hard drive based on the matching degree, the third level, the fourth level, and the fifth level.

[0014] A third duration during which the temperature of the memory exceeds a second temperature threshold is determined, and a third proportion of the third duration to the memory's runtime is determined; the error rate and usage frequency of the memory are determined; and the health of the memory is determined based on the third proportion, the error rate, and the usage frequency.

[0015] In one exemplary embodiment, obtaining operational data of multiple components of the server includes at least one of the following: obtaining operational data of the server's central processing unit via the PECI interface; obtaining operational data of the server's hard disk and memory via the I2C interface; parsing IPM I commands via the KCS interface to obtain alarm data reported by the server, and determining operational data of multiple components of the server based on the alarm data.

[0016] According to another embodiment of this application, a power value display device is provided, comprising: a first determining module, configured to acquire operating data of multiple components of the server, and determine the health status of each component based on the operating data of each component; a second determining module, configured to determine the health status of the server based on the health status of each component; and a control module, configured to control a USB Gadget driver to determine the power value of a battery device based on the health status, and send the power value to the server through the USB interface, so that the server displays the power value through a target icon, wherein the power value is used to indicate the health status, and the USB Gadget driver is used to simulate the battery device.

[0017] According to yet another embodiment of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, and the computer program is configured to perform the steps in any of the above method embodiments when it is run.

[0018] According to yet another embodiment of this application, an electronic device is also provided, 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 method embodiments.

[0019] According to yet another embodiment of this application, a computer program product is also provided, including a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0020] This application obtains operational data from multiple components of the server and determines the health of each component based on its operational data. The health of the server is then determined based on the health of each component. The USB Gadget driver is controlled to determine the battery level of the device based on the health level and sends the battery level to the server via the USB interface. The server then displays the battery level via a target icon, where the battery level indicates the health status, and the USB Gadget driver simulates the battery device. In other words, in this embodiment, the health of each component is calculated based on its data, and the total health of the server is calculated. The USB Gadget driver enumerates the battery function, allowing the server to intuitively display the battery level via a target icon, thus reflecting the server's health status. Therefore, this solves the problem of lacking a real-time, intuitive server health indicator method that requires no additional software environment. Attached Figure Description

[0021] Figure 1 This is a hardware structure block diagram of a server device for a method of displaying battery values ​​according to an embodiment of this application;

[0022] Figure 2 This is a flowchart of a method for displaying battery level according to an embodiment of this application;

[0023] Figure 3 This is a system block diagram of the BMC and host in related technologies;

[0024] Figure 4 This is an actual physical block diagram of a BMC system application that uses the USB Gadget battery function to indicate server health according to an embodiment of this application.

[0025] Figure 5 This is a software flowchart of the BMC data acquisition module according to an embodiment of this application;

[0026] Figure 6 This is a software flowchart of the BMC data analysis module according to an embodiment of this application;

[0027] Figure 7 This is a structural block diagram of a power value display device according to an embodiment of this application. Detailed Implementation

[0028] The embodiments of this application will be described in detail below with reference to the accompanying drawings and examples.

[0029] It should be noted that the terms "first," "second," etc., in the specification, claims, and drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence.

[0030] The methods and embodiments provided in this application can be executed on a server device or a similar computing device. Taking running on a server device as an example, Figure 1 This is a hardware structure block diagram of a server device for a method of displaying battery levels according to an embodiment of this application. For example... Figure 1 As shown, the server device may include one or more ( Figure 1 Only one is shown. A processor 102 (processor 102 may include, but is not limited to, a microprocessor MCU or a programmable logic device FPGA, etc.) and a memory 104 for storing data are also shown. The server device may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server equipment described above. For example, the server equipment may also include components that are more... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0031] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the power value display method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory, and may also include non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to server devices 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.

[0032] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the server device. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0033] This embodiment provides a method for displaying battery levels, applied to a server's baseboard management controller. The baseboard management controller is connected to the server's host via a USB interface. The baseboard management controller includes a USB Gadget driver. Figure 2 This is a flowchart of a method for displaying battery levels according to an embodiment of this application, such as... Figure 2 As shown, the process includes the following steps:

[0034] Step S202: Obtain the operating data of multiple components of the server, and determine the health of each component based on the operating data of each component;

[0035] Step S204: Determine the health status of the server based on the health status of each component;

[0036] Step S206: Control the USB Gadget driver to determine the battery level of the battery device based on the health status, and send the battery level to the server through the USB interface so that the server displays the battery level through a target icon. The battery level is used to indicate the health status, and the USB Gadget driver is used to simulate the battery device.

[0037] Through the above steps, the operating data of multiple components of the server is obtained, and the health of each component is determined based on the operating data of each component; the health of the server is determined based on the health of each component; the USB Gadget driver is controlled to determine the battery level value of the battery device based on the health level, and the battery level value is sent to the server through the USB interface, so that the server displays the battery level value through a target icon, wherein the battery level value is used to indicate the health level, and the USB Gadget driver is used to simulate the battery device. That is, in this embodiment of the application, the health level of each component is calculated based on the data of each component of the server, and the total health level of the server is calculated. The battery function is enumerated through the USB Gadget driver, so that the server can intuitively display the battery level value through a target icon, thereby reflecting the health status of the server. Therefore, the problem of lacking a real-time, intuitive server health level indication method without additional software environment can be solved.

[0038] Alternatively, to better understand step S206 above, step S206 can be implemented in the following way:

[0039] Determine the mapping relationship between the health status and the battery level; control the USB Gadget driver to map the health status to the battery level according to the mapping relationship.

[0040] This application embodiment transforms the abstract server health status into an intuitive battery level display, as detailed below:

[0041] First, it is necessary to define the assessment range for server health. For example, health might be a value from 0 to 100, where 0 indicates that the server is completely unhealthy and 100 indicates that the server is very healthy.

[0042] Define the range of battery capacity values ​​for a battery device. For example, the capacity value is usually from 0% to 100%, where 0% means the battery is depleted and 100% means the battery is fully charged.

[0043] Establishing a mapping relationship between health status and battery level is typically a linear or non-linear function, or a more complex non-linear relationship. This mapping relationship should ensure that a decrease in health status is proportional to a decrease in displayed battery level, allowing users to intuitively understand the server's health status.

[0044] The calculated health value is passed to the driver by calling the USB Gadget driver's interface (e.g., the ioctl interface), and the driver internally implements the mapping logic.

[0045] Through the above embodiments, the invention realizes real-time monitoring and intuitive display of server health, providing users with convenient maintenance and management methods. Especially in scenarios with a small number of servers, no additional software environment or active query operation is required, which greatly improves user experience and server management efficiency.

[0046] Optionally, before acquiring the operating data of multiple components of the server, the method further includes: configuring a device descriptor for the battery device in the framework of the USB Gadget driver, wherein the device descriptor for the battery device includes a description of the battery function; and, when the baseboard management controller and the host of the server are connected via a USB interface, sending the device descriptor for the battery device to the server via the USB interface, so that the server loads the target icon corresponding to the battery device according to the device descriptor.

[0047] It should be noted that the device descriptor configuration in the USB Gadget driver framework is crucial information used by the host to identify the device type, function, and configuration when a USB device communicates with the host. In this application, the configured battery device descriptor not only contains basic USB device information but also specifically includes a description of the battery function. By setting these descriptors in the USBGadget driver, it can be ensured that the device is correctly recognized by the host operating system as a general-purpose USB device with battery functionality.

[0048] When the BMC connects to the server's host via the USB interface, it actively sends a device descriptor to the host. This is the first step in establishing communication between the USB device and the host. With the correct device descriptor, the host can recognize that this is a battery-enabled device and prepare to receive subsequent power information.

[0049] Upon receiving the device descriptor, the server's host operating system loads the corresponding battery icon based on the information in the descriptor. This icon is typically displayed in the operating system's user interface. Regardless of the user's operating system (such as Windows, Linux, etc.), as long as the system supports the recognition and display of USB devices, the battery icon will be visible, providing the user with an intuitive way to understand the server's health status.

[0050] The embodiments of this application achieve the convenience of eliminating the need for users to actively query, thereby improving the efficiency of server management and user experience.

[0051] Optionally, determining the health of the server based on the health of each component includes: determining a weight value for each component; and determining the health of the server based on the weight value and the health of each component.

[0052] In this embodiment, the health status of various key components of the server is used as the basis, and different weight values ​​are assigned to these components to reflect their impact on the overall operating status of the server. Specifically:

[0053] This process identifies and quantifies the contribution or impact of different components within a server on its overall health. For example, components such as the CPU, memory, hard drive, and fans have varying degrees of influence on server stability and performance. Therefore, these components may be assigned different weight values ​​when assessing server health. By assigning a weight value to each component and combining these weight values ​​with the component's health score, the overall health of the server can be calculated.

[0054] The calculation method can be to multiply the health score of each component by its corresponding weight value, then add all the products together, and finally normalize the sum to obtain a health score within a specific range (such as 0 to 100).

[0055] For example, "Total health = (CPU health * CPU weight value + Hard disk health * Hard disk weight value + Memory health * Memory weight value + ...) / Total weight value".

[0056] This application provides a more comprehensive and refined server health assessment scheme, considering not only the health status of individual components but also their relative importance within the server, thus more accurately reflecting the server's actual operating condition. In practical applications, this method helps operations and maintenance personnel quickly locate problematic components and perform timely maintenance and upgrades to maintain high server availability and performance.

[0057] This application provides several methods for determining the weight value of each component, including at least one of the following:

[0058] 1) Determine the weight value of each component based on the hardware configuration of the server;

[0059] Different hardware components may have varying degrees of impact on overall server performance. For example, for a server configured with a high-performance CPU and ample memory, the health of the CPU and memory may have a greater impact on the overall health, while the health of the hard drives has a relatively lower weight. Conversely, if the server is primarily used for storage, then the health of the hard drives should have a higher weight. Evaluation Mechanism: The importance of hardware configuration can be automatically assessed by defining a set of rules. For example, if the number of CPU cores exceeds a certain threshold, the CPU health weight can be increased; if the total memory reaches a certain level, the memory health weight can be increased; for storage servers, if the number or capacity of hard drives reaches a certain level, the hard drive health weight can be increased.

[0060] 2) Determine the weight value of each component based on the application scenario of the server;

[0061] Different application scenarios have different requirements for server hardware. For example, for compute-intensive applications, CPU performance and health are particularly important; while for data-intensive applications, hard drive and network stability may be more critical. Scenario identification algorithm: Develop an algorithm to identify the server's primary application scenario. This can be achieved by analyzing metrics such as the type of software applications on the server, CPU and hard drive utilization, and network traffic. Once the application scenario is identified, the health weights of each component can be adjusted accordingly.

[0062] 3) Determine the weight value of each component based on its operating status;

[0063] During server operation, hardware usage changes over time. Therefore, a dynamic weight adjustment strategy should include real-time monitoring of hardware usage and dynamic adjustment of weights based on the current hardware load. Real-time monitoring system: The BMC can monitor the load and performance of various server components in real time, such as CPU utilization, hard drive read / write speed, and memory usage. If abnormal usage or performance indicators of a component are detected, its health weight can be temporarily increased to more accurately reflect the current health status of the server.

[0064] For example, suppose a server is configured with a high-performance CPU, large-capacity memory, and multiple hard drives, and its primary application is data analysis. Initially, the CPU weight can be set to 0.3, the memory weight to 0.4, and the hard drive weight to 0.3. During operation, if the CPU utilization consistently exceeds 80%, the CPU weight can be temporarily adjusted to 0.4 to more accurately reflect the server's health status under high computing load.

[0065] Dynamically adjusting the health weights of components such as CPU, hard drive, and memory requires consideration of server hardware configuration, application scenarios, real-time monitoring, and user feedback. By designing and implementing these strategies appropriately, the accuracy and usability of server health assessments can be improved, providing users with more precise server status information.

[0066] In an exemplary embodiment, when the plurality of components include a central processing unit (CPU), a hard disk, and memory, determining the health of each component based on the operating data of each component includes: determining a first duration for which the CPU's temperature is greater than a first temperature threshold, and determining a first percentage of the first duration to the CPU's operating time; determining a second duration for which the CPU's load utilization is greater than a load utilization threshold, and determining a second percentage of the second duration to the CPU's operating time; determining a first level for the number of alarm data for the CPU, and determining a second level for the operating time; and determining the health of the CPU based on the first percentage, the second percentage, the first level, and the second level.

[0067] In other words, the CPU health status is calculated as follows:

[0068] 1) Temperature monitoring: The normal operating temperature of a CPU is between 50-80℃. Exceeding this range may indicate overheating. A temperature threshold can be set, for example, exceeding 80℃ can trigger a warning. The percentage of time the CPU remains above the threshold can be calculated to assess its health.

[0069] 2) Load Monitoring: CPU load is usually measured by utilization. Prolonged high load may affect the lifespan of the CPU. A load threshold can be set, such as exceeding 80% as high load, and the percentage of high load duration relative to the total time can be calculated.

[0070] 3) Alarm data: CPU error reports, such as checksum errors, clock errors, etc. You can set an error number threshold; if the threshold is exceeded, the health status will be reduced.

[0071] 4) Running time: CPUs that run for a long time may face more wear and tear, and the degree of aging can be calculated by the total running time.

[0072] The above indicators are weighted according to their importance, and then a health score of 0 to 100 is calculated.

[0073] Acquire monitoring data of the hard drive and determine the matching degree between the monitoring data and standard monitoring data; determine the third level of the hard drive's read / write speed, the fourth level of the hard drive's usage time, and the fifth level of the number of alarm data of the hard drive; determine the health of the hard drive based on the matching degree, the third level, the fourth level, and the fifth level.

[0074] The monitoring data mentioned above can be SMART data. Hard drive SMART data contains various health information of the hard drive, such as error rate, number of remapped sectors, rotational time, etc.

[0075] In other words, the indicators that affect the health of a hard drive are:

[0076] 1) Monitor data and set thresholds for various indicators; if the threshold is exceeded, the health level will be reduced.

[0077] 2) Read / write speed: Monitor the hard drive's read / write speed, compare it with the standard speed, and set a speed drop threshold;

[0078] 3) Usage time: The usage time of the hard drive will also affect its health. Set a lifespan threshold, and exceeding it will affect the health.

[0079] 4) Alarm data: Hard drive error records, such as the number of bad sectors. A threshold can be set, and if it is exceeded, the health status will be reduced.

[0080] A third duration during which the temperature of the memory exceeds a second temperature threshold is determined, and a third proportion of the third duration to the memory's runtime is determined; the error rate and usage frequency of the memory are determined; and the health of the memory is determined based on the third proportion, the error rate, and the usage frequency.

[0081] In other words, the memory health status is calculated as follows:

[0082] 1) Error rate: Monitor memory error rate, including ECC check errors, and set error rate thresholds.

[0083] 2) Temperature monitoring: Memory also has a temperature threshold, and excessively high temperatures may lead to data loss or performance degradation.

[0084] 3) Usage frequency: High-frequency use will cause some wear and tear on the memory. You can calculate the usage frequency over a period of time and set a threshold.

[0085] Optionally, obtaining the operating data of multiple components of the server includes at least one of the following: obtaining the operating data of the server's central processing unit through the PECI interface; obtaining the operating data of the server's hard disk and memory through the I2C interface; parsing IPM I commands through the KCS interface to obtain alarm data reported by the server, and determining the operating data of multiple components of the server based on the alarm data.

[0086] It should be noted that PECI (Platform Environment Control Interface) is a high-efficiency, low-latency communication protocol primarily used for communication between the BMC and the CPU on the server. Through the PECI interface, the BMC can obtain key indicators such as CPU temperature, voltage, frequency, and power usage in real time. This data is crucial for assessing the CPU's operating status and health.

[0087] I2C (Inter-Integrated Circuit) is a bidirectional, two-wire serial bus protocol used for communication between microcontrollers and peripheral devices. In server environments, I2C can be used to monitor and manage various hardware devices, such as hard drives, memory, and power management modules. Through the I2C interface, the BMC can collect data such as hard drive temperature, RPM, and SMART status, as well as memory temperature, usage, and error count. This data is crucial for assessing the health of hard drives and memory and can help identify potential hardware failures.

[0088] Keyboard Controller Style (KCS) is a communication method defined in the Intelligent Platform Management Interface (IPMI) specification. It's used for simple polling communication between the Server Management Console (BMC) and the IPMI host. IPMI commands are typically used for remote server monitoring and management. By parsing these commands through the KCS interface, the BMC can obtain alarm data proactively reported by the server, including but not limited to system failures, resource exhaustion, overheating, and power anomalies. This alarm data provides immediate feedback on the overall health of the server, helping to quickly identify and locate problems, and is another important data source for server health assessment.

[0089] In this embodiment, the operating data of the central processing unit, hard disk, and memory, as well as the server alarm data obtained by the BMC through the PECI, I2C, and KCS interfaces, form the basis for a comprehensive assessment of the server's health status. The collection and analysis of this data helps users understand the server's status in real time and take timely measures to prevent or resolve potential problems.

[0090] To better understand the process of the above-mentioned method for displaying battery power, the implementation flow of the above-mentioned method for displaying battery power will be described below in conjunction with optional embodiments, but this is not intended to limit the technical solution of the embodiments of this application.

[0091] Related technologies utilize proactive log reporting from the BMC system, such as SNMP, SMTP, and Syslog, or monitoring system software developed by the BMC system developer for various components, allowing customers to proactively query server health via a WebUI or other client software. A system block diagram of the related technologies is attached. Figure 3 As shown.

[0092] Based on existing solutions, it is necessary to actively log in to the client UI software to query the server health status. Therefore, there is a lack of a real-time, intuitive method for displaying server health status without requiring additional software. This embodiment provides a method for displaying battery levels, applicable to applications such as... Figure 4 The system shown, Figure 4 The following is an actual physical block diagram of a BMC system application that uses the USB Gadget battery function to indicate server health according to an embodiment of this application:

[0093] The system in this application embodiment has three main implementation modules, including:

[0094] 1. USB Gadget driver for battery function enumeration and battery power setting module:

[0095] The BMC uses a USB Gadget driver to implement battery functionality via a USB interface with the host, allowing the host's OS to enumerate battery devices. The USB Gadget driver enumerates devices according to the standard USB protocol, so the battery devices enumerated under the host can be displayed correctly on any operating system.

[0096] Implement the function of setting battery level in the USB Gadget driver, so that the battery level can be displayed accordingly in the host's OS.

[0097] Implement the ioctl interface to provide an interface for the application layer data analysis module to set the battery level of the USB Gadget.

[0098] 2. BMC Real-time Data Acquisition Module for Host Components:

[0099] The detailed flowchart of the data acquisition module software is as follows: Figure 5 As shown, the details are as follows:

[0100] Step 1: BMC collects various data from the server CPU in real time through the PECI interface.

[0101] Step 2: BMC collects data on the server's fans, hard drives, etc. in real time via the I2C interface.

[0102] Step 3: The BMC parses the IPMI command through the KCS interface to obtain the alarm data actively reported by the server.

[0103] Step 4: Categorize and save the collected data to the BMC cache for use by the data analysis module.

[0104] 3. Host Component Data Analysis Module:

[0105] The detailed flowchart of the data analysis module software is as follows: Figure 6 As shown, the details are as follows:

[0106] Step 1: The data analysis module obtains data from various server components in real time from the collected data cache.

[0107] Step 2: Use the data from each component (CPU, hard drive, memory, IPMI) and their corresponding dedicated algorithms to calculate the health of each component.

[0108] Step 3: Calculate the server's overall health using a comprehensive algorithm based on the health scores of each component over a period of time. For example, the formula is as follows (the health score algorithm may differ for each component, and the percentage of total health score may also vary):

[0109] Total health = ((CPU health * 0.2 + Hard disk health * 0.5 + Memory health * 0.3) * 100)%;

[0110] Step 4: Use the interface provided by the USB Gadget driver to set the battery level based on the calculated total health.

[0111] This application proposes a method for a BMC (Browser Control Center) to use a USB Gadget driver to enumerate the battery function and indicate server health. The BMC system typically provides a USB Device hardware interface in its hardware connection with the host. This USB interface is usually used when the BMC uses keyboard, video, or mouse (KVM) ports and virtual media functions. This application uses this USB interface to enable the BMC to use a USB Gadget driver to enumerate the battery function. When the host detects a USB connection, it can enumerate and display a battery device through the USB interface within the host's operating system. A battery icon will then be visible in the operating system's (OS) UI. Simultaneously, the BMC monitors and analyzes data from various components of the host, calculates the server's health using a corresponding algorithm, and then sets the battery level enumerated by the USB Gadget driver to represent the server's health. Users can then determine the server's health level through the battery level in the OS's human-computer interaction interface (UI), and the OS's low battery warning alerts users of server problems, allowing them to take timely action.

[0112] Through the embodiments of this application, common battery devices can be enumerated under any operating system without relying on the operating system on the host side, saving users the trouble of installing other software environments; prompts can be proactively displayed on the user's operating system interface and alarm functions can be provided to avoid users logging into client software to query.

[0113] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods according to the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) and includes several instructions to cause a terminal device (which may be a mobile phone, computer, server, or network device, etc.) to execute the methods described in the various embodiments of this application.

[0114] This embodiment also provides a power level display device, which is used to implement the above embodiments and preferred embodiments; details already described will not be repeated. As used below, the term "module" can refer to a combination of software and / or hardware that implements a predetermined function. Although the device described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0115] Figure 7 This is a structural block diagram of a power value display device according to an embodiment of this application, such as... Figure 7 As shown, the device includes:

[0116] The first determining module 72 is used to acquire the operating data of multiple components of the server and determine the health of each component based on the operating data of each component;

[0117] The second determining module 74 is used to determine the health of the server based on the health of each component;

[0118] The control module 76 is used to control the USB Gadget driver to determine the battery level of the battery device based on the health status, and send the battery level to the server through the USB interface so that the server displays the battery level through a target icon. The battery level is used to indicate the health status, and the USB Gadget driver is used to simulate the battery device.

[0119] The aforementioned device acquires operational data from multiple components of the server and determines the health of each component based on its operational data. The health of the server is then determined based on the health of each component. The USB Gadget driver is controlled to determine the battery level based on the health level and sends the battery level to the server via the USB interface. The server then displays the battery level via a target icon, where the battery level indicates the health status, and the USB Gadget driver simulates the battery device. In this embodiment, the health of each component is calculated based on its data, and the total health of the server is calculated. The battery function is then enumerated using the USB Gadget driver, allowing the server to intuitively display the battery level via a target icon, thus reflecting the server's health status. Therefore, this addresses the lack of a real-time, intuitive server health indicator method that requires no additional software environment.

[0120] In one exemplary embodiment, the control module 76 is configured to determine the mapping relationship between the health status and the battery level; and to control the USB Gadget driver to map the health status to the battery level according to the mapping relationship.

[0121] In one exemplary embodiment, the above apparatus further includes: a configuration module, configured to configure a device descriptor of the battery device within the framework of the USB Gadget driver, wherein the device descriptor of the battery device includes: a description of the battery function; and, when the baseboard management controller and the host of the server are connected via a USB interface, to send the device descriptor of the battery device to the server via the USB interface, so that the server loads the target icon corresponding to the battery device according to the device descriptor.

[0122] In one exemplary embodiment, the second determining module 74 is configured to determine the weight value of each component; and determine the health of the server based on the weight value and the health of each component.

[0123] In one exemplary embodiment, the second determining module 74 is configured to perform at least one of the following: determining the weight value of each component based on the hardware configuration of the server; determining the weight value of each component based on the application scenario of the server; and determining the weight value of each component based on the operating state of each component.

[0124] In an exemplary embodiment, where the plurality of components include a central processing unit (CPU), a hard disk, and memory, a first determining module 72 is configured to: determine a first duration during which the CPU's temperature is greater than a first temperature threshold, and determine a first percentage of the first duration to the CPU's runtime; determine a second duration during which the CPU's load utilization is greater than a load utilization threshold, and determine a second percentage of the second duration to the CPU's runtime; determine a first level of the number of alarm data for the CPU, and determine a second level of the runtime; and determine the health status of the CPU based on the first percentage, the second percentage, the first level, and the second level.

[0125] Acquire monitoring data of the hard drive and determine the matching degree between the monitoring data and standard monitoring data; determine the third level of the hard drive's read / write speed, the fourth level of the hard drive's usage time, and the fifth level of the number of alarm data of the hard drive; determine the health of the hard drive based on the matching degree, the third level, the fourth level, and the fifth level.

[0126] A third duration during which the temperature of the memory exceeds a second temperature threshold is determined, and a third proportion of the third duration to the memory's runtime is determined; the error rate and usage frequency of the memory are determined; and the health of the memory is determined based on the third proportion, the error rate, and the usage frequency.

[0127] In one exemplary embodiment, the first determining module 72 is configured to perform at least one of the following: obtain the operating data of the central processing unit of the server through the PECI interface; obtain the operating data of the hard disk and memory of the server through the I2C interface; parse the IPM I command through the KCS interface to obtain alarm data reported by the server, and determine the operating data of multiple components of the server based on the alarm data.

[0128] It should be noted that the above modules can be implemented by software or hardware. For the latter, they can be implemented in the following ways, but are not limited to: all the above modules are located in the same processor; or, the above modules are located in different processors in any combination.

[0129] 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 method embodiments when run.

[0130] Optionally, in this embodiment, the storage medium may be configured to store program code for performing the following steps:

[0131] S1, Obtain the operating data of multiple components of the server, and determine the health of each component based on the operating data of each component;

[0132] S2, determine the health of the server based on the health of each component;

[0133] S3, control the USB Gadget driver to determine the battery level of the battery device based on the health status, and send the battery level to the server through the USB interface, so that the server displays the battery level through a target icon, wherein the battery level is used to indicate the health status, and the USB Gadget driver is used to simulate the battery device.

[0134] 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.

[0135] 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 method embodiments.

[0136] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0137] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0138] S1, Obtain the operating data of multiple components of the server, and determine the health of each component based on the operating data of each component;

[0139] S2, determine the health of the server based on the health of each component;

[0140] S3, control the USB Gadget driver to determine the battery level of the battery device based on the health status, and send the battery level to the server through the USB interface, so that the server displays the battery level through a target icon, wherein the battery level is used to indicate the health status, and the USB Gadget driver is used to simulate the battery device.

[0141] 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 method embodiments.

[0142] Embodiments of this application also provide another computer program product, including a non-volatile computer-readable storage medium storing a computer program that, when executed by a processor, implements the steps in any of the above method embodiments.

[0143] Embodiments of this application also provide a computer program that includes computer instructions stored in a computer-readable storage medium; a processor of a computer device reads the computer instructions from the computer-readable storage medium and executes the computer instructions, causing the computer device to perform the steps in any of the above method embodiments.

[0144] Optionally, in this embodiment, the processor can be configured to perform the following steps via a computer program:

[0145] S1, Obtain the operating data of multiple components of the server, and determine the health of each component based on the operating data of each component;

[0146] S2, determine the health of the server based on the health of each component;

[0147] S3, control the USB Gadget driver to determine the battery level of the battery device based on the health status, and send the battery level to the server through the USB interface, so that the server displays the battery level through a target icon, wherein the battery level is used to indicate the health status, and the USB Gadget driver is used to simulate the battery device.

[0148] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0149] Obviously, those skilled in the art should understand that the modules or steps of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0150] 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 this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A method for displaying battery level, characterized in that, A baseboard management controller for a server, the baseboard management controller being connected to the server host via a USB interface, wherein the baseboard management controller includes: a USBGadget driver, comprising: Obtain the operating data of multiple components of the server, and determine the health of each component based on the operating data of each component; The health of the server is determined based on the health status of each component; The USB Gadget driver determines the battery level of the battery device based on the health status and sends the battery level to the server via the USB interface, so that the server displays the battery level through a target icon. The battery level indicates the health status, and the USB Gadget driver simulates the battery device. Determining the health of the server based on the health of each component includes: determining the weight value of each component; and determining the health of the server based on the weight value and the health of each component. The determination of the weight value for each component includes at least one of the following: The weight value of each component is determined based on the hardware configuration of the server; The weight value of each component is determined based on the application scenario of the server; The weight value of each component is determined based on the operating status of each component.

2. The method according to claim 1, characterized in that, Controlling the USB Gadget driver to determine the battery level of the device based on the health status includes: Determine the mapping relationship between the health status and the battery level; The USB Gadget driver is controlled to map the health status to the battery level according to the mapping relationship.

3. The method according to claim 1, characterized in that, Before acquiring operational data from multiple components of the server, the method further includes: Configure the device descriptor of the battery device within the framework of the USB Gadget driver, wherein the device descriptor of the battery device includes: a description of the battery function; When the baseboard management controller and the server host are connected via a USB interface, the device descriptor of the battery device is sent to the server via the USB interface, so that the server loads the target icon corresponding to the battery device according to the device descriptor.

4. The method according to claim 1, characterized in that, In the case where the multiple components include a central processing unit, a hard disk, and memory, the health status of each component is determined based on the operating data of each component, including: Determine a first duration for which the temperature of the central processing unit is greater than a first temperature threshold, and determine a first percentage of the first duration to the running time of the central processing unit; Determine a second duration during which the load utilization of the central processing unit is greater than a load utilization threshold, and determine a second proportion of the second duration to the running time of the central processing unit; A first level is determined by the quantity of alarm data in the central processing unit, and a second level is determined by the runtime; The health status of the central processing unit is determined based on the first proportion, the second proportion, the first level, and the second level. Acquire monitoring data from the hard drive and determine the degree of matching between the monitoring data and standard monitoring data; The third level is determined by the read / write speed of the hard drive, the fourth level by the usage time of the hard drive, and the fifth level by the number of alarm data of the hard drive. The health of the hard drive is determined based on the matching degree, the third level, the fourth level, and the fifth level. Determine a third duration during which the temperature of the memory is greater than a second temperature threshold, and determine a third percentage of the third duration relative to the running time of the memory; Determine the error rate and usage frequency of the memory; The health of the memory is determined based on the third percentage, the error rate, and the usage frequency.

5. The method according to claim 1, characterized in that, Obtain operational data from multiple components of the server, including at least one of the following: The server's central processing unit's operating data is obtained through the PECI interface; The server's hard drive and memory operating data are obtained through the I2C interface; The IPMI commands are parsed through the KCS interface to obtain the alarm data reported by the server, and the operating data of multiple components of the server are determined based on the alarm data.

6. A power level display device, characterized in that, include: The first determining module is used to acquire the operating data of multiple components of the server and determine the health of each component based on the operating data of each component. The second determining module is used to determine the health of the server based on the health of each component; A control module is used to control the USB Gadget driver to determine the battery level of the battery device based on the health status, and send the battery level to the server through the USB interface, so that the server displays the battery level through a target icon, wherein the battery level is used to indicate the health status, and the USB Gadget driver is used to simulate the battery device; The second determining module is used to determine the weight value of each component; and to determine the health of the server based on the weight value and the health of each component. The second determining module is configured to perform at least one of the following: The weight value of each component is determined based on the hardware configuration of the server; The weight value of each component is determined based on the application scenario of the server; The weight value of each component is determined based on the operating status of each component.

7. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the method described in any one of claims 1 to 5.

8. An electronic device comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the steps of the method described in any one of claims 1 to 5.

Images