Detection program version publishing method, device, equipment, storage medium and program product

Abstract

The application discloses a kind of detection program version release method, device, equipment, storage medium and program product.The method comprises the following steps: receiving new version detection program to be released, and recording the version information of the new version detection program, the version information includes version identification, dependency, applicable scope and change description;In the verification environment, the new version detection program is executed based on the version information Regression verification, and risk score is generated according to regression verification result;According to the risk score and business constraint, determine the gray release range, the new version detection program is put online in the gray release range, and the monitoring index after online is monitored in real time;If the monitoring index does not meet the rollback condition, then expand the release range;If the monitoring index meets the rollback condition, then trigger version rollback.

Description

Technical Field

[0001] This application relates to the field of industrial vision inspection technology, and more specifically, to a method, apparatus, equipment, storage medium, and program product for releasing inspection program versions. Background Technology

[0002] In industrial vision inspection scenarios for semiconductor and panel manufacturing, inspection systems are gradually adopting procedural inspection architectures to achieve functional decoupling. An inspection program is a composite execution unit that integrates inspection rules, algorithm models, parameter thresholds, context dependencies, and output protocols. It needs to be deployed and iteratively updated in parallel across multiple production lines, multiple machines, multiple product models, and multiple customer project environments to adapt to the differentiated requirements of different process stages and inspection tasks.

[0003] Existing technologies mostly employ a manual configuration management and direct full-scale deployment model. R&D personnel manually copy configuration files and replace algorithm models and rule bases to upgrade the detection program version. Only basic functional verification is performed before deployment, and manual inspection is required to determine the operational status after release. However, this deployment method has significant release risks in large-scale multi-production line deployments and cannot meet the high reliability and stability deployment requirements of the semiconductor and panel industries for industrial testing systems. Summary of the Invention

[0004] The main objective of this application is to provide a method, apparatus, device, storage medium, and program product for releasing a testing program version, in order to solve the problem of uncontrollable risks in deploying testing programs across multiple production lines, and to significantly improve the stability of large-scale deployment.

[0005] To achieve the above objectives, a first aspect of this application proposes a method for releasing a detection program version, comprising: receiving a new version of the detection program to be released and recording the version information of the new version of the detection program, the version information including version identifier, dependencies, scope of application, and change description; performing regression verification on the new version of the detection program based on the version information in a verification environment, and generating a risk score based on the regression verification results; determining a canary release scope based on the risk score and business constraints, launching the new version of the detection program within the canary release scope, and monitoring the monitoring indicators after launch in real time; if the monitoring indicators do not meet the rollback conditions, expanding the release scope; if the monitoring indicators meet the rollback conditions, triggering a version rollback.

[0006] According to the detection program version release method provided in this application, after expanding the release scope or triggering version rollback, the method further includes: recording the full-process audit log of the version release, and generating version governance knowledge based on the full-process audit log; the full-process audit log includes the version creator, approver, release time, gray-scale range, monitoring indicators, abnormal events, rollback operations and handling conclusions, and the version governance knowledge is used to optimize subsequent gray-scale release strategies, rollback strategies and risk scoring strategies.

[0007] According to the detection program version release method provided in this application, the regression verification includes historical sample playback, typical difficult case playback, target customer data playback, and baseline version comparison.

[0008] According to the detection program version release method provided in this application, the step of generating a risk score based on regression verification results includes: generating the risk score by weighting the detection effect, cycle time performance, stability and equipment compatibility results of regression verification, combined with the scope of changes and dependency complexity.

[0009] According to the detection program version release method provided in this application, the real-time monitoring of the monitoring indicators after the new version of the detection program is launched includes: real-time collection of the monitoring indicators of the new version of the detection program, the monitoring indicators including false alarm rate, false negative rate, detection cycle time, system operation stability and device compatibility data; and calculation of the change range and anomaly correlation between the monitoring indicators of the new version of the detection program and the monitoring indicators of the baseline version of the detection program.

