Defect detection methods and systems

Abstract

This application provides a defect detection method and system, relating to the field of industrial intelligent manufacturing and quality monitoring technology. The method includes acquiring real-time data during the product manufacturing process and storing it in a historical database. The real-time data includes the product's process parameters, defect size, defect coordinates, and defect type. An intelligent model periodically analyzes the data in the historical database and generates a first rule expression, which conforms to a preset syntax for user review. A rule engine performs defect detection based on the real-time data and a second rule expression to output disposal instructions for the product. The second rule expression is obtained by the user based on the first rule expression. According to this solution, the accuracy and efficiency of defect detection can be significantly improved.

Description

Technical Field

[0001] This application relates to the field of industrial intelligent manufacturing and quality monitoring technology, and more specifically, to a defect detection method and system. Background Technology

[0002] Automated optical inspection (AOI) systems are widely used in product quality control. These systems use optical imaging and image processing technology to automatically detect surface defects in products, replacing manual visual inspection. They are primarily used for high-speed surface defect detection in electronics manufacturing. However, currently widely used AOI systems heavily rely on predefined, static judgment rules, such as classifying a defect as defective if its area exceeds a fixed threshold. These rules cannot adjust themselves to dynamic factors such as material batch changes, equipment status drift, and environmental changes, resulting in a high misjudgment rate. This necessitates frequent manual intervention and calibration, leading to high maintenance costs and low efficiency.

[0003] Therefore, improving the accuracy and efficiency of defect detection is an urgent problem to be solved. Summary of the Invention

[0004] This application provides a defect detection method and system that uses an artificial intelligence (AI) model to periodically analyze historical data and dynamically generate rule expressions for defect detection. These rules are then executed by a rule engine to perform defect detection. By combining AI-generated rules with rule engine execution, the method solves the problem of static rule systems being rigid and unable to adapt to production changes. It can quickly respond to production changes, significantly reduce false alarms and false negatives caused by threshold mismatch, and significantly improve the accuracy and efficiency of defect detection.

[0005] Firstly, a defect detection method is provided. This method includes acquiring real-time data from the product manufacturing process and storing it in a historical database. The real-time data includes the product's process parameters, defect dimensions, defect coordinates, and defect types. An intelligent model periodically analyzes the data in the historical database and generates a first rule expression, which conforms to a preset syntax for user review. A rule engine performs defect detection based on the real-time data and a second rule expression to output disposal instructions for the product. The second rule expression is obtained by the user based on the first rule expression.

[0006] In this embodiment, by periodically analyzing production data through an AI intelligent model, subtle changes and trends in the production process can be automatically detected, and updated rule expressions can be dynamically recommended. This ensures that the detection standards are always synchronized with the current optimal production state, overcoming the problem of rigid static rules. It significantly reduces false alarms and false negatives caused by mismatched thresholds, improving the accuracy and reliability of detection. The AI ​​model generates interpretable rules, and its final decision-making is based on clear and concise rule expressions that users can fully understand, trust, and fine-tune. This perfectly integrates data-driven intelligence with the controllability of human experience, greatly improving practicality and acceptability. Furthermore, the way the AI ​​model generates rules is far more efficient than manually analyzing and updating the rule base, enabling rapid response to production changes and significantly improving the automation level and response speed of the quality inspection process.

[0007] In conjunction with the first aspect, in some implementations of the first aspect, the method further includes performing operations on the product according to disposal instructions, including release, hold, alarm, and maintenance. The results of the execution are then fed back to a historical database.

[0008] In this embodiment, the production line receives a disposal instruction, translates the abstract instruction code output by the rule engine into a precise control command for the underlying equipment, executes the corresponding physical operation, and feeds back the execution result to the historical database. This result serves as new training data. The execution result of each disposal instruction is fed back to the system as a new data point, ensuring the traceability of decision effectiveness and providing crucial supervisory data for the continuous self-optimization of the AI ​​model, thus forming a closed-loop feedback.

[0009] In conjunction with the first aspect, in some implementations of the first aspect, data from a historical database is used to periodically train the intelligent model to generate a first criterion logic. This first criterion logic indicates the relationship between the product's data characteristics and the results of execution on the product. Based on the first criterion logic, a first rule generation instruction is output through a predefined function call interface. A first rule expression is generated based on the predefined rule structure and the first rule generation instruction.

[0010] In this embodiment, the AI ​​intelligent model periodically calls historical data for identification and analysis, and uses a function calling mechanism to generate dynamic rule expressions for the current production state. The AI ​​model calls rule structure templates through structured instructions, rather than directly generating code strings, thereby achieving output standardization and ensuring that the output rules conform to the syntax and security specifications of the rule engine. The generated rule logic is clear, easy for users to understand and fine-tune, and offers a user-friendly human-computer interaction, reducing the risk and complexity of errors from directly parsing the output content.

[0011] In conjunction with the first aspect, in some implementations of the first aspect, the first rule expression indicates the location, distribution, characteristics, and relationship between process parameters and disposal instructions of product defects.

[0012] In this embodiment, the defect detection rules are no longer simple threshold judgments, but intelligent criteria that are generated by mining complex production data based on AI intelligent models. These criteria integrate multi-dimensional features, consider the standards of defects in different locations, consider the distribution of defects rather than just looking at a single defect, and associate defect features with production parameters for judgment. This enables precise handling of complex scenarios and improves the accuracy and reliability of detection.

