Circuit board firmware management system and circuit board firmware management method

Abstract

This application relates to the field of firmware management technology, and discloses a circuit board firmware management system and a circuit board firmware management method. The circuit board firmware management method is executed by an automated testing system deployed in a test environment. The method includes: initiating a query request to an artifact repository server based on a preset polling strategy to identify whether a new firmware build artifact exists; when a new firmware build artifact is identified, retrieving the new firmware build artifact and its corresponding integrity verification file from the artifact repository server, and verifying the integrity of the new firmware build artifact based on the integrity verification file; after successful verification, deploying the new firmware build artifact to a preset test execution environment to execute a predefined set of test cases corresponding to the new firmware build artifact in the test execution environment, and collecting test process data. Through this method, manual operation can be minimized, ensuring the absolute accuracy of the version of the new firmware build artifact used for flashing.

Description

Technical Field

[0001] This application relates to the field of firmware management technology, and in particular to a circuit board firmware management system and a circuit board firmware management method. Background Technology

[0002] In traditional PCB manufacturing processes, firmware delivery and flashing typically involve multiple independent and fragmented systems, requiring significant manual intervention. After completing code development, the R&D team usually needs to manually compile and generate firmware, then transmit the firmware file to the testing team via informal channels such as email or instant messaging. Upon receiving the firmware, the testing team must manually download and deploy it to the test environment for verification, and manually report the test results back to R&D. Firmware that passes testing must then be approved by production management personnel before being manually copied to the flashing station in the production workshop via USB flash drive or other portable storage devices, where operators select and execute the flashing task. This highly manual, sequential model is not only inefficient and time-consuming but also highly susceptible to human error, such as transmitting the wrong firmware version, flashing unverified firmware, or having cumbersome and time-consuming approval processes. Furthermore, the lack of effective data connectivity between R&D, testing, and production systems (such as MES) makes it difficult to accurately trace the relationship between firmware versions, production orders, and PCB serial numbers. This makes troubleshooting difficult in case of quality issues, posing a significant challenge to product quality management. Summary of the Invention

[0003] The circuit board firmware management system and circuit board firmware management method provided in this application can minimize manual operation steps and ensure the absolute accuracy of the new firmware build product version used for burning.

[0004] Firstly, this application provides a circuit board firmware management method, executed by an automated testing system deployed in a test environment. The method includes: initiating a query request to an artifact repository server based on a preset polling strategy to identify whether a new firmware build artifact exists; when a new firmware build artifact is identified, obtaining the new firmware build artifact and its corresponding integrity verification file from the artifact repository server, and verifying the integrity of the new firmware build artifact based on the integrity verification file; after successful verification, deploying the new firmware build artifact to a preset test execution environment to execute a predefined set of test cases corresponding to the new firmware build artifact in the test execution environment, and collecting test process data.

[0005] The method further includes, after collecting test process data, generating a test report in a preset standard format based on the test process data, uploading the test report to the artifact repository server, and establishing an association storage with the corresponding new firmware build artifact; identifying the test results in the test report, and if the test result is passed, adding a production-ready identifier to the corresponding new firmware build artifact in the artifact repository server, and triggering the sending of metadata of the new firmware build artifact to the manufacturing execution system. The metadata includes at least the version identifier, storage path, and integrity check value of the new firmware build artifact, so that the manufacturing execution system can bind the new firmware build artifact to the production order.

[0006] Specifically, when a new firmware build artifact is identified, the new firmware build artifact and its corresponding integrity verification file are obtained from the artifact repository server. This includes obtaining the new firmware build artifact and its corresponding integrity verification file from the artifact repository server via HTTP authentication when a new firmware build artifact is identified.

[0007] Secondly, this application provides a circuit board firmware management method, executed by a research and development system. The method includes: generating a new firmware build product and its corresponding integrity verification file based on the firmware code; uploading the new firmware build product and its corresponding integrity verification file to a product repository server; receiving a query request from an automated testing system based on a preset polling strategy to the product repository server, and receiving feedback from the automated testing system that a new firmware build product exists in the product repository server, so that the automated testing system obtains the new firmware build product and its corresponding integrity verification file from the product repository server, and verifies the integrity of the new firmware build product based on the integrity verification file; and after successful verification, the automated testing system deploys the new firmware build product to a preset test execution environment to execute a predefined test case set corresponding to the new firmware build product in the test execution environment, and collects test process data.

[0008] The process of generating a new firmware build artifact and its corresponding integrity verification file based on the firmware code includes: responding to a code push or merge request by sending a corresponding POST request to the open-source automation platform via a network hook, so that the open-source automation platform triggers pipeline operations; wherein the open-source automation platform is used to implement continuous integration and continuous delivery processes; the POST request carries the code metadata of the firmware code; wherein the pipeline operations include the following steps: calling the container interface to build a temporary container; compiling the code metadata in the temporary container to obtain the new firmware build artifact and its corresponding integrity verification file.

[0009] The process of compiling code metadata in a temporary container to obtain a new firmware build artifact and its corresponding integrity verification file includes: compiling code metadata in a temporary container to obtain a new firmware build artifact, and then calculating the integrity verification file corresponding to the new firmware build artifact using the md5sum command.

[0010] The method further includes, after generating the new firmware build artifact and its corresponding integrity verification file based on the firmware code, uploading the compilation log to the artifact repository server; wherein the compilation log is generated when compiling the code metadata.

[0011] Thirdly, this application provides a circuit board firmware management method, executed by a production system, the method comprising: receiving metadata of a new firmware build product sent by an automated testing system, the metadata including at least the version identifier, storage path and integrity verification value of the new firmware build product; the new firmware build product being a new firmware build product that has passed testing by the automated testing system using the circuit board firmware management method provided in the first aspect; and binding the new firmware build product to a production order.

