Structured text program generation method and electronic device

Abstract

The application provides a structured text program generation method and an electronic device. The method comprises the following steps: obtaining a structured text program generation task; obtaining prompt information based on visible verification evidence; calling a large language model to generate a structured text candidate program based on the prompt information; submitting the candidate program to a visible verification chain for verification; when the candidate program passes the visible verification chain, submitting the candidate program to a sealed verification gate for judgment, the sealed verification gate uses a second dynamic test, and the judgment content of the sealed verification gate is not transmitted to the large language model, the second dynamic test is not overlapped with the first dynamic test track; if the judgment result of the sealed verification gate is successful, the candidate program is output, and a structured text program is obtained. The purpose of obtaining a structured text program that is completely and independently verified under the constraint of a fixed verification protocol is achieved.

Description

Technical Field

[0001] This invention belongs to the field of industrial control software technology, and in particular relates to a method for generating structured text programs and an electronic device. Background Technology

[0002] Programmable Logic Controllers (PLCs) directly control sensors, actuators, and industrial equipment by periodically reading inputs, executing control programs, and updating outputs. In addition to Boolean operations and branching structures, ST programs may also include cross-scan hold states, timers, counters, edge detection, interlocking relationships, and priority logic. Therefore, passing a syntax check does not necessarily mean that a program meets the control requirements for all target input sequences.

[0003] Large language models can generate ST candidate programs based on natural language requirements. Existing solutions typically employ one of the following methods: generating the program all at once; returning compilation or formal verification errors to the model and regenerating; or having multiple agents separately undertake planning, coding, verification, and debugging tasks. While external tools can assist in PLC program generation in existing solutions, the following technical problems still exist.

[0004] 1. Latest logs replace historical evidence: Existing closed loops typically only provide the model with the previous candidate and its latest error. The requirements that the candidate has already met, historically recurring errors, and the evidentiary relationships between different validators are not structurally preserved, and local modifications can easily disrupt previously satisfied control behaviors.

[0005] 2. There is a gap between grammatical correctness and functional correctness: the compiler primarily checks syntax, declarations, and types; the formal verifier only judges a given model and properties; dynamic tests only cover a given input trajectory. Relying on only one of these tools may result in incomplete judgments.

[0006] 3. Feedback testing and final evaluation are not isolated: If the same test is continuously disclosed to the model in multiple rounds of generation, the model may only be adapted to that test; if the hidden test fails for the first time and terminates directly, the unused candidate opportunities cannot be explored.

[0007] 4. Uncertainty in validation results being mistakenly treated as functional errors: The formal validator may return inconclusive results due to state space limitations, backend timeouts, or resource constraints. This result does not constitute a counterexample to the program violating requirements, and directly treating the diagnosis as a functional error feedback may induce unfounded modifications to the model.

[0008] 5. Unclear boundaries of generation model permissions: If the validator, properties, test partitions or success conditions can be modified in the model, the final result cannot be used as independent evidence of the correctness of the program. Summary of the Invention

[0009] To address the aforementioned problems in the existing technology, the present invention provides a method for generating structured text programs and an electronic device.

[0010] In a first aspect, embodiments of this disclosure provide a method for generating structured text programs, including: Based on the acquired natural language control requirements, fixed structured text program interface, and public PLC scanning semantics, the task to be generated as a structured text program is obtained. In response to the task of generating a structured text program, a prompt message is obtained based on visible verification evidence, which is obtained based on the historical verification results of the visible verification chain; The large language model is invoked to generate a structured text candidate program based on the prompt information; The candidate program is submitted to the visible verification chain for verification, which includes compilation checks, formal property verification, and a first dynamic test. When the candidate program passes the visible verification chain, the candidate program is submitted to the sealed verification gate for judgment. The sealed verification gate uses a second dynamic test, and the judgment content of the sealed verification gate is not transmitted to the large language model. The second dynamic test trajectory does not overlap with the first dynamic test trajectory. If the determination result of the sealing verification door is successful, the candidate program is output, thus obtaining the structured text program.

[0011] Optionally, the visible verification evidence is obtained by the failure of the structured text candidate program generated by the previous round of the large language model through the visible verification chain, specifically: When the structured text candidate program generated by the previous large language model fails to be verified after being submitted to the visible verification chain, the verification results of each visible verification gate in the visible verification chain are aggregated into a demand-level evidence state. The requirement-level evidence state includes: aggregating the required number, failed requirement number, failure type, summary, and counterexample trajectory returned by each visible verification gate into a candidate set of confirmed failed evidence and a set of supporting requirements; establishing discrete states including failing, supported, previously_supported, and not_yet_supported for each requirement in the requirement set; and generating a stable signature for each failed piece of evidence, which is calculated from the tool, failure type, sorted requirement number, normalized summary, and Oracle state.

[0012] Optionally, the prompt information includes the demand status, non-regression Anchor, and failure certificate; The requirement status records the support status of each requirement in the current candidate program, the non-regression Anchor is used to indicate the candidate program with the best comprehensive verification evidence in the current round, and the failure certificate is used to record the verified failure evidence.

[0013] Optionally, after submitting the candidate program to the seal verification gate for judgment, the method further includes: If the seal verification gate fails and the seal query limit is not reached, a restricted blind restart across rounds is initiated, the visible historical data of the large language model is cleared, and the next generation round begins.

[0014] Optionally, when the candidate program fails the visible verification chain, a non-regression Anchor is selected from the historical candidates of the current epoch, and a prompt message is constructed based on the demand-level evidence state, the non-regression Anchor, and the historical failure memory of the current epoch. Selecting a non-regressive Anchor includes: calculating the lexicographical score of each candidate program within the current epoch, wherein the parameters for calculating the lexicographical score include the number of security-critical requirements supported by the candidate program, the total number of requirements supported by the candidate program, the number of visible verification gates passed by the candidate program, the negative of the number of different failure signatures of the candidate program, and the candidate program number; and selecting the candidate program with the highest lexicographical score as the non-regressive Anchor.

[0015] Optionally, select a non-regression Anchor from the historical candidates of the current epoch, and construct cue information based on the demand-level evidence state, the non-regression Anchor, and the historical failure memory of the current epoch, including: Within the fixed character budget, priority is given to retaining the latest candidate and confirmed failed evidence of valid anchors. Other failed evidence is compressed into historical memory according to stable signatures. Evidence selection is based on the priority order of security critical requirements, blocking errors, signature occurrence count, counterexample trajectory length, and signature lexicographical order. When the character budget is exceeded, older historical and low-priority evidence is deleted first, while the requirement number and current discrete state are retained.

[0016] Optionally, the visible verification chain includes: a response format and interface check gate, a duplicate candidate check gate, an IEC compiler compilation gate, a formal verification gate, and a visible dynamic test gate.

