Ladder program automatic generation method and system, and storage medium

Abstract

The application relates to the technical field of industrial automation control, in particular to a ladder diagram program automatic generation method and system and a storage medium. The application acquires control demand information for a programmable logic controller, generates instruction logic representation information including contact logic, coil driving relationship and execution time sequence based on the control demand information, generates a ladder diagram program accordingly, generates an input time line and a plurality of corresponding check assertions based on the instruction logic representation information and the ladder diagram program, simulates the cyclic scanning of the programmable logic controller by taking the input time line as an input excitation, respectively compares the obtained state snapshots at each sampling moment with the check assertions, determines a failure attribution and an attribution object according to the check assertions with differences in the comparison when the simulation fails, carries out revision processing on the attribution object and updates the verification result, determines the ladder diagram program that passes the verification as a target ladder diagram program, and improves the generation correctness of the programmable logic controller program.

Description

Technical Field

[0001] This application relates to the field of industrial automation control technology, and in particular to a method and system for automatically generating ladder diagram programs, as well as a storage medium thereof. Background Technology

[0002] In the field of industrial automation control, programmable logic controllers (PLCs) are the core devices for equipment control, and their control programs have long relied on manual programming by programmers. With the development of artificial intelligence technology, solutions that automatically generate PLC programs based on control requirements described in natural language have gradually emerged, which can alleviate the programming burden on programmers to some extent.

[0003] However, the requirements for automated control often involve the coordination between multiple input signals. Ladder diagram programs need to include the timing of actions and the logic for handling abnormal operating conditions. Currently, automatically generated ladder diagram programs are prone to logical defects, and the means of verifying the generated results in related solutions are limited. When there are errors in the generated results, it is difficult to locate whether the error originated from the understanding of requirements, logic planning, or code implementation. Often, the only way to correct it is to regenerate the entire program. Even after correction, the program may still introduce new defects, and the correctness of the program cannot be guaranteed.

[0004] Therefore, improving the correctness of automatically generated programmable logic control programs has become a research direction with practical significance in the industry. Summary of the Invention

[0005] This application aims to address at least one of the technical problems existing in the prior art. To this end, this application proposes an automatic ladder diagram program generation method, system, and storage medium, which can improve the correctness of automatic generation of programmable logic control programs.

[0006] An automatic ladder diagram program generation method according to a first aspect embodiment of this application includes: Obtain control requirements information for the programmable logic controller; Based on the control requirement information, instruction logic representation information conforming to the instruction list writing specification is generated; wherein, the instruction logic representation information includes contact logic, coil driving relationship and execution timing that match the control requirement information; Based on the instruction logic representation information, a ladder diagram program is generated; Based on the instruction logic representation information and the ladder diagram program, an input timeline and multiple verification assertions corresponding to the input timeline are generated; wherein, the input timeline is used to record the state changes of each input signal in chronological order, and each verification assertion is used to characterize the expected state of the target soft component at the corresponding observation time; Using the input timeline as the input stimulus, the ladder diagram program simulates the cyclic scanning of a programmable logic controller to obtain state snapshots at each sampling time. Each of the verification assertions is compared with the corresponding state snapshot to obtain the verification result; In response to the verification result indicating verification failure, the failure attribution and the attribution object corresponding to the failure attribution are determined based on the verification assertion showing a difference in comparison. Based on the failure attribution, the attribution object is revised. The verification result is updated based on the revised attribution object; In response to the updated verification result indicating that the verification has passed, the ladder diagram program that passed the verification is determined as the target ladder diagram program.

[0007] An automatic ladder diagram program generation system according to a second aspect embodiment of this application, applied to performing the method described in any one of the first aspect embodiments of this application, includes: The requirement acquisition module is used to acquire control requirement information for the programmable logic controller. A planning intelligent agent is used to generate instruction logic representation information that conforms to the instruction list writing specification based on the control requirement information; wherein, the instruction logic representation information includes contact logic, coil driving relationship and execution timing that match the control requirement information; An coded intelligent agent is used to generate a ladder diagram program based on the instruction logic representation information; The test generates an intelligent agent, which is used to generate an input timeline and multiple verification assertions corresponding to the input timeline based on the instruction logic representation information and the ladder diagram program; wherein, the input timeline is used to record the state changes of each input signal in chronological order, and each of the verification assertions is used to characterize the expected state of the target soft component at the corresponding observation time; A quality verification agent is configured to use the input timeline as input stimulus to simulate a cyclic scan of a programmable logic controller in the ladder diagram program, and obtain state snapshots at each sampling time; compare each verification assertion with the corresponding state snapshot to obtain a verification result; and, in response to the verification result indicating verification failure, determine the failure attribution and the attribution object corresponding to the verification assertion with discrepancies in the comparison. An orchestration agent is configured to, based on the failure attribution, schedule a corresponding agent to revise the attribution object, and trigger the quality verification agent to update the verification result based on the revised attribution object; and, in response to the updated verification result indicating that the verification has passed, determine the ladder diagram program when the verification has passed as the target ladder diagram program.

[0008] Thirdly, embodiments of this application provide a computer-readable storage medium storing a program that is executed by a processor to implement the automatic generation method of a ladder diagram program as described in any one of the embodiments of the first aspect of this application.

[0009] The automatic generation method, system, and storage medium for ladder diagram programs according to embodiments of this application have at least the following beneficial effects: This application first generates instruction logic representation information conforming to instruction list writing specifications based on control requirement information, and then generates a ladder diagram program based on the instruction logic representation information. This ensures that the contact logic, coil driving relationship, and execution timing are determined before program generation. Requirements understanding and code implementation are decomposed into two interconnected stages, each leaving verifiable outputs. When errors are detected, the source of the error can be traced back along both layers of outputs. The input timeline and verification assertions are generated based on the same instruction logic representation information and ladder diagram program, forming a machine-executable verification basis. Using the input timeline as input stimulus, the programmable logic controller's cyclic scanning is simulated, obtaining state snapshots at each sampling moment and comparing them line by line with each verification assertion. This ensures that the dynamic behavior of the ladder diagram program is actually executed and verified before delivery. The existence of programmable logic controller (PLC) defects has clear criteria for judgment. When verification fails, the cause of failure and the corresponding cause object are determined based on the verification assertions that show differences. The revision process is applied to the cause object, and the instruction logic representation information, ladder diagram program, input timeline, and parts of the verification assertions that are not involved in the error remain unchanged. This avoids the overall regeneration from which existing correct content is destroyed and new defects are introduced. After the revision process, the verification result is updated based on the revised cause object. When the updated verification result indicates that the verification has passed, the ladder diagram program at the time of verification is determined as the target ladder diagram program. The correctness of each revision is actually confirmed by a new round of simulation scanning and assertion comparison. The final target ladder diagram program is based on the premise of passing the verification, thereby improving the generation correctness of the PLC program.

[0010] Additional aspects and advantages of this application will be set forth in part in the description which follows, and in part will be obvious from the description, or may be learned by practice of this application. Attached Figure Description

[0011] The above and / or additional aspects and advantages of this application will become apparent and readily understood from the description of the embodiments taken in conjunction with the following drawings, in which: Figure 1 A flowchart illustrating an automatic ladder diagram generation method provided in an embodiment of this application; Figure 2 Another flowchart illustrating the automatic generation method of the ladder diagram program provided in the embodiments of this application; Figure 3 Another flowchart illustrating the automatic generation method of the ladder diagram program provided in the embodiments of this application; Figure 4 Another flowchart illustrating the automatic generation method of the ladder diagram program provided in the embodiments of this application; Figure 5 Another flowchart illustrating the automatic generation method of the ladder diagram program provided in the embodiments of this application; Figure 6A This is a flowchart of the ladder diagram generation program corresponding to the embodiments of this application; Figure 6B This is a flowchart illustrating the processing of the planning agent in the embodiments of this application; Figure 6C This is a flowchart illustrating the processing of the coded intelligent agent corresponding to the embodiments of this application; Figure 6D This is a flowchart illustrating the process of generating an intelligent agent for testing, corresponding to an embodiment of this application. Figure 6E This is a flowchart illustrating the processing of the quality verification agent corresponding to the embodiments of this application; Figure 6F This is a flowchart illustrating the verification and repair process corresponding to an embodiment of this application. Figure 7 This is a schematic diagram of the hardware structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0012] The embodiments of this application are described in detail below. Examples of these embodiments are shown in the accompanying drawings, wherein the same or similar reference numerals denote the same or similar elements or elements having the same or similar functions throughout. The embodiments described below with reference to the accompanying drawings are exemplary and are only used to explain this application, and should not be construed as limiting this application.

[0013] In the description of this specification, the terms "one embodiment," "some embodiments," "illustrative embodiment," "example," "specific example," or "some examples," etc., refer to specific features, structures, materials, or characteristics described in connection with that embodiment or example, which are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. The identification of specific steps below does not imply a limitation on the order of steps or execution logic; the execution order and execution logic between the steps should be understood and inferred from the content described in the embodiments.

[0014] In the field of industrial automation control, programmable logic controllers (PLCs) are the core devices for equipment control, and their control programs have long relied on manual programming by programmers. With the development of artificial intelligence technology, solutions that automatically generate PLC programs based on control requirements described in natural language have gradually emerged, which can alleviate the programming burden on programmers to some extent.

[0015] However, the requirements for automated control often involve the coordination between multiple input signals. Ladder diagram programs need to include the timing of actions and the logic for handling abnormal operating conditions. Currently, automatically generated ladder diagram programs are prone to logical defects, and the means of verifying the generated results in related solutions are limited. When there are errors in the generated results, it is difficult to locate whether the error originated from the understanding of requirements, logic planning, or code implementation. Often, the only way to correct it is to regenerate the entire program. Even after correction, the program may still introduce new defects, and the correctness of the program cannot be guaranteed.

[0016] Therefore, improving the correctness of automatically generated programmable logic control programs has become a research direction with practical significance in the industry.

[0017] The following explanation is based on the accompanying drawings.

[0018] Reference Figure 1 The automatic generation method for ladder diagram programs according to embodiments of this application may include: Step S101: Obtain control requirement information for the programmable logic controller; Step S102: Based on the control requirement information, generate instruction logic representation information that conforms to the instruction list writing specification; wherein, the instruction logic representation information includes contact logic, coil driving relationship and execution timing that match the control requirement information; Step S103: Generate a ladder diagram program based on the instruction logic representation information; Step S104: Based on the instruction logic representation information and the ladder diagram program, generate an input timeline and multiple verification assertions corresponding to the input timeline; wherein, the input timeline is used to record the state changes of each input signal in chronological order, and each verification assertion is used to characterize the expected state of the target soft component at the corresponding observation time; Step S105: Using the input timeline as the input stimulus, simulate the cyclic scanning of the programmable logic controller in the ladder diagram program to obtain state snapshots at each sampling time. Step S106: Compare each verification assertion with the corresponding state snapshot to obtain the verification result; Step S107: In response to the verification result indicating verification failure, determine the failure attribution and the attribution object corresponding to the failure attribution based on the verification assertions that show differences in comparison. Step S108: Based on the failure attribution, revise the attribution object; Step S109: Update the verification results based on the revised attribution objects; Step S110: In response to the updated verification result indicating that the verification has passed, the ladder diagram program when the verification has passed is determined as the target ladder diagram program.

[0019] In step S101 of this embodiment, control requirement information for the programmable logic controller is obtained; It should be noted that control requirement information refers to information describing the control tasks that the programmable logic controller (PLC) should perform. Its content typically includes the composition of the controlled object, the configuration of field input and output devices, and the operational relationships and control requirements that should be achieved between these devices. In traditional development methods, programmers manually write programs based on experience after reading the control requirements; the requirements exist only in the programmer's understanding. The generation process in this application embodiment is based on machine processing. The control requirements must first be received and carried in the form of information before subsequent stages have a common processing object. This step establishes the original basis for all products; the instruction logic representation information, ladder diagram program, input timeline, and verification assertion content can all be traced back to the control requirement information. The content on the requirement side will not be added or omitted arbitrarily in subsequent stages.

[0020] In step S102 of this embodiment, instruction logic representation information conforming to the instruction list writing specification is generated based on control requirement information; wherein, instruction logic representation information includes contact logic, coil driving relationship and execution timing that match the control requirement information; It should be noted that an instruction list (IP) is a text-based programming language used in the field of programmable logic controllers (PLCs). It is included in relevant international standards, with each instruction occupying a single line. The control logic is expressed in the order of the statements. The IPC writing standard refers to the guidelines that should be followed when writing such statements. The logical description information formed according to this standard is the instruction logic representation information. Its content includes: contact logic reflecting the on / off relationships between various input conditions, i.e., which input conditions enable the logic to conduct; coil drive relationships reflecting which output or internal components are driven by the results of logical operations; and execution timing reflecting the sequence of actions and time-related constraints such as delays. These three parts match the control requirement information; the logical content expressed by the representation information is the control content required by the requirement.

[0021] It should be understood that control requirements described in natural language have room for ambiguity, and the same requirement text may be interpreted in different ways to convey different control logics. If the program is directly generated from the requirements, biases at the comprehension level will be mixed into the program and will be difficult to detect later. By first transcribing the control requirement information into instruction logic representation information that conforms to the instruction list writing specifications, the result of the comprehension is solidified into a product with a defined structure and clear meaning. Whether the comprehension is accurate has a test object before program generation. The program generation process has a clear basis, and when errors are finally verified in the program, this intermediate product can be used to distinguish whether the error occurred at the requirement comprehension level or the program implementation level.

[0022] Reference Figure 2 According to some embodiments of this application, step S102, based on control requirement information, generates instruction logic representation information conforming to the instruction list writing specification, which may include: Step S201: Based on the control requirement information, determine multiple soft components and generate soft component annotation information; wherein, the soft component annotation information includes the component address, component type and functional description of each soft component in the control requirement information. Step S202: Establish the input-output mapping relationship of control requirement information; wherein, the input-output mapping relationship is used to characterize the mapping relationship between input signals, output signals and the component addresses of each soft component; Step S203: Logically analyze the control requirement information to obtain the contact logic, coil driving relationship and execution timing that match the control requirement information; Step S204: Generate instruction table program segments according to contact logic, coil driving relationship and execution timing; Step S205: Integrate the soft component annotation information, input / output mapping relationship and instruction table program segment to obtain instruction logic representation information.

