Industrial automation software testing system and method based on artificial intelligence

Abstract

The invention provides an industrial automation software testing system and method based on artificial intelligence. Comprising a use case generation module used for generating a use case set and generating an input sequence, an assertion script and a data acquisition instruction which are associated with use cases; the resource modeling module is used for generating resource configuration description corresponding to the use case; the scheduling execution module is used for establishing a unified time base, implementing resource locking and synchronous triggering, and carrying out online rescheduling under a fault or conflict event; the monitoring and diagnosing module is used for identifying assertion violation and time sequence abnormity according to the baseline model and the time sequence judging device, and positioning a function point and a parameter interval; and the prediction feedforward module is used for generating risk scores for the function points and the resource windows by using the time sequence prediction model, and adjusting the use case priorities and the resource reservation parameters according to the risk scores. According to the invention, automatic use case generation, driver scheduling change, real-time monitoring diagnosis and risk prediction can be realized, and the test efficiency and coverage are improved.

Description

Technical Field

[0001] This application relates to the field of industrial automation software testing technology, and in particular to an artificial intelligence-based industrial automation software testing system and method. Background Technology

[0002] Industrial automation is evolving towards digitalization and networking, with control systems deeply coupled with upper-level business applications. Software demands stringent requirements in terms of multi-device collaboration, real-time determinism, and security. To ensure quality, companies typically employ methods such as script-based functional regression, simulation or semi-physical in-loop testing, manually designed extensive scenario test cases, and post-deployment defect backtracking.

[0003] Existing technologies mainly rely on manual experience to maintain use cases and scenarios, making it difficult to cover complex working conditions and cross-device linkage; the expression and verification of constraints such as timing, concurrency and synchronization are insufficient; the regression scope and priority lack automatic orchestration driven by changes; inconsistent time bases of multi-source data and heterogeneous devices and protocols lead to unsmooth observation and replay links; and there is a lack of machine-readable evidence and traceable evaluation systems.

[0004] With the development of artificial intelligence technology, there have been explorations in test case generation and anomaly identification, but due to limitations such as data scarcity, interpretability and security constraints, and the complexity of switching between online and offline testing, it is still difficult to form an integrated testing solution that covers generation, scheduling, monitoring and prediction. Summary of the Invention

[0005] In view of this, embodiments of this application provide an artificial intelligence-based industrial automation software testing system and method to solve the problems of insufficient use case construction and boundary scenario coverage, lack of change and risk-driven regression priority and resource scheduling, and lack of timing concurrency verification and automatic diagnosis in the testing process.

[0006] The first aspect of this application provides an artificial intelligence-based industrial automation software testing system, comprising: a test case generation module, used to perform semantic parsing of requirements and design documents, combine historical test cases and execution records to generate a test case set, and generate input sequences, assertion scripts and data acquisition instructions associated with the test cases; a resource modeling module, used to calculate test case priorities based on functional importance, change impact score and execution cost, and establish capability, mutual exclusion and synchronization constraint models for computing nodes and equipment, and generate resource configuration descriptions corresponding to the test cases; and a scheduling and execution module, used to allocate and orchestrate test cases according to test case priorities and resource configuration descriptions, and establish a unified... The system includes a time base module, which implements resource locking and synchronization triggering, performs online rescheduling in the event of faults or conflicts, and drives the software under test to execute assertion scripts and data acquisition instructions. The monitoring and diagnostic module collects logs, variables, and device status during execution, identifies assertion violations and timing anomalies based on the baseline model and timing determiner, locates function points and parameter ranges, and sends the location results back to the use case generation module and resource modeling module. The prediction feedforward module builds a timing prediction model based on historical operation and environmental data, uses the timing prediction model to generate risk scores for function points and resource windows, and adjusts use case priorities and resource reservation parameters based on the risk scores.

[0007] The second aspect of this application provides an artificial intelligence-based industrial automation software testing method based on the system of the first aspect, comprising: semantically parsing requirements and design documents to obtain a set of structured elements and associating it with version change identifiers; generating a set of test cases containing input sequences, assertion scripts, data acquisition instructions and timing sequences, and concurrency constraints based on the set of structured elements and historical test cases and execution records; establishing a priority model and generating test case priorities; establishing capability, mutual exclusion, and synchronization constraint models for computing nodes and devices; forming a resource configuration description corresponding to the test case set and outputting an ordered test case queue; and scheduling and orchestrating the ordered test case queue and resource configuration description to establish an execution sequence. The system establishes a unified time base for session binding, locks relevant resource instances, triggers input sequences, assertion scripts, and data acquisition commands according to synchronization barriers and time windows, and implements online rescheduling in the event of conflicts or failures. Under the unified time base, it collects logs, variables, and device status, identifies assertion violations and timing anomalies based on the baseline model and timing determiner, and locates them to function points and parameter ranges. The location results are used to update the test case set and resource configuration description. Under the unified time base, it aligns and aggregates historical test data, runtime data, and environmental data, trains a timing prediction model, generates risk scores for function points and resource windows, and adjusts test case priorities and resource reservation parameters based on the risk scores.

[0008] The above-described technical solutions adopted in the embodiments of this application can achieve the following beneficial effects: The test case generation module performs semantic parsing of requirements and design documents, combines historical test cases and execution records to generate test case sets, and generates input sequences, assertion scripts, and data collection instructions associated with the test cases. The resource modeling module calculates test case priorities based on functional importance, change impact scores, and execution costs, and establishes capability, mutual exclusion, and synchronization constraint models for computing nodes and devices, generating resource configuration descriptions corresponding to the test cases. The scheduling and execution module allocates and orchestrates test cases according to their priorities and resource configuration descriptions, establishes a unified time base, implements resource locking and synchronous triggering, and... In the event of a fault or conflict, online rescheduling is performed, driving the software under test to execute assertion scripts and data acquisition instructions. A monitoring and diagnostic module collects logs, variables, and device status during execution, identifies assertion violations and timing anomalies based on a baseline model and timing determiner, and locates function points and parameter ranges, feeding the results back to the test case generation module and resource modeling module. A prediction feedforward module builds a timing prediction model based on historical operating and environmental data, generates risk scores for function points and resource windows using the timing prediction model, and adjusts test case priorities and resource reservation parameters based on the risk scores. This application enables automatic test case generation, change-driven scheduling, real-time monitoring and diagnosis, and risk prediction, improving testing efficiency and coverage. Attached Figure Description

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

[0010] Figure 1 This is a schematic diagram of the structural composition of an artificial intelligence-based industrial automation software testing system provided in an embodiment of this application; Figure 2 This is a flowchart illustrating the artificial intelligence-based industrial automation software testing method provided in this application embodiment. Detailed Implementation

[0011] In the following description, specific details such as particular system architectures and techniques are set forth for illustrative purposes and not for limitation, in order to provide a thorough understanding of the embodiments of this application. However, those skilled in the art will understand that this application may also be implemented in other embodiments without these specific details. In other instances, detailed descriptions of well-known systems, apparatuses, circuits, and methods have been omitted so as not to obscure the description of this application with unnecessary detail.

[0012] With the advancement of Industry 4.0, industrial automation software plays an increasingly crucial role in industrial production. Industrial automation software needs to possess high stability, accuracy, and reliability to ensure the safe and efficient operation of industrial production. Testing is a vital step in ensuring the quality of industrial automation software, but traditional testing methods face numerous challenges.

[0013] On the one hand, industrial automation software is complex, involving the control of various devices, data interaction, and business logic, resulting in a large number of test cases. Designing and executing test cases manually consumes significant time and manpower, and is prone to oversights. On the other hand, industrial production environments are complex and variable, making it difficult to fully predict software performance under different operating conditions. Traditional testing struggles to cover all possible scenarios, meaning that various problems may still arise after software deployment, affecting the normal operation of industrial production.

[0014] The rapid development of artificial intelligence (AI) technology has provided new avenues for solving these problems. However, current solutions for effectively applying AI technology to industrial automation software testing to significantly improve testing efficiency still need further refinement.

[0015] In view of the problems existing in the prior art, this application aims to provide an automated testing system and method for industrial automation software based on AI tools. By introducing AI tools, test cases are automatically generated, test tasks are intelligently scheduled, the test process is monitored in real time, and potential problems are predicted, thereby significantly improving the testing efficiency and quality of industrial automation software.

[0016] The following is a summary of the main components and functions of the AI-based automated testing system provided in this application, which may include the following: 1. Test case automatic generation module By using Natural Language Processing (NLP) technology, we can analyze the requirements documents and design documents of industrial automation software to extract key information, such as functional descriptions, input and output requirements, and business rules.

[0017] Based on machine learning algorithms, historical test cases and their execution results are learned and combined with information extracted from documents to generate new test cases. For example, Generative Adversarial Networks (GANs) can be used to generate test data and operation steps that conform to the business scenarios of industrial automation software, as part of the test cases.

[0018] The generated test cases are prioritized based on factors such as the importance of the software function, its usage frequency, and the probability of problems being found in historical tests. The execution priority of each test case is determined, and high-priority test cases are executed first to improve testing efficiency.

[0019] 2. Intelligent scheduling module for test tasks Based on operations research and optimization algorithms, test tasks are intelligently scheduled according to the priority of test cases, the resources required for execution, and the availability of those resources. For example, genetic algorithms or simulated annealing algorithms are used to find the optimal test task allocation scheme, rationally distributing test tasks to different test nodes for parallel execution, making full use of test resources, and shortening the test cycle.

[0020] During testing, the scheduling strategy for test tasks is dynamically adjusted. When a test node fails or resource conflicts occur, the test tasks on that node are promptly reallocated to other nodes to ensure the continuity and efficiency of the testing process.

[0021] 3. Real-time monitoring and analysis module for the testing process During the testing and execution of industrial automation software, real-time data collection is performed on the software's operation, including system logs, variable values, and equipment status information. Machine learning algorithms are then used to analyze this data in real time to establish a model of the software's normal operating behavior.

[0022] When the software's operating data deviates from the normal behavior model, a warning signal is issued in a timely manner; for example, anomaly detection algorithms, such as the Isolation Forest algorithm or One-Class Support Vector Machine (SVM), are used to identify abnormal system behavior and determine whether there is a software fault or potential problem.

