A server detection method and electronic device

Abstract

The application discloses a kind of server detection method and electronic equipment, it is related to server hardware inspection technical field, including automatically obtaining life cycle management data without cross-system manual switching operation, and automatically determine target test guide file based on these data, without artificial judgment or screening test scheme;Target test guide file provides unified quantitative test standard, has explicitly included component to be measured and test parameter, can directly drive inspection execution, result determination also forms unified quantitative determination basis, reduces artificial intervention throughout, avoids information deviation caused by human operation from source, reduces human operation cost, improves inspection efficiency and the accuracy and reliability of inspection result.

Description

Technical Field

[0001] This application relates to the field of server hardware testing technology, and in particular to a server testing method and electronic device. Background Technology

[0002] In the field of server hardware inspection, traditional inspection methods have long relied on manual operation to complete the core inspection process. Specifically, inspectors need to manually input a large number of command codes to obtain key component information such as firmware version, motherboard model, and hard drive serial number for each server. Since servers are often deployed in multi-operating system environments, the command logic of different systems differs, requiring inspectors to switch operating methods for different systems. This makes the cross-system data aggregation and verification process time-consuming and cumbersome, severely restricting the overall efficiency of the inspection work.

[0003] Meanwhile, the inherent limitations of manual operation pose a significant threat to the quality of inspection results. On the one hand, frequent command input is prone to human error, leading to character errors and parameter mismatches, directly distorting the acquired hardware information and affecting the accuracy of the inspection results. On the other hand, the extended inspection cycle makes it difficult to update hardware status information in a timely manner, reducing the timeliness of the inspection results. Furthermore, subjective biases exist in the understanding and implementation of inspection standards by different inspectors, and the lack of unified quantitative judgment criteria further exacerbates the uncertainty of the inspection results, making it difficult to meet the stringent reliability requirements of server hardware inspection. Summary of the Invention

[0004] This application provides a server detection method and electronic device to at least solve the problems of low detection efficiency, information distortion and poor timeliness of results caused by the long-term reliance on manual labor in traditional inspection methods.

[0005] This application provides a server testing method, comprising: acquiring lifecycle management data of the server under test, wherein the lifecycle management data includes at least one of engineering change information, bill of materials, and basic test guidance documents; determining a target test guidance document based on the lifecycle management data; wherein the target test guidance document is a test guidance document corresponding to the engineering change information, or a test guidance document obtained by supplementing the basic test guidance document based on the test guidance document corresponding to the bill of materials, or the basic test guidance document; wherein the test guidance document includes the components under test and test parameters of the server under test; inspecting the server under test according to the target test guidance document; and determining whether the server under test contains abnormal components based on the inspection results.

[0006] This application also provides a server detection device, including:

[0007] The acquisition module is used to acquire the lifecycle management data of the server under test. The lifecycle management data includes at least one of the following: engineering change information, bill of materials, and basic test guidance documents.

[0008] The processing module is used to determine the target test guidance file based on lifecycle management data. The target test guidance file is either the test guidance file corresponding to the engineering change information, or a test guidance file obtained by supplementing the basic test guidance file based on the test guidance file corresponding to the bill of materials, or the basic test guidance file. The test guidance file includes the components under test and test parameters of the server under test.

[0009] The verification module is used to verify the server under test according to the target test guide document;

[0010] The judgment module is used to determine whether the server under test contains abnormal components based on the test results.

[0011] This application also provides an electronic device, including: a memory for storing a computer program; and a processor for executing the computer program to implement the steps of the above-described server detection method.

[0012] This application also provides a computer-readable storage medium storing a computer program, wherein the computer program, when executed by a processor, implements the steps of the above-described server detection method.

[0013] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the steps of the above-described server detection method.

[0014] This application automatically acquires lifecycle management data without requiring manual switching between systems, and automatically determines the target test guidance document based on this data, eliminating the need for manual judgment or screening of test schemes. The target test guidance document provides a unified quantitative test standard, clearly including the component to be tested and test parameters, which can directly drive the inspection execution. The result judgment also forms a unified quantitative judgment basis, reducing manual intervention throughout the process, avoiding information deviation caused by human operation from the source, reducing labor operation costs, and improving inspection efficiency as well as the accuracy and reliability of inspection results. Attached Figure Description

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

[0016] Figure 1A schematic diagram of the specific hardware architecture on which the execution of a server detection method provided in this application depends;

[0017] Figure 2 This is a schematic flowchart of a server detection method provided in an embodiment of this application;

[0018] Figure 3 This is a schematic diagram of the code for calculating the component specification matching degree provided in an embodiment of this application;

[0019] Figure 4 This is a schematic diagram of the structure of a server detection device provided in an embodiment of this application;

[0020] Figure 5 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Detailed Implementation

[0021] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this application, and not all embodiments. Based on the embodiments of this application, all other embodiments obtained by those of ordinary skill in the art without creative effort are within the protection scope of this application.