[0013] In conjunction with the first aspect, in some implementations of the first aspect, the method also includes displaying the first rule expression to the user through a graphical interface for the user to process, including confirmation, modification, and rejection.

[0014] In this embodiment, a graphical interface is provided to display the generated rule logic in a highly readable form. The final decision-making basis is a clear and concise rule expression, which users can fully understand, trust, and confirm, fine-tune, or reject on the interface, ensuring the integration of human experience and control over the final decision-making power.

[0015] In conjunction with the first aspect, in some implementations of the first aspect, the rule engine is the Aviator engine, and the first rule expression and the second rule expression conform to the syntax of the Aviator engine.

[0016] In this embodiment, the high-performance rule engine Aviator is used to execute rules. Its compilation and execution efficiency is extremely high, improving efficiency and response speed, and meeting the real-time detection requirements of high-speed production lines. Leveraging the powerful expressive capabilities of the Aviator rule engine, the complex, multi-dimensional defect feature association logic mined by AI intelligent models can be transformed into executable and readable rules. The detection logic is closer to human expert thinking, resulting in more accurate and reasonable rejection decisions.

[0017] In conjunction with the first aspect, some implementations of the first aspect also include encapsulating business logic through custom functions to simplify the second rule expression. The Aviator engine acquires real-time data and makes a judgment based on the simplified second rule expression to output a processing instruction.

[0018] In this embodiment, the Aviator engine supports custom functions, which can support complex business logic. Complex custom functions can be easily called in the defect detection rules. The complex calculation and recognition processes inside the functions are encapsulated and do not need to be reflected in the defect detection rules, thereby significantly reducing the complexity of rule writing and maintenance, and ensuring the accuracy and consistency of professional judgment.

[0019] In conjunction with the first aspect, in some implementations of the first aspect, the data in the historical database includes corresponding weights and confidence levels. The method also includes: training the intelligent model based on the results of the feedback execution, specifically including: adjusting the learning weights of the intelligent model based on the confidence levels corresponding to the data in the historical database.

[0020] In this embodiment, all execution results are synchronously written back to the historical database. This labeled data based on weights and confidence levels becomes a valuable data source for the next round of training and rule optimization of the AI ​​intelligent model, thereby enabling the continuous self-evolution of the entire system.

[0021] In conjunction with the first aspect, in some implementations of the first aspect, the intelligent model includes a knowledge graph that constructs a semantic network of product defects, process parameters, and production equipment; the graph generates a first rule expression based on data in a historical database and the status of the equipment, and the first rule expression is also used to indicate adjustments to the process parameters.

[0022] In this embodiment, entities such as defects, processes, and equipment, along with their relationships, are constructed into a semantic network to achieve deeper logical reasoning. Individual defects are considered within the context of the entire production system, generating more holistic decisions. This not only identifies defects but also provides diagnostic and remedial suggestions. The reasoning path is clearly visible, and users can directly add new entities and relationships to the graph, making it easy to incorporate expert experience.

[0023] In conjunction with the first aspect, in some implementations of the first aspect, the intelligent model is a large language model, and the method also includes the large language model generating a first rule expression based on the user's language instructions and data in the historical database.

[0024] In this embodiment, the large language model has powerful natural language understanding and code generation capabilities. Users can directly describe problems or intentions in language, freeing them from the limitations of predefined rule templates. It can generate extremely complex and nested conditional logic, which is closer to the complex decision-making thinking of human experts, greatly improving the depth and flexibility of human-computer collaboration.

[0025] Secondly, a defect detection system is provided, which is a module or unit for performing the methods described in the first aspect and its various implementations.

[0026] Thirdly, an apparatus is provided, comprising a processor and a memory, wherein the processor and the memory are connected together, wherein the memory is used to store program code, and the processor is used to invoke the program code to execute the methods described in the first aspect and its various implementations.

[0027] Fourthly, a computer-readable storage medium is provided storing a computer program that is executed by a processor to implement the method in any possible implementation of the method design of the first aspect.

[0028] Fifthly, a computer program product is provided, including instructions that, when executed by a processor, cause a computer to perform any possible implementation of the method design of the first aspect described above.

[0029] Other beneficial effects can be found in the description of the first aspect, and will not be repeated here. Attached Figure Description

[0030] Figure 1 This is a schematic diagram of the defect detection method provided in the embodiments of this application; Figure 2 This is a data acquisition diagram provided in an embodiment of this application; Figure 3 This is a schematic diagram of the intelligent engine rule generation provided in the embodiments of this application; Figure 4 This is a schematic diagram of rule management provided in an embodiment of this application; Figure 5 This is a schematic diagram of intelligent model optimization provided in an embodiment of this application; Figure 6 This is a schematic diagram of the defect detection system architecture provided in the embodiments of this application; Figure 7 This is a schematic diagram of the defect detection process provided in the embodiments of this application; Figure 8 This application provides a schematic diagram of the defect detection system structure. Detailed Implementation

[0031] To make the objectives, technical solutions, and advantages of this application clearer, the embodiments of this application will be described in further detail below with reference to the accompanying drawings.