[0012] The method, after binding the new firmware build product to the production order, also includes: establishing a secure connection with the burning terminal; calling the firmware distribution interface to send an encrypted address to the burning terminal, so that the burning terminal can download the new firmware build product from the product library server through the encrypted address, and use the new firmware build product to burn firmware onto the circuit board; and receiving the burning result fed back by the burning terminal.

[0013] Fourthly, this application provides a circuit board firmware management system, which includes: an automated testing system deployed in a testing environment for implementing the circuit board firmware management method provided in the first aspect; a research and development system for implementing the circuit board firmware management method provided in the second aspect; and a production system for implementing the circuit board firmware management method provided in the third aspect.

[0014] The beneficial effects of the embodiments of this application are as follows: Unlike the prior art, the circuit board firmware management system and circuit board firmware management method provided in this application involve an automated testing system initiating a query request to the artifact library server based on a preset polling strategy to identify whether a new firmware build product exists; when a new firmware build product is identified, the system obtains the new firmware build product and its corresponding integrity verification file from the artifact library server, and verifies the integrity of the new firmware build product based on the integrity verification file; after successful verification, the new firmware build product is deployed to a preset test execution environment to execute a predefined test case set corresponding to the new firmware build product in the test execution environment, and collects test process data, thereby constructing a complete automated pipeline from the generation of the new firmware build product to automated testing, minimizing manual operation steps, and ensuring the absolute accuracy of the version of the new firmware build product used for burning. In other words, the circuit board firmware management system and circuit board firmware management method provided in this application construct a complete end-to-end automated pipeline, seamlessly integrating code compilation, version management, unattended automatic burning, system testing and result feedback, etc., realizing efficient, reliable and repeatable verification of embedded software (firmware) quality. Through software-defined operation and remote control, the traditional hardware operation that relies on manual execution is transformed into an automated process, which significantly improves the overall automation level and manageability of the system. Attached Figure Description

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

[0016] Figure 1 This is a flowchart illustrating an embodiment of the circuit board firmware management method provided in this application;

[0017] Figure 2 This is a flowchart illustrating another embodiment of the circuit board firmware management method provided in this application;

[0018] Figure 3 This is a flowchart illustrating another embodiment of the circuit board firmware management method provided in this application;

[0019] Figure 4 This is a flowchart illustrating another embodiment of the circuit board firmware management method provided in this application;

[0020] Figure 5 This is a flowchart illustrating another embodiment of the circuit board firmware management method provided in this application;

[0021] Figure 6This is a schematic diagram of an embodiment of the circuit board firmware management system provided in this application. Detailed Implementation

[0022] The technical solutions of the embodiments of this application will be clearly and completely described below with reference to the accompanying drawings. It is understood that the specific embodiments described herein are only for explaining this application and not for limiting it. Furthermore, it should be noted that, for ease of description, only the parts related to this application are shown in the accompanying drawings, not all structures. All other embodiments obtained by those skilled in the art based on the embodiments of this application without creative effort are within the scope of protection of this application.

[0023] In this document, the term "embodiment" means that a particular feature, structure, or characteristic described in connection with an embodiment may be included in at least one embodiment of this application. The appearance of this phrase in various places throughout the specification does not necessarily refer to the same embodiment, nor is it a separate or alternative embodiment mutually exclusive with other embodiments. It will be explicitly and implicitly understood by those skilled in the art that the embodiments described herein can be combined with other embodiments.

[0024] In traditional PCB manufacturing processes, firmware delivery and flashing typically involve multiple independent and fragmented systems, requiring significant manual intervention. After completing code development, the R&D team usually needs to manually compile and generate firmware, then transmit the firmware file to the testing team via informal channels such as email or instant messaging. Upon receiving the firmware, the testing team must manually download and deploy it to the test environment for verification, and manually report the test results back to R&D. Firmware that passes testing must then be approved by production management personnel before being manually copied to the flashing station in the production workshop via USB flash drive or other portable storage devices, where operators select and execute the flashing task. This highly manual, sequential model is not only inefficient and time-consuming but also highly susceptible to human error, such as transmitting the wrong firmware version, flashing unverified firmware, or having cumbersome and time-consuming approval processes. Furthermore, the lack of effective data connectivity between R&D, testing, and production systems (such as MES) makes it difficult to accurately trace the relationship between firmware versions, production orders, and PCB serial numbers. This makes troubleshooting difficult in case of quality issues, posing a significant challenge to product quality management.

[0025] For example, in the entire process from firmware compilation, delivery, testing to production flashing, many steps rely on manual operation, which can easily lead to problems such as incorrect version selection, file corruption, and incorrect flashing targets, directly resulting in batch quality defects in the product. The reliance on manual delivery and approval during firmware transfer across systems creates process bottlenecks, prolonging iteration cycles and hindering efficient continuous integration and delivery, thus impacting the overall efficiency of product production.

[0026] Based on this, the circuit board firmware management system and circuit board firmware management method provided in this application include an automated testing system that initiates a query request to the artifact library server based on a preset polling strategy to identify whether a new firmware build artifact exists. When a new firmware build artifact is identified, the system obtains the new firmware build artifact and its corresponding integrity verification file from the artifact library server and verifies the integrity of the new firmware build artifact based on the integrity verification file. After successful verification, the new firmware build artifact is deployed to a preset test execution environment to execute a predefined set of test cases corresponding to the new firmware build artifact and collect test process data. This constructs a complete automated pipeline from the generation of the new firmware build artifact to automated testing, minimizing manual operation steps and ensuring the absolute accuracy of the version of the new firmware build artifact used for burning. In other words, the circuit board firmware management system and method provided in this application construct a complete end-to-end automated pipeline, seamlessly integrating code compilation, version management, unattended automatic flashing, system testing, and result feedback. This achieves efficient, reliable, and repeatable verification of embedded software (firmware) quality. Through software-defined operation and remote control, it transforms traditionally manual hardware operations into automated processes, significantly improving the overall automation level and manageability of the system. See the technical solutions of any of the following embodiments for details.