[0017] Optionally, the candidate program is submitted to the sealing verification gate for judgment. If the result is a failure, only the verification failure status is returned to the large language model, and the rejected candidate program, sealing status, summary, evidence, input trajectory and output trajectory are not returned to the large language model.

[0018] Optionally, it also includes setting an upper limit for the total number of candidate programs, an upper limit for sealed queries, and an upper limit for restorative restarts; and outputting a confirmed termination status when the number of candidates, the number of sealed queries, or the number of restorative restarts are reached.

[0019] Secondly, embodiments of this disclosure also provide an electronic device, the electronic device comprising: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions executable by the at least one processor, which, when executed, enable the at least one processor to perform the structured text program generation method described in any of the first aspects.

[0020] The structured text program generation method provided by this invention organizes the structured evidence generated by the visible verification chain into model hints, drives a large language model to generate candidate programs, and performs a final judgment through a sealed verification gate isolated from the generation process information after the candidates pass all visible verifications. This achieves the goal of obtaining a complete and independently verified structured text program under the constraints of a fixed verification protocol. Attached Figure Description

[0021] The above and other objects, features and advantages of this disclosure will become more apparent from the accompanying drawings, in which like reference numerals generally denote like parts.

[0022] Figure 1 A flowchart of a structured text program generation method provided in this disclosure embodiment; Figure 2 A flowchart illustrating the organization of demand evidence and the processing of non-regression Anchors provided for embodiments of this disclosure; Figure 3 A flowchart illustrating the cross-epoch restricted blind restart state transition provided in this embodiment of the disclosure; Figure 4 A schematic block diagram of an electronic device provided in an embodiment of this disclosure. Detailed Implementation

[0023] The embodiments of this disclosure will now be described in detail with reference to the accompanying drawings.

[0024] It should be understood that the following specific examples illustrate the implementation of this disclosure, and those skilled in the art can easily understand other advantages and effects of this disclosure from the content disclosed in this specification. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. This disclosure can also be implemented or applied through other different specific implementation methods, and the details in this specification can also be modified or changed based on different viewpoints and applications without departing from the spirit of this disclosure. It should be noted that, in the absence of conflict, the following embodiments and features in the embodiments can be combined with each other. Based on the embodiments in this disclosure, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this disclosure.

[0025] It should be noted that the aspects described herein can be embodied in a wide variety of forms, and any particular structure and / or function described herein is merely illustrative. Based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice method. Furthermore, this device and / or practice method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0026] It should also be noted that the illustrations provided in the following embodiments are only schematic representations of the basic concept of this disclosure. The illustrations only show the components related to this disclosure and are not drawn according to the number, shape and size of the components in actual implementation. In actual implementation, the form, quantity and proportion of each component can be arbitrarily changed, and the layout of the components may also be more complex.

[0027] Furthermore, specific details are provided in the following description to facilitate a thorough understanding of the examples. However, those skilled in the art will understand that the described aspects can be practiced without these specific details.

[0028] Structured Text (ST) refers to the PLC programming language specified in IEC 61131-3.

[0029] Anchor refers to anchoring; Epoch refers to a round or cycle.

[0030] This embodiment relates to the fields of automatic generation of industrial control software, programmable logic controller (PLC) program verification, and artificial intelligence-assisted programming. In particular, it relates to a method for generating IEC 61131-3 ST programs using large language models and forming a feedback loop through compilation verification, formal verification, and runtime dynamic verification. This method is applicable to application scenarios such as manufacturing equipment, robots, logistics equipment, energy systems, and process control that require the execution of control logic according to a scan cycle.

[0031] The technical problems to be solved in this embodiment include: how to organize heterogeneous evidence generated by multiple rounds of compilation, formal verification and dynamic execution, so that the next candidate can retain the control requirements that have been met, under the condition that the generation model is not allowed to modify the requirements, verification tools and final judgment criteria; and how to continue to use the remaining generation resources when the sealing test fails or the necessary verifier cannot form a definite conclusion, while avoiding the leakage of hidden evaluation or uncertain diagnosis to the model.

[0032] This invention solves at least the following sub-problems: 1. Unify the gate states, requirement numbers, error summaries, and counterexample trajectories returned by different validators into computable requirement-level evidence states; 2. Determine the Anchor for subsequent generation among multiple historical candidates to reduce the probability that new candidates will lose support for existing features; 3. Select different generation actions based on duplicate candidates, error type, duplicate failure signature, and number of affected requirements; 4. Separate the visible verification that can be used for generation from the seal verification that is only used for final judgment; 5. Set restricted cross-epoch restart paths for sealing failures and verification uncertainties, and ensure that the corresponding content does not enter the next model view; 6. Implement deterministic termination and auditable execution when the total number of candidates, sealed queries, and restorative restarts are limited.

[0033] like Figure 1 As shown, this embodiment discloses a method for generating structured text programs, including: Based on the acquired natural language control requirements, fixed structured text program interface, and public PLC scanning semantics, the task to be generated as a structured text program is obtained. Natural language control requirements are control requirements described in natural language, such as the motor running in the forward direction when the forward start button is pressed and there is no fault.

[0034] The fixed structured text program interface refers to the input / output parameter definition of the ST function block.

[0035] Public PLC scan semantics refers to the fixed rules and behavioral conventions that a PLC executes programs within each scan cycle. This includes the order of input sampling, program execution, and output refresh within each cycle.

[0036] In response to the task of generating a structured text program, a prompt message is obtained based on visible verification evidence, which is obtained based on the historical verification results of the visible verification chain; The visible verification evidence is obtained by the failure of the structured text candidate program generated by the previous round of the large language model through the visible verification chain, specifically: When the structured text candidate program generated by the previous large language model fails to be verified after being submitted to the visible verification chain, the verification results of each visible verification gate in the visible verification chain are aggregated into a demand-level evidence state. The requirement-level evidence state includes: aggregating the required number, failed requirement number, failure type, summary, and counterexample trajectory returned by each visible verification gate into a candidate set of confirmed failed evidence and a set of supporting requirements; establishing discrete states including failing, supported, previously_supported, and not_yet_supported for each requirement in the requirement set; and generating a stable signature for each failed piece of evidence, which is calculated from the tool, failure type, sorted requirement number, normalized summary, and Oracle state.

[0037] Oracle is a decision logic embedded within dynamic test gates (visible OpenPLC gates and sealed OpenPLC gates).

[0038] The large language model is invoked to generate a structured text candidate program based on the prompt information; Large language models can be Deepseek, Qianwen, Doubao, etc. Each time the model is called, a candidate program is generated, and multiple candidate programs are generated by calling the model multiple times.

[0039] The candidate program is submitted to the visible verification chain for verification, which includes compilation checks, formal property verification, and a first dynamic test. In a specific scenario, the visible verification chain includes response format checking, duplicate candidate checking, MatIEC compilation checking, PLCverif formal verification, and visible OpenPLC dynamic testing.

