Firmware release control method and device for embedded firmware, and electronic device

Abstract

Embodiments of the present application provide a firmware release control method and device for embedded firmware, and an electronic device, wherein the method comprises: continuously monitoring a change object of a current firmware version of an embedded firmware to be released; in response to monitoring that the current change content corresponding to the change object, matching the current change content with a historical problem constraint template in a historical problem constraint template set, in the case of matching at least one target problem constraint template from the historical problem constraint template set, inheriting the at least one target problem constraint template to the current firmware version to obtain a current problem constraint set; based on the current problem constraint set, performing multi-dimensional verification on the current firmware version to obtain a multi-dimensional verification result, and based on the multi-dimensional verification result, performing a release control operation on the embedded firmware to be released. Through the present application, the regression risk of the embedded firmware is effectively reduced, and the version release quality is improved.

Description

Technical Field

[0001] This application relates to the field of embedded firmware technology, and more specifically, to a firmware release control method and apparatus, and an electronic device for embedded firmware. Background Technology

[0002] As embedded systems become increasingly complex and firmware version iterations become more frequent, various operations during actual R&D and maintenance, such as introducing new features, upgrading third-party vendor firmware, parameter tuning, hardware configuration changes, timing adjustments, and power path modifications, can all impact the behavior of existing systems and cause historical issues to reappear in subsequent versions. Currently, related technologies typically employ defect management systems (bug systems), test case management platforms, summaries of human experience, and version release checklists for quality management and risk control.

[0003] However, in embedded firmware development and release scenarios, the aforementioned methods such as defect management systems, test case management platforms, manual experience summaries, and version release checklists only serve as static records after historical issues have been fixed. The risk conditions, trigger paths, and verification requirements after historical issues have been fixed are difficult to be automatically inherited to new versions. This makes it impossible for developers to accurately identify high-risk modules, configuration items, and key log characteristics, which in turn leads to the repeated occurrence of the same historical issues in different firmware versions. Summary of the Invention

[0004] This application provides a firmware release control method, apparatus, and electronic device for embedded firmware, to at least solve the technical problem in related technologies where the same historical problems repeatedly occur in different firmware versions because they are only statically recorded after being repaired.

[0005] According to one aspect of the embodiments of this application, a firmware release control method for embedded firmware is provided, comprising: continuously monitoring change objects of the current firmware version of the embedded firmware to be released; in response to detecting the current change content corresponding to the change object, matching the current change content with historical issue constraint templates in a historical issue constraint template set, wherein the historical issue constraint templates in the historical issue constraint template set match the firmware type of the embedded firmware to be released, each historical issue constraint template in the historical issue constraint template set corresponds to a closed historical issue data and records at least one risk element extracted from the corresponding historical issue data; when at least one target issue constraint template is matched from the historical issue constraint template set, inheriting the at least one target issue constraint template to the current firmware version to obtain a current issue constraint set; performing multi-dimensional verification on the current firmware version based on the current issue constraint set to obtain multi-dimensional verification results, and performing release control operations on the embedded firmware to be released based on the multi-dimensional verification results.

[0006] According to another aspect of the embodiments of this application, a firmware release control device for embedded firmware is also provided, comprising: a monitoring unit, configured to continuously monitor the change objects of the current firmware version of the embedded firmware to be released; a matching unit, configured to, in response to detecting the current change content corresponding to the change object, match the current change content with historical issue constraint templates in a historical issue constraint template set, wherein the historical issue constraint templates in the historical issue constraint template set match the firmware type of the embedded firmware to be released, each historical issue constraint template in the historical issue constraint template set corresponds to a closed historical issue data, and records at least one risk element extracted from the corresponding historical issue data; an inheritance unit, configured to, when at least one target issue constraint template is matched from the historical issue constraint template set, inherit the at least one target issue constraint template to the current firmware version to obtain a current issue constraint set; and a control unit, configured to, based on the current issue constraint set, perform multi-dimensional verification on the current firmware version to obtain multi-dimensional verification results, and, based on the multi-dimensional verification results, perform release control operations on the embedded firmware to be released.

[0007] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, wherein a computer program is stored therein, wherein the computer program is configured to perform the steps in any of the above method embodiments when executed by a processor.

[0008] According to another aspect of the embodiments of this application, a computer program product or computer program is provided, the computer program product or computer program including computer instructions stored in a computer-readable storage medium. A processor of a computer device reads the computer instructions from the computer-readable storage medium, and the processor executes the computer instructions, causing the computer device to perform the steps in any of the method embodiments described above.

[0009] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program, and the processor is configured to perform the steps of any of the above method embodiments through the computer program.

[0010] This application continuously monitors the change objects of the current firmware version of the embedded firmware to be released, enabling real-time acquisition of changes in the current firmware version during R&D iterations. In response to the detected change content, the current change content is matched with historical issue constraint templates in a historical issue constraint template set. These historical issue constraint templates match the firmware type of the embedded firmware to be released, and each historical issue constraint template corresponds to a closed historical issue data point, recording at least one risk element extracted from the corresponding historical issue data. This allows identification of whether the current change content touches upon risk elements already present in historical issues, thus proactively associating relevant historical risk knowledge when a change occurs. If at least one target issue constraint template is matched from the historical issue constraint template set, this target issue constraint template is inherited into the current firmware version. This approach transforms static historical problem-solving experience into dynamic development constraints that the current firmware version must adhere to. This ensures that the risk conditions, trigger paths, and verification requirements of historical problems remain effective in subsequent versions, avoiding the loss of constraints due to reliance on manual memory or static documentation. Based on this constraint set, the current firmware version undergoes multi-dimensional verification, providing comprehensive checks to ensure it meets inherited risk constraints. Finally, based on the multi-dimensional verification results, release control operations are performed on the embedded firmware to be released. Release is allowed when the multi-dimensional verification results show that the current firmware version meets all historical problem constraints; otherwise, the release process is blocked. This achieves automatic inheritance, automatic verification, and automatic release blocking of historical problem constraints, effectively reducing the risk of embedded firmware regression and improving version release quality. Therefore, it solves the technical problem in related technologies where historical problem fixes are merely static records, leading to the recurrence of similar historical problems in different firmware versions. Attached Figure Description

[0011] Figure 1 This is a schematic diagram illustrating an application scenario of a firmware release control method for embedded firmware according to an embodiment of this application.

[0012] Figure 2 This is a flowchart illustrating an optional embedded firmware release control method according to an embodiment of this application.

[0013] Figure 3 This is a schematic diagram of an optional change detection method according to an embodiment of this application;

[0014] Figure 4 This is a schematic diagram of an optional matching history constraint template according to an embodiment of this application;

[0015] Figure 5 This is a schematic diagram illustrating an optional method for collecting historical issues according to an embodiment of this application;

[0016] Figure 6 This is a schematic diagram illustrating an optional risk factor extraction method according to an embodiment of this application;

[0017] Figure 7 This is a schematic diagram illustrating the generation of an optional historical problem constraint template according to an embodiment of this application;

[0018] Figure 8 This is a schematic diagram of an optional historical problem constraint template saving process according to an embodiment of this application;

[0019] Figure 9 This is a schematic diagram of an optional release control process according to an embodiment of this application;

[0020] Figure 10 This is a structural block diagram of an optional embedded firmware release control device according to an embodiment of this application;

[0021] Figure 11 This is a computer system architecture block diagram of an optional electronic device according to an embodiment of this application. Detailed Implementation

[0022] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0023] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0024] According to one aspect of the embodiments of this application, a firmware release control method for embedded firmware is provided. Optionally, in this embodiment, the above-described firmware release control method for embedded firmware can be applied to, but is not limited to, applications such as... Figure 1 The hardware environment shown includes terminal device 102 and server 104. Server 104 can be connected to terminal device 102 via a network and can be used to provide services (e.g., application services, etc.) to terminal device 102 or clients installed on terminal device 102. A database can be set up on server 104 or independently of server 104 to provide data storage services for server 104.

[0025] The aforementioned network may include, but is not limited to, at least one of the following: wired network and wireless network. The aforementioned wired network may include, but is not limited to, at least one of the following: wide area network (WAN), metropolitan area network (MAN), and local area network (LAN). The aforementioned wireless network may include, but is not limited to, at least one of the following: Wireless Fidelity (WIFI) and Bluetooth. Terminal device 102 may be, but is not limited to, a personal computer (PC), mobile phone, tablet computer, power supply controller, embedded controller, etc. Server 104 may be, but is not limited to, a cloud server, server cluster, or other server types.

[0026] The firmware release control method for embedded firmware in this application embodiment can be executed by server 104, terminal device 102, or jointly by server 104 and terminal device 102. Alternatively, the firmware release control method for embedded firmware in this application embodiment can be executed by a client installed on the terminal device 102.

[0027] Taking the firmware release control method of the embedded firmware in this embodiment executed by the terminal device 102 as an example, Figure 2This is a flowchart illustrating an optional embedded firmware release control method according to an embodiment of this application, as shown below. Figure 2 As shown, the process of this method may include the following steps:

[0028] Step S202: Continuously monitor the change objects of the current firmware version of the embedded firmware to be released;

[0029] Step S204: In response to detecting the current change content corresponding to the changed object, the current change content is matched with the historical problem constraint templates in the historical problem constraint template set. The historical problem constraint templates in the historical problem constraint template set match the firmware type of the embedded firmware to be released. Each historical problem constraint template in the historical problem constraint template set corresponds to a closed historical problem data and records at least one risk element extracted from the corresponding historical problem data.

[0030] Step S206: If at least one target problem constraint template is matched from the historical problem constraint template set, the at least one target problem constraint template is inherited to the current firmware version to obtain the current problem constraint set;

[0031] Step S208: Based on the current problem constraint set, perform multi-dimensional verification on the current firmware version to obtain multi-dimensional verification results, and perform release control operations on the embedded firmware to be released based on the multi-dimensional verification results.

[0032] The firmware release control method for embedded firmware in this embodiment can be applied to the field of embedded firmware technology and to scenarios where firmware release control is performed on embedded firmware.

[0033] As embedded systems become increasingly complex and firmware version iterations become more frequent, various operations during actual R&D and maintenance, such as introducing new features, upgrading third-party vendor firmware, parameter tuning, hardware configuration changes, timing adjustments, and power path modifications, can all impact the behavior of existing systems and cause historical issues to reappear in subsequent versions. Currently, related technologies typically employ defect management systems (bug systems), test case management platforms, summaries of human experience, and version release checklists for quality management and risk control.

[0034] However, in the embedded firmware development and release scenarios of related technologies, historical issues, after being fixed, are often statically recorded only in the form of defect closures, test passes, or experience documents. The corresponding risk conditions, trigger paths, and verification requirements after the historical issues are fixed are difficult to automatically inherit into the development process of subsequent versions. Therefore, subsequent developers often find it difficult to know the following in a timely manner: which modules have historical high-risk issues; which configuration items should not be modified arbitrarily; which test items must be re-executed; which key logs need to be verified; and which initialization sequences or power sequences must be met.

[0035] Therefore, in the absence of a continuous constraint mechanism, the experience gained in fixing historical problems is difficult to translate into automated risk prevention and control rules for subsequent versions, resulting in the recurrence of similar problems in different versions, configurations, or modification scenarios.