[0023] It automatically diagnoses and locates problems encountered during testing. By analyzing runtime data and test case execution paths, and utilizing causal analysis algorithms such as Bayesian networks, it identifies the root cause of problems and provides testers with detailed problem diagnostic reports to help them quickly resolve issues.

[0024] 4. Potential Problem Prediction Module Collect and organize historical test data, operational data, and related environmental data (such as temperature, humidity, and equipment load in the industrial production environment) of industrial automation software.

[0025] Based on deep learning algorithms, such as Long Short-Term Memory (LSTM) networks or Convolutional Neural Networks (CNNs), a potential problem prediction model is built. This model learns patterns and regularities in historical data to predict potential problems that may arise during the future operation of the software, such as performance bottlenecks and compatibility issues.

[0026] Based on the forecast results, corresponding response strategies should be developed in advance, such as optimizing software code, adjusting test plans, or improving the industrial production environment, to avoid potential problems affecting industrial production after the software goes live.

[0027] The core innovation of this application's technical solution lies in deeply integrating AI technology into the entire process of industrial automation software testing, constructing an integrated intelligent testing system encompassing "generation-scheduling-monitoring-prediction," specifically including: 1. AI-driven automated test case generation technology Natural Language Processing (NLP) is used to parse requirements / design documents, accurately extract key information such as functional descriptions and input / output requirements, and solve the problems of low efficiency and easy omission in traditional manual extraction.

[0028] By combining machine learning algorithms (such as generative adversarial networks, GANs) to learn from historical test data, test cases covering normal and edge scenarios are generated, and efficient execution is achieved through priority ranking (based on functional importance, probability of historical problems, etc.).

[0029] 2. Dynamic and intelligent test task scheduling mechanism Based on operations research and optimization algorithms (such as genetic algorithms and simulated annealing algorithms), test tasks are dynamically allocated according to test case priority and resource availability, supporting parallel execution; automatic rescheduling is performed when node failures or resource conflicts occur to ensure test continuity.

[0030] 3. Real-time monitoring and diagnosis of the testing process Real-time collection of software operation data (system logs, device status, etc.), construction of normal behavior models through machine learning, and rapid identification of anomalies by combining anomaly detection algorithms (such as Isolation Forest, One-Class SVM).

[0031] By using causal analysis algorithms (such as Bayesian networks), the root cause of problems can be automatically located, diagnostic reports can be generated, and the time for troubleshooting can be shortened.

[0032] 4. Deep learning-based ability to predict potential problems By integrating historical test data, operational data, and environmental data (temperature, humidity, etc.), a predictive model is built using Long Short-Term Memory Network (LSTM) or Convolutional Neural Network (CNN) to anticipate potential risks such as performance bottlenecks and compatibility issues.

[0033] The scope of protection of this application mainly focuses on the specific implementation of the technical solution and the module collaboration logic, the core of which includes: 1. Protection of methods and steps The complete process of test case generation: NLP document parsing → machine learning (including GAN) test case generation → specific rules and algorithm applications for priority ranking.

[0034] Test the dynamic mechanism of task scheduling: resource modeling method, task allocation logic based on genetic algorithm / simulated annealing algorithm, and rescheduling strategy in case of failure / conflict.

[0035] Real-time monitoring and diagnosis process: data collection scope, normal behavior model construction method, application of anomaly detection algorithms (such as isolated forest), and specific steps for Bayesian network localization problem.

[0036] Implementation of potential problem prediction: historical data integration standards, LSTM / CNN model construction and training methods, and the logical connection between prediction results and response strategies.

[0037] 2. Innovative combination of system modules The collaborative architecture of the four core modules (automatic test case generation, intelligent test task scheduling, real-time monitoring and analysis of the test process, and prediction of potential problems) includes the data interaction methods between modules and the logic of functional connection.

[0038] 3. Scenario-based applications of AI technology The specific application of GANs in generating test cases for edge scenarios in industrial automation software differs from the generation logic in general domains.

[0039] LSTM / CNN is a predictive model that integrates industrial environmental data (temperature, equipment load, etc.) with software operation data, and its dedicated training method for predicting performance bottlenecks and compatibility issues.

[0040] 4. Related protection of technical effects The technical effects achieved through the collaborative implementation of four modules—"automatic generation, intelligent scheduling, real-time monitoring, and predictive prevention"—such as "improved testing efficiency (shortened cycle), enhanced comprehensive coverage (edge ​​scenario coverage), and early prevention of problems," are linked to specific technical steps.

[0041] The specific modules and functions of the artificial intelligence-based industrial automation software testing system provided in this application will be described in detail below with reference to the accompanying drawings and specific embodiments. Figure 1 This is a schematic diagram of the structural composition of an artificial intelligence-based industrial automation software testing system provided in an embodiment of this application, as shown below. Figure 1 As shown, this AI-based industrial automation software testing system may specifically include the following modules: The use case generation module 101 is used to perform semantic parsing of requirements and design documents, combine historical use cases and execution records to generate a set of use cases, and generate input sequences, assertion scripts and data collection instructions associated with the use cases; Resource modeling module 102 is used to calculate use case priorities based on functional importance, change impact score and execution cost, and to establish capability, mutual exclusion and synchronization constraint models for computing nodes and devices, and generate resource configuration descriptions corresponding to use cases; The scheduling and execution module 103 is used to allocate and orchestrate test cases according to test case priority and resource configuration description, establish a unified time base, implement resource locking and synchronous triggering, perform online rescheduling under fault or conflict events, and drive the software under test to execute assertion scripts and data acquisition instructions. The monitoring and diagnosis module 104 is used to collect logs, variables and device status during execution, identify assertion violations and timing anomalies based on the baseline model and timing determiner, locate the function point and parameter range, and send the location results back to the test case generation module and resource modeling module. The prediction feedforward module 105 is used to establish a time-series prediction model based on historical operation and environmental data, generate risk scores for function points and resource windows using the time-series prediction model, and adjust the use case priority and resource reservation parameters according to the risk scores.

[0042] In some embodiments, semantic parsing of requirements and design documents includes: Preprocess and identify the chapter structure of requirements and design documents, and perform term disambiguation and entity standardization based on domain dictionary and rule base to establish a unified naming for function points, parameter items, device objects and interface identifiers; Based on syntactic relations and semantic role annotations, functional points, input and output constraints, state transition descriptions, timing and concurrency constraints, and device linkage relationships are extracted to form a set of structured elements; The structured feature set is mapped to input items for use case generation and associated with version change identifiers.

[0043] Specifically, in this embodiment, a unified data processing link is established for the semantic parsing of requirements and design documents. The data processing link consists of four stages: preprocessing and document structure recognition, term disambiguation and entity standardization, semantic element extraction and structured modeling, and use case generation input item mapping and version change association.

[0044] First, the document source is preprocessed to ensure consistent encoding, standardized formatting, and removal of headers, footers, and irrelevant elements. The heading levels, numbering system, and cross-page continuation relationships are then analyzed to generate a document tree. Each node in the document tree records the level number, heading text, paragraph range, and anchor points for referenced figures.

[0045] Secondly, terminology disambiguation and entity standardization are performed based on a domain dictionary and rule base. The domain dictionary covers commonly used functional points, parameter items, equipment objects, and interface identifiers in industrial control, while the rule base includes naming conventions, unit conversions, and alias mapping rules. Homographs are distinguished using contextual nearest neighbor windows and document position signals, and entities are unified under a standardized name.

[0046] Furthermore, following the syntactic dependency and semantic role labeling strategy, functional points, input / output constraints, state transition descriptions, timing and concurrency constraints, and device linkage relationships are extracted from paragraph statements. Event trigger words, condition words, units, and thresholds are then structurally labeled to form a set of structured elements. These structured elements record, in the form of entries, identifiers, source document paths, triggering conditions, participating entities, parameter fields, constraint types, and referenced interface identifiers.

[0047] Finally, the structured set of elements is mapped to the input items for use case generation, including input sequence placeholders, assertion script placeholders, data acquisition instruction placeholders, timing and concurrency constraint placeholders, and resource requirement placeholders. The association is established with version change identifiers to record the addition, modification, and deletion status of elements in different versions.

[0048] The innovative technical features and technical terms involved in this embodiment are explained below: Chapter tree and numbering alignment mechanism: The chapter tree is built using hierarchical headings, technical point lists, and citation numbers as anchors to ensure that cross-chapter function points and parameter items are traceable and referable during the parsing phase.

[0049] Terminology disambiguation and entity standardization: Synonymous terms are unified through alias mapping, unit conversion and naming standard set. For example, "execution unit" and "actuator" are unified as the same device object identifier, and "millisecond" and "ms" are unified as standard unit identifiers and converted to a unified time base.

[0050] Semantic element extraction templates: Several extraction templates are configured for common expressions of control logic, including condition trigger templates, state transition templates, input / output constraint templates, concurrency mutual exclusion templates, and device linkage templates, and element entries are generated by combining syntactic dependencies and role labeling.

[0051] Input placeholders and version association: The input sequences, assertion scripts, data collection instructions, timing and concurrency constraints and resource requirements required for test case generation are all derived from the element set in the form of placeholders, and their source and change trajectory are recorded with version change identifiers to support subsequent regression test selection and scheduling orchestration.

[0052] For example, take a design document describing the control of a conveyor line. The document contains a title hierarchy of "System Overview → Upper Control → Conveyor Cycle → Anomaly Handling". The "Conveyor Cycle" section describes the function "Cycle Triggering and Cycle Completion", and the "Anomaly Handling" section describes the function "Block Detection and Removal".

[0053] In the preprocessing stage, a chapter tree is parsed, establishing two chapter nodes: "Transportation Beat" and "Exception Handling," and identifying the paragraph ranges corresponding to the numbers "3.2.1" and "3.4.2." In the terminology disambiguation stage, the dictionary unifies synonyms such as "beat trigger" and "beat start" into the function point identifier "beat trigger," and unifies "blockage" and "stuck" into the function point identifier "blockage detection." The rule base unifies "ms" and "milliseconds" to a unified time base.

