Method for acquiring and dynamically displaying hardware configuration information based on graphical user interface

Abstract

The invention relates to a method for acquiring and dynamically displaying hardware configuration information based on a graphical user interface, which comprises the following steps: generating and scheduling a task queue by responding to a hardware information query request initiated by a user on a GUI interface, calling an MCS system interface by utilizing a CLI command to acquire hardware configuration data, and generating a log event in an execution process; the event management module receives a hardware state change notice sent by the MCS system through Socket communication, generates an alarm event when an abnormality is detected, and adds the alarm event into an event queue; the front-end module obtains event data through a polling interface, the GUI dynamically updates display content according to the event data, and the hardware running state and abnormal information are visually displayed through color coding and a dynamic chart. The hardware state monitoring method and device can be applied to scenes such as servers and electronic equipment, and the real-time performance, the visualization degree and the user interaction experience of hardware state monitoring are improved.

Description

Technical Field

[0001] The present application relates to the technical field of computer system management and graphical user interface, and in particular to a method for acquiring and dynamically displaying hardware configuration information based on a graphical user interface. Background Art

[0002] Graphical user interfaces (GUIs), as an important interactive means of computer system management, are widely used in hardware status monitoring and system maintenance. With the exponential growth in the complexity of computer hardware, users are increasingly demanding the visualization, real-time, and intelligent presentation of system configuration information. In related technologies, a basic hardware information acquisition and display system has been constructed through the collaborative operation of command-line interfaces (CLIs), remote procedure calls (RPCs), and multi-controller systems (MCSs). Specifically, this technology covers the entire process from hardware data acquisition and information processing to graphical feedback, including key links such as operating system-level API calls, cross-platform development frameworks, task scheduling mechanisms, and event monitoring systems. The MCS system, as the core platform for storage and control, undertakes important functions such as hardware status query, anomaly detection, and data encapsulation, providing basic support for system maintenance and fault diagnosis.

[0003] However, existing methods for acquiring and displaying hardware information directly employ unified output or static display methods, without layered processing and dynamic feedback of information. This can lead to problems such as information overload, fragmented interactions, and maintenance difficulties. Specifically, some tools fail to display specialized parameters in a hierarchical manner, making it difficult for ordinary users to quickly identify key information and requiring secondary screening. Hardware information is scattered across multiple subsystems, lacking a unified integration mechanism, which impacts the intuitiveness and readability of the information. Furthermore, traditional methods rely on accumulated expertise to locate hardware anomalies, making it difficult to achieve rapid response and accurate judgment, thus impacting system maintenance efficiency and operational cost control. Summary of the Invention

[0004] The present application aims to solve one of the technical problems in the related art at least to a certain extent.

[0005] To this end, the first purpose of this application is to propose a method for obtaining and dynamically displaying hardware configuration information based on a graphical user interface, aiming to solve the problems in the existing technology such as complex hardware information acquisition methods, non-intuitive display, and low maintenance efficiency. By constructing a unified GUI interface and a collaborative mechanism with the back-end data processing module, efficient acquisition, dynamic update and visual feedback of hardware configuration information can be achieved.

[0006] The second objective of this application is to provide a device for acquiring and dynamically displaying hardware configuration information based on a graphical user interface.

[0007] The third objective of this application is to provide an electronic device.

[0008] The fourth object of this application is to provide a computer-readable storage medium.

[0009] A fifth object of this application is to provide a computer program product.

[0010] To achieve the above objectives, the first embodiment of the present application proposes a method for obtaining and dynamically displaying hardware configuration information based on a graphical user interface, comprising: In response to a hardware information query request initiated by a user in the GUI interface, a corresponding query task is generated; the query task is added to the task queue of the task management module, and the task management module determines whether to execute the tasks sequentially in the queue based on task dependencies; When the task is in execution, the MCS system interface is called through CLI commands to obtain hardware configuration data, and log events are generated during the execution process; Send the log event to the event management module, which establishes a connection with the MCS system server through Socket communication and receives the hardware status change notification sent by the MCS system; If a hardware anomaly is detected, the event management module encapsulates the anomaly information as an alarm event and adds the alarm event to the event queue. The front-end module requests event data from the event management module at preset time intervals through a polling interface. Based on the event data, the GUI interface module dynamically updates the display content according to the hardware status, and displays the hardware operation status and abnormal information through color coding and dynamic charts, where red indicates component failure, black indicates missing components, and yellow indicates warning status.