[0022] It should be noted that, in the description of this application, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or apparatus. The terms "first," "second," etc., in this application are used to distinguish similar objects and are not used to describe a specific order or sequence.

[0023] To more clearly illustrate the embodiments of this application, the technical terms used in the embodiments will be briefly introduced below:

[0024] Product Lifecycle Management (PLM) is an information management system that covers the entire lifecycle of a product, from concept design, R&D, production, sales to disposal. Its core function is to integrate product data, promote cross-departmental collaboration, and accelerate product innovation.

[0025] The Manufacturing Execution System (MES) is an execution-level management system located between the enterprise planning layer and the production site automation system. It is mainly responsible for real-time monitoring, scheduling, data collection and optimization of the production process to ensure the effective implementation of production plans.

[0026] Engineering change refers to the formal process and actions involved in modifying, adding to, or deleting core elements of a product, such as its design, technical parameters, material specifications, manufacturing processes, and documentation, during product research and development, production, or lifecycle management. Its core purpose is to ensure the necessity, rationality, and traceability of changes through standardized approval, evaluation, and execution, thereby preventing product quality risks, production interruptions, or cost overruns caused by disorderly changes.

[0027] A bill of materials is a structured technical document that details all materials (including raw materials, parts, components, etc.) required to produce or assemble a product. It also indicates the model, specifications, quantity, unit, hierarchical relationship (such as parent and child components) of each material and related technical specifications.

[0028] WebSocket is an application-layer network transport protocol based on the Transmission Control Protocol (TCP), enabling full-duplex communication over a single TCP connection. WebSocket simplifies data exchange between clients and servers, allowing servers to proactively push data to clients.

[0029] To enable those skilled in the art to better understand the present application, the present application will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0030] The specific application environment architecture or specific hardware architecture on which the execution of the server detection method depends is described here.

[0031] like Figure 1 As shown, Figure 1 A schematic diagram of the specific hardware architecture on which the server detection method depends.

[0032] The central maintenance and control system is configured to: obtain engineering change information from the product lifecycle management system and the bill of materials from the manufacturing execution system, and centrally manage and initially schedule this data to provide a data foundation for subsequent processes.

[0033] The standard conversion engine is configured to standardize and convert data from the central maintenance and control system, ensuring that data from different sources and formats can be uniformly adapted to subsequent processing and testing requirements.

[0034] The unified data model library is configured to store standardized data to form a unified data model, facilitating data retrieval and matching by subsequent systems.

[0035] The diagnostic system is configured to perform diagnostic analysis on the entire server and determine the testing standards and procedures.

[0036] The automated testing terminal is configured to perform automated testing operations on the server based on the output of the diagnostic system, completing tests on various hardware indicators and performance aspects. After testing, the results are recorded, and electronic files are generated for subsequent traceability and management. Simultaneously, the test results undergo final manual verification to ensure accuracy and reliability; any abnormalities can be manually intervened and corrected at this stage.

[0037] The embodiments of this application provide a server detection method, and the method is described in detail below in conjunction with the execution flow of the server detection method.

[0038] like Figure 2 As shown, the server detection method includes the following steps S201~S204:

[0039] S201. Obtain the lifecycle management data of the server under test.

[0040] The lifecycle management data includes at least one of the following: engineering change information, bill of materials (BOM), and basic testing guidelines. Engineering change (EC) information is used for key parameter changes such as hardware compatibility adjustments and firmware version updates. The bill of materials (BOM) contains detailed component information for the server hardware configuration.

[0041] Engineering change information pushed by the PLM system is received via WebSocket. Specifically, the system listens for updates to EC (Engineering Change) information from the PLM system via a Kafka message queue. The message queue adopts a distributed architecture. Engineering change information includes, but is not limited to, changes to components, hardware compatibility adjustments, and firmware version updates. This approach leverages the full-duplex communication capabilities of WebSocket to achieve real-time reception of EC information, while relying on the distributed nature of Kafka to ensure the stability and high throughput of message transmission. This avoids information loss or delays caused by single points of failure, ensuring that critical change information such as hardware compatibility adjustments and firmware version updates can be synchronized in a timely manner, thus saving time for subsequent process responses.

[0042] The system receives the bill of materials from the MES system via an Application Programming Interface (API). Utilizing standardized API interaction rules enables rapid integration with the MES system, reducing data exchange adaptation costs and ensuring the accuracy and efficiency of server hardware configuration information acquisition.

[0043] Obtain the basic test guide documents from the historical test guide library. The rules in the basic test guide documents are general specifications based on industry-standard practices, historical experience, or basic product requirements. They are uniformly applied when there are no special changes or material configuration requirements, ensuring that similar basic components in different batches and scenarios use consistent test standards.

[0044] The historical test guide repository is stored using a MongoDB database, supporting dynamic updates of test guide files. MongoDB is an open-source document-oriented NoSQL database based on a distributed architecture. When a new test guide file is released, it is imported into the administrator backend in JavaScript Object Notation (JSON) format. The system automatically parses and updates the test guide repository. Leveraging the lightweight and easily parsed nature of JSON, the complexity of file import and parsing is reduced. Combined with MongoDB's dynamic update capabilities, this ensures the test guide repository keeps pace with changing business needs, avoiding the inefficiency and error risks associated with manual updates.