[0054] In the semantic element extraction phase, the sentence "When the start / stop signal is 'on' and the photoelectric sensor detects no material for 500ms, the cycle is started. After starting, the previous station should be cleared and a completion signal should be fed back within 1000ms" is parsed. The input / output constraints are extracted as "start / stop signal = on" and "photoelectric sensor = no material". The timing constraints are "no material duration = 500ms" and "completion time limit = 1000ms". The equipment linkage relationship is "previous station clears → completion feedback". The sentence "After the blockage detection is triggered, the downstream conveying is paused and the alarm light is lit. The release condition is manual confirmation or the sensor recovers 1000ms of continuous no material" is parsed into the state transition descriptions "normal → blockage → pause" and "pause → normal". The concurrency constraint is "downstream conveying is mutually exclusive during the pause". The above content is recorded as structured element entries, each with its source document path and parameter domain.

[0055] During the input item mapping phase, element items are projected onto use case generation input items: Input sequence placeholders include "Start / Stop = On", "Simulate no material for 500ms", "Trigger beat", "Check completion feedback", assertion script placeholders include "Completion feedback arrives within 1000ms", "Give way signal precedes completion feedback", data acquisition instruction placeholders include "Acquire start / stop signal, photoelectric sensor quantity, give way signal, completion feedback, alarm light status", timing and concurrency constraint placeholders include "Downstream conveyor pause mutual exclusion" and "Block release condition group", and resource requirement placeholders include "Conveyor line controller, photoelectric sensor, alarm light".

[0056] During the version association phase, for the version change identifier "V1.2→V1.3", the record "the blockage removal condition is confirmed by manual confirmation and the newly added sensor restores continuous no material for 1000ms" is recorded. The change type is marked as "new" in the element entry, and the corresponding assertion script placeholder and data acquisition command placeholder are added to the input item placeholder.

[0057] Through the above embodiments, a closed-loop parsing process is completed, from document chapters to unified naming, from semantic elements to input item placeholders, and then to version change associations, providing directly referable structured input for subsequent use case generation, priority assessment, and scheduling orchestration.

[0058] In some embodiments, a set of use cases is generated by combining historical use cases and execution records, including: Map historical use cases, execution records, and structured element sets based on version change identifiers; Based on the similarity between function points and parameter domains, placeholders for input sequences, assertion scripts, and data acquisition instructions are reused. Based on the execution record sedimentation boundary parameters and concurrent timing characteristics, rules and perturbation scripts are constructed, and adversarial samples are used to generate supplementary boundaries and abnormal test cases; The generated test cases are validated for executability and resource synchronization consistency. Those that pass the validation are registered as a set of test cases and bound to a version change identifier.

[0059] Specifically, this embodiment establishes a four-stage generation chain around "use case expansion driven by historical accumulation": mapping and aggregation, similarity reuse, rule and perturbation expansion, and executability and synchronization consistency verification. First, historical use cases and execution records are aggregated based on version change identifiers and mapped one-to-one with the structured element set formed during the semantic parsing stage. Second, the similarity between function points and parameter domains is used to reuse and complete input sequence placeholders, assertion script placeholders, and data acquisition instruction placeholders. Third, based on the boundary parameters and concurrent timing characteristics accumulated in the execution records, rules and perturbation scripts are constructed, and boundary and abnormal use cases are supplemented through an adversarial sample generation mechanism. Finally, the executability and resource synchronization consistency of the generated use cases are verified; those that pass are registered in the use case set and bound to the version change identifier.

[0060] The innovative technical features and technical terms involved in this embodiment are explained below: Version change mapping: Using version change identifiers as anchors, a pointing relationship is established between the preconditions, inputs and outputs, assertions and timing attributes of historical use cases and the structured element entries, forming a traceable mapping across versions.

[0061] Function point and parameter domain similarity: The candidate reuse degree is jointly measured by the semantic similarity of function points and the overlap of parameter domains. Priority is given to reusing historical use case fragments that are close to the upper bound of parameters, have similar triggering conditions and consistent assertion structures.

[0062] Rules and perturbation script library: Automatically extracts boundary values, jitter ranges, concurrency mutual exclusion and synchronization order features from execution records, and solidifies them into reusable rules and perturbation script entries for systematically generating extreme and abnormal scenarios.

[0063] Adversarial sample generation: Based on function points, parameter domains and timing constraints, candidate extreme combinations are generated; based on the standard validator and execution feasibility discriminator, unexecutable and self-contradictory samples are filtered out, and samples that pass the test are retained to enter the candidate set of use cases.

[0064] For example, taking the conveyor line control example as an example, the version was upgraded from V1.2 to V1.3, and a new element was added: "The blockage is cleared when the sensor resumes continuous zero material for 1000ms".

[0065] Mapping and aggregation: Read historical use cases and their execution records from V1.2, and establish a mapping based on the function point identifiers "tick trigger" and "blockage detection and removal" and the structured element set; mark the source chapter path and parameter domain range for historical entries involving "start stop = on", "photoelectric sensor = no material", and "completion feedback ≤ 1000ms".

[0066] Similarity reuse: For the "Beat Trigger" function, calculate the semantic similarity and parameter domain overlap between the V1.2 use case and the V1.3 elements. Reuse the input sequence placeholders "Start / Stop = On → Simulate no material for 500ms → Trigger Beat" and "Check Completion Feedback". Reuse the assertion script placeholders "Completion Feedback ≤ 1000ms, Yield Signal Before Completion Feedback". Reuse the data acquisition command placeholders "Acquisition Start / Stop, Photoelectric, Yield, Completion Feedback". For the "Block Removal" function, while reusing the "Manual Confirmation Removal" placeholder, add the new placeholder "Removal occurs after 1000ms of continuous no material from the sensor".

[0067] Rule and Disturbance Expansion: Boundary and concurrency characteristics are extracted from execution records, such as "photoelectric jitter 50ms", "downstream transport pause mutual exclusion", and "sensitivity to the order of yielding and completion feedback", generating rule entries such as "no material duration threshold ∈ [480ms, 520ms]", "completion time limit ∈ [900ms, 1100ms]", and "downstream mutual exclusion window ≥ 800ms". Based on this, disturbance scripts are constructed, such as "insert a short period of material supply for 20ms when no material supply lasts for 480ms and then resume no material supply", and "insert a yielding signal delay of 50ms before completion feedback". Through adversarial sample generation, boundary use cases such as "no material supply duration is exactly 500ms", "completion feedback is exactly 1000ms", and "downstream pause and upstream beat trigger boundary concurrency" are formed, as well as abnormal use cases such as "yielding is later than completion feedback" and "jitter causes no material supply to be interrupted".

[0068] Verification and Registration: Execution verification is performed on each generated test case to check whether parameter values ​​fall within the device's capabilities and range, and whether the action sequence can be triggered within the predetermined time window; resource synchronization consistency verification is performed to check whether mutual exclusion sets, synchronization barriers, and occupied intervals conflict, and for cross-device joint test cases, the unified time base and triggering order are verified. Test cases that pass verification are registered in the test case set with a unique identifier and bound to the version change identifier V1.3, while also recording their source elements and reuse fragment fingerprints.

[0069] After registration, the system saves the final drafts of the input sequence placeholders, assertion script placeholders, data acquisition instruction placeholders, and timing concurrency constraint placeholders for each new use case, and retains the reference relationships pointing to structured element entries, historical reuse fragments, and disturbance rule entries. This set of use cases serves as direct input for subsequent priority calculations and resource configuration description generation, ensuring a continuous connection from version element changes to regression selection and scheduling orchestration.

[0070] In some embodiments, use case priority is calculated based on functional importance, change impact score, and execution cost, including: A priority model is established using functional importance, change impact score, and execution cost as factors to generate initial use case priorities; The risk score output by the prediction feedforward module is incorporated into the priority model to obtain the corrected use case priority. Based on the mutual exclusion set and synchronization constraints provided by the resource modeling module, the priority of the modified test cases is adjusted for feasibility, and an ordered test case queue is output.

[0071] Specifically, this embodiment calculates use case priorities based on a chain of "priority modeling—risk incorporation—feasibility adjustment—queue output". First, an initial use case priority is generated by establishing a priority model using functional importance, change impact score, and execution cost as factors. Then, the risk scores for functional points and resource windows output by the prediction feedforward module are received and incorporated into the priority model to form a revised use case priority. Finally, the revised use case priorities are adjusted for feasibility based on the mutual exclusion set and synchronization constraints given by the resource modeling module, and an ordered use case queue is output.

[0072] The innovative technical features and technical terms involved in this embodiment are explained below: Functional importance: Functional points are scored based on business weight, call frequency and security level to reflect the criticality of the tested function in the control chain.

[0073] Change Impact Score: Based on version change identifiers, the differences between code and configuration are propagated, and the impact is quantified by combining historical defect hotspots and use case hit paths.

[0074] Execution cost: Combining resource configuration description and statistics duration, equipment usage, probability of mutual exclusion conflicts, and license quota consumption, the execution cost of the use case is formed.

[0075] Risk Score: The risk quantification for target function points and resource windows is given by a time series prediction model trained on historical test data, operational data and environmental data under a unified time base.

[0076] Feasibility adjustment: Under the premise of mutual exclusion set and synchronization constraint, apply conflict penalty and synchronization alignment correction to the priority of modified use cases to ensure that the schedule is executable.

[0077] For example, taking the function points "cycle triggering" and "blockage detection and removal" in version V1.3 of the conveyor line control example as an example: Initial use case priority generation: For use cases related to "cycle triggering," the functional importance is set to high based on the importance record of the "start / stop control - cycle completion" link; V1.3 adds "sensor continuous no material for 1000ms" to the "blockage relief condition," and the impact score of changes to related use cases is marked as high; for use cases involving cross-device joint testing that require the use of the conveyor line controller and downstream sensors, the execution cost is marked as medium-high. The model normalizes the three factors and combines their weights to output the initial use case priority.

[0078] Risk is incorporated into the priority model: the prediction feedforward module assigns a high risk score to "feedback completion ≤ 1000ms" in the "high temperature and high humidity + high load" resource window, and a medium-to-high risk score to concurrent overlap in the "downstream mutual exclusion window". The system incorporates the risk scores into the priority model, raising the priority of boundary use cases and abnormal use cases for the corresponding functional points, thus forming a priority model for corrective use cases.