[0011] Optionally, the query task includes a query task and a subscription task, wherein: The query task is triggered by the user and is used to obtain the current hardware configuration information; The subscription task is triggered periodically by the background to continuously obtain hardware status change information.

[0012] Optionally, the task management module divides tasks into queue execution tasks and non-queue execution tasks according to the execution order of tasks, wherein: The queue execution task is used to execute CLI commands with dependencies; Non-queue execution tasks are used to execute CLI commands without dependencies and can be executed immediately.

[0013] Optionally, the event management module adopts a publish-subscribe mode to receive event notifications from the MCS system and generate corresponding alarm events according to the event type; the notification type sent by the MCS system to the event management module is one or more of Notification, Bellwether, Resy; Flush_ack, and the notification type sent by the event management module to the MCS system is one or more of Subscribe, Unsubscribe, and Flush.

[0014] Optionally, the GUI interface module adopts a layered information architecture, including a basic layer and an expert layer, wherein: The base layer is used to display the core parameters of the hardware, including CPU, memory, and storage; The expert layer displays advanced hardware status information through a folding menu, including hard disk SMART status, GPU temperature, and fan speed.

[0015] To achieve the above-mentioned purpose, the second embodiment of the present application proposes a device for acquiring and dynamically displaying hardware configuration information based on a graphical user interface, comprising: GUI interface module, used to receive hardware information query requests input by users and display hardware configuration information and abnormal status; A task management module, connected to the GUI interface module, is used to receive the query request and generate a query task, add the task to the task queue, and control the execution order of the tasks according to the task dependency relationship; A CLI execution module, connected to the task management module, is used to execute CLI commands to call the MCS system interface to obtain hardware configuration data and generate log events during the execution process; An event management module, connected to the CLI execution module and the MCS system interface, is used to receive and process hardware status change notifications, encapsulate abnormal information into alarm events, and add the alarm events to the event queue; An event queue module, connected to the event management module and the GUI interface module, for storing and responding to polling requests from the front-end module and returning event data to the GUI interface module; The GUI interface module dynamically updates the display content based on the event data, and displays the hardware operation status and abnormal information through color coding and dynamic charts, where red indicates component failure, black indicates component missing, and yellow indicates warning status.

[0016] Optionally, the GUI interface module supports dynamic charts and color-coded visual displays, wherein: Dynamic charts are used to display the utilization of hardware resources; Color coding is used to identify hardware status, with red indicating a component failure, black indicating a missing component, and yellow indicating a warning state.

[0017] To achieve the above-mentioned purpose, a third embodiment of the present application provides an electronic device, comprising: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method as described in any one of the first aspects.

[0018] To achieve the above-mentioned purpose, the fourth embodiment of the present application proposes a computer-readable storage medium, which stores computer-executable instructions. When the computer-executable instructions are executed by a processor, they are used to implement the method as described in any one of the first aspects.

[0019] To achieve the above-mentioned objectives, the fifth embodiment of the present application proposes a computer program product, which implements any one of the methods in the first aspect when executed by a processor.

[0020] The technical solutions provided by the embodiments of this application bring at least the following beneficial effects: 1. Lower user barriers to entry: By replacing the traditional command line interface (CLI) with a graphical user interface (GUI), non-professionals can quickly understand the system hardware status, improving system usability. 2. Improve maintenance efficiency: By real-time monitoring of hardware parameter changes and combining event-driven mechanisms, dynamic feedback on hardware status is achieved, helping operation and maintenance personnel to promptly detect and handle anomalies. 3. Enhance information integration capabilities: Unify and integrate hardware information from multiple platforms and third-party tools to avoid information fragmentation and improve information acquisition efficiency; 4. Improve anomaly identification efficiency: By combining dynamic charts with color coding, users can identify hardware anomalies more than 40% faster and reduce the rate of false positives. 5. Optimize the task execution process: through the task queue and execution monitoring mechanism, ensure the orderliness of task execution and the timeliness of exception handling, reduce task conflicts and improve system stability; 6. Enhance system scalability and compatibility: Through decoupled design and provider configuration mechanism, it supports flexible expansion and adapts to different platforms and hardware environments; 7. Improve product competitiveness: Graphical, real-time, and intelligent hardware monitoring systems can significantly improve product user experience and enhance market competitiveness.

[0021] Additional aspects and advantages of the present application will be given in part in the description below, and in part will become apparent from the description below, or will be learned through practice of the present application. BRIEF DESCRIPTION OF THE DRAWINGS

