Constraint consistency training and decoding method for industrial ST code generation

Abstract

The present application belongs to the technical field of industrial automation control, and relates to a constraint consistency training and decoding method for industrial ST code generation, comprising: constructing a shared static rule library and organizing training samples in multiple views to form demand, planning, structure and code views; generating token-level risk weights for safety, interlocking, timing and type constraint fragments through a weight semantic routing gate mechanism, and constructing a constraint-sensitive training target; based on a multi-view consistency calibration mechanism, splitting the sample into planning, structure and code views, and adopting a course-based multi-objective fine-tuning to reduce hierarchical gradient interference; in the decoding stage, introducing a constraint-aware beam search mechanism to embed syntax constraints and safety semantic constraints into the beam search process, to perform real-time checking and rearrangement on the candidate prefix, and output ST code conforming to industrial control specifications. The present application reduces the omission of high-risk control constraints, and improves the automation level, interpretability and engineering usability of code generation.

Description

Technical Field

[0001] This invention belongs to the field of industrial automation control technology and relates to a constraint consistency training and decoding method for industrial ST code generation. Background Technology

[0002] In industrial control systems, Structured Text (ST) language is one of the core programming languages ​​specified in the IEC 61131-3 standard, and is widely used in the control logic development of PLCs, DCSs, and related industrial control equipment. Unlike general-purpose software code, industrial ST code typically operates directly on production processes such as motor start-stop, interlock protection, emergency stop control, sequential action switching, timed linkage, and fault alarms, and has strong requirements for real-time performance, security, and determinism. An ST program must not only meet the requirements of correct syntax and type, but also satisfy process constraints such as equipment interlocks, timing, exception priority, output mutual exclusion, and manual reset. Therefore, any local error may be amplified into downtime risk, malfunction risk, or even a safety accident.

[0003] While existing code generation methods based on large language models can achieve good results in general-purpose languages ​​such as Python and Java, they still face the following problems when directly transferred to industrial ST (Speed ​​Execution) scenarios: First, emergency stop logic, interlocking conditions, type constraints, and timing constraints in industrial control are usually low-frequency in the training corpus, and the model is prone to ignoring these sparse but high-risk key constraints during long sequence generation. Second, ST code simultaneously contains a control intent layer, a program structure layer, and an executable implementation layer. Multi-level objectives are prone to gradient interference under a unified loss function, leading to problems such as locally syntactically correct but distorted control logic, or logically correct but uncompileable code. Third, traditional beam search or sampling decoding only expands candidate sequences based on probability scores, which cannot timely block paths that inevitably violate safety rules during the generation process, resulting in high subsequent repair costs and poor interpretability.

[0004] In existing technologies, retrieval-enhanced generation methods mainly inject specification knowledge from external sources through prompts, but do not change the underlying generation distribution of the model; compilation-based repair methods can improve syntax errors, but struggle to cover higher-level semantic issues such as interlock failures, priority conflicts, and sequence control anomalies; post-processing static checking methods can only identify risky code after generation and cannot perform prefix-level active constraints during the decoding phase. Therefore, there is an urgent need for an ST code generation method that can maintain a unified constraint definition across the three stages of data preparation, model training, and inference / decoding, and explicitly enhance industrial safety rules.

[0005] Furthermore, industrial site requirements are typically expressed using a mix of natural language process descriptions, point lists, timing specifications, and empirical norms. The same control intent may correspond to multiple near-synonymous expressions. For example, statements such as "all actuators are de-energized during an emergency stop," "all outputs are cut off first during an emergency stop," and "driving is prohibited when the safety circuit is disconnected" are equivalent in engineering meaning, but differ significantly in literal form. Without a unified semantic routing and rule mapping mechanism, the model struggles to stably map these requirements to a consistent safety control template, leading to inconsistencies in constraint understanding between the training and decoding phases. Summary of the Invention

[0006] To address the aforementioned technical problems in existing technologies, this invention proposes a constraint consistency training and decoding method for industrial ST code generation, the specific technical solution of which is as follows:

[0007] A constraint consistency training and decoding method for industrial ST code generation includes the following steps:

[0008] Step 1: Construct a shared static rule library and perform constraint semantic annotation and multi-view organization on the training samples to form a unified input requirement, planning representation, structural skeleton and target code data sample;

[0009] Step 2: Based on the weighted semantic routing gating mechanism, perform rule mapping on key semantic segments related to security, interlocking, timing, and type, and generate token-level risk weights. Use the risk weights to weight the training loss of the ST code generation model to obtain a constraint-sensitive training target.

[0010] Step 3: Based on the multi-view consistency calibration mechanism, the same industrial ST sample is split into planning view, structure view and code view, and jointly optimized by course-based multi-objective fine-tuning method to reduce gradient interference between different abstraction levels;

[0011] Step 4: In the inference and decoding stage, a constraint-aware bundle search mechanism is introduced to embed the syntactic constraints and security semantic constraints in the shared static rule base into the bundle search process, perform real-time verification and rearrangement of candidate prefixes, and output ST code that conforms to industrial control specifications.

[0012] Furthermore, step 1 includes the following sub-steps:

[0013] Step 1.1: Receive industrial control task requirements and standardize them into a text sequence, retaining semantic slots for equipment objects, action objects, state conditions, timing triggers, and prohibition conditions; the industrial control task requirements include natural language process descriptions, sequential control step descriptions, input / output point descriptions, interlocking relationship descriptions, alarm condition descriptions, and safety procedure descriptions;