[0032] The "range" disclosed in this application is defined by a lower limit and an upper limit. A given range is defined by selecting a lower limit and an upper limit, which define the boundaries of a specific range. Ranges defined in this way include endpoint values ​​and can be arbitrarily combined; that is, any lower limit can be combined with any upper limit to form a range. For example, if ranges of 60-120 and 80-110 are listed for a specific parameter, it is also expected that ranges of 60-110 and 80-120 are also included. Furthermore, if the minimum range values ​​are listed as 1 and 2, and the maximum range values ​​are listed as 3, 4, and 5, then the following ranges are all expected: 1-3, 1-4, 1-5, 2-3, 2-4, and 2-5. In this application, unless otherwise stated, the numerical range "ab" represents a shortened representation of any combination of real numbers between a and b, where a and b are real numbers. For example, the numerical range "0-5" means that all real numbers between "0-5" have been listed herein; "0-5" is simply a shortened representation of these numerical combinations. Furthermore, when a parameter is described as an integer greater than or equal to 2, it is equivalent to disclosing that the parameter is, for example, an integer such as 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, etc.

[0033] Unless otherwise specified, all embodiments and optional embodiments of this application can be combined with each other to form new technical solutions.

[0034] Unless otherwise specified, all technical features and optional technical features of this application may be combined to form new technical solutions.

[0035] The terminology used in the following embodiments is for the purpose of describing particular embodiments only and is not intended to be limiting of this application. As used in the specification and appended claims of this application, the singular expressions “a,” “an,” “the,” “the,” “the,” and “this” are intended to also include expressions such as “one or more,” unless the context clearly indicates otherwise. It should also be understood that in the following embodiments of this application, “at least one” and “one or more” refer to one, two, or more than two. The term “and / or” is used to describe the relationship between related objects, indicating that three relationships may exist; for example, A and / or B can indicate: A alone, A and B simultaneously, or B alone, where A and B can be singular or plural. The character “ / ” generally indicates that the preceding and following related objects are in an “or” relationship.

[0036] References to "one embodiment," "some embodiments," "one example," or "some examples" used in this specification mean that one or more embodiments of this application include a specific feature, structure, or characteristic described in connection with that embodiment. Therefore, the phrases "in one embodiment," "in some embodiments," "in other embodiments," "in still other embodiments," etc., appearing in different parts of this specification do not necessarily refer to the same embodiment, but rather mean "one or more, but not all, embodiments," unless otherwise specifically emphasized. The terms "comprising," "including," "having," and variations thereof mean "including but not limited to," unless otherwise specifically emphasized.

[0037] In the description of the embodiments of this application, technical terms such as "first" and "second" are used only to distinguish different descriptive objects and should not be construed as indicating or implying relative importance or implicitly specifying the number, specific order, or primary and secondary relationship of the indicated technical features. In the description of the embodiments of this application, "multiple" means two or more, unless otherwise explicitly defined.

[0038] To better understand the solutions involved in this application, the terminology used in this application will be introduced first.

[0039] 1. Automated optical inspection (AOI) AOI (Automated Optical Inspection) equipment operates by capturing images of circuit boards using high-definition cameras and comparing them with predefined correct parameters using image processing and analysis software to automatically detect any non-conformities. This equipment is widely used in various electronics manufacturing industries, such as inspecting the soldering quality and component placement on printed circuit boards (PCBs) to ensure there are no problems like missing solder joints, incorrect polarity, or misaligned components, or to detect defects on glass surfaces. AOI equipment significantly improves inspection efficiency and accuracy, reducing the burden of manual inspection.

[0040] 2. Manufacturing Execution System (MES) Manufacturing Execution System (MES) is a computerized system used to track, monitor, and control the production process in a manufacturing workshop, from raw materials to finished products. Its core function is to connect planning and execution, creating a data loop, translating production plans formulated by senior management into concrete, actionable operations on the workshop floor. Simultaneously, it collects real-time production data from the workshop and feeds it back to management, achieving transparent and controllable management of the entire production process. MES can automatically or manually collect various data related to workshop production, equipment, and quality inspection, such as output, pass rate, equipment uptime, number of failures, and material consumption, replacing traditional manual recording, reducing human error, and ensuring data accuracy, timeliness, and traceability. Real-time process parameter data can be obtained from MES.

[0041] 3. Function calling In computer science, a function call is the process by which a piece of code in a program calls and executes another predefined function.

[0042] 4. Rule Engine A rules engine is a software system that extracts business decision-making logic from application code and automatically executes decisions based on predefined rules.

[0043] Embodiments of this application will now be described in more detail with reference to the accompanying drawings. For clarity, the various parts in the drawings are not drawn to scale. Furthermore, some well-known parts may not be shown in the drawings.

[0044] In modern manufacturing, automated optical inspection systems are widely used in product quality control. These systems automatically detect surface defects in products using optical imaging and image processing technologies, improving inspection efficiency and accuracy. However, currently widely used automated optical inspection systems heavily rely on predefined, static judgment rules, such as "a defect area greater than a fixed threshold is considered defective." These rules cannot self-adjust based on dynamic factors such as material batch changes, equipment status drift, and environmental changes, resulting in a high false alarm rate (false positives and false negatives). This necessitates frequent manual intervention and calibration, leading to high maintenance costs and low efficiency.

[0045] To address the aforementioned issues, this application provides a defect detection method and system. It utilizes an artificial intelligence model to periodically analyze historical data and dynamically generate rule expressions for defect detection. These rules are then executed through a rule engine to perform defect detection. By combining AI-driven dynamic generation with rule engine execution, the method solves the problem of static rule systems being rigid and unable to adapt to production changes. It can quickly respond to production changes, significantly reducing false alarms and false negatives caused by mismatched thresholds, and significantly improving the accuracy and efficiency of defect detection.