[0023] In some embodiments, step S201 involves determining multiple soft components based on control requirement information and generating soft component annotation information; wherein, the soft component annotation information includes the component address, component type, and functional description of each soft component in the control requirement information. It should be noted that soft components are the basic units within a programmable logic controller (PLC) responsible for state storage and logical operations. They evolved from the physical relays in early relay control systems, and each soft component has a unique identifier within the controller. The input devices, output devices, and intermediate states required during control mentioned in the control requirements information are all mapped to specific soft components within the PLC. This step first identifies these soft components from the control requirements information. The generated soft component annotation information includes three parts: the component address (the soft component's identifier within the controller, used for all references in the program); the component type (distinguishing the type of soft component; input, output, auxiliary, timing, counting, and data storage components, etc., are categorized differently); and the functional description (describes the function of the soft component in the control requirements information, allowing the reader to understand the correspondence between each soft component and the control task). The soft component annotation information centrally registers all soft components used in the program, providing a reference for program reading and verification, and a unified source for referencing soft components when writing subsequent instructions.

[0024] In some embodiments, step S202 involves establishing an input-output mapping relationship for control requirement information; wherein the input-output mapping relationship is used to characterize the mapping relationship between input signals, output signals, and the component addresses of each soft component. It's important to note that control requirements are typically described using the names of field devices, while the program internally operates on specific software components using their addresses. A correspondence needs to be established between these two levels, and the input-output mapping relationship serves this connection. Input signals are the manifestation of the field device's action on the controller's input side, while output signals are the driving results sent from the controller's output side to the field device. The mapping relationship maps each input and output signal to a specific component address. Once this mapping relationship is established, the devices mentioned in the requirement text and their addresses in the program statements are no longer disconnected. When writing instructions, there is a clear guide to which address to reference, and subsequent reading of the program allows for the lookup of the corresponding field device from the address.

[0025] In step S203 of some embodiments, the control requirement information is logically parsed to obtain the contact logic, coil driving relationship and execution timing that match the control requirement information; It should be noted that logical parsing refers to identifying the logical content of control requirements from the textual description of control demand information and transforming the identification results into structured logical information. The parsed contact logic comes from the description of action conditions in the demand, i.e., which conditions allow action; the coil driving relationship comes from the description of the action object in the demand, i.e., which component drives the external action after the conditions are met; the execution sequence comes from the description of the action order and delay requirements in the demand, i.e., the order and interval of each action. Control demand information is written in natural language, and these three types of logical content are often intertwined in the same text. After parsing, they are extracted and clarified separately. Each control requirement in the demand is thus translated into specific logical content, eliminating the need to reread the meaning of the demand text when writing the next instruction statement.

[0026] In some embodiments, step S204 generates an instruction table program segment according to the contact logic, coil driving relationship, and execution timing. It should be noted that the instruction list program paragraph is the written representation of the three types of logical content obtained from the parsing, and it is written according to the instruction list writing specifications. Contact logic, coil driving relationships, and execution timing guide different aspects of the content within the paragraph. Conditional combinations are written based on contact logic, component driving is written based on coil driving relationships, and the order of statements is arranged according to the execution timing. Since the content of the paragraph directly originates from the results of logical parsing, the information required for the writing process is already complete during the parsing stage. The writing itself no longer relies on a secondary understanding of the requirements, thus ensuring a path for consistency between the paragraph and the requirements.

[0027] Reference Figure 3 According to some embodiments of this application, after step S204 generates the instruction table program segment according to the contact logic, coil driving relationship and execution timing, the embodiments of this application further include performing contract verification on the instruction table program segment to obtain the contract verification result, which may specifically include: Step S301: Extract the drive type instructions from the instruction table program segment and determine the address of the component driven by each drive type instruction; wherein, the drive type instructions include output instructions, set instructions and reset instructions. Step S302: The extracted driver type instructions are grouped according to the component address to obtain the driver type instructions corresponding to each component address; Step S303: If there is a component address driven by multiple output instructions, the component address is determined to be a conflicting address; Step S304: If there is a component address that is driven by both an output instruction and a set instruction or a reset instruction, the component address is determined as a mixed address. Step S305: Based on the determined conflicting and mixed addresses, generate the contract verification result.

[0028] In some embodiments, step S301 involves extracting drive type instructions from the instruction list program segment and determining the address of the component driven by each drive type instruction; wherein, the drive type instructions include output instructions, set instructions, and reset instructions. It should be noted that driver-type instructions refer to instructions that directly write the result or state of a logical operation to a soft device, including three categories: output instructions, set instructions, and reset instructions. Output instructions write the result of the current logical operation to the corresponding device address in real time; set instructions set the corresponding device address to a valid state and retain it; and reset instructions clear the retained state of the corresponding device address. The instruction list program segment also contains other instructions for reading input conditions and performing logical operations. Since contract verification is concerned with the correctness of the driving relationships, this step first extracts the driver-type instructions from the segment and determines the device address driven by each driver-type instruction. The extraction and determination results fully present the fact that which instruction drives which in the program segment, and subsequent detection work is based on this fact.

[0029] In step S302 of some embodiments, the extracted driver type instructions are aggregated according to the component address to obtain the driver type instructions corresponding to each component address; It's important to note that aggregation refers to grouping driver-type instructions scattered across different locations in the instruction list program segment, using component addresses as the dimension. This ensures that each component address corresponds to all the driver-type instructions that drive it. The previous step yielded driver facts at the instruction level, but whether the same component address is driven by multiple locations or by different types of instructions can only be determined from the perspective of the component address itself. After aggregation, the number of instructions driving any given component address and the types of instructions driving it can be directly read from the aggregation results, thus providing the statistical basis for verification.

[0030] In step S303 of some embodiments, if there is a component address driven by multiple output instructions, the component address is determined to be a conflicting address; It should be noted that programmable logic controllers (PLCs) operate in a cyclic scanning manner. Within the same scan cycle, the output instruction executed later will overwrite the result written by the output instruction executed earlier for the same element address. If the same element address is driven by multiple output instructions, the final state of that element address depends on the output instruction in the sequence. The logic of the output instructions in the sequence is rendered invalid during execution, and the actual behavior of the program deviates from the logic expected by the writer. Such deviations are not easily detected when statically reading the program. This step identifies element addresses driven by multiple output instructions as conflicting addresses, marking this multi-coil conflict problem with a clear address format.

[0031] In step S304 of some embodiments, if there is a component address that is driven by both an output instruction and a set instruction or a reset instruction, the component address is determined to be a mixed address. It's important to note that output instructions and set / reset instructions update the state of soft devices using different mechanisms. Output instructions write the result of logical operations in real time and refresh the state once per scan cycle, while set and reset instructions maintain the state after being set until a reset occurs. If the same device address is driven by these two different mechanisms, its state will be alternately rewritten by both real-time writing and state maintenance mechanisms, resulting in unpredictable behavior that varies with the scan order. This step identifies device addresses driven by both output instructions and set or reset instructions as mixed addresses, clearly marking the mixed driving mechanism problem in address form to distinguish it from conflicting addresses. The causes and subsequent modification methods for these two types of problems are different.

[0032] In some embodiments, step S305 generates a contract verification result based on the determined conflicting and mixed addresses; It should be noted that this step generates a contract verification result based on the identified conflicting and mixed addresses. When an address is detected, the contract verification result carries the address of the problematic component and its problem category, clearly indicating where the problem is located and what type of problem it is; when no address is detected, the contract verification result indicates that the verification passed. The contract verification result serves as the verification conclusion of the instruction list program segment in terms of the driving relationship, providing a clear basis for whether to use the segment to generate the ladder diagram program in the future.

[0033] Reference Figure 4 According to some embodiments of this application, step S204, which generates an instruction list program segment based on contact logic, coil driving relationship, and execution timing, may include: Step S401: Assign a corresponding instruction driving paradigm to each component address; wherein, the instruction driving paradigm is either a real-time output paradigm or a status latch paradigm. Step S402: Generate the drive type instruction corresponding to each component address according to the coil drive relationship and the instruction drive paradigm corresponding to each component address; Step S403: Generate logical operation instructions according to the contact logic; Step S404: Arrange the logical operation instructions and the driver type instructions according to the execution sequence to obtain the instruction table program segment.

[0034] In step S401 of some embodiments, a corresponding instruction-driven paradigm is specified for each element address; wherein, the instruction-driven paradigm is a real-time output paradigm or a state latching paradigm. It's important to note that the instruction-driven paradigm refers to the agreed-upon method for driving component addresses. The real-time output paradigm writes the result of logical operations to the component address in real-time using output instructions. In this mode, the state of the component address is refreshed with the result of the logical operation in each scan cycle. The state-latching paradigm sets the component address to a valid state using a set instruction and resets it to an invalid state using a reset instruction. In this mode, the state of the component address remains unchanged after being set until a reset occurs. Each paradigm is suitable for different control scenarios. The real-time output paradigm is suitable for situations requiring real-time adaptation to changes in logical conditions, while the state-latching paradigm is suitable for situations requiring the memorization of an event until a clear instruction is received. Assigning a separate instruction-driven paradigm to each component address means that the driving method for each component address is uniquely agreed upon before instruction generation. This provides a unified standard for writing subsequent driving instructions, preventing the same component address from being used interchangeably with different driving methods, thus making the program's behavior predictable.

[0035] In step S402 of some embodiments, the driving type instruction corresponding to each component address is generated according to the coil driving relationship and the instruction driving paradigm corresponding to each component address. It's important to note that generating driver type instructions requires two considerations: the coil driving relationship addresses what to drive, i.e., which component addresses should be driven by the result of the logical operation; the instruction driving paradigm addresses how to drive, i.e., which type of instruction to use for each component address. Combining these two considerations determines the driver type instruction for each component address. The driving content and driving method originate from the results of requirements analysis and the prior paradigm agreement, respectively. These two sources are different and independently determined, but they converge in this step to form specific instructions. Therefore, there is no room for arbitrary instruction selection in the generation of driver instructions.

[0036] According to some embodiments of this application, step S402, which generates drive type instructions corresponding to each component address based on the coil drive relationship and the instruction drive paradigm corresponding to each component address, may include: If the instruction driving paradigm of the component address is specifically a real-time output paradigm, then a corresponding output instruction is generated for the component address. If the instruction-driven paradigm for a component address is specifically a state latching paradigm, then for that component address, the corresponding set and reset instructions are generated. It should be noted that for a component address in the real-time output paradigm, a corresponding output instruction is generated. In the real-time output paradigm, the state of the component address is entirely determined by the result of the logical operation. Each scan cycle refreshes the value based on the operation result, and a single output instruction is sufficient to fully express the driving relationship for that component address. By limiting the output instruction to one, the driving logic is centralized in one place in the program structure. During reading and maintenance, there is no need to search for other driving locations for the same component address in the program. This also avoids the situation where the same component address is driven by multiple output instructions from the generation source, forming a combination of prior agreement and post-verification with the conflict address detection in the aforementioned contract verification. In some more specific embodiments, the output Y000 of the motor start-stop self-holding control is the motor contactor coil, the input X000 is the start button, and the input X001 is the stop button. When the start button is pressed or the self-locking contact of the motor output is turned on, and the stop button is not pressed, the motor output is driven. The entire driving relationship is fully expressed by a single output instruction for Y000, and there is no second driving location for Y000 in the program.

[0037] Furthermore, for the element address of the state latching paradigm, corresponding set and reset instructions are generated. The working process of the state latching paradigm includes three stages: state activation, state holding, and state deactivation. The set instruction is responsible for state activation, the reset instruction is responsible for state deactivation, and state holding is completed by the paradigm's own mechanism between the two instructions. The set and reset instructions are generated in pairs, and both endpoints of the latching process have clear instructions, preventing situations where a state is activated but there is no way to deactivate it, or where a deactivation instruction exists but no state is ever activated. The latching logic remains complete in terms of instruction structure. In some more specific embodiments, the successful answer signal of a contestant in a two-way buzzer system needs to be latched. The indicator light corresponding to the group of contestants who pressed the button first lights up and remains lit. Subsequent button presses have no effect. The successful answer event activates and holds the corresponding indicator light element through the set instruction. After the host presses the reset button, the current state is cleared by the reset instruction. The set and reset occur in pairs, and the latching process is complete.

[0038] In some embodiments, step S403 involves generating logical operation instructions according to the contact logic. It should be noted that logical operation instructions are responsible for reading and combining input conditions, and are the carriers of the condition section in the instruction list program segment. Contact logic reflects the on / off relationships between various input conditions; converting this relationship into instruction list statements yields the logical operation instructions. The hierarchy of condition combinations remains consistent with the combination relationships expressed by the contact logic, thus ensuring that the required conditional relationships are faithfully implemented in the condition section of the program segment.

[0039] In some embodiments, step S404 involves arranging the logical operation instructions and the driver type instructions according to the execution sequence to obtain an instruction table program segment. It should be noted that arrangement refers to determining the position of each instruction within the instruction list program segment. The programmable logic controller (PLC) executes instructions one by one according to the arrangement order; the arrangement position determines the execution order. The required sequence of actions and delays needs to be translated into a specific statement order through arrangement. This step organizes the logical operation instructions and driver-type instructions generated in the previous steps according to the execution sequence, with the condition section and driver section connecting and cooperating to form a complete instruction list program segment. After this step, the logical content and timing requirements in the control demand information are all translated into writable instruction statements, and the logical body representing the instruction logic information is thus formed.

[0040] According to some embodiments of this application, in step S404, arranging the logical operation instructions and the driver type instructions according to the execution sequence may include: In the process of arranging various logic operation instructions and various drive type instructions, for the element address of the corresponding state latching paradigm, the set instruction is arranged before the reset instruction.

[0041] It should be noted that programmable logic controllers (PLCs) execute instructions sequentially according to their order, with instructions listed earlier executed first and those listed later executed later. The logical order of state latching is to establish the state first, then de-state, placing set instructions before reset instructions to ensure this logical order aligns with the scan execution order, allowing state changes at element addresses to occur in a predictable sequence. If the order is reversed, de-state actions will execute before establishment actions within the same scan cycle, misaligning the state change order with the causal order of the latching logic, thus reducing the predictability of program behavior. This specification fixes the causal order of the latching paradigm during the arrangement phase, combining it with the paired generation phase, thus forming a complete constraint on the state latching paradigm from instruction composition to arrangement.

[0042] In some more specific embodiments, the program of the two-way answer buzzer includes latching logic and reset logic for successful answering. The setting instruction for a successful answer is arranged before the reset instruction corresponding to the reset button. Within the same scan cycle, the state establishment for successful answering is processed first, and the state release for reset operation is processed later. When answering and resetting occur at the same time, the behavior of the program is still determined.

[0043] In some embodiments, step S205 integrates soft element annotation information, input / output mapping relationships, and instruction list program segments to obtain instruction logic representation information; It should be noted that integration refers to combining the three parts generated in the aforementioned steps into a complete product. The instruction list program segment carries the main body of the control logic, the soft component annotation information describes the various soft components referenced in the segment, and the input / output mapping relationship connects the field devices in the requirements with the component addresses in the program. After the three are combined, the instruction logic representation information contains not only the executable logic content but also the registration and correspondence information needed to understand this content. When generating the ladder diagram program based on the instruction logic representation information, the required logic, component, and address correspondences can all be obtained from this product, thus ensuring the integrity of the intermediate product.

[0044] According to some embodiments of this application, step S204, which generates an instruction list program segment based on contact logic, coil driving relationship, and execution timing, may include: Determine the physical contact type of each input signal; wherein, the physical contact type is used to characterize the on / off characteristics of the physical device corresponding to the input signal between the inactive state and the active state; Based on the physical contact type of each input signal and the contact type corresponding to each input signal in the contact logic, determine the read bit instruction for each input signal; where the contact type includes normally open contact and normally closed contact, and the read bit instruction includes normally open read bit instruction and normally closed read bit instruction. In determining the read position command for each input signal, if the input signal has a normally open contact, the instruction contact type of the corresponding read position command is consistent with the physical contact type. In the process of determining the read position instruction for each input signal, if the input signal has a normally closed contact, the instruction contact type of the corresponding read position instruction is opposite to the physical contact type. Write the read instructions corresponding to each input signal into the instruction table program segment.

[0045] In some embodiments, the physical contact type of each input signal is determined; wherein, the physical contact type is used to characterize the on / off characteristics of the physical device corresponding to the input signal between the inactive state and the active state; It should be noted that the input signals come from physical devices in the field, and the switching characteristics of these devices are not the same. Some devices are open when not in operation and closed when in operation, while others are closed when not in operation and open when in operation. The physical contact type describes this switching characteristic. When the program reads the input signal, it reads the actual on / off state of the device contacts. The same logical condition applied to devices with different switching characteristics requires different reading methods to obtain the correct result. This step first determines the physical contact type of each input signal, clarifying the true characteristics of the field devices, so that there is a factual basis for selecting the reading method later. In some more specific embodiments, the field input devices include self-reset normally open buttons, self-reset normally closed buttons, holding switches, and various sensors. A self-reset normally open button is closed when pressed and open when released. A holding switch maintains the current on / off state after being toggled. The physical contact types of various devices are registered one by one during the determination phase.

[0046] In some embodiments, the read instruction for reading each input signal is determined according to the physical contact type of each input signal and the contact type corresponding to each input signal in the contact logic; wherein, the contact type includes normally open contact and normally closed contact, and the read instruction includes normally open read instruction and normally closed read instruction. It should be noted that normally open (NOT) and normally closed (NCD) contacts in contact logic represent logical requirements. NOT contacts require conduction when a condition is met, while NCD contacts require disengagement when a condition is met. Read instructions are commands used by the program to read input signals. Normally open read instructions directly read the on / off state of the signal, while normally closed read instructions read the inverted result of the on / off state. Logical requirements and physical characteristics are not necessarily inherently consistent. If read instructions are selected directly based on contact type without differentiation, the reading result will deviate from the control requirements when the combination of logical requirements and device characteristics is inconsistent. This step considers both physical contact type and contact configuration when determining the read instructions, ensuring that the reading method matches both the actual characteristics of the device and the logical requirements.

[0047] In some embodiments, during the process of determining the read instruction for each input signal, if the input signal has a normally open contact, the instruction contact type of the corresponding read instruction is consistent with the physical contact type. It should be noted that the logic requires normally open contacts, meaning that the input signal should result in conduction when activated. If the physical device happens to conduct when activated, the conduction result can be directly obtained by reading the normally open bit position using a normally open read instruction. As long as the instruction contact type matches the physical contact type, the logic requirement is met. In some more specific embodiments, the start button X000 for motor start / stop control is a self-resetting normally open button. In the contact logic, it serves as the start condition, with a normally open contact type. X000 is read using a normally open read instruction; when the button is pressed, the read result shows conduction, thus fulfilling the start condition, consistent with the intuitive expectation of on-site operation.

[0048] In some embodiments, during the process of determining the read instruction for each input signal, if the input signal has a normally closed contact, the instruction contact type of the corresponding read instruction is opposite to the physical contact type. It should be noted that the logic requires normally closed contacts, meaning that the input signal should be conductive when not activated and disconnected when activated. If the physical device only conducts when activated, the direct reading result is exactly the opposite of the logic requirement. In this case, a normally closed read instruction is used to invert the signal. When not activated, the signal is disconnected; after inversion, it is conductive. When activated, the signal is conductive; after inversion, it is disconnected. This achieves the semantics of normally closed contacts in ladder diagrams. In some more specific embodiments, the stop button X001 for motor start / stop control is a physically normally open button. When not pressed, the signal is disconnected; when pressed, the signal is conductive. The stop condition in the contact logic requires normally conductive and disconnected when pressed. The contact type is normally closed. A normally closed read instruction is used to read X001. When not pressed, the reading result is conductive, and the motor continues to run. When pressed, the reading result is disconnected, and the motor stops. The physically normally open device achieves the effect of a logically normally closed contact.

[0049] In some embodiments, the read bit instructions corresponding to each input signal are written into the instruction table program segment; It should be noted that after the determined read instruction is written into the instruction table program segment, the contact alignment result is implemented in the program. After the program is downloaded to the controller and put into field operation, the actual actions of the field devices are consistent with the logical state read by the program. Pressing the start button turns on the device and pressing the stop button turns it off. The logical behavior of the program matches the actual meaning of the field operation. If the read instruction does not match the physical contact, the signal state read by the program will deviate from the actual action of the device, and the control logic cannot be executed correctly as required. The content written in this step is the read method after the aforementioned alignment process. This kind of deviation is eliminated during the program generation stage.

[0050] In step S103 of this embodiment, a ladder diagram program is generated based on instruction logic representation information; It should be noted that ladder diagram programs, which use graphical logic symbols such as contacts and coils arranged in a ladder-like manner, are a widely used program format in programmable logic controller (PLC) engineering. They can run directly or after format conversion on the target controller and are the final product obtained from the generation process of this application embodiment. Since the generation is based on instruction logic representation information rather than the original control requirement information, each part of the logic in the ladder diagram program can find its corresponding content in the instruction logic representation information. The program generation is based on the established logic for conversion and implementation, and there is no element of fabrication in the generation process. The resulting correspondence between the program and the representation information provides a benchmark for subsequent verification of whether the program faithfully adheres to the established logic, allowing for segment-by-segment comparison.

[0051] According to some embodiments of this application, step S103, which generates a ladder diagram program based on instruction logic representation information, may include: According to the order of statements in the instruction list program segment, each statement is converted into its corresponding program instruction; wherein, the program instruction and its corresponding statement have the same operands; By combining the program instructions according to their corresponding conversion order, a ladder diagram program is obtained.

[0052] In some embodiments, each statement is converted into a corresponding program instruction in the order of the statements in the instruction list program segment; wherein the program instruction and the corresponding statement have the same operands; It's important to note that converting each statement into its corresponding program instruction means rewriting the statements in the instruction list program segment into program instructions in the ladder diagram program. Both forms use the same instruction set; the conversion process involves a change in format, not the logical content. The conversion is performed statement by statement in order. Statements appearing earlier in the instruction list program segment have their converted program instructions also appearing earlier. The programmable logic controller (PLC) executes these instructions sequentially. The order itself is part of the logic, and the conversion process preserves this order, ensuring the predetermined execution order in the representation information is retained in the program. Program instructions and their corresponding statements have the same operands; that is, the address of the component referenced in the statement is the same address referenced in the converted program instruction. The driven object remains unchanged before and after the conversion. This sequential correspondence, coupled with consistent operands, ensures that every program instruction can be traced back to a specific statement in the instruction list program segment. The correspondence between the program and the representation information is established at the instruction level, allowing for sequential comparison when verifying the program's faithfulness to the predetermined logic. In some more specific embodiments, the instruction table program segment of the motor start-stop self-holding control sequentially includes the statement for reading the start button X000, the statement for the parallel motor output Y000 self-locking contact, the statement for reading the normally closed position of the series stop button X001, and the output statement for driving Y000. The order of the program instructions after conversion is consistent with this, and the operands of each program instruction are also X000, Y000, X001, and Y000, which are exactly the same as the corresponding statements.

[0053] In some embodiments, the program instructions are combined according to the conversion order corresponding to each program instruction to obtain the ladder diagram program; It should be noted that combination refers to organizing the program instructions obtained from individual conversions according to their respective conversion order to form a complete ladder diagram program. The conversion order is inherited from the arrangement order of the program segments in the instruction list. Therefore, the sequence of program instructions obtained by combination maintains the same sequential relationship as the original statement sequence, and the predetermined logical order in the program segments falls completely into the ladder diagram program.

[0054] In some more specific embodiments, the ladder diagram program of the two-way answer buzzer contains 18 logic networks, which sequentially carry the reset logic, mandatory answer mode setting, answer start logic, host green light output, violation detection, contestant successful answer latch, indicator light output, confirmation timing and answer timing, etc. The order of each logic network is consistent with the arrangement order of the corresponding content in the instruction table program segment, and the program structure is consistent with the planned order.

[0055] In step S104 of this embodiment, an input timeline and multiple verification assertions corresponding to the input timeline are generated based on instruction logic representation information and ladder diagram program; wherein, the input timeline is used to record the state changes of each input signal in chronological order, and each verification assertion is used to characterize the expected state of the target soft component at the corresponding observation time. It should be noted that the input timeline describes the changes of the field inputs over time. It records the state changes of each input signal at various moments in chronological order, specifying the time, the input signal, and the state it transitions from. When applied to the program, this becomes the input stimulus for the driver program. The target soft component refers to the soft component whose state needs to be examined in the program. This can be an output component driving external devices or an internal component handling intermediate states. Verification assertions indicate the state the target soft component should be in at the corresponding observation moment, constituting a clear expectation of the program's execution result. Logical defects in control programs are often related to time factors. Simply reading the program text statically is insufficient to expose these defects. Only by observing the actual driver program with inputs changing over time and judging based on clear expected states can defects be discovered. It should also be pointed out that both the input timeline and verification assertions are generated based on instruction logic representation information and ladder diagram programs. The test content, control requirements, and actual program content are consistent, ensuring that the test covers the required behavior and fits the actual program structure.

[0056] According to some embodiments of this application, step S104 generates an input timeline and multiple verification assertions corresponding to the input timeline based on instruction logic representation information and ladder diagram program, including generating multiple verification assertions corresponding to the input timeline, which may specifically include: Based on the instruction logic representation information, multiple acceptance items are determined; each acceptance item corresponds to a control requirement in the control requirement information. For each acceptance item, generate at least one corresponding verification assertion; wherein the verification assertion carries the acceptance item identifier corresponding to the acceptance item.

[0057] It should be noted that multiple acceptance items are determined based on the instruction logic representation information. Each acceptance item corresponds to a control requirement in the control requirement information. An acceptance item is a verification unit formed when checking a control requirement in the control requirement information. Whether a control requirement can be met is reflected by whether the corresponding acceptance item passes verification. Acceptance items are determined from the instruction logic representation information because this information carries the contact logic, coil driving relationships, and execution timing that match the control requirement information. Each control requirement in the control requirement information has a corresponding logical arrangement in the instruction logic representation information. Dividing acceptance items based on the instruction logic representation information ensures that each acceptance item corresponds to a control requirement and is also associated with the specific logical content that implements that control requirement. Taking the control requirements of a two-way quiz buzzer system as an example, the control requirements information includes multiple control requirements such as reset, prohibition of illegal buzzing, determination of successful buzzer-ups, and handling of mandatory-answer mode. The acceptance items determined accordingly correspond one-to-one with the control requirements. The reset acceptance item verifies the reset function; the illegal buzzing acceptance item verifies the illegal buzzing determination function; the successful buzzing acceptance items for contestant one and contestant two respectively verify the buzzing determination for each contestant; and the mandatory-answer mode acceptance item verifies the processing logic in mandatory-answer mode. The verification conclusions can thus be given item by item, with a clear verification point for whether each control requirement in the control requirements information is met.

[0058] It needs to be clarified that for each acceptance item, at least one corresponding verification assertion should be generated. Each verification assertion carries an acceptance item identifier corresponding to the acceptance item. A control requirement often requires verification through multiple observation positions and at multiple observation times; therefore, each acceptance item corresponds to at least one verification assertion, and acceptance items with complex control requirements correspond to multiple verification assertions. Using the two-way buzzer system scenario described above, the reset acceptance item corresponds to fourteen verification assertions, verifying the status of each group of indicator lights, prompt lights, and related software components after the reset action. The unauthorized buzzer-in acceptance item corresponds to four verification assertions, the successful buzzer-in acceptance item for contestant one corresponds to six verification assertions, the successful buzzer-in acceptance item for contestant two corresponds to four verification assertions, and the mandatory-answer mode acceptance item corresponds to three verification assertions. The acceptance item identifier carried in the verification assertion is used to mark which acceptance item the verification assertion belongs to. After comparison, the comparison results of each verification assertion are aggregated according to the acceptance item identifier to determine the verification status of each acceptance item. When verification fails, the verification assertions with discrepancies are directly linked to the corresponding control requirements based on their acceptance item identifiers. The control requirements affected by the failure are immediately apparent, providing clear direction for subsequent failure attribution and revision. When verification passes, the pass status of each acceptance item is also statistically analyzed according to its identifier, making the verification and coverage of each control requirement in the control requirements information readily verifiable.

[0059] According to some embodiments of this application, generating at least one corresponding verification assertion for each acceptance item may include: For each acceptance item, determine the corresponding input action time; where the input action time is the moment when the state of the input signal that triggers the control requirement corresponding to the acceptance item changes in the input timeline; The observation time of each verification assertion is determined according to the input action time and the sampling period; wherein, the sampling period is the time interval between adjacent sampling times, the observation time is located after the input action time, and is separated from the input action time by at least one sampling period.

[0060] It should be noted that for each acceptance item, the corresponding input action time must be determined. The input action time is the moment in the input timeline when the state of the input signal that triggers the control requirement corresponding to the acceptance item changes. Each acceptance item corresponds to a control requirement in the control requirement information. The response process of the control requirement is triggered by a specific input signal, and the position in the input timeline where the state of this input signal changes is the corresponding input action time. The input action time provides the anchor point for the timing settings of the verification assertions. The verification assertions check the response result of the ladder diagram program to the input stimulus. The response process begins with the state change of the input signal, and the observation time of the verification assertions needs to be arranged relative to this change process. Taking the acceptance item of contestant one successfully answering in a two-way quiz machine as an example, the input signal that triggers the control requirement corresponding to this acceptance item is contestant one's answer button. The moment in the input timeline when the button changes from off to on is the corresponding input action time for this acceptance item, and the observation time of each verification assertion under this acceptance item is determined based on this moment.

[0061] It should be noted that the observation time for each verification assertion is determined according to the input action time and the sampling period. The sampling period is the time interval between adjacent sampling times, and the observation time is located after the input action time, with at least one sampling period between them. The observation time does not coincide with the input action time because the programmable logic controller (PLC) operates in a cyclic scanning manner. After the input signal changes at the input action time, the ladder diagram program needs to read the state of the input signal during the scan cycle, execute the program instructions of each logic network, and then update the state of the output-side soft components. The state change of the target soft component lags behind the input action time due to the scan execution delay. Observing the target soft component at the input action time would require the program to respond simultaneously with the input change, exceeding the capabilities of the cyclic scanning operation. The resulting comparison failure is due to improper verification assertion settings. Setting the observation time at least one sampling period after the input action time reserves a time window for the program's scan response. The verification assertion checks the state reached by the program after one or more scan cycles, which is compatible with the cyclic scanning operation. Using the above scenario, if contestant one's buzzer button is activated at 1000 ms and the snapshot sampling period is 10 ms, then the observation time for the corresponding validation assertion is set at 1010 ms. As one implementation method, when changes in the input signal need to be transmitted through multiple logic networks before being reflected in the target soft element, the observation time can be set two sampling periods after the input action time, reserving an additional scan period for the logic transmission across networks.

[0062] It should be understood that setting the observation time offset reduces the possibility of unreasonable timing of the verification assertions themselves during the generation stage. Since the verification assertions are aligned with the scan execution rhythm during generation, the number of comparison failures caused by overly strict observation times during the verification phase is correspondingly reduced. The conclusions of failure attribution are less affected by test-side factors, and the verification results more accurately reflect the correctness of the program.

[0063] According to some embodiments of this application, step S104 generates an input timeline and multiple verification assertions corresponding to the input timeline based on instruction logic representation information and ladder diagram program, including generating the input timeline, which specifically may include: Based on control demand information and instruction logic representation information, multiple action moments are determined, as well as the input signals and changed state values ​​corresponding to each action moment; Multiple input records are generated in chronological order of each action, and the multiple input records constitute the input timeline. Each input record includes the action time, the signal identifier of the corresponding input signal, and the changed state value. For continuous input actions, two pairs of input records are generated, which are used to represent the start and end times of the continuous input action, respectively.

[0064] It should be noted that the action moment refers to the moment when the input signal undergoes a state change during the test. The action moment, along with the corresponding input signal and the changed state value, collectively describes an input change. The determination of the action moment is based on both control requirement information and instruction logic representation information. The control requirement information describes the action process in the control scenario, including the sequence and content of each action. The instruction logic representation information records the input signals and their component addresses involved in fulfilling the control requirements, thus allowing the action subjects appearing during the action process to be mapped to specific input signals. Taking the control requirements of a two-way quiz buzzer as an example, the control requirement information describes the action process of the host issuing a start signal, the contestant pressing the buzzer button, and the host performing a reset. Combining the input-output mapping relationship in the instruction logic representation information, these actions correspond to input signals such as contestant one's buzzer button X000, contestant two's buzzer button X001, and reset button X010. The moment each action occurs during the test is the action moment, and the signal value change caused by each action is the changed state value.

[0065] It should be noted that multiple input records are generated in chronological order according to the action moments, and these multiple input records constitute the input timeline. Each input record includes the action moment, the corresponding input signal's signal identifier, and the changed state value. The input record is the basic unit of the input timeline; one input record describes one input change at one action moment. The signal identifier is used to locate the changed input signal, and the changed state value indicates the value that the input signal retains after that action moment. Multiple input records are arranged in chronological order according to the action moments, and the entire change process of the input signal during the test is expressed by this record sequence. During simulation, the input records are applied to the ladder diagram program one by one in chronological order. The input signal state read in each scan cycle is determined by the currently active input record, thus reproducing the action process described by the control requirement information in the simulation. Using the above scenario, when contestant's buzzer button X000 is activated at 1000 ms, the corresponding input record records the action time of 1000 ms, the signal identifier X000 and the changed state value are activated. After the simulation executes to this time, the state of X000 read by the ladder diagram program changes accordingly.

[0066] It should be noted that for continuous input actions, two pairs of input records are generated. These two records represent the start and end times of the continuous input action, respectively. A continuous input action refers to an action in which the input signal maintains an action state for a period of time and then returns to its initial state. Pressing and releasing a button is a typical example of a continuous input action. The input timeline records state changes. One continuous input action involves two state changes: at the start time, the input signal changes to the action state, and at the end time, the input signal returns to its initial state. Therefore, it is represented by two separate input records. The interval between the two input records determines the duration of the action state. The duration directly affects the response process of the ladder diagram program. Control logic involving self-holding, timing, and delay conditions all have requirements on the holding time of the input signal. If only the start time is recorded and not the end time, the input signal will remain in the action state indefinitely during simulation, and the program behavior after the button is released cannot be verified. As one implementation method, the continuous input action of the contestant's answer button X000 is represented by two input records at a start time of 1000 ms and an end time of 1100 ms. The duration of the button being on is 100 ms. The reading results of the ladder diagram program during this duration and the holding behavior after the button is released are both included in the verification scope.

[0067] According to some embodiments of this application, a ladder diagram program is represented in the form of a structured data record; wherein, the ladder diagram program includes multiple logical networks arranged in sequence, each logical network corresponding to a network data object in the structured data record; each logical network includes multiple program instructions, each program instruction including an instruction mnemonic and an operand corresponding to the instruction mnemonic; the last program instruction in each logical network is a network end instruction.

[0068] It should be noted that a ladder diagram program consists of multiple sequentially arranged logic networks, each corresponding to a network data object in a structured data record. A logic network is the basic unit in a ladder diagram program that completes a relatively independent logical function; a coil drive or an interlock relationship is carried by one logic network. Multiple logic networks are arranged sequentially, and the order of arrangement is consistent with the order in which the programmable logic controller (PLC) executes each logic network during cyclic scanning. The execution semantics of the program are reflected by this arrangement. Each logic network corresponds to a network data object, and the boundaries between networks are clearly distinguishable in data organization. Program processing can be performed on a unit basis: logic network. Taking a two-way quiz buzzer program as an example, this program consists of eighteen logic networks. Functions such as reset logic, mandatory answer mode setting, quiz start logic, host green light output, violation detection, contestant successful answer latch, indicator light output, confirmation timing, answer timing, yellow light flashing, and red light timeout output are each carried by their respective logic networks, and each logic network corresponds to a network data object in a structured data record.

[0069] It should be noted that each logic network includes multiple program instructions, each including an instruction mnemonic and a corresponding operand. A program instruction is the smallest unit of execution within a logic network. The instruction mnemonic represents the operation type of the instruction, and the operand represents the soft element to which the instruction acts. The instruction mnemonic and operand work together to completely determine the object and method of operation of a program instruction. The set of program instructions is sufficient to express the contact connection relationship and coil drive relationship of the ladder diagram. Taking the motor start-stop scenario as an example, the start-stop logic consisting of start button X000, stop button X001, and motor contactor Y000 is composed of four program instructions: a fetch instruction with X000 as an operand, an OR instruction with Y000 as an operand, an invert instruction with X001 as an operand, and an output instruction with Y000 as an operand. These four program instructions express the logical relationship that the start contact and the self-holding contact are connected in parallel, then inverted with the stop contact, and finally connected in series to drive the output coil.

[0070] It is important to clarify that the last program instruction in each logical network is the network end instruction. The network end instruction marks the end position of a logical network, clearly defining the scope of each logical network within the program instruction sequence. The existence of the network end instruction allows the program instruction sequence to be accurately divided into individual logical networks. This provides a clear starting and ending point for simulation execution as it progresses segment by segment along the logical networks. Furthermore, program verification and revision can be performed within the scope defined by the network end instruction. Once the instruction scope of each logical network is determined, the hierarchical relationship between the program instruction sequence and the logical networks remains unique in the structured data record, and the program's organizational structure strictly corresponds to the unit of scan execution.

[0071] In step S105 of this embodiment, the ladder diagram program is used as the input timeline as the input stimulus to simulate the cyclic scanning of the programmable logic controller and obtain state snapshots at each sampling time. It should be noted that programmable logic controllers (PLCs) work cyclically, repeating the process of reading inputs, executing programs, and refreshing outputs. This working mode is called cyclic scanning, and the logical effect of the program is formed under this cycle-by-cycle mechanism. This step uses the input timeline as the input stimulus to simulate the execution of the ladder diagram program in a cyclic scanning manner, and records the instantaneous state of each soft component in the program at each sampling moment, obtaining a state snapshot corresponding to each sampling moment. The state snapshot is the state record of the program execution process at the corresponding sampling moment, reflecting the actual state of each soft component at that moment. The execution effect of the ladder diagram program depends on the scanning order and the cycle-by-cycle refresh mechanism. The simulation process follows the same mechanism, so that the obtained state change process is consistent with the actual operation of the program after it is downloaded to the real controller. Subsequent comparisons are only meaningful if they are based on the state snapshots.

[0072] According to some embodiments of this application, step S105, using the input timeline as input stimulus, simulates a cyclic scan of the programmable logic controller in the ladder diagram program to obtain state snapshots at each sampling time, and may include: In each scan cycle, the program instructions in each logic network are executed sequentially according to the arrangement order of each logic network, and the state values ​​of each soft element involved in the ladder diagram program are updated according to the execution results. At each sampling time, the current state value of each soft element is recorded to obtain the corresponding state snapshot; wherein, each state snapshot includes a time field and the state value of each soft element at the time corresponding to the time field.

[0073] It's important to note that a scan cycle is the basic number of rounds in a cyclic scan. A programmable logic controller (PLC) completes one scan cycle after each round of program execution. This simulation proceeds in scan cycles. Within each scan cycle, program instructions in each logic network are executed sequentially according to their arrangement. The execution results of these instructions update the state values ​​of the soft components involved in the ladder diagram program. The order of arrangement is crucial here; logic networks that are executed earlier are executed first, and their updated soft component states can be read by logic networks that are executed later in the same cycle. Different scan orders result in different execution results. The simulation process must follow the same order as the real controller for the simulation to be meaningful. This cycle-by-cycle approach also allows for the reproduction of cross-cycle behavior.

[0074] In some more specific embodiments, the motor start-stop self-holding control drives the output Y000 to conduct during the scan cycle when the start button X000 is pressed. During the scan cycle after the button is released, the position of the self-locking contact reads the updated conduction state of Y000, and the output continues to be maintained. This type of self-holding behavior that depends on the state transmission between previous and subsequent cycles is realistically reproduced in the simulation process of updating the state value cycle by cycle.

[0075] It is important to clarify that the program's execution is continuous, and verification requires comparable data. This step records the current state value of each soft component at each sampling moment, forming a corresponding state snapshot. The time field in the state snapshot records the sampling moment corresponding to that snapshot, and the state value of each soft component records its actual state at that moment. Combining these two, the state of each soft component at any sampling moment can be determined from the snapshot. When comparing the verification assertion with the state snapshot later, there is clear data available to read which snapshot corresponds to the observation moment targeted by the assertion and what the actual state of the target soft component is at that moment. The required runtime data for verification is thus saved in a structured manner. In some more specific embodiments, when simulating the ladder diagram program of a two-way quiz buzzer, state snapshots are recorded at each sampling moment after the start button, contestant's answer button, and reset button are pressed. The state values ​​of the green light on the host's platform, the contestant's indicator light, and the violation warning light in each snapshot can be determined one by one, providing a data foundation for verifying the correctness of the quiz logic.

[0076] According to some embodiments of this application, each verification assertion may further include a comparison method; wherein, the comparison method includes equality comparison and threshold comparison; Each verification assertion is compared with its corresponding state snapshot to obtain the verification result, which may include: For each verification assertion, the state snapshot with the corresponding sampling time no later than the observation time and the largest corresponding sampling time is determined as the target state snapshot; Read the state value corresponding to the target soft component in the target state snapshot; According to the comparison method of the verification assertion, the read state value is compared with the expected state to obtain the comparison result; The verification results are obtained based on the comparison results of each verification assertion.

[0077] It should be noted that each verification assertion can also include a comparison method. These comparison methods include equivalent comparison and threshold comparison. The purpose of the comparison method is to fix the verification rules between the expected state and the read state value, so that subsequent comparisons do not rely on manual interpretation of the graph. The state values ​​of soft components include both switch quantities and numerical quantities. For switch quantities such as indicator lights and auxiliary relays, the same logic state may be represented in different ways in the simulation output, such as True, False, 1, 0, on, or off. Equivalent comparison first unifies these representations to the same logical value, and then checks it against the expected state, avoiding misjudgments of logical errors due to different representations. For numerical quantities such as the current value of a timer, the control requirements are often concerned with whether the timing process has reached the preset point, rather than whether a certain sampling instant is exactly equal to a certain value. Threshold comparison checks the relationship between the read state value and the expected state, which can cover the case where the current value of the timer crosses the preset point. Taking timers numbered T0 to T199 in a programmable logic controller as an example, their timing resolution is 100 ms. If the control requirement is to turn on the output after a delay of 3000 ms, the current value of the timer near the observed time usually changes in steps of 100 ms. Using threshold comparison to check whether the current value has reached the preset value is more in line with the actual working mode of the timer than strictly checking the equality relationship at a certain instant.

[0078] It should be noted that state snapshots are recorded discretely at sampling times, while observation times are determined by the timing of actions required by control. These two types of times generally do not naturally overlap. After the input signal changes at a certain time, the ladder diagram program needs one or more scan cycles to reflect this change on the target soft element. The state of the soft element remains unchanged between two adjacent sampling times. Based on this fact, the state snapshot formed by the most recent sampling before the observation time records the actual state maintained by each soft element at the observation time. Determining it as the target state snapshot is equivalent to converting the continuously maintained element state onto a discrete sampling sequence, achieving the semantics of piecewise constant value maintenance. In some more specific embodiments, the input timeline records the start button being turned on at 1000 ms, the snapshot sampling period is 10 ms, and the observation time of a certain verification assertion is 1005 ms. Therefore, the state snapshot with a sampling time of 1000 ms is determined as the target state snapshot, without reading the non-existent 1005 ms snapshot, nor reverting to the 990 ms snapshot that has not yet reflected the current input change.

[0079] It should be noted that the process involves reading the state value corresponding to the target soft element from the target state snapshot. The target state snapshot records the state values ​​of each soft element at that sampling moment. The verification assertion has already identified the target soft element. The reading action locates the target soft element in the target state snapshot based on this information and retrieves its state value at that moment. During location, matching is performed according to the soft element's address, ensuring a one-to-one correspondence between the target soft element in the verification assertion and the state value in the state snapshot. As one implementation method, each soft element is recorded in the state snapshot in the form of soft element name plus state value. During reading, the corresponding record is retrieved by the element address, and the state value in that record is taken as the read state value. After this step, the expected state abstractly written in the verification assertion is realized as a comparable pair of data: one side is the expected state from the control requirements, and the other side is the actual state value maintained by the target soft element during the observation moment.

[0080] It should be noted that, according to the comparison method of the verification assertions, the read state value is compared with the expected state to obtain the comparison result. The comparison method has been given in the verification assertions, and this step performs the verification according to the comparison method of each verification assertion. When the comparison method is an equal value comparison, the read state value and the expected state are first normalized to a unified logical value, and then the consistency of the normalized value is checked. When the comparison method is a threshold comparison, the relationship between the read state value and the expected state is directly checked to see if it meets the requirements of the verification assertion. Each verification assertion yields a comparison result, which reflects whether the verification assertion is true at the observation time. Continuing with the scenario of the aforementioned two-way buzzer system, the acceptance item for contestant one's successful buzzer-in corresponds to multiple verification assertions. Among them, the verification assertion for contestant one's indicator light uses an equal value comparison to check whether the target soft component Y000 is in the on state at the observation time. Among them, the verification assertion for the confirmation timer uses a threshold comparison to check whether the current value of the timer has reached the preset value at the observation time. Each check assertion yields its own comparison result, thus enabling error localization to be precise down to the specific check assertion and the specific observation time.

[0081] It should be noted that the verification result is obtained based on the comparison results of each verification assertion. If the comparison results of all verification assertions indicate that the verification is true, the verification result indicates that the verification has passed. If the comparison result of any verification assertion indicates that the verification is false, the verification result indicates that the verification has failed, and the differences between the observation time, target soft component, expected state, and read state value corresponding to that verification assertion are recorded. Since each verification assertion carries an acceptance item identifier corresponding to the acceptance item, the verification result, in addition to providing a pass or fail conclusion, also retains the correspondence between the failed verification assertions and the acceptance items. Subsequent failure attribution begins with the verification assertions with discrepancies in the comparison. Here, the verification result serves both as a conclusion determination and as structured evidence, giving the revision process a clear focus.

[0082] In step S106 of this embodiment, each verification assertion is compared with the corresponding state snapshot to obtain the verification result; It should be noted that for each verification assertion, a state snapshot corresponding to its observation time is found, the actual state of the target soft component in the snapshot is read, and then compared with the expected state recorded in the verification assertion. The comparison results of each verification assertion are collected to form the verification result, which indicates whether the verification passed or failed. This line-by-line comparison allows for identification of which verification assertion, at which observation time, caused the deviation between the actual and expected states when verification failed. The time, object, and content of the deviation are all preserved. This information provides a specific entry point for subsequent analysis of the cause of failure. Therefore, the verification not only provides a conclusion but also preserves the basis for forming that conclusion.

[0083] In step S107 of this application embodiment, in response to the verification result indicating verification failure, the failure attribution and the attribution object corresponding to the failure attribution are determined based on the verification assertions that show differences in comparison. It's important to note that the process from receiving control requirements information to creating a deliverable program involves stages such as logical representation, program generation, and test generation. Verification failures may stem from a misunderstanding of the requirements based on the instruction's logical representation, discrepancies between the ladder diagram program and the established logic, or improper settings in the input timeline or verification assertions. Different sources of failure necessitate different modifications to the deliverables; indiscriminately redoing all deliverables is uneconomical and risks damaging already verified content. Failure attribution is a determination of which stage the verification failure originated from, and the attribution object is the specific deliverable requiring revision, as indicated by this determination. Comparing discrepancies in verification assertions records the observation time of the deviation, the target software component, and the content of the deviation, providing clues for tracing the source of failure. Based on this, the failure attribution and the attribution object are determined, and the direction of revision is determined by the analysis conclusions, not by repeated attempts.

[0084] Reference Figure 5 According to some embodiments of this application, step S107, which determines the failure attribution and the corresponding attribution object based on the verification assertions showing differences, may include: Step S501: Verify the sampling match between the observation time of the verification assertion where there is a difference and the corresponding state change time of the input signal in the input timeline; Step S502: In response to the mismatch between the observation time and the corresponding state change time, the attribution object is determined to be the input timeline and the validation assertion; Step S503: In response to the matching of the observation time with the corresponding state change time, the ladder diagram program is checked for consistency by comparing the instruction logic representation information. Step S504: In response to the consistency check detecting inconsistency between the ladder diagram program and the instruction logic representation information, the attribution object is determined to be the ladder diagram program. Step S505: In response to the lack of inconsistency detected during the consistency check, the attribution object is determined to be the instruction logic representation information.

[0085] In step S501 of some embodiments, the sampling match between the observation time of the verification assertion where there is a difference and the state change time of the corresponding input signal in the input timeline is verified.

[0086] It's important to note that sampling matching is used to measure whether the observation time falls within a reasonable response window relative to the state change time. After the input signal changes at the state change time, the ladder diagram program needs to perform a loop scan to reflect this change on the target soft component. Therefore, the observation time should be later than the corresponding state change time, allowing time for the scan execution. If the observation time is set too early, the target soft component may not have completed its response by the observation time, and the verification assertion will fail to match even for a logically correct ladder diagram program. This step places this check first to eliminate timing design problems on the test side with minimal verification cost. The input timeline and verification assertion are generated collaboratively in the same step. The relationship between the observation time and the state change time is an internal attribute of the test product. Verifying this relationship does not require consulting the ladder diagram program and instruction logic representation information. After confirming that the test timing is reasonable, we can then delve into the program and specification layers, checking from shallow to deep to avoid meaningless checks on the program and specifications when the test design itself has flaws.

[0087] Step S502: In response to the mismatch between the observation time and the corresponding state change time, the attribution object is determined to be the input timeline and the validation assertion.

[0088] It's important to note that when the observation time and state change time don't match, the failure stems from the test timing design, indicating a problem attributing the failure to the testing level. The input timeline and validation assertions are identified as the root cause because the mismatch could originate from the state change time setting, the observation time setting, or the relationship between the two times. The input timeline and validation assertions are interdependent during generation; revising only one cannot guarantee the consistency of the revised test timing. By identifying both as root cause objects, subsequent revisions can re-examine all elements of the test timing within the same round, and re-verify after revision, avoiding the problem of only changing the observation time or only changing the state change time while leaving the other side unaddressed.

[0089] Step S503: In response to the matching of the observation time with the corresponding state change time, the ladder diagram program is checked for consistency by comparing the instruction logic representation information.

[0090] It should be noted that after the test timing is confirmed to be reasonable, the scope of the failure reasons narrows down to two aspects: the ladder diagram program and the instruction logic representation information. Consistency verification refers to comparing the ladder diagram program with the instruction logic representation information to verify whether the ladder diagram program accurately implements the contact logic, coil drive relationships, and execution timing recorded in the instruction logic representation information. The ladder diagram program is generated from the instruction logic representation information; in this comparison, the instruction logic representation information is in the specification position, and the ladder diagram program is in the implementation position. When there is a deviation between the implementation and the specification, the deviation itself can explain why the verification assertion comparison fails. This step uses the instruction logic representation information as an intermediate layer to complete the verification, thus providing a comparable benchmark for the correctness of the ladder diagram program, and the verification conclusion can be grounded in the specific differences between the program and the specification.

[0091] Step S504: In response to the consistency check detecting inconsistency between the ladder diagram program and the instruction logic representation information, the ladder diagram program is identified as the cause.

[0092] It should be noted that the inconsistency detected during the consistency check indicates that the ladder diagram program deviates from the logical requirements established by the instruction logic representation information. The error originates in the stage where the ladder diagram program is generated from the instruction logic representation information. Therefore, the failure is attributed to the program implementation level, and the cause is identified as the ladder diagram program. When revising the ladder diagram program subsequently, the inconsistencies detected by the consistency check provide direct clues for the revision. The revised ladder diagram program regains consistency with the instruction logic representation information, and the cause of the comparison failure is thus eliminated.

[0093] Step S505: In response to the lack of inconsistency detected during the consistency check, the attribution object is determined to be the instruction logic representation information.

[0094] It should be noted that even when the test timing is reasonable and the ladder diagram program accurately implements the instruction logic representation information, the verification assertion still fails to match. The reason for the failure can be traced back along the data flow of the solution, falling on the understanding and planning of the control requirements information by the instruction logic representation information. The failure attribution points to the specification level, and the attribution object is determined to be the instruction logic representation information. At this point, the sources at the test layer, program layer, and specification layer have all been covered, and each failure scenario corresponds to a unique and clear attribution object. It should be pointed out that the specification layer is checked last, consistent with the generation dependency relationship between the three layers. Both the ladder diagram program and test products are based on the instruction logic representation information. After downstream level errors are eliminated first, the remaining errors can be attributed to the specification itself. This elimination order ensures the reliability of the attribution conclusion and allows subsequent revisions to accurately target the truly faulty link.

[0095] In step S108 of this embodiment, the attribution object is revised according to the failure attribution. It should be noted that revision processing refers to modifying the attribution object according to the failure attribution determination. The modification targets the specific type of problem the failure attribution points to. The modification applies to the product corresponding to the stage where the failure originated; the instruction logic representation information, ladder diagram program, input timeline, and products not involved in the failure in the verification assertions remain unchanged. Compared to a complete regeneration, this revision method preserves existing content that has already been verified as correct, keeps the scope of modification within necessary limits, and reduces the possibility of introducing new defects during the correction process.

[0096] According to some embodiments of this application, step S108, which involves revising the attribution object based on the failure attribution, may include: revising the instruction logic representation information according to the failure attribution in response to the attribution object being instruction logic representation information; and regenerating the ladder diagram program based on the revised instruction logic representation information.

[0097] It should be noted that, in response to the attribution object being the instruction logic representation information, the instruction logic representation information is revised according to the failure attribution. The failure attribution has already been formed during the previous attribution process, carrying the observation time corresponding to the verification assertions with discrepancies, the target soft component, the difference between the expected state and the read state value, and the conclusion that consistency checks have eliminated program implementation deviations. Revising the instruction logic representation information according to the failure attribution refers to making targeted modifications to the contact logic, coil drive relationships, or execution timing recorded in the instruction logic representation information based on the evidence formed in these verification stages. The revision occurs on the instruction logic representation information, and its purpose is to eliminate errors at the specification level. The instruction logic representation information is located between the control requirement information and the ladder diagram program. Both the ladder diagram program and the test product are generated based on the instruction logic representation information, and deviations in the specification will be propagated to the program and test along the generation direction. If the ladder diagram program is directly repaired without considering the instruction logic representation information, new inconsistencies will appear between the program and the specification, and subsequent verification and rework will lose a comparable benchmark, thus masking the true source of the error. Taking a motor start-stop self-holding scenario as an example, the start button is an input signal for an instantaneous action, and the control requirement is that the motor continues to run after the start button is pressed. If the instruction logic representation information omits the self-holding plan, and the ladder diagram program implements the instruction logic representation information accurately, the target soft component of the motor cannot remain in the connected state at the observation moment when the start button is released. The corresponding verification assertion comparison fails, and the consistency check cannot detect the deviation between the program and the specification. The failure is thus attributed to the instruction logic representation information. The revision process adds the self-holding contact logic and coil drive relationship to the instruction logic representation information, eliminating the specification-level gap.

[0098] It needs to be clarified that the ladder diagram program is regenerated based on the revised instruction logic representation information. After the instruction logic representation information is revised, the specifications on which the original ladder diagram program was based have changed, and the original program is no longer an implementation of the revised specifications. Regenerating the ladder diagram program means taking the revised instruction logic representation information as input and executing the ladder diagram program generation step again, so that the resulting ladder diagram program reflects the revised contact logic, coil drive relationship, and execution timing. Continuing with the above scenario of motor start / stop self-holding, the revised instruction logic representation information includes self-holding logic, and the regenerated ladder diagram program accordingly includes a self-holding contact connected in parallel with the start contact. After the start button is released, the target soft component relies on the self-holding branch to maintain the connected state. After regenerating the ladder diagram program, the solution process returns to the verification stage. The verification results are updated based on the revised attribution object, and the effectiveness of the revision is verified by a new round of verification assertion comparison. The sequential arrangement of specification revisions and procedure regeneration ensures that each specification-level revision results in a new procedure that remains consistent with the specification. The closed loop of verification, attribution, and revision also applies at the specification level.

[0099] According to some embodiments of this application, step S108, which involves revising the attribution object based on the failure attribution, may include: In response to the attribution object being the input timeline and the verification assertion, the state change time of the input signal in the input timeline is adjusted according to the failure attribution, or the observation time and expected state of the verification assertion are adjusted.

[0100] It is important to clarify that this step follows the attribution conclusion, and the revision action is applied to the test product. The ladder diagram program and instruction logic representation information are not modified in this embodiment. Adjusting the state change timing of input signals in the input timeline addresses situations where the timing of the test stimulus itself is unreasonable. The input timeline records the state changes of each input signal in chronological order, and the state change timing determines when each input signal changes its value during the simulation. If the duration of a certain input change is improperly set, the ladder diagram program may not be able to read the change in time during the loop scan, resulting in a failed verification assertion, and the reason for the failure is not in the program. Taking button-type input signals as an example, the button being on and the button being released correspond to two state change moments in the input timeline. If the interval between the two state change moments is shorter than one scan cycle, the program may never read the button being on when reading the input image within one scan cycle, and the action simulated by the test stimulus will not leave any response trace on the program side. By shifting the state change time corresponding to button release to the later stage according to the failure attribution, the duration of button on covers at least one complete scan cycle, and the test stimulus is restored to reasonableness. After revision and re-verification, it is possible to distinguish whether the original failure was due to a test design problem or a program problem.

[0101] It's important to clarify that adjusting the observation time and expected state of the verification assertion addresses situations where the verification assertion itself is improperly configured. The observation time determines which state snapshot of the target soft component's state to read, while the expected state determines the benchmark value for comparison. If the observation time coincides with the state change time of the input signal, and the target soft component has not yet undergone a scan response at the observation time, the verification assertion imposes requirements on the program that exceed the scan semantics. If the expected state is inconsistent with the stimulus process described by the input timeline, the verification assertion itself has written an incorrect benchmark. Adjusting the observation time according to failure attribution means postponing the observation time to after the corresponding state change time, reserving a time window for the program's scan response. Adjusting the expected state according to failure attribution means correcting the expected value in the verification assertion by comparing it with the stimulus process recorded by the input timeline, ensuring that the verification assertion matches the test stimulus. Taking the violation test of a two-way quiz buzzer system as an example, if the buzzer button is activated at 1000 ms and the snapshot sampling period is 10 ms, and the verification assertion sets the observation time of the indicator light at 1000 ms and expects the indicator light to be activated, the verification assertion will inevitably fail. In the revision, the observation time is extended to 1010 ms or 1020 ms, aligning the requirements of the verification assertion with the program's scanning execution rhythm, thus eliminating the previous comparison failures caused by overly strict observation times.

[0102] It should be understood that the significance of this revision branch also lies in controlling the scope of the revision. Since failure attribution has already indicated that the error lies at the test level, the revision action is therefore limited to the input timeline and verification assertions, without affecting the ladder diagram program and instruction logic representation information. After the test-side revision is completed, simulation and comparison are re-executed based on the revised attribution object, and the verification results are updated. If the revised verification passes, the original ladder diagram program is proven to be logically correct, avoiding misjudging test design flaws as program flaws and making unfounded modifications to the program, ensuring that the revision direction remains consistent with the true source of the failure.

[0103] According to some embodiments of this application, step S108, which involves revising the attribution object based on the failure attribution, may include: in response to the attribution object being a ladder diagram program, locating the position to be revised in the ladder diagram program based on the failure attribution; keeping the program content outside the position to be revised in the ladder diagram program unchanged, and revising the position to be revised.

[0104] It should be noted that, in response to the attribution object being a ladder diagram program, the location to be revised within the ladder diagram program is determined based on the failure attribution. The location to be revised refers to the position of the program content corresponding to the failure cause within the ladder diagram program. This location can be pinpointed to a specific logic network and the program instructions within that network. The failure attribution carries the observation time and target soft component corresponding to the verification assertion showing a discrepancy, as well as the inconsistencies detected by the consistency check between the ladder diagram program and the instruction logic representation information. These pieces of information collectively point to a specific range within the program. The target soft component is driven by a specific logic network, and the inconsistencies record the specific form in which the program deviates from the instruction logic representation information, thus determining the location to be revised. For example, in a motor start-stop scenario, if the motor contactor Y000 fails to remain connected after the start button is released, the corresponding verification assertion comparison fails, and the consistency check detects that the ladder diagram program lacks the self-holding branch recorded in the instruction logic representation information. Therefore, the location to be revised is located in the logic network driving Y000. Taking a two-way buzzer system scenario as an example, if contestant one successfully buzzes in, contestant two's buzzer is not blocked. The consistency check detects that there is a lack of interlocking relationship between the two contestants' buzzer-judging networks. Based on this, the correction position is located to the logic networks corresponding to each of the two contestants. The correction action has a clear target before execution, and the scope of the correction corresponds to the scope of the failure reason.

[0105] It should be noted that the program content outside the location to be revised in the ladder diagram program remains unchanged, while the location to be revised is modified. The program content outside the location to be revised is irrelevant to the failure of this comparison; these contents did not show defects in the verification and remain unchanged, so that the logic that has already passed the verification is not affected by the revision action. The revision process focuses on the location to be revised, filling in the missing logic or correcting the error instructions according to the inconsistencies given by the failure attribution. Continuing with the above motor start-stop scenario, the revision process adds a self-holding contact in parallel with the start contact to the logic network driving Y000, while the rest of the program content remains unchanged. Continuing with the above quiz buzzer scenario, the revision process inserts the inverted contact of the successful quiz state of contestant two into the quiz determination network of contestant one, and performs corresponding processing in the quiz determination network of contestant two, while the program instructions of the other logic networks remain unchanged.

[0106] It's important to clarify that the approach of partial revision should be adapted to the actual scope of the error. Failure attribution has already pinpointed the error to a specific location within the program. Regenerating or significantly modifying content outside that location might introduce new defects into the originally correct parts. By limiting the revision scope to the area to be revised, each round of revisions results in limited and traceable changes to the program. During re-verification after revision, if differences still exist, the relationship between these differences and the content of this round of revisions is clearly traceable, and the analysis of the failure cause will not be interfered with by large-scale content changes. As the cycle of verification, attribution, and revision progresses, defects in the ladder diagram program are gradually eliminated, and the program's correctness gradually converges within a limited revision scope.

[0107] In step S109 of this embodiment, the verification result is updated based on the revised attribution object; It's important to note that completing the revision process does not automatically guarantee its correctness. Whether the revised deliverables have eliminated the original failures or introduced new impacts on related content requires further verification. Updating the verification results involves re-executing simulations and comparisons based on the revised attribution objects, replacing the original verification results with the new ones to reflect the true state of each deliverable after the revision. The revision action itself does not prove its effectiveness; the effectiveness of the revision is judged by the updated verification results. The effectiveness of each round of revisions is verifiable, and the progress of the process is always based on verified deliverables.

[0108] According to some embodiments of this application, step S109, which updates the verification result based on the revised attribution object, may include: In response to the attribution object being instruction logic representation information or ladder diagram program, based on the revised attribution object, the input timeline and the corresponding verification assertion are regenerated, and the verification result is updated based on the regenerated input timeline and verification assertion; In response to the attribution object being the input timeline and validation assertions, the validation results are updated based on the revised input timeline and validation assertions.

[0109] It should be noted that, in response to the attribution object being instruction logic representation information or ladder diagram program, the input timeline and corresponding verification assertions are regenerated based on the revised attribution object, and the verification results are updated based on the regenerated input timeline and verification assertions. The input timeline and verification assertions are jointly generated by the instruction logic representation information and the ladder diagram program. After the instruction logic representation information or ladder diagram program is revised, the content upon which the original input timeline and verification assertions are based changes, and the original test product and the revised program no longer maintain a correspondence. When using the revised program as the verification object, if the original input timeline and verification assertions are continued, the verification is actually targeting an outdated test benchmark, and the resulting verification results cannot reflect the true situation of the revised ladder diagram program. Therefore, in this embodiment, the input timeline and verification assertions are first regenerated based on the revised attribution object, and then the simulation and comparison are re-executed using the regenerated input timeline as the input stimulus to obtain the updated verification results. Taking the motor start-stop scenario as an example, after the instruction logic representation information is added to the self-holding logic and the ladder diagram program is regenerated accordingly, the test generation stage re-establishes the input timeline and verification assertions based on the revised instruction logic representation information and the regenerated ladder diagram program. The on / off state of the start button and the hold observation after disconnection are all arranged according to the revised program content. The updated verification results reflect the performance of the new program under the new test benchmark. The revised program and the regenerated test product re-establish a correspondence, thereby ensuring the validity of the verification conclusions.

[0110] It should be noted that, in response to the attribution object being the input timeline and verification assertions, the verification results are updated based on the revised input timeline and verification assertions. In this embodiment, the object of revision is the input timeline and verification assertions themselves; the instruction logic representation information and ladder diagram program remain unchanged, and the generation basis of the input timeline and verification assertions remains the same, eliminating the need for a re-generation process. The revised input timeline and verification assertions are directly used as the new test benchmark. The ladder diagram program is re-simulated using the revised input timeline as input stimulus, and each verification assertion is re-compared with its corresponding state snapshot to obtain the updated verification results. Continuing with the scenario of excessively strict observation time in the violation-based answering test, the observation time is extended from 1000 ms to 1010 ms. The simulation and comparison are then re-executed using the original ladder diagram program and the revised input timeline and verification assertions, keeping the program content unchanged in this round of verification. This embodiment eliminates the process of regenerating the test product; when the revision scope is limited to the test side, the verification update path is correspondingly shortened.

[0111] The two-branch approach ensures consistency between the method of updating verification results and the scope of revision processing. When a revision affects the program or specification, the test artifacts are updated synchronously, and verification is built upon the corresponding programs and tests. When a revision only affects the test artifacts, the program remains unchanged, and verification is directly re-executed on the revised test benchmark. Regardless of which branch is followed, the updated verification results are based on the currently valid instruction logic representation information, ladder diagram program, input timeline, and verification assertions. The correspondence between the verification conclusions and the artifacts in the solution is maintained in each iteration.

[0112] In step S110 of this embodiment, in response to the updated verification result indicating that the verification has passed, the ladder diagram program when the verification has passed is determined as the target ladder diagram program. It should be noted that the target ladder diagram program refers to the ladder diagram program that is ultimately delivered and can be used on-site. Only if the updated verification results indicate that the verification has passed is the ladder diagram program currently being verified identified as the target ladder diagram program; if the updated verification results still indicate that the verification has failed, the process returns to the aforementioned attribution, revision, and update process to continue. Delivery is contingent upon successful verification; the correctness of the target ladder diagram program is verified through actual simulation and line-by-line comparison, and is not based on the generation process itself as a reliable credential.

[0113] According to some embodiments of this application, the embodiments of this application may further include: When the verification result indicates a verification failure, a failure feature identifier corresponding to the current failure is generated and recorded; the failure feature identifier is generated based on the failure attribution and the verification assertions that show differences. In response to the updated verification result still indicating verification failure after the ladder diagram program has been revised, and the failure feature identifier corresponding to the updated verification result is consistent with the recorded failure feature identifier, the attribution object is adjusted to the instruction logic representation information.

[0114] It should be noted that the failure feature identifier is generated based on the failure attribution and the verification assertions showing discrepancies, and is used to characterize the identity of the failure in this round. The failure attribution provides the level to which the failure belongs and the attribution object, while the verification assertions showing discrepancies provide the observed location of the failure and the target soft component. The combination of these two pieces of information can distinguish failures from different sources and locations. A failure feature identifier is generated and recorded each time a verification round fails, allowing for comparison between failures in different rounds and providing a verifiable basis for determining whether failures belong to the same problem. Revising the ladder diagram program is a local revision at the program level. If the verification still fails after the revision and the failure feature identifier is consistent with the previous version, it indicates that the same problem is reproduced exactly after the local revision. The root cause of the error is not in the specific implementation of the program, but in the instruction logic representation information on which the program is based. At this point, continuing to make local revisions to the ladder diagram program will not change the result. The attribution object is thus adjusted to the instruction logic representation information, and the revision path is upgraded from the program level to the specification level, where the contact logic, coil drive relationships, and execution timing arrangements are re-examined. This upgrade mechanism is triggered by the consistency of failure feature identifiers. The timing of the upgrade is determined by the actual reproduction of the failure. The switching of the revision path is based on verifiable records, thus avoiding repeated and ineffective program patching on the same problem.

[0115] According to some embodiments of this application, the embodiments of this application may further include: Determine the coverage status of each acceptance item based on the acceptance item identifier carried by each verification assertion; In response to the updated verification results indicating that the verification has passed and there are acceptance items whose coverage status is not covered, a supplementary input timeline and corresponding supplementary verification assertions are generated for the acceptance items whose coverage status is not covered. The verification results are updated based on the supplementary input timeline and supplementary verification assertions.

[0116] It should be noted that the coverage status is used to characterize whether each acceptance item has a corresponding verification assertion for verification. By aggregating the generation and comparison of each verification assertion according to the acceptance item identifier, the state of each acceptance item as covered or uncovered can be determined. In response to the updated verification results indicating that verification has passed, and for acceptance items with a coverage status indicating that they are not covered, supplementary input timelines and corresponding supplementary verification assertions are generated for these covered acceptance items, and the verification results are updated based on the supplementary input timelines and supplementary verification assertions. Verification passing indicates that all existing verification assertions have been verified. Covered acceptance items indicate that there are still control requirements in the control requirement information that have not been verified, and the program's correct performance in only some scenarios is insufficient to confirm the program's correctness. For uncovered acceptance items, supplementary test artifacts are generated and the verification results are updated, extending the verification scope to all control requirements in the control requirement information. Taking a two-way buzzer system as an example, if the existing tests cover acceptance items such as reset, illegal buzzer-in, and successful buzzer-in by the contestant, but the acceptance items for the mandatory answer mode are not covered, then a supplementary input timeline and supplementary verification assertions are generated for the mandatory answer mode to check the behavior of each indicator light and related software component in the mandatory answer mode. The correctness of the program under key working conditions is thus fully verified.

[0117] According to some embodiments of this application, the embodiments of this application may further include: Record the number of revisions processed; In response to the fact that the number of revision processing steps has reached the preset limit and the updated verification result does not indicate that the verification has passed, the automatic generation process of the ladder diagram program is terminated, and processing status information is output. The processing status information includes the verification assertions that failed and the current revision status.

[0118] It should be noted that if the number of revisions reaches the preset limit and verification still fails, it indicates that the current problem has not converged after multiple rounds of revisions, and continuing the cycle will hardly yield progress. Terminating the generation process at this point prevents the process from idling on unsolvable problems. The output processing status information records the failed validation assertions and the current revision status. The failed validation assertions indicate unresolved checkpoints, and the current revision status records the revision paths and content already executed. Subsequent manual review can use this information to understand the location and process of failures, providing a complete on-site record for review and intervention.

[0119] According to some embodiments of this application, the embodiments of this application may further include: Obtain domain rules; the domain rules are stored in the form of replaceable rule files, and the generation of instruction logic representation information, generation of ladder diagram program, generation of input timeline and verification assertion, and the process of obtaining verification results are all loaded with the rule content corresponding to the processing task of each stage in the domain rules.

[0120] It should be noted that domain rules are stored in the form of replaceable rule files. These rule files are separate from the processing logic of each stage. Changing the rule file adjusts the domain constraints followed by the solution, without altering the processing flow itself. Each stage—generating instruction logic representation information, generating ladder diagram programs, generating input timelines and verification assertions, and obtaining verification results—loads the corresponding rule content from the domain rules for its respective processing task. The processing tasks of each stage differ, requiring different domain knowledge. The stage generating instruction logic representation information focuses on the scan semantics and logic planning constraints of the programmable logic controller (PLC); the stage generating ladder diagram programs focuses on instruction mapping rules and vendor address constraints; and the stage generating test products and performing verification focuses on timing settings and comparison rules. Loading the corresponding rule content for each stage ensures that the domain constraints followed by each stage precisely match its processing task. Taking the adaptation of a certain PLC as an example, the rule file records constraints such as octal addressing for input / output soft devices, the need to replace some instructions with supported instruction forms, and timers being segmented by number to correspond to different resolutions. Timers numbered T0 to T199 correspond to a 100 ms resolution. When it is necessary to adapt to programmable logic controllers from other brands, the switch can be completed by replacing the corresponding rule file. The adaptability of the solution to hardware constraints of different manufacturers is supported by the replaceability of the rule file.

[0121] According to some embodiments of this application, at least one of the steps of generating instruction logic representation information, generating ladder diagram program, generating input timeline and verification assertion, and obtaining verification result is executed by the corresponding configured large language model; the large language model corresponding to each step is configured independently according to the model configuration information.

[0122] It should be noted that the large language model undertakes the understanding and generation tasks in each stage. The nature of the tasks in each stage differs, as do the requirements for model capabilities. The stage that generates instruction logic representation information focuses on understanding control requirements and logical planning, while the stage that generates ladder diagram programs focuses on accurate output in code form. Each stage's large language model is configured independently based on model configuration information, allowing each stage to select a model suitable for its own task. Adjustments to the model in one stage do not affect other stages. As an implementation method, the stage that generates instruction logic representation information is configured with a local model fine-tuned using planned task samples, while the stage that generates ladder diagram programs is configured with a model with strong code generation capabilities. Model configuration information can be pre-specified or modified under different projects, operating environments, or security policies, maintaining flexibility in model selection and deployment.

[0123] The following example uses the motor start-stop control scenario, combined with... Figures 6A to 6FThe complete processing procedure of the embodiments of this application is described below. The control requirements described in the control demand information are: the motor starts running after the start button is pressed, the motor continues to run after the start button is released, and the motor stops running after the stop button is pressed. The start button corresponds to input signal X000, the stop button corresponds to input signal X001, and the motor contactor corresponds to output signal Y000. Figure 6A The overall flowchart of the corresponding ladder diagram generation program is shown below. Figure 6B The corresponding planning agent's processing flowchart, Figure 6C The corresponding processing flowchart of the coded intelligent agent, Figure 6D The corresponding test generates a flowchart of the intelligent agent's processing. Figure 6E The corresponding processing flowchart for the quality verification agent. Figure 6F Corresponding verification and repair flowchart. Specific implementation examples are given below with reference to the diagrams.

[0124] Figure 6A The overall processing flow of an embodiment of this application is shown. Figure 6A The natural language control requirements in this application correspond to the control requirement information in the embodiments of this application; the IL specification corresponds to the instruction logic representation information; the JSON ladder diagram corresponds to the ladder diagram program; the timeline corresponds to the input timeline; the assertion corresponds to the verification assertion; the deliverable program corresponds to the target ladder diagram program; the judgment of verification passing and sufficient coverage corresponds to the verification result representing the situation where verification passes and the coverage status of each acceptance item represents the situation where all items are covered; entering the verification rework process corresponds to the verification result representing the situation where verification fails or the coverage status represents the situation where acceptance items are not covered. After obtaining the control requirement information for the programmable logic controller, the processing flow sequentially goes through four stages: generating instruction logic representation information, generating ladder diagram program, generating input timeline and verification assertion, and behavioral simulation and assertion evaluation. These four stages are executed by the planning agent, coding agent, test generation agent, and quality verification agent, respectively. When the verification result output by the quality verification agent represents that the verification passes and the coverage is sufficient, the process outputs the target ladder diagram program. When the verification fails or the coverage is insufficient, the process enters the next stage. Figure 6F The verification and repair process is shown below. In this example, after the control requirement information enters the process, the planning agent first generates instruction logic representation information.

[0125] Figure 6B The process flow for generating instruction logical representation information is shown. Figure 6BThe natural language requirements in the PLC correspond to control requirement information; the backtracking evidence corresponds to the failure attributions formed during the verification phase and the discrepancy information they carry; the PLC planning rules, scan semantics, and manufacturer constraints correspond to the rule content in the domain rules corresponding to the planning task; the control objectives, I / O, interlocks, and timing requirements correspond to the contact logic, coil drive relationships, and execution timing obtained by logically parsing the control requirement information; the soft component annotation table corresponds to soft component annotation information; the I / O mapping table corresponds to input / output mapping relationships; the IL logic specification corresponds to instruction logic representation information; the IL contract verification corresponds to contract verification; the revision of the drive paradigm, address, scan order, or physical contact type corresponds to the revision of the instruction table program segment when the contract verification fails; the coil table and interlock table are records of the coil drive relationships and interlock arrangements in the instruction logic representation information, respectively. The planning agent receives control requirement information and may also receive failure attributions from the verification phase during the verification and rework phase. The planning agent loads the rule content in the domain rules corresponding to the planning task, and then performs logical parsing on the control requirement information to obtain the contact logic, coil drive relationships, and execution timing that match the control requirement information. In this example, the contact logic includes the parallel relationship between the start contact and the self-holding contact, and the inverted series relationship of the stop contact. The coil driving relationship is the drive motor contactor Y000, and the execution timing reflects the sequence of start, hold, and stop actions. The planning agent determines multiple soft components based on the control requirement information and generates soft component annotation information. The soft component annotation information records the component address, component type, and functional description of X000, X001, and Y000 respectively, and establishes an input-output mapping relationship. This mapping relationship represents the mapping relationship between the start button, stop button, and motor contactor and the component addresses of X000, X001, and Y000, respectively. The planning agent generates instruction table program segments according to the contact logic, coil driving relationship, and execution timing. These segments contain fetch instructions with X000 as an operand, OR instructions with Y000 as an operand, invert instructions with X001 as an operand, and output instructions with Y000 as an operand. After the instruction list program segment is formed, a contractual verification is performed. The driver type instructions within the segment are extracted and grouped by component address. It checks for conflicting addresses driven by multiple output instructions, and for mixed addresses driven by both output instructions and set or reset instructions. In this example, Y000 is driven by only one output instruction, and the contractual verification result indicates that the verification passed. The planning agent then integrates soft component annotation information, input-output mapping relationships, and the instruction list program segment, outputting the logical representation information of the instructions.

[0126] Figure 6C The process flow of the ladder diagram generation program is shown. Figure 6CThe repair guidelines correspond to structured repair guidelines that record failure attributions and attribution objects. The JSON ladder diagram specification, instruction whitelist, and address rules correspond to the rules in the domain rules that correspond to the coding task. Building a JSON network according to the IL network order corresponds to building the corresponding network data object according to the order of statements in the instruction list program segment. IL instructions correspond to the statements in the instruction list program segment. Mapping IL instructions one by one to JSON instruction tuples corresponds to converting each statement one by one into the corresponding program instruction. Mnemonics correspond to instruction mnemonics. Locally refactoring the program according to the principle of minimum modification corresponds to keeping the program content outside the position to be revised unchanged in the ladder diagram program and revising the position to be revised. The JSON ladder diagram program corresponds to the ladder diagram program. The coding agent receives instruction logic representation information and may also receive structured repair guidelines during the verification and rework phase. The coding agent loads the rule content corresponding to the coding task from the domain rules. Then, it establishes network data objects corresponding to the logical networks in the instruction logic representation information according to the order of statements in the instruction table program segment. Each statement is then converted into a corresponding program instruction, which includes an instruction mnemonic and its corresponding operand. The converted program instruction has the same operands as its corresponding statement. In this example, the fetch instruction with X000 as operand, the OR instruction with Y000 as operand, the NOT instruction with X001 as operand, and the output instruction with Y000 as operand are arranged sequentially in the same network data object. The last program instruction in the network data object is the network end instruction. The coding agent then checks whether the address format, instruction mnemonic, and operands of each program instruction conform to the vendor's address rules, and checks whether the arrangements for driver paradigm, self-holding, interlocking, and alarm protection conform to the domain rules before performing compilation or structural verification. If the verification fails, the coding agent keeps the program content outside the area to be revised unchanged and performs revision processing on the area to be revised. After successful verification, the coded agent outputs a ladder diagram program and a coded digest.

[0127] Figure 6D The process flow for generating input timelines and validation assertions is shown. Figure 6DThe latest IL specification, JSON program, and acceptance items correspond to the latest instruction logic representation information, ladder diagram program, and each acceptance item, respectively. The test generation rules correspond to the rule content in the domain rules corresponding to the test generation task. The identification of main flow, boundary, exception, and interlock scenarios corresponds to the division of test scenarios based on various control requirements in the control requirement information. Pressing, releasing, and state changes correspond to paired input records of continuous input actions in the input timeline and the changed state values ​​recorded in each input record. Structured assertions correspond to verification assertions, observation time corresponds to observation time, expected value corresponds to expected state, acceptance item coverage mapping corresponds to the record of the coverage state of each acceptance item, and the assertion table is a collection of each verification assertion. Supplementing test scenarios for uncovered items corresponds to generating supplementary input timelines and corresponding supplementary verification assertions for acceptance items whose coverage state representation is not covered. The test generation agent reads the latest instruction logic representation information, ladder diagram program, and each acceptance item, and loads the rule content in the domain rules corresponding to the test generation task. The test-generated agent determines multiple acceptance criteria based on instruction logic representation information. In this example, the identified acceptance criteria include start, hold, and stop, each corresponding to a control requirement in the control requirements information. The test-generated agent determines multiple action moments, corresponding input signals, and changed state values ​​based on the control requirements information and instruction logic representation information. It then generates multiple input records in chronological order of the action moments, forming an input timeline. In this example, pressing the start button is a continuous input action, represented by a pair of input records: one record shows the action moment 1000 ms, with signal identifier X000 connected to the changed state value; the other record shows the action moment 1100 ms, with signal identifier X000 disconnected from the changed state value. Similarly, pressing the stop button is represented by a pair of input records. The test-generated agent generates at least one verification assertion for each acceptance criterion. Each verification assertion carries an acceptance criterion identifier corresponding to the acceptance criterion and represents the expected state of the target soft component at the corresponding observation moment. The observation time is determined based on the input action time and sampling period, and is located after the input action time with an interval of at least one sampling period between it and the input action time. In this example, the snapshot sampling period is 10 ms. To maintain the verification assertion corresponding to the acceptance item, the observation time is set to 1110 ms. The target soft device is Y000, and the expected state is on. This observation time is one sampling period apart from the input action time when X000 is off. The test generation agent establishes a coverage mapping for each acceptance item. When the coverage is insufficient, supplementary input timelines and corresponding supplementary verification assertions are generated for the uncovered acceptance items representing the coverage status. After sufficient coverage, the test scenario, assertion table, and coverage information are output.

[0128] Figure 6E The process flow for behavioral simulation and assertion evaluation is shown. Figure 6E The JSON program, test scenario, and assertions in the code correspond to the ladder diagram program, input timeline, and validation assertions, respectively. The completeness of the pre-deliverables is checked to ensure the ladder diagram program and test deliverables are complete. Missing programs and missing tests correspond to missing ladder diagram programs and missing input timelines and validation assertions, respectively. The execution behavior simulation generates state snapshots by using the input timeline as input stimulus to simulate a cyclic scan of the programmable logic controller in the ladder diagram program and obtain state snapshots at each sampling time. Querying snapshots by observation time corresponds to selecting the snapshot whose corresponding sampling time is no later than the observation time and whose corresponding sampling time is the longest. The state snapshot is determined as the target state snapshot. The structured assertion evaluation compares each verification assertion with its corresponding state snapshot. Hierarchical failure attribution determines the failure attribution and the corresponding attribution object based on the verification assertions showing discrepancies in the comparison. Three attribution targets—sampling or testing issues, program implementation issues, and specification contradictions or gaps—correspond to three scenarios: attribution objects are the input timeline and verification assertions; the attribution object is the ladder diagram program; and the attribution object is the instruction logic representation information, respectively. Coverage gaps correspond to records of acceptance items not covered by the state representation. Verification pass corresponds to the verification result representing successful verification. The quality verification agent reads the ladder diagram program, test scenario, and verification assertions. It first performs a pre-check; if the ladder diagram program is missing, it points to the coding agent; if the input timeline and verification assertions are missing, it points to the test generation agent; if the pre-check products are complete, it enters simulation. The quality verification agent uses the input timeline as input stimulus to simulate the cyclic scanning of a programmable logic controller (PLC) using a ladder diagram program. Within each scan cycle, it executes the program instructions in each logic network sequentially according to their arrangement, updating the state values ​​of each soft component based on the execution results. At each sampling moment, it records the current state value of each soft component, obtaining a state snapshot at each sampling moment. Subsequently, the quality verification agent determines the target state snapshot for each verification assertion, reads the state value corresponding to the target soft component in the target state snapshot, and compares the read state value with the expected state according to the verification assertion comparison method, obtaining the comparison results for each verification assertion. Based on these comparison results, it obtains the verification result. When all verification assertions are true, it enters the coverage check phase. If there is a coverage status indicating an uncovered acceptance item, it marks it as needing extended testing and outputs a coverage gap. If the coverage is sufficient, it outputs a verification result indicating successful verification. If there are verification assertions that fail to match, it enters the hierarchical failure attribution phase.

[0129] Figure 6F The verification and repair process is shown. Figure 6FThe quality verification results correspond to the verification results output by the quality verification agent. Assertion failures represent verification failure scenarios. Three types of failure attributions—test design defects, program implementation defects, and specification gaps or requirement ambiguities—correspond to three revision directions: attribution objects are the input timeline and verification assertions; attribution objects are the ladder diagram program; and attribution objects are the instruction logic representation information. Supplementing test scenarios, fixing JSON ladder diagram programs, and revising IL logic specifications correspond to the revision processes performed on the input timeline and verification assertions, ladder diagram programs, and instruction logic representation information, respectively. Writing back to the shared state corresponds to writing the revised attribution objects and their version information into the shared state repository. Re-executing behavioral simulation corresponds to updating the verification results based on the revised attribution objects. Passing but insufficient coverage corresponds to the updated verification results representing a situation where verification passed, but there are uncovered acceptance items. The orchestration agent reselecting the next node corresponds to the orchestration agent determining the next execution stage based on the version relationships recorded in the shared state repository. When the verification results output by the quality verification agent represent verification failure, the process generates structured repair guidelines and routes the revision tasks to the corresponding agents based on the failure attribution. In this example, the verification assertion corresponding to the acceptance item failed during the initial verification. The target state snapshot at observation time 1110 ms showed that the state value of Y000 was disconnected, which differed from the expected state of being connected. The hierarchical failure attribution first checked the sampling match between the observation time of this verification assertion and the state change time of X000 being disconnected. The observation time was one sampling period after the state change time, and the sampling match met the requirements. Subsequently, a consistency check was performed on the ladder diagram program against the instruction logic representation information. It was detected that the logic network driving Y000 in the ladder diagram program lacked the self-holding branch recorded in the instruction logic representation information. The failure attribution was determined to be a program implementation defect, and the attribution object was determined to be the ladder diagram program. The structured repair guide carries the verification assertion with discrepancies and the inconsistencies detected by the consistency check. Based on this, the orchestration agent routes the revision task to the coding agent. The coding agent locates the point to be revised in the logic network driving Y000 based on the failure attribution. It keeps the program content outside the revision point unchanged in the ladder diagram program, inserting an OR instruction with Y000 as an operand into this logic network to form a self-holding branch. The revised ladder diagram program is written back to the shared state repository. Due to the change in the ladder diagram program, the test generation agent regenerates the input timeline and verification assertions based on the revised ladder diagram program, and the quality verification agent re-executes the behavioral simulation and assertion comparison. In this example, the updated verification result indicates that all verification assertions pass the comparison and have sufficient coverage. The orchestration agent determines the ladder diagram program when verification passes as the target ladder diagram program and outputs it. If the failure attribution points to a test design flaw, the revision task is routed to the test generation agent to adjust the input timeline and verification assertions.If the failure attribution points to a specification gap or requirement ambiguity, the revision task is routed to the planning agent to revise the instruction logic representation information. If the updated verification result after revising the ladder diagram program still indicates verification failure, and the failure feature identifier matches the recorded failure feature identifier, the orchestration agent adjusts the attribution object to the instruction logic representation information. If the number of revision attempts reaches the preset limit and verification still fails, the process terminates and outputs processing status information, including failed verification assertions and the current revision status.

[0130] This example demonstrates that the motor start-stop control scenario starts with control requirement information, and is generated layer by layer through instruction logic representation information, ladder diagram program, input timeline and verification assertions. Verification is then completed through behavioral simulation and assertion comparison. If verification fails, the failure is attributed to the cause and the program is reworked accordingly. Finally, the target ladder diagram program that has passed verification is obtained. The products of each stage of the solution correspond to each other, and the verification and revision have clear basis.

[0131] The following general implementation example clarifies the cooperative and temporal relationships of intelligent agents.

[0132] This application embodiment illustrates the collaborative timing between the orchestration agent, shared state repository, domain knowledge layer, planning agent, coding agent, test generation agent, and quality verification agent. Continuing with the motor start / stop control scenario, the collaborative process between the agents will be explained below in conjunction with this application embodiment.

[0133] The user submits control requirements for the programmable logic controller (PLC) to the orchestration agent. These requirements describe the motor's operation upon pressing the start button, its hold upon releasing the start button, and its stop upon pressing the stop button. Upon receiving the control requirements, the orchestration agent creates a corresponding task in the shared state repository and reads the current state recorded there, determining if valid instruction logic representation information exists. The shared state repository records the products of each stage and their version information. The orchestration agent schedules the process based on the version relationships recorded in the shared state repository. In this example, the task is a newly created task, and no valid instruction logic representation information exists in the shared state repository. Therefore, the orchestration agent determines the planning agent as the next execution node.

[0134] The orchestration agent reads the rule content corresponding to the planning task from the domain knowledge layer. This rule content includes the programmable logic controller's planning rules, scan semantics, and vendor constraints. It then requests the planning agent to generate instruction logic representation information. The planning agent then proceeds according to… Figure 6BThe illustrated process completes logic parsing, soft component annotation information generation, input / output mapping relationship establishment, instruction list program segment generation, and contract verification. The generated instruction logic representation information and contract verification results are returned to the orchestration agent. The orchestration agent writes the instruction logic representation information and its specification version into the shared state repository, thus creating a valid instruction logic representation information in the shared state repository. After reading the latest specification version, the orchestration agent determines that the ladder diagram program is missing and identifies the coding agent as the next execution node.

[0135] The orchestration agent reads the rule content corresponding to the coding task from the domain knowledge layer. This rule content includes instruction mapping rules and the structured data specifications of the ladder diagram program. It then requests the coding agent to generate the ladder diagram program. The coding agent follows... Figure 6C The illustrated process completes each transformation and check, returning the ladder diagram program, compilation and verification results, and code summary to the orchestration agent. The orchestration agent writes the program version and the specification version upon which the program is based to the shared state repository, enabling subsequent steps to determine the correspondence between various deliverables. After reading the program version, the orchestration agent checks for missing input timelines and verification assertions, determining the next execution node to be the test generation agent.

[0136] The orchestration agent reads the rule content corresponding to the test generation task from the domain knowledge layer, and then requests the test generation agent to generate the input timeline and validation assertions. The test generation agent then follows... Figure 6D The illustrated process generates an input timeline, validation assertions, and coverage mappings, and returns the test scenario, assertion table, and coverage information to the orchestration agent. The orchestration agent writes the test version and coverage information to a shared state repository, then reads the test version and coverage information, determines if validation is missing, and identifies the quality validation agent as the next execution node.

[0137] The orchestration agent reads and verifies the rules corresponding to the task from the domain knowledge layer. These rules include simulation semantics and assertion evaluation rules. The orchestration agent then requests the quality verification agent to perform behavioral simulation and assertion evaluation. The quality verification agent then... Figure 6E The illustrated process involves simulating a loop scan of the ladder diagram program using the input timeline as input stimulus, obtaining state snapshots at each sampling time, and comparing each verification assertion with its corresponding state snapshot. The simulation snapshot, assertion results, and diagnostic information are then returned to the orchestration agent. The orchestration agent writes the verification version, verification result, and failure feature identifier to the shared state repository and reads the latest verification result to determine the subsequent flow. The rule content read by the orchestration agent is sent to the corresponding agents upon request and loaded and executed by each agent.

[0138] When the verification result indicates that the verification is successful and the coverage is sufficient, the orchestration agent determines the ladder diagram program at the time of successful verification as the target ladder diagram program and outputs a deliverable ladder diagram program to the user. When the verification result indicates that the verification is successful but there are acceptance items that are not covered by the coverage status, the orchestration agent requests the test generation agent to generate supplementary input timelines and supplementary verification assertions for the uncovered acceptance items. The test generation agent returns an expanded test scenario. After the orchestration agent updates the test version and coverage mapping, the quality verification agent re-executes the behavioral simulation and returns new verification results.

[0139] In this example, the initial verification result indicates a verification failure, maintaining discrepancies in the checksums corresponding to the acceptance items. Hierarchical failure attribution identifies a program implementation defect as the cause, with the ladder diagram program as the attribution object. The orchestration agent, carrying structured repair guidelines, requests the coding agent to perform targeted repair. The coding agent adds self-holding branches to the logic network driving Y000, keeping the program content outside the revised location unchanged, and returns the revised ladder diagram program to the orchestration agent. The orchestration agent updates the program version. Since the program version has changed, the test generation agent regenerates the input timeline and checksums based on the revised ladder diagram program. The quality verification agent re-executes the behavioral simulation and returns a new verification result. The updated verification result indicates successful verification with sufficient coverage. The orchestration agent outputs the target ladder diagram program to the user.

[0140] If the failure attribution points to a test design flaw, the orchestration agent requests the test generation agent to revise the input timeline and validation assertions, carrying structured repair guidelines. The test generation agent returns the revised test scenario, and the orchestration agent updates the test version and coverage mapping. The quality verification agent then re-executes the behavioral simulation. If the failure attribution points to a specification gap or requirement ambiguity, the orchestration agent requests the planning agent to revise the instruction logic representation information, carrying backtesting evidence generated during the verification phase. The planning agent returns the revised instruction logic representation information, and the orchestration agent updates the specification version and triggers subsequent generation, testing, and verification phases.

[0141] If, after revising the ladder diagram program, the updated verification result still indicates verification failure, and the failure feature identifier corresponding to the updated verification result is consistent with the recorded failure feature identifier, the orchestration agent will upgrade the local repair to specification replanning, requesting the planning agent to re-examine the instruction logic representation information and scan semantic constraints. The planning agent will return the replanned instruction logic representation information, and the orchestration agent will update the specification version, failure feature identifier, and revision processing count. If the revision processing count reaches the preset limit, and the updated verification result does not indicate verification success, the orchestration agent will terminate the automatic generation process of the ladder diagram program and output processing status information to the user. The processing status information includes the failed verification assertions and the current revision status, which the user will then manually review.

[0142] As can be seen from the collaborative timing of the embodiments of this application, the orchestration agent does not directly execute the generation and verification actions. Instead, it determines the next execution node based on the version relationships recorded in the shared state repository. The instruction logic representation information, ladder diagram program, input timeline, verification assertions, and verification results generated by each stage are all written back to the shared state repository. When any stage fails, the failure attribution determines the routing direction of the revision task. After the revision is completed, the version relationships are updated accordingly, and the process continues to advance along the updated version relationships. Each stage forms a closed-loop collaboration based on the records in the shared state repository.

[0143] The automatic ladder diagram program generation system according to the embodiments of this application, applied to the automatic ladder diagram program generation method according to any one of the embodiments of this application, may include: The requirement acquisition module is used to acquire control requirement information for the programmable logic controller. The planning agent is used to generate instruction logic representation information that conforms to the instruction list writing specification based on control requirement information; wherein, the instruction logic representation information includes contact logic, coil driving relationship and execution timing that match the control requirement information; Encoded intelligent agents are used to generate ladder diagram programs based on instruction logic representation information; The test generates an intelligent agent, which is used to generate an input timeline and multiple verification assertions corresponding to the input timeline based on instruction logic representation information and ladder diagram program; wherein, the input timeline is used to record the state changes of each input signal in chronological order, and each verification assertion is used to characterize the expected state of the target soft component at the corresponding observation time. The quality verification agent is used to simulate the cyclic scanning of a programmable logic controller using the input timeline as input stimulus, and obtain state snapshots at each sampling time. Each verification assertion is compared with the corresponding state snapshot to obtain the verification result. In response to the verification result indicating verification failure, the agent determines the failure attribution and the corresponding attribution object based on the verification assertions with differences in comparison. An orchestration agent is used to schedule the corresponding agent to revise the attribution object based on the failure attribution, and to trigger the quality verification agent to update the verification result based on the revised attribution object; and, in response to the updated verification result indicating that the verification is passed, to determine the ladder diagram program when the verification is passed as the target ladder diagram program.

[0144] It is evident that the content of the above-described automatic ladder diagram program generation method embodiments is applicable to the embodiments of this automatic ladder diagram program generation system. The specific functions implemented by this automatic ladder diagram program generation system embodiment are the same as those of the above-described automatic ladder diagram program generation method embodiments, and the beneficial effects achieved are also the same as those achieved by the above-described automatic ladder diagram program generation method embodiments.

[0145] Reference Figure 7 , Figure 7 This illustration shows the hardware structure of an electronic device according to another embodiment. The electronic device may include: The processor 701 can be implemented using a general-purpose CPU (Central Processing Unit), microprocessor, application-specific integrated circuit (ASIC), or one or more integrated circuits, and is used to execute relevant programs to implement the technical solutions provided in the embodiments of this application. The memory 702 can be implemented as a read-only memory (ROM), a static storage device, a dynamic storage device, or a random access memory (RAM). The memory 702 can store the operating system and other application programs. When the technical solutions provided in the embodiments of this specification are implemented through software or firmware, the relevant program code is stored in the memory 702 and is called and executed by the processor 701 to execute the automatic generation method of the ladder diagram program in the embodiments of this application. The input / output interface 703 is used to implement information input and output; The communication interface 704 is used to enable communication and interaction between this device and other devices. Communication can be achieved through wired means (such as USB, Ethernet cable, etc.) or wireless means (such as mobile network, WIFI, Bluetooth, etc.). Bus 705 transmits information between various components of the device (e.g., processor 701, memory 702, input / output interface 703, and communication interface 704); The processor 701, memory 702, input / output interface 703, and communication interface 704 are connected to each other within the device via bus 705.

[0146] This application also provides a computer program product, which includes a computer program. A processor of a computer device reads and executes the computer program, causing the computer device to perform the above-described automatic ladder diagram program generation method.

[0147] In the several embodiments provided in this application, it should be understood that the disclosed systems, apparatuses, and methods can be implemented in other ways. For example, the apparatus embodiments described above are merely illustrative; for instance, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces, or indirect coupling or communication connection between apparatuses or units, and may be electrical, mechanical, or other forms.

[0148] Furthermore, the functional units in the various embodiments of this application can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit. The integrated unit can be implemented in hardware or as a software functional unit.

[0149] If the integrated unit is implemented as a software functional unit and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned storage medium may include: a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, and other media capable of storing program code.

[0150] It should also be understood that the various implementation methods provided in this application can be combined arbitrarily to achieve different technical effects.

[0151] The above is a detailed description of the embodiments of this application. However, this application is not limited to the above embodiments. Those skilled in the art can make various equivalent modifications or substitutions without departing from the spirit of this application. All such equivalent modifications or substitutions are included within the scope defined by the claims of this application.

Claims

1. A method for automatically generating ladder diagram programs, characterized in that, include: Obtain control requirements information for the programmable logic controller; Based on the control requirement information, instruction logic representation information conforming to the instruction list writing specification is generated; wherein, the instruction logic representation information includes contact logic, coil driving relationship and execution timing that match the control requirement information; Based on the instruction logic representation information, a ladder diagram program is generated; Based on the instruction logic representation information and the ladder diagram program, an input timeline and multiple verification assertions corresponding to the input timeline are generated; wherein, the input timeline is used to record the state changes of each input signal in chronological order, and each verification assertion is used to characterize the expected state of the target soft component at the corresponding observation time; Using the input timeline as the input stimulus, the ladder diagram program simulates the cyclic scanning of a programmable logic controller to obtain state snapshots at each sampling time. Each of the verification assertions is compared with the corresponding state snapshot to obtain the verification result; In response to the verification result indicating verification failure, the failure attribution and the attribution object corresponding to the failure attribution are determined based on the verification assertion showing a difference in comparison. Based on the failure attribution, the attribution object is revised. The verification result is updated based on the revised attribution object; In response to the updated verification result indicating that the verification has passed, the ladder diagram program that passed the verification is determined as the target ladder diagram program.

2. The automatic generation method for ladder diagram programs according to claim 1, characterized in that, The step of generating instruction logic representation information that conforms to the instruction list writing specification based on the control requirement information includes: Based on the control requirement information, multiple soft components are identified, and soft component annotation information is generated; wherein, the soft component annotation information includes the component address, component type, and functional description of each soft component in the control requirement information; Establish the input-output mapping relationship of the control requirement information; wherein, the input-output mapping relationship is used to characterize the mapping relationship between the input signal, the output signal and the component address of each of the soft components; The control requirement information is logically parsed to obtain the contact logic, coil driving relationship and execution timing that match the control requirement information. Based on the contact logic, the coil driving relationship, and the execution timing, an instruction table program segment is generated. By integrating the soft component annotation information, the input-output mapping relationship, and the instruction table program segment, the instruction logic representation information is obtained.

3. The automatic generation method for ladder diagram programs according to claim 2, characterized in that, After generating the instruction table program segment according to the contact logic, the coil driving relationship, and the execution timing, the method further includes performing contract verification on the instruction table program segment to obtain a contract verification result, specifically including: Extract the driver type instructions from the instruction table program segment and determine the address of the component driven by each driver type instruction; wherein, the driver type instructions include output instructions, set instructions and reset instructions; The extracted driver type instructions are aggregated according to the component address to obtain the driver type instructions corresponding to each component address; If a component address exists that is driven by multiple output instructions, the component address is determined to be a conflicting address; If there exists a component address that is driven by both the output instruction and the set instruction or the reset instruction, the component address is determined to be a mixed address; Based on the determined conflicting address and the mixed address, the contract verification result is generated.

4. The automatic generation method for ladder diagram programs according to claim 2, characterized in that, The step of generating an instruction table program segment according to the contact logic, the coil driving relationship, and the execution timing includes: Each of the aforementioned component addresses is assigned a corresponding instruction-driven paradigm; wherein, the instruction-driven paradigm is either a real-time output paradigm or a state latching paradigm; Based on the coil driving relationship and the instruction driving paradigm corresponding to each of the component addresses, generate the driving type instruction corresponding to each of the component addresses; Logical operation instructions are generated according to the contact logic described above; According to the execution sequence, the logical operation instructions and the driver type instructions are arranged to obtain the instruction table program segment.

5. The automatic generation method for ladder diagram programs according to claim 4, characterized in that, The step of generating the drive type instruction corresponding to each component address according to the coil drive relationship and the instruction drive paradigm corresponding to each component address includes: If the instruction driving paradigm of the component address is specifically the real-time output paradigm, a corresponding output instruction is generated for the component address. If the instruction driving paradigm of the component address is specifically the state latching paradigm, then for the component address, generate corresponding set and reset instructions; The step of arranging the logical operation instructions and the driver type instructions according to the execution sequence includes: In the process of arranging the logical operation instructions and the driver type instructions, for the element address corresponding to the state latching paradigm, the set instruction is arranged before the reset instruction.

6. The method for automatically generating ladder diagram programs according to claim 2, characterized in that, The step of generating an instruction table program segment according to the contact logic, the coil driving relationship, and the execution timing includes: Determine the physical contact type of each input signal; wherein, the physical contact type is used to characterize the on / off characteristics of the physical device corresponding to the input signal between the inactive state and the active state; According to the physical contact type of each input signal and the contact type corresponding to each input signal in the contact logic, a read instruction for reading each input signal is determined; wherein, the contact type includes normally open contact and normally closed contact, and the read instruction includes normally open read instruction and normally closed read instruction; In the process of determining the read instruction for each of the input signals, if the input signal is a normally open contact, then the instruction contact type of the corresponding read instruction is consistent with the physical contact type. In the process of determining the read position instruction for each of the input signals, if the input signal is a normally closed contact, the instruction contact type of the corresponding read position instruction is opposite to the physical contact type. Write the read instruction corresponding to each input signal into the instruction table program segment.

7. The method for automatically generating ladder diagram programs according to claim 1, characterized in that, The step of generating an input timeline and multiple verification assertions corresponding to the input timeline based on the instruction logic representation information and the ladder diagram program includes generating multiple verification assertions corresponding to the input timeline, specifically including: Based on the instruction logic representation information, multiple acceptance items are determined; wherein each acceptance item corresponds to a control requirement in the control requirement information; For each of the aforementioned acceptance items, at least one corresponding verification assertion is generated; wherein the verification assertion carries an acceptance item identifier corresponding to the acceptance item.

8. The method for automatically generating ladder diagram programs according to claim 1, characterized in that, The step of revising the attribution object based on the failure attribution includes: In response to the attribution object being the ladder diagram program, the position to be revised is located in the ladder diagram program according to the failure attribution; Keeping the program content in the ladder diagram program unchanged except for the position to be revised, the position to be revised is then revised.

9. An automatic ladder diagram program generation system, characterized in that, Applied to performing the method according to any one of claims 1 to 8, comprising: The requirement acquisition module is used to acquire control requirement information for the programmable logic controller. A planning intelligent agent is used to generate instruction logic representation information that conforms to the instruction list writing specification based on the control requirement information; wherein, the instruction logic representation information includes contact logic, coil driving relationship and execution timing that match the control requirement information; An coded intelligent agent is used to generate a ladder diagram program based on the instruction logic representation information; The test generates an intelligent agent, which is used to generate an input timeline and multiple verification assertions corresponding to the input timeline based on the instruction logic representation information and the ladder diagram program; wherein, the input timeline is used to record the state changes of each input signal in chronological order, and each of the verification assertions is used to characterize the expected state of the target soft component at the corresponding observation time; A quality verification agent is configured to use the input timeline as input stimulus to simulate a cyclic scan of a programmable logic controller in the ladder diagram program, and obtain state snapshots at each sampling time; compare each verification assertion with the corresponding state snapshot to obtain a verification result; and, in response to the verification result indicating verification failure, determine the failure attribution and the attribution object corresponding to the verification assertion with discrepancies in the comparison. An orchestration agent is configured to, based on the failure attribution, schedule a corresponding agent to revise the attribution object, and trigger the quality verification agent to update the verification result based on the revised attribution object; and, in response to the updated verification result indicating that the verification has passed, determine the ladder diagram program when the verification has passed as the target ladder diagram program.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the automatic generation method of the ladder diagram program as described in any one of claims 1 to 8.

Images