[0036] To at least partially address the aforementioned technical issues, this embodiment establishes a closed-loop mechanism of "historical problem extraction—constraint generation—version inheritance—automatic verification—release blocking," transforming historical problem governance from a discrete management approach reliant on manual experience into a standardized and automated process that can be systematically executed. This helps promote the standardization of embedded firmware R&D, testing, and release management systems, improves overall R&D efficiency and quality control levels, and effectively reduces embedded firmware regression risks by transforming historical problems from "static defect records" into "executable R&D constraints." These constraints are then integrated into subsequent version development, testing, verification, and release access control processes, thereby enhancing version release quality and forming a sustainable and reusable enterprise-level historical problem governance capability. Specifically, continuous monitoring of changes to the current firmware version of the embedded firmware to be released enables real-time acquisition of information on changes to the current firmware version during development iterations. In response to the detected changes, the current changes are matched against historical issue constraint templates in a historical issue constraint template set. These historical issue constraint templates match the firmware type of the embedded firmware to be released, and each historical issue constraint template corresponds to a closed historical issue and records at least one risk element extracted from the corresponding historical issue data. This allows identification of whether the current changes affect risk elements already present in historical issues, thus proactively associating relevant historical risk knowledge when a change occurs. If at least one target issue constraint template is matched from the historical issue constraint template set, this target issue constraint template is inherited into the current firmware version, resulting in... The current issue constraint set transforms static historical issue fixing experience into dynamic development constraints that the current firmware version must follow. This ensures that the risk conditions, trigger paths, and verification requirements of historical issues remain effective in subsequent versions, avoiding constraint gaps caused by reliance on manual memory or static documentation. Based on the current issue constraint set, the current firmware version undergoes multi-dimensional verification, obtaining multi-dimensional verification results that comprehensively check whether the current firmware version meets the inherited risk constraint requirements. Finally, based on the multi-dimensional verification results, release control operations are performed on the embedded firmware to be released. When the multi-dimensional verification results show that the current firmware version meets all historical issue constraint requirements, release is allowed; when the multi-dimensional verification results show unmet constraints or a possibility of historical risk recurrence, the release process is blocked. This achieves automatic inheritance, automatic verification, and automatic release blocking of historical issue constraints, effectively reducing the risk of embedded firmware regression and improving the quality of version releases.

[0037] In this embodiment, the embedded firmware to be released refers to the embedded software system that is ready for version release. Optionally, the embedded firmware runs on embedded hardware devices (such as embedded controllers (such as computers, mobile phones, etc.), Internet of Things (IoT) and smart home devices, etc.) and is used to control the basic functions and operating logic of the hardware.

[0038] The current firmware version of the embedded firmware to be released refers to the specific software version instance that is being built, tested and prepared for release during the embedded firmware's R&D iteration cycle. Optionally, the current firmware version includes all merged code, configuration and dependencies of historical firmware versions.

[0039] The change object of the current firmware version of the embedded firmware to be released refers to the software development object that causes the difference between the current firmware version and the historical firmware version. Optionally, the change object of the current firmware version may include code commit records, configuration file modifications, third-party firmware upgrade operations or hardware version changes.

[0040] The current changes to the changed object refer to the specific changes made to that object. Optionally, the current changes include modified code file paths, modified configuration parameter values, newly added or deleted functional module code, and related build log information. For example, the system continuously monitors changed objects in the current firmware version. Changed objects include, but are not limited to: code commit records (Git Commit); code review requests (such as Gerrit Change List (GerritCL); Repo Manifest); firmware configuration files; kernel / firmware configuration scripts (Kconfig); device tree; board-level configuration files; vendor firmware versions; parameter files or hardware configuration tables. The system can trigger a change scan to monitor changed objects in the current firmware version each time a code commit is made, a CL is merged, a build version is created, or a release request is initiated.

[0041] For example, Figure 3 This is a schematic diagram of an optional change detection method according to an embodiment of this application, such as... Figure 3 As shown, the system continuously monitors the changed objects in the current development version. It triggers change scanning every time code is committed, merged into CL, built, or a release request is initiated. In response to the detected change content corresponding to the changed object, the system matches the current change content with the historical issue constraint templates in the historical issue constraint template set.

[0042] The historical problem constraint template set refers to a database, structured file system, or rule engine that includes all developed constraint rules. Optionally, the historical problem constraint template set includes risk control rules extracted and structured from historical R&D processes. The historical problem constraint template set includes multiple historical problem constraint templates.

[0043] A historical problem constraint template refers to a set of structured constraint rules generated for a single historical problem. Optionally, the historical problem constraint template records the triggering conditions, associated modules, key code paths, exception characteristics, event sequence relationships, and verification requirements for the corresponding historical problem.

[0044] Here, the historical problem constraint templates in the historical problem constraint template set are matched with the firmware type of the embedded firmware to be released. It can be understood that the system selects historical problem constraint templates from the historical problem constraint template set that are applicable to the specific firmware type of the embedded firmware to be released (such as embedded controller (EC) firmware, basic input / output system (BIOS) firmware, power delivery (PD) controller firmware, etc.) to ensure the applicability and accuracy of the constraint rules.

[0045] The firmware type of the embedded firmware to be released refers to the type of hardware platform or functional domain on which the embedded firmware to be released runs. Optionally, the firmware type of the embedded firmware to be released may include one or more of the following: embedded controller firmware, power delivery controller firmware, USB Type-C controller firmware, battery management firmware, BIOS / Unified Extensible Firmware Interface (UEFI) firmware, ChromeOS embedded firmware, IoT device firmware, or industrial control firmware.

[0046] Each historical issue constraint template in the historical issue constraint template set corresponds to a closed historical issue data. A closed historical issue data refers to issue data that has been marked as fixed and verified in a historical firmware version. Optionally, historical issue data may include information such as issue phenomenon, root cause, fix, reproduction steps and closure time.

[0047] Here, each historical problem constraint template in the historical problem constraint template set corresponds to a closed historical problem data. It can be understood that each historical problem constraint template in the historical problem constraint template set is uniquely associated with a closed historical problem data. The historical problem constraint template set template is a dynamic rule carrier generated by extracting risk information from the corresponding closed historical problem data.

[0048] Each historical issue data includes at least one risk element. At least one risk element refers to a set of key features extracted from closed historical issue data to define the recurrence conditions of the historical issue. Optionally, at least one risk element may include at least one of risk modules, risk configurations, code paths, anomaly characteristics, event sequence relationships, and associated test requirements.

[0049] A target issue constraint template refers to a historical issue constraint template that is matched with the current change content from the historical issue constraint template set. Optionally, matching at least one target issue constraint template from the historical issue constraint template set means that the current change content touches on at least one risk element recorded in at least one target issue constraint template. The target issue constraint template can be used to constrain the current firmware version, verify whether the current firmware version conforms to the release process, and thus perform release control operations on the embedded firmware to be released.

[0050] The current problem constraint set refers to the constraint set obtained by inheriting at least one target text constraint template into the current firmware version.

[0051] Optionally, inheriting at least one target issue constraint template into the current firmware version means automatically loading and binding the constraints, verification logic, and blocking rules in the target issue constraint template into the release process of the current firmware version, so that these static historical constraint rules are transformed into dynamic control strategies that the current firmware version must execute.

[0052] It should be noted that the current issue constraint set can be a summary set of all inherited historical issue constraint rules that the current firmware version must satisfy before release. Optionally, the current issue constraint set can include the historical issue constraint set and the current issue constraints of the current firmware version.

[0053] Multi-dimensional verification of the current firmware version refers to the process of performing multi-dimensional verification on the current firmware version according to the constraint rules in the current problem constraint set. Optionally, multi-dimensional verification may include test coverage verification, anomaly feature verification, code path verification, configuration verification, and event timing verification.

[0054] Multi-dimensional verification results refer to the verification results obtained by performing multi-dimensional verification on the current firmware version. Optionally, multi-dimensional verification results may include data such as whether each verification passed, missing test items, detected abnormal features, and timing deviations.

[0055] Optionally, after obtaining the multi-dimensional verification results, release control operations are performed on the embedded firmware to be released based on the multi-dimensional verification results. The release control operations on the embedded firmware to be released refer to determining whether the current firmware version is allowed to enter the release process based on the multi-dimensional verification results. If the multi-dimensional verification results show that there are unmet constraints or the risk of historical risks recurring, the release process is blocked. If the results show that all historical problem constraints are met, the release is allowed.

[0056] In some embodiments, the multi-dimensional verification of the current firmware version based on the current problem constraint set can be performed to obtain the multi-dimensional verification result. This can be achieved by: obtaining the code difference set of the current firmware version relative to historical versions, and using a pre-trained code semantic embedding model to map the code change fragments in the code difference set into semantic vectors; extracting the target historical problem constraint template associated with the current firmware version from the current problem constraint set, and reading the pre-stored risk code semantic vector in the target historical problem constraint template; calculating the semantic similarity index between the semantic vector of the code change fragment and the risk code semantic vector; and determining that the current firmware version has a possibility of semantic-level historical risk recurrence when the semantic similarity index exceeds a preset semantic risk threshold, and generating a semantic risk verification sub-result, wherein the multi-dimensional verification result includes the semantic risk verification sub-result. Alternatively, a virtual hardware model corresponding to the target hardware platform of the embedded firmware to be released is loaded. The virtual hardware model includes a simulated register mapping table, interrupt controller logic, and peripheral state machine. The binary code of the current firmware version is loaded into the virtual hardware model, and a virtual event sequence matching the historical risk triggering conditions recorded in the current problem constraint set is injected. The state change sequence and interrupt response sequence of key registers in the virtual hardware model are captured in real time. The captured state change sequence is compared with the preset safe state convergence path. When it is detected that the state of a key register has not converged to the expected safe state within a preset time window, or an illegal state combination defined in the target constraint set occurs, a virtual operation verification sub-result is generated. The multi-dimensional verification result includes the virtual operation verification sub-result.

[0057] In some embodiments, the method of performing release control operations on the embedded firmware to be released based on the multi-dimensional verification results may include: calculating the comprehensive risk score of the current firmware version according to the risk weight of each verification sub-result in the multi-dimensional verification results; comparing the comprehensive risk score with a preset risk threshold range to classify the current firmware version into a secure release level, a restricted release level, or a prohibited release level; wherein, the restricted release level corresponds to the situation where low-risk constraints are not met but there are no high-risk logical conflicts, and the prohibited release level corresponds to the situation where high-risk constraints are not met or critical security status is abnormal; when it is determined to be a secure release level, a release license file is generated, allowing the embedded firmware to be released to enter the full release process; when it is determined to be a restricted release level, a release restriction instruction is generated, which includes limiting the release scope, reducing the release priority, or adding a mandatory monitoring strategy; limiting the release scope is used to allow the embedded firmware to be released only to non-critical business areas or gray-scale test clusters; the mandatory monitoring strategy is used to monitor key performance indicators in real time after release and trigger automatic rollback when the indicators are abnormal; when it is determined to be a prohibited release level, a release blocking instruction is generated, freezing the release permission of the embedded firmware to be released, and generating a structured remediation report containing specific risk causes and remediation suggestions. Alternatively, when multi-dimensional verification results indicate the presence of configuration risks, locate the configuration item causing the risk; search for historical remediation solutions recorded in the current issue constraint set to obtain similar code remediation patterns; utilize the code generation model to generate at least one candidate mitigation code patch or configuration correction suggestion based on the code remediation pattern and the current code context; automatically integrate the candidate mitigation code patch or configuration correction suggestion into the temporary branch of the current firmware version and re-execute multi-dimensional verification; if the re-verification multi-dimensional verification results show that the risk has been eliminated, generate a release approval instruction and mark the candidate mitigation code patch as a recommended remediation solution for use in the release process; if the risk is still not eliminated after re-verification, maintain the release blocking status and return the candidate mitigation code patch and its verification failure reason to the development work order system.