[0022] The above and / or additional aspects and advantages of the present application will become apparent and easily understood from the following description of the embodiments in conjunction with the accompanying drawings, in which: Figure 1 A flowchart of a method for obtaining and dynamically displaying hardware configuration information based on a graphical user interface provided in an embodiment of the present application; Figure 2 A schematic diagram of the backend data service provided in an embodiment of the present application. DETAILED DESCRIPTION

[0023] The following describes in detail embodiments of the present application, examples of which are shown in the accompanying drawings, wherein the same or similar reference numerals throughout represent the same or similar elements or elements having the same or similar functions. The embodiments described below with reference to the accompanying drawings are exemplary and are intended to be used to explain the present application, and should not be construed as limiting the present application.

[0024] Figure 1 This is a flow chart of a method for obtaining and dynamically displaying hardware configuration information based on a graphical user interface provided in an embodiment of the present application. Figure 1 As shown, the method includes the following steps: Step S1, in response to a hardware information query request initiated by a user in the GUI interface, a corresponding query task is generated; the query task is added to the task queue of the task management module, and the task management module determines whether to execute the tasks sequentially in the queue according to the task dependency relationship.

[0025] In an embodiment of the present application, when a user initiates a hardware information query request in a graphical user interface (GUI), the system responds to the request and generates a corresponding query task. The query task is added to a task queue maintained by a task management module. The task management module dynamically determines whether to execute the tasks in the task queue sequentially based on their dependencies.

[0026] Specifically, at system startup, a graphical user interface (GUI) module is built using cross-platform development frameworks such as Electron or Qt. This interface utilizes a layered architecture, consisting of a basic layer and an expert layer. The basic layer displays core hardware parameters by default, such as CPU model, memory capacity, and storage device type. The expert layer, in a collapsible menu, provides more detailed advanced hardware parameters, such as hard drive SMART status and GPU temperature curves. The GUI's design is modeled after the tree structure of the MCS "System Report" to improve user information retrieval efficiency, interface consistency, and enhance the system's cross-platform adaptability.

[0027] In terms of the interaction between the front-end and the back-end, two types of communication are defined in the embodiment of the present application: (1) Requests based on the RPC protocol are used for periodic polling. For example, the rpc.polling.poll request type is often used for event subscription or status update; (2) Ordinary Servlet requests for non-RPC protocols, such as requests for memory information query operations, will be directed to Servlet interfaces such as MEMGridDataHandler, and the corresponding Java class on the backend will be responsible for data processing.

[0028] In terms of task types, query tasks are divided into two categories: query tasks and subscription tasks. Query tasks are triggered by the user and are used to obtain current hardware configuration information. Subscription tasks, on the other hand, are triggered periodically by the system background to monitor dynamic changes in hardware status, allowing the system to respond promptly and provide updated information.

[0029] The task management module further divides tasks into queue execution tasks and non-queue execution tasks according to the execution order requirements of the tasks: Queued execution tasks are used for commands with dependencies. For example, you must first execute the "Get CPU Information" command before you can get the "Heat Dissipation Status" information. Such tasks must be executed in sequence after the dependency conditions are met. Non-queue execution tasks are suitable for independent CLI commands without dependencies, which can be executed concurrently immediately to improve overall execution efficiency.

[0030] like Figure 2 As shown, this application also sets up a unified task manager. The task manager's responsibility is to receive all task commands from the front end, including operations such as device creation, modification, and deletion, and convert these operations into CLI tasks. All tasks will be added to the task queue to be executed. The execution of tasks follows the queue rules: execute one by one from the head of the queue, only one task is taken at a time and marked as "executing", and the remaining tasks in the queue remain in the "pending" state. The system also updates the number of tasks waiting to be executed corresponding to each task to ensure the traceability of execution.

[0031] When a task is executed, the system generates event information and adds it to the event list. Furthermore, during CLI command execution, the system monitors command output and pushes any events generated during the process to the event list in real time. The frontend obtains real-time task execution feedback from the event list through regular RPC requests, enabling visual and responsive management of task execution.

[0032] After the task is completed, the system automatically takes the next task from the head of the queue and continues to execute it until all tasks are processed.

[0033] Step S2: When the task is in execution, the MCS system interface is called through the CLI command to obtain hardware configuration data, and log events are generated during the execution process.

[0034] In another embodiment of the present application, the above-mentioned task generation and scheduling process is continued. When the task is in the "executing" state, the system will automatically call the MCS system interface through the CLI (command line interface) command to obtain the required hardware configuration information, and generate log events in real time during the entire execution process for subsequent tracking and front-end interface display.