[0027] See Figure 1 , Figure 1 This is a flowchart illustrating an embodiment of the circuit board firmware management method provided in this application. Executed by an automated testing system deployed in a test environment, the method includes:

[0028] Step 11: Initiate a query request to the artifact repository server based on a preset polling strategy to identify whether there are new firmware build artifacts.

[0029] In some embodiments, the artifact repository server is used to store new firmware build artifacts. New firmware build artifacts can be compiled from firmware code. New firmware build artifacts can be defined as circuit board firmware files.

[0030] In some embodiments, the automated testing system may employ a preset polling strategy to initiate query requests to the artifact repository server to identify whether a new firmware build artifact exists. If a new firmware build artifact is identified, step 12 is executed. If no new firmware build artifact is identified, the system waits for the next polling strategy and initiates another query request to the artifact repository server to identify whether a new firmware build artifact exists.

[0031] The preset polling strategy allows you to set the corresponding polling period, such as 1 hour, 1.5 hours, 3 hours, 5 hours, 10 hours, 15 hours, 24 hours, 48 ​​hours, etc.

[0032] Step 12: When a new firmware build artifact is identified, obtain the new firmware build artifact and its corresponding integrity verification file from the artifact repository server, and verify the integrity of the new firmware build artifact based on the integrity verification file.

[0033] In some embodiments, when a new firmware build artifact is identified, the new firmware build artifact and its corresponding integrity verification file are obtained from the artifact repository server via HTTP authentication.

[0034] In some embodiments, the integrity verification file can be an MD5 (Message Digest Algorithm 5) verification file. MD5 is an encryption algorithm that generates a 128-bit fixed-length hash value, which can convert data of arbitrary length into a 32-bit hexadecimal string output.

[0035] In some embodiments, the artifact repository server can be built upon the Nexus artifact repository. Nexus is a repository manager that stores and retrieves artifacts. It enables the hosting of built artifacts in a private and secure repository.

[0036] After obtaining the new firmware build artifact from the artifact repository server, its current integrity verification file can be recalculated based on the new firmware build artifact. The current integrity verification file is compared with the integrity verification file obtained from the artifact repository server. If the two integrity verification files match, the new firmware build artifact is determined to be complete, and the verification passes. If the two integrity verification files do not match, the new firmware build artifact is determined to be incomplete, and the verification fails.

[0037] If the integrity check fails, a message indicating that the integrity check failed can be sent to the artifact repository server so that the personnel in the corresponding R&D system can check and verify the new firmware build artifacts in the artifact repository server.

[0038] Step 13: After successful verification, deploy the new firmware build artifact to the preset test execution environment to execute the predefined test case set corresponding to the new firmware build artifact in the test execution environment and collect test process data.

[0039] In some embodiments, the preset test execution environment can be a physical test environment. The physical test environment can be constructed from several physical test devices. The test case set can be predefined according to the function of the circuit board. Based on this, a test case set can be constructed for each function of the circuit board according to its different functions.

[0040] The predefined test case set includes hardware interface testing, protocol stack compatibility testing, etc.

[0041] In some embodiments, test case sets can be constructed in the following ways:

[0042] Configure general test cases and specific test cases. General test cases can be applied to all circuit boards, while specific test cases can be configured for the specific functions of the circuit board.

[0043] After setting up general and specific test cases, a test case set can be constructed based on the circuit board's functionality. This test case set can include general test cases and specific test cases corresponding to the circuit board. For example, when building a test case set for firmware A, general test cases and specific test cases corresponding to firmware A are obtained. Similarly, when building a test case set for firmware B, general test cases and specific test cases corresponding to firmware B are obtained. It can be understood that the test case sets are all temporarily constructed; there is no need to set up a test case set for every type of firmware. Thus, the automated testing system 20 can store fewer test cases to support testing circuit boards with different functions, meaning that test cases can occupy less storage space.

[0044] In this embodiment, the automated testing system initiates a query request to the artifact repository server based on a preset polling strategy to identify whether a new firmware build artifact exists. When a new firmware build artifact is identified, it retrieves the new firmware build artifact and its corresponding integrity verification file from the artifact repository server, and verifies the integrity of the new firmware build artifact based on the integrity verification file. After successful verification, the new firmware build artifact is deployed to a preset test execution environment to execute a predefined set of test cases corresponding to the new firmware build artifact and collect test process data. This constructs a complete automated pipeline from the generation of the new firmware build artifact to automated testing, minimizing manual operation steps and ensuring the absolute accuracy of the version of the new firmware build artifact used for flashing. In other words, the circuit board firmware management system and circuit board firmware management method provided in this application construct a complete end-to-end automated pipeline, seamlessly integrating code compilation, version management, unattended automatic flashing, system testing, and result feedback. This achieves efficient, reliable, and repeatable verification of embedded software (firmware) quality. Through software-defined operation and remote control, traditional hardware operations that rely on manual execution are transformed into automated processes, significantly improving the overall automation level and manageability of the system.

[0045] See Figure 2 , Figure 2 This is a flowchart illustrating another embodiment of the circuit board firmware management method provided in this application. After being executed by an automated testing system deployed in a test environment and collecting test process data, the method further includes:

[0046] Step 21: Based on the test process data, generate a test report in a preset standard format, and upload the test report to the artifact repository server to establish an association storage with the corresponding new firmware build artifact.

[0047] In some embodiments, the preset standard format can be set by the user in advance. For example, the JUnit format. The JUnit format is a format used for converting code style check results. It can convert the check results into a JUnit-compatible XML format, which is convenient for integration into the CI / CD process and analysis using various test reporting tools.

[0048] In some embodiments, serial port logs and signal data are collected in real time during the test; after the test is completed, a JUnit format test report is generated, the report is uploaded via the Nexus API and associated with the new firmware build artifact for storage; if the test fails, an unqualified test report is output, the report content includes the firmware version number, test failure details and log links.

[0049] The test report is generated in a preset standard format and uploaded to the artifact repository server. It is then associated with the corresponding new firmware build artifact for storage, so as to facilitate the subsequent tracking of relevant test data of the new firmware build artifact.

[0050] Step 22: Identify the test results in the test report. If the test results are passed, add a production-ready flag to the corresponding new firmware build artifact in the artifact library server and trigger the sending of metadata of the new firmware build artifact to the manufacturing execution system. The metadata includes at least the version identifier, storage path and integrity check value of the new firmware build artifact, so that the manufacturing execution system can bind the new firmware build artifact to the production order.

[0051] In some embodiments, when the test passes, a production-ready flag is added to the corresponding new firmware build artifact in the artifact repository server via the Nexus API. This flag can be a "PROD_READY" label. The manufacturing execution system's (MES) production interface is then invoked to send metadata of the new firmware build artifact to the MES. The metadata includes at least the version identifier, storage path, and integrity checksum of the new firmware build artifact. The version identifier can be a version number, and the integrity checksum can be a SHA256 checksum.

[0052] The Manufacturing Execution System (MES) binds the new firmware build product to the production order and the new firmware build product to the PCB board serial number, and updates the Bill of Materials (BOM) status to "Firmware Ready", completing the digital preparation before production.

[0053] In this embodiment, after collecting test process data, the automated testing system generates a test report in a preset standard format based on the test process data and uploads the test report to the artifact repository server, establishing an association storage with the corresponding new firmware build artifact. The system identifies the test results in the test report; if the test result is pass, a production-ready identifier is added to the corresponding new firmware build artifact in the artifact repository server, triggering the sending of metadata of the new firmware build artifact to the manufacturing execution system. The metadata includes at least the version identifier, storage path, and integrity check value of the new firmware build artifact, enabling the manufacturing execution system to bind the new firmware build artifact to the production order. Then, according to the production order, the new firmware build artifact is burned into the corresponding circuit board, thus constructing a complete automated pipeline from code submission to production burning. This seamlessly connects the R&D system, automated testing system, and production system through a CI / CD pipeline, and utilizes the manufacturing execution system of the production system to automatically associate qualified firmware with the production plan, minimizing manual operation and ensuring the absolute accuracy of the version of the new firmware build artifact used for burning. In other words, the circuit board firmware management system and circuit board firmware management method provided in this application construct a complete end-to-end automated pipeline, seamlessly integrating code compilation, version management, unattended automatic burning, system testing and result feedback, etc., realizing efficient, reliable and repeatable verification of embedded software (firmware) quality. Through software-defined operation and remote control, the traditional hardware operation that relies on manual execution is transformed into an automated process, which significantly improves the overall automation level and manageability of the system.

[0054] See Figure 3 , Figure 3 This is a flowchart illustrating another embodiment of the circuit board firmware management method provided in this application. Executed by the R&D system, the method includes:

[0055] Step 31: Generate the new firmware build artifact and its corresponding integrity verification file based on the firmware code.

[0056] In some embodiments, the R&D system can be deployed on a server that can receive firmware code submitted by several code generation terminals, and then compile these firmware codes to obtain a new firmware build product and its corresponding integrity verification file.

[0057] In some embodiments, step 31 may be the following process: in response to a code push or merge request, a corresponding POST request is sent to the open-source automation platform via a network hook to trigger pipeline operations on the open-source automation platform; wherein, the open-source automation platform is used to implement continuous integration and continuous delivery processes; the POST request carries the code metadata of the firmware code; wherein, the pipeline operations include the following process: calling the container interface to build a temporary container; compiling the code metadata in the temporary container to obtain the new firmware build artifact and its corresponding integrity verification file.

[0058] A webhook is a method that allows an application to provide real-time information to other applications. It's a "reverse API," meaning instead of the client actively requesting data from the server, the server proactively sends an HTTP request (usually a POST request) to a specified URL to notify the client when a specific event is detected. Webhooks are used for integration between various online services and applications to automate notifications and data synchronization. For example, when code is pushed to GitHub, GitHub can configure a webhook to automatically notify continuous integration services (such as Jenkins or Travis CI), triggering automated build and testing processes.

[0059] In some embodiments, the code metadata is compiled in a temporary container to obtain a new firmware build artifact, and then the integrity verification file corresponding to the new firmware build artifact is calculated using the md5sum command.

[0060] Step 32: Upload the new firmware build artifact and its corresponding integrity verification file to the artifact repository server.

[0061] In some embodiments, after a new firmware build artifact and its corresponding integrity verification file are generated based on the firmware code, the compilation log is uploaded to the artifact repository server; the compilation log is generated during the compilation of code metadata. The compilation log can record relevant information of the firmware code during the compilation process in real time, such as exception information and normal information, which facilitates subsequent firmware information traceability.