[0046] like Figure 1As shown, the defect detection method 100 provided in this application embodiment includes at least the following steps: S110 acquires real-time data during the product manufacturing process and stores it in a historical database.

[0047] The real-time data includes the product's process parameters, defect size, defect coordinates, and defect type.

[0048] like Figure 2 As shown, the defect detection system is responsible for collecting data in real time from various data sources in the production environment. These data sources include the Manufacturing Execution System (MAS), the Automated Optical Inspection System (AIO), and sensors. The data acquisition module in the defect detection system obtains work orders and batch information from the MAS, defect data from high-precision industrial cameras and image processing units in the AIO, and process parameters from sensors on the production line.

[0049] The defect detection system is also configured to process the collected raw data. This includes cleaning, normalizing, and extracting features from the raw data, then fusing and associating these features before storing them. For example, processing defect image data identifies the defect type and calculates key feature values ​​such as defect area and coordinates, storing these values ​​in a structured historical database. The processed defect feature data includes defect type, distance from the defect to the edge, defect coordinates, and defect area size.

[0050] Manufacturing execution systems, vision sensors, and production line control equipment continuously collect production data and product defect data, which are stored in a historical database. The defect data includes defect size, coordinates, and type characteristics.

[0051] This step can be performed by the rule generation module in the defect detection system.

[0052] S120 periodically analyzes data in the historical database using an intelligent model and generates the first rule expression.

[0053] The first rule expression conforms to the preset syntax for user review. The first rule expression is the logical criterion that conforms to the rule engine's syntax.

[0054] This step can be performed by the rule generation module in the defect detection system.

[0055] In one embodiment, the first rule expression indicates the relationship between the location, distribution, characteristics, and process parameters of product defects and handling instructions.

[0056] The rule generation module of the defect detection system periodically calls historical data, performs pattern recognition and analysis through machine learning intelligent models, and uses a function call mechanism to generate dynamic rule expression recommendations for the current production state. In this embodiment, function call refers to the core mechanism by which the AI ​​model outputs structured instructions to call a predefined rule template function and pass in parameters.

[0057] The rule generation module, acting as the "brain" of the defect detection system, is responsible for learning from historical data and generating optimized detection strategies.

[0058] In one embodiment, the intelligent model is periodically trained using data from a historical database to generate a first criterion logic, which indicates the relationship between the product's data characteristics and the results of execution on the product. Based on the first criterion logic, a first rule generation instruction is output through a predefined function call interface. A first rule expression is generated based on the predefined rule structure and the first rule generation instruction.

[0059] For example, such as Figure 3 As shown, the rule generation module transforms historical data into executable business rules through a three-stage process.

[0060] In the first stage, intelligent model training and rule discovery are carried out through multi-dimensional perception and recognition of defect patterns.

[0061] The defect detection system employs highly interpretable machine learning algorithms, such as gradient boosting decision tree (GBDT) and Bayesian networks, to train on historical production and defect data in a database. The intelligent model is input with feature data processed by the data acquisition module, including defect characteristics such as defect size, coordinates, and type, as well as relevant process parameters. Its supervisory signals are historical manual quality inspection results or verified pass / fail labels. By analyzing feature importance, decision paths, and the strong correlation between different feature combinations and results, the intelligent model automatically discovers potential and effective judgment logic.

[0062] For example, the intelligent model might discover and learn a key rule: "When the defect type is a scratch and its coordinates X > 100 and Y < 200, the rejection threshold for the 'length' feature should be adjusted from the general 20 pixels to a more precise 15 pixels." This generates the first criterion logic.

[0063] In the second stage, semantic mapping of business logic is performed through function calls and instruction generation.

[0064] At this stage, instead of directly outputting a simple "qualified / unqualified" judgment, the system outputs the first rule generation instruction through a predefined function call interface based on the first criterion logic. The statistical patterns and criterion logic discovered in the first stage are output as structured rule generation instructions through the predefined function call interface. This mechanism precisely maps the model's numerical discoveries into operation commands for the rule template.

[0065] For example, regarding the first criterion logic, "When the defect type = scratch and its coordinate X > 100 and coordinate Y < 200, the rejection threshold for the 'length' feature should be adjusted from the general 20 pixels to a more precise 15 pixels," the rule generation module calls a function such as `generate_threshold_rule("scratch", "length", 15, "region A")`. This outputs the first rule generation instruction. This step achieves a semantic transformation from data insight to operational intent.

[0066] In the third stage, the automatic synthesis of rule codes is achieved through template filling and expression generation.

[0067] The pre-built rule template library within the defect detection system receives the aforementioned rule generation instructions. The template library predefines rule structures that conform to business logic (e.g., "IF-[Defect Type]-[Feature]-[Operator]-[Threshold]-AND-[Regional Condition]-THEN-[Adjustment Action]"). Based on the parameters in the rule generation instructions, the template library automatically completes the population and rendering, ultimately generating a rule expression string that conforms to the rule engine's syntax, i.e., the first rule expression.

[0068] For example, the above rule generation instructions are transformed into a first rule expression, such as: if(type="SCRATCH"&&length>15&&coordinateX>100&&coordinateY<200){return"REPAIR";}, which is a high-quality, executable code, thereby completing the transformation from intelligent discovery to a qualitative closed loop in the industry.