[0079] Feasibility Adjustment and Queue Sequencing: Based on the mutual exclusion set and synchronization constraints defined in the resource modeling module, concurrency limits and synchronization barriers are applied to use cases with "downstream transport pause mutual exclusion" to align with them. For cross-device cycle boundary use cases with resource conflicts within the same time window, a cooldown period is inserted and their order in adjacent windows is adjusted. For use cases requiring unified time base alignment where "yielding signal precedes completion feedback," the triggering order is kept consistent and they are moved to the earliest executable position that satisfies the synchronization constraints. After adjustment, an ordered use case queue is output, including "cycle trigger just-in-time use cases," "completion feedback time limit boundary use cases," "downstream mutual exclusion concurrency boundary use cases," and "blockage removal new condition use cases."

[0080] The ordered use case queue and resource configuration description are submitted to the scheduling and execution module for execution. During the execution process, if the monitoring and diagnosis module locates an assertion violation related to boundary parameters or concurrency characteristics, the system will send the location result back, triggering a refresh of the risk score for the corresponding function point and a fine-tuning of the priority of the relevant use cases, thus completing the rolling update.

[0081] This embodiment achieves integrated orchestration of use case sorting and resource alignment by prioritizing functional importance, change impact score, and execution cost, along with risk scoring, mutual exclusion, and synchronization constraints, resulting in an ordered queue of executable use cases that covers boundary scenarios.

[0082] In some embodiments, a capability, mutual exclusion, and synchronization constraint model is established for computing nodes and devices, and a resource configuration description corresponding to the use case is generated, including: Establish resource capability descriptions for computing nodes and devices, and define mutual exclusion and synchronization constraints; Map the resource requirements of the use cases to specific resource instances, and provide the resource configuration description by binding the usage range, concurrency and quota allocation, cooldown time and priority. Perform mutual exclusion consistency and quota feasibility verification on the resource configuration description, and establish association with use case identifier and version change identifier.

[0083] Specifically, this embodiment generates resource configuration descriptions corresponding to use cases based on the process of "capability modeling → mutual exclusion and synchronization modeling → use case resource mapping → quota and consistency verification → version association output". First, resource capability descriptions are established for computing nodes and devices, and mutual exclusion and synchronization constraints are defined; then, the resource requirements of the target use case are mapped to specific resource instances, and the occupancy range, concurrency and quota allocation, cooldown time and priority binding are given; finally, mutual exclusion consistency and quota feasibility verification are performed on the generated resource configuration descriptions, and association is established with use case identifiers and version change identifiers.

[0084] The innovative technical features and technical terms involved in this embodiment are explained below: Resource capability description: Records processing capability metrics, interface / peripheral usage granularity, license quota, dependencies, usage duration granularity, and trigger latency limit for computing nodes and devices.

[0085] Mutual exclusion set and shared mode: Include the same physical link or exclusive peripheral into a mutual exclusion set, distinguish between exclusive and shared modes, and configure the concurrency limit.

[0086] Synchronization Barrier and Time Window: Used for action alignment during cross-device joint testing. The barrier defines the trigger order and the time window for allowing jitter, and is bound to a unified time base.

[0087] Occupancy Period and Cooldown Time: The occupation period describes the time range from when a resource is locked to when it is released, while the cooldown time is used to prevent the state from not being reset due to frequent switching.

[0088] Priority binding and quota allocation: Bind the current priority of the use case to the resource lock request order and allocate quotas on the license or scarce resources.

[0089] For example, taking the V1.3 version function points "cycle triggering" and "blockage detection and removal" in the conveyor line control example as background, a resource configuration description is generated for the joint testing scenario of the boundary use case "completion feedback exactly at 1000ms".

[0090] First, for the computing node CN1, record its processing capacity as the maximum throughput of periodic tasks, scheduling granularity of 1ms, maximum concurrent test sessions of 3, license quota of 2, and peripheral bandwidth limit as a predetermined value; for the conveyor controller PLC1, record its interface DI / DO occupancy granularity, minimum command execution cycle, and maximum status feedback delay; for the photoelectric sensor PS1, record its sampling period and adjustable range of debouncing parameters; and for the alarm light AL1, record its exclusive output port and minimum hold time. Register the dependency relationship CN1→PLC1→PS1→AL1 as a control link dependency graph.

[0091] Furthermore, the downstream conveyor control port of PLC1 and other test sessions on the same line are included in the mutual exclusion set M1, with the mode being exclusive; the sampling configuration port of PS1 is included in the mutual exclusion set M2, with the mode being shared and the concurrency limit being 2; a synchronization barrier B1 is defined for the triggering relationship of "yielding signal precedes completion feedback", with the preceding event being the rising edge of the yielding signal and the subsequent event being the arrival of completion feedback, and the allowed jitter time window being 20ms; a synchronization barrier B2 is defined for the "downstream pause mutual exclusion window", with the preceding event being the downstream pause taking effect and the subsequent event being the upstream beat trigger, and the time window being [800ms, 1200ms].

[0092] Furthermore, the resource requirements of boundary use cases are mapped to instances CN1, PLC1, PS1, and AL1. The occupancy intervals are set as follows: CN1 is locked from the start of the session until the assertion is completed and then released; PLC1 is locked 50ms before the input sequence is issued until 100ms after the feedback confirmation is completed and then released; PS1 is locked from the setting of sampling parameters until the data acquisition is completed; AL1 is exclusively occupied only when the congestion detection path is triggered. Concurrency and quota allocation are as follows: CN1 consumes 1 session concurrency and 1 license quota; PLC1 is exclusively occupied within M1 and queues other sessions on the same line; PS1 occupies 1 shared concurrency within M2. Cooldown times are set as follows: PLC1 requires 200ms to cool down after release; PS1 requires 100ms to stabilize after the debouncing parameters are changed. Priority binding attaches the current priority of the use case to the CN1 lock request and the M1 / M2 arbitration sequence, ensuring that high-priority use cases obtain resources first.

[0093] Furthermore, a mutual exclusion consistency check is performed to verify that there are no concurrent conflicts for M1 and that M2 does not exceed the concurrency limit within the same time window; the triggering order and time window configuration of B1 and B2 are checked to ensure they are consistent with the unified time base, and the priority relationship of the yielding signal is not disrupted by other barriers; a quota feasibility check is performed to confirm that the CN1 license quota is sufficient and the session concurrency does not exceed the limit; a dependency feasibility check is performed to ensure that there are no loop waiting or deadlock risks in the CN1→PLC1→PS1→AL1 link within the occupied interval; and an overlap analysis is performed on the cooldown time and the occupied interval to avoid mutual time constraints between release and re-application.

[0094] Furthermore, the verified configurations are summarized into a resource configuration description, including instance identifier, occupied range, concurrency and quota allocation, cooldown time, priority binding, and barrier set {B1, B2}. This description is associated with the unique use case identifier UC_V1.3_Edge1000 and the version change identifier V1.3, and output for the scheduling execution module to reference; at the same time, the source element entries and mutual exclusion set fingerprints are recorded for auditing and regression reuse.

[0095] This embodiment completes constraint modeling of capacity, mutual exclusion and synchronization under a unified time base, and generates verifiable resource configuration descriptions by binding occupancy intervals, concurrency and quotas, and cooldown time and priority. This embodiment provides a pre-guarantee for the executability and synchronization consistency of cross-device joint test cases, and supports the stable operation of subsequent scheduling and online rescheduling.

[0096] In some embodiments, the scheduling execution module is used to: Determine the executable use cases and their start and end times based on the use case priority and resource configuration description, establish the corresponding execution sessions and bind them to a unified time base; Request a lease and lock the resource instances involved in the execution session until the release conditions are met; Trigger the input sequence, assertion script, and data acquisition instructions according to the synchronization barrier and time window parameters in the resource configuration description; When a resource conflict or node failure event is detected, online rescheduling is performed based on the use case priority and resource configuration description.

[0097] Specifically, this embodiment revolves around a closed loop of "executable use case selection → execution session establishment and unified time base binding → resource lease and locking → barrier-driven triggering and observation → online rescheduling → release and write-back". The scheduling execution module takes an ordered use case queue and resource configuration description as input and outputs the execution session and its status record.

[0098] The innovative technical features and technical terms involved in this embodiment are explained below: Executable test cases and start / end times are determined as follows: Read the ordered test case queue on a unified timeline, and assign the earliest feasible start time and expected end time to each candidate test case according to the use case priority based on the occupied interval, cooldown time and concurrency limit in the resource configuration description, and remove slices that conflict with the mutual exclusion set.

[0099] Execution Session and Unified Time Base: An execution session is established for the selected use cases, recording the session identifier, start and end times, associated input sequences, assertion scripts and data acquisition instructions, and binding it to the system's unified time base for cross-device synchronization and timing determination.

[0100] Resource leases and locking: Apply for leases and lock the relevant computing nodes and device instances according to the resource configuration description. The lease includes the occupancy range, priority binding, quota indication and release conditions. The lock is released only when the release conditions are met.

[0101] Barrier and time window triggering: Based on the synchronization barrier and time window parameters, the triggering order of the input sequence, the judgment time of the assertion script, and the sampling rhythm of the data acquisition command are organized, and all triggers are aligned under a unified time base.

[0102] Online rescheduling: When the monitoring and diagnosis module reports resource conflicts or node failure events, the scheduling execution module performs partial rolling rescheduling based on the use case priority and resource configuration description, including session migration, occupied interval shifting and backup resource switching.

[0103] Release and Writeback: After the session is completed, resources are unlocked according to the release conditions, and the session timestamp, resource usage records, and synchronization barrier achievement status are written back for subsequent priority fine-tuning and regression testing.

[0104] For example, taking the boundary use case "Completion feedback exactly at 1000ms" in conveyor line control V1.3 as an example, the resources involved are computing node CN1, controller PLC1, photoelectric sensor PS1 and alarm light AL1. The synchronization barriers include B1 "Give way before completion feedback, jitter ≤ 20ms" and B2 "Downstream pause before upstream cycle trigger, time window [800ms, 1200ms]".

[0105] Executable use case selection and start / end time determination: The scheduling execution module reads the ordered use case queue and arranges the boundary use case and the "blockage relief and new condition use case" on the timeline. According to the resource configuration description, PLC1 belongs to the mutually exclusive set M1 and is exclusively used, and downstream use cases on the same line need to be queued; PS1 belongs to the shared set M2 with a concurrency limit of 2. Without violating M1 and M2, the module assigns a start time T0 to the boundary use case and predicts an end time T0+Tcase, where Tcase is determined by the input sequence length, the barrier time window, and the assertion decision cutoff.