[0014] Step 1.2: Parse the standardized industrial control task requirements into a set of semantic units, where each semantic unit describes a device object, action object, state condition, timing trigger, and prohibition or abnormal condition.

[0015] Step 1.3: Construct a shared static rule library. Each rule in the library includes a triggering condition, constraint predicate, location function, and rule category. The rule categories include security rules, interlocking rules, time-series rules, and type rules.

[0016] Step 1.4: Perform the routing mapping from semantic units to rules. Based on the joint matching function of keywords, pattern templates, variable roles, process dictionary and context window, calculate the set of triggering rules corresponding to each semantic unit.

[0017] Step 1.5: Based on the routing mapping results of Step 1.4, the input requirements are annotated offline to form the association between requirement fragments, rule categories, risk levels, and target code locations;

[0018] Step 1.6: Construct multi-view training samples, organizing each training sample into a requirement view, planning view, structure view, and code view. The planning view is used to describe variables, control steps, and interlocking conditions; the structure view is used to describe the abstract syntax skeleton or control flow skeleton; and the code view is used to describe the target ST program that meets the IEC 61131-3 constraints.

[0019] Furthermore, a single training sample in step 1.6 is represented as follows:

[0020]

[0021] in, This represents a subset of triggerable rules associated with the training samples. Represents the requirements view, Represents planning view, Represents structural view, Represents the code view;

[0022] Planning View It can be represented as:

[0023]

[0024] in, Represents a set of variables. Represents the set of control steps. Represents the set of interlocking relationships. Represents a set of temporal relationships;

[0025] Structural View It can be represented as:

[0026]

[0027] in, Represents a set of syntax nodes. This represents a set of control flow or syntax edges. The node type marker function is used to identify structural components such as PROGRAM, VAR, IF, CASE, FOR, function block calls, and assignment statements.

[0028] Furthermore, step 2 includes the following sub-steps:

[0029] Step 2.1: Assign different risk weights to each rule in the shared static rule base according to its category, so that the risk weight of security rules is the highest, followed by the risk weight of interlocking rules, and the risk weights of time-series rules and type-series rules decrease in that order.

[0030] Step 2.2: Process the target ST code with a tokenizer to obtain a token sequence, and calculate the risk intensity of each token in the sequence. The risk intensity is determined by the sum of the weights of all rules covering the token.

[0031] Step 2.3: Normalize the risk intensity and generate a normalized loss weight for any token;

[0032] Step 2.4: Employ a risk amplification coefficient that dynamically changes with the training step, and gradually introduce weights so that the ST code generation model first learns the basic language patterns and code structure in the early stages of training, and then gradually increases its attention to high-risk constraints;

[0033] Step 2.5: Based on the normalized loss weights, weight the standard cross-entropy loss to construct a weighted semantic routing gating training objective;

[0034] Step 2.6: Based on the same weight system as the training objective, calculate the weighted safety rule coverage score, which is used to characterize the degree to which the generated results satisfy high-risk rules;

[0035] Step 2.7: Retain risk mapping records of token risk strength, rule coverage source, demand triggering fragment, and corresponding code location for use in post-training analysis and engineering audit.

[0036] Furthermore, step 3 includes the following sub-steps:

[0037] Step 3.1: Split the same industrial ST sample into planning view, structure view and code view and organize them into a multi-perspective cascaded condition generation task so that the control intent, program skeleton and ST specific implementation form a generation link from coarse to fine.

[0038] Step 3.2: Construct the overall loss for multi-view consistency calibration, consisting of planning view loss, structural view loss, and code view loss;

[0039] Step 3.3: Adopt a course-based scheduling strategy to divide the training process of the ST code generation model into an intent learning stage, a structure alignment stage, and a code convergence stage, and dynamically adjust the weights of the planning view loss, structure view loss, and code view loss in different training stages.

[0040] Step 3.4: Introduce a view-gated routing mechanism, and perform view-related transformations on the hidden states of the intermediate layer through a low-rank adapter, so that different views can maintain relatively independent representation subspaces while sharing the parameters of the backbone model;

[0041] Step 3.5: Execute the view Figure 1 Consistency check: For the key interlocking conditions and timing relationships derived from the planning view, back-check in the structure view and code view respectively. If the key relationships in the planning are not reflected in the skeleton structure or target code, a consistency penalty item is added.

[0042] Step 3.6: Perform course-based joint fine-tuning by freezing the trunk parameters and only fine-tuning the low-rank adapter parameters;

[0043] Step 3.7: Combine the weighted semantic routing gating training objective from Step 2.5 with the multi-view consistency calibration training objective from Step 3.2 to obtain the overall training objective.

[0044] Furthermore, in step 3.2, for the training step... The overall loss of the multi-view consistency calibration is:

[0045]

[0046] in, , and These correspond to the loss terms in the planning view, structure view, and code view, respectively. , , The course-based weights change dynamically with the training process; they are increased in the early stages of training. To enhance the ability to abstract control intentions; increase during the training period To enhance the ability to model the structural skeleton; increase the size in the later stages of training. This is to improve code implementation quality and compilation success rate.

[0047] Furthermore, step 4 includes the following sub-steps:

[0048] Step 4.1: In the decoding process that introduces the beam search mechanism, the constraints in the shared static rule base are divided into a set of syntactic constraints and a set of security semantic constraints, which are used to determine whether the current prefix can still be expanded into a valid ST program and whether it has entered an unrepairable state, respectively; the prefix refers to the incomplete code fragment that has been generated during the beam search process.

[0049] Step 4.2: For any candidate prefix at any decoding time, construct a composite decoding state, which includes the currently generated prefix, the incremental syntax parsing state, and the semantic monitoring state;

[0050] Step 4.3: Perform constraint-aware bundle expansion: At each decoding time, expand the predicted candidate tokens based on the conditional probability distribution of the model output, and retain only the candidate prefixes that simultaneously satisfy the syntactic constraints and security semantic constraints;

[0051] Step 4.4: For candidate tokens that pass the constraint check, update the semantic monitoring state according to the state transition function;

[0052] Step 4.5: Based on the model log probability and the scores of the soft constraints that have been met, jointly rank the candidate prefixes that have passed the constraint check;

[0053] Step 4.6: Employ a tiered rollback mechanism to ensure that all candidate prefixes in a certain decoding step are subject to hard constraint pruning, and perform local constraint repair on code segments with local violations after code generation is complete;

[0054] Step 4.7: Estimate the additional overhead of constraint decoding and reduce inference decoding time by caching parsing state and semantic monitoring state.

[0055] Furthermore, the semantic monitoring status record includes triggered security conditions, pending reset conditions, interlock occupancy status, opened timing windows, and prohibited action markers.

[0056] Furthermore, step 4.6 specifically includes:

[0057] First, keep the grammatical constraints as hard constraints, and only downgrade the security semantic constraints from hard pruning to soft scoring. All candidate prefixes in a certain decoding step are hard-pruned. If no feasible candidates are found, the security semantic constraints are temporarily relaxed, the current best grammatically expandable prefix is ​​retained, and the code snippets with local violations are rewritten in a constraint-driven manner after the code generation is completed.

[0058] For code snippets that still contain violations after generation, extract the violation window. And then re-search for a repair solution within the local neighborhood, the objective of which can be expressed as:

[0059]

[0060] in, This represents a local candidate set constructed around the violation window. This indicates the code generated by the model. The parameter is The conditional probability distribution of the generative model. This is the penalty coefficient for violations. Indicates candidate code The cost of violations against rule base R.

[0061] Furthermore, after step 4, there are also code output and offline verification steps, specifically: using the IEC61131-3 syntax checker, type checker, and static verifier corresponding to the shared static rule base to perform final verification on the generated program; when there are local violations, a local repair strategy is triggered, and only the violating code block is regenerated with a minimum scope; when the final verification is passed, the target ST program is output, and the rule coverage record, risk fragment mapping record, and multi-view intermediate product are output simultaneously.

[0062] The advantages and beneficial effects of this invention are as follows:

[0063] First, to address the issue that low-frequency, high-risk constraints in industrial ST scenarios are easily ignored by the model, this invention directly transforms safety, interlocking, and timing constraints into token-level training weights through weighted semantic routing gating. This allows key constraints to be continuously enhanced during the training phase, which is more conducive to preserving industrial safety knowledge compared to solutions that rely solely on ordinary supervision and fine-tuning.

[0064] Second, this invention achieves unified constraints in the training, inference, and evaluation phases by sharing a static rule base, avoiding the problem of training objectives being out of sync with final acceptance criteria, which is beneficial to improving the consistency and interpretability of system engineering.

[0065] Third, this invention explicitly separates the optimization objectives at three levels—control intent, structural skeleton, and code implementation—through multi-perspective consistency calibration, and employs curriculum-based scheduling to reduce gradient interference, thereby simultaneously improving the integrity of the program structure and the consistency of the control logic.

[0066] Fourth, this invention introduces a prefix-level checking mechanism for syntactic constraints and security semantic constraints during the bundle search phase, so that candidate branches that do not meet the constraints are actively pruned during the generation process, thereby reducing the passive processing cost of "centralized repair after generation" from the source.

[0067] Fifth, this invention supports the output of intermediate results such as rule coverage records, risk mapping records, planning views, and structural views, which facilitates audit tracking, problem localization, and version comparison in industrial settings and is more suitable for high-reliability industrial software development processes.

[0068] Sixth, by introducing a local constraint repair mechanism, this invention regenerates only the violation fragments within a minimal scope while keeping most of the correct code unchanged. This helps reduce the damage to the generated correct statements caused by decoding rollback and improves the reproducibility and controllability of the project. Attached Figure Description

[0069] Figure 1 This is a schematic diagram of the overall process of a constraint consistency training and decoding method for industrial ST code generation according to the present invention.

[0070] Figure 2 A schematic diagram illustrating the processing flow of shared static rule base and weighted semantic routing gating.

[0071] Figure 3 A schematic diagram of the training structure for multi-view consistency calibration.

[0072] Figure 4 A schematic diagram illustrating the processing flow of constraint-based sensing cluster search decoding and hierarchical backoff mechanism.

[0073] Figure 5 This is a schematic diagram of a constraint consistency training and decoding device for industrial ST code generation according to an embodiment of the present invention. Detailed Implementation

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