[0062] Step 33: The automated testing system sends a query request to the artifact repository server based on a preset polling strategy, and reports to the automated testing system that a new firmware build artifact exists in the artifact repository server. This allows the automated testing system to obtain the new firmware build artifact and its corresponding integrity verification file from the artifact repository server, and verify the integrity of the new firmware build artifact based on the integrity verification file. After successful verification, the automated testing system deploys the new firmware build artifact to a preset test execution environment to execute a predefined set of test cases corresponding to the new firmware build artifact in the test execution environment, and collects test process data.

[0063] See Figure 4 , Figure 4 This is a flowchart illustrating another embodiment of the circuit board firmware management method provided in this application. Executed by a production system, the method includes:

[0064] Step 41: Receive the metadata of the new firmware build artifact sent by the automated testing system. The metadata includes at least the version identifier, storage path and integrity check value of the new firmware build artifact.

[0065] In some embodiments, the new firmware build product is the new firmware build product that has passed the test by the automated test system using the circuit board firmware management method of any of the above embodiments.

[0066] The production system can retrieve the corresponding new firmware build artifact from the artifact repository server based on the storage path in the metadata. It then verifies the retrieved new firmware build artifact using the version identifier and integrity check value. After successful verification, step 42 is executed.

[0067] In some embodiments, the production system includes a manufacturing execution system and a programming terminal.

[0068] Manufacturing Execution System (MES) is production management software that bridges the Enterprise Resource Planning (ERP) and Industrial Automation (IMA) layers, adhering to the ANSI / ISA-S95 international standard and the SJZ 11362-2006 national standard. This system integrates core functions such as production process modeling, production planning and scheduling, material tracking, and quality process control through factory modeling, real-time data acquisition and monitoring. Based on an SOA architecture, it supports modular expansion and encompasses 15 business modules, including production performance feedback, dynamic inventory management, and a cross-departmental cost control network. It employs RAID 5 storage and off-site disaster recovery mechanisms to ensure data security and collaborates with ERP, warehouse management, and other systems to form a comprehensive information management platform.

[0069] Step 42: Bind the new firmware build artifact to the production order.

[0070] After binding the new firmware build artifact to the production order, when executing the production order, the new firmware build artifact can be obtained from the artifact library server and burned into the corresponding circuit board.

[0071] See Figure 5 , Figure 5 This is a flowchart illustrating another embodiment of the circuit board firmware management method provided in this application. After the production system binds the new firmware build artifact to the production order, the method further includes:

[0072] Step 51: Establish a secure connection with the programming terminal.

[0073] Step 52: Call the firmware distribution interface to send an encrypted address to the burning terminal, so that the burning terminal can download the new firmware build product from the product library server through the encrypted address, and use the new firmware build product to burn firmware onto the circuit board.

[0074] Step 53: Receive the burning result from the burning terminal.

[0075] In some embodiments, the programming terminal invokes programming tools to program and verify the firmware on the circuit board using the new firmware build product.

[0076] In some embodiments, after the programming terminal completes the programming, it compares the chip signature with the expected verification value and performs a full-chip verification to obtain the programming result. The programming result includes at least one of the following: success status, PCB serial number, firmware version, verification value, timestamp, and operator ID. The programming result is pushed to the message queue of the manufacturing execution system in real time, and the production database is updated after being parsed by the data consumption service.

[0077] See Figure 6 , Figure 6 This is a schematic diagram of an embodiment of the circuit board firmware management system provided in this application. The circuit board firmware management system 100 includes: an automated testing system 20, a research and development system 10, and a production system 30 deployed in a testing environment.

[0078] An automated testing system 20 deployed in a test environment is used to implement the circuit board firmware management method of any of the above embodiments.

[0079] The R&D system 10 is used to implement the circuit board firmware management method of any of the above embodiments.

[0080] The production system 30 is used to implement the circuit board firmware management method of any of the above embodiments.

[0081] In some embodiments, the R&D system 10 is used to generate new firmware build products and corresponding verification files for the circuit board, and upload the new firmware build products and corresponding integrity verification files to the artifact library server.

[0082] In some embodiments, the R&D system 10 may consist of a server that receives firmware code submitted by several code-generating terminals, compiles this firmware code, and obtains a new firmware build artifact and a corresponding integrity verification file. For example, the integrity verification file may be an MD5 (Message Digest Algorithm 5) verification file. MD5 is an encryption algorithm that generates a 128-bit fixed-length hash value, which can convert data of arbitrary length into a 32-bit hexadecimal string output.

[0083] In some embodiments, the artifact repository server can be a Nexus artifact repository. Nexus is a repository manager that stores and retrieves artifacts. It can host built artifacts in a private and secure repository.

[0084] In some embodiments, the R&D system 10 is further configured to: in response to a code push or merge request, send a corresponding POST request to the open-source automation platform via a webhook, so that the open-source automation platform triggers pipeline operations. A webhook is a method that allows an application to provide real-time information to other applications. It is a "reverse API," meaning that instead of the client actively requesting data from the server, the server proactively sends an HTTP request (usually a POST request) to a specified URL to notify the client when it detects a specific event. Webhooks are used for integration between various online services and applications to achieve automated notifications and data synchronization. For example, when code is pushed to GitHub, GitHub can configure a webhook to automatically notify continuous integration services (such as Jenkins or Travis CI), triggering automated build and testing processes.

[0085] Among them, open-source automation platforms are used to implement continuous integration and continuous delivery processes.

[0086] POST requests carry code metadata.

[0087] The assembly line operation includes the following processes:

[0088] A temporary container is constructed by calling the container interface; within the temporary container, the code metadata is compiled to obtain the new firmware build artifacts and the corresponding integrity verification file. For example, a standardized compilation script is executed within the temporary container to compile the code metadata.

[0089] In some embodiments, the pipeline operation further includes the following process: compiling the code metadata in a temporary container to obtain the circuit board firmware file, and then calculating the integrity verification file of the new firmware build artifact using the md5sum command.