[0040] When the candidate program passes the visible verification chain, the candidate program is submitted to the sealed verification gate for judgment. The sealed verification gate uses a second dynamic test, and the judgment content of the sealed verification gate is not transmitted to the large language model. The second dynamic test trajectory does not overlap with the first dynamic test trajectory. The sealed verification gate performs a black-box final determination of the candidate program using a set of independent dynamic test cases completely isolated from the generated model after all visible verification chains have passed. It only returns status bits to the controller, and all test details are invisible to the model. The test trajectory refers to a series of input signal sequences arranged according to the scan cycle applied to the candidate program in dynamic testing (visible OpenPLC gate or sealed OpenPLC gate), and the corresponding expected output sequence.

[0041] If the determination result of the sealing verification door is successful, the candidate program is output, thus obtaining the structured text program.

[0042] This embodiment constructs a closed loop consisting of a generative model (large language model), a fixed verification protocol, and an evidence orchestration controller. The generative model is only responsible for generating complete ST candidate programs based on prompts; the fixed verification protocol independently executes visible verification and sealing verification; the evidence orchestration controller is responsible for organizing visible evidence, selecting anchors, determining generation actions, and executing state transitions. Requirements, interfaces, scan semantics, validator order, test partitioning, and termination limits are fixed before runtime and cannot be modified by the generative model.

[0043] In this embodiment, a single continuous generation of contexts is referred to as an epoch. Within the same epoch, visible verification evidence can be organized and used for the next candidate; if a sealing failure occurs or the required validator remains inconclusive (unable to determine), the controller can enter a new epoch within the limit. The new epoch does not inherit the candidates, dialogues, and diagnostics that triggered the restart, but only accepts public tasks and pre-fixed diverse strategies or resource recovery strategies.

[0044] The method in this embodiment may include the following steps.

[0045] S101, Task loading: Obtain natural language control requirements, fixed ST interface, and public PLC scan semantics to form a task. Load the frozen validator, properties, visibility test, sealing test, and stop limit.

[0046] S102, Pre-execution checks: This checks if each required validator exists, if its version matches the configuration, if the sealed door is marked as invisible, if the reference asset is complete, and if the model identity matches the allowed list. The task stops if any required condition is not met, and missing validators are not considered as passing the procedure.

[0047] S103, construct initial prompts, mark all requirements as "not yet supported" when there are no historical candidates in the current epoch, combine the public IEC pattern and fixed check obligations, and require the model to output a complete ST function block.

[0048] S104, Generate complete candidate programs, and call the large language model to obtain complete candidate programs. Incorrect formatting, empty responses, or inconsistent interfaces are all recorded as candidate failures and do not require direct code rewriting.

[0049] S105 performs visible verification, running format and repeat checks, MatIEC, PLCverif, and visible OpenPLC in a fixed order. Subsequent gates can be skipped if a previous blocking gate fails, but a failed operation must not be recorded as a pass.

[0050] S106 organizes requirement-level evidence, maps the requirement number, failed requirement number, failure type, summary, and counterexample trajectory returned by the validator to the requirement-level evidence state, generates stable failure signatures, and saves the historical occurrence count.

[0051] S107. Select a non-regression Anchor. Among the candidates in the current epoch, prioritize those that support more security-critical requirements, support more overall requirements, pass more verification gates, and have fewer different failure signatures as Anchors.

[0052] S108, Select the generation action. Based on candidate duplication, failure type, whether the failure signature is duplicated, and the number of affected requirements, select the next generation action from Synthesize, Patch, Restructure, and Restart.

[0053] S109, continue with the same epoch. If the verification fails, combine the requirement state, Anchor, failure memory and action into the next prompt within the fixed context budget, and return to step S104.

[0054] S110 executes the sealing verification. If the verification passes, the sealing OpenPLC gate is invoked. If the sealing passes, the candidate and verification results are output; if the sealing fails, the test content or counterexamples must not be returned to the model.

[0055] S111, perform a restricted blind restart. If sealing fails but there is still a sealing query quota, or if the required visible validator is still inconclusive and there is still a recovery quota, create a new epoch, clear the visible history of the large language model, and regenerate using only public tasks and pre-fixed strategies.

[0056] S112, Termination and Recording: Returns a definitive termination status upon successful verification, exhaustion of the corresponding quota, sealing inconclusive, infrastructure error, or exhaustion of the total candidate quota; writes the candidate hash, validator version, state transition, model identifier, resource usage, and termination reason to an audit log that cannot be further modified.

[0057] The core object and optimization goal of this implementation method are: The task, verification protocol, and control policy are defined as follows: , , ; in, This represents a task to generate an ST program; This represents a set of publicly available functional requirements with a unique number, which can be further marked with safety-critical requirements; This indicates a fixed input / output interface, including the variable name, direction, and data type. This indicates publicly available PLC scan semantics, such as input sampling, program execution, output updates, and cross-scan state retention rules. Indicates a fixed authentication protocol; The visible verification chain can include response format checking, duplicate candidate checking, MatIEC compilation checking, PLCverif formal verification, and visible OpenPLC dynamic testing. This indicates a sealed verification gate, which can use an OpenPLC input trajectory that does not overlap with the visible test. This indicates the evidence arrangement and control strategy; This represents the evidence organization map, used to construct the next hint based on the public task and the visible history of the current epoch; This represents a state transition mapping, used to determine whether to continue the current epoch, enter a new epoch, or terminate based on the verification state.

[0058] The process for generating and verifying the k-th candidate program is defined as follows: , , , ； in, Indicates the sequence number of the current complete ST candidate program; Indicates the generation of the first The history that the model is allowed to read before each candidate procedure and within the current epoch; The first controller construction Sub-model hints; This embodiment represents the basic large language model, and the model parameters are not modified or retrained in this example. The model generates the first A complete ST candidate program; and These represent the states of visible verification and sealed verification, respectively. The state set includes at least Pass, Fail, and Inconclusive. This indicates that the sealing gate has not been executed. The sealing gate is only invoked when all visible verifications pass, thus preventing obviously illegal candidates or those that do not meet the public nature requirements from being sent to the final decision; the symbol " "" indicates that the candidate can be affected by the randomness of model sampling, and the control logic in this embodiment does not depend on a specific model manufacturer.

[0059] The boundaries of the sealed information and the upper limit of execution resources are defined as follows: , , , , in, This indicates the set of sealed fields that are prohibited from being disclosed to the model, including the sealed test state, summary, evidence, input trajectory, output trajectory, and candidates rejected by the sealed field. The model generates the first All fields that can actually be read when there is a candidate program; This indicates the extraction of a set of fields from a model input object; An empty intersection indicates that no sealed field should be included in the model view; This indicates the maximum number of candidate programs that can be generated in a single task; This represents the execution trajectory of a single task. and Count the number of sealed queries and the number of restorative restarts in the trajectory separately; and These are the upper limits for sealed queries and restorative restarts, respectively. These upper limits are configurable parameters and are not limited to a fixed value.