[0106] Session establishment and unified time base binding: Establish session SID_Edge1000, associate input sequence "start / stop = on → simulate no data for 500ms → trigger beat", assertion script "completion feedback ≤ 1000ms, yield before completion feedback", data acquisition command "acquire start / stop, photoelectric, yield, completion feedback, alarm light", and bind unified time base UTCRef for subsequent barrier alignment and evidence timestamp generation.

[0107] Resource leasing and locking: A lease request is initiated and locked for PLC1 within T0-50ms, and the lock is released 100ms after the feedback confirmation is completed; CN1 is locked from the start of the session until the assertion is completed; PS1 is locked after the sampling parameters are set and released when data acquisition ends; AL1 is locked only briefly when a blocking path is triggered. If M1 is already occupied by another session, the module is bound according to priority, allowing boundary use cases to acquire the lock first, and the start time of other sessions is shifted to after their cooldown time.

[0108] Barrier-driven triggering and observation: At T0, the input sequence is triggered according to the resource configuration description. The first synchronization barrier B2 requires "downstream pause to take effect" before "upstream clock trigger". The scheduling execution module first issues a pause command under a unified time base and waits for confirmation before triggering clock start. Subsequently, according to the constraint B1 "yielding precedes completion feedback", the module performs alignment judgment on the rising edge of the yielding signal and the arrival of the completion feedback, allowing jitter not to exceed 20ms. The data acquisition command collects signal changes at a high sampling rate before and after key points. All sampling points and trigger and assertion timestamps are strictly recorded under UTCRef.

[0109] Online rescheduling processing: If CN1 health check fails or PLC1 detects contention on M1 during execution, the module generates an event E_conflict or E_fail and initiates online rescheduling. For E_conflict, the module shifts the start time of the contention session and inserts a cooldown period without changing the barrier constraints of the boundary use cases. For E_fail, if the CN1 failure is migratable, the session SID_Edge1000 is rebuilt on the standby compute node CN2, and the session context and completed triggers and evidence are copied. If PLC1 is temporarily unavailable, the session state is frozen at a safe point before the barrier, and the trigger is delayed according to the reserved parameters in the resource configuration description until PLC1 recovers and the time windows of B1 and B2 are not violated. Migration or delay requires re-verification of the mutual exclusion set and quota to ensure no deadlock risk.

[0110] Session Convergence and Release: After all assertion script checks are completed, the module releases the locks on PS1 and AL1 according to the release conditions, records the release time and cooldown time interval of PLC1, and closes the session on CN1. The module writes back the session start and end times, barrier achievement status, resource usage trajectory, and key timestamps under a unified time base to the evidence and audit logs, and feeds back resource usage conflicts and waiting segments to the resource modeling module for subsequent queue fine-tuning.

[0111] In some examples, if the prerequisite event cannot be met within the barrier time window, the module immediately stops subsequent triggering and marks the session as unachievable, releases resource locks that are no longer needed, and retains the minimum evidence set; if the delay in the collection instruction causes an evidence gap, the module triggers a supplementary collection window without changing the behavior sequence and marks the collection offset.

[0112] This embodiment uses barriers and time windows to drive input, assertions, and data collection under a unified time base. Combined with lease locking and online rescheduling strategies, the scheduling execution module enables executable arrangement, conflict resolution, and fault migration of cross-device joint test cases, forming a reusable execution session and a complete temporal evidence chain, ensuring that test cases are implemented in an orderly manner according to priority and constraints.

[0113] In some embodiments, the monitoring and diagnostic module is used for: Under a unified time base, logs, variables, and device status are time-aligned and correlated to form a multi-source observation sequence; Based on the baseline model trained through use cases and stable operating samples, deviations are determined for the amplitude distribution, correlation, and time lag interval of multi-source observation sequences; The assertion script is mapped to a timing determiner with finite state automata and time window constraints, and the triggering order, mutual exclusion and synchronization conditions are determined online. For the identified violations or anomalies, timestamped evidence fragments and context parameter sets are generated, and the location is pinpointed to the function point and parameter range. The location results are then used by the test case generation module and the resource modeling module.

[0114] Specifically, this embodiment implements monitoring and diagnosis through a closed loop: "time alignment and correlation → baseline determination → time sequence determination → evidence generation and location → result feedback." First, logs, variables, and device status are aligned and cross-source correlations are established under a unified time base, forming a multi-source observation sequence. Then, based on a baseline model trained with use cases and stable operating samples, deviations in amplitude distribution, correlation, and time lag intervals are determined. Subsequently, assertion scripts are mapped to finite state automata with time window constraints to determine trigger order, mutual exclusion, and synchronization conditions online. For determined violations or anomalies, timestamped evidence fragments and context parameter sets are generated, and the location is pinpointed to the function point and parameter range. The location results are then used by the use case generation module and resource modeling module.

[0115] The innovative technical features and technical terms involved in this embodiment are explained below: Unified time base and cross-source association: Align log entries, control variable sampling, device status events and environmental quantity sampling with a unified time base; establish cross-source association through session identifier, device instance identifier and use case identifier to ensure that observations from different sources can be compared on the same time axis.

[0116] Baseline Model: A joint statistical and time-series baseline constructed using use cases and stable operating samples. It records the amplitude range of variables, the correlation between variables, the time-delay distribution of events and feedback and their confidence intervals, and provides a gradually changing adaptive update strategy.

[0117] Finite state automata and time window constraints: The sequential relationships, mutual exclusion relationships and synchronization constraints in the assertion script are formalized into state transitions and time windows, and the online consumption event flow is used for judgment.

[0118] Evidence fragments and context parameter set: Evidence fragments include start and end times, triggering events, state transitions, and key variable trajectories; context parameter set includes session information, resource instance usage, barrier achievement status, and version change identifiers, etc.

[0119] For example, taking the boundary use case "Completion feedback exactly 1000 milliseconds" in version V1.3 of the conveyor line control example as the background, the functional points involved include "tap trigger", "yield confirmation", "completion feedback" and "blockage detection and removal", and the observed objects include start and stop commands, photoelectric sensor quantities, yield signals, completion feedback, alarm light status and downstream pause status.

[0120] Time Alignment and Correlation: The monitoring and diagnostic module receives a unified time base at the start of the session and establishes an observation channel for this session, aligning log entries, variable sampling, and device status events at the millisecond level. Events such as "Start / Stop = On", "No Feed for 500 Milliseconds", "Tick Trigger", "Downstream Pause", "Yield Rising Edge", and "Completion Feedback Arrival" are written into the multi-source observation sequence in a time-ordered manner and correlated with the session identifier and use case identifier.

[0121] Baseline determination: Based on stable operating samples, the baseline model records that the common jitter range of "continuous no-feed" is ±20 milliseconds, and the time lag of "yielding to completion feedback" is distributed in the interval [100 milliseconds, 300 milliseconds] with a high correlation coefficient. The monitoring and diagnosis module examines the amplitude distribution of this observation and its correlation with the variables, and at the same time, compares the causal time lag of "downstream pause and upstream beat trigger". If the observation falls outside the baseline confidence interval, it is marked as a deviation candidate.

[0122] Timing determination: The assertion script is mapped to an automaton and time window constraints, including assertion A1 "Completion feedback no later than 1000 milliseconds", assertion A2 "Give way before completion feedback and jitter no more than 20 milliseconds", and assertion A3 "Downstream pause before tick trigger and time window in [800 milliseconds, 1200 milliseconds]". During online determination, the automaton opens the A2 time window after detecting the "give way rising edge" and closes it when "completion feedback arrives" and calculates the difference between the two; simultaneously, it opens the A3 time window after detecting "downstream pause takes effect" and closes it for verification when "tick triggers". For A1, the timing window opens when "tick triggers" and closes when "completion feedback arrives".

[0123] Violation and Anomaly Identification: When the "Completion Feedback" is observed to arrive around 1000 milliseconds but the interval between it and the "Yielding Rising Edge" is 25 milliseconds, exceeding the A2 allowable jitter threshold of 20 milliseconds, the module will determine A2 as a violation; if the interval between "Downstream Pause" and "Tap Trigger" is 780 milliseconds, which is lower than the A3 lower bound of 800 milliseconds, then A3 will also be determined as a violation; if "Variable Correlation" and "Yielding to Completion Feedback Lag" fall within the baseline confidence interval, then A1 can still be satisfied.

[0124] Evidence Generation and Location: Evidence fragments are generated for violations A2 and A3 respectively, recording start and end times, event names, sequence differences or time windows, relevant variable trajectories, and log excerpts. A set of contextual parameters is also summarized, including resource instance usage in the current session, barrier achievement status, and version change identifiers. The location algorithm, based on the mapping relationship between function points and parameter intervals, locates violation A2 to the time-series parameter interval of the function point "yielding confirmation," and violation A3 to the parameter interval of the "downstream pause window," providing corresponding upper and lower bounds for the parameters and references to neighboring elements.

[0125] Results Feedback: The monitoring and diagnosis module sends the location results and evidence index back to the use case generation module and the resource modeling module. Based on this, the use case generation module adds boundary use cases related to "yielding to jitter boundary" and "pause window lower bound" in subsequent rounds; the resource modeling module adjusts the synchronization barrier configuration and time window parameters accordingly, and reserves a larger alignment buffer for related use cases in resource mutual exclusion arbitration.

[0126] In some examples, when a short-term sample loss occurs in the observation channel, the monitoring and diagnosis module prioritizes using redundant logs from the same source to fill in the gap; if a critical event is missing and cannot be filled in, the corresponding assertion is marked as "cannot be determined" and the minimum set of evidence and the gap location are output.

[0127] This embodiment aligns and correlates multi-source observations under a unified time base, and uses a baseline model and a finite state automaton with a time window for joint determination. The monitoring and diagnosis module can determine the triggering order, mutual exclusion and synchronization conditions online, generate traceable time-series evidence and accurately locate the function point and parameter range, supporting the closed-loop update of use case generation and resource modeling.