[0010] According to a detection program version release method provided in this application, the rollback conditions include at least one of the following: the false alarm rate increases to exceed a first threshold, the false negative rate increases to exceed a second threshold, the average detection latency exceeds a third threshold, the system stability decreases, and the device compatibility is abnormal.

[0011] This application also provides a detection program version release device, comprising the following modules: a receiving and recording module and a verification and release module; the receiving and recording module is used to receive a new version of the detection program to be released and record the version information of the new version of the detection program, the version information including version identifier, dependencies, scope of application, and change description; the verification and release module is used to perform regression verification on the new version of the detection program based on the version information in a verification environment, and generate a risk score based on the regression verification results; determine the canary release scope based on the risk score and business constraints, launch the new version of the detection program within the canary release scope, and monitor the monitoring indicators after launch in real time; if the monitoring indicators do not meet the rollback conditions, the release scope is expanded; if the monitoring indicators meet the rollback conditions, a version rollback is triggered.

[0012] This application also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to implement the detection program version release method as described above.

[0013] This application also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the detection program version release method as described above.

[0014] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the detection program version release method as described above.

[0015] The technical solutions provided by the embodiments of this application can include the following beneficial effects: Since the new version of the detection program can be received and its version identifier, dependencies, scope of application, and change descriptions can be recorded, unified version management of the detection program can be achieved, avoiding version confusion, dependency conflicts, and unclear scope of application caused by manual configuration; since regression verification can be performed based on version information in the verification environment and risk scores can be generated based on the verification results, the risk of the detection program going live can be quantified before release, solving the problem of uncontrollable risks caused by traditional basic function verification; since the gray-scale release scope can be determined based on the risk score and business constraints and the program can be launched within the gray-scale range, the large-scale failure risk caused by direct full-scale deployment can be avoided, achieving small-scale, step-by-step, and controllable release; since the indicators after launch can be monitored in real time and version rollback can be triggered when rollback conditions are met, detection anomalies, performance degradation, and compatibility issues can be detected in a timely manner, preventing the escalation of failures from affecting production line production. Thus, a closed-loop governance of the entire detection program process can be achieved from aspects such as version control, risk quantification, gray-scale release, and anomaly rollback, significantly improving the stability and reliability of multi-production line deployments in semiconductors and panels, and meeting the high reliability and high stability operation requirements of industrial vision inspection systems. Attached Figure Description

[0016] The accompanying drawings, which form part of this application, are used to provide a further understanding of the application and to make other features, objects, and advantages of the application more apparent. The illustrative embodiments and descriptions of this application are used to explain the application and do not constitute an undue limitation of the application. In the drawings: Figure 1 One of the flowcharts illustrating the method for releasing the detection program version provided in this application; Figure 2 The second flowchart illustrating the method for releasing the detection program version provided in this application; Figure 3 This is a schematic diagram of the detection program version release device provided by the present invention; Figure 4 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0017] 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 skilled in the art without creative effort should fall within the scope of protection of the present application.

[0018] 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 for the embodiments of this application 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.

[0019] In this application, the terms "upper," "lower," "left," "right," "front," "rear," "top," "bottom," "inner," "outer," "middle," "vertical," "horizontal," "lateral," and "longitudinal" indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. These terms are primarily for the purpose of better describing this application and its embodiments, and are not intended to limit the indicated device, element, or component to having a specific orientation, or to be constructed and operated in a specific orientation.

[0020] Furthermore, in addition to indicating location or positional relationship, some of the aforementioned terms may also have other meanings. For example, the term "above" may also be used in some cases to indicate a certain dependency or connection relationship. Those skilled in the art can understand the specific meaning of these terms in this application based on the specific circumstances.

[0021] Furthermore, the terms "installation," "setup," "equipped with," "connection," "linked," and "socketing" should be interpreted broadly. For example, "connection" can be a fixed connection, a detachable connection, or an integral structure; it can be a mechanical connection or an electrical connection; it can be a direct connection or an indirect connection through an intermediate medium, or an internal connection between two devices, components, or parts. Those skilled in the art can understand the specific meaning of the above terms in this application according to the specific circumstances.