[0035] In the embodiments of this application, the command manager, as a key component, is primarily responsible for organizing, scheduling, and executing commands. The command manager not only initiates and issues commands but also implements a listener for the command execution process. This listener monitors the command execution status in real time, including key information such as whether the command is executed correctly and whether any exceptions are thrown. If an exception occurs during command execution, the listener will immediately record and report it, generating a corresponding error event to ensure the system has a good fault-tolerant mechanism.

[0036] In terms of the execution mechanism of commands, commands can be divided into two categories according to their dependencies: (1) Commands that require queue execution: These commands have execution order dependencies. For example, some commands involving task configuration or hardware initialization require that a specific command be completed before the next command can be executed. In this case, the command manager places these commands in the task queue and executes them strictly in the queue order to avoid execution failures due to unsatisfied dependencies.

[0037] (2) Commands that do not require queue execution: These commands have no upstream or downstream dependencies and can be triggered immediately. For example, a single status read or log query command does not depend on other results and can be directly dispatched and executed by the system without waiting in a queue, thus improving system response efficiency.

[0038] In this embodiment, a key mechanism for ensuring system stability is also designed: the MCS memory anomaly file monitoring mechanism. The system continuously monitors a specific path in the MCS layer to see if a diagnostic file caused by memory anomalies is generated. If the file is detected, it can be preliminarily determined that the MCS has a potential memory anomaly issue.

[0039] Furthermore, the system dynamically monitors changes to the file's content: if the file continues to grow, the anomaly is still occurring. Once the file size stops changing within a certain period, indicating that the abnormal data has been written, the system immediately terminates the current application to prevent further damage or the spread of the anomaly. This mechanism ensures that the system can promptly stop losses and trigger fault recovery processes when memory anomalies occur, providing underlying security for stable system operation.

[0040] In summary, the embodiment of the present application constructs a hardware information query and processing system with real-time monitoring, sequence control and abnormal self-handling capabilities through the collaborative design of CLI command scheduling MCS interface, command monitoring mechanism, and abnormal file monitoring mechanism.

[0041] Step S3: Send the log event to the event management module. The event management module establishes a connection with the MCS system server through Socket communication and receives the hardware status change notification sent by the MCS system.

[0042] In the further steps of the embodiment of the present application, step S3 involves the design and implementation of an event processing mechanism. When a log event is generated during the execution of a CLI command, the system will send the log event to the event management module to implement the unified reception, processing and reporting functions of the event.

[0043] The event management module, one of the core components in this application's implementation, is responsible for maintaining a communication connection with the MCS system and for real-time sensing and processing of hardware status change events. The event management module primarily consists of two subcomponents: the event manager and the event list manager, which together form an efficient event distribution mechanism based on socket communication and a publish-subscribe model.

[0044] In terms of communication mechanism, the event manager establishes a persistent connection with the Socket server in the MCS system through the Socket client, and continuously listens for data change messages sent by the MCS system. The MCS system can send various types of notification information to the event management module, including but not limited to: Notification: used to indicate regular state change events; Bellwether: used to identify key events or indicator changes; Resy: indicates the system response status at the resource level; Flush_ack: used to confirm that the previous flush operation has been completed.

[0045] After receiving the above notification, the event manager will parse and classify the event according to the event type and generate the corresponding structured event object. At the same time, the event manager also has the ability to send control instructions and can actively send the following types of instructions to the MCS system to implement subscription control: Subscribe: subscribe to a certain type of event; Unsubscribe: cancel subscription; Flush: flushes the event queue and requests the latest status.

[0046] During event reception and processing, the Event List Manager handles event caching and scheduling. This module integrates the PollingManager, which receives event information submitted by various business modules and stores it in a centralized queue structure. When the frontend requests events through RPC, the PollingManager filters and returns the corresponding event set based on the provider information in the request.

[0047] To further improve the flexibility and scalability of event processing, this application uses a decoupled publish-subscribe model to process events. This model supports the derivation and aggregation of original events. For example, when executing a "query memory" operation, the system automatically generates a corresponding "query memory" event and a "query information deletion" event to assist the front-end in updating page status or releasing resources.

[0048] Furthermore, to satisfy event subscription requests from the frontend through the rpc.polling.xxx interfaces, the system completes the registration and configuration of various providers during application initialization. Each provider defines the processing logic and subscription rules for specific event types, ensuring that the frontend can efficiently obtain relevant status updates.

[0049] To sum up, this application realizes an efficient event interaction and status notification system with the MCS system by setting up an event manager and an event list manager, and combining the Socket communication mechanism and the publish-subscribe model. While ensuring the system's asynchronous processing capabilities, it enhances the real-time and scalability of event response.