[0128] In some embodiments, a time-series prediction model is established based on historical operation and environmental data, and the time-series prediction model is used to generate risk scores for function points and resource windows, including: Under a unified time base, historical test data, operational data, and environmental data are aligned and aggregated according to version change identifiers to form a time-series sample set containing function point identifiers and resource consumption characteristics; A sliding window is used to construct the input sequence and the forward interval label to train the time series prediction model. Risk scores are calculated for target function points and resource windows based on a time-series prediction model, and the risk scores are then associated with version change identifiers, function points, and resource windows.

[0129] Specifically, this embodiment revolves around a closed loop of "time series sample construction → sliding window modeling → time series prediction model training → risk score calculation and association". Based on a unified time base, it aligns and aggregates historical test data, operational data and environmental data, trains the time series prediction model and outputs risk scores on given function points and resource windows. Finally, it establishes an association between the risk scores and version change identifiers, function points and resource windows, providing quantitative input for priority correction and resource reservation.

[0130] First, in some examples, the time-series sample construction process includes the following: Data sources and a unified time base: assertion results and key timestamps from historical tests, variable trajectories obtained from runtime sampling (such as start / stop signals, photoelectric sensor quantities, yield signals, and completion feedback), resource usage records (compute node concurrency, license quota usage, and mutual exclusion set occupancy), and environmental quantities (temperature, humidity, and equipment load). All data is aligned to a unified time base to ensure that cross-source events and sampling points are compared on the same time axis.

[0131] Version change alignment and labeling: The samples are binned by version change identifier, and the same functional points in versions V1.2, V1.3 and other versions are mapped. In V1.3, the newly added element "blockage release condition is 1000ms of continuous no material from the sensor" is labeled.

[0132] Feature Extraction and Normalization: For the conveyor line example, extracted features include: load (number of cycles per unit time), completion feedback delay distribution statistics (quantiles, variance), correlation between variables (yielding—cross-correlation peak and lag of completion feedback), mutual exclusion occupancy ratio (duration of mutual exclusion set occupancy / window duration), concurrency, license quota utilization rate, temperature and humidity trajectories, sensor jitter counts, etc. Continuous features are scaled across intervals, count-type features are logarithmically transformed, and category features (version, equipment configuration) are embedded and encoded.

[0133] Sample Labels and Task Definitions: This embodiment employs two types of forward-looking tasks: (i) temporal metric overthreshold prediction, such as whether "completion feedback ≤ 1000ms" is likely to exceed the threshold within the future ΔT; and (ii) event risk regression, such as the probability value of assertion violation within the future ΔT. This results in a binary / regression hybrid label for joint training or multi-head training.

[0134] Furthermore, in some examples, the sliding window modeling process includes the following: Input window and lookout interval: Set the input window length W_in and the lookout interval W_out, such as W_in=60s and W_out=10s, and generate samples by sliding across the entire historical sequence with a step size s. Each sample contains the feature trajectory within the past W_in and the label for the future W_out.

[0135] Resource window slicing: Resource occupancy records are sliced ​​according to resource windows, such as "downstream pause mutual exclusion window", "high temperature and high humidity interval", and "high load interval". The current window type and position index are attached to each sample to facilitate the model to learn scene sensitivity.

[0136] Furthermore, in some examples, the training process for time-series prediction models includes the following: First, the model structure: It adopts a structure of temporal encoder-fusion layer-multiple output. The encoder can be a long short-term memory network or a one-dimensional convolutional temporal network; the resource and environment branches are encoded separately and then concatenated in the fusion layer; output head A is used for binary classification (whether the limit is exceeded), and output head B is used for risk regression (violation probability or degree of time delay exceeding the threshold).

[0137] Next, training and validation: a cross-version leave-to-be-validated strategy is used, for example, using V1.2 as the main training set and early V1.3 data as validation data, to prevent leakage and improve generalization. The loss is a weighted sum: binary classification cross-entropy + regression mean squared error; hard example mining or weight balancing is used for scenarios with extremely imbalanced classes.

[0138] Then, calibration and stabilization: temperature scaling calibration is performed on the output probabilities to ensure consistent probabilistic interpretation of the model under different resource windows; slowly adaptive updates are applied to drift features (environmental quantities), and normalized parameters are periodically re-estimated.

[0139] Furthermore, in some examples, the risk score calculation and association process includes the following: Inference and aggregation: Perform rolling inference on the target function point and resource window to obtain a risk output at the moment level. Aggregate the maximum or quantile of the risks within the window to obtain a window-level risk score R ∈ [0, 1].

[0140] Explanatory variables and profiling: Attach a key contribution feature profile to R, such as "the upward distribution of the completion feedback lag", "high mutual exclusion occupancy ratio", "the increase in sensor jitter accompanied by the increase in temperature", for subsequent strategy use.

[0141] Association registration: Establish an association record for <R, version change identifier, function point, resource window, time range> and write it into the metadata: model version fingerprint, training time, calibration parameters, input window and forward-looking interval configuration, for auditing and playback.

[0142] For example, take the function point "beat trigger / completion feedback" and the resource window "high temperature and high humidity + high load" as an example: Collect case and operation data from V1.2 and V1.3, align them according to a unified time base, and form a feature sequence including "completion feedback delay statistics", "yield-completion feedback cross-correlation lag", "downstream mutual exclusion occupancy ratio", "PS1 jitter count", "temperature and humidity trajectory".

[0143] Construct samples with W_in = 60s and W_out = 10s. Define the binary classification label as "whether the completion feedback exceeds the 1000ms threshold within the next 10s", and define the regression label as "the probability of the completion feedback delay exceeding the threshold within the next 10s".

[0144] After training, perform inference on the target window to obtain a window-level R = 0.72, and the profile shows that "mutual exclusion occupancy ratio ↑, temperature and humidity ↑, jitter count ↑" are the main contributing factors.

[0145] Establish an association between R and the version change identifier V1.3, the function point "beat trigger / completion feedback", and the resource window "high temperature and high humidity + high load [T1, T2]", and register the model fingerprint and calibration coefficient.

[0146] Before scheduling execution, the priority model receives R and maps it to a case priority correction amount; the resource modeling module receives the resource redundancy coefficient mapped by R and adjusts the concurrency limit, standby nodes, and synchronization time window buffer; the case generation module increases the generation density of boundary cases and perturbation cases according to R.

[0147] This embodiment achieves pre-quantitative characterization of high-risk scenarios by aligning and aggregating cross-source historical data under a unified time base, training a time series prediction model with a sliding window, and outputting risk scores oriented towards function points and resource windows. It supports the linkage control of priority correction and resource reservation, and enhances the coverage and programmability of boundary and abnormal scenarios.

[0148] In some embodiments, adjusting use case priority and resource reservation parameters based on risk scores includes: The risk score is mapped to the use case priority adjustment amount and resource redundancy coefficient, and the use cases associated with the function points are promoted in the ranking and the boundary and disturbance use cases are supplemented. In the resource configuration description, resource reservation parameters are set according to the resource redundancy coefficient. The adjusted ordered use case queue and resource configuration description are submitted to the scheduling execution module for rolling reordering, and the adjustment record is associated with the version change identifier.

[0149] Specifically, this embodiment implements dynamic adjustment based on risk scores through a closed loop of "risk score access → priority correction → resource redundancy configuration → rolling reordering → association and auditing". The input is the risk score R∈[0,1] and its profile information output by the aforementioned time series prediction model, and the output is the corrected ordered use case queue and the updated resource configuration description, which are associated with the version change identifier.

[0150] First, in some examples, the mapping strategy and parametric design process include the following: Use case priority adjustment ΔP: Define a monotonic mapping ΔP = f1(R, importance, change impact score, execution cost), which satisfies that ΔP does not decrease as R increases, and provides weighted amplification for use cases with high importance and high change impact score. Set a saturation upper limit to avoid queue oscillation.

[0151] Resource redundancy coefficient κ: Defined as κ = f2(R, resource window type, mutual exclusion ratio, license quota remaining). κ is increased when R increases or the mutual exclusion ratio is high. It is mapped to the increment of concurrency limit buffer, standby node activation, license quota retention, cooldown time and synchronization time window buffer.

[0152] Atomic updates and consistency: Priority and resource configuration updates are committed in a transactional manner to ensure the consistency of queue order and resource parameters; adjustments are applied to sessions in execution only at safe points before barriers to avoid disrupting critical timing.

[0153] Furthermore, in some examples, the implementation of the conveyor line example includes the following: The scenario continues from the aforementioned V1.3 version. The risk score R of the "beat trigger / completion feedback" function point under the resource window "high temperature and high humidity + high load" is 0.72, and the profile shows the mutual exclusion occupancy ratio and sensor jitter uplink.

[0154] For the test case set U = {boundary test cases (completion feedback exactly 1000ms), exception test cases (yielding to feedback later than completion), and concurrent boundary test cases (downstream pause window overlaps with upstream tick trigger)} of the associated functional points, ΔP is calculated. Because both the functional importance and change impact scores are high, the system applies an amplified weight to R = 0.72, resulting in ΔP higher than the normal threshold. After the update, test cases within U are moved forward, and two types of test cases are automatically added for gap scenarios: (1) Boundary encryption use case: Generate assertion window combinations with fine-grained steps (e.g., 995ms, 1000ms, 1005ms) near the latency threshold; (2) Disturbance coupling use case: Insert a short jitter sequence during the 500ms period of no material, and combine it with the 50ms yield delay and the lower bound of the downstream pause window.

[0155] κ is calculated for the resource window under the conditions of "high temperature and high humidity + high load". Considering the high mutual exclusion occupancy ratio and license remaining capacity, κ > 1. Based on κ, the following incremental settings are made to the resource configuration description: (1) Concurrency limit buffer: Temporarily reduce the concurrency limit of the shared set M2 (sensor sampling configuration port) to reduce mutual interference; (2) Enable standby node: Configure CN2 as a hot standby for compute node CN1, mirror the execution session context, and quickly switch over when CN1’s health signal is abnormal; (3) License quota reservation: Reserve at least one license quota for boundary and disturbance use cases to ensure the immediate triggering of assertions and collection scripts; (4) Extended cooling time: The cooling time after PLC1 release is temporarily increased from 200ms to 300ms to ensure sufficient state reset; (5) Synchronization time window buffer: Without changing the assertion logic, the scheduling buffer for synchronization barrier B2 (downstream pause is triggered before the beat) is increased to reduce the jitter caused by resource contention in front of the barrier.