[0022] This application describes some exemplary embodiments for illustrative purposes. It should be understood that this application may be implemented in other ways not specifically shown in the accompanying drawings.

[0023] like Figure 1 As shown, this application provides a method for detecting program version release, which can be applied to a program version release device. The method may include steps S101-S104: S101. The detection program version release device receives the new version of the detection program to be released and records the version information of the new version of the detection program.

[0024] The version information includes version identifier, dependencies, scope of application, and change descriptions.

[0025] It should be noted that the new version of the inspection program refers to a composite execution unit that integrates inspection rules, algorithm models, parameter thresholds, context dependencies, and output protocols in the visual inspection scenario of the semiconductor and panel industry. It is an iterative version obtained by optimizing the functions, fixing defects, enhancing capabilities, or adapting to new scenarios of the original inspection program.

[0026] It should be noted that the version identifier in the version information refers to the number or name used to distinguish different versions of the detection program. It clarifies the version identity, upgrade relationship, and iteration order, avoiding version confusion. For example, it can include the version number and the parent version number. Dependencies refer to the version information of the algorithm model, rule base, metadata interpreter, and output protocol that the new version of the detection program depends on for normal operation. This is used to verify environment compatibility and avoid operational anomalies due to dependency mismatches. Scope of application refers to the production lines, machines, product models, process sections, or customer project scope where the new version of the detection program can be deployed. This limits the release boundaries and prevents the version from going live in incompatible scenarios. Change notes refer to the new features, defect fixes, parameter adjustments, and logic modifications in the new version of the detection program. This clarifies the changes and provides a basis for regression verification and risk assessment.

[0027] S102. The detection program version release device performs regression verification on the new version detection program based on the version information in the verification environment, and generates a risk score based on the regression verification results.

[0028] The regression validation includes historical sample playback, typical difficult case playback, target customer data playback, and baseline version comparison.

[0029] It should be noted that historical sample playback refers to loading and running previously labeled normal images and defect sample data to verify the compatibility and consistency of the new version of the detection program with historical scenarios, ensuring that version iteration does not reduce the original detection capabilities. Typical difficult case playback refers to replaying tests on difficult samples such as those prone to missed detection, false alarms, and complex edge defects to verify the new version's handling effect on high-difficulty defects, ensuring that the defect detection capability meets the requirements. Target customer data playback refers to replaying and verifying using real-world data from corresponding customers, production lines, and product models to ensure the adaptability and stability of the new version in the target deployment environment. Baseline version comparison refers to comparing the new version with the currently stable baseline version in parallel to quantitatively evaluate changes in indicators such as false alarm rate, missed detection rate, detection cycle time, and stability, objectively reflecting the version iteration effect.

[0030] Specifically, the testing program version release device can perform regression verification in a verification environment consistent with the production environment based on the changes, dependencies, and scope of application in the version information. By reproducing historical testing data, typical defect samples, edge-hard samples, and target customer field data, the new version of the testing program is compared with the baseline version in parallel to verify whether the new version has deteriorated in terms of detection effect, testing cycle time, operational stability, and equipment compatibility, ensuring that version changes do not introduce anomalies.

[0031] Optionally, generating a risk score based on regression validation results includes: generating the risk score by weighting the results of regression validation based on the detection effect, cycle time performance, stability, and equipment compatibility, combined with the scope of change and dependency complexity.

[0032] Specifically, the detection program version release device can, based on regression verification results, statistically analyze the quantitative data of four categories of indicators: detection effect, cycle time performance, operational stability, and equipment compatibility, and assign values ​​to each item according to the quality of the data; then, it determines the change scope weight based on the number of functional modules involved in the version change and the depth of the changes, and determines the dependency complexity weight based on the number of dependent components and the degree of version differences; after multiplying each item's value by its corresponding weight and summing them, a final risk score is obtained through weighted calculation, with a higher score indicating a greater release risk.

[0033] For example, when the false positive rate increases significantly, or when the core detection logic is changed and multiple components are relied upon, the risk score will increase accordingly.