[0058] Through the embodiments provided in this application, continuous monitoring of the change objects of the current firmware version of the embedded firmware to be released enables real-time acquisition of information on changes in the current firmware version during the R&D iteration process. In response to the detection of the current change content corresponding to the change object, the current change content is matched with historical problem constraint templates in the historical problem constraint template set. The historical problem constraint templates in the historical problem constraint template set match the firmware type of the embedded firmware to be released, and each historical problem constraint template in the historical problem constraint template set corresponds to a closed historical problem data point and records at least one risk element extracted from the corresponding historical problem data. This allows identification of whether the current change content touches upon risk elements already present in historical problems, thereby proactively associating relevant historical risk knowledge when a change occurs. If at least one target problem constraint template is matched from the historical problem constraint template set, the at least one target problem constraint template is inherited into the current firmware version, resulting in the current problem constraint set. This approach transforms static historical problem-solving experience into dynamic development constraints that the current firmware version must adhere to. This ensures that the risk conditions, trigger paths, and verification requirements of historical problems remain effective in subsequent versions, avoiding the lack of constraints caused by reliance on manual memory or static documentation. Based on the current set of problem constraints, the current firmware version undergoes multi-dimensional verification, obtaining multi-dimensional verification results that comprehensively check whether the current firmware version meets the inherited constraints regarding test coverage, anomaly characteristics, code paths, configuration, and timing. Finally, based on the multi-dimensional verification results, release control operations are performed on the embedded firmware to be released. Release is allowed when the multi-dimensional verification results show that the current firmware version meets all historical problem constraints; the release process is blocked when the multi-dimensional verification results show unmet constraints or a possibility of historical risk recurrence. This achieves automatic inheritance, automatic verification, and automatic release blocking of historical problem constraints, effectively reducing the risk of embedded firmware regression and improving version release quality. Therefore, it can solve the technical problem in related technologies where historical problem fixes are only statically recorded, leading to the repeated occurrence of similar historical problems in different firmware versions.

[0059] In one exemplary embodiment, the firmware type of the embedded firmware to be released includes at least one of the following: platform identifier, chipset identifier, and parameter set identifier of configuration parameter set;

[0060] In this embodiment, the platform identifier refers to the unique coded identifier of the hardware platform or board model on which the embedded firmware to be released runs.

[0061] The chipset identifier refers to the model identifier of the chip controlled by the embedded firmware to be released. Optionally, the chipset identifier may include the core processor identifier or the power management chip identifier.

[0062] The parameter set identifier of the configuration parameter set refers to the configuration set version identifier used by the functional modules (such as Type-C PD and battery management) in the embedded firmware to be released.

[0063] Optionally, if the current firmware version includes the firmware type of the embedded firmware to be released, the firmware type of the embedded firmware to be released is matched with the firmware applicability recorded in each historical issue constraint template. For example, if the applicable board type, hardware platform, Vendor Firmware version, or firmware branch of the current firmware version is consistent with the applicability of a historical issue, then the corresponding historical issue constraint template is inherited.

[0064] In some embodiments, matching the current change content with historical issue constraint templates in the historical issue constraint template set includes at least one of the following: if the current change content includes changes to risk modules, matching the risk module to which the current change content belongs with the risk modules recorded in each historical issue constraint template; if the current change content includes changes to code paths, matching the source file path associated with the current change content with the risk code path recorded in each historical issue constraint template; if the current change content includes changes to configuration items, matching the configuration item associated with the current change content with the risk configuration item recorded in each historical issue constraint template.

[0065] In this embodiment, a risk module refers to a software functional unit or driver module that has experienced a failure or has risky characteristics in a historical firmware version of the embedded firmware to be released.

[0066] The changes to risk modules in the current changes refer to the content of risk modules related to historical issues in the current firmware version of the embedded firmware to be released.

[0067] The changes to the code paths mentioned above refer to the code paths related to historical issues in the current firmware version of the embedded firmware to be released.

[0068] The source file path associated with the current change refers to the absolute or relative path of the specific source code file in the version control system where the code change occurred in the current firmware version.

[0069] The risk code path recorded in each historical issue constraint template refers to the set of source code file paths or directory paths that are pre-stored in the historical issue constraint template and are related to a certain historical issue.

[0070] The changes to configuration items in the current changes refer to the risk configuration items related to historical issues in the current firmware version of the embedded firmware to be released.

[0071] The configuration items associated with the current changes refer to the configuration items that have changed in the current firmware version.

[0072] Optionally, in response to detecting the current changes to the object being changed, the system matches the current version's changes with historical issue constraint templates in the constraint asset library to determine whether a historical issue constraint needs to be inherited. The matching methods include at least:

[0073] (1) Risk module matching. If the current change involves modules associated with historical issues (i.e., risk modules), for example, risk modules include UCSI, Type-C, Power Protected Circuit (PPC) or Battery modules, then the corresponding historical issue constraints are inherited;

[0074] (2) Code path matching. If the current change involves a critical code path recorded in the historical issue constraint template, for example, the critical code path includes startup gating logic, prepared device object ready (PDO Ready) judgment logic, power good waiting logic, Type-C state switching logic or GPIO control logic, then the corresponding historical issue constraint is inherited.

[0075] (3) Configuration matching. If the current change involves high-risk configuration items associated with historical issues, such as PDO parameters, battery string configuration, general purpose input / output (GPIO) configuration, or startup gating configuration, then the corresponding historical issue constraints will be inherited.

[0076] For example, Figure 4 This is a schematic diagram of an optional matching history constraint template according to an embodiment of this application, such as... Figure 4As shown, historical constraint templates can be matched from the following aspects: risk module matching (if the current change involves modules associated with historical issues, such as UCSI, Type-C, PPC, or Battery modules, then the corresponding historical issue constraints are inherited); code path matching (if the current change involves critical code paths recorded in the historical issue constraint template); configuration matching (if the current change involves high-risk configuration items associated with historical issues, such as PDO parameters, battery string configuration, GPIO configuration, or startup gating configuration, then the corresponding historical issue constraints are inherited); platform matching (if the board type, hardware platform, Vendor Firmware version, or firmware branch applicable to the current version is consistent with the scope of application of historical issues, then the corresponding historical issue constraints are inherited).

[0077] This embodiment combines firmware type (platform, chip, configuration) for multi-dimensional pre-screening to ensure that only historical risk constraints related to the current version's hardware environment and software configuration are activated and inherited. This avoids irrelevant historical constraints from ineffectively interfering with the current version release process. By independently matching risk modules, code paths, and configuration items, it can more meticulously identify the different dimensions of the impact of current changes on historical risks. These risks can be accurately captured and triggered to trigger corresponding risk prevention and control mechanisms. This can significantly reduce false alarms caused by code refactoring or variable renaming, while improving the running efficiency of the matching algorithm.

[0078] In an exemplary embodiment, the method further includes: upon obtaining closed target historical issue data, extracting risk elements from the target historical issue data according to a preset element type, wherein the preset element type includes at least one of the following: risk module, code path, risk configuration item, exception log feature, event sequence relationship, and associated test item; in response to extracting at least one target risk element, generating a historical issue constraint template based on the at least one target risk element, and storing the generated historical issue constraint template in a template database, wherein the historical issue constraint template set is a set of historical issue constraint templates retrieved from the template database that match the firmware type of the embedded firmware to be released.

[0079] In this embodiment, target historical problem data refers to historical problem data generated in the historical firmware versions of the embedded firmware to be released. Optionally, a closed target historical problem data can record the fault problem, fault cause, repair solution and verification results.

[0080] Preset element types refer to predefined types used to characterize risk dimensions. Optionally, preset element types include at least one of the following: risk module, code path, risk configuration item, exception log characteristics, event sequence relationship, and associated test item.

[0081] Among them, abnormal log characteristics refer to the characteristics that appear in the log when a fault occurs. Optionally, abnormal log characteristics may include error keywords, error codes, or abnormal status strings.

[0082] Event timing relationship refers to the sequence and time constraints of a series of hardware events or software state transitions before a fault occurs. For example, event A must occur within 5ms after event B.

[0083] Related test items refer to the names of necessary test cases or test scenarios used to verify whether the fault has been repaired.

[0084] At least one target risk element refers to at least one risk element in the preset element type.

[0085] A template database is a database used to store historical problem constraint targets. Here, the historical problem constraint template set is a collection of historical problem constraint templates retrieved from the template database that match the firmware type of the embedded firmware to be released.

[0086] Optionally, when generating the historical problem constraint template, an adaptation identifier can be added to the historical problem constraint template. The adaptation identifier can be at least one of the platform identifier, chipset identifier, and parameter set identifier of the configuration parameter set. The adaptation identifier matches the firmware type and is determined based on the firmware version of the embedded firmware corresponding to the target historical problem data.

[0087] In some embodiments, in response to the extraction of at least one target risk element, generating a historical issue constraint template based on at least one target risk element may include: for each extracted target risk element, collecting verification data from at least three independent data sources, including a defect management system, a code repository, and an automated testing platform; calculating the cross-validation consistency score of the target risk element by comparing descriptions, code change records, and test results of the same risk element in different data sources; when the consistency score is lower than a preset consistency threshold, determining the target risk element as a low-confidence element and removing it from the initial risk element set; performing structured processing on the remaining target risk elements to generate an initial historical issue constraint template; assigning a basic confidence weight to each retained target risk element; determining the final confidence weight by multiplying the cross-validation consistency score corresponding to each retained target risk element by a preset value; embedding the final confidence weight into the historical issue constraint template as a priority reference indicator; and storing the generated historical issue constraint template with confidence weights in a template database.

[0088] Optionally, the system will structurally encapsulate at least one extracted target risk element to form a historical problem constraint template. This historical problem constraint template not only includes the extracted risk element but may also include metadata (such as problem number, risk level, applicable platform, etc.). The historical problem constraint template serves as a carrier for transforming historical problem records into rules that can be automatically identified and executed by the system. For example, assuming a historical problem is a Type-C interface negotiation failure during cold start, the system extracts the following: the risk module is the TCPC Driver; the code path is the `tcpm_init` function in `drivers / usb / typec / tcpm.c`; the exception log characteristic is PDO Ready Timeout; and the event timing relationship is that `GPIO_CCD_LOW` must be at least 100ms after `USB_VBUS_ON`. The system packages the above information to generate a constraint template and stores it in the template database.