[0045] From a technical perspective, it achieves real-time, standardized, and highly reliable management of lifecycle management data (EC information, BOM, test guidance documents) throughout the entire process. The technology selection at each stage is highly matched with business needs, ensuring efficient data flow in cross-PLM and MES system interactions, as well as the flexibility and scalability of data storage. It provides stable, timely, and accurate data support for server testing, improving the overall system's response efficiency and business adaptability.

[0046] In some embodiments, after obtaining engineering change information, bill of materials, and basic test guidelines, they are converted into a unified format. Specifically, the first field of the engineering change information is converted into a standard field; the second field of the bill of materials is parsed to obtain structured data.

[0047] For example, the first field ec_number of the engineering change information is converted to the standard field EC-ec_number with the prefix "EC-", and the second field order_gpu_spec:RTX3090 / 16G of the bill of materials is parsed into a JSON object {"type":"RTX3090","memory":"16GB"} containing the type and memory. As shown in Table 1.

[0048] Table 1

[0049]

[0050] The ec_number field is prefixed with "EC-" to form the standard field EC-ec_number, which unifies the identification format of engineering change information and avoids cross-system identification errors caused by non-standard field naming, such as the mismatch between the original field pushed by the PLM system and the field stored in the internal system. At the same time, it makes the field semantics more intuitive, making it easier for development and maintenance personnel to quickly identify engineering change data and reducing the cognitive cost and error rate when filtering and retrieving data.

[0051] The JSON parsing of the `order_gpu_spec` field splits the originally single string data into two clearly defined structured fields: "type" and "video memory," resolving the parsing difficulties caused by information coupling in the original string. This structured processing not only makes engineering change information easier for the system to automatically identify and extract, but also seamlessly adapts to downstream business scenario requirements. For example, during product specification verification, the consistency between actual components and the BOM list can be quickly compared directly through the key-value pairs of the JSON object, without the need to write additional complex string truncation logic. Simultaneously, the structured JSON format is compatible with the test guidance file format stored in MongoDB, facilitating the maintenance of format consistency among multiple types of data during subsequent integration and analysis, and improving the smoothness of data flow across stages.

[0052] In addition, these two operations improve the accuracy and availability of information from the data source. The standard field EC-ec_number reduces the risk of misassociating change information due to ambiguous field identifiers, while the structured JSON object avoids the problem of memory unit confusion or information omission that may occur when manually reading strings.

[0053] The names of affected components in engineering change information can also be converted to standard component names, as shown in Table 2.

[0054] Table 2

[0055]

[0056] Additionally, it should be noted that in Table 2, inspection category L2 indicates that electrical conformity testing needs to be performed when inspecting the Power_Unit_V3 component under test; inspection category L3 indicates that product specification matching needs to be performed when inspecting the NVIDIA_H100_SXM component under test.

[0057] The standardized conversion of the component names under test eliminates the potential arbitrariness in the original component names, creating a unified identifier for component information from different sources. This avoids information gaps across stages caused by inconsistent component names. When the system receives the standardized PWR-3.0-12VDC component name, it can automatically identify its product specification matching L2 product specification matching inspection category, thereby triggering the electrical conformity testing process. Similarly, the product specification matching category corresponding to GPU-H100-80G can drive the system to automatically retrieve the product specification matching parameter from the product specification matching list to complete the product specification matching inspection. No manual judgment of the inspection type is required, reducing errors from human decision-making and laying the foundation for automated triggering of the inspection process, significantly improving the response speed and execution accuracy of the inspection process.

[0058] S202. Determine the target test guidance document based on lifecycle management data.

[0059] The target test guidance file is either the test guidance file EC_Rule(c) corresponding to the engineering change information, or the test guidance file Custom_Rule(c) obtained by supplementing the basic test guidance file with the test guidance file corresponding to the bill of materials, or the basic test guidance file Base_Rule(c); the test guidance file includes the components to be tested and the test parameters of the server under test;

[0060] The lifecycle management data, including engineering change information, bill of materials (BOM), and basic test guidance information, are prioritized in the following order: engineering change information has the highest priority, BOM has the middle priority, and basic test guidance documents have the lowest priority.

[0061] In some embodiments, when the lifecycle management data includes engineering change information, the test guidance file EC_Rule(c) corresponding to the engineering change information is determined as the target test guidance file. When the lifecycle management data does not include engineering change information but includes a bill of materials (BOM), the basic test guidance file is supplemented based on the test guidance file corresponding to the BOM, and the resulting test guidance file Custom_Rule(c) is used as the target test guidance file. When the lifecycle management data includes neither engineering change information nor a BOM, i.e., only the basic test guidance file, the basic test guidance file Base_Rule(c) is used as the target test guidance file FinalRule(c).