[0034] Understandably, by quantifying and weighting the multi-dimensional results of regression verification, the release risks of the new version detection program can be objectively and comprehensively reflected, making the risks quantifiable and comparable, providing an accurate basis for selecting the gray-scale release range, avoiding the subjectivity and uncertainty brought about by relying on human experience judgment, and improving the security and controllability of version release.

[0035] S103. The detection program version release device determines the gray release range based on the risk score and business constraints, launches the new version of the detection program within the gray release range, and monitors the monitoring indicators after launch in real time.

[0036] Specifically, the testing program version release device can first classify release levels based on risk scores, with higher risk scores resulting in a smaller and more conservative gray-scale release range. Then, considering business constraints such as production lines, machines, product models, process sections, customer projects, and shift requirements, it can screen out suitable target deployment objects. After determining the gray-scale release range, the new version of the testing program is distributed to the corresponding equipment and deployment is completed within that range. After the new version is deployed and launched within the gray-scale release range, operational data is continuously collected to monitor the actual operating status of the testing program.

[0037] Understandably, determining the scope of gray-scale release through a dual matching of risk scoring and business constraints enables small-scale pilot testing of high-risk versions and moderate expansion of low-risk versions. This ensures the efficiency of new version iterations while limiting potential anomalies to a localized area, avoiding large-scale production fluctuations caused by direct full deployment, and improving the safety and controllability of the release process in multi-production line and multi-machine environments.

[0038] Optionally, the grayscale release range can be divided according to production line, machine, product model, process section, batch, shift, or customer project. The specific range can be determined according to actual usage needs, and this application embodiment does not limit this.

[0039] Optionally, the real-time monitoring of the monitoring indicators after the system goes online includes: real-time collection of monitoring indicators of the new version of the detection program, including false alarm rate, false negative rate, detection cycle time, system operation stability, and device compatibility data; and calculation of the change range and anomaly correlation between the monitoring indicators of the new version of the detection program and the monitoring indicators of the baseline version of the detection program.

[0040] Specifically, the detection program version release device can collect the running data of the new version detection program in a grayscale environment in real time at fixed intervals, and statistically analyze the false alarm rate, false negative rate, average detection cycle time per frame, number of abnormal program restarts, number of crashes, and the adaptation status with cameras, image acquisition cards, and industrial control computers generated per unit time, to obtain the real-time values ​​of various monitoring indicators; compare the above indicators with the historical indicators of the baseline version under the same scenario and the same load, calculate the change range of the indicators of the new version relative to the baseline version, and locate the correlation between the indicator anomalies and the machine, product model, process section or deployment scope to form an anomaly correlation degree.

[0041] Understandably, by collecting comprehensive real-time data on core testing performance, operational efficiency, system stability, and equipment compatibility, the operational status of a new version can be promptly assessed. By comparing quantifiable changes with the baseline version, degradation trends and root causes of anomalies can be quickly identified, providing objective and accurate data for expanding releases or triggering rollbacks, thus improving the real-time nature and accuracy of release control. Generating anomaly correlations allows for rapid identification of the relationship between anomalies and machine, product model, process segment, and deployment scope, accurately distinguishing between global issues with the new version, local equipment compatibility issues, and specific product adaptation issues. This avoids unnecessary global rollbacks triggered by single anomalies, ensuring production line safety while maximizing the preservation of the effective release scope.

[0042] S104. If the monitoring indicators do not meet the rollback conditions, the detection program version release device expands the release scope; if the monitoring indicators meet the rollback conditions, the detection program version release device triggers a version rollback.

[0043] The rollback conditions include at least one of the following: the false alarm rate increases by more than a first threshold, the false negative rate increases by more than a second threshold, the average detection latency exceeds a third threshold, the system stability decreases, or the device compatibility is abnormal.

