Upgrade methods, control devices, and fault diagnosis equipment for fault diagnosis equipment

Abstract

This application proposes an upgrade method, control device, and fault diagnosis equipment for fault diagnosis devices, relating to the field of remote upgrade technology. The upgrade method includes: setting a first storage area as the current firmware storage area and a second storage area as the upgrade firmware storage area; acquiring current firmware data and target firmware data; downloading the target firmware data to the second storage area; in response to executing a device upgrade operation, retrieving the target firmware data from the second storage area and migrating it to the first storage area; running the target firmware data in the first storage area to determine the validity and integrity of the target firmware data; if the target firmware data fails verification or has migration anomalies, retrieving the target firmware data from the second storage area and migrating it to the first storage area again, until the migration is complete and verification passes. This application can improve upgrade reliability, adapt to upgrade needs in harsh power supply and network environments, reduce maintenance costs, and improve the reliability of firmware upgrades.

Description

Technical Field

[0001] This application relates to the field of remote upgrade technology, and in particular to an upgrade method, control device and fault diagnosis equipment for a fault diagnosis device. Background Technology

[0002] Blockchain server systems encompass various equipment types, including large-scale computing servers, distributed storage servers, and cryptocurrency servers. During continuous high-load operation, these servers are significantly affected by factors such as environmental temperature fluctuations, humidity changes, and natural hardware aging, frequently experiencing various operational failures. When failures occur, maintenance personnel typically rely on specialized diagnostic tools for detection and repair. However, traditional diagnostic tools only support single-brand or specific model devices, severely limiting their versatility in multi-brand mixed deployment environments and making it impossible to achieve unified diagnostics for server components from different manufacturers. To address this issue, a fault diagnosis device compatible with multiple brands and models has been developed. This device can adapt to diverse tested devices such as complete machines, power modules, and computing boards, enabling a standardized diagnostic process.

[0003] However, as manufacturers of the devices under test (DUTs) continuously optimize their product firmware and update communication protocols, diagnostic equipment must undergo simultaneous software upgrades to ensure that the diagnostic logic remains consistent with the latest version of the DUT. During actual upgrade implementation, especially in areas with unstable power supply (such as the high temperature and humidity environments of tropical countries where it is difficult to configure backup batteries for diagnostic equipment) and in scenarios with poor network conditions, remote firmware update operations are highly susceptible to unexpected interruptions such as communication link outages, abnormal power supply fluctuations, or storage media write failures. Such interruptions cause the upgrade process to terminate abruptly, leaving the firmware of the diagnostic equipment in an incomplete or corrupted state, leading to serious problems such as the device failing to boot or complete failure of diagnostic functions. In some cases, the equipment may even need to be returned to the factory for repair, resulting in prolonged interruptions to diagnostic services and a significant increase in maintenance costs. Current technologies lack reliable mechanisms to handle abnormal interruptions during the upgrade process, ensuring the integrity of firmware data and the continuous availability of the device, especially in harsh power supply and network environments where the risk of upgrade failure is extremely high. Summary of the Invention

[0004] The main objective of this invention is to provide an upgrade method for fault diagnosis equipment, which aims to avoid firmware damage caused by abnormal interruption during the upgrade process, improve upgrade reliability, adapt to upgrade requirements in harsh power supply and network environments, reduce operation and maintenance costs, and improve the reliability of firmware upgrades.

[0005] To achieve the above objectives, the present invention provides an upgrade method for a fault diagnosis device, wherein the fault diagnosis device has a first storage area and a second storage area, and the upgrade method for the fault diagnosis device includes: Set the first storage area as the current firmware storage area, and set the second storage area as the upgrade firmware storage area; Obtain the current firmware data in the first storage area and the target firmware data in the remote management backend that differs from the current firmware data; If the target firmware data exists, download the target firmware data to the second storage area; In response to performing a device upgrade operation, the target firmware data in the second storage area is retrieved and migrated to the first storage area; After the migration is completed, the target firmware data in the first storage area is run to determine the validity and integrity of the target firmware data; If the target firmware data fails verification or has an abnormal migration, the target firmware data in the second storage area is retrieved again and migrated to the first storage area until the migration is completed and the verification is successful.

[0006] Optionally, obtaining the current firmware data in the first storage area and the target firmware data in the remote management backend that differs from the current firmware data includes: Obtain the model information and current firmware data of the device under test or component under test connected to the fault diagnosis device; Upload the model information and the current firmware data to the remote management backend; Receive metadata about candidate firmware data returned by the remote management backend based on the model information and the current firmware data; The meta-information is compared with the version feature field of the current firmware data in the first storage area. If the version feature field is inconsistent, the candidate firmware data is marked as the target firmware data.

[0007] Optionally, if the target firmware data exists, downloading the target firmware data to the second storage area includes: In response to an upgrade instruction request for the fault diagnosis device, a firmware acquisition request is sent to the remote management backend based on the model information and the target firmware version identifier. The remote management backend receives target firmware data corresponding to the model information and target firmware version identifier based on the firmware acquisition request; In the second storage area, an independent write task instance is created. The write task instance allocates a contiguous storage space within the second storage area and divides the received target firmware data into multiple firmware data blocks according to a preset data block size. Each firmware data block is sequentially written into the contiguous space allocated in the second storage area until all firmware data blocks have been written.

[0008] Optionally, if the target firmware data exists, downloading the target firmware data to the second storage area includes: When the fault diagnosis device is powered on for the first time or the device feature code of the device under test is first identified, the firmware preloading thread is activated. The firmware preloading thread is used to initiate a firmware data synchronization request to the remote management background. Run the firmware preloading thread to send a firmware download request to the remote management backend; Listen for the target firmware data returned by the remote management backend.

[0009] Optionally, the step of retrieving target firmware data from the second storage area and migrating it to the first storage area in response to performing a device upgrade operation includes: Before performing the migration operation, a status query instruction is sent to the first storage area, and the current execution status parameters returned by the first storage area in response to the status query instruction are received. The current execution status parameters include whether the first storage area is being read by the processor for diagnostic tasks. If the current execution status parameter indicates that the first storage area is busy, the migration operation is suspended, and after a preset time interval, the status query instruction is repeatedly sent to the first storage area until the current execution status parameter indicates that the first storage area is idle. When the first storage area is idle, the target firmware data in the second storage area is divided into several sequentially arranged migration units, and the migration units are written to the corresponding addresses in the first storage area one by one in the order of the migration units.

[0010] Optionally, after the migration is completed, the target firmware data in the first storage area is processed to determine the validity and integrity of the target firmware data, including: After the migration is completed, the diagnostic logic core segment contained in the target firmware data is extracted from the first storage area, and the diagnostic logic core segment is loaded into a temporary running sandbox in the processor. In the temporary running sandbox, a set of preset standard diagnostic input signal sequences are invoked to drive the diagnostic logic core segment to process each input signal and capture the output signal sequence generated during the processing. The output signal sequence is compared bit by bit with the standard output signal sequence corresponding to the target firmware data provided in advance by the remote management backend. If all bits match, the target firmware data is determined to be valid and complete. If there are mismatched bits, the target firmware data is determined to be invalid or incomplete, and the migrated target firmware data in the first storage area is erased, restoring the current firmware data before migration.

[0011] Optionally, if the target firmware data fails verification or has an migration anomaly, the step of retrieving the target firmware data from the second storage area and migrating it to the first storage area until the migration is complete and verification passes includes: When a failed data segment with a verification failure is detected in the target firmware data in the first storage area, the logical address range of the failed data segment in the first storage area is recorded. Determine a target logical address range from the second storage area that maps to the logical address range of the failed data, and migrate the data corresponding to the target logical address range back to the corresponding position in the first storage area to replace the failed data segment; After the replacement is completed, the replaced data segment is independently verified. If the verification fails, the second migration and verification loop is re-executed until the migration is completed and the verification passes. If the number of migration and verification cycles exceeds a preset threshold, the firmware in the first storage area will be restored to the current firmware data, and a corresponding fault alarm message will be generated. Display the fault alarm information.

[0012] Optionally, setting the first storage area as the current firmware storage area and setting the second storage area as the upgrade firmware storage area includes: Obtain the stored configuration information of the fault diagnosis device at startup; Based on the storage configuration information, the starting address of the first storage area is mapped to the firmware running entry point, and the starting address of the second storage area is mapped to the firmware upgrade program entry point; Establish a mapping table between the first storage area and the second storage area. The mapping table records the mapping relationship between the address of each storage block in the first storage area and the address of the corresponding backup storage block in the second storage area.

[0013] Furthermore, to achieve the above objectives, the present invention also provides a control device, the control device comprising: a memory, a processor, and an upgrade program for a fault diagnosis device stored in the memory and executable on the processor, the upgrade program for the fault diagnosis device being configured to implement the upgrade method for the fault diagnosis device as described above.

[0014] In addition, to achieve the above objectives, the present invention also provides a fault diagnosis device, including the control device described above.