[0075] like Figure 1 As shown, this embodiment provides a constraint consistency training and decoding method for industrial ST code generation, aiming to improve the ability to maintain safety constraints, structural consistency, and generation reliability during the automatic generation of industrial control code. The method includes the following steps:

[0076] Step 1: Rule Base Construction and Sample Organization: Construct a shared static rule base for industrial ST code generation, and perform constraint semantic annotation and multi-view organization on training samples to form unified input requirements, planning representations, structural skeletons, and target code data samples. For example... Figure 2 As shown, the specific steps include the following:

[0077] Step 1.1: Receive and standardize industrial control task requirements.

[0078] The requirements include, but are not limited to, natural language process descriptions, sequential control step descriptions, input / output point descriptions, interlocking relationship descriptions, alarm condition descriptions, and safety procedure descriptions. The system standardizes the input industrial control task requirements into a text sequence. It also retains key semantic slots such as device objects, action objects, state conditions, timing triggers, and prohibition conditions.

[0079] Step 1.2: Decompose the standardized industrial control task requirements in a standardized manner.

[0080] The original requirements are parsed into a set of semantic units. any semantic unit It can be represented as:

[0081]

[0082] in, Indicates the controlled object or device entity. Indicates the action type. This indicates the prerequisite state conditions. Indicates timing or delay conditions. This indicates a prohibited or abnormal condition.

[0083] Through the above decomposition, the mixed-expression process description can be uniformly mapped into structured semantic units that facilitate rule matching.

[0084] Step 1.3: Build a shared static rule base.

[0085] The static rule base is denoted as Each rule in the library Each rule must include at least a triggering condition, a constraint predicate, a location function, and a rule category. The rule category must include at least security rules, interlocking rules, sequence rules, and type rules. For any rule... Its form can be expressed as:

[0086]

[0087] in, This indicates the conditions for triggering the rule. Boolean predicates indicating whether constraints are satisfied. This represents the set of code locations covered by the rule. Indicates the category to which the rule belongs.

[0088] Step 1.4: Perform route mapping from semantic units to rules.

[0089] For any semantic unit The system calculates its set of triggering rules. :

[0090]

[0091] in, This represents a joint matching function based on keywords, pattern templates, variable roles, a process dictionary, and a context window. The joint matching function supports both explicit rule triggering and merging mapping of synonyms such as prohibiting reversal, requiring manual reset, and prioritizing emergency stop disconnection.

[0092] Step 1.5: Generate constraint semantic annotations.

[0093] Based on the routing mapping results in step 1.4, the security-critical segments in the input requirements are labeled offline, and the relationships between requirement segments, rule categories, risk levels, and target code locations are formed for subsequent training weight construction and offline auditing.

[0094] Step 1.6: Construct multi-view training samples.

[0095] For any training sample, organize it into a demand view. Planning View Structural View and code view Planning view A structural view used to describe variables, control steps, and interlocking conditions. Used to describe abstract syntax skeletons or control flow skeletons, code view To meet the target ST procedure of IEC 61131-3 constraints. Accordingly, a single training sample can be represented as:

[0096]

[0097] in, This represents a subset of triggerable rules associated with the training samples. Represents the requirements view, Represents planning view, Represents structural view, Represents the code view.

[0098] Planning View It can be represented as:

[0099]

[0100] in, Represents a set of variables. Represents the set of control steps. Represents the set of interlocking relationships. Represents a set of temporal relationships.

[0101] Structural View It can be represented as:

[0102]

[0103] in, Represents a set of syntax nodes. This represents a set of control flow or syntax edges. The node type marker function is used to identify structural components such as PROGRAM, VAR, IF, CASE, FOR, function block calls, and assignment statements.

[0104] Step 2, Semantic Routing Risk Weighting: Based on the weighted semantic routing gating mechanism, key semantic segments related to security, interlocking, timing, and type are mapped using rules to generate token-level risk weights. These risk weights are then used to weight the training loss of the ST code generation model to obtain a constraint-sensitive training objective. (Continue to refer to...) Figure 2 Specifically, it includes the following sub-steps:

[0105] Step 2.1: Perform category weight mapping.

[0106] For each rule in the static rule base, different risk weights are assigned based on its category. For each rule... Its weighting function Defined as:

[0107]

[0108] Among them, satisfying This is to ensure that safety and interlocking constraints receive greater attention during training. This indicates the risk weight of safety-related rules. This indicates the risk weight of interlocking rules. This represents the risk weight of time-series rules. This represents the risk weight of the type-based rule.

[0109] Step 2.2: Calculate the token-level risk intensity.

[0110] The target ST code in the sample is processed by a tokenizer to obtain a token sequence. For any token Its risk intensity Represented as:

[0111]

[0112] in, For indicator functions;

[0113] If a token is covered by multiple high-risk rules at the same time, its risk intensity is accumulated according to the weights.

[0114] Step 2.3: Normalize the risk intensity and generate loss weights.

[0115] Normalized loss weight for any token Defined as:

[0116]

[0117] in, This is a risk amplification factor. The upper bound of the weight, This is a stabilizing term used to avoid the denominator being zero and to prevent abnormal gradient amplification in the early stages of training.

[0118] Step 2.4: Implement progressive weighting.

[0119] To reduce instability in the early stages of training, the risk amplification factor in step 2.3 is set as a function that dynamically changes with the training steps:

[0120]

[0121] in, This represents the final risk amplification factor. This indicates the number of weight warm-up steps. Warming up allows the model to first learn basic language patterns and code structures, and then gradually increase its focus on high-risk constraints.

[0122] Step 2.5: Construct risk-weighted training objectives.

[0123] Based on the normalized weights (which are essentially nothing), the standard cross-entropy loss is weighted to obtain the weighted semantic routing gating training objective:

[0124]

[0125] in, The parameter is The conditional probability distribution of the generative model.

[0126] By using the weighting method described above, the model can form a more stable parameter memory for low-frequency but high-risk safety constraint segments during the optimization process.

[0127] Step 2.6: Calculate the weighted security rule coverage score.

[0128] To ensure consistency between the training objectives and offline evaluation metrics, the system also defines rules to cover scores based on the same weighting system:

[0129]

[0130] in, This indicates the code generated by the model. Used to characterize the degree to which the generated results satisfy high-risk rules.

[0131] Step 2.7: Retain risk mapping records.

[0132] The system stores the token risk intensity, rule coverage source, demand triggering fragment, and corresponding code location together, so as to analyze whether high-risk fragments are truly absorbed by the model after training, and to facilitate engineers in tracking where the model learns security constraints.

[0133] Step 3, Multi-view Calibration Joint Training: Based on a multi-view consistency calibration mechanism, the same industrial ST sample is split into a planning view, a structural view, and a code view. A course-based multi-objective fine-tuning approach is used for joint optimization to reduce gradient interference between different abstraction levels and improve the consistency between control intent, program structure, and implementation details. For example... Figure 3 As shown, the specific steps include the following:

[0134] Step 3.1: Organize a multi-perspective condition generation task.

[0135] The planning view, structural view, and code view are organized into a cascaded prediction process, and their joint conditional distribution is represented as follows:

[0136]

[0137] Among them, planning view Used to convey control intent, structural view Used to constrain the program skeleton, code view Used to generate specific ST statements and variable call details.

[0138] Step 3.2: Define the multi-objective consistency loss.

[0139] For training steps Construct a multi-view consistency calibration training objective and define the overall loss for multi-view consistency calibration:

[0140]

[0141] in, , and These correspond to the loss terms in the planning view, structure view, and code view, respectively. , , These are course-based weights that change dynamically with the training process. They are increased in the early stages of training. To enhance the ability to abstract control intentions; increase during the training period To enhance the ability to model the structural skeleton; increase the size in the later stages of training. This is to improve code implementation quality and compilation success rate.

[0142] Step 3.3: Implement a curriculum-based scheduling strategy: Divide the training into three phases: intent learning, structure alignment, and code convergence, while satisfying the following conditions:

[0143]

[0144] During the intention learning phase Take the maximum value; during the structural alignment stage, make Take the maximum value; during the code convergence phase... Take the maximum value.

[0145] The above strategy enables the structured text code generation model to learn the control task from coarse to fine, reducing gradient oscillations caused by direct competition between different levels of supervision targets.

[0146] Step 3.4: Introduce view-gated routes.

[0147] For any intermediate layer hidden state Combined with the view type to which the current token belongs Calculate the view gating factor And perform view-related transformations through a lightweight adapter, the expression of which is:

[0148]

[0149]

[0150] in, This represents the Sigmoid function. Indicates view type embedding, Representation and View The corresponding low-rank adapter, This indicates element-wise multiplication.

[0151] Through the above gating mechanism, different views can maintain relatively independent representation subspaces while sharing the backbone model parameters.

[0152] Step 3.5: Execute the view Figure 1 Consistency check.

[0153] For key interlocking conditions and timing relationships derived from the planning view, a back-check is performed in both the structure view and the code view. If it is found that key relationships existing in the planning are not reflected in the skeleton structure or target code, a consistency penalty term is added to the sample to reduce the problem of correct planning but missing implementation.

[0154] Step 3.6: Perform curriculum-based joint fine-tuning. Training is performed by freezing the backbone parameters and fine-tuning only the low-rank adapter parameters to reduce deployment overhead. In a preferred embodiment, the low-rank adapter is set to rank=8 and the scaling factor is... It only applies to the query projection matrix and value projection matrix in the attention module.

[0155] Step 3.7: Construct the overall training objective.

[0156] Preferably, the risk-weighted objective in step 2.5 is combined with the multi-view objective in step 3.2 to obtain the overall training objective:

[0157]

[0158] in, This is a balancing coefficient used to control the relative strength between constraint-sensitive optimization and multi-view consistency optimization.

[0159] Ultimately, a structured text code generation model trained to meet the task requirements is obtained.

[0160] Step 4, Constraint-Aware Decoding and Hierarchical Rollback: In the inference decoding stage, a constraint-aware bundle search (CABS) mechanism is introduced. Syntactic constraints and security semantic constraints from the shared static rule base are embedded into the beam search process. Candidate paths are validated and rearranged in real time through incremental parsing and semantic monitoring. Candidate prefixes that are not scalable or inevitably violate rules are pruned. Hierarchical rollback and local repair are triggered when necessary, thereby outputting ST code that conforms to industrial control specifications, i.e., constraint-consistent ST code. For example... Figure 4 As shown, the specific steps include the following:

[0161] Step 4.1: Construct a set of prefix-level constraints.