[0044] It should be noted that a false alarm rate exceeding the first threshold refers to a situation where the proportion of false alarms generated by the new version of the detection program exceeds the preset maximum allowable increase compared to the baseline version, indicating a deterioration in detection performance. A false negative rate exceeding the second threshold refers to a situation where the proportion of actual defects not detected by the new version of the detection program exceeds the preset maximum allowable increase compared to the baseline version, indicating that defect detection capability is inadequate. An average detection latency exceeding the third threshold refers to a situation where the average detection time for a single image or product exceeds the production line's cycle time requirements, potentially leading to production line congestion or downtime. Decreased system stability refers to anomalies such as program crashes, unresponsiveness, repeated restarts, and excessive CPU or memory usage, preventing continuous and stable operation. Equipment compatibility anomalies refer to incompatibility issues between the detection program and the camera, image acquisition card, industrial computer, driver, or communication protocol, resulting in the inability to acquire images or output detection results correctly.

[0045] Specifically, if all monitoring indicators are within the normal range and no rollback condition is triggered, the new version of the detection program will be gradually promoted to a wider range of production lines, machines or product models according to the preset strategy; if any monitoring indicator reaches or exceeds the corresponding threshold and meets the rollback condition, the current release process will be stopped immediately, and the detection program within the abnormal range will be restored to the baseline version to prevent the spread of the abnormality.

[0046] For example, such as Figure 2 As shown, the detection program version release device can compare the real-time monitored false alarm rate, false negative rate, average detection latency, system stability, and equipment compatibility indicators with preset rollback conditions. If all monitoring indicators improve comprehensively and no rollback condition is triggered, the release scope is expanded to promote the new version of the detection program to more production lines, machines, or product models. After full deployment and stabilization, it is transferred to stable version management. If the false alarm rate is detected to rise above the preset threshold, the new version release process is frozen, and the abnormal scope is rolled back to the previous version to prevent the spread of false alarms from affecting production. If the detection cycle time is exceeded or the average detection latency exceeds the production line requirements, the scope of application of the new version can be reduced, and it can be deployed only in scenarios with relaxed cycle time requirements, or a lightweight alternative solution can be enabled to ensure that the production line cycle time is not affected. If only local machine abnormalities or equipment compatibility issues occur, a partial rollback operation is performed, restoring only the abnormal machines to the baseline version, while triggering compatibility checks to locate and fix adaptation issues. The remaining normal machines retain the new version deployment, ensuring production line safety while maximizing the preservation of version iteration effects.

[0047] Understandably, by automatically determining the timing of release and rollback through monitoring indicators, the need for manual inspection and experience-based judgment can be eliminated, enabling automated and standardized control of the release of inspection program versions. When indicators are normal, the scope can be expanded in an orderly manner to ensure the efficiency of version iteration. When indicators are abnormal, rollback can be triggered quickly to effectively prevent defective versions from affecting the stable operation of multiple production lines and machines, thereby significantly improving the reliability and security of industrial vision inspection systems.

[0048] Optionally, the rollback granularity that triggers version rollback can be one or more of the following: global rollback, rollback by machine, rollback by customer, rollback by product, or rollback by batch. The specific rollback granularity can be determined according to actual usage requirements, and this application embodiment does not limit it.

[0049] Optionally, after expanding the release scope or triggering a version rollback, the detection program version release device can record a full-process audit log of the version release and generate version governance knowledge based on the full-process audit log. The full-process audit log includes the version creator, approver, release time, gray-scale range, monitoring indicators, abnormal events, rollback operations, and handling conclusions. The version governance knowledge is used to optimize subsequent gray-scale release strategies, rollback strategies, and risk scoring strategies.

[0050] Specifically, after expanding the release scope or triggering a version rollback, the detection program version release device can comprehensively collect and persistently store the information of the version creator, approver, release execution time, the production lines and machines covered by the canary release, various monitoring indicators after going live, details of abnormal events generated during operation, the content of the rollback operation, and the final handling results involved in the entire version release process, forming an immutable full-process audit log. Then, the data in the audit log is statistically analyzed, summarized, and refined to analyze the risk performance corresponding to different change types, the release stability of different canary ranges, and the effectiveness of rollback under different threshold conditions, forming reusable version governance knowledge. This version governance knowledge can then be applied to the risk scoring calculation, canary range selection, and rollback strategy formulation of subsequent versions.