[0156] The system generates a revised ordered queue of test cases Q′ and an updated resource configuration description RCD′. In Q′, boundary and disturbance test cases are moved forward, while ordinary regression test cases are moved backward accordingly; in RCD′, the concurrency, quota, cooling, standby, and barrier buffer parameters all reflect the increment of κ.

[0157] Furthermore, in some examples, the scroll reflow and activation control process includes the following: Triggering and Scope: After Q′ and RCD′ are generated, the scheduling execution module enters rolling reordering: for sessions that have not yet started, the new order and new parameters are directly adopted; for sessions that are in progress, the new resource buffering and synchronization strategy is applied only when they reach the safe point before the barrier; for sessions where the critical barrier has been opened, the original strategy is maintained until the barrier is closed.

[0158] Migration and rollback: If the CN1 health signal fluctuates, the session will be migrated to CN2 in real time according to RCD′, and the session context and evidence cache will be copied; if the migration fails, the session will be rolled back to the old queue and old resource parameters, and the reason for failure and timestamp will be recorded.

[0159] Consistency check: Before each re-arrangement commit, mutual exclusion consistency and quota feasibility checks are performed to ensure that M1 exclusive access does not conflict, M2 concurrency does not exceed the limit, license balance is non-negative, and cooling-off and occupied intervals do not overlap.

[0160] Furthermore, the system will associate the adjusted mapping parameters <ΔP,κ>, the effective Q′ and RCD′, the trigger time, the applicable resource window, the model fingerprint, and the version change identifier V1.3, and record them in the audit metadata. At the same time, the preceding use cases and the corresponding boundary / disturbance generation basis will be written back to the use case generation module to form a traceable link.

[0161] Furthermore, if the additional boundary or disturbance use cases cause the queue length to be too large and exceed the time window capacity, the system will roll back the low-importance use cases to the next time window according to their importance and ΔP; if the license quota is insufficient, the boundary and disturbance use cases will be prioritized, and the ordinary use cases will be delayed and their queuing order will be preserved.

[0162] This embodiment quantifies and maps risk scores into priority correction amounts and resource redundancy coefficients, and updates them in a transactional manner with queues and resource parameters. This embodiment achieves the pre-positioning of key use cases and the elastic reservation of resources within high-risk windows, while taking into account the consistency between executability verification and online reordering, ensuring that boundary and abnormal scenarios are verified first under controlled resource conditions.

[0163] Through the technical solutions provided in the above embodiments of this application, this application has at least the following advantages: Improve testing efficiency: Through automatic test case generation and intelligent test task scheduling, the time spent on manual test case design and execution is greatly reduced, test resources are fully utilized for parallel testing, and the testing cycle of industrial automation software is significantly shortened.

[0164] Enhanced test comprehensiveness: AI tools can generate more diverse and comprehensive test cases, covering edge scenarios and complex operating conditions that are difficult to reach by traditional testing methods, thereby improving the coverage of software testing and reducing the risks after software goes live.

[0165] Real-time monitoring and rapid diagnosis: The real-time monitoring and analysis module during the testing process can detect problems in the software operation in real time and quickly diagnose and locate them, helping testers to solve problems in a timely manner and reducing the time cost of troubleshooting.

[0166] Preventing potential problems: The potential problem prediction module learns and analyzes historical data to predict potential software problems in advance, providing enterprises with the opportunity to take preventive measures and avoid industrial production interruptions and losses caused by software failures.

[0167] The above embodiments have described in detail the specific modules and functions of the artificial intelligence-based industrial automation software testing system of this application. The implementation process of the artificial intelligence-based industrial automation software testing method of this application will be described in detail below with reference to specific embodiments. Figure 2 This is a flowchart illustrating the artificial intelligence-based industrial automation software testing method provided in this application embodiment, as shown below. Figure 2 As shown, this AI-based industrial automation software testing method may specifically include the following steps: S201 performs semantic parsing on requirements and design documents to obtain a set of structured elements and associates them with version change identifiers; S202, based on the structured element set and historical use cases and execution records, generates a set of use cases containing input sequences, assertion scripts, data acquisition instructions and timing, and concurrency constraints; S203, establish a priority model and generate use case priorities, establish capability, mutual exclusion and synchronization constraint models for computing nodes and devices, form a resource configuration description corresponding to the use case set and output an ordered use case queue; S204 schedules and orchestrates according to the ordered use case queue and resource configuration description, establishes an execution session and binds it to a unified time base, locks the resource instances involved, triggers the input sequence, assertion script and data acquisition instructions according to the synchronization barrier and time window, and implements online rescheduling in the event of conflict or failure. S205 collects logs, variables and device status under a unified time base, identifies assertion violations and timing anomalies based on the baseline model and timing determiner, and locates them to function points and parameter ranges. The location results are used to update the use case set and resource configuration description. S206 aligns and aggregates historical test data, runtime data, and environmental data under a unified time base, trains a time-series prediction model, generates risk scores for function points and resource windows, and adjusts test case priorities and resource reservation parameters based on the risk scores.

[0168] Specifically, S201 semantic parsing and version association 1) Preprocessing and document structure identification: The requirements and design documents are coded uniformly, formatted properly, and noise is removed. The heading levels and numbering system are parsed to generate a document tree. Each node records the level number, heading, paragraph range, and reference anchor point for subsequent element backtracking.

[0169] 2) Terminology disambiguation and entity standardization: Based on the domain dictionary and rule base, function points, parameter items, device objects and interface identifiers are uniformly named, and synonyms and aliases are mapped to unique identifiers; units are standardized (such as ms, ℃) and converted to a unified time base.

[0170] 3) Semantic element extraction: Combining syntactic dependency and semantic role labeling, input and output constraints, state transition descriptions, timing and concurrency constraints, device linkage relationships and triggering conditions are extracted to form a structured set of elements.

[0171] 4) Version Change Association: Establish a mapping between the addition / modification / deletion of elements and historical versions based on the version change identifier, and output the input item placeholders for use case generation (input sequence placeholder, assertion script placeholder, data collection instruction placeholder, timing concurrency constraint placeholder, resource requirement placeholder) and their source chapter paths.

[0172] S202 combines historical data to generate a set of use cases. 1) Historical Mapping and Reuse: Based on the version change identifier, historical use cases and execution records are mapped to the structured element set of S201, and input sequence placeholders, assertion script placeholders and data acquisition instruction placeholders are reused based on the similarity between function points and parameter domains.

[0173] 2) Boundary and Exception Expansion: Boundary parameters and concurrent timing characteristics are extracted from execution records and solidified into rules and perturbation scripts; an adversarial sample generation mechanism is adopted to construct candidate test cases based on parameter upper / lower bounds, mutual exclusion concurrency and synchronization order, and filter out unexecutable samples.

[0174] 3) Consistency verification and registration: Perform executability verification (parameter range, trigger reachability) and resource synchronization consistency verification (mutual exclusion set, synchronization barrier, occupied range) on the generated test cases. The qualified ones are registered as test case sets and bound to the version change identifier. Output instantiable input sequences, assertion scripts, data acquisition instructions and timing concurrency constraints.

[0175] S203 Priority Modeling and Resource Allocation Description Generation 1) Priority model establishment: The initial use case priority is synthesized by normalizing and weighting the factors of functional importance, change impact score and execution cost; risk scoring is reserved and entry point is set.

[0176] 2) Resource Capability and Constraint Modeling: Establish resource capability descriptions for computing nodes and devices (processing capacity, interface / peripheral usage granularity, license quota, dependency relationships, trigger latency limit, cooldown time), define mutual exclusion sets and sharing modes, concurrency limits, synchronization barriers and time window parameters, and bind all of them to a unified time base.

[0177] 3) Resource mapping and parameterization: Map the resource requirements of the use cases to specific resource instances, and give the occupancy range, concurrency and quota allocation, cooldown time and priority binding, to initially form a resource configuration description.

[0178] 4) Feasibility verification and queue output: Perform mutual exclusion consistency and quota feasibility verification on the resource configuration description, and output an ordered queue of test cases based on the test cases that pass the verification and their priorities, as input to S204.

[0179] S204 Scheduling and Execution, Unified Time Base Binding and Online Rescheduling 1) Executable use case selection and session establishment: Based on the ordered use case queue and resource configuration description, calculate the earliest feasible start and end time of each use case, establish an execution session and bind a unified time base, and associate the input sequence, assertion script and data acquisition instructions.

[0180] 2) Lease and Lock: Request a lease and lock the resource instance involved in the session. The lease record includes the occupied range, quota and release conditions. If there is a mutual exclusion conflict, it will be queued or moved according to priority and cooldown time rules.

[0181] 3) Barrier-driven triggering and observation: The input sequence is triggered according to the synchronous barrier and time window parameters. At key time points, the assertion script is started to determine and execute the data acquisition command. All triggers and sampling are aligned with a unified time base to generate a time-series event stream.

[0182] 4) Online rescheduling: When the monitoring and diagnosis module reports resource conflicts or node failures, a partial rolling rescheduling is performed, including session migration, shifting of occupied intervals and switching of backup resources. After recalibrating mutual exclusion and quotas, execution continues; the original timing of key barriers that have been opened is maintained until they are closed.

[0183] S205 Monitoring, Diagnosis, Location, and Data Transmission Update 1) Time alignment and multi-source association: Under a unified time base, logs, variables and device status are aligned at the millisecond level to establish a three-dimensional association between sessions / devices / use cases and form a multi-source observation sequence.

[0184] 2) Baseline model determination: Using the baseline model trained through use cases and stable running samples, deviation determination is performed on the amplitude distribution, variable correlation and time lag interval to generate deviation candidates.

[0185] 3) Timing Determinator: Map the assertion script to a finite state automaton and time window constraints, online determine the triggering order, mutual exclusion, and synchronization condition fulfillment, and label whether the assertion is satisfied / violated and the reasons.

[0186] 4) Evidence and Location: Generate timestamped evidence fragments (events, sequence differences, key trajectories, log excerpts) and context parameter sets (session information, resource occupancy, barrier status, version change identifiers) for violations or anomalies, and locate them to specific function points and parameter intervals based on the function point - parameter interval mapping.