[0050] In step S4, if a hardware anomaly is detected, the event management module encapsulates the anomaly information as an alarm event and adds the alarm event to the event queue. The front-end module requests event data from the event management module at preset time intervals through the polling interface.

[0051] In an embodiment of the present application, further, in step S4, if the event management module detects that the event from the MCS system contains hardware abnormality information, the system will trigger an alarm mechanism and encapsulate and process the abnormal event.

[0052] Specifically, the event management module first parses and categorizes the received raw abnormal events to identify whether they represent abnormal conditions, such as device failure, overtemperature, voltage abnormality, or abnormal SMART status of a storage device. Once the event is confirmed to be a hardware abnormality, the event management module encapsulates it into a standard alarm format.

[0053] The alarm event not only retains the original abnormal information, but also adds fields such as the event occurrence time, associated hardware identification, alarm level (such as serious, warning, information) and predefined recommended processing actions, thereby enhancing the readability and operability of the event.

[0054] The event management module then adds the encapsulated alarm event to the event queue, which the front-end module can then retrieve and display. The event queue is centrally managed by the event list manager and features a first-in-first-out (FIFO) mechanism, ensuring that events are pushed in chronological order to avoid information delays or overwriting.

[0055] To ensure real-time front-end awareness of system anomalies, this embodiment of the present application utilizes a polling mechanism as a front-end / back-end communication method. The front-end module invokes a polling interface (e.g., rpc.polling.xxx) to periodically request the latest event data from the event management module at preset intervals (e.g., every 5 seconds or every 10 seconds). When a polling request reaches the event management module, the system filters the event queue for events not yet delivered to the front-end and returns them in order.

[0056] Through the above mechanism, the system can achieve timely reporting and front-end prompts of hardware anomalies without introducing a complex push architecture, thereby greatly improving the overall system's abnormal response capabilities and user visualization experience.

[0057] The alarm event mechanism, event queue cache and polling front-end pull method in the embodiments of this application jointly construct a low-coupling, highly controllable system exception handling path, which can flexibly adapt to the exception handling strategies of different business modules and provide basic support for subsequent alarm linkage, log auditing and system recovery.

[0058] In step S5, based on the event data, the GUI interface module dynamically updates the display content according to the hardware status, and displays the hardware operation status and abnormal information through color coding and dynamic charts, where red indicates component failure, black indicates component missing, and yellow indicates warning status.

[0059] In step S5 of the present embodiment, the system dynamically displays and updates the hardware status in real time using the GUI module based on the event data provided by the event management module. This process not only enables the visualization of hardware information but also enhances the efficiency of identifying abnormal conditions and the user interaction experience through color coding and dynamic charts.

[0060] Specifically, upon receiving the latest event data from the event queue, the GUI module determines the status of the corresponding hardware component based on the event content and dynamically adjusts the displayed content within the interface. For hardware modules with changing status, such as the CPU, memory, disk, and GPU, the interface will refresh their status indicators in real time and trigger corresponding visual displays based on the current status.

[0061] In order to improve the efficiency of anomaly identification, the embodiment of the present application adopts a combination of a color coding mechanism and a dynamic chart component to achieve enhanced visualization of the status.

[0062] Color coding mechanism: Red indicates serious anomalies or component failures, such as CPU overheating, GPU failure, or storage device read failure; black indicates missing or unrecognizable hardware components, such as a motherboard without a certain device installed; yellow indicates an alarm state, such as a hard drive SMART parameter exceeding the warning threshold or abnormal power supply voltage fluctuations but not reaching the critical failure value; At the same time, the temperature information is also dynamically judged using the temperature threshold. For example, when the temperature exceeds 80°C, it is marked as red.

[0063] The system introduces a circular progress bar chart component (similar to the disk utilization display in Windows Task Manager), replacing the traditional numeric percentage text display. This chart displays information such as hardware utilization and load level in a circular format, and uses color coding to more intuitively and quickly convey current status changes. User testing data shows that compared to traditional numeric percentage displays, the circular progress chart can improve anomaly identification speed by approximately 40%, especially when multiple indicators are displayed side by side.

[0064] In addition, the GUI interface module supports dynamic refresh and a hierarchical display mechanism. The basic layer displays core indicators, while the expert layer provides more granular status data analysis through graphical components (such as heat maps, curve graphs, and bar charts), facilitating fault diagnosis and performance evaluation by professionals.