[0162] In the decoding process that incorporates a bundle search mechanism, the constraints in the shared static rule base are divided into a set of syntax constraints. and security semantic constraint set .in, Used to determine whether the current prefix can still be expanded into a valid ST program. This is used to determine whether the current prefix has entered an irreparable state, such as interlock failure, emergency stop priority violation, or prohibited action overreach. The prefix refers to the incomplete code segment that has been generated during the bundle search process of decoding and generating code.

[0163] Step 4.2: Maintain the decoding state.

[0164] For any decoding moment Candidate prefixes are used to construct composite decoding states. :

[0165]

[0166] in, This indicates that a prefix has been generated. Indicates the incremental parsing state. This indicates the semantic monitoring status. The semantic monitoring status records at least the triggered security conditions, the reset conditions to be met, the interlock occupancy status, the opened timing windows, and the prohibited action flags.

[0167] Step 4.3: Perform constraint-aware bundle expansion.

[0168] Assuming at the decoding time The Beam set is For each candidate prefix The model provides the conditional probability distribution of the next token and selects it from the distribution. Candidate tokens are expanded tentatively. Candidate prefixes that satisfy both syntactic and security semantic constraints constitute the candidate set for the next time step.

[0169]

[0170] in, This indicates a prefix concatenation operation. The highest score is retained. 10 candidate paths.

[0171] Step 4.4: Perform semantic state update.

[0172] For candidate tokens that pass the constraint check, the system updates the semantic monitoring state based on the state transition function. :

[0173]

[0174] in, Based on the newly added variable assignments, function block calls, conditional branches, or reset statements in the current prefix, update the status variables such as interlock occupancy, fault retention, whether manual reset is completed, and whether emergency stop priority is violated.

[0175] Step 4.5: Perform constraint-aware rearrangement.

[0176] For candidate prefixes that pass the constraint check, they can be further ranked jointly based on the model log probability and the score of the satisfied soft constraints. Their candidate scores can be expressed as:

[0177]

[0178] in, This represents the soft constraint score that the candidate prefix has been determined to satisfy at the current time. This represents the soft constraint rearrangement coefficient.

[0179] Step 4.6: Trigger the tiered rollback mechanism and perform local repair.

[0180] First, keep the grammatical constraints as hard constraints, and only downgrade the security semantic constraints from hard pruning to soft scoring. All candidate prefixes in a certain decoding step are hard-pruned. If no feasible candidates still exist, the security semantic constraints are temporarily relaxed, the current best grammatically expandable prefix is ​​retained, and the code snippets with local violations are rewritten in a constraint-driven manner after the code generation is completed.

[0181] For code snippets that still contain violations after generation, extract the violation window. And then re-search for a repair solution within the local neighborhood, the objective of which can be expressed as:

[0182]

[0183] in, This represents a local candidate set constructed around the violation window. This is the penalty coefficient for violations. This represents the violation cost of the candidate code to the rule base. By regenerating only the minimum necessary fragments, the perturbation to the remaining correct code can be reduced.

[0184] Step 4.7: Estimate the constraint decoding cost.

[0185] If the Beam width is The number of candidates per step is The generated length is The incremental parsing single-step time is Semantic monitoring single-step time is The additional time complexity of CABS can be approximated as:

[0186]

[0187] This additional overhead can be effectively controlled by caching the parsing state and semantic monitoring state.

[0188] This invention also includes code output and offline verification steps. After generation, the system uses the IEC 61131-3 syntax checker, type checker, and the corresponding static verifier of the rule base to perform final verification on the generated program. If local violations exist, a local repair strategy is triggered, and only the violating code block is regenerated with a minimal scope. If the verification passes, the target ST program is output, and rule coverage records, risk fragment mapping records, and multi-view intermediate products are output simultaneously to facilitate subsequent engineering auditing and tracking.

[0189] In summary, the method of this invention maintains a unified constraint definition across the three stages of data preparation, model training, and inference decoding, reducing the omission of high-risk control constraints and improving the automation, interpretability, and engineering usability of industrial ST code generation.

[0190] Corresponding to the aforementioned embodiment of a constraint consistency training and decoding method for industrial ST code generation, the present invention also provides an embodiment of a constraint consistency training and decoding device for industrial ST code generation.

[0191] See Figure 5 The present invention provides a constraint consistency training and decoding device for industrial ST code generation, comprising one or more processors for implementing the constraint consistency training and decoding method for industrial ST code generation in the above embodiments.

[0192] The embodiment of the constraint consistency training and decoding device for industrial ST code generation of this invention can be applied to any device with data processing capabilities, such as a computer. The device embodiment can be implemented in software, hardware, or a combination of both. Taking software implementation as an example, as a logical device, it is formed by the processor of any data processing device loading the corresponding computer program instructions from non-volatile memory into memory for execution. From a hardware perspective, such as... Figure 5 The diagram shown is a hardware structure diagram of any data processing-capable device, including a constraint consistency training and decoding device for industrial ST code generation according to the present invention. (Except for...) Figure 5 In addition to the processor, memory, network interface, and non-volatile memory shown, any data processing device in the embodiment may also include other hardware depending on the actual function of the data processing device, which will not be described in detail here.

[0193] The specific implementation process of the functions and roles of each unit in the above device can be found in the implementation process of the corresponding steps in the above method, and will not be repeated here.