[0089] In some embodiments, Figure 5 This is a schematic diagram of an optional historical problem collection method according to an embodiment of this application, such as... Figure 5 As shown, historical issues can be collected from the following aspects: issue tickets, issue descriptions, repair instructions, reproduction steps, and closure records in the defect management system; test failure records, test logs, regression test records, and test results in the automated testing platform; Git Commits, Gerrit CLs, patch content, and repair commit records in the code repository; firmware configuration files, board-level configuration files, Kconfig configurations, Device Tree configurations, parameter tables, and Vendor Firmware version information; and runtime records such as EC Log, PD Log, Kernel Log, Boot Log, and Firmware Update Log generated during firmware operation.

[0090] In an optional embodiment, Figure 6 This is a schematic diagram illustrating an optional risk factor extraction method according to an embodiment of this application, such as... Figure 6As shown, the risk elements for each historical issue can be extracted by the system from the issue description, modification records, associated code, associated configurations, and associated logs for each historical issue. Specifically, they can be extracted from the following aspects: Risk modules represent the firmware functional domains or control modules involved in the historical issue; Risk configurations represent high-risk configuration items or parameter items associated with the historical issue; Code paths represent the key control logic involved in the historical issue, not ordinary source file paths, but key control logic that may affect the recurrence of the historical issue; Anomaly characteristics represent the abnormal behavior of the historical issue in logs, status outputs, or error messages, such as error mismatch in type logs; Event sequence relationships represent the order and time constraints of security events that must be met after the historical issue is fixed; Associated tests represent the verification tests that must be performed in subsequent versions after the historical issue is fixed.

[0091] For example, a historical constraint construction module is set up to complete the transformation process from historical issues to historical issue constraint templates. This historical constraint construction module includes a historical issue collection unit, a risk factor extraction unit, a constraint template generation unit, and a constraint asset storage unit. First, historical issue collection is performed. The system collects historical issue data from the historical R&D and testing processes. Historical issue data includes, but is not limited to: issue tickets, issue descriptions, repair instructions, reproduction steps, and closure records from the defect management system; test failure records, test logs, regression test records, and test results from the automated testing platform; Git Commits, Gerrit CLs, patch content, and repair commit records from the code repository; firmware configuration files, board-level configuration files, Kconfig configurations, Device Tree configurations, parameter tables, and VendorFirmware version information; runtime records generated during firmware operation, such as EC Log, PD Log, Kernel Log, Boot Log, and Firmware Update Log; and hardware platform information, board type information, battery information, and interface configuration differences related to the issue. The system can periodically pull closed issues from the defect system via scripts or interfaces, and associate them (closed issues) with fix submission records, test records and log files to form a historical issue sample set.

[0092] In an optional embodiment, Figure 7 This is a schematic diagram illustrating the generation of an optional historical problem constraint template according to an embodiment of this application, such as... Figure 7As shown, in the historical issue constraint template, the system generates a constraint template for each historical issue based on risk factors. The historical constraint template includes at least the following: historical issue identifier; applicable platform information; risk module set; risk configuration set; code path constraint set; abnormal feature constraint set; event sequence constraint set; related test set; constraint triggering conditions; risk level; release blocking rules.

[0093] For example, after obtaining a sample set of historical issues, the system extracts risk factors. For each historical issue, the system extracts risk factors from its issue description, repair records, associated code, associated configurations, and associated logs. Risk factors include at least the following categories:

[0094] (1) Risk module. The risk module is used to represent the firmware functional domain or control module involved in the historical problem. For example, UCSI (USB Type-C Connector System Software Interface); Type-C module; PPC (Power Path Controller) module; Battery module; EC Power Sequence module; Charge Manager.

[0095] (2) Risk configuration. Risk configuration is used to represent high-risk configuration items or parameter items associated with historical issues, such as Power Data Object (PDO) parameters; battery string configuration; GPIO default configuration; Kconfig switch items; Device Tree parameters; temperature threshold / thermal protection threshold; related board-level configuration items;

[0096] (3) Code path. The code path is used to represent the key control code logic involved in the historical problem. The "code path" here is not a regular source file path, but refers to the key control logic that may affect the recurrence of the historical problem, including but not limited to: Application Processor (AP) startup control logic; PDO Ready status judgment logic; Type-C negotiation state switching logic; GPIO set (pull high / pull low) / reset (release / pull high / pull low) (Assert / Deassert) control logic; Power path controller enable (PPC Enable) / Charge PathSelect (Charge PathSelect) control logic;

[0097] (4) Abnormal characteristics. Abnormal characteristics are used to indicate the abnormal behavior of historical problems in logs, status outputs or error messages, such as "PDO mismatch"; "didn't find DP alternate mode"; "Partner not responding"; initialization failure error code; charging path switching failure status; battery identification abnormal prompt;

[0098] (5) Event timing relationship. The event timing relationship is used to represent the order and time constraints of security events that must be met after the historical problem is fixed. For example, PDO Ready must precede AP Boot Enable (Power Data Object Ready state, must be achieved before the application processor starts and enables); Power Good must be reached within a preset time window after PPC Enable; GPIO A must precede GPIO B Assert (the valid signal of GPIO A (pull-high or pull-low) must be issued before the valid signal of GPIOB); Type-C Discovery must be completed within the specified timeout period; a certain interrupt response must occur before a certain state switch.

[0099] (6) Correlation tests: Correlation tests are used to represent verification tests that must be performed in subsequent versions after historical issues have been fixed. Examples include Display Port Alt Mode Test, Cold Boot Test, USB PD Compliance Test, Battery Charge Regression Test, Type-C Negotiation Regression Test, and Power Sequence Test.

[0100] In some embodiments, Figure 8 This is a schematic diagram of an optional historical problem constraint template saving process according to an embodiment of this application, such as... Figure 8As shown, the constraint asset is stored in the database. The system stores the generated historical issue constraint templates in the constraint asset database (i.e., the template database). The constraint asset database can be implemented using a database, a structured file system, or a rule engine. It is used to preserve the R&D constraint assets accumulated from the company's historical issues. The following mapping relationships can be set: mapping relationship between historical issues and risk modules; mapping relationship between historical issues and code paths; mapping relationship between historical issues and configuration items; mapping relationship between historical issues and abnormal characteristics; mapping relationship between historical issues and event sequence templates; mapping relationship between historical issues and related tests. Historical issues no longer exist only as closure records in the defect system, but are transformed into historical issue constraint assets that can be automatically called and automatically verified in subsequent version development.

[0101] For example, after obtaining at least one target risk element, the system generates a historical problem constraint template for each historical problem based on the aforementioned risk element. The historical problem constraint template includes at least the following fields: historical problem identifier; applicable platform information; risk module set; risk configuration set; code path constraint set; anomaly characteristic constraint set; event sequence constraint set; related test set; constraint triggering conditions; risk level; and release blocking rules. Specifically, the code path constraint set specifies which key control logic, once modified, must trigger the inheritance and supplementary verification of the historical problem; the anomaly characteristic constraint set specifies which error keywords, error codes, failure states, or abnormal behaviors, once reappearing, indicate a risk of historical problem recurrence; and the event sequence constraint set specifies which key events must satisfy sequential order, preconditions, or time window constraints.

[0102] For example, the generated historical issue constraint templates can be stored in a constraint asset repository. This repository can be implemented using a database, a structured file system, or a rules engine, and is used to permanently store R&D constraint assets accumulated from historical issues within the enterprise. The constraint asset repository can simultaneously store: mappings between historical issues and risk modules; mappings between historical issues and code paths; mappings between historical issues and configuration items; mappings between historical issues and anomaly characteristics; mappings between historical issues and event sequence templates; and mappings between historical issues and associated tests.

[0103] Through the above methods, historical issues are no longer merely closed records in the defect system, but are transformed into historical issue constraint assets that can be automatically invoked and verified in subsequent version development. By extracting historical issue handling experience from scattered bug records, manual memory, and testing habits, and transforming it into structured, executable, and reusable constraint rules, the development, testing, and release processes no longer primarily rely on the experience and judgment of senior personnel. This improves the replicability and stability of the development process and reduces its dependence on individual experience. Furthermore, test constraints are automatically generated based on historical issues, and in subsequent version changes, configuration adjustments, module modifications, or firmware upgrades, the system automatically identifies supplementary test items, mandatory test items, and related verification items, thereby preventing the omission of critical historical regression tests, improving the completeness of test coverage, and enhancing the ability to specifically verify high-risk issues.

[0104] This embodiment transforms historical problem data into standardized historical problem constraint templates, forming reusable risk assets. By automatically extracting risk elements and generating templates, the workload of manually summarizing historical risks is reduced, improving the efficiency and consistency of constraint rule generation, avoiding rule omissions due to human negligence, and by storing historical problem constraint templates in a template database and supporting firmware type-based retrieval, it ensures that the constraint rules inherited in subsequent firmware versions are highly relevant to the current hardware platform and configuration environment, avoiding false alarms of irrelevant historical risks and improving the accuracy of risk prevention and control.

[0105] In an exemplary embodiment, unlike general software defects, many problems in embedded systems are not simply functional logic errors, but are often closely related to hardware initialization processes, module dependencies, configuration matching relationships, and power / timing control processes. Examples include: initialization timing anomalies; incorrect power-on or power-off sequence; PDOReady delay timeout; GPIO Assert / Deassert sequence anomalies; Battery configuration mismatch; Type-C negotiation timeout; insufficient peripheral power-on settling time; and incompatible firmware parameters with hardware versions. These problems typically exhibit clear path dependencies, timing dependencies, and configuration coupling characteristics, with triggering conditions often scattered across multiple dimensions such as code modifications, hardware parameters, firmware configuration, test steps, and runtime logs. Traditional defect management systems usually only record static information such as "problem phenomenon—cause—fix result," making it difficult to transform the aforementioned timing constraints, configuration dependencies, and verification requirements into executable, verifiable, and preventable risk control mechanisms for subsequent versions. Therefore, they cannot continuously constrain such historical risks. To address the issue of unsustainable risk control due to the difficulty in translating the aforementioned timing constraints, configuration dependencies, and verification requirements into executable, verifiable, and preventable risk control mechanisms in subsequent versions, this embodiment transforms historical risks from "static records" to "dynamically executable rules" by converting the multi-dimensional risk elements of historical issues into structured target constraint templates. Through target module association constraints and code path constraints, a precise mapping between code changes and historical risks is established, enabling automatic code-level verification. Target configuration constraints lock high-risk parameters to prevent hidden faults caused by configuration mismatches. Target timing constraints solidify event sequences, dependencies, and timeout windows, resolving the timing coupling issues unique to embedded systems. Target log constraints and test constraints solidify historical anomaly characteristics and regression testing requirements into automated pre-release verification standards. Ultimately, a comprehensive risk prevention and control system covering code, configuration, timing, logs, and testing is constructed, ensuring that historical constraints are inheritable, verifiable, and preventable, effectively preventing regression risks in embedded firmware.

[0106] Generate a historical issue constraint template based on at least one target risk element, including: generating a target module association constraint when at least one target risk element contains a target risk module, wherein the target module association constraint is used to identify the target risk module to establish a module-level association between the changed content and the historical issue; generating a target code path constraint when at least one target risk element contains a target risk code path, wherein the target code path constraint is used to lock the target risk code path to trigger risk verification when a modification of the target risk code path is detected; and generating a target configuration constraint when at least one target risk element contains a target risk configuration item, wherein the target configuration constraint is used to lock... The system includes: a target risk configuration item to trigger risk verification upon detection of modification of the target risk configuration item; a target log constraint to define automatic verification of the target abnormal log feature before firmware release if at least one target risk element contains a target abnormal log feature; a target timing constraint to constrain at least one of the execution order, prerequisite dependencies, and timeout window of the target events if at least one target risk element contains a target associated test item; and a target test constraint to constrain the firmware release to execute the target associated test item if at least one target risk element contains a target associated test item.