[0062] For example, as shown in formula (1) below.

[0063] (1)

[0064] The above embodiments achieve flexible adaptation and precise positioning of test guidance documents by establishing hierarchical and clearly prioritized test guidance document matching rules. When engineering change information exists, the corresponding EC_Rule(c) is matched first, which can quickly respond to the adjustment of test requirements caused by engineering changes and ensure that the changed products or components can be tested according to the latest rules. If engineering change information is missing but a bill of materials exists, Custom_Rule(c) is matched, which can call the corresponding test logic based on the specific configuration of the materials and adapt to the test requirements of different material combinations. When only a basic test guidance document exists, Base_Rule(c) serves as a fallback rule, ensuring that the testing work still has a unified basic standard to follow when there are no special changes or material configuration information. This hierarchical rule system improves the system's adaptability to complex scenarios. Lifecycle management data from different sources and with different priorities can be matched with appropriate test guidance documents, avoiding test rule confusion caused by incomplete data types or unclear priorities. This enhances the standardization and reliability of the testing process and provides a clear logical basis for the automated scheduling of testing work and the rapid switching of testing strategies in different scenarios, indirectly improving the efficiency and accuracy of the testing phase in the entire lifecycle management process.

[0065] In addition to identifying the target test guideline file, when the lifecycle management data includes engineering change information, a basic test guideline file for the component under test (DUT) is determined from the historical test guideline library based on the DUT corresponding to the engineering change information. Then, the basic test guideline file is replaced with the test guideline file corresponding to the engineering change information. The basic test guideline file serves as a universal template for the DUT, eliminating the need to rewrite the entire file for each engineering change; only partial replacements for the changed items are required to generate the corresponding test guideline file, reducing redundant development costs.

[0066] For example, when an engineering change notice indicates that the voltage tolerance of the PWR-3.0-12VDC power module is adjusted from ±10% to ±5%, the basic test guide document for the power module is first retrieved from the historical test guide library. This basic test guide document (which includes the ±10% tolerance requirement) is then used to replace the ±10% voltage tolerance with ±5% based on the engineering change notice. This approach retains all general test rules from the basic test guide document except for the changed items (such as electrical safety and interface compatibility) while precisely covering the adjustments to test requirements brought about by the change. This ensures that the final target test guide document is both complete and aligned with the latest change requirements, preventing test omissions or standard conflicts caused by only updating some rules in the change.

[0067] The above embodiments also enhance the traceability and version correlation of test guideline documents. The basic test guideline document serves as the original standard basis for the component under test, while the document following engineering changes represents the revised standard. The two form a clear version correlation link through the logic of first identifying the basic document and then replacing it. This correlation not only facilitates subsequent tracing of differences in test standards before and after changes but also provides clear data support for tracing the source of quality issues. If voltage-related problems are found during subsequent testing, a comparison between the basic test guideline document and the revised document can quickly determine whether the problem is related to the engineering change, reducing the difficulty of tracing the source.

[0068] If the lifecycle management data does not include engineering change information but includes a bill of materials, first determine the configuration information of the component to be tested based on the test guide file corresponding to the bill of materials, and then supplement the basic test guide file in the historical test guide library based on this configuration information.

[0069] For example, suppose the bill of materials (BOM) requires the graphics processing unit (GPU) model to be RTX4090 / 24GB, but the basic test guide file in the historical test guide library does not specify this model. In this case, the test guide file corresponding to the BOM will be saved to the historical test guide library, supplementing it with special parameter requirements not covered in the basic test guide file for configuration matching during verification. Adding these special parameter requirements to the historical test guide library retains the general GPU testing rules in the basic test guide file while adding specific configuration requirements for RTX4090 / 24GB.

[0070] In the above embodiment, when the lifecycle management data includes a bill of materials (BOM) but not engineering change information, the configuration information of the component under test is first determined based on the Custom_Rule(c) corresponding to the BOM, and then the basic test guide file (Base_Rule(c)) in the historical test guide library is added. The configuration information in the BOM often reflects the specific needs of actual production or procurement. Adding the corresponding special parameters to the library is equivalent to accumulating customized rules for subsequent testing of similar materials. When encountering the BOM of the same GPU model again, the system does not need to parse Custom_Rule(c) repeatedly and can directly call the supplemented basic test guide file, greatly improving the efficiency of calling test rules.

[0071] When lifecycle management data does not include engineering change information and bills of materials, the basic test guidelines are used. For example, the basic test guidelines include a default test standard of 1000-3000 rpm for fan speed. When there is no engineering change information to adjust the speed standard, and no bill of materials to specify a special fan model, the basic test guidelines are used by default, without waiting for additional data or manually formulating temporary rules, ensuring a smooth connection from data reception and rule matching to test execution.