[0015] The fault diagnosis device of this invention has a first storage area and a second storage area. The upgrade method of the fault diagnosis device sets the first storage area as the current firmware storage area and the second storage area as the upgrade firmware storage area. It then obtains the current firmware data in the first storage area and the target firmware data (which differs from the current firmware data) from the remote management backend. If the target firmware data exists, it downloads the target firmware data to the second storage area. In response to the device upgrade operation, it retrieves the target firmware data from the second storage area and migrates it to the first storage area. After migration, it runs the target firmware data in the first storage area to determine its validity and integrity. If the target firmware data fails verification or the migration is abnormal, it retrieves the target firmware data from the second storage area again and migrates it to the first storage area until the migration is complete and the verification passes. Thus, by dividing the current firmware running storage area and the upgrade backup storage area, writing the target firmware to the backup storage area first and then migrating it to the running storage area, and performing validity verification after migration, and allowing for re-migration or restoration of the original firmware in case of an anomaly, it effectively avoids upgrade failures and device downtime caused by network, power, or storage anomalies during the upgrade process, reducing maintenance costs and improving firmware upgrade reliability. Attached Figure Description

[0016] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0017] Figure 1 This is a schematic diagram of an upgrade method for a fault diagnosis device according to an embodiment of the present invention; Figure 2 This is a schematic diagram of an upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 3 This is a schematic diagram of an upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 4 This is a schematic diagram of the upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 5 This is a schematic diagram of an upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 6 This is a schematic diagram of an upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 7 This is a schematic diagram of an upgrade method for a fault diagnosis device according to another embodiment of the present invention; Figure 8 This is a schematic diagram of the upgrade method for a fault diagnosis device according to another embodiment of the present invention.

[0018] The realization of the objective, functional features and advantages of the present invention will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0019] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, not all embodiments. Well-known modules, units, and their connections, links, communications, or operations are not shown or described in detail. Furthermore, the described features, architectures, or functions can be combined in any way in one or more embodiments. Those skilled in the art should understand that the various embodiments described below are only for illustrative purposes and not for limiting the scope of protection of the present invention. It is also readily understood that the modules, units, or processing methods in the various embodiments described herein and shown in the accompanying drawings can be combined and designed in various different configurations. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0020] Blockchain server systems encompass various equipment types, including large-scale computing servers, distributed storage servers, and cryptocurrency servers. During continuous high-load operation, these servers are significantly affected by factors such as environmental temperature fluctuations, humidity changes, and natural hardware aging, frequently experiencing various operational failures. When failures occur, maintenance personnel typically rely on specialized diagnostic tools for detection and repair. However, traditional diagnostic tools only support single-brand or specific model devices, severely limiting their versatility in multi-brand mixed deployment environments and making it impossible to achieve unified diagnostics for server components from different manufacturers. To address this issue, the industry has developed fault diagnosis equipment compatible with multiple brands and models. This equipment can adapt to diverse tested devices such as complete machines, power modules, and computing boards, enabling a standardized diagnostic process.

[0021] However, as manufacturers of the devices under test (DUTs) continuously optimize their product firmware and update communication protocols, diagnostic equipment must undergo simultaneous software upgrades to ensure that the diagnostic logic remains consistent with the latest version of the DUT. During actual upgrade implementation, especially in areas with unstable power supply (such as the high temperature and humidity environments of tropical countries where it is difficult to configure backup batteries for diagnostic equipment) and in scenarios with poor network conditions, remote firmware update operations are highly susceptible to unexpected interruptions such as communication link outages, abnormal power supply fluctuations, or storage media write failures. Such interruptions cause the upgrade process to terminate abruptly, leaving the firmware of the diagnostic equipment in an incomplete or corrupted state, leading to serious problems such as the device failing to boot or complete failure of diagnostic functions. In some cases, the equipment may even need to be returned to the factory for repair, resulting in prolonged interruptions to diagnostic services and a significant increase in maintenance costs. Current technologies lack reliable mechanisms to handle abnormal interruptions during the upgrade process, ensuring the integrity of firmware data and the continuous availability of the device, especially in harsh power supply and network environments where the risk of upgrade failure is extremely high.

[0022] It's important to note that in the current blockchain server repair industry, firmware upgrades for fault diagnosis equipment are generally handled using official jigs. These jigs typically employ wired or card-based upgrade methods. While some companies that have developed their own jigs have attempted wireless upgrade solutions, they are still limited by the weak power and network infrastructure in many third-world countries or overseas regions, resulting in unstable wireless signals and frequent power outages, leading to an upgrade success rate of less than 40%. To address this issue, many repair companies often dispatch engineers with specialized jigs to manually upgrade on-site when wireless upgrades are not immediately possible. However, this method often results in delayed firmware updates, causing diagnostic logic to lag behind the new device firmware version, increasing false alarm rates, decreasing compatibility, and continuously declining diagnostic accuracy, ultimately affecting the delivery quality and timeliness of the entire repair production line. Another approach is to use built-in batteries for backup power to ensure upgrade completion. However, due to the miniaturized design of the devices and battery degradation issues in harsh environments such as high temperature and humidity, built-in battery solutions have an average lifespan of less than 6 months in tropical regions, leading to frequent battery replacements that exacerbate the maintenance burden and costs. In areas with weak network infrastructure, many attempts to improve connectivity by adding signal enhancement modules, satellite communication modules, or edge computing nodes to fault diagnosis equipment have been hampered by a sharp increase in power consumption and power supply pressure. Furthermore, these modules age rapidly in high-temperature and high-humidity environments, resulting in a failure rate exceeding 35% in actual deployments, thus becoming new points of failure. More importantly, these modules are costly, with a single unit costing 18% more than the price of the entire device, significantly increasing the already low-profit margins of repair services. Moreover, the problem of consistency recovery after firmware upgrade interruptions remains unresolved.

[0023] The main solution of this application embodiment is as follows: by setting the first storage area as the current firmware storage area and the second storage area as the upgrade firmware storage area, the current firmware data in the first storage area and the target firmware data in the remote management background that differs from the current firmware data are obtained. If the target firmware data exists, the target firmware data is downloaded to the second storage area. In response to the device upgrade operation, the target firmware data in the second storage area is retrieved and migrated to the first storage area. After the migration is completed, the target firmware data in the first storage area is run to determine the validity and integrity of the target firmware data. If the target firmware data fails to be verified or the migration is abnormal, the target firmware data in the second storage area is retrieved again and migrated to the first storage area until the migration is completed and the verification is successful.

[0024] In this embodiment, for ease of description, the following description will focus on the control device as the executing entity.

[0025] This application provides a solution that divides the current firmware running storage area and the upgrade backup storage area into separate areas. The target firmware is first written to the backup storage area and then migrated to the running storage area. After the migration, the validity is verified. In case of an anomaly, the original firmware can be re-migrated or restored. This solution can effectively avoid upgrade failures and device downtime caused by network, power or storage anomalies during the upgrade process, reduce maintenance costs and improve the reliability of firmware upgrades.

[0026] Therefore, the present invention proposes an upgrade method for fault diagnosis equipment; it is understood that the fault diagnosis equipment is equipped with a control device for storing and executing the following method. The control device can be implemented using a main controller, such as MCU (Micro Controller Unit), DSP (Digital Signal Processor), FPGA (Field Programmable Gate Array), SOC (System On Chip), etc.

[0027] When performing software upgrades on existing fault diagnosis equipment, especially in scenarios with unstable power supply or poor network conditions, remote firmware update operations are prone to unexpected interruptions such as communication link outages, abnormal power supply fluctuations, or storage media write failures. Such interruptions cause the upgrade process to terminate abruptly, leaving the firmware of the fault diagnosis equipment in an incomplete or corrupted state, which in turn leads to serious problems such as the equipment failing to boot and diagnostic functions failing, resulting in service interruptions and increased maintenance costs.

[0028] Therefore, referring to Figure 1In one embodiment of the present invention, the fault diagnosis device is provided with a first storage area and a second storage area, and the upgrade method of the fault diagnosis device includes steps S100-S600, wherein: S100: Set the first storage area as the current firmware storage area, and set the second storage area as the upgrade firmware storage area; S200: Obtain the current firmware data in the first storage area and the target firmware data in the remote management backend that differs from the current firmware data; S300: Write the target firmware data completely into the second storage area. S300: If the target firmware data exists, download the target firmware data to the second storage area; S400, in response to performing a device upgrade operation, retrieve the target firmware data in the second storage area and migrate it to the first storage area; S500: After the migration is completed, run the target firmware data in the first storage area to determine the validity and integrity of the target firmware data. S600. If the target firmware data fails verification or has an abnormal migration, the target firmware data in the second storage area is retrieved again and migrated to the first storage area until the migration is completed and the verification is successful.