[0065] Through the above mechanism, the embodiments of this application significantly enhance the system's ability to visualize hardware status, achieving full-link closed-loop control from data reception and status recognition to visual output. Users can directly grasp the system's operating status and potential fault points through a graphical interface without having to access the command line or backend, greatly enhancing the system's usability and fault response efficiency.

[0066] In summary, the present embodiment provides a unified task management mechanism applicable to both query and subscription tasks. By fine-tuning the execution paths, event generation, and front-end and back-end communication of these two types of tasks, the system can achieve both active query and passive monitoring of hardware status information.

[0067] Specifically: For query tasks, they are mainly used for hardware status query behaviors actively initiated in the user interface component. For example, when a user clicks a button on the front-end page to obtain the memory status, the system will trigger the following process: the page component executes the query action; the component sends a query URL request to the back-end, such as rpc.query.memory; the system generates the corresponding query task; the query task is added to the task queue in the task manager, waiting for execution; during the task execution process, the underlying MCS platform interface is called through the CLI command to obtain hardware information, and the system generates corresponding log information; the generated log information is encapsulated as a log event and added to the event list; the front-end module initiates a request to the event management module through the rpc.polling.poll interface at an interval of 1.5 seconds, pulls the latest log event from the event list, and realizes real-time visual feedback of the task execution process.

[0068] The execution path of subscription tasks is structurally similar to query tasks, but their triggering mechanism is different. These tasks are not directly triggered by user actions but are initiated periodically by the system backend. They are often used to continuously monitor hardware operating status. The specific process is as follows: the page component initiates a subscription topic; a query URL request (e.g., rpc.query.memory) is sent to the backend; the system generates the corresponding subscription task; the task is added to the task manager and awaits execution according to the scheduled order; during task execution, the system calls CLI commands to access the underlying data interface of the MCS platform to obtain key information such as memory frequency and in-place status; the log information generated during execution is encapsulated as log events and added to the event list; the frontend uses the polling mechanism rpc.polling.poll to request task-related event logs every 1.5 seconds; the backend encapsulates the hardware status data obtained by the CLI command and responds to the frontend request component through the corresponding Servlet service; the frontend component updates the page display based on the returned data. If an abnormal state is detected (such as memory not being in place), a color-coded alarm is automatically triggered, such as a red display to alert the user.

[0069] Through the above process, this application realizes the refined control of each key link in the task execution life cycle, including task generation, management, execution, log event generation and display. In particular, combined with a unified polling interface design and event list caching mechanism, the system has good responsiveness and visualization capabilities to hardware status changes. In addition, the underlying hardware data obtained through CLI commands is not only used for front-end display, but also used to trigger the corresponding visual alarm logic, forming an automatic closed-loop control of "data acquisition → anomaly identification → alarm presentation", which greatly improves the system's real-time perception and anomaly response capabilities.

[0070] To implement the above embodiment, the present application also proposes a device for acquiring and dynamically displaying hardware configuration information based on a graphical user interface. The device includes: GUI interface module, used to receive hardware information query requests input by users and display hardware configuration information and abnormal status; A task management module, connected to the GUI interface module, is used to receive the query request and generate a query task, add the task to the task queue, and control the execution order of the tasks according to the task dependency relationship; A CLI execution module, connected to the task management module, is used to execute CLI commands to call the MCS system interface to obtain hardware configuration data and generate log events during the execution process; An event management module, connected to the CLI execution module and the MCS system interface, is used to receive and process hardware status change notifications, encapsulate abnormal information into alarm events, and add the alarm events to the event queue; An event queue module, connected to the event management module and the GUI interface module, for storing and responding to polling requests from the front-end module and returning event data to the GUI interface module; The GUI interface module dynamically updates the display content based on the event data, and displays the hardware operation status and abnormal information through color coding and dynamic charts, where red indicates component failure, black indicates component missing, and yellow indicates warning status.

[0071] Optionally, the GUI interface module supports dynamic charts and color-coded visual displays, wherein: Dynamic charts are used to display the utilization of hardware resources; Color coding is used to identify hardware status, with red indicating a component failure, black indicating a missing component, and yellow indicating a warning state.

[0072] Regarding the apparatus in the above embodiment, the specific manner in which each module performs operations has been described in detail in the embodiment of the method, and will not be elaborated here.

[0073] In order to implement the above embodiments, the present application also proposes an electronic device, comprising: a processor, and a memory communicatively connected to the processor; the memory stores computer-executable instructions; the processor executes the computer-executable instructions stored in the memory to implement the method provided by the above embodiments.