[0090] In some embodiments, the R&D system 10 is further configured to: upload compilation logs to the artifact repository server 40; wherein the compilation logs are generated during the compilation of code metadata. The compilation logs can record relevant information of the firmware code during the compilation process in real time, such as exception information and normal information, which facilitates subsequent firmware information traceability.

[0091] In some embodiments, the automated testing system 20 is communicatively connected to the artifact library server 40. When an unprocessed new firmware build artifact is detected in the artifact library server 40, the system retrieves the new firmware build artifact and its corresponding integrity verification file from the artifact library server 40, performs integrity verification on the new firmware build artifact using the integrity verification file, and tests the new firmware build artifact after successful verification. Upon successful testing, a target tag is set for the new firmware build artifact and added to the artifact library server 40; the target tag indicates that the new firmware build artifact is ready. That is, the new firmware build artifact with the target tag added to the artifact library server 40 can be used for subsequent firmware burning to the corresponding circuit board. If the integrity verification fails, a message indicating failure can be sent to the R&D system 10 so that personnel in the R&D system 10 can check and verify the new firmware build artifact in the artifact library server. Similarly, if the test fails, a message indicating failure can be sent to the R&D system 10 so that personnel in the R&D system 10 can modify and check the code corresponding to the new firmware build artifact in the artifact library server to improve the code and facilitate passing the next test.

[0092] In some embodiments, the automated testing system 20 is further configured to: periodically monitor whether there are any unprocessed new firmware build artifacts in the artifact repository server through an automated scheduling service; if so, obtain the new firmware build artifact and the corresponding integrity verification file from the artifact repository server, perform integrity verification on the new firmware build artifact using the integrity verification file, test the new firmware build artifact after the verification passes, and set a target tag for the new firmware build artifact and add it to the artifact repository server after the test passes.

[0093] In some embodiments, the automated testing system 20 is further configured to: deploy the new firmware build artifact to a physical testing environment and invoke a test management framework to execute a predefined set of test cases to test the new firmware build artifact. The physical testing environment can be constructed from several physical testing devices. The test case set can be predefined according to the function of the circuit board. Based on this, a test case set can be constructed for each functional circuit board according to its different functions.

[0094] In some embodiments, test case sets can be constructed in the following ways:

[0095] Configure general test cases and specific test cases. General test cases can be applied to all circuit boards, while specific test cases can be configured for the specific functions of the circuit board.

[0096] After setting up general and specific test cases, a test case set can be constructed based on the circuit board's functionality. This test case set can include general test cases and specific test cases corresponding to the circuit board. For example, when building a test case set for firmware A, general test cases and specific test cases corresponding to firmware A are obtained. Similarly, when building a test case set for firmware B, general test cases and specific test cases corresponding to firmware B are obtained. It can be understood that the test case sets are all temporarily constructed; there is no need to set up a test case set for every type of firmware. Thus, the automated testing system 20 can store fewer test cases to support testing circuit boards with different functions, meaning that test cases can occupy less storage space.

[0097] In some embodiments, the automated testing system 20 is further configured to: after setting a target tag for the new firmware build product, call the production interface of the manufacturing execution system to synchronize the metadata of the new firmware build product, so that the manufacturing execution system binds the new firmware build product with the production work order number and the circuit board serial number, and updates the status of the bill of materials to the first status; the metadata includes the version number, check value, and file storage path of the new firmware build product; the first status is used to indicate that the firmware is ready.

[0098] In some embodiments, the production system 30 includes a manufacturing execution system and a programming terminal. The manufacturing execution system is communicatively connected to the automated testing system 20 and the programming terminal. The manufacturing execution system is used to send an encrypted address to the programming terminal so that the programming terminal can download the circuit board firmware file corresponding to the target tag from the product library server through the encrypted address, and use the new firmware to build the product to program the firmware on the circuit board.

[0099] Manufacturing Execution System (MES) is production management software that bridges the Enterprise Resource Planning (ERP) and Industrial Automation (IMA) layers, adhering to the ANSI / ISA-S95 international standard and the SJZ 11362-2006 national standard. This system integrates core functions such as production process modeling, production planning and scheduling, material tracking, and quality process control through factory modeling, real-time data acquisition and monitoring. Based on an SOA architecture, it supports modular expansion and encompasses 15 business modules, including production performance feedback, dynamic inventory management, and a cross-departmental cost control network. It employs RAID 5 storage and off-site disaster recovery mechanisms to ensure data security and collaborates with ERP, warehouse management, and other systems to form a comprehensive information management platform.

[0100] In some embodiments, the manufacturing execution system is further configured to: establish a secure connection with the burning terminal; and call the firmware distribution interface to send an encrypted address to the burning terminal.

[0101] In some embodiments, the programming terminal is also used to: invoke programming tools to program and verify the firmware on the circuit board using the new firmware build product.

[0102] The programming terminal is also used for: after programming is completed, comparing the chip signature with the expected verification value and performing full-chip verification to obtain the programming result; the programming result includes at least one of the following: success status, PCB serial number, firmware version, verification value, timestamp and operator ID; and pushing the programming result to the message queue of the manufacturing execution system in real time, which is then parsed by the data consumption service and updated in the production database.