[0187] 5) Result Feedback: Feedback the location results and evidence indexes to the test case generation module and resource modeling module for supplementing boundary / disturbance test cases and adjusting synchronization barriers or time window parameters, and at the same time precipitate them as one of the data sources for S206 training.

[0188] S206 Timing Prediction and Risk - Driven Closed - Loop Correction 1) Data Alignment and Sample Construction: Align and aggregate historical test data, running data, and environmental data according to version change identifiers under a unified time base, extract features such as load, completion feedback delay statistics, mutual exclusion occupancy ratio, sensor jitter count, temperature and humidity, etc., and construct a timing sample set containing function point identifiers and resource window labels.

[0189] 2) Sliding Window Training: Construct samples with an input window W_in and a forward - looking interval W_out, and use long short - term memory networks or convolutional timing networks for training. The multi - head output simultaneously regresses the violation probability and the degree of delay exceeding the threshold, and performs probability calibration.

[0190] 3) Risk Score Output and Association: Roll - infer and quantile - aggregate the risk score R for the target function point and resource window, establish an association of <R, version change identifier, function point, resource window, time range>, and attach a key contribution feature profile and model fingerprint.

[0191] 4) Correction Based on R: Map R to the test case priority correction amount ΔP and resource redundancy coefficient κ, synchronously update the ordered test case queue and resource configuration description (concurrency upper - limit buffer, standby node activation, quota reservation, cooling time, and synchronization time window buffer), and perform rolling re - orchestration by the scheduling execution module; all adjustment records and version change identifiers form an audit link.

[0192] For example, in the conveyor line example scenario, version V1.3 adds "blockage release condition = sensor continuously without material for 1000ms". S201 identifies and categorizes the data into a structured set of elements; S202 reuses input and assertion placeholders based on the V1.2 use cases, and generates use cases for "Completion Feedback 1000ms Boundary", "Delayed Yielding", and "Lower Boundary of Pause Window" using a perturbation script; S203 sets the priority of the relevant use cases to high and generates a resource configuration description for PLC mutual exclusion and PS shared concurrency; S204 drives execution with barriers B1 "Yielding before Completion Feedback (Jitter ≤ 20ms)" and B2 "Downstream Pause before Tick Trigger (Window [800ms, 1200ms])", migrating to a backup computing node in case of failure; S205 if A2 or A3 is detected as a violation, it locates the "Yielding Confirmation Timing Parameter Range" or "Downstream Pause Window Parameter Range" and sends back the rule update; S206 outputs R=0.72 in the "High Temperature and High Humidity + High Load" resource window, and the system improves the ranking of relevant use cases and increases resource redundancy accordingly, completing the closed-loop correction.

[0193] In some examples, when observation channels experience short-term sample loss, they are prioritized to be supplemented with redundant logs from the same source; if supplementation is not possible, the corresponding assertion is marked as "unable to determine" and the minimum set of evidence is output. When resources are severely insufficient, low-priority use cases are degraded and postponed according to importance and ΔP, while maintaining queuing order and mutual exclusion consistency.

[0194] Therefore, this embodiment integrates "semantic parsing - use case generation - priority and resource modeling - scheduling execution - monitoring and diagnosis - timing prediction and correction" into an auditable closed loop under a unified time base. The output of each step serves as a deterministic input for subsequent steps, ensuring the feasibility and reproducibility of the method in an industrial automation testing environment.

[0195] It should be understood that the sequence number of each step in the above method embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.

[0196] The above embodiments are only used to illustrate the technical solutions of this application, and are not intended to limit them. Although the technical solutions of this application have been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this application, and should all be included within the protection scope of this application.

Claims

1. An industrial automation software testing system based on artificial intelligence, characterized in that, include: The test case generation module is used to perform semantic parsing of requirements and design documents, combine historical test cases and execution records to generate a set of test cases, and generate input sequences, assertion scripts and data collection instructions associated with the test cases; The resource modeling module is used to calculate the priority of use cases based on functional importance, change impact score and execution cost, and to establish capability, mutual exclusion and synchronization constraint models for computing nodes and devices, and generate resource configuration descriptions corresponding to use cases. The scheduling and execution module is used to allocate and orchestrate test cases according to the test case priority and resource configuration description, establish a unified time base, implement resource locking and synchronous triggering, perform online rescheduling under fault or conflict events, and drive the software under test to execute the assertion script and data acquisition instructions. The monitoring and diagnosis module is used to collect logs, variables and device status during execution, identify assertion violations and timing anomalies based on the baseline model and timing determiner, locate the function points and parameter ranges, and send the location results back to the test case generation module and resource modeling module. The prediction feedforward module is used to establish a time-series prediction model based on historical operation and environmental data, generate risk scores for function points and resource windows using the time-series prediction model, and adjust the use case priority and resource reservation parameters according to the risk scores.

2. The system according to claim 1, characterized in that, The semantic parsing of requirements and design documents includes: Preprocess and identify the chapter structure of requirements and design documents, and perform term disambiguation and entity standardization based on domain dictionary and rule base to establish a unified naming for function points, parameter items, device objects and interface identifiers; Based on syntactic relations and semantic role annotations, functional points, input and output constraints, state transition descriptions, timing and concurrency constraints, and device linkage relationships are extracted to form a set of structured elements; The structured set of elements is mapped to input items for use case generation and associated with version change identifiers.

3. The system according to claim 2, characterized in that, The process of combining historical use cases and execution records to generate a use case set includes: Based on the version change identifier, a mapping is established between historical use cases, execution records, and the set of structured elements; Based on the similarity between function points and parameter domains, placeholders for input sequences, assertion scripts, and data acquisition instructions are reused. Based on the execution record sedimentation boundary parameters and concurrent timing characteristics, rules and perturbation scripts are constructed, and adversarial samples are used to generate supplementary boundaries and abnormal test cases. The generated test cases are validated for executability and resource synchronization consistency. Those that pass the validation are registered as the test case set and bound to the version change identifier.

4. The system according to claim 1, characterized in that, The calculation of use case priorities based on functional importance, change impact score, and execution cost includes: A priority model is established using the aforementioned functional importance, change impact score, and execution cost as factors to generate initial use case priorities; The risk score output by the prediction feedforward module is incorporated into the priority model to obtain the corrected use case priority; Based on the mutual exclusion set and synchronization constraints provided by the resource modeling module, the priority of the modified test cases is adjusted for feasibility, and an ordered test case queue is output.

5. The system according to claim 4, characterized in that, The process of establishing capability, mutual exclusion, and synchronization constraint models for computing nodes and devices, and generating resource configuration descriptions corresponding to use cases, includes: Establish resource capability descriptions for computing nodes and devices, and define mutual exclusion and synchronization constraints; Map the resource requirements of the use cases to specific resource instances, and provide the resource configuration description by binding the usage range, concurrency and quota allocation, cooldown time and priority. The resource configuration description is checked for mutual exclusion consistency and quota feasibility, and then associated with the use case identifier and version change identifier.

6. The system according to claim 1, characterized in that, The scheduling execution module is used for: Determine the executable use cases and their start and end times based on the use case priority and resource configuration description, establish the corresponding execution sessions and bind them to a unified time base; Request a lease and lock the resource instances involved in the execution session until the release conditions are met; The input sequence, assertion script, and data acquisition instructions are triggered according to the synchronization barrier and time window parameters in the resource configuration description. When a resource conflict or node failure event is detected, online rescheduling is performed based on the use case priority and resource configuration description.

7. The system according to claim 1, characterized in that, The monitoring and diagnostic module is used for: Under a unified time base, logs, variables, and device status are time-aligned and correlated to form a multi-source observation sequence; Based on the baseline model trained through use cases and stable operating samples, deviations are determined for the amplitude distribution, correlation, and time lag interval of the multi-source observation sequences; The assertion script is mapped to a timing determiner of a finite state automaton and time window constraints to perform online determination of triggering order, mutual exclusion and synchronization conditions; For the identified violations or anomalies, timestamped evidence fragments and context parameter sets are generated, and the location is pinpointed to the function point and parameter range. The location results are then used by the use case generation module and the resource modeling module.

8. The system according to claim 1, characterized in that, The time-series prediction model established based on historical operation and environmental data, and the risk scores generated for function points and resource windows using the time-series prediction model, include: Under a unified time base, historical test data, operational data, and environmental data are aligned and aggregated according to version change identifiers to form a time-series sample set containing function point identifiers and resource consumption characteristics; A sliding window is used to construct the input sequence and the forward interval label to train the time series prediction model. Based on the time-series prediction model, risk scores are calculated for target function points and resource windows, and the risk scores are associated with version change identifiers, function points, and resource windows.

9. The system according to claim 8, characterized in that, The adjustment of use case priority and resource reservation parameters based on the risk score includes: The risk score is mapped to the use case priority adjustment amount and resource redundancy coefficient, and the use cases associated with the function points are promoted in the ranking and the boundary and disturbance use cases are supplemented. In the resource configuration description, set the resource reservation parameters according to the resource redundancy coefficient, submit the adjusted ordered use case queue and resource configuration description to the scheduling execution module for rolling reordering, and establish a correlation between the adjustment record and the version change identifier.

10. An artificial intelligence-based industrial automation software testing method based on the system described in any one of claims 1 to 9, characterized in that, include: Semantic parsing of requirements and design documents yields a set of structured elements, which are then associated with version change identifiers. Based on the structured element set and historical use cases and execution records, a use case set containing input sequences, assertion scripts, data acquisition instructions and timing, and concurrency constraints is generated. Establish a priority model and generate use case priorities. Establish capability, mutual exclusion and synchronization constraint models for computing nodes and devices. Form a resource configuration description corresponding to the set of use cases and output an ordered use case queue. The system schedules and orchestrates according to the ordered use case queue and the resource configuration description, establishes an execution session and binds it to a unified time base, locks the resource instances involved, triggers the input sequence, assertion script and data acquisition instructions according to the synchronization barrier and time window, and implements online rescheduling in the event of conflict or failure. Logs, variables and device status are collected under a unified time base. Based on the baseline model and timing decision-maker, assertion violations and timing anomalies are identified and located to function points and parameter ranges. The location results are used to update the use case set and the resource configuration description. Under a unified time base, historical test data, runtime data, and environmental data are aligned and aggregated to train a time series prediction model, generate risk scores for function points and resource windows, and correct the use case priority and resource reservation parameters based on the risk scores.

Images