[0051] Understandably, by recording audit logs throughout the entire process, the entire version release process can be traced and verified, clarifying operational responsibilities and the causes of anomalies, which facilitates subsequent problem localization and responsibility determination. By generating and reusing version governance knowledge based on audit logs, risk scoring, canary release, and automatic rollback strategies can be continuously optimized, making subsequent version releases more robust and controllable, gradually forming a closed-loop iterative version governance capability, and improving the long-term stability and security of large-scale deployments across multiple production lines and multiple machines.

[0052] In this embodiment, because it can receive new versions of the detection program and record version identifiers, dependencies, scope of application, and change descriptions, unified version management of the detection program can be achieved, avoiding version confusion, dependency conflicts, and unclear scope of application caused by manual configuration. Because it can perform regression verification based on version information in the verification environment and generate risk scores based on the verification results, the risk of deploying the detection program before release can be quantified, solving the problem of uncontrollable risks caused by traditional basic function verification. Because it can determine the scope of gray-scale release based on risk scores and business constraints and deploy within the gray-scale range, the large-scale failure risk caused by direct full deployment can be avoided, achieving small-scale, step-by-step, and controllable deployment. Because it can monitor post-deployment indicators in real time and trigger version rollback when rollback conditions are met, detection anomalies, performance degradation, and compatibility issues can be detected in a timely manner, preventing the escalation of failures from affecting production lines. Thus, a closed-loop governance of the entire detection program process can be achieved from aspects such as version control, risk quantification, gray-scale release, and anomaly rollback, significantly improving the stability and reliability of multi-production line deployments in semiconductors and panels, meeting the high reliability and stability requirements of industrial vision inspection systems.

[0053] The foregoing mainly describes the solutions provided by the embodiments of this application from a methodological perspective. To achieve the above functions, it includes corresponding hardware structures and / or software modules for executing each function. Those skilled in the art should readily recognize that, in conjunction with the units and algorithm steps of the various examples described in the embodiments disclosed herein, the embodiments of this application can be implemented in hardware or a combination of hardware and computer software. Whether a function is executed in hardware or by computer software driving hardware depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0054] It should be noted that the steps shown in the flowchart in the accompanying drawings can be executed in a computer system such as a set of computer-executable instructions, and although a logical order is shown in the flowchart, in some cases the steps shown or described may be executed in a different order than that shown here.

[0055] The detection program version release method provided in this application can be executed by a detection program version release device or a control module for releasing detection program versions within that device. This application uses the execution of the detection program version release method by a detection program version release device as an example to illustrate the detection program version release device provided in this application.

[0056] It should be noted that the embodiments of this application can divide the detection program version release device into functional modules according to the above method examples. For example, each function can be divided into its own functional modules, or two or more functions can be integrated into one processing module. The integrated modules can be implemented in hardware or as software functional modules. Optionally, the module division in the embodiments of this application is illustrative and is only a logical functional division; other division methods may be used in actual implementation.

[0057] like Figure 3 As shown in the figure, this application embodiment provides a detection program version release device 300. The detection program version release device 300 includes: a receiving and recording module 301 and a verification and release module 302; the receiving and recording module 301 is used to receive a new version of the detection program to be released and record the version information of the new version of the detection program, the version information including version identifier, dependencies, scope of application, and change description; the verification and release module 302 is used to perform regression verification on the new version of the detection program based on the version information in a verification environment, and generate a risk score based on the regression verification result; determine the canary release scope based on the risk score and business constraints, launch the new version of the detection program within the canary release scope, and monitor the monitoring indicators after launch in real time; if the monitoring indicators do not meet the rollback conditions, the release scope is expanded; if the monitoring indicators meet the rollback conditions, a version rollback is triggered.

[0058] Optionally, after expanding the release scope or triggering a version rollback, the receiving and recording module 301 is also used to record the full-process audit log of the version release and generate version governance knowledge based on the full-process audit log; the full-process audit log includes the version creator, approver, release time, gray-scale range, monitoring indicators, abnormal events, rollback operations and handling conclusions, and the version governance knowledge is used to optimize subsequent gray-scale release strategies, rollback strategies and risk scoring strategies.