[0060] Given a task distribution, the goal of the control strategy is to increase the probability of obtaining successful verification candidates within the limited resources: , in, It is a task-level success indicator; if the previous If at least one of the candidate programs passes both the visibility verification and the sealing verification, the value is 1; otherwise, the value is 0. Indicates an indicator function; This indicates the randomness of model sampling and other controlled random factors; This refers to the control strategy that maximizes the expected task-level success rate under the same task, model, and verification protocol. This embodiment is implemented through pre-constructed deterministic control logic. It does not require using training data to update the parameters of a large language model.

[0061] Demand-based evidence organization and non-regression Anchor: like Figure 2 As shown, the demand-level evidence organization and non-regression Anchor are not simply a concatenation of the latest logs, but rather a mapping of the current epoch history to demand states, Anchors, failure memories, and generation actions.

[0062] For candidate programs The results of each visible verification gate are aggregated as follows.

[0063] , , , , in, Indicates candidate In the The status of the visible door; This represents the set of requirement numbers explicitly supported by this gate; This represents the set of failure evidence output by the gate; Summarize all failure evidence for the candidates; Only retain failure evidence that Oracle has confirmed can be attributed to the candidate program, excluding unconfirmed tooling errors; A piece of structured evidence must include at least the tool, failure type, associated requirements, summary, Oracle status, and optional counterexample traces. It is a stable signature of the evidence, calculated from the tool, failure type, sorted requirement number, normalized digest and Oracle status, which can be implemented using truncated hashing; Represents the set of different failure signatures for candidate programs; This represents a set of requirement numbers associated with evidence; This represents the set of requirements that are "supported by at least one visible gate and not refuted by a confirmed failure of the same candidate." This definition avoids discarding all other properties that have already passed when the entire verification gate fails.

[0064] The evidence score and selection rule for the Anchor, i.e., the formula for calculating the lexicographical score of each candidate program in the current epoch, is as follows: , , in, Candidate Five-element dictionary order score; This represents the set of pre-marked safety-critical requirements in the task; This indicates the number of security-critical requirements for which a candidate program has received support, representing the highest priority. This represents the total number of requests that have received support for the candidate program. This indicates the number of visible verification gates that the candidate program passed; The negative of the number of different failure signatures is used to prioritize candidate programs with fewer failure types when other items are the same. The candidate number is used to select the newer implementation when all evidence scores are the same. Indicates the range of candidate indices within the current epoch; This indicates lexicographical maximization based on tuples from left to right; This indicates the candidate index selected as the Anchor. This rule does not require subsequent candidates to mathematically strictly contain all the requirements of the Anchor, but rather to explicitly write these requirements into the "no regression" obligation in the next prompt.

[0065] Let the effective Anchor index be When the action of the same epoch is Restart, let Otherwise The latest candidate support for the required Anchor loss is as follows: , , , , in, This indicates the Anchor index that actually leads to the next prompt; This represents the set of requirements for an anchor to gain support; This represents the set of requirements for the latest candidate to gain support in the current epoch; This represents the set of support lost by the latest candidate relative to the Anchor, and is a direct input for non-regression checks; when it is necessary to discard duplicate structures, The Anchor procedure and Anchor support set are both empty, but historical failure memories of the current epoch can still be used to avoid generating the same structure again; this formula only expresses the difference in evidence and does not claim anything. It must contain .

[0066] For each demand, establish the following discrete state: , in, Represents a set of public demands One of the requirements is: failing indicates that the latest candidate has failure evidence directly related to the requirement; supported indicates that the latest candidate has gained visible support for the requirement; previously_supported indicates that the requirement was supported by an earlier candidate in the current epoch, but the latest candidate does not currently support it; not_yet_supported indicates that the current epoch has not yet gained visible support for the requirement; branches are matched in a top-down order, prioritizing direct failure evidence over passing evidence; when there are no candidates in the initial epoch, all requirements are not_yet_supported.

[0067] Within a fixed character budget, the evidence state is compressed as follows: , in, This indicates that the evidence character budget or equivalent token budget is allowed to be written to the model hint; The deterministic evidence selection function prioritizes retaining the latest candidate and confirmed failures of valid Anchors, then compresses other failures into historical memory based on stable signatures. In a preferred embodiment, the evidence priority is considered in the following order: whether it involves security-critical requirements, whether it is a blocking format / interface / compilation error, whether the signature is appearing for the first time, whether the counterexample trajectory is short, and the lexicographical order of the signature. Only one representative detailed piece of evidence is retained for the same signature, while the occurrence count and the most recently appearing candidate program are also saved. When the budget is exceeded, older historical and low-priority evidence is deleted first, but the requirement number and its current discrete state are not deleted. It leads to a structured state that prompts you for the next step, rather than the raw tool log that was not selected.

[0068] The action to be selected for the next candidate procedure is: , in, This indicates the generation action to be used in the next candidate program; Synthesize indicates the first time a complete program is generated from the public task in the current epoch. This indicates that the latest candidate program has the same normalized hash as the historical candidate program, or that the verification gate explicitly returns a duplicate candidate program; This indicates that the failure only includes response format, interface, compilation or formal source code errors, and is suitable for performing a partial patch. This indicates that the two most recent candidate programs have the same non-empty set of failure signatures; This indicates that the latest failure involves multiple requirements or has reached a preset multi-evidence threshold, suggesting that the local patch may be insufficient; This indicates the action taken when generating the latest candidate program; repeated failures first trigger Restructure, and if the same failure still exists after restructure, then Restart is triggered for the same epoch and the Anchor program is removed; the conditions of the formula are matched from top to bottom to ensure that the processing of repeated candidate programs takes precedence over local modifications to the source code.

[0069] Component 1 ultimately forms the prompt mapping: , , in, The constructor indicates a deterministic hint; This represents a complete ST procedure for valid Anchors; it is empty if no Anchor exists. This indicates that the function retrieves only IEC model cards, scans semantic prompts, contractual risk obligations, and fixed pre-launch checks based on the publicly available mission; it does not read reference programs, sealing tests, sealing results, or other Oracle proprietary assets; the output prompts simultaneously tell the model "what needs to be modified" and "which already supported requirements must not be lost," thereby compressing the cross-candidate history into a limited, auditable generated state.

[0070] Restricted blind restart across epochs (restricted blind restart across rounds): like Figure 3 The diagram illustrates the relationship between normal continuation, sealed blind restart, and restorative blind restart. The key to cross-epoch restricted blind restart is not to feed hidden errors back to the model, but rather to only allow verification state changes to the control flow.