[0072] In scenarios where lifecycle management data does not contain engineering change information or bills of materials, and relies solely on basic test guidelines, the above embodiments eliminate the need for additional rule parsing, data matching, or library update operations. The system can directly call the preset basic test guidelines, reducing CPU computing power, memory usage, and database interaction frequency. Simultaneously, for operators, there is no need to learn complex rule adjustment logic; they only need to perform tests according to fixed basic standards, reducing training costs and operational difficulty. This is particularly suitable for scenarios involving batch testing of basic components, significantly improving testing efficiency.

[0073] S203. Inspect the server to be tested according to the target test guide document.

[0074] The inspection of the server under test includes at least one of the following: component power-on testing, electrical compliance testing, and product specification matching. Component power-on testing, electrical compliance testing, and product specification matching assess the server status from three core dimensions: hardware power-on stability, electrical performance compliance, and configuration and standard matching.

[0075] In some embodiments, performing component power-on testing on the server under test includes: firstly, monitoring the power-on status information of the component under test; then, based on the power-on status information of the component under test and the preset status information contained in the target test guidance document, verifying whether the component under test passes the component power-on test. This further determines the component power-on test pass rate of the server under test.

[0076] For example, assuming the components under test include a power supply and a fan, the "Chassis Status Get" command is first used to obtain information such as the power supply status and fan speed of the chassis, avoiding subjective errors from manual inspection. Data is collected every 5 seconds for 3 consecutive times to prevent misjudgment of a component as unqualified due to a single abnormal data point, ensuring data stability. The monitored data is then compared with the preset status information contained in the target test guidance document. For example, if the fan speed is less than the speed threshold of 800 rpm, it can be determined that the fan has failed the power-on test. This avoids inconsistencies in judgment caused by different testers' interpretations, significantly improving the accuracy of the power-on test. For example, if a server under test contains 10 components and 8 pass the test, the pass rate is 80%. This indicator can intuitively reflect the overall health of the server hardware's power-on status, making it easy for managers to quickly grasp the testing status of batch servers.

[0077] The above embodiments form a unified testing operation standard, which can be followed by both new employees and experienced operators to perform testing according to a fixed procedure, reducing the randomness of the operation process. On the other hand, it transforms the scattered test results of individual components into an overall quantitative indicator, which can intuitively reflect the overall health of the server hardware's power-on status, improving the efficiency and accuracy of power-on testing.

[0078] In some embodiments, the electrical qualification test of the server under test includes: firstly collecting the electrical parameters of the component under test, and then determining whether the component under test is qualified based on the collected electrical parameters and the preset tolerance range contained in the target test guidance document, thereby determining the component electrical qualification rate of the server under test.

[0079] Specifically, a digital multimeter is used to collect the electrical parameters of the component under test, including key electrical indicators such as voltage and current, to ensure that the data directly reflects the electrical performance status of the component. Then, the data is compared with the preset tolerance range contained in the target test guide document. When the voltage deviation exceeds 120% of the preset tolerance range, the component under test is deemed seriously unqualified; when the voltage deviation is between 100% and 120% of the preset tolerance range, the component under test is deemed slightly unqualified; when the current deviation exceeds 110% of the preset tolerance range, it is deemed unqualified.

[0080] For example, assuming a power module's voltage tolerance is preset to ±5% (standard range 11.4V-12.6V), if the actual voltage is 15.12V, the deviation reaches 26%, exceeding the 120% tolerance limit, and it can be directly judged as a serious non-compliance, requiring immediate shutdown to prevent hardware damage. If the actual voltage is 15.12V, 12.6V × 120% = 15.12V, and the deviation is 120%, then it is judged as a minor non-compliance, and the need for debugging and reuse can be evaluated. For example, if 8 out of 10 electrical components in a server under test are qualified, 1 is slightly non-qualified, and 1 is seriously non-qualified, the pass rate is 80%.

[0081] The above embodiments, combined with the standardized operation of digital multimeters, form a unified testing standard, avoiding the arbitrariness of subjective human judgment. Transforming the grading results of individual components into overall quantitative indicators can intuitively reflect the overall health level of the server's electrical performance, facilitating managers to quickly locate batch problems. The grading criteria based on preset tolerance ranges achieve refined control of electrical risks, enabling more accurate differentiation of component electrical risk levels. This grading can quickly identify high-risk components. It improves the hardware quality control system for server lifecycle management, enhancing server testing efficiency and the precision of risk control.

[0082] In some embodiments, performing product specification matching on the server under test includes: first obtaining the configuration information of the component under test, then calculating the component specification matching degree between the configuration information and the preset specifications contained in the target test guidance document, and determining whether the server under test has an abnormal configuration based on the component specification matching degree.

[0083] The configuration information of the component under test includes Basic Input / Output System (BIOS) settings, Peripheral Component Interconnect Express (PCIe) link status, GPU memory (gpu_mem), Solid State Drive (SSD) capacity (ssd_size), etc.