[0107] Target module association constraints refer to constraints used to identify target risk modules in order to establish module-level associations between changed content and historical issues.

[0108] Target code path constraints are constraints used to lock down target risk code paths, triggering risk verification when modifications to the target risk code path are detected. The target risk code path refers to the specific source code location where the root cause of a historical problem lies. The target risk code path can include source file paths, specific function names, classes, or critical code blocks, and can represent the specific logic implementation location that caused the failure.

[0109] Target configuration constraints are used to lock down target risk configuration items, triggering risk verification if a target risk configuration item is detected to have been modified. Target risk configuration items refer to specific firmware configuration parameters that affect the reproduction or remediation of historical issues.

[0110] Target log constraints are constraints used to define the characteristics of target anomaly logs for automatic verification before firmware version release. Target timing constraints are constraints used to constrain the execution order of target events, prerequisite dependencies, and at least one of the timeout windows. Target anomaly log characteristics are representative features that can be extracted from system logs during the period in which historical problems occurred.

[0111] Target-related test items refer to test items related to the target risk elements.

[0112] Target test constraints refer to constraints used to constrain firmware versions to perform target-related test items.

[0113] It should be noted that the constraints in a historical issue constraint template can include at least one of the following: target module association constraints, target code path constraints, target configuration constraints, target log constraints, and target test constraints.

[0114] This embodiment generates corresponding constraint objects for different types of risk factors, and structures historical issues, making the constraint rules clearer. By generating multiple types of constraints such as module associations, code paths, and configuration items, the system can establish risk trigger points from multiple dimensions, including code logic, parameter configuration, runtime logs, temporal behavior, and test coverage. Any abnormal change or verification failure in any dimension can independently trigger risk verification, improving the comprehensiveness of risk identification.

[0115] In an exemplary embodiment, in related technologies, log systems are mainly used for post-event troubleshooting and lack proactive verification capabilities before release. Currently, log systems primarily serve as auxiliary troubleshooting tools after problems occur in the R&D process; that is, after test failures or equipment malfunctions, R&D or testing personnel manually analyze log content to determine the cause of the failure and the attribution of the problem. However, log information is usually not structured with historical problem knowledge, release constraints, and test verification requirements, making it difficult to proactively identify risks before version release. Specifically, log systems in related technologies typically struggle to achieve the following capabilities: automatically identifying log characteristics requiring key verification based on historical problems; automatically checking whether critical initialization paths, state transition paths, or negotiation paths meet historical constraints before release; converting key log patterns from historical problems into reusable automatic verification rules; and issuing warnings or blocking version releases when historical risk log characteristics are detected. Therefore, while log data has high value in problem review and fault localization, related technologies have not yet formed a "proactive verification and risk prevention capability based on historical problems before release," failing to effectively support the prevention and control of historical problem recurrence during embedded system version releases. To address the technical problem that log information is often not structurally linked to historical issue knowledge, release constraints, and testing requirements, thus hindering its proactive risk identification function before version release, this embodiment defines log constraint elements. Key log information from historical issues (such as specified log characteristics and anomaly patterns) is extracted and solidified into verification rules that must be executed before release. This transforms logs from mere post-failure analysis material into core verification evidence in version release access control. By parsing constraint elements and generating issue constraint instances, a structured mapping relationship is established between historical issues and current version verification tasks. This allows for the automatic extraction of specified log characteristics and status items from historical constraint templates, converting log phenomena into reusable and executable automatic verification rules.

[0116] In some embodiments, inheriting at least one target problem constraint template to the current firmware version to obtain a current problem constraint set includes: parsing the constraint elements recorded in each target problem constraint template, wherein one constraint element recorded in each target problem constraint template corresponds to at least one risk element; generating a problem constraint instance based on the constraint elements recorded in each target problem constraint template, and adding the generated at least one problem constraint instance to the current problem constraint set; wherein one constraint element recorded in each target problem constraint template is one of the following: a module association constraint, used to identify a risk module among the functional modules, driver modules, and hardware units associated with historical problems, in order to establish... Establish module-level associations between changes and historical issues; code path constraints to identify risky code paths associated with historical issues, triggering risk verification when a risky code path is detected to have been modified; configuration constraints to identify at least one of the risky configuration items, parameter combinations, and configuration change risks associated with historical issues; log constraints to define at least one of the log characteristics, status items, and exception modes that the firmware version needs to be automatically verified before release; timing constraints to constrain at least one of the initialization timing, power timing, handshake sequence, signal valid level sequence, and timeout window; and test constraints to limit at least one of the verification items, regression test items, related test items, and supplementary test items that the firmware version needs to perform.

[0117] In this embodiment, each target problem constraint template in at least one target problem constraint template includes multiple constraint elements, wherein each constraint element refers to a specific rule defined in the target problem constraint template for characterizing the specified risk control requirements. Here, each constraint element recorded in each target problem constraint template corresponds to a risk element.

[0118] Each constraint element recorded in the target issue constraint template can be one of the following: test constraint, log constraint, configuration constraint, timing constraint, module association constraint, and release blocking rule.

[0119] Test constraints refer to constraints that limit at least one of the following: verification tests, regression tests, and supplementary tests required for a firmware version. Verification tests are standard tests that must be performed before firmware release to ensure the correctness of basic firmware functions, system stability, and compliance with established design specifications. Regression tests are specified test cases that must be re-executed for previously fixed defects (bugs) or known risks. Supplementary tests are additional test items derived from in-depth analysis of historical issues or specific risk scenarios, beyond the standard verification tests and regular regression tests.

[0120] Log constraints are constraints used to define at least one of the specified log characteristics, status items, and exception modes that firmware versions need to be automatically verified before release. Specified log characteristics are those extracted from fault logs of historical issues.

[0121] Status items refer to status items reflected during firmware runtime. Optionally, status items can be specific variable values, register states, or global flag bits that reflect the health status, operating mode, or configuration effectiveness of key system components during firmware runtime.

[0122] An abnormal pattern is a pattern that indicates system failure or performance degradation, formed by combining multiple status items, event sequences, or log characteristics according to specified logic.

[0123] Configuration constraints are used to identify at least one of the configuration items, parameter combinations, and configuration change risks associated with historical issues. Timing constraints are used to constrain at least one of initialization timing, power timing, handshake sequence, signal valid level sequence, and timeout window. Module association constraints are used to identify one of the functional modules, driver modules, and hardware units associated with historical issues.

[0124] Release blocking rules are constraints that limit the execution of at least one of the following in the version release process: alerting, blocking, and access control, when a specified test is missing, a risk configuration change is made, a historical constraint is not met, or a specified log is abnormal.

[0125] A problem constraint instance refers to a constraint instance generated after applying constraint elements to the current firmware version context. Optionally, a problem constraint instance may include specific parameters required to perform verification (such as specific test case IDs, specific log keywords, specific configuration item names, etc.) and the current running status.

[0126] The current problem constraint set can include at least one problem instance.

[0127] In some embodiments, by extracting, structurally modeling, and generating rules from historical issue repair information, issue logs, affected modules, triggering conditions, associated configurations, test paths, and timing dependencies, a corresponding set of development constraints is automatically formed after the historical issue is closed. The set of development constraints includes, but is not limited to: test constraints, used to limit the verification items, regression test items, and supplementary test items that must be executed in subsequent versions; log constraints, used to define key log characteristics, status items, and abnormal patterns that need to be automatically verified before release; configuration constraints, used to identify high-risk configuration items, parameter combinations, and configuration change risks related to historical issues; timing constraints, used to constrain initialization timing, power timing, handshake sequence, signal high / low sequence, and timeout windows; module association constraints, used to identify functional modules, driver modules, hardware units, or firmware subsystems related to historical issues; and release blocking rules, used to perform warnings, interceptions, or access control on the version release process when key test deficiencies, risky configuration changes, unmet historical constraints, or key log anomalies are detected. During subsequent R&D, when code changes, configuration modifications, firmware upgrades, hardware version changes, test plan adjustments, or release requests are detected, the system can automatically identify whether the current version triggers historical risk paths based on the historical issue constraint set, and execute corresponding constraint inheritance, risk verification, and pre-release access control. This allows the triggering conditions, associated modules, test requirements, log characteristics, configuration dependencies, and timing constraints after historical issue fixes to be automatically accumulated into R&D constraint rules, which are continuously inherited and automatically verified during subsequent version development and release. This effectively identifies whether the current version re-triggers historical risk paths, reducing the probability of similar issues re-entering new versions. Furthermore, for numerous issues in embedded firmware caused by factors such as initialization order, power timing, handshake timing, GPIO pull-high / pull-low order, and timeout windows, the system can extract and solidify the timing conditions from historical issues into timing constraints, automatically verifying them during subsequent R&D and pre-release verification. This achieves continuous control over timing-level risks and improves the ability to prevent hidden timing problems.

[0128] This embodiment parses and instantiates historical issue constraint templates into specific issue constraint instances for the current version, enabling historical risk prevention rules to adapt to the current specific firmware version context. This achieves the transformation from general rules to specific execution objects. By aggregating the generated issue constraint instances into the current issue constraint set, a complete, unified, and structured historical risk constraint is established for the current firmware version. This clarifies all historical verification requirements that the current version must meet, providing a clear data foundation for subsequent automated verification and access control. Since the current issue constraint set includes various types of constraint instances such as test, log, configuration, timing, and module association, it can perform comprehensive and multi-dimensional automated verification for the current version, ensuring that the risk of recurrence of historical issues is fully covered and checked in all dimensions (code, configuration, timing, log, test).

[0129] In an exemplary embodiment, based on the current problem constraint set, multi-dimensional verification is performed on the current firmware version to obtain multi-dimensional verification results, including at least one of the following: extracting a set of risky code paths from the current problem constraint set, and performing code path verification on the current firmware version based on the risky code path set, wherein the code path verification is used to determine whether the current firmware version involves modifying risky code paths in the risky code path set; extracting a set of risky configuration items from the current problem constraint set, and performing configuration item verification on the current firmware version based on the risky configuration item set, wherein the configuration item verification is used to determine whether the current firmware version involves modifying risky configuration items in the risky configuration item set; extracting a set of abnormal features from the current problem constraint set, and performing verification on abnormal features... The system performs anomaly feature verification on the current firmware version, specifically verifying that no anomalies from the anomaly feature set appear during the current firmware version's testing process. It also extracts the event timing constraint set from the current issue constraint set and performs event timing verification on the current firmware version based on this set. This verification confirms that the event timing during the current firmware version's operation conforms to the event timing constraints in the event timing constraint set. Finally, it extracts the associated test item set from the current issue constraint set and performs test coverage verification on the current firmware version based on this set. This test coverage verification confirms that the current firmware version's testing process covers the associated test items in the associated test item set that correspond to the current firmware version.

[0130] The set of risky code paths in the current problem constraint set refers to the set of all source code file paths, function names, or key logic blocks related to historical problems extracted from the historical problem constraint template inherited from the current firmware version. Optionally, the set of risky code paths in the current problem constraint set can represent the code modification area that triggered the historical problem.