[0029] In this context, a fault diagnosis device refers to a dedicated hardware or software system used to detect, analyze, and identify various operational faults in equipment. This device connects to the device or component under test (DUT), assesses its operational status through pre-defined diagnostic logic and algorithms, and outputs fault information or a diagnostic report. The first storage area refers to the main storage area within the fault diagnosis device used to store currently running firmware data. This first storage area is typically directly accessed by the processor to execute the device's core functions and diagnostic tasks. The second storage area refers to the auxiliary storage area within the fault diagnosis device used to store the target firmware data to be upgraded. Write operations to the second storage area are independent of the operating status of the first storage area, ensuring that while fault diagnosis tasks continue to be executed in the first storage area, the second storage area can safely and completely complete the writing of the target firmware data.

[0030] The current firmware storage area is designated as the storage area for storing the firmware data currently running on the diagnostic device, typically corresponding to the first storage area. The upgrade firmware storage area is designated as the storage area for storing the target firmware data to be installed or activated, typically corresponding to the second storage area. Current firmware data refers to all program code, configuration parameters, and diagnostic logic contained in the firmware version currently running on the diagnostic device. Target firmware data refers to the new firmware version used to replace the current firmware data, which typically includes fixes for existing functionalities, performance optimizations, or the introduction of new features. The remote management backend is a centralized server system used to store, manage, and distribute firmware versions of the diagnostic device. This backend can receive firmware update requests from the device and provide the corresponding firmware data.

[0031] Device upgrade operation refers to the process triggered by the user or system to migrate target firmware data from the upgrade firmware storage area to the current firmware storage area and activate the new firmware to replace the old firmware. Verification failure refers to a situation where, after firmware data migration or operation, a preset verification mechanism (such as CRC check, MD5 check, or functional testing) discovers that the firmware data is corrupted, incomplete, or does not behave as expected. Migration anomaly refers to a situation where, during the transfer of firmware data from one storage area to another, data transmission is interrupted, data is lost, or data is written incorrectly due to hardware failure, software errors, or external interference.

[0032] This embodiment first configures the storage structure of the fault diagnosis device. As one implementation, this setting can be accomplished using default configuration parameters loaded during device startup, or by the system administrator manually specifying the role of each storage area during device initialization. For example, at the factory, the first storage area can be pre-configured for running firmware, and the second storage area can be used to store firmware to be upgraded.

[0033] One approach is to obtain current firmware data and target firmware data manually by the device operator, who then compares and identifies available new firmware versions through a remote management interface. For example, the operator can log in to the remote management interface, view the latest firmware list for the current device model, and compare it with the firmware version running on the device to determine if there is target firmware data that needs to be upgraded.

[0034] When the target firmware data is identified and its existence is confirmed, this embodiment will download the target firmware data to the second storage area. As one implementation, this download operation can be manually triggered by the user through the user interface of the fault diagnosis device. The device then retrieves the target firmware data from a remote management backend via a network connection and writes it completely to the second storage area. During this process, the second storage area operates independently of the first storage area, ensuring that the current diagnostic task is not affected.

[0035] In response to performing a device upgrade operation, this embodiment migrates the target firmware data from the second storage area to the first storage area. As one implementation, this migration operation can be initiated immediately after the user explicitly issues an upgrade command. The control device directly copies the complete target firmware data block stored in the second storage area to the first storage area, overwriting the existing current firmware data. After completing the data migration, the device can attempt to restart and load the new firmware. If the device can start normally and enter a working state, the target firmware data is considered valid and complete. Conversely, if the device fails to start or exhibits abnormal behavior, the target firmware data is considered invalid or incomplete. When a new firmware startup failure or abnormal operation is detected, the system will automatically trigger a complete retry mechanism, migrating the target firmware data from the second storage area to the first storage area again. This retry process will continue until the new firmware can be successfully migrated and start normally.

[0036] The upgrade method for the fault diagnosis device in this embodiment divides the firmware upgrade process into two stages: downloading to an independent storage area and migrating as needed. It also incorporates post-migration validity and integrity verification and a failure retry mechanism. This effectively avoids firmware corruption caused by upgrade interruptions in environments with unstable power supply or poor network conditions. Therefore, it improves the reliability of firmware upgrades for the fault diagnosis device, ensures stable operation of the device during the upgrade process, and reduces service interruptions and maintenance costs caused by upgrade failures.

[0037] This embodiment mainly divides the system into a first storage area and a second storage area. The first is the storage area for normal operation, and the second is the storage area used for upgrade backup. When an upgrade is needed, the data is first stored in the second storage area to avoid affecting the normal operation of the first storage area. The write operation of the second storage area is independent of the operating state of the first storage area, thereby ensuring that while the first storage area continues to perform fault diagnosis tasks, the second storage area can safely and completely complete the writing of the target firmware data. After the second storage area completes the write operation, once the verification is successful, it is checked whether the first storage area is performing the current firmware data diagnosis task. If the first storage area is detected to be in a non-idle state, the migration is not performed immediately, but waits for it to become idle before seamlessly switching over. If the first storage area is detected to be idle, the migration process is immediately started to ensure that the device diagnosis service is uninterrupted and the upgrade process is seamless. Furthermore, this design can effectively avoid upgrade failures or device downtime caused by factors such as network, power, or storage area failures. Of course, if the upgrade failure is caused by a failure of the first or second storage area, or by the presence of bad sectors or dead sectors, other methods will be used to solve the problem, which is not within the scope of this application.

[0038] The fault diagnosis device in this embodiment has a first storage area and a second storage area. The upgrade method of the fault diagnosis device sets the first storage area as the current firmware storage area and the second storage area as the upgrade firmware storage area. It then obtains the current firmware data in the first storage area and the target firmware data (which differs from the current firmware data) from the remote management backend. If the target firmware data exists, it downloads the target firmware data to the second storage area. In response to the device upgrade operation, it retrieves the target firmware data from the second storage area and migrates it to the first storage area. After migration, it runs the target firmware data in the first storage area to determine its validity and integrity. If the target firmware data fails verification or the migration is abnormal, it retrieves the target firmware data from the second storage area again and migrates it to the first storage area until the migration is complete and the verification passes. Thus, by dividing the current firmware running storage area and the upgrade backup storage area, writing the target firmware to the backup storage area first and then migrating it to the running storage area, and performing validity verification after migration, and allowing for re-migration or restoration of the original firmware in case of an anomaly, it effectively avoids upgrade failures and device downtime caused by network, power, or storage anomalies during the upgrade process, reducing maintenance costs and improving firmware upgrade reliability.

[0039] In practice, simply acquiring firmware data in a general way may result in downloading unnecessary firmware or failing to accurately identify the latest firmware that matches the current diagnostic device and the connected diagnostic device or component under test, thus affecting upgrade efficiency and accuracy.

[0040] Therefore, referring to Figure 2Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 1 The illustrated embodiment obtains current firmware data in the first storage area and target firmware data in the remote management backend that differs from the current firmware data, including steps S210-S240, wherein: S210. Obtain the model information and current firmware data of the device under test or component under test connected to the fault diagnosis device. S220. Upload the model information and the current firmware data to the remote management backend; S230. Receive the metadata of candidate firmware data returned by the remote management backend based on the model information and the current firmware data; S240. Compare the metadata with the version feature field of the current firmware data in the first storage area. If the version feature field is inconsistent, mark the candidate firmware data as the target firmware data.

[0041] In this embodiment, when acquiring the model information and current firmware data of the device under test (DUT) or component under test connected to the fault diagnosis device, the fault diagnosis device can establish a connection with the DUT through its built-in communication interface, such as USB, CAN bus, Ethernet, or a proprietary diagnostic interface. Once the connection is established, the fault diagnosis device sends a query command to read detailed information such as the unique identifier, manufacturer information, product model, and hardware version of the DUT or component under test to obtain its precise model information. Furthermore, the fault diagnosis device reads key data such as the version number, release date, and checksum of the currently running firmware from its first storage area as the current firmware data. This embodiment requires obtaining the corresponding brand and model, such as a server from brand A (V1.0 version) or a power supply from brand B (V1.2 version), before determining the target firmware data that differs. When uploading the model information and current firmware data to the remote management backend, the fault diagnosis device establishes a secure communication channel with the remote management backend through its network module (such as Wi-Fi, cellular network, or wired Ethernet interface). The fault diagnosis device encapsulates the obtained model information of the fault diagnosis device or component under test, along with its own current firmware data, for example, using JSON or XML format, and sends it to the remote management backend via an encrypted protocol (such as HTTPS). This is intended to provide the remote management backend with the detailed current status of the fault diagnosis device, enabling the backend to perform accurate firmware matching.

[0042] When receiving metadata about candidate firmware data returned by the remote management backend based on the model information and matching it with the current firmware data, the remote management backend, upon receiving information uploaded by the fault diagnosis device, will search its firmware database based on this information. First, the backend will filter out all compatible firmware versions based on the model information; second, it will further filter out firmware versions that are newer or better than the current version based on the current firmware data (such as version number). The remote management backend will not directly send the complete firmware file, but will return metadata about these candidate firmware files, such as the firmware's unique identifier, version number, release date, file size, digital signature or checksum, and a brief update description. This metadata is returned to the fault diagnosis device in the form of a lightweight data packet.