[0071] Generate the first The controller states and visible history of each candidate are defined as follows: , , , in, Indicates the generation of the first The complete controller state before each candidate program; Indicates the current epoch number; This indicates the starting position of the current epoch in the global candidate records; This indicates the number of sealed queries that have already been executed; This indicates the number of restorative restarts that have already been performed; This indicates the publicly disclosed diversification strategy or resource recovery strategy used in the current new epoch; Indicates the preceding An internal append-only record of each candidate program and its visible verification results; slice Only records from the current epoch are taken to form the visible history of the model. ;symbol" "Indicates appending to the end of the record" Details of the sealing test are not included.

[0072] The three non-terminating state transitions are defined as follows.

[0073] , in, This indicates that the normal epoch continues: the candidate number increases, while the epoch and starting position remain unchanged; Indicates a blind restart after a sealing failure: epoch increases, the starting position moves to after the appended candidate, and the sealing query count increases; This indicates a blind restart following the inconclusive validation of the required validator: epoch increment, start position shift, and recovery count increment. This indicates a pre-fixed, publicly available, and diverse strategy that is selected only by the epoch number, such as changing the state organization, output decoding, or priority implementation. This indicates a pre-defined verification resource recovery strategy, such as requiring the use of bounded count states, avoiding an unbounded global clock that grows with the scan cycle, and reducing retained states; neither strategy should read sealed traces or inconclusive diagnostic content. This indicates that no cross-epoch strategy is required when continuing normally.

[0074] The unified state transition function is: , in, When the visibility verification is determined to fail, the current epoch is retained, and the visibility evidence is organized by component one; This indicates that both the visibility verification and the sealing verification have passed, and a verification success candidate will be returned immediately. This indicates that sealing has failed but there are still available sealing query quotas and candidate quotas; therefore, a blind sealing restart should be performed. This indicates that the sealing process failed and the available sealing query quota or candidate quota has been exhausted, and a sealing failure message is returned. This indicates that the sealing of the door itself has not reached a definitive conclusion. In a preferred embodiment, this state terminates directly to avoid declaring success when the final determination is uncertain; This indicates that the required visible gate remains inconclusive and there is still recovery capacity available, so a blind recovery restart is performed; This indicates that the recovery quota or candidate quota has been exhausted, returning an infrastructure error; Continue only indicates that the controller can generate the next candidate, not that the current candidate has passed; the segmentation conditions are fixed before execution, and the model cannot be changed based on the result. , or .

[0075] Both cross-epoch mappings result in an empty visible history for the next epoch: , in, In addition The length after each candidate is Set the starting point of the new epoch to After that, the slice from that position to the end of the record is empty; therefore, the next prompt cannot access the candidates, anchors, failure certificates, or original dialogues of the previous epoch; the global record is still kept internally by the controller and can be used for candidate hash deduplication, resource counting, and auditing, but cannot be automatically entered into the model view; this clearing operation is the basis for the implementation of "blind restart" and is also the main difference between it and a normal epoch restart.

[0076] The information not visible during restart is subject to the constraint: The rule prohibits fields from having no intersection with the model view; The new model view can only come from public tasks, public fixed contexts, and pre-frozen strategies. ; in, This represents the set of prohibited fields that trigger a blind restart; when sealing fails, this set must include at least the rejected candidate, sealing status, summary, evidence, input trajectory, and output trajectory; when the validator is inconclusive, this set must include at least the corresponding candidate, tool status, error summary, and diagnostic log. This indicates the fields that the model can see when a new epoch is first generated; the controller can read "which state has occurred" to decide whether to restart, but must not use the specific content of prohibited fields to customize the next prompt.

[0077] In a specific application scenario, the visible verification chain includes the following verification gates in sequence.

[0078] Response format and interface gates: Check whether the model outputs only complete ST function blocks in the specified format, and whether the function block name, input, output, data type, and direction are consistent with the task interface.

[0079] Duplicate candidate gate: Calculate the hash of the normalized candidate; if it is the same as any historical candidate, it forms duplicate evidence, thus avoiding the repeated consumption of subsequent verification resources.

[0080] MatIEC compiler gate: Examines the syntax, declarations, types, expressions, and control structures of IEC 61131-3 ST. Compilation failure serves as visible evidence, but cannot be used to infer functional behavior.

[0081] The PLCverif formal verification gate uses all required properties pre-frozen in the task to verify candidates. The verifier returns the pass number and a reliable counterexample for each property; it does not allow the model to generate its own property file for the final decision.

[0082] The OpenPLC dynamic gate can be seen to execute candidates on a fixed scan semantic and visible input trajectory, returning a failed scan prefix or output difference associated with the requirement number.

[0083] Seal OpenPLC gates: This function is executed only after all visible gates have passed through, and does not overlap with the visible trajectory. Detailed results are not returned to the generated model; they are only used to output success, trigger a blind restart, or terminate the process.

[0084] The tools described above are preferred embodiments and not the only ones. Other IEC compilers, model checkers, or PLC runtimes that can provide equivalent syntax / type judgment, formal property judgment, and dynamic execution of the scan cycle can replace the corresponding tools, but the fixed order, explicit state, visible / sealed isolation, and failure shutdown principles should still be maintained after the replacement.

[0085] Other structured text program generation systems include: The task management module is used to load requirements, interfaces, scan semantics, properties, and test assets, and to isolate public assets from Oracle private assets. The model invocation module is used to invoke one or more large language models according to the controller prompts and verify the actual returned model identifier; The candidate parsing module is used to extract the complete ST program, check the response format, and fix the interface. The visible verification module is used to perform compilation, formal verification, and visible dynamic testing, and output structured evidence with requirement numbers; The sealed verification module is used to perform independent dynamic tests in an isolated environment and prohibits writing test content and diagnostics into model requests; The evidence organization module is used to calculate requirement support, failure signatures, discrete requirement states, and bounded failure memories. The Anchor selection module is used to select the valid Anchor for the current epoch based on the lexicographical evidence score. The action decision module is used to determine Synthesize, Patch, Restructure, or Restart of the same epoch. The blind restart module is used to create a new epoch, clear the visible state of the model, and select a pre-frozen public strategy when sealing fails or verification is uncertain. The budget and termination module is used to limit the number of candidate, sealed queries, and restorative restarts and output a definitive termination status; The evidence ledger module is used to store candidate hashes, configuration hashes, validator versions, model identifiers, state transitions, and resource consumption in an append-only, optional hash chain manner.

[0086] In a specific application scenario, the same epoch continues after a common failure: Suppose the task requires generating a motor control function block with the following public requirements: the run output should be set when the start input is valid and fault-free; the stop input should have higher priority; the run output should be cleared immediately upon a fault; and the reset function should only take effect after the fault input is cleared. The interfaces are fixed as StartCmd, StopCmd, Fault, Reset, and MotorRun.