[0069] Existing inspection systems typically use static rule expressions that cannot be dynamically adjusted based on real-time production conditions. They lack intelligent adaptation capabilities and cannot automatically adapt inspection rules to different product types, process parameters, or defect characteristics. They also lack intelligent decision-making capabilities based on AI algorithms, making it difficult to achieve accurate defect detection.

[0070] According to this application, by periodically analyzing production data through AI algorithms, subtle changes and trends in the production process can be automatically detected, and updated rule expressions can be dynamically recommended. This ensures that the detection standards are always synchronized with the current optimal production state, overcoming the problem of rigid static rules, significantly reducing the false alarm and false negative rates caused by threshold mismatch, and improving the accuracy and reliability of the detection system.

[0071] S140 uses a rule engine to perform defect detection based on real-time data and a second rule expression to output instructions for product handling.

[0072] The second rule expression is obtained by the user based on the first rule expression.

[0073] It should be understood that the second rule expression can be exactly the same as the first rule expression, meaning the user directly obtains the second rule expression based on the first rule expression without modification. Alternatively, the second rule expression can be obtained by the user after modifying the first rule expression.

[0074] This step can be performed by the rule engine module in the defect detection system.

[0075] The rules engine loads the certified second rule expression and receives real-time product data from the production line. The rules engine executes the rule logic and outputs the corresponding disposal instructions for the current product, including pass, hold, alarm, or repair.

[0076] The rules engine module is the "heart" of the defect detection system, responsible for efficiently executing certified business logic.

[0077] The rules engine module includes preset rules engines, such as Aviator, Groovy, and JRuby.

[0078] Preferably, the rule engine is the Aviator engine, and both the first and second rule expressions conform to the syntax of the Aviator engine. The Aviator rule engine is selected as the choice. Aviator is a high-performance, lightweight Java expression evaluation engine. Due to its advantages such as high compilation and execution performance, concise syntax, ease of embedding and integration, and support for user-defined functions, it is very suitable for the high real-time requirements of industrial environments. As the core dynamic rule engine, the Aviator engine is responsible for loading, compiling, and executing the rule expressions generated by AI.

[0079] The Aviator engine obtains the certified rule expression string from the rule management module. The Aviator engine then compiles the certified rules into bytecode in real time to ensure maximum execution efficiency.

[0080] In one embodiment, business logic is encapsulated through a custom function to simplify the second rule expression. The Aviator engine acquires real-time data and makes a judgment based on the simplified second rule expression to output a processing instruction.

[0081] The Aviator engine supports custom function extensions, allowing you to register a large number of custom functions to support complex business logic.

[0082] For example, as shown in Table 1, different business logic can be implemented through different custom functions.

[0083] Table 1. Examples of User-Defined Functions

[0084] The custom function receives three parameters upon execution: a set of defect coordinates, a judgment threshold, and a reference diameter. It calculates the defect distribution characteristics through an internal defect clustering analysis subroutine and outputs the analysis results in two ways: firstly, it writes detailed clustering characteristic information into the rule engine execution environment, including the set of clustering region coordinates and a list of corresponding defect identifiers; secondly, it returns a Boolean clustering judgment result for the rule engine to directly perform logical judgments. This approach greatly simplifies the rule expressions.

[0085] For example, a rule for judging cluster defects in screen modules can be directly written in the following form: if (hasClusterDefects(defectList, 3, 100)) {return "REJECT";}. Here, defectList is a list of coordinates of defects detected in real time; "3" represents the threshold for determining the number of cluster defects; and "100" represents the cluster radius calculated with a base diameter of 100 mm. This expression intuitively describes the business logic of "rejecting a module when three or more cluster defects appear within a 100 mm base diameter range".

[0086] The complex coordinate calculations, distance assessments, and cluster identification processes within the function are all encapsulated, eliminating the need to include them in the rules. This significantly reduces the complexity of rule writing and maintenance while ensuring the accuracy and consistency of professional judgments. This also allows for convenient calling of such complex functions within the rules.

[0087] For each incoming product, the rules engine module receives all its real-time feature data, injects it as a context (Env) into the Aviator engine to execute the loaded rules, and finally outputs disposal instructions (such as "PASS", "HOLD", "ALARM").

[0088] Existing detection systems suffer from complex rule expressions, requiring hard-coding to implement intricate detection logic, which is difficult to maintain and lacks scalability. Traditional binary or simple logic rules are ill-suited for handling complex defect scenarios. For example, they cannot accurately express complex logic such as "defects located in the core functional area of ​​a product, even if small in size, should be strictly controlled, while similar defects located in peripheral areas can be subject to more lenient standards" or "multiple clustered small defects pose a higher risk than a single isolated large defect," which require comprehensive judgment based on multi-dimensional features such as defect size, location, shape, and distribution density.

[0089] According to the solution in this application, leveraging the powerful expressive capabilities of a rule engine (such as Aviator), the complex, multi-dimensional defect feature association logic mined by the AI ​​intelligent model, such as location + size + type + distribution density, can be transformed into executable and readable rules. This enables the defect detection system to accurately handle complex scenarios such as "small defects located in a specific area have a higher risk" or "defect clusters have a higher risk than isolated defects," making the detection logic closer to human expert thinking and resulting in more accurate and reasonable rejection decisions. Simultaneously, the use of a high-performance expression engine to execute rules results in extremely high compilation and execution efficiency, meeting the real-time detection requirements of high-speed production lines. The method of generating rules by the intelligent model is also far more efficient than manual analysis and updating of the rule base, enabling rapid response to production changes and significantly improving the automation level and response speed of the quality inspection process.