[0131] The risk configuration item set in the current issue constraint set refers to all firmware configuration items related to historical issues extracted from the historical issue constraint template inherited from the current version.

[0132] The set of abnormal features in the current problem constraint set refers to the set of all features extracted from the historical problem constraint template inherited from the current version that are used to identify signs of recurrence of historical problems.

[0133] The event sequence constraint set in the current issue constraint set refers to the set of all constraint rules extracted from the historical issue constraint template inherited from the current version, which are related to the execution order, prerequisite dependencies, and allowed time windows between specified events.

[0134] The set of associated test items in the current issue constraint set refers to the set of all valid test items that were confirmed to be associated during the historical issue repair verification phase, extracted from the historical issue constraint template inherited from the current version.

[0135] Optionally, the system performs test coverage verification on the current firmware version. Based on the historical issue constraint templates inherited by the current version, the system extracts the associated test sets and checks whether the corresponding test items have been executed in the current version's test records. For example, when the current version modifies the UCSI module, Type-C negotiation logic, or AP boot gating code, the system may require the execution of: DP Alt Mode Test; UCSI Compliance Test; Cold Boot Test; and USB PD Protocol Compliance Test. If the current version has not executed the test items required by historical issues, a risk of missing test coverage is determined, and this result is sent to the risk assessment module.

[0136] Optionally, the current firmware version undergoes anomaly feature verification. This verification determines whether the current version exhibits the same abnormal behavior as historical issues. After testing, the system automatically collects the current version's runtime output information, including but not limited to: embedded controller error logs (EC error logs); PD protocol error logs; kernel exception logs; firmware update failure logs; status anomaly alarm information; and error and failure codes. The system then extracts error keywords, exception codes, protocol failure features, initialization failure features, and status anomaly features from these data and matches them against the anomaly feature constraint set in the historical issue constraint template. If the current version re-encounters issues such as "PDO mismatch," "didn't find DP alternate mode," or "Partner not responding," the system determines that the current version has a risk of recurring historical issue anomaly patterns.

[0137] Optionally, code path verification is performed on the current firmware version. This verification determines whether the current version has modified critical control code paths related to historical issues, thereby identifying code changes that may re-trigger historical problems in advance. The system analyzes the code differences in the current version to identify whether the following types of critical logic have been modified: startup condition control logic; state machine switching logic; protocol handshake status judgment logic; conditional wait logic such as Power Good, PDO Ready, and Battery Ready; timeout, retry, and failure recovery logic; GPIO Assert / Deassert control logic; and power path control logic such as PPCEnable, Charge Path Select, and VBUS Control. If it is found that the current version has modified critical code paths in the historical problem constraint template, the current version is deemed to have triggered code path risks, and further requirements may be made: perform correlation testing; perform event timing verification; increase the risk level of the current version; and send the results to the release access control module. It should be noted that code path verification is a pre-development risk identification measure, the purpose of which is to identify code changes that may cause historical problems to recur before the problem is exposed through logs.

[0138] Optionally, configuration verification is performed on the current firmware version to determine whether the current version has modified high-risk configuration items related to historical issues. The verification targets configuration files, parameter files, board-level configurations, and firmware parameters, not control logic code. The system automatically compares the configuration differences between the current version and historically secure versions, identifying the following types of risky configuration changes: PDO parameter table changes; Battery Cell Count modifications; GPIO default configuration changes; Device Tree node parameter changes; Kconfig option changes; Thermal Threshold parameter changes; Vendor Firmware version changes; and board-level function switch changes. If a high-risk configuration item is detected to have been modified, the system may automatically require the execution of historical regression tests related to that configuration item, or trigger event timing verification.

[0139] Optionally, event timing verification is performed on the current firmware version. This verification determines whether the current version still satisfies the sequence and timing of security events formed after historical issue fixes. The verification object is the runtime event sequence, not the exception text logs or static code logic. The system automatically collects event trajectory data related to the firmware operation process, including but not limited to: General Purpose Input / Output Pin Events (GPIO Events); PD Events; Power Events; Interrupt Events; Boot Events; State Transition Events; Charge Path Events; and Type-C Discovery Events. Each event can include a timestamp, event type, event source, status value, and context information. The system constructs the runtime event sequence of the current version based on the event timestamps and compares it with the event timing constraint set in the historical issue constraint template.

[0140] In an optional embodiment, event timing constraints may include: the order of critical events; dependencies of preceding events; maximum allowed timeout; state transition window; prohibited reverse order relationships; and mandatory completion conditions.

[0141] For example, if historical issues require that: PDO Ready must precede AP Boot Enable; Power Good must occur within a preset time window after PPC Enable; Type-C Discovery must be completed before the negotiation timeout; and the current version's runtime event sequence does not meet any of the above conditions, then the system determines that the current version has a risk of historical timeline path regression.

[0142] This embodiment performs verification across five different dimensions: code path, configuration items, anomaly characteristics, event sequence, and test coverage. It comprehensively scans the current firmware version from five levels: static code, static configuration, dynamic logs, dynamic sequence, and test process, eliminating blind spots from single-dimensional detection. For different types of historical problem characteristics, it employs the most suitable verification methods for targeted checks, significantly improving the accuracy and recall rate of risk identification. It can automatically execute the entire process from data extraction and comparative analysis to result determination without manual intervention, ensuring consistency of verification standards and execution efficiency. Each verification step outputs verification results independently, enabling the system to accurately identify specific risks in the current version and provide developers with clear remediation guidance.

[0143] In an exemplary embodiment, in related technologies, the version release process typically uses the pass / fail status of the current version's tests as the primary criterion, focusing on whether tests pass and defects are closed, while rarely considering whether the current version has re-triggered the risk path corresponding to historical issues. In other words, the release mechanism in related technologies usually lacks the ability to proactively identify and block the "risk of historical issue recurrence." Therefore, even if the current version has the following characteristics: key tests related to historical issues have not been performed; high-risk configurations related to historical issues have been modified; the security timing conditions on which historical issue repairs depend have been violated; or verification of key log items, status items, or constraints is lacking, it may still be allowed to enter the release process due to superficially passing tests, thereby causing historical issues to re-expose in mass production or subsequent testing stages. To address the aforementioned problem of lacking the ability to proactively identify and block the "risk of historical issue recurrence," this embodiment, based on multi-dimensional verification results, performs release control operations on the embedded firmware to be released, establishing an automatic access control system for firmware release, and intercepting firmware versions that show signs of historical risk recurrence.

[0144] In some embodiments, based on the multi-dimensional verification results, release control operations are performed on the embedded firmware to be released, including: if the multi-dimensional verification results indicate that the verification has failed, performing at least one of the following blocking operations on the release process of the embedded firmware to be released: warning, interception, access control; if the multi-dimensional verification results indicate that the verification has passed, allowing the embedded firmware to be released to enter the release process.

[0145] In this embodiment, performing an early warning during the release process of the embedded firmware to be released means sending a notification (such as an email, instant message, or work order system alert) to inform that the current firmware version has a risk. Intercepting the release process of the embedded firmware to be released means preventing the current firmware version from entering subsequent release stages. Entry control during the release process of the embedded firmware to be released means locking the release permissions of the current firmware version, so that any subsequent automated scripts or manual operations cannot bypass this checkpoint.

[0146] In some embodiments, an alert is triggered when the multi-dimensional verification results show the presence of low-risk or historical risk factors that require attention, but have not yet constituted a fatal error that directly hinders release, or when it serves as an accompanying notification mechanism for blocking operations; an interception is triggered when the multi-dimensional verification results show a high probability of historical problem recurrence risk, and this risk cannot be confirmed as safe through automated means at the current stage; and access control is triggered when at least one verification result fails verification in the multi-dimensional verification results.

[0147] Optionally, confirm that all associated verification items in the multi-dimensional verification results are shown as passed or risk-free (e.g., no modification to risky code paths, no changes to configuration items, no historical anomaly characteristics in logs, timing constraints are met, and all associated test items have been executed and passed). Based on this verified status, the embedded firmware to be released is allowed to enter the release process.

[0148] In some embodiments, a risk assessment module can be set up to uniformly summarize the results of various constraint executions (i.e., multi-dimensional verification results) and output the regression risk conclusion of the current version.

[0149] The risk assessment module receives the following inputs: test coverage verification results; anomaly feature verification results; code path verification results; configuration verification results; event sequence verification results; and the set of historical problem constraints inherited by the current version. The risk assessment module can comprehensively assess the current version based on preset rules or a risk scoring mechanism, such as: whether critical tests are missing; whether historical anomaly features are hit; whether critical code paths have been modified; whether high-risk configuration items have been modified; whether historical time-series regressions have occurred; and whether multiple high-risk conditions are hit simultaneously.

[0150] In an optional embodiment, if the current firmware version meets all three conditions of "hitting a critical code path change + not executing related tests + exhibiting abnormal characteristics", it can be directly identified as a high-risk regression version.

[0151] Optionally, the risk assessment module can also generate a structured risk report, which includes the following: the hit historical issue number; the hit risk module; the hit code path; the hit configuration item; the missing test item; the detected abnormal features; the detected timing anomalies; the verification items to be added; and whether to recommend blocking the release.

[0152] In some embodiments, the release access control module is used to control whether the current firmware version is allowed to enter the release process based on the risk assessment result.

[0153] In one embodiment, the system uniformly performs access control judgment during the firmware Release phase. The Release phase includes, but is not limited to: FW Release (firmware version release); OTA Release (online upgrade release); Factory Release (factory mass production release); Vendor Delivery (delivering the version to the supplier or customer).

[0154] If the risk assessment module determines that the current version has a historical issue regression risk, or that any high-risk constraint is not met, the release access control module will automatically block the version from entering the release process and output the reason for the block. After fixing the issue, supplementing testing, or adjusting the configuration, the developers can re-initiate the release request. The system will then re-execute the above constraint inheritance and constraint verification process until the current version meets all historical issue constraint requirements before allowing it to enter the release process.

[0155] In some embodiments, the system as a whole can be divided into the following five functional modules:

[0156] 1. The historical constraint construction module is used to collect historical issues, extract risk factors, generate constraint templates, and store constraint assets, transforming historical issues into executable constraint templates;

[0157] 2. Change awareness and constraint inheritance module, used to monitor code, configuration and version changes during subsequent version development, and automatically inherit historical issue constraints related to the current change to the current version;

[0158] 3. The constraint execution verification module is used to verify constraints related to historical issues in the current version. Constraint verification includes at least: test coverage verification; exception feature verification; code path verification; configuration verification; and event sequence verification.

[0159] 4. Risk assessment module, used to summarize the execution results of various constraints, assess the regression risk of the current version, and generate a risk report;

[0160] 5. Release the access control module, which is used to determine whether to allow the current firmware version to enter the release process based on the risk assessment results; when there is a risk of historical problem recurrence or constraints are not met, the release will be blocked.