[0043] When comparing the version feature fields of the metadata with the current firmware data in the first storage area, and if the version feature fields are inconsistent, the candidate firmware data is marked as target firmware data. After receiving the candidate firmware metadata returned by the remote management backend, the fault diagnosis device parses this metadata and extracts the version feature fields, such as version number, revision number, or release timestamp. Simultaneously, the fault diagnosis device extracts the version feature fields corresponding to the currently running firmware from its first storage area. Subsequently, the fault diagnosis device performs a comparison operation, such as comparing the version number or the release timestamp. If the comparison result shows that the version feature fields of the candidate firmware are inconsistent with those of the current firmware (e.g., the candidate firmware has a higher version number or a later release date), it indicates that an available update exists. In this case, the candidate firmware data will be marked as target firmware data by the system for subsequent download and upgrade.

[0044] Through the above technical solution, the fault diagnosis equipment can first obtain precise model information and current firmware data of itself and the connected fault diagnosis equipment or component under test. Then, this key information is uploaded to a remote management backend, enabling the backend to perform accurate matching based on this information and return metadata of candidate firmware data that matches the actual needs of the fault diagnosis equipment. Locally, by comparing this metadata with the version characteristic field of the current firmware data in the first storage area, it can accurately determine whether there is target firmware data that needs to be updated. This mechanism avoids blindly downloading irrelevant firmware, ensuring that the acquired target firmware data is optimized for a specific fault diagnosis equipment model and current firmware version, thereby significantly improving the accuracy and efficiency of firmware upgrades, reducing unnecessary network bandwidth consumption and storage space waste, and laying a solid foundation for subsequent firmware download and migration operations.

[0045] In practical applications, ensuring that the download process of the target firmware data is accurate, efficient, and does not interfere with the existing diagnostic tasks of the fault diagnosis equipment, while effectively managing the storage resources of the second storage area, are technical problems that need to be solved.

[0046] Therefore, referring to Figure 3 Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 2 In the illustrated embodiment, if the target firmware data exists, downloading the target firmware data to the second storage area includes steps S310-S340, wherein: S310. In response to the upgrade instruction request for the fault diagnosis device, a firmware acquisition request is sent to the remote management backend based on the model information and the target firmware version identifier. S320: Receive the target firmware data corresponding to the model information and target firmware version identifier from the remote management backend based on the firmware acquisition request; S330. Create an independent write task instance in the second storage area. The write task instance allocates a contiguous storage space within the second storage area and divides the received target firmware data into multiple firmware data blocks according to a preset data block size. S340. Write each firmware data block sequentially into the continuous space allocated in the second storage area until all firmware data blocks have been written.

[0047] This embodiment responds to a user's request by performing a specific download, specifically in response to an "upgrade command request." This upgrade command request can be issued by the user through the fault diagnosis device interface, a remote management platform, or a preset automation strategy. When sending the request, the control device utilizes previously acquired "model information" and a determined "target firmware version identifier" to ensure that the firmware data requested from the remote management backend is precisely matched to the current fault diagnosis device model and has the correct version, thereby avoiding the download of incorrect or incompatible firmware.

[0048] After the fault diagnosis device sends a firmware retrieval request, the remote management backend matches the "model information" and "target firmware version identifier" contained in the request and transmits the corresponding "target firmware data" back to the fault diagnosis device. This is typically accomplished by establishing a secure network connection and data transmission protocol to ensure the integrity and security of data transmission.

[0049] Creating an "independent write task instance" means that the firmware data write operation runs as a separate process or thread, isolated from other core functions of the fault diagnosis device (especially the diagnostic tasks in the first storage area), thereby avoiding resource contention and mutual interference. This write task instance pre-allocates a contiguous storage space in the "second storage area," which helps optimize write performance, reduce storage fragmentation, and provide a clean and efficient area for subsequent firmware data storage. Simultaneously, the received "target firmware data" is divided into multiple firmware data blocks according to a preset block size, allowing data transmission and storage to be performed in blocks, facilitating management, error detection, and breakpoint resumption, thus improving download robustness.

[0050] After allocating contiguous storage space and dividing the data into blocks, the system writes each firmware data block sequentially into the corresponding contiguous space in the second storage area. This process continues until all firmware data blocks have been successfully written, ensuring the integrity and correctness of the target firmware data. A verification mechanism may be included during the writing process to ensure the accuracy of each data block being written.

[0051] Through the above technical solutions, the fault diagnosis equipment can download target firmware data in a controlled and efficient manner. First, by responding to explicit upgrade command requests and combining precise model information with the target firmware version identifier, the accuracy of the downloaded firmware is ensured, avoiding the risk of version mismatch or incorrect firmware. Second, an independent write task instance is created in the second storage area, and contiguous storage space is pre-allocated, completely isolating the firmware download and write process from the diagnostic tasks being executed in the first storage area. This effectively avoids resource conflicts and performance degradation, ensuring that the fault diagnosis equipment can still stably provide diagnostic services during the download. Furthermore, dividing the target firmware data into multiple data blocks and writing them sequentially not only improves the efficiency of data transmission and storage but also enhances the robustness of the download process, such as supporting breakpoint resumption and partial error recovery. This significantly improves the reliability and user experience during the firmware upgrade preparation phase and reduces the risk of upgrade failure due to download issues.

[0052] In practical applications, if the firmware download process relies on manual triggering by the user or passive response during the operation of the fault diagnosis device, the fault diagnosis device may not be able to obtain the latest firmware version in a timely manner when it is used for the first time or when identifying a new fault diagnosis device, thus affecting diagnostic efficiency and user experience. This lag may prevent the fault diagnosis device from providing optimal performance at critical moments, and may even require additional operations to ensure that the firmware is up-to-date.

[0053] Therefore, referring to Figure 4 Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 1 In the illustrated embodiment, if the target firmware data exists, the target firmware data is downloaded to the second storage area, including steps S350-S370, wherein: S350. When the fault diagnosis device is powered on for the first time or the device feature code of the device under test is first identified, the firmware preloading thread is activated. The firmware preloading thread is used to initiate a firmware data synchronization request to the remote management background. S360. Run the firmware preloading thread to send a firmware download request to the remote management backend; S370. Listen for the target firmware data returned by the remote management backend.

[0054] When the diagnostic device powers on for the first time or first identifies the diagnostic device's fault code, the control device activates a firmware pre-loading thread. "Initial power-on" refers to the initial stage when the diagnostic device resumes operation after a complete power outage; system resources are relatively idle at this time, making it an ideal time for background tasks. "First identification of the diagnostic device's fault code" refers to the diagnostic device automatically downloading firmware upon connecting to or scanning a new, previously undiagnosed device or component, by reading its unique identifier (such as serial number, model, firmware version, etc.). Activating the firmware pre-loading thread typically involves creating a separate, low-priority process or thread in the background, responsible for subsequent firmware synchronization requests. This thread initiates firmware data synchronization requests to the remote management backend. The firmware pre-loading thread monitors the diagnostic task load status of the diagnostic device in the background and initiates firmware data synchronization requests to the remote management backend during idle time windows when the diagnostic task load is below a preset load threshold. For example, when CPU utilization is below 20% and memory utilization is below 50%, the system can be considered to be in an idle state. If it is the first boot, other tasks are interrupted directly, and firmware upgrade is performed first to ensure that the fault diagnosis equipment has the latest functions before being put into use.

[0055] Based on this, upon receiving a synchronization response from the remote management backend (indicating new firmware is available), the firmware preloading thread constructs a standard HTTP / HTTPS request or uses a specific communication protocol to request the download of the target firmware data. The request typically includes information such as the target firmware version identifier and the fault diagnosis device model, so that the remote management backend can accurately provide the corresponding firmware package. Furthermore, the fault diagnosis device listens for the target firmware data returned by the remote management backend. After sending the download request, the firmware preloading thread needs to continuously monitor the network connection and receive the target firmware data stream transmitted from the remote management backend. During the reception process, data integrity verification (such as CRC checksum and MD5 checksum) can be performed to ensure that the received data is not corrupted. The received data is temporarily stored in the fault diagnosis device's buffer and then written to the secondary storage area.

[0056] Through the above technical solution, this embodiment enables automatic and proactive synchronization and download of firmware data. This mechanism allows the fault diagnosis equipment to silently acquire and prepare the latest firmware version in the background without manual user intervention when it is put into use or faces new diagnostic scenarios. Especially by downloading during idle time windows with low diagnostic task load, or prioritizing execution upon initial startup, it effectively avoids problems such as low diagnostic efficiency or incomplete functionality caused by outdated firmware versions. This not only improves the intelligence level and user experience of the fault diagnosis equipment but also ensures that the equipment always operates in optimal condition, thereby improving the accuracy and reliability of fault diagnosis while minimizing interference with normal diagnostic tasks.