[0074] In order to implement the above embodiments, the present application also proposes a computer-readable storage medium, in which computer-executable instructions are stored. When the computer-executable instructions are executed by a processor, they are used to implement the methods provided by the above embodiments.

[0075] In order to implement the above embodiments, the present application also proposes a computer program product, including a computer program, which implements the methods provided by the above embodiments when executed by a processor.

[0076] The collection, storage, use, processing, transmission, provision and disclosure of user personal information involved in this application are in compliance with relevant laws and regulations and do not violate public order and good morals.

[0077] It is important to note that personal information collected from users should be used for legitimate and reasonable purposes and should not be shared or sold beyond these legitimate uses. Furthermore, such collection / sharing should be conducted only after receiving the user's informed consent, including but not limited to notifying the user to read the user agreement / user notice and sign an agreement / authorization that includes the relevant user information before using the feature. Furthermore, any necessary steps must be taken to safeguard and secure access to such personal information and ensure that others with access to personal information comply with its privacy policy and procedures.

[0078] This application contemplates providing implementations that allow users to selectively block the use or access of personal information data. Specifically, this disclosure contemplates providing hardware and / or software to prevent or block access to such personal information data. Risks can be minimized by limiting data collection and deleting data once it is no longer needed. Furthermore, where applicable, such personal information can be de-identified to protect user privacy.

[0079] In the descriptions of the foregoing embodiments, the reference terms "one embodiment", "some embodiments", "example", "specific example", or "some examples" mean that the specific features, structures, materials or characteristics described in conjunction with the embodiment or example are included in at least one embodiment or example of the present application. In this specification, the schematic expressions of the above terms do not necessarily refer to the same embodiment or example. Moreover, the specific features, structures, materials or characteristics described may be combined in any one or more embodiments or examples in a suitable manner. In addition, those skilled in the art may combine and combine the different embodiments or examples described in this specification and the features of the different embodiments or examples, unless they are mutually inconsistent.

[0080] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of the technical features being referred to. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of such features. Throughout the description of this application, "plurality" means at least two, for example, two, three, etc., unless otherwise specifically defined.

[0081] Any process or method description in a flowchart or otherwise described herein may be understood to represent a module, segment or portion of code comprising one or more executable instructions for implementing the steps of a custom logical function or process, and the scope of the preferred embodiments of the present application includes alternative implementations in which functions may be performed out of the order shown or discussed, including performing functions in a substantially simultaneous manner or in the reverse order depending on the functions involved, which should be understood by those skilled in the art to which the embodiments of the present application belong.

[0082] The logic and / or steps represented in a flowchart or otherwise described herein, for example, can be considered a sequenced list of executable instructions for implementing the logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus, or device (e.g., a computer-based system, a system including a processor, or other system that can fetch and execute instructions from an instruction execution system, apparatus, or device). For purposes of this specification, a "computer-readable medium" is any device that can contain, store, communicate, propagate, or transport a program for use by, or in conjunction with, an instruction execution system, apparatus, or device. More specific examples (not exhaustive) of computer-readable media include: an electrical connection with one or more wires (electronic devices), a portable computer disk cartridge (magnetic device), random access memory (RAM), read-only memory (ROM), erasable and programmable read-only memory (EPROM or flash memory), fiber optic devices, and a portable compact disc read-only memory (CDROM). Furthermore, the computer-readable medium may even be paper or other suitable medium on which the program is printed, since the program may be obtained electronically, for example, by optically scanning the paper or other medium and then editing, interpreting or processing it in another suitable manner if necessary, and then storing it in a computer memory.

[0083] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above-described embodiments, multiple steps or methods can be implemented using software or firmware stored in a memory and executed by a suitable instruction execution system. For example, if implemented using hardware, as in another embodiment, any one of the following technologies known in the art or a combination thereof can be used: a discrete logic circuit having logic gate circuits for implementing logical functions on data signals, an application-specific integrated circuit having suitable combinational logic gate circuits, a programmable gate array (PGA), a field-programmable gate array (FPGA), etc.

[0084] Those skilled in the art will understand that all or part of the steps in the method of the above embodiment can be completed by instructing related hardware through a program, and the program can be stored in a computer-readable storage medium. When the program is executed, it includes one or a combination of the steps of the method embodiment.

[0085] In addition, the functional units in the various embodiments of the present application may be integrated into a processing module, or each unit may exist physically separately, or two or more units may be integrated into a module. The above-mentioned integrated module may be implemented in the form of hardware or in the form of a software functional module. If the integrated module is implemented in the form of a software functional module and sold or used as an independent product, it may also be stored in a computer-readable storage medium.