[0087] The controller constructs initial prompts and obtains candidate programs. MatIEC passed, but PLCverif reported that the stop priority property passed while the fault clearing property failed, providing the associated requirement number and counterexample; this indicates that OpenPLC failed to execute due to formal gate blocking. The controller marked the fault requirement as failing and the stop priority requirement as supported, selecting... Set it as an Anchor and the action as a Patch. The next hint contains the complete... Summary of failure examples and the obligation to retain stop priority.

[0088] Model generation candidate program Subsequently, both MatIEC and PLCverif passed, indicating that OpenPLC detected an error in the output update order within the same scan cycle on the reset trajectory. The controller retained the previously supported fault clearing and stop priority requirements, marked the reset requirement as failing, and continued generating candidate programs. .like If you pass through all the visible doors, you will enter the sealed door; if you pass through the sealed door, you will return. And the verification success status.

[0089] This example illustrates that the feedback from the same epoch is not simply a return of the latest error, but rather carries both the current failure and the requirement that the Anchor is supported.

[0090] Structural adjustments after repeated failures: Assuming candidate program and The counterexample has the same formal signature, and this counterexample involves two interacting state requirements. The action decision module makes... and If true, Restructure is selected, which no longer requires the model to perform minimal local patching, but instead re-derives the order of state transitions and output assignments.

[0091] If a reconstruction candidate still produces the same failure signature, and the action when that candidate was generated was already Restructure, then the next action becomes a Restart within the same epoch. The controller no longer provides an Anchor procedure, but retains the repeated failure signature and the requirement state, demanding that the model reformulate a different implementation from the public contract. This Restart does not create a new epoch, thus still allowing the use of visible failure memories; its difference from a sealed blind restart is that it does not touch any sealed results.

[0092] Blind restart after sealing failure: Candidate Program After passing through MatIEC, PLCverif, and the visible OpenPLC, the data is fed into the sealed OpenPLC. Sealing testing reveals that a candidate does not satisfy a certain unseen input sequence. The sealed module only returns a Fail status to the controller, without returning the use case, summary, expected output, actual output, or counterexample trace.

[0093] like and The controller executes This update increments the epoch number and sealed query count, sets the new epoch start point to the end of the current global record, and removes candidates, anchors, failure certificates, and original dialogues. The next model request will only contain the public task, the fixed IEC context, and the public diversification strategy determined by the new epoch number. The model is unaware of the inputs under which the previous candidate failed and cannot use this information to target sealed use cases.

[0094] If the new candidate passes all validations, output success; if the sealed query reaches its target... or candidates reach If the condition is not met, the output will be either SealedFailure or CandidateBudgetExhausted. This embodiment achieves a simultaneous constraint between allowing continued exploration and preventing the disclosure of hidden evaluations.

[0095] Recoverive blind restart after formal verification resource shortage: Candidate Program The compilation succeeded, but PLCverif failed to generate a Pass or Fail within the fixed backend and fixed timeout. The controller recorded it as Inconclusive instead of interpreting the tool timeout as a requirement violation. and The controller executes Clear candidate and all diagnoses, enter a new epoch, and provide the model with a pre-frozen finite state resource strategy. .

[0096] In a specific application scenario The model is required to use count states that saturate after reaching a threshold, avoid global time variables that continuously increase with each scan, reduce irrelevant cross-scan states, and separate independent state subsystems. This strategy is fixed before experimentation, and specific code modifications are not inferred from timeout logs. If the recovery quota is exhausted and the system remains inconclusive, an InfrastructureError is returned, and the task is not recorded as a functional failure or a successful verification.

[0097] The following technical means can also be used in this embodiment: The generative model can be a single large language model, a multi-model router, or an intelligent agent system with multiple roles cooperating; this embodiment limits the control method of candidates and evidence, and does not limit the specific model.

[0098] ST can be extended to be an intermediate representation of other IEC 61131-3 languages ​​or a program organization unit that translates with ST, but requires the configuration of the corresponding compiler and execution semantics.

[0099] MatIEC can be replaced with other compilers that conform to a subset of the target IEC; PLCverif can be replaced with a model checker or theorem prover that can independently determine the frozen properties; OpenPLC can be replaced with other runtimes, simulators, or real PLC testbeds with deterministic scan semantics.

[0100] Visible and sealing tests can be divided according to input trajectory, requirements, equipment conditions, or time windows, as long as the two do not overlap and the sealing content does not enter the model view.

[0101] Anchor scores can be added to validated execution costs, program complexity, or vendor compatibility metrics, but support for safety-critical requirements and overall requirements should precede program surface features.

[0102] Evidence budgets can be expressed as characters, tokens, number of evidence items, or proportion of model context; the selection strategy must be predetermined and auditable.

[0103] Diversified strategies can employ fixed sequences, pseudo-random sequences determined by epoch numbers, or pre-frozen strategy tables, but sealed diagnostics cannot be used as input.

[0104] The recovery strategy for the validator Inconclusive can be configured for state space, time, integer bit width, or call depth, but the recovery hints only include publicly available general resource constraints and do not include the current uncertain diagnostics.

[0105] Global records can be stored using hash chains, signed logs, append-only databases, or trusted execution environments to prove that the verification configuration and candidate records have not been modified by the generation model.

[0106] The final candidate can also be reviewed by the vendor's compiler, vendor's simulator, or real PLC; this additional step can serve as a final verification gate, but does not change the evidence organization and blind restart principle of this invention.

[0107] The method disclosed in this embodiment is compared with the prior art in Table 1. Table 1. Comparison of the method disclosed in this embodiment with the prior art: .

[0108] This embodiment can be deployed in software within industrial control software development environments, continuous integration systems, or PLC program verification platforms. Its inputs are control requirements and fixed interfaces provided by engineers, and its outputs are complete ST candidates and audit logs verified through a predetermined verification protocol. This solution does not require changes to the PLC hardware and can be used in conjunction with existing IEC compilers, formal verifiers, open-source PLC runtimes, and vendor tools. It is suitable for automatically filtering and feedback-based generation of PLC control logic generated from large models.

[0109] In security-related projects, the output of this embodiment should continue to undergo requirements review, vendor compilation / simulation, target hardware verification, and engineering approval. This embodiment provides multi-layered verification evidence within the declared requirements, nature, and testing scope, and is not equivalent to unconditional proof of correctness for all field inputs, vendor extensions, and physical device behavior.

[0110] This embodiment has the following specific effects: 1. Improve the utilization rate and goal orientation of evidence generation process: Unlike the scheme that only returns the latest original log to the model, this embodiment aggregates the visible verification results of multiple rounds and types into a structured requirement-level evidence state according to the requirement number, and selects non-regression anchors from them. This allows the subsequent model prompts to simultaneously include the dual constraints of "current failure needs to be repaired" and "existing functions must not be lost", which significantly reduces the risk of functional regression in the iteration process.

[0111] 2. Achieving independence and immutability of final judgment: By strictly separating visible verification (used to guide model generation) from sealed verification (used for final judgment), the test cases, input trajectories and diagnostic results of sealed verification are completely kept out of the model view, avoiding adaptive fitting of the model to the final evaluation criteria and ensuring the objectivity and credibility of the verification results.