[0161] Optionally, Figure 9 This is a schematic diagram of an optional release control process according to an embodiment of this application, such as... Figure 9 As shown, in the historical constraint construction module, the historical issue collection module collects historical issues, extracts risk factors from historical issues, generates historical issue constraint templates through the constraint template generation module, and stores multiple historical issue constraint templates in the constraint asset library (i.e., the historical issue constraint template set). In the change perception and constraint inheritance module, code / configuration / version changes are detected, historical constraint templates are matched from the constraint asset library, and a set of constraints to be executed in the current version (i.e., the current issue constraint set) is generated. Multi-dimensional verification (including: test coverage verification, anomaly feature verification, code path / configuration verification, event sequence verification) is performed through the constraint execution verification module to obtain multi-dimensional verification results. Risk judgment is performed through the risk assessment module, and release control operations are performed on the embedded firmware to be released through the release access control module.

[0162] Optionally, an embedded firmware regression risk control method, system, and storage medium based on the inheritance of historical problem constraints can be proposed to address the problems of difficulty in continuously constraining historical problems, lack of test coverage, difficulty in identifying configuration risks, easy regression caused by changes in key code paths, and lack of historical problem blocking mechanisms before release during embedded firmware development. Specifically, the system first collects and structures historical problems, extracting risk modules, risk configurations, key code paths, anomaly characteristics, event sequence relationships, and associated test requirements, and generates historical problem constraint templates based on these, storing them in a constraint asset library. During subsequent firmware version development, the system continuously monitors code changes, configuration changes, and firmware version changes, and automatically inherits historical problem constraints related to the current version based on the relationship between the current changes and the historical problem constraint templates. Subsequently, the system performs test coverage verification, anomaly characteristic verification, code path verification, configuration verification, and event sequence verification on the current version, and makes a risk assessment based on the verification results. When any constraint is not met, the system automatically blocks firmware release, thereby preventing historical problems from flowing into subsequent versions. Compared to related technologies that rely solely on bug systems, human experience, and test results, this method goes beyond simply recording when a problem has occurred. It further solidifies historical problem-solving experience into executable rules, ensuring their continued effectiveness throughout subsequent version development, testing, and release phases. This forms a historical problem-driven development constraint system for embedded firmware. Before release, it automatically checks test execution, configuration change risks, key log characteristics, and historical timing constraint fulfillment based on historical problem constraint rules. When high-risk issues are not verified, historical constraints are not met, or risk paths are retried, it executes warnings, blocking, or access control, thereby improving the accuracy of release decisions and the overall quality of firmware versions. It continuously accumulates risk knowledge, constraint rules, and verification logic formed during the repair, verification, and release processes of historical problems, gradually building a historical problem constraint asset library for the enterprise's R&D system. This asset library can be reused across projects, versions, and hardware platforms, providing a unified risk knowledge foundation for subsequent product development, quality governance, and release control.

[0163] This embodiment directly maps multi-dimensional verification results to release control operations (blocking or allowing). The system establishes an automated decision-making chain from historical problem analysis to version release, eliminating the need for manual intervention to determine whether to allow release. This eliminates the possibility of unqualified version releases due to human error. By executing blocking operations such as "early warning, interception, and access control," the system strongly intercepts firmware versions showing signs of historical risk recurrence at the final line of defense before release (release access control). This ensures that firmware versions released to end users or factories are safe in terms of historical risk. The automated verification results enable or disable release, avoiding inconsistent risk control standards caused by differences in experience or subjective judgment among different release personnel. This ensures that all version releases adhere to a unified historical risk prevention standard. Through the "interception" and "early warning" mechanisms, the system can immediately provide feedback on specific historical risks present in a version to the development team, prompting developers to fix problems or supplement verification as soon as possible, shortening the cycle from problem discovery to fix.

[0164] Through the above embodiments, historical issues that occurred and were fixed during the embedded firmware development process are transformed from traditional "static bug records" into "executable, inheritable, verifiable, and preventable" development constraint rules. These rules continue to be effective in subsequent version development, configuration adjustments, parameter changes, hardware modifications, third-party firmware upgrades, and version releases. This establishes a regression risk control mechanism driven by historical issues, enabling the long-term inheritance of historical issue constraints and preventing the loss of problem-fixing experience during version iterations. Automatic tracking of historical risk paths identifies whether subsequent changes re-trigger existing problem conditions. Automatic discovery of missing tests prevents key historical verification items from being overlooked. Automatic identification of configuration risks reduces the probability of recurrence of problems caused by high-risk parameters, hardware configurations, or firmware combinations. Automatic verification of timing anomalies improves the ability to identify anomalies in initialization paths, power paths, and interface negotiation paths. Automatic pre-release access control prevents version release when historical risks are detected as unresolved or key constraints are not met.

[0165] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are preferred embodiments, and the actions and modules involved are not necessarily essential to this application.

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

[0167] According to another aspect of the embodiments of this application, a firmware release control device for embedded firmware is also provided. This embedded firmware release control device can be used to implement the firmware release control method for embedded firmware provided in the above embodiments, and will not be repeated hereafter. As used below, the term "module" can be a combination of software and / or hardware that implements a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware implementation, or a combination of software and hardware, is also possible and contemplated.

[0168] Figure 10 This is a structural block diagram of an optional embedded firmware release control device according to an embodiment of this application, such as... Figure 10 As shown, the firmware release control device for the embedded firmware includes:

[0169] The monitoring unit 1002 is used to continuously monitor the changes to the current firmware version of the embedded firmware to be released.

[0170] The matching unit 1004 is used to match the current change content with the historical problem constraint templates in the historical problem constraint template set in response to the detection of the current change content corresponding to the change object. The historical problem constraint templates in the historical problem constraint template set match the firmware type of the embedded firmware to be released. Each historical problem constraint template in the historical problem constraint template set corresponds to a closed historical problem data and records at least one risk element extracted from the corresponding historical problem data.

[0171] Inheritance unit 1006 is used to inherit at least one target problem constraint template into the current firmware version when at least one target problem constraint template is matched from the historical problem constraint template set, so as to obtain the current problem constraint set.

[0172] The control unit 1008 is used to perform multi-dimensional verification on the current firmware version based on the current problem constraint set, obtain multi-dimensional verification results, and perform release control operations on the embedded firmware to be released based on the multi-dimensional verification results.

[0173] It should be noted that the monitoring unit 1002 in this embodiment can be used to execute the above step S202, the matching unit 1004 in this embodiment can be used to execute the above step S204, the inheritance unit 1006 in this embodiment can be used to execute the above step S206, and the control unit 1008 in this embodiment can be used to execute the above step S208.

[0174] Through the embodiments provided in this application, continuous monitoring of the change objects of the current firmware version of the embedded firmware to be released enables real-time acquisition of information on changes in the current firmware version during the R&D iteration process. In response to the detection of the current change content corresponding to the change object, the current change content is matched with historical issue constraint templates in the historical issue constraint template set. The historical issue constraint templates in the historical issue constraint template set match the firmware type of the embedded firmware to be released, and each historical issue constraint template in the historical issue constraint template set corresponds to a closed historical issue data point and records at least one risk element extracted from the corresponding historical issue data. This allows identification of whether the current change content touches upon risk elements already present in historical issues, thereby proactively associating relevant historical risk knowledge when a change occurs. If at least one target issue constraint template is matched from the historical issue constraint template set, the at least one target issue constraint template is inherited into the current firmware version. This method obtains a set of current problem constraints, transforming static historical problem-solving experience into dynamic development constraints that the current firmware version must follow. This ensures that the risk conditions, trigger paths, and verification requirements of historical problems remain effective in subsequent versions, avoiding the lack of constraints caused by reliance on manual memory or static documentation. Based on the current problem constraint set, the current firmware version undergoes multi-dimensional verification, obtaining multi-dimensional verification results that comprehensively check whether the current firmware version meets the inherited risk constraint requirements. Finally, based on the multi-dimensional verification results, release control operations are performed on the embedded firmware to be released. When the multi-dimensional verification results show that the current firmware version meets all historical problem constraints, release is allowed; when the multi-dimensional verification results show unmet constraints or a possibility of historical risk recurrence, the release process is blocked. This achieves automatic inheritance, automatic verification, and automatic release blocking of historical problem constraints, effectively reducing the risk of embedded firmware regression and improving version release quality. Therefore, it can solve the technical problem in related technologies where historical problem fixes are only statically recorded, leading to the repeated occurrence of similar historical problems in different firmware versions.

[0175] In an exemplary embodiment, the firmware type of the embedded firmware to be released includes at least one of the following: platform identifier, chipset identifier, and parameter set identifier of configuration parameter set; the matching unit 1004 is used for at least one of the following: when the current change content includes change content of a risk module, matching the risk module to which the current change content belongs with the risk module recorded in each historical issue constraint template; when the current change content includes change content of a code path, matching the source file path associated with the current change content with the risk code path recorded in each historical issue constraint template; when the current change content includes change content of a configuration item, matching the configuration item associated with the current change content with the risk configuration item recorded in each historical issue constraint template.

[0176] In an exemplary embodiment, the apparatus further includes an extraction unit, which is configured to extract risk elements from the target historical issue data according to a preset element type when a closed target historical issue data is obtained, wherein the preset element type includes at least one of the following: risk module, code path, risk configuration item, exception log feature, event sequence relationship, and associated test item; in response to the extraction of at least one target risk element, generate a historical issue constraint template based on the at least one target risk element, and store the generated historical issue constraint template in a template database, wherein the historical issue constraint template set is a set of historical issue constraint templates retrieved from the template database that match the firmware type of the embedded firmware to be released.

[0177] In one exemplary embodiment, the extraction unit is configured to: generate a target module association constraint when at least one target risk element contains a target risk module, wherein the target module association constraint is used to identify the target risk module to establish a module-level association between the changed content and historical issues; generate a target code path constraint when at least one target risk element contains a target risk code path, wherein the target code path constraint is used to lock the target risk code path to trigger risk verification upon detection that the target risk code path has been modified; and generate a target configuration constraint when at least one target risk element contains a target risk configuration item, wherein the target configuration constraint is used to lock the target risk configuration item. The system sets a risk verification option to be triggered when a target risk configuration item is detected to have been modified. If at least one target risk element contains a target anomaly log feature, a target log constraint is generated, wherein the target log constraint defines the automatic verification of the target anomaly log feature before firmware release. If at least one target risk element contains a timing relationship of target events, a target timing constraint is generated, wherein the target timing constraint constrains at least one of the execution order, prerequisite dependencies, and timeout windows of target events. If at least one target risk element contains a target associated test item, a target test constraint is generated, wherein the target test constraint constrains the firmware version to execute the target associated test item.

[0178] In an exemplary embodiment, the inheritance unit 1006 is configured to parse the constraint elements recorded in each target problem constraint template in at least one target problem constraint template, wherein one constraint element recorded in each target problem constraint template corresponds to at least one risk element; based on the constraint elements recorded in each target problem constraint template, a problem constraint instance is generated respectively, and the generated at least one problem constraint instance is added to the current problem constraint set; wherein one constraint element recorded in each target problem constraint template is one of the following: a module association constraint, used to identify a risk module among the functional modules, driver modules, and hardware units associated with historical problems, so as to establish a relationship between the changed content and the historical problems. The system includes: module-level associations; code path constraints, used to identify risky code paths associated with historical issues, triggering risk verification when a risky code path is detected to have been modified; configuration constraints, used to identify at least one of the risky configuration items, parameter combinations, and configuration change risks associated with historical issues; log constraints, used to define at least one of the log characteristics, status items, and exception modes that the firmware version needs to be automatically verified before release; timing constraints, used to constrain at least one of the initialization timing, power timing, handshake sequence, signal valid level sequence, and timeout window; and test constraints, used to limit at least one of the verification items, regression test items, associated test items, and supplementary test items that the firmware version needs to perform.