[0194] For the device embodiments, since they basically correspond to the method embodiments, the relevant parts can be referred to in the description of the method embodiments. The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units, that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of the present invention according to actual needs. Those skilled in the art can understand and implement this without creative effort.

[0195] This invention also provides a computer-readable storage medium storing a program thereon, which, when executed by a processor, implements the constraint consistency training and decoding method for industrial ST code generation described in the above embodiments.

[0196] The computer-readable storage medium can be an internal storage unit of any data processing device described in any of the foregoing embodiments, such as a hard disk or memory. The computer-readable storage medium can also be an external storage device, such as a plug-in hard disk, smart media card (SMC), SD card, flash card, etc., equipped on the device. Furthermore, the computer-readable storage medium can include both internal storage units of any data processing device and external storage devices. The computer-readable storage medium is used to store the computer program and other programs and data required by the data processing device, and can also be used to temporarily store data that has been output or will be output.

[0197] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention in any way. Although the implementation process of the present invention has been described in detail above, those skilled in the art can still modify the technical solutions described in the foregoing examples or make equivalent substitutions for some of the technical features. All modifications and equivalent substitutions made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A constraint consistency training and decoding method for industrial ST code generation, characterized in that, Includes the following steps: Step 1: Construct a shared static rule library and perform constraint semantic annotation and multi-view organization on the training samples to form a unified input requirement, planning representation, structural skeleton and target code data sample; Step 2: Based on the weighted semantic routing gating mechanism, perform rule mapping on key semantic segments related to security, interlocking, timing, and type, and generate token-level risk weights. Use the risk weights to weight the training loss of the ST code generation model to obtain a constraint-sensitive training target. Step 3: Based on the multi-view consistency calibration mechanism, the same industrial ST sample is split into planning view, structure view and code view, and jointly optimized by course-based multi-objective fine-tuning method to reduce gradient interference between levels; Step 4: In the inference and decoding stage, a constraint-aware bundle search mechanism is introduced to embed the syntactic constraints and security semantic constraints in the shared static rule base into the bundle search process, perform real-time verification and rearrangement of candidate prefixes, and output ST code that conforms to industrial control specifications.

2. The constraint consistency training and decoding method for industrial ST code generation according to claim 1, characterized in that, Step 1 includes the following sub-steps: Step 1.1: Receive industrial control task requirements and standardize them into a text sequence, retaining semantic slots for equipment objects, action objects, state conditions, timing triggers, and prohibition conditions; the industrial control task requirements include natural language process descriptions, sequential control step descriptions, input / output point descriptions, interlocking relationship descriptions, alarm condition descriptions, and safety procedure descriptions; Step 1.2: Parse the standardized industrial control task requirements into a set of semantic units, where each semantic unit describes a device object, action object, state condition, timing trigger, and prohibition or abnormal condition. Step 1.3: Construct a shared static rule library. Each rule in the library includes a triggering condition, constraint predicate, location function, and rule category. The rule categories include security rules, interlocking rules, time-series rules, and type rules. Step 1.4: Perform the routing mapping from semantic units to rules. Based on the joint matching function of keywords, pattern templates, variable roles, process dictionary and context window, calculate the set of triggering rules corresponding to each semantic unit. Step 1.5: Based on the routing mapping results of Step 1.4, the input requirements are annotated offline to form the association between requirement fragments, rule categories, risk levels, and target code locations; Step 1.6: Construct multi-view training samples, organizing each training sample into a requirement view, planning view, structure view, and code view. The planning view is used to describe variables, control steps, and interlocking conditions; the structure view is used to describe the abstract syntax skeleton or control flow skeleton; and the code view is used to describe the target ST program that meets the IEC 61131-3 constraints.

3. The constraint consistency training and decoding method for industrial ST code generation according to claim 2, characterized in that, A single training sample in step 1.6 is represented as follows: in, This represents a subset of triggerable rules associated with the training samples. Represents the requirements view, Represents planning view, Represents structural view, Represents the code view; Planning View It can be represented as: in, Represents a set of variables. Represents the set of control steps. Represents the set of interlocking relationships. Represents a set of temporal relationships; Structural View It can be represented as: in, Represents a set of syntax nodes. This represents a set of control flow or syntax edges. A function to indicate the node type.

4. The constraint consistency training and decoding method for industrial ST code generation according to claim 2, characterized in that, Step 2 includes the following sub-steps: Step 2.1: Assign different risk weights to each rule in the shared static rule base according to its category, so that the risk weight of security rules is the highest, followed by the risk weight of interlocking rules, and the risk weights of time-series rules and type-series rules decrease in that order. Step 2.2: Process the target ST code with a tokenizer to obtain a token sequence, and calculate the risk intensity of each token in the sequence. The risk intensity is determined by the sum of the weights of all rules covering the token. Step 2.3: Normalize the risk intensity and generate a normalized loss weight for any token; Step 2.4: Employ a risk amplification coefficient that dynamically changes with each training step, and gradually introduce weights so that the ST code generation model first learns the basic language patterns and code structure in the early stages of training, and then gradually increases its attention to high-risk constraints. Step 2.5: Based on the normalized loss weights, weight the standard cross-entropy loss to construct a weighted semantic routing gating training objective; Step 2.6: Based on the same weight system as the training objective, calculate the weighted safety rule coverage score, which is used to characterize the degree to which the generated results satisfy high-risk rules; Step 2.7: Retain risk mapping records of token risk strength, rule coverage source, demand triggering fragment, and corresponding code location for use in post-training analysis and engineering audit.