[0112] 3. Enhanced robustness in handling verification uncertainties: The Inconclusive state returned by the formal validator due to resource limitations or other reasons is treated differently from program function errors. Instead of using it as evidence of failure to mislead model modification, a pre-set restorative blind restart mechanism is used to change the generation strategy and try again under the condition of information isolation, thus avoiding invalid iterations.

[0113] 4. Achieve controllable exploration and deterministic termination under limited resources: By setting hard upper limits on the total number of candidates, the number of sealed queries, and the number of restorative restarts, the system is endowed with the ability to explore in multiple rounds while ensuring that the algorithm will inevitably terminate and output a deterministic state within limited resources, thus balancing generation efficiency and predictability of results.

[0114] 5. Enhanced system auditability and reproducibility: The generated model has no right to modify requirements, validators, and decision criteria. All candidates, configurations, verification results, and state transitions are recorded in an append-only manner. Any successful candidate can be re-verified by the same toolchain, providing the necessary compliance traceability foundation for industrial applications.

[0115] 6. Reduce evidence loss: The requirement-level status retains the support or failure status of each requirement in the latest and historical candidates, so that subsequent prompts not only focus on the current error, but also clearly indicate the existing function support.

[0116] 7. Reduce functional regression: The non-regression Anchor is not fixed as the latest candidate, but is selected based on a comprehensive consideration of security-critical requirements, all requirements, verification gates, and failure signatures, providing a calculable retention obligation for the next candidate.

[0117] 8. Improve the availability of heterogeneous verification evidence: Compilation errors, formal counterexamples, and dynamic trajectories are aligned with requirement numbers through a unified evidence structure, avoiding unprocessed long logs from occupying the model context.

[0118] 9. Protect the independence of the seal evaluation: The visible test and the seal test are separated. The seal content can only affect the control flow and cannot enter the model prompt, thereby reducing the risk of adaptive fitting of the final evaluation trajectory.

[0119] 10. Properly handle verification uncertainties: Inconclusive features are not marked as functional failures; reversible blind restarts use fixed resource constraint strategies to re-express the program state, rather than implementing modifications based on unreliable diagnostics.

[0120] 11. Improved auditability and reproducibility: The generated model cannot modify the Oracle, key assets and state transitions can record hashes and versions, and any successful candidate can be re-verified by the same toolchain.

[0121] In a specific scenario, validation was performed using a task set containing 100 IEC-ST tasks and a DeepSeek-V4-Flash model: the complete solution passed 70 tasks; after removing the requirement evidence organization and non-regression Anchor components, it passed 37 tasks; and after removing the cross-epoch restricted blind restart component, it passed 51 tasks. These results are intended to illustrate the feasibility of the prototype and the effectiveness of the components, and do not constitute a guarantee that the same results will be achieved for any model, any task, or any PLC vendor environment.

[0122] The electronic device disclosed in this embodiment includes a memory and a processor. The memory is used to store non-transitory computer-readable instructions. Specifically, the memory may include one or more computer program products, which may include various forms of computer-readable storage media, such as volatile memory and / or non-volatile memory. The volatile memory may, for example, include random access memory (RAM) and / or cache memory. The non-volatile memory may, for example, include read-only memory (ROM), hard disk, flash memory, etc.

[0123] The processor may be a central processing unit (CPU) or other processing unit with data processing capabilities and / or instruction execution capabilities, and may control other components in the electronic device to perform desired functions. In one embodiment of this disclosure, the processor is used to execute computer-readable instructions stored in the memory, causing the electronic device to perform all or part of the steps of the structured text program generation methods of the foregoing embodiments of this disclosure.

[0124] Those skilled in the art will understand that, in order to solve the technical problem of how to achieve a good user experience, this embodiment may also include well-known structures such as communication buses and interfaces, and these well-known structures should also be included within the protection scope of this disclosure.

[0125] like Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present disclosure. It illustrates a structural schematic diagram suitable for implementing the electronic device in the embodiment of the present disclosure. Figure 4 The electronic device shown is merely an example and should not be construed as limiting the functionality and scope of the embodiments disclosed herein.

[0126] like Figure 4As shown, an electronic device may include a processing unit (such as a central processing unit, graphics processing unit, etc.) that can perform various appropriate actions and processes based on a program stored in read-only memory (ROM) or a program loaded from a storage device into random access memory (RAM). The RAM also stores various programs and data required for the operation of the electronic device. The processing unit, ROM, and RAM are interconnected via a bus. Input / output (I / O) interfaces are also connected to the bus.

[0127] Typically, the following devices can be connected to the I / O interface: input devices, such as sensors or visual information acquisition devices; output devices, such as displays; storage devices, such as magnetic tapes or hard drives; and communication devices. Communication devices allow electronic devices to exchange data wirelessly or via wired communication with other devices, such as edge computing devices. Although Figure 4 Electronic devices with various devices are shown, but it should be understood that it is not required to implement or have all of the devices shown. More or fewer devices may be implemented or have instead.

[0128] In particular, according to embodiments of this disclosure, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments of this disclosure include a computer program product comprising a computer program carried on a non-transitory computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from a storage device, or installed from a ROM. When the computer program is executed by a processing device, all or part of the steps of the structured text program generation method of embodiments of this disclosure are performed.

[0129] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0130] A computer-readable storage medium according to embodiments of the present disclosure stores non-transitory computer-readable instructions. When these non-transitory computer-readable instructions are executed by a processor, all or part of the steps of the structured text program generation methods described in the foregoing embodiments of the present disclosure are performed.

[0131] The aforementioned computer-readable storage media include, but are not limited to: optical storage media (e.g., CD-ROM and DVD), magneto-optical storage media (e.g., MO), magnetic storage media (e.g., magnetic tape or portable hard drive), media with built-in rewritable non-volatile memory (e.g., memory card), and media with built-in ROM (e.g., ROM cartridge).

[0132] For a detailed description of this embodiment, please refer to the corresponding descriptions in the foregoing embodiments, which will not be repeated here.

[0133] The basic principles of this disclosure have been described above with reference to specific embodiments. However, it should be noted that the advantages, benefits, and effects mentioned in this disclosure are merely examples and not limitations, and should not be considered as essential features of each embodiment of this disclosure. Furthermore, the specific details disclosed above are for illustrative and facilitative purposes only, and are not limitations. These details do not limit the scope of this disclosure to the necessity of employing the aforementioned specific details for implementation.