[0179] In one exemplary embodiment, the control unit 1008 is configured to at least one of the following: extract a set of risky code paths from the current problem constraint set, and perform code path verification on the current firmware version based on the risky code path set, wherein the code path verification is used to determine whether the current firmware version involves modifying risky code paths in the risky code path set; extract a set of risky configuration items from the current problem constraint set, and perform configuration item verification on the current firmware version based on the risky configuration item set, wherein the configuration item verification is used to determine whether the current firmware version involves modifying risky configuration items in the risky configuration item set; and extract a set of abnormal features from the current problem constraint set, and perform abnormal feature verification on the current firmware version based on the abnormal feature set. The verification process includes: 1) Anomaly feature verification, which verifies that no anomalies from the anomaly feature set appear during the current firmware version's version testing process; 2) Extracting the event timing constraint set from the current problem constraint set, and performing event timing verification on the current firmware version based on the event timing constraint set, whereby the event timing verification verifies that the event timing during the current firmware version's operation conforms to the event timing constraints in the event timing constraint set; 3) Extracting the associated test item set from the current problem constraint set, and performing test coverage verification on the current firmware version based on the associated test item set, whereby the test coverage verification verifies that the current firmware version's version testing process covers the associated test items in the associated test item set corresponding to the current firmware version.

[0180] In one exemplary embodiment, the control unit 1008 is configured to perform at least one of the following blocking operations on the release process of the embedded firmware to be released if the multi-dimensional verification result indicates that the verification has failed: warning, interception, access control; and allow the embedded firmware to be released to enter the release process if the multi-dimensional verification result indicates that the verification has passed.

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

[0182] According to another aspect of the embodiments of this application, a computer-readable storage medium is provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0183] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as USB flash drives, ROMs, RAMs, portable hard drives, magnetic disks, or optical disks.

[0184] According to another aspect of the embodiments of this application, an electronic device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor. The processor is configured to perform the steps of any of the method embodiments described above via the computer program. In an exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor, and the input / output device is connected to the processor.

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

[0186] According to another aspect of the embodiments of this application, a computer program product is also provided, comprising a computer program / instructions containing program code for performing the methods shown in the flowchart. In such an embodiment, the computer program can be downloaded and installed from a network via communication section 1109, and / or installed from removable medium 1111. When the computer program is executed by central processing unit 1101, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are merely descriptive and do not represent the superiority or inferiority of the embodiments.

[0187] Figure 11 A schematic block diagram of a computer system architecture for implementing embodiments of the present application is shown. Figure 11 As shown, the computer system 1100 includes a Central Processing Unit (CPU) 1101, which can perform various appropriate actions and processes based on programs stored in ROM 1102 or programs loaded into RAM 1103 from storage section 1108. Random access memory 1103 also stores various programs and data required for system operation. The CPU 1101, ROM 1102, and RAM 1103 are interconnected via bus 1104. Input / output (I / O) interface 1105 is also connected to bus 1104.

[0188] The following components are connected to I / O interface 1105: an input section 1106 including a keyboard, mouse, etc.; an output section 1107 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 1108 including a hard disk, etc.; and a communication section 1109 including a network interface card such as a local area network card, modem, etc. The communication section 1109 performs communication processing via a network such as the Internet. A drive 1110 is also connected to I / O interface 1105 as needed. Removable media 1111, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., are installed on drive 1110 as needed so that computer programs read from them can be installed into storage section 1108 as needed.

[0189] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 1109, and / or installed from removable medium 1111. When the computer program is executed by central processing unit 1101, it performs various functions defined in the system of this application.

[0190] It should be noted that, Figure 11 The computer system 1100 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

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

[0192] The above are merely preferred embodiments of this application and are not intended to limit this application. Various modifications and variations can be made to this application by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made within the principles of this application should be included within the protection scope of this application.

Claims

1. A firmware release control method for embedded firmware, characterized in that, include: Continuously monitor the objects affected by changes in the current firmware version of the embedded firmware to be released; In response to detecting the current change content corresponding to the changed object, the current change content is matched with the historical problem constraint templates in the historical problem constraint template set. The historical problem constraint templates in the historical problem constraint template set match the firmware type of the embedded firmware to be released. Each historical problem constraint template in the historical problem constraint template set corresponds to a closed historical problem data and records at least one risk element extracted from the corresponding historical problem data. If at least one target problem constraint template is matched from the set of historical problem constraint templates, the at least one target problem constraint template is inherited to the current firmware version to obtain the current problem constraint set; Based on the current problem constraint set, the current firmware version is verified in multiple dimensions to obtain multi-dimensional verification results. Based on the multi-dimensional verification results, release control operations are performed on the embedded firmware to be released.

2. The method according to claim 1, characterized in that, The firmware type of the embedded firmware to be released includes at least one of the following: platform identifier, chipset identifier, and parameter set identifier of configuration parameter set. The step of matching the current change content with the historical issue constraint templates in the historical issue constraint template set includes at least one of the following: If the current change content includes changes to a risk module, the risk module to which the current change content belongs will be matched with the risk modules recorded in each historical issue constraint template; If the current change content includes changes to code paths, the source file path associated with the current change content will be matched with the risk code paths recorded in each historical issue constraint template; If the current change content includes changes to configuration items, the configuration items associated with the current change content are matched with the risk configuration items recorded in each historical issue constraint template.

3. The method according to claim 1, characterized in that, The method further includes: When a closed target historical issue data is obtained, risk elements are extracted from the target historical issue data according to a preset element type, wherein the preset element type includes at least one of the following: risk module, code path, risk configuration item, abnormal log characteristics, event sequence relationship, and associated test item; In response to the extraction of at least one target risk element, a historical problem constraint template is generated based on the at least one target risk element, and the generated historical problem constraint template is stored in a template database. The historical problem constraint template set is a set of historical problem constraint templates retrieved from the template database that match the firmware type of the embedded firmware to be released.

4. The method according to claim 3, characterized in that, The step of generating a historical problem constraint template based on the at least one target risk factor includes: If the at least one target risk element includes a target risk module, a target module association constraint is generated, wherein the target module association constraint is used to identify the target risk module in order to establish a module-level association between the changed content and the historical issues; If the at least one target risk element contains a target risk code path, a target code path constraint is generated, wherein the target code path constraint is used to lock the target risk code path so as to trigger risk verification if the target risk code path is detected to have been modified. If the at least one target risk element includes a target risk configuration item, a target configuration constraint is generated, wherein the target configuration constraint is used to lock the target risk configuration item so as to trigger risk verification if the target risk configuration item is detected to have been modified. If the at least one target risk element includes a target abnormal log feature, a target log constraint is generated, wherein the target log constraint is used to define the automatic verification of the target abnormal log feature before the firmware version is released; If the at least one target risk element contains a temporal relationship of target events, a target temporal constraint is generated, wherein the target temporal constraint is used to constrain at least one of the execution order, prerequisite dependencies, and timeout window of the target events; If the at least one target risk element includes a target associated test item, a target test constraint is generated, wherein the target test constraint is used to constrain the firmware version to perform the target associated test item.

5. The method according to claim 1, characterized in that, The step of inheriting the at least one target problem constraint template to the current firmware version to obtain the current problem constraint set includes: The constraint elements recorded in each target problem constraint template in the at least one target problem constraint template are parsed, wherein one constraint element recorded in each target problem constraint template corresponds to at least one risk element; Based on the constraint elements recorded in each target problem constraint template, a problem constraint instance is generated, and at least one generated problem constraint instance is added to the current problem constraint set. Wherein, one of the constraint elements recorded in each target problem constraint template is one of the following: Module association constraints are used to identify a risk module among the functional modules, driver modules, and hardware units associated with historical issues, in order to establish a module-level association between the changed content and the historical issues; Code path constraints are used to identify risky code paths associated with historical issues, so as to trigger risk verification if a risky code path is detected to have been modified. Configuration constraints are used to identify at least one of the risky configuration items, parameter combinations, and configuration change risks associated with historical issues; Log constraints are used to define at least one of the following log characteristics, status items, and exception modes that the firmware version needs to be automatically verified before release: Timing constraints are used to constrain at least one of the following: initialization timing, power timing, handshake sequence, signal valid level sequence, and timeout window. Test constraints are used to limit at least one of the following: verification items, regression test items, correlation test items, and supplementary test items that the firmware version needs to perform.

6. The method according to claim 1, characterized in that, Based on the current problem constraint set, the current firmware version is subjected to multi-dimensional verification to obtain multi-dimensional verification results, including at least one of the following: Extract the set of risky code paths from the current problem constraint set, and perform code path verification on the current firmware version based on the set of risky code paths, wherein the code path verification is used to determine whether the current firmware version involves modifying the risky code paths in the set of risky code paths; Extract the risk configuration item set from the current problem constraint set, and perform configuration item verification on the current firmware version based on the risk configuration item set, wherein the configuration item verification is used to determine whether the current firmware version involves modifying the risk configuration items in the risk configuration item set; Extract the set of abnormal features from the current problem constraint set, and perform abnormal feature verification on the current firmware version based on the set of abnormal features. The abnormal feature verification is used to verify that no abnormal features in the set of abnormal features appeared during the version testing process of the current firmware version. Extract the event timing constraint set from the current problem constraint set, and perform event timing verification on the current firmware version according to the event timing constraint set, wherein the event timing verification is used to verify that the event timing during the operation of the current firmware version conforms to the event timing constraints in the event timing constraint set; Extract the set of associated test items from the current problem constraint set, and perform test coverage verification on the current firmware version based on the set of associated test items. The test coverage verification is used to verify that the version testing process of the current firmware version covers the associated test items in the set of associated test items that correspond to the current firmware version.

7. The method according to any one of claims 1 to 6, characterized in that, The step of performing release control operations on the embedded firmware to be released based on the multi-dimensional verification results includes: If the multi-dimensional verification result indicates that the verification has failed, at least one of the following blocking operations shall be performed on the release process of the embedded firmware to be released: warning, interception, access control; If the multi-dimensional verification results indicate that the verification has passed, the embedded firmware to be released is allowed to enter the release process.

8. A firmware release control device for embedded firmware, characterized in that, include: The monitoring unit is used to continuously monitor the changes to the current firmware version of the embedded firmware to be released; A matching unit is configured to, in response to detecting the current change content corresponding to the changed object, match the current change content with the historical issue constraint templates in the historical issue constraint template set, wherein the historical issue constraint templates in the historical issue constraint template set match the firmware type of the embedded firmware to be released, and each historical issue constraint template in the historical issue constraint template set corresponds to a closed historical issue data and records at least one risk element extracted from the corresponding historical issue data; An inheritance unit is used to inherit at least one target problem constraint template into the current firmware version when at least one target problem constraint template is matched from the historical problem constraint template set, thereby obtaining the current problem constraint set; The control unit is used to perform multi-dimensional verification on the current firmware version based on the current problem constraint set, obtain multi-dimensional verification results, and perform release control operations on the embedded firmware to be released based on the multi-dimensional verification results.

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

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

Images