[0084] Optional, such as Figure 3As shown, the component specification matching degree between the configuration information bom_spec and the preset specification actual_spec contained in the target test guidance file is calculated using the cosine similarity algorithm. First, the configuration information and the preset specification are vectorized to obtain vector vec_bom and vector vec_actual, respectively. Then, the dot product of the vectors is obtained by multiplying the corresponding elements of the two vectors and summing them. Then, the norm norm_bom of vector vec_bom, that is, the square root of the sum of the squares of each element of vector vec_bom, and the norm norm_actual of vector vec_actual are calculated. Finally, the dot product is divided by the product of the norms of the two vectors to obtain the component specification matching degree, which is between 0.0 and 1.0. The larger the value of the component specification matching degree, the higher the matching degree of the configuration. The component specification matching degree can be calculated by the following formula (2):

[0085] (2)

[0086] In formula (2), Represents a vector of preset specifications. This is a vector representing the configuration information of the component under test, where n is the parameter dimension vector. An alert is triggered when the component specification matching degree is less than the matching degree threshold of 90%.

[0087] For example, suppose the configuration information of the component under test shows that the GPU is RTX4080 / 16GB, while the target test guide file contains a preset specification requirement of RTX4090 / 24GB for the GPU. The calculated component specification matching degree is 62%, which is less than the matching degree threshold of 90%, triggering an alert.

[0088] The above embodiments convert the matching degree between configuration information and preset specifications into a value between 0.0 and 1.0. Compared with the traditional binary judgment of conformity / non-conformity, this provides a more nuanced representation of the degree of configuration difference. This quantitative judgment facilitates the rapid identification of severely mismatched abnormal configurations, improving the accuracy of specification matching. When the server configuration's matching degree with the preset specifications is less than 90%, the system automatically issues a warning, quickly capturing core specification deviations during the detection phase and preventing abnormally configured servers from entering subsequent production or maintenance stages. This improves the accuracy and comprehensiveness of product specification matching and provides a scientific and efficient technical means for quality control of server hardware specifications.

[0089] S204. Determine whether the server under test contains abnormal components based on the test results.

[0090] The test results include at least one of the following: component power-on test pass rate, component electrical qualification rate, and component specification matching degree.

[0091] In some embodiments, during the process of determining whether the server under test contains abnormal components based on the test results, a confidence level is first calculated based on the test results. If the confidence level is less than a preset confidence level, the abnormal component of the server under test is located, and a prompt message is generated to remind the user to perform a review. Upon receiving a review instruction from the user, a review operation is performed on the abnormal component. The preset confidence level can be set to 0.85; when the confidence level is less than 0.85, the failure rate of the server under test will exceed 10%.

[0092] Optionally, the confidence level can be calculated based on the test results according to the following formula (3):

[0093] (3)

[0094] In formula (3), S L1 It is the pass rate of component power-on test, S L2 It is the electrical qualification rate of components, S L3 It refers to the degree of matching of component specifications. i (i=1,2,3) are dynamic weighting coefficients, calculated according to the following formula (4):

[0095] (4)

[0096] w i Regular updates based on server fault data reflect the actual contribution of different inspection dimensions to fault interception. If the proportion of interceptable faults due to electrical defects is high during a certain period, w2 will increase accordingly. For example, wi=0.6, w2=0.3, w3=0.1. This dynamic adjustment ensures that the confidence score calculation accurately matches the current fault distribution characteristics of the server, avoiding judgment bias caused by changes in fault modes due to static weights, and guaranteeing the long-term effectiveness of the confidence score.

[0097] The above embodiments fuse multi-dimensional inspection results into a confidence score through dynamic weighting. Compared with single-dimensional judgment, this provides a more comprehensive reflection of the overall health level of the server, avoiding the overlooking of potential problems in other dimensions due to a good single dimension, and improving the comprehensiveness and accuracy of fault diagnosis. The human-machine collaborative mechanism of initial machine judgment and manual review balances automation efficiency and judgment accuracy. The machine quickly calculates the confidence score based on the algorithm and filters out servers with low confidence scores. After triggering an alert, a human reviews the abnormal components. This approach utilizes automated processes to efficiently complete the initial screening, reducing the workload of manual inspection of each server; while manual review avoids potential misjudgments by the algorithm, ensuring the final accuracy of the abnormal component judgment. Especially in scenarios with complex server configurations and diverse fault modes, this human-machine collaboration can significantly improve the reliability of anomaly identification.

[0098] In some embodiments, the test results of various tests are integrated to generate an electronic profile carrying confidence levels. The electronic profile includes the test results of each component under test of the server under test, application records of test guidance documents, etc.

[0099] In summary, the server detection method provided in this application, at the data processing level, achieves real-time transmission and stable reception of PLM system engineering change information through WebSocket combined with distributed Kafka, ensures accurate docking of MES system material list through API interface, and enables flexible storage and dynamic updating of MongoDB database adaptation test guide file. At the same time, standardized field operations eliminate data format differences and naming chaos, ensuring both the efficiency and accuracy of cross-system data flow and providing a unified and structured data foundation for subsequent stages, avoiding information gaps or misjudgments caused by non-standard data.