[0059] Optionally, the regression validation includes historical sample playback, typical difficult case playback, target customer data playback, and baseline version comparison.

[0060] Optionally, generating a risk score based on regression validation results includes: generating the risk score by weighting the results of regression validation based on the detection effect, cycle time performance, stability, and equipment compatibility, combined with the scope of change and dependency complexity.

[0061] Optionally, the real-time monitoring of the monitoring indicators after the system goes online includes: real-time collection of monitoring indicators of the new version of the detection program, including false alarm rate, false negative rate, detection cycle time, system operation stability, and device compatibility data; and calculation of the change range and anomaly correlation between the monitoring indicators of the new version of the detection program and the monitoring indicators of the baseline version of the detection program.

[0062] Optionally, the rollback conditions include at least one of the following: the false alarm rate increases by more than a first threshold, the missed detection rate increases by more than a second threshold, the average detection latency exceeds a third threshold, the system stability decreases, or the device compatibility is abnormal.

[0063] In this embodiment, because it can receive new versions of the detection program and record version identifiers, dependencies, scope of application, and change descriptions, unified version management of the detection program can be achieved, avoiding version confusion, dependency conflicts, and unclear scope of application caused by manual configuration. Because it can perform regression verification based on version information in the verification environment and generate risk scores based on the verification results, the risk of deploying the detection program before release can be quantified, solving the problem of uncontrollable risks caused by traditional basic function verification. Because it can determine the scope of gray-scale release based on risk scores and business constraints and deploy within the gray-scale range, the large-scale failure risk caused by direct full deployment can be avoided, achieving small-scale, step-by-step, and controllable deployment. Because it can monitor post-deployment indicators in real time and trigger version rollback when rollback conditions are met, detection anomalies, performance degradation, and compatibility issues can be detected in a timely manner, preventing the escalation of failures from affecting production lines. Thus, a closed-loop governance of the entire detection program process can be achieved from aspects such as version control, risk quantification, gray-scale release, and anomaly rollback, significantly improving the stability and reliability of multi-production line deployments in semiconductors and panels, meeting the high reliability and stability requirements of industrial vision inspection systems.

[0064] Figure 4 An example is a schematic diagram of the physical structure of an electronic device, such as... Figure 4As shown, the electronic device may include: a processor 410, a communications interface 420, a memory 430, and a communication bus 440, wherein the processor 410, communications interface 420, and memory 430 communicate with each other through the communication bus 440. The processor 410 can call logical instructions in the memory 430 to execute a detection program version release method. This method includes: receiving a new version of the detection program to be released and recording the version information of the new version of the detection program, the version information including version identifier, dependencies, scope of application, and change description; performing regression verification on the new version of the detection program in a verification environment based on the version information, and generating a risk score based on the regression verification results; determining the canary release scope based on the risk score and business constraints, launching the new version of the detection program within the canary release scope, and monitoring the monitoring indicators after launch in real time; if the monitoring indicators do not meet the rollback conditions, expanding the release scope; if the monitoring indicators meet the rollback conditions, triggering a version rollback.

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

[0066] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer can execute the detection program version release method provided by the above methods. The method includes: receiving a new version detection program to be released and recording the version information of the new version detection program, the version information including version identifier, dependencies, scope of application, and change description; performing regression verification on the new version detection program based on the version information in a verification environment, and generating a risk score based on the regression verification result; determining the canary release scope based on the risk score and business constraints, launching the new version detection program within the canary release scope, and monitoring the monitoring indicators after launch in real time; if the monitoring indicators do not meet the rollback conditions, expanding the release scope; if the monitoring indicators meet the rollback conditions, triggering a version rollback.