[0090] Optionally, the defect detection method provided in this application embodiment further includes: S130, displaying a first rule expression to the user through a graphical interface for the user to process.

[0091] The processing includes confirmation, modification, and rejection.

[0092] This step can be performed by the rule management module in the defect detection system.

[0093] In one embodiment, the rule management module receives the rule expressions output by the rule generation module and provides them to domain experts for review, adjustment, and certification via a human-computer interaction interface. Only certified rule expressions can be deployed to the rule engine.

[0094] like Figure 4 As shown, the first rule expression is reviewed by the user and can be confirmed or rejected. The confirmed rule expression is deployed to the rule engine, where parameters can be adjusted. The rule engine then executes the deployed rules to perform defect detection.

[0095] The rule management module serves as a bridge between the intelligent system and human experts, ensuring the controllability and reliability of rules. It performs version control on all rules output by the rule generation module and rules modified manually, supporting rapid rule rollback and traceability.

[0096] In one embodiment, the rule management module provides a graphical interface through a UI to display the rule logic, confidence level, and data basis supporting the rule generated by the rule generation module in a highly readable form, such as a decision tree diagram or highlighted code.

[0097] Quality control engineers or process experts can confirm, modify, or reject rules on the interface.

[0098] For example, an engineer can fine-tune the threshold recommended by the AI ​​intelligent model from 15 pixels to 14 pixels, and then click "Approve Deployment". This step ensures the incorporation of human experience and control over the final decision-making.

[0099] In existing solutions, although end-to-end deep learning models have shown potential in defect identification, their decision-making process is opaque and is considered a "black box." Production line quality engineers find it difficult to understand and trust the results, and are unable to quickly locate the root cause of the problem and integrate it into the existing rule-based quality control system, resulting in a dilemma where the model is good but difficult to implement.

[0100] According to this application, instead of directly replacing the original system with a "black box" AI model, AI is used as a "senior analyst" to generate interpretable rules. The final decision-making basis is a clear and concise rule expression that quality control engineers can fully understand, trust, and fine-tune. This perfectly integrates data-driven intelligence with the controllability of human experience, greatly improving the system's usability and acceptability.

[0101] Optionally, the defect detection method provided in this application embodiment further includes: S150, performing operations on the product according to the disposal instructions, and feeding back the execution results to the historical database.

[0102] The handling instructions include release, hold, alarm, and maintenance.

[0103] This step can be performed by the production line control module in the defect detection system.

[0104] The production line control module receives processing instructions, executes the corresponding physical operations, and feeds back the results to the historical database. These results serve as new training data for subsequent optimization of the AI ​​intelligent model, forming a closed-loop feedback loop.

[0105] The core function of the production line control module is to achieve closed-loop control from digital decision-making to physical execution. As a "bridge" between the information world and the physical production line, it translates the abstract instruction code output by the rule engine into precise control commands for underlying devices such as the MES system and programmable logic controllers (PLCs). The production line control module drives various industrial actuators through predefined interface protocols.

[0106] For example, when the rules engine outputs an "ALARM" action command, the production line control module immediately activates the audible and visual alarms installed on the production line, emitting flashes and buzzers at a specific frequency to alert the on-site operators of an abnormal situation. Simultaneously, this alarm event (including time, workstation, and triggering rule ID) is recorded as an "alarm record" and fed back to the system database for statistical analysis of the frequency of specific defects.

[0107] For example, when the rules engine outputs a "HOLD" disposal command, the production line control module sends an emergency stop signal to the PLC controller of the production line, causing the conveyor belt to stop running immediately and ensuring that the suspicious product remains at the current inspection station. At the same time, the "interception event" and the product ID are pushed to the MES system and operator terminal in real time, triggering the manual re-inspection process.

[0108] For example, when the rules engine outputs a "REPAIR" disposal instruction, the production line control module will activate an automatic sorting mechanism, such as a robotic arm or push rod, to transfer the defective product from the main line to the repair track. At the same time, it will trigger the synchronization of detailed information such as the defect type and coordinate image to the workbench of the repair station, and generate a "repair work order" to be fed back to the database, recording that this product has entered the repair-pending state.

[0109] In one embodiment, the data in the historical database includes corresponding weights and confidence levels. The intelligent model is trained based on the results of the feedback execution, specifically by adjusting the learning weights of the intelligent model according to the confidence levels corresponding to the data in the historical database.

[0110] In this way, the execution result of each disposal instruction is fed back to the system as a new data point, ensuring the traceability of decision-making effectiveness and providing crucial supervisory data for the continuous self-optimization of the AI ​​intelligent model.

[0111] All defect detection results, including the final manual review results, are synchronously written back to the MES system and the historical database. This weighted and confidence-based labeled data becomes a valuable data source for the next round of training and rule optimization of the AI ​​intelligent model, thereby enabling the continuous self-evolution and closed-loop optimization of the entire system.

[0112] like Figure 5As shown, the core idea of ​​the intelligent optimization feedback mechanism is to dynamically adjust the learning weights based on confidence levels. The optimization goal of the intelligent model is to avoid overturning correct perceptions, strengthen uncertain perceptions, and focus on correcting blind spots in the model. The model's learning weight allocation is adjusted based on the input of feedback data, which includes cases with high confidence but errors, high confidence and correctness, and low confidence. For example, the weights of high-confidence and correct cases are maintained or reduced, higher weights are set for low-confidence and correct cases, and the highest weights are set for high-confidence but incorrect cases. This maximizes the iterative efficiency of the intelligent model and improves the stability of the system.