[0086] The storage medium mentioned above may be a read-only memory, a magnetic disk, or an optical disk, etc. Although the embodiments of the present application have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present application. Persons skilled in the art may make changes, modifications, substitutions, and variations to the above embodiments within the scope of the present application.

[0087] It should be understood that the various forms of the processes shown above can be used to reorder, add, or delete steps. For example, the steps described in this application can be performed in parallel, sequentially, or in a different order, as long as the desired results of the technical solution of this application can be achieved. This is not limited herein.

[0088] The above specific embodiments do not constitute a limitation on the scope of protection of this application. Those skilled in the art will appreciate that various modifications, combinations, sub-combinations, and substitutions may be made based on design requirements and other factors. Any modifications, equivalent substitutions, and improvements made within the spirit and principles of this application shall be included within the scope of protection of this application.

Claims

1. A method for acquiring and dynamically displaying hardware configuration information based on a graphical user interface, characterized in that: The following steps are involved: In response to a hardware information query request initiated by a user in the GUI interface, a corresponding query task is generated; the query task is added to the task queue of the task management module, and the task management module determines whether to execute the tasks sequentially in the queue based on task dependencies; When the task is in execution, the MCS system interface is called through CLI commands to obtain hardware configuration data, and log events are generated during the execution process; Send the log event to the event management module, which establishes a connection with the MCS system server through Socket communication and receives the hardware status change notification sent by the MCS system; If a hardware anomaly is detected, the event management module encapsulates the anomaly information as an alarm event and adds the alarm event to the event queue. The front-end module requests event data from the event management module at preset time intervals through a polling interface. Based on the event data, the GUI interface module dynamically updates the display content according to the hardware status, and displays the hardware operation status and abnormal information through color coding and dynamic charts, where red indicates component failure, black indicates missing components, and yellow indicates warning status.

2. The method according to claim 1, wherein The query tasks include query tasks and subscription tasks, where: The query task is triggered by the user and is used to obtain the current hardware configuration information; The subscription task is triggered periodically by the background to continuously obtain hardware status change information.

3. The method according to claim 1, wherein The task management module divides tasks into queue execution tasks and non-queue execution tasks according to the execution order of tasks, wherein: The queue execution task is used to execute CLI commands with dependencies; Non-queue execution tasks are used to execute CLI commands without dependencies and can be executed immediately.

4. The method according to claim 1, wherein The event management module adopts a publish-subscribe mode to receive event notifications from the MCS system and generate corresponding alarm events according to the event type; the notification type sent by the MCS system to the event management module is one or more of Notification, Bellwether, Resy; Flush_ack, and the notification type sent by the event management module to the MCS system is one or more of Subscribe, Unsubscribe, and Flush.

5. The method according to claim 1, wherein The GUI interface module adopts a layered information architecture, including a basic layer and an expert layer, wherein: The base layer is used to display the core parameters of the hardware, including CPU, memory, and storage; The expert layer displays advanced hardware status information through a folding menu, including hard disk SMART status, GPU temperature, and fan speed.

6. A device for acquiring and dynamically displaying hardware configuration information based on a graphical user interface, characterized in that: include: GUI interface module, used to receive hardware information query requests input by users and display hardware configuration information and abnormal status; A task management module, connected to the GUI interface module, is used to receive the query request and generate a query task, add the task to the task queue, and control the execution order of the tasks according to the task dependency relationship; A CLI execution module, connected to the task management module, is used to execute CLI commands to call the MCS system interface to obtain hardware configuration data and generate log events during the execution process; An event management module, connected to the CLI execution module and the MCS system interface, is used to receive and process hardware status change notifications, encapsulate abnormal information into alarm events, and add the alarm events to the event queue; An event queue module, connected to the event management module and the GUI interface module, for storing and responding to polling requests from the front-end module and returning event data to the GUI interface module; The GUI interface module dynamically updates the display content based on the event data, and displays the hardware operation status and abnormal information through color coding and dynamic charts, where red indicates component failure, black indicates component missing, and yellow indicates warning status.

7. The device according to claim 6, characterized in that The GUI interface module supports dynamic charts and color-coded visual displays, where: Dynamic charts are used to display the utilization of hardware resources; Color coding is used to identify hardware status, with red indicating a component failure, black indicating a missing component, and yellow indicating a warning state.

8. An electronic device, characterized in that: include: a processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 5.

9. A computer-readable storage medium, characterized in that The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 5 when executed by a processor.

10. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 5 when executed by a processor.

Images