[0067] In another aspect, the present invention also provides a non-transitory computer-readable storage medium storing a computer program thereon. When executed by a processor, the computer program implements a method for releasing a detection program version provided by the methods described above. This method includes: receiving a new version of the detection program to be released and recording version information of the new version of the detection program, the version information including a version identifier, dependencies, scope of application, and change descriptions; performing regression verification on the new version of the detection program in a verification environment based on the version information, and generating a risk score based on the regression verification results; determining a canary release scope based on the risk score and business constraints, launching the new version of the detection program within the canary release scope, and monitoring monitoring indicators after launch in real time; if the monitoring indicators do not meet the rollback conditions, expanding the release scope; if the monitoring indicators meet the rollback conditions, triggering a version rollback.

[0068] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate. The components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0069] Obviously, those skilled in the art should understand that the various units 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. Optionally, they can be implemented using computer-executable program code, thereby storing them in a storage device for execution by a computing device, or fabricating them separately as individual integrated circuit modules, or fabricating multiple modules or steps into a single integrated circuit module. Thus, this application is not limited to any particular combination of hardware and software.

[0070] The above description is merely a preferred embodiment of this application and is 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 spirit and principles of this application should be included within the protection scope of this application.

Claims

1. A method for detecting program version release, characterized in that, include: Receive the new version detection program to be released and record the version information of the new version detection program, including version identifier, dependencies, scope of application and change description; In the verification environment, regression verification is performed on the new version detection program based on the version information, and a risk score is generated based on the regression verification results; The scope of the canary release is determined based on the risk score and business constraints. Within the scope of the canary release, the new version detection program is launched, and the monitoring indicators after launch are monitored in real time. If the monitoring metrics do not meet the rollback conditions, the release scope will be expanded; if the monitoring metrics meet the rollback conditions, a version rollback will be triggered.

2. The detection program version release method according to claim 1, characterized in that, After expanding the release scope or triggering a version rollback, the method further includes: Record the entire version release audit log and generate version governance knowledge based on the audit log. The full-process audit log includes the version creator, approver, release time, gray-scale range, monitoring indicators, abnormal events, rollback operations, and handling conclusions. The version governance knowledge is used to optimize subsequent gray-scale release strategies, rollback strategies, and risk scoring strategies.

3. The detection program version release method according to claim 1, characterized in that, The regression validation includes historical sample playback, typical difficult case playback, target customer data playback, and baseline version comparison.

4. The detection program version release method according to claim 1 or 3, characterized in that, The process of generating a risk score based on regression validation results includes: calculating the risk score by weighting the results of regression validation based on the detection effect, cycle time performance, stability, and equipment compatibility, combined with the scope of changes and dependency complexity.

5. The detection program version release method according to claim 1, characterized in that, The monitoring metrics after the real-time monitoring is launched include: The monitoring metrics of the new version of the detection program are collected in real time, including false alarm rate, false negative rate, detection cycle time, system operation stability, and device compatibility data. Calculate the magnitude of change and anomaly correlation between the monitoring indicators of the new version detection program and the monitoring indicators of the baseline version detection program.

6. The detection program version release method according to claim 1, characterized in that, The rollback conditions include at least one of the following: the false alarm rate increases beyond a first threshold, the false negative rate increases beyond a second threshold, the average detection latency exceeds a third threshold, system stability decreases, or device compatibility is abnormal.

7. A device for detecting program version release, characterized in that, include: The module for receiving records and the module for verifying and publishing; The receiving and recording module is used to receive the new version detection program to be released and record the version information of the new version detection program. The version information includes version identifier, dependencies, scope of application, and change description. The verification and release module is used to perform regression verification on the new version detection program based on the version information in the verification environment, and generate a risk score based on the regression verification results. The scope of the canary release is determined based on the risk score and business constraints. Within the scope of the canary release, the new version detection program is launched, and the monitoring indicators after launch are monitored in real time. If the monitoring metrics do not meet the rollback conditions, the release scope will be expanded; if the monitoring metrics meet the rollback conditions, a version rollback will be triggered.

8. 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 detection program version release method as described in any one of claims 1 to 6.

9. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by a processor, it implements the detection program version release method as described in any one of claims 1 to 6.

10. A computer program product, comprising a computer program, characterized in that, When the computer program is executed by a processor, it implements the detection program version release method as described in any one of claims 1 to 6.

Images