[0103] In one application scenario, for R&D system 10, a webhook listening mechanism linked to the Git repository is configured on the Jenkins server. Specifically, this is achieved by installing the GitLab Plugin or GitHub Integration Plugin in Jenkins, generating a unique webhook URL in the Jenkins task, and configuring it in the version control platform's webhook settings. The trigger events are set to Push and Merge Request events. When a developer pushes code to a specific branch or makes a merge request, the Git server sends a POST request carrying metadata such as commit hash and branch information to this URL (Webhook URL) to trigger the pipeline operation. Jenkins starts the build according to the predefined Jenkinsfile process: the first step of the pipeline operation is to call the Docker Engine API to create a temporary container based on a pre-built embedded toolchain image. The Jenkins workspace directory is mounted to the / app / src path (specified path) inside the container using the -v parameter. Standardized compilation scripts are executed inside the container. The toolchain image pre-installs ARM GCC 10.3, IAR C / C++ Compiler for ARM8.50.6, CMake 3.20, and project-specific dependencies to ensure environment consistency. After compilation, the `md5sum` command is used within the container to generate a checksum for the firmware binary file. Then, the firmware file, compilation logs, and MD5 checksum file are synchronously uploaded to the `embedded-firmware` repository in the Nexus artifact repository via the Jenkins Nexus Plugin. The storage path strictly follows the versioned naming convention "${PROJECT_NAME} / ${BRANCH_NAME} / ${GIT_COMMIT_ID} / ", thus ensuring full version traceability.

[0104] For the automated testing system 20, an automated scheduling service deployed in a Kubernetes cluster periodically calls the Nexus REST API to poll for new firmware (new firmware build artifacts), using a timestamp filter to retrieve the latest build artifacts. When unprocessed firmware is detected, the system automatically downloads the firmware binary file and corresponding MD5 checksum file via HTTP authentication. After verifying its integrity, it deploys it to a physical test bench (physical test environment) via SSH protocol. Subsequently, it calls the test management framework to execute predefined test case sets (including hardware interface testing, protocol stack compatibility testing, etc.). During the test, serial port logs and signal data are collected in real time. After the test is completed, a JUnit format test report is generated, uploaded via the Nexus API, and stored in association with the firmware version. If the test fails, a failure test report is output, containing the firmware version number, test failure details, and log links. When the test passes, the Nexus API is used to retrieve the firmware binary file and corresponding MD5 checksum. The API adds a "PROD_READY" tag (target tag) to the firmware and simultaneously calls the production interface of the MES system (Manufacturing Execution System) to synchronize firmware metadata (including version number, SHA256 checksum, and file storage path). The MES system automatically binds the firmware to the production work order number and PCB board serial number and updates the bill of materials (BOM) status to "Firmware Ready", completing the digital preparation before production.

[0105] For production system 30, the MES system automatically generates a daily programming task queue through the scheduling engine and issues instructions to the programming workstations of designated production lines according to the work order priority. Specifically, a secure connection is first established with the programming terminal through the HTTPS two-way authentication protocol (using mTLS certificate authentication), and the firmware distribution interface is called to encrypt and transmit the firmware metadata and download address with the "PROD_READY" tag in the Nexus artifact library to the programming terminal; the programming terminal pulls the firmware binary file (circuit board firmware file) from the Nexus artifact library through SFTP over SSH (specified port 22), and stores it in the local secure storage area after decryption using a preset AES-256 key. The programming terminal's programming fixture connects to a programmer (such as J-LinkPro or ST-LINK / V3) via USB-HID protocol, automatically calling the OpenOCD command-line tool (openocd -f / cfg / stm32h7.cfg -c "program firmware.bin verify reset exit") or ST-LINK CLI (ST-LINK_CLI -c SWD -Pfirmware.hex -V -HardRst) to perform programming, monitoring voltage stability and signal timing in real time during the process. After programming, the chip's Flash signature (STM32's UID verification or ESP32's eFuse digest) is read and compared with the expected verification value, while simultaneously performing a full-chip CRC32 check. Finally, the programming result (including success status, PCB serial number, firmware version, verification value, timestamp, and operator ID) is pushed in real time to the MES system's Kafka message queue via the MQTT protocol. The data consumption service parses the message, updates the production database, and synchronizes it to the Quality Management System (QMS) to generate digital batch files, completing closed-loop traceability.

[0106] SFTP over SSH is a file transfer method implemented through the SSH protocol. Its core is that the SFTP protocol runs as a subsystem of SSH2, which is significantly different from the traditional FTP over SSH.

[0107] The working principle of SFTP over SSH is as follows:

[0108] SFTP (SSH File Transfer Protocol) is directly integrated into the SSH2 protocol, and all data transfers (including control and data channels) are completed through an encrypted SSH connection. After the client establishes an SSH connection with the server, file operations are performed through the SFTP subsystem, without the need for additional FTP protocol support.

[0109] It is understandable that the programming terminal can be set up with several programming stations, and each programming station can program firmware for a circuit board.

[0110] In summary, the circuit board firmware management system 100 provided in this application generates new firmware build products and corresponding verification files in the R&D system 10, and uploads the new firmware build products and corresponding verification files to the product library server. It communicates with the product library server through an automated testing system 20. When an unprocessed new firmware build product is detected in the product library server, the system retrieves the new firmware build product and corresponding verification file from the product library server, performs integrity verification on the new firmware build product using the verification file, and tests the new firmware build product after successful verification. After successful testing, a target tag is set for the new firmware build product and added to the product library server; the target tag is used to indicate that the circuit board firmware file is ready. The process involves using the Manufacturing Execution System (MES) of Production System 30 to send an encrypted address to the burning terminal. This allows the burning terminal to download the new firmware build product corresponding to the target tag from the product library server via the encrypted address. The new firmware build product is then used to burn the firmware onto the circuit board. This creates a complete automated pipeline from code submission to production burning. The CI / CD pipeline drives the seamless integration of R&D System 10, Automated Testing System 20, and Production System 30. The MES of Production System 30 is used to automatically associate qualified firmware with the production plan. Finally, the firmware file of the tested circuit board is accurately delivered to the burning terminal of Production System 30 via an encrypted address, minimizing manual operations and ensuring the absolute accuracy and efficient delivery of firmware versions in Production System 30. In other words, the circuit board firmware management system 100 provided in this application constructs a complete end-to-end automated pipeline, seamlessly integrating code compilation, version management, unattended automatic burning, system testing and result feedback, etc., realizing efficient, reliable and repeatable verification of embedded software (firmware) quality. Through software-defined operation and remote control, it transforms the traditional hardware operation that relies on manual execution into an automated process, significantly improving the overall automation level and manageability of the system.