[0113] The existing defect detection system, manufacturing execution system, and production equipment data are not effectively integrated and coordinated. Visual defect features are isolated from real-time process parameters (such as temperature, pressure, speed, etc.), making it impossible to perform correlation analysis. This prevents the diagnosis of defect causes at their root and the preventive optimization of process parameters, thus limiting the depth and foresight of quality control.

[0114] According to the solution proposed in this application, the rule expression can seamlessly integrate real-time process parameters and visual defect features through a function call mechanism, breaking down data silos between systems. This not only achieves more accurate defect judgment but also optimizes production process parameters through result feedback, forming a complete quality closed loop from "detection-judgment-feedback-optimization." This enables a leap from simple "quality inspection" to "quality prevention" and "quality root cause analysis," thereby improving the overall production quality level.

[0115] In another embodiment, the intelligent model includes a knowledge graph that constructs a semantic network of product defects, process parameters, and production equipment; the graph generates a first rule expression based on data from a historical database and the status of the equipment, and the first rule expression is also used to indicate adjustments to the process parameters.

[0116] The rule generation module constructs a semantic network from entities such as defects, processes, and equipment and their relationships, enabling deeper logical reasoning.

[0117] For example, a knowledge graph is constructed, with nodes including "Equipment A," "Process Parameter B," and "Defect Type C," and edge relationships including "prone to," "controlled by," and "related to." When defect C is detected, the AI ​​intelligent model traverses and reasons within the constructed knowledge graph, discovering that it may be caused by an abnormal state of Equipment A through an offset in process parameter B. This generates a composite rule: "IF Defect C occurs AND Equipment A's vibration value exceeds limits THEN Recommend checking and adjusting process parameter B, while temporarily increasing the threshold for this type of defect." This rule not only identifies the defect but also provides diagnostic and remedial suggestions.

[0118] According to this application, individual defects are considered within the context of the entire production system, generating more holistic decisions. The reasoning path is clearly visible, much like an expert performing logical chain analysis. Experts can directly add new entities and relationships to the graph, intuitively empowering the AI ​​intelligent model and easily incorporating expert experience.

[0119] In another embodiment, the intelligent model is a large language model, and the method further includes the large language model generating a first rule expression based on the user's language instructions and data in a historical database.

[0120] Large language models possess powerful natural language understanding and code generation capabilities, and can be used to replace or enhance existing machine learning models. As the core, large language models enable the collaborative construction of rules for natural language interaction. Upgrading the rule generation process from "function calls" to "semantic understanding" can greatly enhance the depth and flexibility of human-computer collaboration.

[0121] The interface of the rules management module has changed from a traditional graphical form to a natural language dialogue interface. Engineers can directly describe problems or intentions using language.

[0122] For example, an engineer can ask the system, "Analyze the pattern of new spot defects appearing in the edge area over the past week." The large language model will analyze the data, report insights in natural language, and simultaneously generate corresponding rule code drafts. The engineer can then instruct the system, "For this type of spot, if its area is larger than the standard but its color is lighter, can the standard be relaxed? Please generate a test rule." The large language model will understand the semantics of concepts such as "area," "color," and "relax," and generate complex rule expressions that integrate multiple features. The defect detection system will validate the rules generated by the large language model on sandbox or historical data, display the simulation results, and deploy them after engineer confirmation.

[0123] Large language models can simultaneously read unstructured data such as technical documents and quality standard files, enabling the generated rules to be based not only on data but also on textual knowledge and to provide reasoning support. Through continuous dialogue with experts, large language models can learn their preferences and decision-making styles, making the generated rule recommendations increasingly tailored to the specific "tastes" of particular companies or experts, thus achieving personalized optimization.

[0124] According to the solution proposed in this application, the use of a large language model eliminates the limitations of predefined rule templates and can generate extremely complex, nested conditional logic, which is closer to the complex decision-making thinking of human experts.

[0125] Figure 6 and Figure 7 This is a schematic diagram of the architecture and process of defect detection.

[0126] like Figure 6and Figure 7 As shown, the embodiments of this application combine data-driven AI technology with interpretable rule engine technology to construct an adaptive and evolvable human-machine collaborative intelligent detection system. A complete closed-loop methodology is built, consisting of "data acquisition - AI analysis and rule generation - human authentication - rule engine execution - feedback optimization." The application of AI is transformed from direct "end-to-end classification" to "rule generator." Instead of directly providing detection results, AI outputs user-readable, parameter-adjustable, and process-manageable business rule expressions for the rule engine. This solves the problems of pure AI models being "black boxes" and uncontrollable, as well as the rigidity and lack of adaptability of static rule systems.

[0127] The rule generation module is decoupled from rule generation through a predefined function call interface. The AI ​​intelligent model calls rule templates through structured instructions, rather than directly generating code strings. This achieves output standardization, ensuring that the output rules conform to the rule engine's syntax and security specifications. The generated rules have clear logic, making them easy for human experts to understand and fine-tune. The system is more robust, reducing the risk and complexity of errors from directly parsing the output content.