5. The constraint consistency training and decoding method for industrial ST code generation according to claim 4, characterized in that, Step 3 includes the following sub-steps: Step 3.1: Split the same industrial ST sample into planning view, structure view and code view and organize them into a multi-perspective cascaded condition generation task so that the control intent, program skeleton and ST specific implementation form a generation link from coarse to fine. Step 3.2: Construct the overall loss for multi-view consistency calibration, consisting of planning view loss, structural view loss, and code view loss; Step 3.3: Adopt a course-based scheduling strategy to divide the training process of the ST code generation model into an intent learning stage, a structure alignment stage, and a code convergence stage, and dynamically adjust the weights of the planning view loss, structure view loss, and code view loss in different training stages. Step 3.4: Introduce a view-gated routing mechanism, and perform view-related transformations on the hidden states of the intermediate layer through a low-rank adapter, so that different views can maintain relatively independent representation subspaces while sharing the parameters of the backbone model; Step 3.5: Perform view consistency verification: For the key interlocking conditions and timing relationships derived from the planning view, perform a back check in the structure view and code view respectively. If the key relationships existing in the planning are not reflected in the skeleton structure or target code, then apply a consistency penalty item. Step 3.6: Perform course-based joint fine-tuning by freezing the trunk parameters and only fine-tuning the low-rank adapter parameters; Step 3.7: Combine the weighted semantic routing gating training objective from Step 2.5 with the multi-view consistency calibration training objective from Step 3.2 to obtain the overall training objective.

6. The constraint consistency training and decoding method for industrial ST code generation according to claim 5, characterized in that, In step 3.2, for the training step The overall loss of the multi-view consistency calibration is: in, , and These correspond to the loss terms in the planning view, structure view, and code view, respectively. , , The course-based weights change dynamically with the training process; they are increased in the early stages of training. To enhance the ability to abstract control intentions; increase during the training period To enhance the ability to model the structural skeleton; increase the size in the later stages of training. This is to improve code implementation quality and compilation success rate.

7. The constraint consistency training and decoding method for industrial ST code generation according to claim 1, characterized in that, Step 4 includes the following sub-steps: Step 4.1: In the decoding process that introduces the beam search mechanism, the constraints in the shared static rule base are divided into a set of syntactic constraints and a set of security semantic constraints, which are used to determine whether the current prefix can still be expanded into a valid ST program and whether it has entered an unrepairable state, respectively; the prefix refers to the incomplete code fragment that has been generated during the beam search process. Step 4.2: For any candidate prefix at any decoding time, construct a composite decoding state, which includes the currently generated prefix, the incremental syntax parsing state, and the semantic monitoring state; Step 4.3: Perform constraint-aware bundle expansion: At each decoding time, expand the predicted candidate tokens based on the conditional probability distribution of the model output, and retain only the candidate prefixes that simultaneously satisfy the syntactic constraints and security semantic constraints; Step 4.4: For candidate tokens that pass the constraint check, update the semantic monitoring state according to the state transition function; Step 4.5: Based on the model log probability and the scores of the soft constraints that have been met, jointly rank the candidate prefixes that have passed the constraint check; Step 4.6: Employ a tiered rollback mechanism to ensure that all candidate prefixes in a certain decoding step are subject to hard constraint pruning, and perform local constraint repair on code segments with local violations after code generation is complete; Step 4.7: Estimate the additional overhead of constraint decoding and reduce inference decoding time by caching parsing state and semantic monitoring state.

8. The constraint consistency training and decoding method for industrial ST code generation according to claim 7, characterized in that, The semantic monitoring status record includes triggered security conditions, pending reset conditions, interlock occupancy status, opened timing windows, and prohibited action markers.

9. The constraint consistency training and decoding method for industrial ST code generation according to claim 7, characterized in that, Step 4.6 specifically involves: First, keep the grammatical constraints as hard constraints, and only downgrade the security semantic constraints from hard pruning to soft scoring. All candidate prefixes in a certain decoding step are hard-pruned. If no feasible candidates are found, the security semantic constraints are temporarily relaxed, the current best grammatically expandable prefix is ​​retained, and the code snippets with local violations are rewritten in a constraint-driven manner after the code generation is completed. For code snippets that still contain violations after generation, extract the violation window. And then re-search for a repair solution within the local neighborhood, the objective of which can be expressed as: in, This represents a local candidate set constructed around the violation window. This indicates the code generated by the model. The parameter is The conditional probability distribution of the generative model. This is the penalty coefficient for violations. Indicates candidate code The cost of violations against rule base R.

10. The constraint consistency training and decoding method for industrial ST code generation according to claim 1, characterized in that, Following step 4, code output and offline verification steps are also included, specifically: the generated program is finally verified using the IEC 61131-3 syntax checker, type checker, and static verifier corresponding to the shared static rule base; when local violations exist, a local repair strategy is triggered, and only the violating code block is regenerated with a minimal scope; when the final verification is passed, the target ST program is output, and the rule coverage record, risk fragment mapping record, and multi-view intermediate product are output simultaneously.

Images