[0111] Furthermore, both the automated testing system 20 and the production system 30 obtain new firmware build products from the artifact repository server for testing and flashing, ensuring the uniqueness of new firmware build products and eliminating human error and operational inconsistencies caused by manual flashing and testing in traditional development. By automating the entire process and seamlessly integrating it, a closed loop from code submission to test feedback is achieved, accelerating the development iteration cycle. The system provides complete and traceable test data and version records, providing solid data support for quality analysis and continuous optimization.

[0112] In the several embodiments provided in this application, it should be understood that the disclosed methods and devices can be implemented in other ways. For example, the device embodiments described above are merely illustrative. For instance, the division of modules or units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed.

[0113] If the integrated units in the other embodiments described above are implemented as software functional units and sold or used as independent products, they can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) or processing circuit component (processor) to execute all or part of the steps of the methods described in the various embodiments of this application. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0114] The above description is merely an embodiment of this application and does not limit the patent scope of this application. Any equivalent structural or procedural transformations made using the content of this application's specification and drawings, or direct or indirect applications in other related technical fields, are similarly included within the patent protection scope of this application.

Claims

1. A circuit board firmware management method, characterized in that, The method includes: The R&D system generates new firmware build artifacts and their corresponding integrity verification files based on the firmware code. The R&D system uploads the new firmware build product and its corresponding integrity verification file to the product library server; The automated testing system initiates query requests to the artifact repository server based on a preset polling strategy to identify whether there are new firmware build artifacts; the automated testing system is deployed in the testing environment; When the automated testing system identifies the new firmware build artifact, it obtains the new firmware build artifact and its corresponding integrity verification file from the artifact repository server, and verifies the integrity of the new firmware build artifact based on the integrity verification file. After verification, the automated testing system deploys the new firmware build artifact to a preset test execution environment to execute a predefined set of test cases corresponding to the new firmware build artifact in the test execution environment and collect test process data. The production system receives metadata of a new firmware build artifact sent by the automated testing system. The metadata includes at least the version identifier, storage path, and integrity check value of the new firmware build artifact. The new firmware build artifact is the new firmware build artifact that has passed the test by the automated testing system. The production system binds the new firmware build artifacts to production orders.

2. The circuit board firmware management method according to claim 1, characterized in that, After collecting the test process data, the method further includes: The automated testing system generates a test report in a preset standard format based on the test process data, and uploads the test report to the artifact library server to establish an association storage with the corresponding new firmware build artifact; The automated testing system identifies the test results in the test report. If the test result is passed, it adds a production-ready identifier to the corresponding new firmware build product in the artifact library server and triggers the sending of metadata of the new firmware build product to the manufacturing execution system. The metadata includes at least the version identifier, storage path, and integrity check value of the new firmware build product, so that the manufacturing execution system binds the new firmware build product to the production order.

3. The circuit board firmware management method according to claim 1, characterized in that, When the automated testing system identifies the new firmware build artifact, it retrieves the new firmware build artifact and its corresponding integrity verification file from the artifact repository server, including: When the automated testing system identifies the new firmware build artifact, it retrieves the new firmware build artifact and its corresponding integrity verification file from the artifact repository server via HTTP authentication.

4. The circuit board firmware management method according to claim 1, characterized in that, The R&D system generates new firmware build artifacts and their corresponding integrity verification files based on the firmware code, including: In response to a code push or merge request, the R&D system sends a corresponding POST request to the open-source automation platform via a network hook, causing the open-source automation platform to trigger pipeline operations; wherein, the open-source automation platform is used to implement continuous integration and continuous delivery processes; the POST request carries the code metadata of the firmware code; The pipeline operation includes the following process: Call the container interface to build a temporary container; The code metadata is compiled in the temporary container to obtain the new firmware build artifact and its corresponding integrity verification file.

5. The circuit board firmware management method according to claim 4, characterized in that, The process of compiling the code metadata in the temporary container to obtain the new firmware build artifact and its corresponding integrity verification file includes: The code metadata is compiled in the temporary container to obtain the new firmware build artifact, and the integrity verification file corresponding to the new firmware build artifact is calculated by the md5sum command.

6. The circuit board firmware management method according to claim 4, characterized in that, After the R&D system generates a new firmware build artifact and its corresponding integrity verification file based on the firmware code, the method further includes: The R&D system uploads compilation logs to the artifact repository server; wherein the compilation logs are generated when the code metadata is compiled.

7. The circuit board firmware management method according to claim 1, characterized in that, After the production system binds the new firmware build artifact to the production order, the method further includes: The production system establishes a secure connection with the programming terminal; The production system calls the firmware distribution interface to send an encrypted address to the burning terminal, so that the burning terminal can download the new firmware build product from the product library server through the encrypted address, and use the new firmware build product to burn firmware onto the circuit board. The production system receives the burning results from the burning terminal.

8. A circuit board firmware management system, characterized in that, The circuit board firmware management system includes: an automated testing system, a research and development system, and a production system deployed in a testing environment; the automated testing system, the research and development system, and the production system are used to implement the circuit board firmware management method as described in any one of claims 1-7.

Images