[0100] At the test guide matching level, the system prioritizes calling EC_Rule(c) to replace the basic test guide file for engineering change information, calls Custom_Rule(c) to supplement the basic test guide file for bill of materials scenarios, and uses Base_Rule(c) when there is no special data, thus achieving precise adaptation of the test standard. In engineering change scenarios, it retains general rules while accurately covering change requirements, enhancing the traceability of the test standard; in bill of materials scenarios, it fills the gaps in the basic test guide file's coverage of special configurations, promoting dynamic optimization of the test guide library; and the basic test guide file fallback mechanism ensures the continuity of the test process when there are no special requirements. The three work together to ensure that there is a matching test standard to support different data scenarios.

[0101] At the hardware testing level, based on the target testing guidelines, automated processes enable rapid completion of various server tests, shortening the time from the start of inspection to obtaining results. This allows for timely feedback of hardware status information, ensuring strict alignment between testing actions and preset rules. Furthermore, quantitative indicators enhance the reliability and traceability of test results, providing standardized and precise execution methods for hardware quality control. Automated testing objectively and quantitatively determines whether a server meets standards, guaranteeing the reliability of test results and meeting the stringent reliability requirements of server hardware testing.

[0102] At the anomaly detection level, a design based on multi-dimensional test results and dynamic weighting coefficients to calculate confidence levels enables a comprehensive quantitative assessment of server status. Dynamic weights are updated periodically with fault data, ensuring that confidence level calculations align with actual fault patterns. This approach balances automation efficiency with accuracy; the machine quickly completes initial screening, while human intervention corrects potential algorithmic errors, ultimately achieving precise location and reliable identification of abnormal components.

[0103] Data processing provides the foundation for test guideline matching, test guideline matching provides standards for hardware testing, hardware testing provides data for anomaly detection, and anomaly detection, in turn, optimizes data processing and test rules, forming a complete technical closed loop. This system not only ensures the efficiency of data flow, the adaptability of test standards, and the accuracy of hardware testing in server lifecycle management, but also improves the reliability of anomaly detection through human-machine collaboration. Ultimately, it provides intelligent and comprehensive technical support for the entire process of server quality control from R&D and production to operation and maintenance, effectively reducing failure risks and improving management efficiency and resource utilization.

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

[0105] like Figure 4 As shown, embodiments of this application also provide a server detection device, which includes:

[0106] The acquisition module 401 is used to acquire the lifecycle management data of the server under test. The lifecycle management data includes at least one of the following: engineering change information, bill of materials, and basic test guidance documents.

[0107] Processing module 402 is used to determine the target test guidance file based on lifecycle management data; the target test guidance file is the test guidance file corresponding to the engineering change information, or the test guidance file obtained by supplementing the basic test guidance file based on the test guidance file corresponding to the bill of materials, or the basic test guidance file; wherein the test guidance file includes the components to be tested and test parameters of the server under test;

[0108] The inspection module 403 is used to inspect the server under test according to the target test guide document;

[0109] The determination module 404 is used to determine whether the server under test contains abnormal components based on the test results.

[0110] As an optional implementation provided in this application, the processing module 402 is specifically used for: when the lifecycle management data includes engineering change information, determining the test guidance document corresponding to the engineering change information as the target test guidance document; when the lifecycle management data does not include engineering change information but includes a bill of materials, supplementing the basic test guidance document according to the test guidance document corresponding to the bill of materials, so as to use the supplemented basic test guidance document as the target test guidance document; and when the lifecycle management data does not include engineering change information and a bill of materials, determining the basic test guidance document as the target test guidance document.

[0111] As an optional implementation provided in this application, the processing module 402 is further configured to: when the lifecycle management data includes engineering change information, determine the basic test guide file of the component under test from the historical test guide library according to the component under test corresponding to the engineering change information; and replace the basic test guide file with the test guide file corresponding to the engineering change information.

[0112] As an optional implementation provided in this application, the processing module 402 is specifically used to: determine the configuration information of the component under test according to the test guidance document corresponding to the bill of materials when the lifecycle management data does not include engineering change information but includes the bill of materials; and supplement the basic test guidance document according to the configuration information of the component under test.

[0113] As an optional implementation provided in this application, the verification module 403 is specifically used for: monitoring the power-on status information of the component under test; verifying whether the component under test has passed the component power-on test based on the power-on status information and the preset status information contained in the target test guidance document; and determining the component power-on test pass rate of the server under test.

[0114] As an optional implementation provided in this application, the inspection module 403 is specifically used for: collecting electrical parameters of the component under test; determining whether the component under test is qualified based on the electrical parameters and the preset tolerance range contained in the target test guidance document; and determining the electrical qualification rate of the components of the server under test.

[0115] As an optional implementation provided in this application, the verification module 403 is specifically used for: obtaining the configuration information of the component under test; calculating the component specification matching degree between the configuration information and the preset specifications contained in the target test guidance document; and determining whether there is an abnormal configuration in the server under test based on the component specification matching degree.