[0057] Upon receiving an upgrade command, the fault diagnosis equipment attempts to migrate the target firmware data from the second storage area to the first storage area. However, in practical applications, the first storage area may be performing critical diagnostic tasks. If firmware migration is performed directly at this time, it may lead to interruption of the diagnostic task, data corruption, or even equipment failure, severely affecting the continuity and reliability of the fault diagnosis service.

[0058] Therefore, referring to Figure 5 The present invention also provides an embodiment of an upgrade method for a fault diagnosis device, based on the above. Figure 1 The illustrated embodiment, in response to performing a device upgrade operation, retrieves target firmware data from the second storage area and migrates it to the first storage area, including steps S410-S430, wherein: S410. Before performing the migration operation, a status query instruction is sent to the first storage area, and the current execution status parameters returned by the first storage area in response to the status query instruction are received. The current execution status parameters include whether the first storage area is being read by the processor for diagnostic tasks. S420. If the current execution status parameter indicates that the first storage area is in a busy state, suspend the migration operation and repeatedly send a status query instruction to the first storage area after a preset time interval until the current execution status parameter indicates that the first storage area is in an idle state. S430. When the first storage area is idle, the target firmware data in the second storage area is divided into several sequentially arranged migration units, and the migration units are written to the corresponding addresses in the first storage area one by one according to the order of the migration units.

[0059] Before performing the migration operation, the fault diagnosis device sends a status query command to the first storage area and receives the current execution status parameter returned by the first storage area in response to the status query command. This current execution status parameter explicitly indicates whether the first storage area is being read by the processor for diagnostic tasks. Specifically, before initiating the firmware migration operation, the fault diagnosis device proactively sends a status query command to the first storage area. This status query command aims to obtain the current operating status of the first storage area to determine whether it is being read or written by the processor to execute diagnostic tasks. Upon receiving this command, the first storage area responds and returns a current execution status parameter. This current execution status parameter is a quantitative representation of the internal state of the first storage area; for example, it can be a Boolean flag indicating "busy" or "idle," or it can be a structure containing more detailed information, such as the currently executing task ID, remaining task quantity, etc. The core of this parameter is to explicitly indicate whether the first storage area is being read by the processor for diagnostic tasks. For example, when the processor is loading diagnostic logic, reading diagnostic configuration, or storing diagnostic results from the first storage area, the first storage area is considered to be in a busy state. In terms of implementation, status queries and parameter returns can be performed between the main processor and the controller of the first memory area through hardware registers, memory-mapped I / O, or dedicated communication protocols.

[0060] If the current execution status parameter indicates that the first storage area is busy, the fault diagnosis device will suspend the migration operation and repeatedly send a status query command to the first storage area after a preset time interval until it receives a current execution status parameter indicating that the first storage area is idle. When the received current execution status parameter indicates that the first storage area is busy, the fault diagnosis device will not immediately execute the firmware migration operation, but will suspend the migration operation. "Suspending" means pausing the current migration process and waiting for a suitable opportunity. To avoid indefinite waiting, the control device will send a status query command to the first storage area again after a preset time interval. This process will be repeated to form a polling mechanism until the current execution status parameter returned by the first storage area indicates that it is idle. The preset time interval needs to take into account the real-time requirements of the diagnostic task and the timeliness requirements of the upgrade, and can be set to tens of milliseconds to several seconds. This mechanism ensures that the operation will not be forcibly interrupted when the first storage area is busy, thereby ensuring the integrity of the diagnostic task and the stability of the fault diagnosis device.

[0061] When the first storage area is idle, the fault diagnosis device divides the target firmware data in the second storage area into several sequentially arranged migration units, and writes each migration unit to its corresponding address in the first storage area in that order. Once the first storage area is confirmed to be idle, the fault diagnosis device initiates the actual firmware migration process. Before this, the target firmware data already downloaded in the second storage area is divided into several sequentially arranged migration units. These migration units can be fixed-size data blocks or modules logically divided according to the firmware structure. The purpose of dividing the data into migration units is to facilitate management and control of the migration process, and to make it easier to resume or roll back even if an accident occurs during the migration process. Subsequently, the control device writes each of these migration units to its corresponding address in the first storage area in a preset order. The "corresponding address" refers to the logical or physical storage location where the target firmware data should occupy in the first storage area. This method of writing one by one, combined with the previous idle state detection, further reduces the risk of errors during the migration process and allows for finer-grained error detection and handling during the writing process.

[0062] Through the above technical solution, the fault diagnosis equipment can intelligently determine the current operating status of the first storage area when performing firmware upgrade operations. When the first storage area is busy with diagnostic tasks, the system will actively suspend firmware migration and continuously monitor its status until the first storage area is idle. This mechanism effectively avoids problems such as diagnostic interruption, data corruption, or fault diagnosis equipment downtime that may occur if firmware migration is forced during a diagnostic task, thereby ensuring the continuity and stability of the fault diagnosis service. At the same time, dividing the target firmware data into migration units and writing them one by one further improves the reliability and controllability of the migration process. Even if local problems occur during the migration process, recovery or retry is easy, ultimately achieving a smooth and seamless firmware upgrade without affecting the normal diagnostic function of the fault diagnosis equipment.

[0063] After migrating the target firmware data, the fault diagnosis equipment needs to run the target firmware data in the first storage area to determine its validity and integrity. However, if the target firmware data that has not been fully verified is executed directly in the main operating environment, if the data is defective, damaged, or incompatible, it may cause the fault diagnosis equipment to malfunction, the system to crash, or even interrupt the ongoing diagnostic task, thereby affecting the stability of the fault diagnosis equipment and the continuity of service.

[0064] Therefore, referring to Figure 6 Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 1 In the illustrated embodiment, after the migration is completed, the target firmware data in the first storage area is processed to determine the validity and integrity of the target firmware data, including steps S510-S530, wherein: S510. After the migration is completed, extract the diagnostic logic core segment contained in the target firmware data from the first storage area, and load the diagnostic logic core segment into a temporary running sandbox in the processor. S520. In the temporary running sandbox, a set of preset standard diagnostic input signal sequences are invoked to drive the diagnostic logic core segment to process each input signal and capture the output signal sequence generated during the processing. S530. The output signal sequence is compared bit by bit with the standard output signal sequence corresponding to the target firmware data provided in advance by the remote management backend. If all bits match, the target firmware data is determined to be valid and complete. If there are mismatched bits, the target firmware data is determined to be invalid or incomplete, and the migrated target firmware data in the first storage area is erased, restoring the current firmware data before migration.

[0065] After migrating the target firmware data from the second storage area to the first storage area, the fault diagnosis device does not immediately deploy the new firmware to the main operating environment. First, the control unit extracts the core diagnostic logic segment from the target firmware data in the first storage area. This core diagnostic logic segment refers to the key code module in the target firmware data responsible for executing core diagnostic functions, data processing logic, and interacting with the fault diagnosis device under test. Extracting this core diagnostic logic segment aims to isolate the most critical functions for verification, avoiding the complexity and resource consumption of loading the entire firmware. This can be achieved by using firmware structure parsing tools to identify specific code segments, function entry points, or data structures in the firmware image. For example, based on predefined firmware format specifications or metadata information, the diagnostic algorithm module, communication protocol processing module, etc., can be located.

[0066] Subsequently, the extracted diagnostic logic core segment is loaded into a temporary execution sandbox within the processor. The temporary execution sandbox is an isolated, controlled execution environment that simulates the processor's firmware execution environment but is isolated from main system resources (such as main memory and critical peripherals). Its purpose is to allow the safe testing and verification of the diagnostic logic core segment of the target firmware data without affecting the normal operation of the fault diagnosis equipment. This can be achieved through virtualization technology, container technology, or by partitioning the processor into independent memory regions and execution contexts, and restricting the sandbox's access to external resources to ensure that its execution does not cause side effects on the main system.

[0067] In the temporary sandbox environment, the system invokes a set of preset standard diagnostic input signal sequences. These sequences are predefined, representative sets of input data or instructions used to simulate various inputs that the diagnostic equipment might receive in real-world scenarios. These sequences are typically generated by a remote management backend based on the firmware's functional specifications and test case library, aiming to comprehensively cover various working paths and boundary conditions of the core diagnostic logic segment. Through these standard inputs, the diagnostic logic can be systematically triggered, and its behavior observed. The processor executes the core diagnostic logic segment step-by-step according to the preset standard diagnostic input signal sequences. During this process, the sandbox environment monitors and captures in real-time the output data, state changes, or execution results generated by the core diagnostic logic segment after processing each input signal, forming a complete output signal sequence. This process simulates the firmware's response to input data during actual diagnostics.