[0134] In this disclosure, relational terms such as "first" and "second" are used merely to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. The block diagrams of devices, apparatuses, devices, and systems involved in this disclosure are merely illustrative examples and are not intended to require or imply that they must be connected, arranged, or configured in the manner shown in the block diagrams. As those skilled in the art will recognize, these devices, apparatuses, devices, and systems can be connected, arranged, and configured in any manner. Words such as "comprising," "including," "having," etc., are open-ended terms meaning "including but not limited to," and are used interchangeably with them. The terms "or" and "and" as used herein refer to the terms "and / or," and are used interchangeably with them unless the context clearly indicates otherwise. The term "such as" as used herein refers to the phrase "such as but not limited to," and is used interchangeably with it.

[0135] Additionally, as used herein, the "or" used in a list of items beginning with "at least one" indicates a separate list, such that a list of, for example, "at least one of A, B, or C" means A or B or C, or AB or AC or BC, or ABC (i.e., A and B and C). Furthermore, the word "exemplary" does not imply that the described example is preferred or better than other examples.

[0136] It should also be noted that in the systems and methods of this disclosure, the components or steps can be decomposed and / or recombined. These decompositions and / or recombinations should be considered as equivalent solutions to this disclosure.

[0137] Various changes, substitutions, and modifications can be made to the techniques described herein without departing from the teachings defined in this embodiment. Furthermore, the scope of this embodiment is not limited to the specific aspects of the processes, machines, manufacturing processes, events, means, methods, and actions described above. Currently existing or later-developed processes, machines, manufacturing processes, events, means, methods, or actions that perform substantially the same function or achieve substantially the same result as the corresponding aspects described herein can be utilized. Therefore, this embodiment includes such processes, machines, manufacturing processes, events, means, methods, or actions within its scope.

[0138] The above description of the disclosed aspects is provided to enable any person skilled in the art to make or use this disclosure. Various modifications to these aspects will be readily apparent to those skilled in the art, and the general principles defined herein may be applied to other aspects without departing from the scope of this disclosure. Therefore, this disclosure is not intended to be limited to the aspects shown herein, but rather to be carried out within the widest scope consistent with the principles and novel features disclosed herein.

[0139] The above description has been given for purposes of illustration and description. Furthermore, this description is not intended to limit the embodiments of this disclosure to the forms disclosed herein. Although numerous exemplary aspects and embodiments have been discussed above, those skilled in the art will recognize certain variations, modifications, alterations, additions, and sub-combinations therein.

Claims

1. A method for generating structured text programs, characterized in that, include: Based on the acquired natural language control requirements, fixed structured text program interface, and public PLC scanning semantics, the task to be generated as a structured text program is obtained. In response to the task of generating a structured text program, a prompt message is obtained based on visible verification evidence, which is obtained based on the historical verification results of the visible verification chain; The large language model is invoked to generate a structured text candidate program based on the prompt information; The candidate program is submitted to the visible verification chain for verification, which includes compilation checks, formal property verification, and a first dynamic test. When the candidate program passes the visible verification chain, the candidate program is submitted to the sealed verification gate for judgment. The sealed verification gate uses a second dynamic test, and the judgment content of the sealed verification gate is not transmitted to the large language model. The second dynamic test trajectory does not overlap with the first dynamic test trajectory. If the determination result of the sealing verification door is successful, the candidate program is output, thus obtaining the structured text program.

2. The structured text program generation method according to claim 1, characterized in that, The visible verification evidence is obtained by the failure of the structured text candidate program generated by the previous round of the large language model through the visible verification chain. Specifically: When the structured text candidate program generated by the previous large language model fails to be verified after being submitted to the visible verification chain, the verification results of each visible verification gate in the visible verification chain are aggregated into a demand-level evidence state. The requirement-level evidence state includes: aggregating the required number, failed requirement number, failure type, summary, and counterexample trajectory returned by each visible verification gate into a candidate set of confirmed failed evidence and a set of supporting requirements; establishing discrete states including failing, supported, previously_supported, and not_yet_supported for each requirement in the requirement set; and generating a stable signature for each failed piece of evidence, which is calculated from the tool, failure type, sorted requirement number, normalized summary, and Oracle state.

3. The structured text program generation method according to claim 1, characterized in that, The prompt information includes the demand status, non-regression Anchor, and failed certificate; The requirement status records the support status of each requirement in the current candidate program, the non-regression Anchor is used to indicate the candidate program with the best comprehensive verification evidence in the current round, and the failure certificate is used to record the verified failure evidence.

4. The structured text program generation method according to claim 1, characterized in that, After the step of submitting the candidate program to the seal verification gate for judgment, the method further includes: If the seal verification gate fails and the seal query limit is not reached, a restricted blind restart across rounds is initiated, the visible historical data of the large language model is cleared, and the next generation round begins.

5. The structured text program generation method according to claim 1, characterized in that, When the candidate program fails the visible verification chain, a non-regression Anchor is selected from the historical candidates of the current epoch, and a prompt message is constructed based on the demand-level evidence state, the non-regression Anchor, and the historical failure memory of the current epoch. Selecting a non-regressive Anchor includes: calculating the lexicographical score of each candidate program within the current epoch, wherein the parameters for calculating the lexicographical score include the number of security-critical requirements supported by the candidate program, the total number of requirements supported by the candidate program, the number of visible verification gates passed by the candidate program, the negative of the number of different failure signatures of the candidate program, and the candidate program number; and selecting the candidate program with the highest lexicographical score as the non-regressive Anchor.

6. The structured text program generation method according to claim 5, characterized in that, Select non-regression anchors from the historical candidates of the current epoch, and construct cue information based on the demand-level evidence state, non-regression anchors, and historical failure memories of the current epoch, including: Within the fixed character budget, priority is given to retaining the latest candidate and confirmed failed evidence of valid anchors. Other failed evidence is compressed into historical memory according to stable signatures. Evidence selection is based on the priority order of security critical requirements, blocking errors, signature occurrence count, counterexample trajectory length, and signature lexicographical order. When the character budget is exceeded, older historical and low-priority evidence is deleted first, while the requirement number and current discrete state are retained.

7. The structured text program generation method according to claim 1, characterized in that, The visible verification chain includes: response format and interface check gate, duplicate candidate check gate, IEC compiler compilation gate, formal verification gate, and visible dynamic test gate.

8. The structured text program generation method according to claim 1, characterized in that, The candidate program is submitted to the sealing verification gate for judgment. If the result is a failure, only the verification failure status is returned to the large language model. The rejected candidate program, sealing status, summary, evidence, input trajectory and output trajectory are not returned to the large language model.

9. The structured text program generation method according to claim 1, characterized in that, It also includes setting an upper limit for the total number of candidate programs, an upper limit for sealed queries, and an upper limit for restorative restarts; and outputting a confirmed termination status when the number of candidates, the number of sealed queries, or the number of restorative restarts are reached.

10. An electronic device, characterized in that, The electronic device includes: At least one processor; and, A memory communicatively connected to the at least one processor; wherein, The memory stores instructions that can be executed by the at least one processor to enable the at least one processor to perform the structured text program generation method according to any one of claims 1-9.

Images