[0116] As an optional implementation provided in this application, the determination module 404 is specifically used to calculate the confidence level based on the inspection results; the inspection results include at least one of the following: component power-on test pass rate, component electrical qualification rate, and component specification matching degree; if the confidence level is less than the preset confidence level, the abnormal component of the server under test is located and a prompt message is generated to remind the user to perform a review; upon receiving the review instruction input by the user, a review operation is performed on the abnormal component.

[0117] As an optional implementation provided in this application, the device further includes a standardization module, used to convert the first field of the engineering change information into a standard field when the lifecycle management data includes engineering change information; and to parse the second field of the bill of materials to obtain structured data when the lifecycle management data includes a bill of materials.

[0118] For a description of the features in the embodiment corresponding to the server detection device, please refer to the relevant description in the embodiment corresponding to the server detection method, which will not be repeated here.

[0119] like Figure 5 As shown, embodiments of this application also provide an electronic device, including a memory 501 and a processor 502, wherein the memory 501 stores a computer program, and the processor 502 is configured to run the computer program to perform the steps in any of the above-described server detection method embodiments.

[0120] 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-described server detection method embodiments when it runs.

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

[0122] 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-described server detection method embodiments.

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

[0124] Those skilled in the art will further recognize that the units and algorithm steps of the various examples described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the components and steps of the various examples have been generally described in terms of functionality in the foregoing description. Whether these functions are implemented in hardware or software depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0125] The server detection method and electronic device provided in this application have been described in detail above. Specific examples have been used to illustrate the principles and implementation methods of this application. The descriptions of the embodiments above are only intended to help understand the method and core ideas of this application. It should be noted that those skilled in the art can make several improvements and modifications to this application without departing from the principles of this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. A server detection method, characterized by, The method comprises: acquiring life cycle management data of a to-be-tested server, the life cycle management data comprising at least one of engineering change information, a bill of materials, and a basic test guide file; determining a target test guide file according to the life cycle management data; the target test guide file being a test guide file corresponding to the engineering change information, or a test guide file obtained by supplementing the basic test guide file according to a test guide file corresponding to the bill of materials, or the basic test guide file; wherein the test guide file comprises to-be-tested components and test parameters of the to-be-tested server; performing inspection on the to-be-tested server according to the target test guide file, the inspection on the to-be-tested server comprising at least one of component power-on detection, electrical qualification detection, and product specification matching; determining whether the to-be-tested server contains abnormal components according to an inspection result.

2. The method of claim 1, wherein, The method further comprises: in a case where the life cycle management data comprises the engineering change information, determining a basic test guide file of a to-be-tested component corresponding to the engineering change information from a historical test guide library; replacing the basic test guide file with a test guide file corresponding to the engineering change information. The method further comprises:

3. The method of claim 2, wherein, in a case where the life cycle management data comprises the engineering change information, determining a basic test guide file of a to-be-tested component corresponding to the engineering change information from a historical test guide library; replacing the basic test guide file with a test guide file corresponding to the engineering change information. The method further comprises:

4. The method of claim 2, wherein, in a case where the life cycle management data comprises the engineering change information, determining a basic test guide file of a to-be-tested component corresponding to the engineering change information from a historical test guide library; replacing the basic test guide file with a test guide file corresponding to the engineering change information. The method further comprises:

5. The method of claim 1, wherein, monitoring power-on state information of the to-be-tested component; verifying whether the to-be-tested component passes the component power-on detection according to the power-on state information and preset state information contained in the target test guide file; determining a component power-on detection pass rate of the to-be-tested server. The method further comprises:

6. The method of claim 1, wherein, acquiring electrical parameters of the to-be-tested component; ​ determining whether the to-be-tested component is qualified according to the electrical parameter and a preset tolerance range contained in the target test guide file; determining a component electrical qualification rate of the to-be-tested server.

7. The method of claim 1, wherein, The verifying the to-be-tested server according to the target test guide file comprises: obtaining configuration information of the to-be-tested component; calculating a component specification matching degree between the configuration information and a preset specification contained in the target test guide file; determining whether the to-be-tested server has an abnormal configuration according to the component specification matching degree.

8. The method of claim 1, wherein, The determining whether the to-be-tested server contains an abnormal component according to the verification result comprises: calculating a confidence degree according to the verification result; the verification result comprises at least one of a component power-on detection pass rate, a component electrical qualification rate and a component specification matching degree; in a case where the confidence degree is less than a preset confidence degree, locating an abnormal component of the to-be-tested server and generating a prompt information, the prompt information being used to remind a user to review; in a case where a review instruction input by the user is received, performing a review operation on the abnormal component.

9. The method of claim 1, wherein, The method further comprises: in a case where the lifecycle management data comprises the engineering change information, converting a first field of the engineering change information into a standard field; in a case where the lifecycle management data comprises the bill of materials, performing parsing on a second field of the bill of materials to obtain structured data.

10. An electronic device, comprising: comprise: a memory, configured to store a computer program; a processor, configured to implement steps of the server detection method in any one of claims 1 to 9 when executing the computer program.

Images