[0068] Next, the captured output signal sequence is precisely compared bit-by-bit (or byte-by-byte, data unit-by-data) with the standard output signal sequence corresponding to the target firmware data version, which is pre-provided by the remote management backend. The standard output signal sequence is the correct output result obtained by the remote management backend through authoritative testing or simulation verification under a known input sequence. Bit-by-bit comparison ensures that the output of the diagnostic logic core segment is completely consistent with expectations, thereby verifying its functional correctness. If all bits of the captured output signal sequence match the standard output signal sequence, it can be determined that the diagnostic logic core segment in the target firmware data is valid and complete, and can be safely put into use. Conversely, if any mismatched bits exist, it indicates that the target firmware data is defective, damaged, or incompatible, and is judged to be invalid or incomplete. At this time, to avoid potential risks, the fault diagnosis device will immediately erase the invalid target firmware data that has been migrated in the first storage area and restore it to the current firmware data before migration, ensuring that the fault diagnosis device can continue to operate stably.

[0069] One way to achieve data "rollback" is to set up an internal or external backup storage area to save a complete snapshot of the firmware before migration; or to use an atomic write mechanism during the migration process to ensure that firmware update operations are either all successful or completely ineffective, so as to automatically restore to the state before migration when the detection fails; or to use a log recording and timestamp verification mechanism to accurately locate the firmware version before migration and perform a trusted restore when the detection fails.

[0070] Through the above technical solution, this embodiment does not immediately fully enable the target firmware data in the main operating environment after it is migrated to the first storage area. Instead, it first extracts the key diagnostic logic core segments from the target firmware data and loads them into an isolated temporary operating sandbox for pre-verification. This sandbox mechanism effectively decouples the firmware verification process from the main operating environment of the fault diagnosis device, avoiding the risk of system crashes or service interruptions caused by potential defects in the new firmware. By calling a preset standard diagnostic input signal sequence in the sandbox and accurately comparing the generated output signal sequence with the standard output sequence provided by the remote management backend, the validity and integrity of the target firmware data can be quickly and accurately determined. If the verification fails, the fault diagnosis device can promptly erase the invalid firmware and restore the original current firmware data, thereby ensuring that the fault diagnosis device is always in a stable and usable state. This greatly improves the security, reliability, and user experience of the firmware upgrade process, achieving "zero awareness" and "zero risk" in the upgrade process.

[0071] In practice, due to partial damage to the storage medium, momentary interference during transmission, or accidental errors in write operations, some data segments may fail to be verified after being migrated to the first storage area. Simply performing a full retry at this point is not only inefficient but also increases wear and tear on the storage medium. Repeated failures may even prevent the upgrade process from being completed smoothly, affecting the normal operation of the fault diagnosis equipment.

[0072] Therefore, referring to Figure 7 Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 1 In the illustrated embodiment, if the target firmware data fails verification or has an migration anomaly, the target firmware data is retrieved again from the second storage area and migrated to the first storage area until the migration is complete and the verification passes, including steps S610-S650, wherein: S610. When a failed data segment with a verification failure is detected in the target firmware data in the first storage area, the logical address range of the failed data segment in the first storage area is recorded. S620. Determine a target logical address range that maps to the logical address range of the failed data from the second storage area, and relocate the data corresponding to the target logical address range to the corresponding position in the first storage area to replace the failed data segment. S630. After the replacement is completed, perform independent verification on the replaced data segment. If the verification fails, re-execute the second migration and verification loop until the migration is completed and the verification passes. S640. If the number of migration and verification cycles exceeds a preset threshold, restore the firmware in the first storage area to the current firmware data and generate corresponding fault alarm information. S650, Display the fault alarm information.

[0073] After migrating the target firmware data to the first storage area, the fault diagnosis device performs data integrity verification, such as using algorithms like Cyclic Redundancy Check (CRC), MD5 hash, or SHA-256 hash to check the data blocks. If the checksum of a data block does not match the expectation, that data block is determined to be a "failed data segment." At this point, the firmware management module or storage controller inside the fault diagnosis device accurately locates and records the starting address and length of the failed data segment in the first storage area, i.e., its logical address range of failed data. This recording method helps with subsequent accurate repair and avoids unnecessary rewriting of the entire firmware.

[0074] Subsequently, since the second storage area has fully received and stored the firmware data to be upgraded during the download of the target firmware data, it can be used as a data source for partial recovery. When setting up the first and second storage areas, the fault diagnosis device establishes a mapping table to record the address mapping relationship of each storage block in the two storage areas. After obtaining the logical address range of failed data in the first storage area, the system queries this mapping table to determine the corresponding target logical address range in the second storage area. Then, the system initiates a partial data migration task, reading only the data block corresponding to the target logical address range in the second storage area and writing it to the corresponding failed data logical address range in the first storage area, thereby achieving precise replacement of the damaged data segment rather than a complete rewrite.

[0075] After replacing a partial data segment, the control device re-executes a verification algorithm on the replaced data segment just written to the first storage area to confirm whether the replacement operation itself was successful and whether the newly written data is complete and error-free. If the verification passes, the data segment is considered successfully repaired. If the verification still fails, it indicates that there may be a deeper problem. In this case, the control device will not give up but will retrieve the data segment from the second storage area again for re-migration and verification. This "two-stage migration and verification loop" mechanism can effectively deal with occasional errors and improve the success rate of the upgrade.

[0076] To ensure the safety of the upgrade process, the control device sets a counter to record the number of times the migration and verification loop is executed for the same failed data segment. When the counter reaches a preset threshold (e.g., 3 or 5 times), the control device determines that the upgrade cannot be completed through partial repair. At this point, the control device triggers a rollback operation, erasing the firmware data in the first storage area and restoring the current firmware data from the reserved backup area before the upgrade, ensuring that the fault diagnosis device can start and run normally. In addition, the control device generates detailed fault alarm information, including the failed data segment, the cause of failure, and the number of attempts, and reports it to the user or remote management backend via the display screen, indicator lights, or network interface. These fault alarm messages can be displayed in various ways, such as displaying error codes or text prompts on the local display screen of the fault diagnosis device; sending alarm information to the remote management backend via the fault diagnosis device's network interface for remote monitoring and handling by the administrator; or indicating the fault status through the flashing pattern of the fault diagnosis device's indicator lights. The displayed information should be clear enough to help the user understand the problem and guide subsequent operations.

[0077] Through the above technical solution, this embodiment significantly improves the reliability and robustness of firmware upgrades by introducing a refined error handling and recovery mechanism. When the target firmware data fails to verify after being migrated to the first storage area, instead of simply retrying the entire data, it can accurately detect and record the logical address range of the failed data segment. Based on this, the control device can locate and re-migrate the corresponding original data segment from the second storage area, achieving partial replacement, thereby avoiding unnecessary full data rewriting and effectively reducing the number of writes and wear on the storage medium. In addition, independent verification is performed on the replaced data segment, and multiple retry opportunities are provided, enhancing the success rate of partial repair. Even if repair fails after multiple attempts, the control device can intelligently roll back to the current firmware data before the upgrade and generate detailed fault alarm information, ensuring that the fault diagnosis equipment is always available and avoiding the risk of equipment downtime due to upgrade failure. This strategy of segmented verification, partial repair, and intelligent rollback not only improves upgrade efficiency and reduces resource consumption, but more importantly, it greatly ensures the stability and reliability of the fault diagnosis equipment in complex and unstable upgrade environments, providing users with a worry-free upgrade experience.

[0078] When upgrading firmware on fault diagnosis equipment, to ensure the stability of the upgrade process and the continuous operation of the equipment, it is necessary to rationally and clearly divide and manage the internal storage resources of the equipment. Failure to effectively distinguish and configure different storage areas may cause the system to fail to correctly identify the firmware operating environment at startup, or storage area conflicts may occur during the upgrade process, thereby affecting the normal loading and execution of the firmware, or even causing upgrade failure or malfunction of the fault diagnosis equipment.

[0079] Therefore, referring to Figure 8 Another embodiment of the present invention provides an upgrade method for a fault diagnosis device, based on the above. Figure 1 The embodiment shown sets the first storage area as the current firmware storage area and the second storage area as the upgrade firmware storage area, including steps S110-S130, wherein: S110. Obtain the stored configuration information when the fault diagnosis device is started; S120. Based on the storage configuration information, map the starting address of the first storage area to the firmware running entry point, and map the starting address of the second storage area to the firmware upgrade program entry point. S130. Establish a correspondence table between the first storage area and the second storage area. The correspondence table records the mapping relationship between the address of each storage block in the first storage area and the address of the corresponding backup storage block in the second storage area.

[0080] When the fault diagnosis device starts up, the control device first performs an operation to obtain the storage configuration information of the fault diagnosis device at startup. This operation aims to identify the physical layout and preset logical partition information of the internal memory of the fault diagnosis device. Typically, this can be achieved by reading the configuration parameters pre-programmed into the fault diagnosis device's bootloader, accessing specific hardware registers, or parsing a memory mapping table stored in non-volatile memory (such as EEPROM or dedicated configuration flash memory blocks). This configuration information details the total capacity of the memory, the starting address and size of each partition, and its intended use, providing a basis for subsequent firmware mapping and address redirection.