[0128] When the aforementioned defect detection methods are applied to visual defect detection scenarios in manufacturing, the generated rules are no longer simple threshold judgments, but rather intelligent criteria that integrate multi-dimensional features and are produced by AI intelligent models after mining complex production data. Examples include location-based dynamic threshold rules: applying different standards to the same defect in different areas; or defect density-based cluster effect rules: considering defect distribution rather than just individual defects; or composite rules integrating real-time process parameters: associating defect features with production parameters for judgment.

[0129] The results of rule execution, especially the results of manual review, are used as new labeled data and automatically fed back to the AI ​​intelligent model for retraining. This defect detection system is not a static system deployed once and for all, but an intelligent agent that can learn from use and continuously evolve over time. Through mechanisms such as "active learning," it efficiently utilizes feedback from human experts to achieve continuous iteration and optimization of detection capabilities. The ultimate goal is to reduce reliance on human intervention and create a self-improving flywheel effect.

[0130] According to this application, by combining the dynamic analysis capabilities of AI intelligent models with the execution capabilities of rule engines, a high-precision, highly adaptive, highly transparent, and easily integrated intelligent defect detection system has been created, providing strong technical support for the digital transformation of the manufacturing industry.

[0131] Furthermore, based on the defect detection method proposed in the embodiments of this application, the embodiments of this application also propose a system for implementing the defect detection method.

[0132] Figure 8 This is a schematic diagram of a defect detection system 200 proposed in an embodiment of this application.

[0133] refer to Figure 7 As shown, the defect detection system may include: a rule generation module 210, a rule management module 220, a rule engine module 230, and a production line control module 240.

[0134] The specific functions of each module can be found in the previous text, and will not be repeated here.

[0135] Furthermore, this application also proposes a defect detection device, which includes a processor and a memory connected together. The memory is used to store program code, and the processor is used to call the program code to execute any of the defect detection methods proposed in this application.

[0136] This application also provides a computer program product, which includes computer program code that, when run on a computer, causes the computer to perform the methods described in the above embodiments.

[0137] This application also provides a computer-readable medium storing program code that, when run on a computer, causes the computer to perform the methods described in the above embodiments.

[0138] Although this application has been described with reference to preferred embodiments, various modifications can be made thereto and components or steps can be replaced with equivalents without departing from the scope of this application. In particular, the technical features mentioned in the various embodiments can be combined in any manner, provided there is no conflict in structure or method steps. This application is not limited to the specific embodiments disclosed herein, but includes all technical solutions falling within the scope of the claims.

[0139] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A defect detection method, characterized in that, The method includes: The system acquires real-time data during the product manufacturing process and stores it in a historical database. The real-time data includes the product's process parameters, defect size, defect coordinates, and defect type. The intelligent model periodically analyzes the data in the historical database and generates a first rule expression, which conforms to a preset syntax for user review. The rule engine performs defect detection based on the real-time data and the second rule expression to output disposal instructions for the product. The second rule expression is obtained by the user based on the first rule expression.

2. The method according to claim 1, characterized in that, The method further includes: The product is operated according to the disposal instructions, which include release, hold, alarm, and repair. The results of the execution are fed back to the historical database.

3. The method according to claim 1 or 2, characterized in that, The step of periodically analyzing the data in the historical database using an intelligent model and generating a first rule expression specifically includes: The intelligent model is periodically trained using data from the historical database to generate a first criterion logic, which indicates the relationship between the data features of the product and the results of the execution of the product. Based on the first criterion logic, the first rule generation instruction is output through a predefined function call interface; The first rule expression is generated based on the predefined rule structure and the first rule generation instruction.

4. The method according to any one of claims 1-3, characterized in that, The first rule expression indicates the relationship between the location, distribution, characteristics, and process parameters of the product's defects and the handling instructions.

5. The method according to any one of claims 1-4, characterized in that, The method further includes: The first rule expression is displayed to the user through a graphical interface for the user to process, including confirmation, modification, and rejection.

6. The method according to any one of claims 1-5, characterized in that, The rule engine is the Aviator engine, and the first rule expression and the second rule expression conform to the syntax of the Aviator engine.

7. The method according to claim 6, characterized in that, The method further includes: The second rule expression is simplified by encapsulating the business logic through a custom function. The Aviator engine acquires the real-time data and makes a judgment based on the simplified second rule expression to output the processing instruction.

8. The method according to any one of claims 2-7, characterized in that, The data in the historical database includes corresponding weights and confidence levels, and the method further includes: The intelligent model is trained based on the feedback execution results, specifically including: The learning weights of the intelligent model are adjusted based on the confidence levels corresponding to the data in the historical database.

9. The method according to claim 1 or 2, characterized in that, The intelligent model includes a knowledge graph, which constructs a semantic network from the product's defects, process parameters, and production equipment. The step of periodically analyzing the data in the historical database using an intelligent model and generating a first rule expression includes: The graph generates a first rule expression based on the data in the historical database and the status of the equipment. The first rule expression is also used to indicate the adjustment of the process parameters.

10. The method according to claim 1 or 2, characterized in that, The intelligent model is a large language model, and the method further includes: The large language model generates a first rule expression based on the user's language instructions and data from the historical database.

11. A defect detection system, characterized in that, Includes modules or units for performing the method as described in any one of claims 1 to 10.

12. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that is executed by a processor to implement the method as described in any one of claims 1 to 10.

13. A computer program product, characterized in that, It includes instructions that, when executed by a processor, cause the method as described in any one of claims 1 to 10 to be performed.

Images