[0081] Based on this, according to the storage configuration information, the starting address of the first storage area is mapped to the firmware execution entry point, and the starting address of the second storage area is mapped to the firmware upgrade program entry point, thus assigning clear logical roles to the two storage areas. Mapping the starting address of the first storage area to the firmware execution entry point means that the processor will load and execute the current firmware data from this address in normal operating mode to start the diagnostic function of the fault diagnosis device. Mapping the starting address of the second storage area to the firmware upgrade program entry point means that when the fault diagnosis device needs to enter firmware upgrade mode, the processor will execute program code specifically for managing the upgrade process, such as a separate upgrade bootloader or recovery firmware, from this address. This mapping is usually achieved by configuring the registers of the Memory Management Unit (MMU), setting the interrupt vector table, or defining jump addresses in the bootloader to ensure that the system can accurately identify and switch to the correct firmware execution environment.

[0082] Furthermore, a mapping table is established between the first and second storage areas. This table records the mapping relationship between the addresses of each storage block in the first storage area and the addresses of the corresponding backup storage blocks in the second storage area. This mapping table is crucial for enabling precise migration and rollback of firmware data between the two storage areas. This mapping table can be stored in a dedicated area of ​​the non-volatile memory of the fault diagnosis device, or dynamically generated according to preset storage partitioning rules during system startup. Each record in the table clearly indicates the starting address of a logical storage block (e.g., a flash page, sector, or custom data block) in the first storage area, and the starting address of its corresponding backup storage block in the second storage area. This fine-grained block-level mapping provides precise address guidance for retrieving target firmware data from the second storage area and migrating it to the first storage area during subsequent fault diagnosis device upgrade operations. It also provides a basis for targeted re-migration of specific data segments in case of verification failure or migration anomalies.

[0083] Through the above technical solution, the logical roles and interrelationships of the first and second storage areas can be clearly and accurately defined and configured at the initial startup of the fault diagnosis equipment. This clear storage area division and entry mapping fundamentally ensures the physical and logical independence of the current firmware data and the upgraded firmware data, effectively avoiding conflicts and confusion between storage areas. Furthermore, the established correspondence table provides a reliable address mapping basis for the accurate migration, verification, and potential rollback operations of subsequent firmware data, greatly improving the stability and reliability of the firmware upgrade process. This enables the fault diagnosis equipment to safely and efficiently complete firmware upgrades without interrupting normal diagnostic tasks, effectively responding to possible anomalies during the upgrade process, and ensuring the continuity of the fault diagnosis equipment's functions and the integrity of its data.

[0084] The present invention also proposes a control device, the control device comprising: a memory, a processor, and an upgrade program for a fault diagnosis device stored in the memory and executable on the processor, the upgrade program for the fault diagnosis device being configured to implement the upgrade method for the fault diagnosis device as described above.

[0085] The core innovation of this embodiment lies in combining the upgrade programs of memory, processor and fault diagnosis equipment in a collaborative architecture, thereby building a reliable firmware upgrade guarantee mechanism in harsh power supply and network environments, avoiding firmware damage caused by abnormal interruptions, and achieving the effect of ensuring the continuity of fault diagnosis equipment diagnostic services and reducing operation and maintenance costs.

[0086] It is worth noting that since the control device of the present invention is based on the above-described upgrade method for fault diagnosis equipment, the embodiments of the control device of the present invention include all the technical solutions of all embodiments of the above-described upgrade method for fault diagnosis equipment, and the technical effects achieved are exactly the same, so they will not be repeated here.

[0087] The present invention also proposes a fault diagnosis device, which includes the control device as described in the above embodiments.

[0088] Fault diagnosis equipment is a specialized hardware system designed to detect, analyze, and identify abnormal operating states, performance bottlenecks, and security vulnerabilities in blockchain servers and their related components. This equipment typically integrates multiple functional components, including a data acquisition module, signal processing unit, diagnostic algorithm executor, communication interface, and user interface, aiming to provide accurate and real-time fault information. Its implementation varies, ranging from a portable handheld terminal to a fixed monitoring unit integrated into an industrial production line, or an embedded diagnostic module within a large fault diagnosis device. As the physical carrier for firmware upgrade functionality, the fault diagnosis equipment provides the necessary hardware environment and operating platform for the control device's operation.

[0089] The control unit is a core component of the fault diagnosis equipment. It integrates a memory, a processor, and an upgrade program for the fault diagnosis equipment stored in the memory and running on the processor. This control unit is responsible for comprehensively managing the firmware upgrade process within the fault diagnosis equipment, including firmware acquisition, downloading, verification, migration, and anomaly handling. It ensures that the upgrade program logic can be executed efficiently and securely within the fault diagnosis equipment, thereby achieving reliable firmware updates.

[0090] By integrating the control device directly into the fault diagnosis equipment using the above technical solution, the fault diagnosis equipment can function as a complete, self-contained system, autonomously performing firmware upgrades. This integrated design ensures that the upgrade method directly affects the fault diagnosis equipment itself, thereby achieving reliable and efficient firmware updates. Specifically, the fault diagnosis equipment can fully utilize the dual-storage upgrade mechanism provided by the control device to complete firmware download, verification, and migration without interrupting core diagnostic tasks. This not only significantly improves the maintenance convenience of the fault diagnosis equipment during field deployment and long-term operation but also effectively guarantees the accuracy of diagnostic results and the overall stability of the fault diagnosis equipment by ensuring that it always runs the latest and verified firmware, while reducing the upgrade risks caused by external intervention or improper operation.

[0091] It is worth noting that since the fault diagnosis device of the present invention is based on the above-mentioned control device, the embodiments of the fault diagnosis device of the present invention include all the technical solutions of all the embodiments of the above-mentioned control device, and the technical effects achieved are exactly the same, which will not be repeated here.

[0092] The overall principle of this application will be explained below in conjunction with all the above embodiments and through an implementable implementation method. However, it should be noted that this implementation method is merely illustrative and not limiting. The implementation method is as follows: At an industrial site (Location A), a fault diagnosis device is deployed to diagnose blockchain server components of various brands and models. The device is currently running firmware version V1.0, but needs to be upgraded to V2.0 to ensure compatibility with a newly released power module (model Z) from a certain brand and to support its new communication protocol. The network environment at Location A is unstable, and the power supply fluctuates occasionally.

[0093] First, upon startup, the fault diagnosis device, based on its internal storage configuration information, designates a specific storage area as the first storage area, serving as the current firmware storage area for running the V1.0 version diagnostic program. The device also designates another independent storage area as the second storage area, specifically for temporarily storing firmware data to be upgraded. Internally, the fault diagnosis device establishes and maintains a mapping table, recording the correspondence between the addresses of each storage block in the first storage area and the addresses of the corresponding backup storage blocks in the second storage area, providing precise address location for subsequent data migration and rollback operations.

[0094] When user A decides to upgrade the fault diagnosis device, the fault diagnosis device first obtains the model information (e.g., "Brand X power module, Model Y") of the connected device under test (e.g., a power module of a server of a certain brand) and the currently running firmware data (version V1.0) in the first storage area. Subsequently, the fault diagnosis device uploads this model information and the current firmware data to the remote management backend. The remote management backend matches the received information and returns a series of metadata for candidate firmware data, such as firmware identifiers and checksums for versions V1.1, V1.2, and V2.0. The fault diagnosis device compares this metadata with the version characteristic fields of the current firmware data in the first storage area, discovers a difference between the V2.0 firmware and the current V1.0 version, and therefore marks the V2.0 firmware as the target firmware data.

[0095] After the target firmware data (V2.0) is determined, the fault diagnosis device sends a firmware retrieval request to the remote management backend based on the user's upgrade instruction request, requesting to download the V2.0 version firmware. Upon receiving the request, the remote management backend returns the target firmware data corresponding to the model information and target firmware version identifier. The fault diagnosis device creates an independent write task instance in the second storage area. This instance allocates a contiguous storage space within the second storage area and divides the received target firmware data into multiple firmware data blocks according to a preset data block size (e.g., 4KB). The fault diagnosis device sequentially writes these firmware data blocks into the contiguous space allocated in the second storage area until all firmware data blocks are written. During this process, even if the first storage area is continuously performing diagnostic tasks on other server components, the write operation in the second storage area will not be affected, ensuring the continuity of the diagnostic service. This design, which pre-downloads the target firmware data to an independent second storage area instead of directly overwriting the currently running firmware, effectively avoids the risk of firmware corruption due to network interruptions or power fluctuations during the download process, significantly improving the robustness of the upgrade process compared to the traditional direct overwrite upgrade method.

[0096] When the fault diagnosis device is ready to perform a firmware migration operation, it first sends a status query command to the first storage area. The fault diagnosis device receives the current execution status parameter returned by the first storage area in response to this command. This parameter indicates whether the first storage area is being read by the processor for diagnostic tasks. If the current execution status parameter indicates that the first storage area is busy (e.g., performing real-time diagnostics on a server component), the fault diagnosis device suspends the migration operation and, after a preset time interval (e.g., 5 seconds), repeatedly sends the status query command to the first storage area until it receives a current execution status parameter indicating that the first storage area is idle. When the first storage area is idle, the fault diagnosis device divides the target firmware data in the second storage area into several sequentially arranged migration units and writes these migration units one by one to the corresponding address in the first storage area, according to the order of the migration units. This mechanism of intelligently detecting the status of the first storage area and waiting for it to become idle before performing the migration achieves seamless switching, ensuring uninterrupted diagnostic services, zero user awareness of the upgrade process, and avoiding the problem of service interruption caused by the forced interruption of diagnostic tasks when the fault diagnosis device is busy, as is common in traditional upgrades.

[0097] After migration, the fault diagnosis device does not immediately switch to the new firmware. It first extracts the diagnostic logic core segment from the target firmware data in the first storage area and loads it into a temporary running sandbox within the processor. In the temporary sandbox, the fault diagnosis device invokes a set of preset standard diagnostic input signal sequences (e.g., simulating various sensor readings, communication protocol frames) to drive the diagnostic logic core segment to process each input signal and capture the output signal sequence generated during processing. The fault diagnosis device then compares the captured output signal sequence bit-by-bit with the standard output signal sequence corresponding to the target firmware data pre-provided by the remote management backend. If all bits match, the target firmware data is determined to be valid and complete. If there are mismatched bits (e.g., a diagnostic result does not match expectations), the target firmware data is determined to be invalid or incomplete. At this point, the fault diagnosis device immediately erases the migrated target firmware data in the first storage area and restores the current firmware data (V1.0) before migration, ensuring the fault diagnosis device can still operate normally. This sandbox pre-verification mechanism verifies the validity of the new firmware without affecting the currently running firmware, greatly reducing the risk of upgrade failure causing the fault diagnosis device to fail to start or malfunction.

[0098] Suppose that during the above verification process, a failed data segment is detected in the target firmware data in the first storage area (e.g., a data block of a diagnostic module is corrupted). The fault diagnosis device records the logical address range of the failed data segment in the first storage area. Then, it determines the target logical address range that maps to the logical address range of the failed data from the second storage area. The fault diagnosis device migrates the data corresponding to the target logical address range in the second storage area back to the corresponding position in the first storage area to replace the failed data segment. After replacement, the fault diagnosis device performs independent verification on the replaced data segment. If verification fails, the fault diagnosis device re-executes the migration and verification loop until migration is complete and verification passes. If the number of migration and verification loops exceeds a preset threshold (e.g., 3 times), the fault diagnosis device restores the firmware in the first storage area to the current firmware data (V1.0) and generates a corresponding fault alarm message (e.g., "Firmware upgrade failed: storage area write error"). The fault diagnosis device displays this fault alarm message to user A, indicating that the upgrade failed and has been restored to a stable state. This partial retry and rollback mechanism can self-repair when some data is corrupted and safely roll back after multiple failed attempts, avoiding the risk of the fault diagnosis equipment becoming "bricked". It improves the success rate and reliability of upgrades in harsh environments, which is in contrast to traditional upgrades that often require manual intervention or even return to the factory for repair once they fail.

[0099] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for upgrading a fault diagnosis device, wherein the fault diagnosis device is provided with a first storage area and a second storage area, characterized in that, The upgrade method for the fault diagnosis equipment includes: Set the first storage area as the current firmware storage area, and set the second storage area as the upgrade firmware storage area; Obtain the current firmware data in the first storage area and the target firmware data in the remote management backend that differs from the current firmware data; If the target firmware data exists, download the target firmware data to the second storage area; In response to performing a device upgrade operation, the target firmware data in the second storage area is retrieved and migrated to the first storage area; After the migration is completed, the target firmware data in the first storage area is run to determine the validity and integrity of the target firmware data; If the target firmware data fails verification or has an abnormal migration, the target firmware data in the second storage area is retrieved again and migrated to the first storage area until the migration is completed and the verification is successful.

2. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, The step of obtaining the current firmware data in the first storage area and the target firmware data in the remote management backend that differs from the current firmware data includes: Obtain the model information and current firmware data of the device under test or component under test connected to the fault diagnosis device; Upload the model information and the current firmware data to the remote management backend; Receive metadata about candidate firmware data returned by the remote management backend based on the model information and the current firmware data; The meta-information is compared with the version feature field of the current firmware data in the first storage area. If the version feature field is inconsistent, the candidate firmware data is marked as the target firmware data.

3. The upgrade method for the fault diagnosis equipment as described in claim 2, characterized in that, If the target firmware data exists, downloading the target firmware data to the second storage area includes: In response to an upgrade instruction request for the fault diagnosis device, a firmware acquisition request is sent to the remote management backend based on the model information and the target firmware version identifier. The remote management backend receives target firmware data corresponding to the model information and target firmware version identifier based on the firmware acquisition request; In the second storage area, an independent write task instance is created. The write task instance allocates a contiguous storage space within the second storage area and divides the received target firmware data into multiple firmware data blocks according to a preset data block size. Each firmware data block is sequentially written into the contiguous space allocated in the second storage area until all firmware data blocks have been written.

4. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, If the target firmware data exists, downloading the target firmware data to the second storage area includes: When the fault diagnosis device is powered on for the first time or the device feature code of the device under test is first identified, the firmware preloading thread is activated. The firmware preloading thread is used to initiate a firmware data synchronization request to the remote management background. Run the firmware preloading thread to send a firmware download request to the remote management backend; Listen for the target firmware data returned by the remote management backend.

5. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, The step of retrieving target firmware data from the second storage area and migrating it to the first storage area in response to performing a device upgrade operation includes: Before performing the migration operation, a status query instruction is sent to the first storage area, and the current execution status parameters returned by the first storage area in response to the status query instruction are received. The current execution status parameters include whether the first storage area is being read by the processor for diagnostic tasks. If the current execution status parameter indicates that the first storage area is busy, the migration operation is suspended, and after a preset time interval, the status query instruction is repeatedly sent to the first storage area until the current execution status parameter indicates that the first storage area is idle. When the first storage area is idle, the target firmware data in the second storage area is divided into several sequentially arranged migration units, and the migration units are written to the corresponding addresses in the first storage area one by one in the order of the migration units.

6. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, After the migration is completed, the target firmware data in the first storage area is processed to determine the validity and integrity of the target firmware data, including: After the migration is completed, the diagnostic logic core segment contained in the target firmware data is extracted from the first storage area, and the diagnostic logic core segment is loaded into a temporary running sandbox in the processor. In the temporary running sandbox, a set of preset standard diagnostic input signal sequences are invoked to drive the diagnostic logic core segment to process each input signal and capture the output signal sequence generated during the processing. The output signal sequence is compared bit by bit with the standard output signal sequence corresponding to the target firmware data provided in advance by the remote management backend. If all bits match, the target firmware data is determined to be valid and complete. If there are mismatched bits, the target firmware data is determined to be invalid or incomplete, and the migrated target firmware data in the first storage area is erased, restoring the current firmware data before migration.

7. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, If the target firmware data fails verification or has an migration anomaly, the target firmware data is retrieved again from the second storage area and migrated to the first storage area until the migration is complete and verification passes, including: When a failed data segment with a verification failure is detected in the target firmware data in the first storage area, the logical address range of the failed data segment in the first storage area is recorded. Determine a target logical address range from the second storage area that maps to the logical address range of the failed data, and migrate the data corresponding to the target logical address range back to the corresponding position in the first storage area to replace the failed data segment; After the replacement is completed, the replaced data segment is independently verified. If the verification fails, the second migration and verification loop is re-executed until the migration is completed and the verification passes. If the number of migration and verification cycles exceeds a preset threshold, the firmware in the first storage area will be restored to the current firmware data, and a corresponding fault alarm message will be generated. Display the fault alarm information.

8. The upgrade method for the fault diagnosis equipment as described in claim 1, characterized in that, Setting the first storage area as the current firmware storage area and the second storage area as the upgrade firmware storage area includes: Obtain the stored configuration information of the fault diagnosis device at startup; Based on the storage configuration information, the starting address of the first storage area is mapped to the firmware running entry point, and the starting address of the second storage area is mapped to the firmware upgrade program entry point; Establish a mapping table between the first storage area and the second storage area. The mapping table records the mapping relationship between the address of each storage block in the first storage area and the address of the corresponding backup storage block in the second storage area.

9. A control device, characterized in that, The control device includes: a memory, a processor, and an upgrade program for a fault diagnosis device stored in the memory and executable on the processor, the upgrade program being configured to implement the upgrade method for the fault diagnosis device as described in any one of claims 1 to 8.

10. A fault diagnosis device, characterized in that, Includes the control device as described in claim 9.

Images