System and method to automatically generate, convert, validate, and manage automation artifacts

Abstract

A common data model is created for an automation system, which includes an ontology of semantic relationships between entities of the automation system captured from multiple simulation tools based on a simulation design of the automation system. Artifacts, such as simulation and automation artifacts may be attached to corresponding entities in the common data model. New automation artifacts may be generated utilizing logic definitions from the simulation artifacts in the common data model. Changes to an artifact may be propagated to affected artifacts in the common data model utilizing dependencies defined by the semantic relationships. A snapshot of the common data model, including the newly generated or modified artifacts are committed to a version control system. A continuous integration execution engine executes virtual commissioning for validating each automation artifact against a simulation environment in a simulation of the automation system, based on the commit of the common data model.

Description

Docket No. 202413967SYSTEM AND METHOD TO AUTOMATICALLY GENERATE, CONVERT, VALIDATE, AND MANAGE AUTOMATION ARTIFACTSTECHNICAL FIELD

[0001] The present disclosure relates generally to the field of industrial automation, and in particular, to automation engineering systems.BACKGROUND

[0002] Automation systems are widespread across many industries and industrial applications. For example, in automated production systems, each phase of the production lifecycle, including planning, design, simulation, automation engineering, and execution, may be performed by different experts using different specialized tools, and therefore often requires a high degree of coordination across multiple stakeholders to reach a final agreement and acceptance of the overall behavior of the physical and automation systems. Changes made in the engineering of one system must then be communicated to the other engineers, adopted into their engineering systems, and cross- validated in each context (planning, design, and automation).

[0003] One of the challenges with the existing state-of-the-art art involves inefficiencies caused by siloed engineering data that often cannot be shared and reused across contexts, engineering tools, and production lifecycle phases. Another challenge is to deal with inconsistencies that can emerge between different instantiations of the overall automation concept using different simulation tools (e.g., at different levels of abstraction) due to lack of communication between engineers and / or lack of a comparable (cross-platform) digital representation of the intended system behavior. Another potential issue involves incompatibilities that can arise between different proprietary automation concepts, such as between legacy and modern tools or third-party automation products.SUMMARY

[0004] Aspects of this disclosure provide methods, systems, and computer program products that can address and overcome one or more of the above-described technical challenges. Specifically, aspects of this disclosure provide technical features to automatically generate, convert, validate and manage automation artifacts, together with simulation artifacts in a simulation design of an automationDocket No. 202413967 system.

[0005] A first aspect of this disclosure provides a computer-implemented method for automatically generating and validating automation artifacts. The method comprises generating a simulation design of an automation system via a number of simulation tools to create simulation artifacts for entities of the automation system, the simulation artifacts including logic defining behaviors of the corresponding entities. The method further comprises, based on the simulation design, creating a common data model in a data store. The common data model includes an ontology of semantic relationships between entities of the automation system captured from the simulation tools, wherein the simulation artifacts are attached to the corresponding entities in the common data model. The method further comprises generating, via an automatic conversion module, an initial version of an automation artifact utilizing logic definitions from the simulation artifacts in the common data model and attaching the initial version automation artifact to a corresponding entity in the common data model. The method further comprises committing a snapshot of the common data model that includes the attached simulation artifacts and the initial version of the automation artifact to a version control system. The method further comprises executing, via a continuous integration (CI) execution engine coupled to the version control system, a virtual commissioning pipeline for validating the automation artifact against a simulation environment in a simulation of the automation system, based on the commit of the common data model.

[0006] A second aspect of this disclosure provides a computer-implemented method for modifying and validating automation artifacts. The method comprises creating a common data model for an automation system in a data store. The common data model includes an ontology of semantic relationships between entities of the automation system captured from a number of simulation tools based on a simulation design of the automation system. The common data model comprises artifacts, including one or more automation artifacts and simulation artifacts, attached to corresponding entities. The method further comprises performing, over one or more instances: making a change to at least one of the artifacts, propagating the change to affected artifacts in the common data model utilizing dependencies defined by the semantic relationships, committing a snapshot of the common data model that includes the changed artifacts to a version control system, and executing, via a continuous integration (CI) execution engine coupled to the version control system, a virtual commissioning pipeline for validating each automation artifact against a simulation environment in a simulation of the automation system, based on the commit of the common data model.Docket No. 202413967

[0007] Further aspects of this disclosure provide a computing system and a computer program product embodying the described method.

[0008] Additional technical features and benefits may be realized through the techniques of the present disclosure. Embodiments and aspects of the disclosure are described in detail herein and are considered a part of the claimed subject matter. For a better understanding, refer to the detailed description and to the drawings.BRIEF DESCRIPTION OF THE DRAWINGS

[0009] The foregoing and other aspects of the present disclosure are best understood from the following detailed description when read in connection with the accompanying drawings. To easily identify the discussion of any element or act, the most significant digit or digits in a reference number refer to the figure number in which the element or act is first introduced.

[0010] FIG. 1 is a high-level block diagram of a system according to one or more embodiments of the disclosure.

[0011] FIG. 2 is a simplified visualization of an object tree in a common data model according to one or more embodiments.

[0012] FIG. 3 is a flowchart illustrating a method for automatically generating and validating automation artifacts according to one or more embodiments.

[0013] FIG. 4 is a flowchart illustrating a method for modifying and validating automation artifacts according to one or more embodiments.

[0014] FIG. 5 illustrates a block diagram of a computing system in which embodiments of the disclosure may be implemented.DETAILED DESCRIPTION

[0015] FIGS. 1 through 5, discussed below, and the various embodiments used to describe the principles of the present disclosure in this patent document are by way of illustration only and should not be construed in any way to limit the scope of the disclosure. Those skilled in the art will understandDocket No. 202413967 that the principles of the present disclosure may be implemented in any suitably arranged device. The numerous innovative teachings of the present application will be described with reference to exemplary non-limiting embodiments.

[0016] As an initial matter, it is recognized that digital twin simulation tools can be used to model behaviors of complex industrial automation systems at different levels of abstraction or granularity. By way of example, some simulation tools, such as NX MCD® developed by Siemens, can be used for physics-based modeling of individual components of an automation system, such as a robot or a machine. Other simulation tools, such as Process Simulate® developed by Siemens, can be used for kinematic modelling of cells (i.e., at a higher level of granularity), where a cell may include several robots or machines. Still other simulation tools, such as Plant Simulation® developed by Siemens, may use discrete event modeling techniques to simulate behaviors at a plant or shop floor level (i.e., at an even higher level of granularity), for example, by analyzing material flow, resource utilization, etc., using a data driven approach. It can be expensive and time consuming to develop each simulation model, and the models often lack interoperability and exchangeability as they are built on separate simulation platforms, so that each simulation model at each granularity level may need to be developed from scratch.

[0017] Many digital twin simulation tools also support basic automation concepts, like sequence modeling (e.g., in NX MCD®), definition of smart objects and PLC modules (e.g., in Process Simulate®), or custom behavior models or logic (e.g., in Plant Simulation®), which are then configured within and embedded into the simulation. However, these capabilities typically model the automation system at a much higher level of abstraction than automation artifacts, such as programming code for a programmable logic controller (PLC) or a robot or a Human Machine Interface (HMI). Additionally, programming code for automation devices may need to account for many atypical paths, such as fault and error handling, among others, which are often not considered in simulation design. For example, because of the lack of integration and interchangeability, PLC programs may need to be developed from scratch via specialized automation engineering tools (e.g., Total Integrated Automation or TIA Portal®, SIMATIC AX®, both developed by Siemens), without leveraging the embedded behaviors or sequences already engineered in the simulation tools. Furthermore, reuse of these automation concepts may require an understanding of the relationships between automation concepts in the simulation tools. As currently implemented by many simulation tools, these relationships are usually defined manually and remain only inside the simulation tool in which they were authored. This, again, canDocket No. 202413967 cause inefficiencies in the engineering process and leaves potential synergy effects still on the table.

[0018] By way of further background, virtual commissioning is an established methodology for testing and validating the physical behavior of manufacturing lines, cells, machines, and components, together with the corresponding automation logic for those systems (e.g., in the form of behavioral models of periphery components or PLC programs). Virtual commissioning approaches utilize a simulation environment, complete with all physical and logical components, as a testing environment for automation artifacts such as PLC I robot / HMI programs. This approach relies on trust in the simulation as an accurate portrayal of both physical and behavioral components of the system and its interaction with the PLC program. While effective, virtual commissioning in this manner can give rise to inconsistencies between simulated behavior and actual behavior seen during commissioning. Such issues may be caused by miscommunication or data inconsistencies and may only manifest during commissioning. These problems may then need to be solved by the commissioning engineer / system integrator, and the changes propagated back “upstream” to the simulation engineers. This propagation is still manual (emails, phone calls, design reviews, workshops) and not supported by a central data backbone and data models, meaning that simulation behavior can easily become out of sync with actual system behavior.

[0019] The proposed methodology is directed to management of automation artifacts by unifying engineering data from different disciplines, that may be represented in different data models via different simulation / automation engineering tools, using a common data model. “Automation artifacts” can include programming code (e.g., including components such as function blocks, technology objects, I / O definitions, code libraries, etc.) and configuration artifacts (e.g., including hardware and network configurations) for automation devices such as PLCs, robots, HMIs, Edge devices, among others. The common data model may be created based on a simulation design of the automation system using a number of simulation tools and may include an ontology of semantic relationships between entities of the automation system captured from the simulation tools. Software artifacts, including simulation artifacts and automation artifacts, may be attached to the corresponding entities in the common data model. The common data model can provide cross-platform compatibility to implement a data backbone allowing data exchange between disparate ecosystems, such as between different simulation tools and automation engineering tools.

[0020] Using the common data model, it may be possible to reuse logic defined in a simulationDocket No. 202413967 artifact to generate an automation artifact, or vice versa, as well as propagate changes in one artifact (e.g., created using a particular simulation or automation engineering tool) to other affected artifacts (e.g., created using the same or other tools), utilizing dependencies defined by the semantic relationships in the common data model. The above may be implemented via an automatic conversion module that can include one or more automatic conversion tools to generate automation artifacts and propagate changes to any artifact across various target software. A version control system, for example with features such as tagging, branching, and merging, may facilitate parallel development and integration processes for automation artifacts. A DevOps platform including a continuous integration- continuous deployment / delivery (CI-CD) execution engine may be used to execute a virtual commissioning pipeline for automated testing and revalidation after each revision or generation of an automation artifact against a simulation environment in a simulation of the automation system. The CI-CD execution engine may, in many cases, orchestrate the virtual commissioning pipeline together with code-level testing (e.g., unit / functional / integration tests) to validate each automation artifact. The validated automation artifact may be deployed to production on an automation device.

[0021] The proposed methodology provides a number of distinguishing features. First, it can allow the system to maintain an integrated collection of simulation and automation artifacts that span low- level automation code to high-level production flow representations. This enables cross-domain I cross-application use-cases, such as measuring the impact of changes to a PLC program (e.g., made in an automation engineering tool) on high-level production KPIs (e.g., evaluated using a plant-level simulation stool). Also, semantic relationships captured in the common data model can enable the automatic conversion tools to propagate changes to automation artifacts across software tools, ensuring consistency across all domains after any change and minimizing the need for manual design review, integration, and debugging efforts. Furthermore, the proposed methodology can allow automation artifacts in third-party proprietary formats to be stored and integrated into the common data model and converted / migrated to a desired company-specific format using the automatic conversion tools. The converted I migrated automation artifacts can then be automatically validated through build, test, and virtual commissioning pipelines configured in the DevOps platform.

[0022] Turning now to the drawings, FIG. 1 illustrates a block diagram of a system 100 according to one or more embodiments. The various blocks shown, such as the simulation and automation engineering tools 102, the data backbone 104, the automatic conversion module 106 and the CI-CD execution engine 114, including components thereof, may be implemented by a computing system inDocket No. 202413967 various ways, for example, as hardware and programming. The programming for the blocks 102, 104, 106, 114 may take the form of processor-executable instructions stored on non-transitory machine- readable storage mediums and the hardware may include processors to execute those instructions. Furthermore, the processing capability may be distributed among multiple system components, such as among multiple processors and memories, optionally including multiple distributed processing systems or cloud / network elements. While some embodiments are described here in the context of an automated production system, one skilled in the art will appreciate that aspects of this disclosure may have numerous other industrial applications, including but not limited to manufacturing, oil refineries and drilling platforms, energy, building and train automation.

[0023] The simulation and automation engineering tools 102 may include a number of simulation tools, such as 102a, 102b, 102c, and one or more automation engineering tools, such as 102d, 102e, 102f. The tools 102 may be used to create software artifacts, including simulation artifacts and automation artifacts.

[0024] For example, in the context of an automated production system, the simulation tools 102a, 102b, 102c may include tools for production planning and design, that can be used to generate a simulation design (“digital twin”) of an automation system. In some embodiments, the simulation tools 102a-c may be configured to model the automation system at different levels of granularity. Non-limiting examples of such simulation tools include Plant Simulation®, Process Simulate® and NX MCD®, as described above. In some embodiments, the simulation tools 102a-c may be configured to model different aspects of the automation system or its components, such as mechanical, electrical, kinematic, thermodynamic aspects, among others.

[0025] The simulation tools 102a-c may be used to create simulation artifacts for entities of the automation system. Each simulation artifact may include logic defining behaviors of the corresponding entities. A simulation artifact may comprise a predefined, reusable, component (e.g., a library) and may be in a format specific to the particular tool. For example, in Process Simulate®, the simulation artifacts may include “smart objects” (defining logic for machines, such as conveyors, etc.) and “PLC modules” (defining logic components of PLCs).

[0026] The one or more automation engineering tools 102d, 102, 102f may include an application that provides a framework for programmers to design automation artifacts for various entities theDocket No. 202413967 automation system (e.g., PLCs, robots, HMIs, etc.) and may additionally provide access to services such as planning, integrated engineering, operations, etc. Non-limiting example of automation engineering tools include TIA portal® and SIMATIC AX®, among others. In some embodiments, the automation engineering efforts may be expedited using large language model (LLM)-based engineering assistants, e.g., Industrial Copilot for Engineering®, developed by Siemens AG and Microsoft Corporation, that can partially or wholly generate an automation artifact based on an input specification. In some embodiments, the one or more automation engineering tools may also include tools for creating automation artifacts in third-party proprietary formats.

[0027] The data backbone 104 may include a data store 108 for persistently storing engineering data in a cross-platform compatible format. The data store 108 may include a number of digital repositories, implemented, for example, in a network-connected storage, cloud storage, local hard drive, or combinations thereof. The cross-platform compatible format may be realized by a common data model 110. The common data model 110 may capture and preserve semantic relationships between physical entities (e.g., PLCs, drives, conveyors, etc.), their digital twin I simulation model counterparts, automation code, configuration artifacts, etc. In various embodiments, the common data model 110 may take the form of a custom-tailored data model (e.g., based on a custom JSON schema), a graph database (e.g., based on Resource Description Framework or RDF), or knowledge graph based on a formalized ontology for industrial systems and automation concepts, among others. The engineering data in the data store 108 may be managed by versioning snapshots of the common data model 110 via a version control system 112, to enable continuous testing, validation and deployment of automation artifacts.

[0028] The common data model 110 may be created based on a simulation design of the automation system. The simulation design may be generated using a number of simulation tools 102a- c as described above. Using simulation design, an ontology may be derived defining semantic relationships between entities of the automation system captured from the simulation tools 102a-c (each of which may its own specific data model). Then, software artifacts, including simulation artifacts and automation artifacts (automation code, configuration files, etc.) that define behavior at the resource level, may be associated as attachments to the corresponding entities of the automation system in the common data model. In practice, such a mapping could associate the simulated logic behavior of a resource, the kinematic modeling of that resource, and the automation code for that resource (e.g. a function block or technology object and associated I / O, defined via an automationDocket No. 202413967 engineering tool, such as TIA Portal®) with the corresponding entity in the common data model.

[0029] FIG. 2 is a simplified visualization of data 200 in a common data model according to one or more embodiments. In the shown example, the data 200 is represented in an object tree derived from a number of simulation tools at different levels of abstraction or granularity. The entities of the automation system, represented in circles, include a plant, which has as attributes, lower level entities, such as lines (production lines), which in turn, have as attributes, machines and PLCs. The software artifacts, represented in rectangles, are attached to the corresponding entities. These include automation artifacts (TIA Portal® projects), simulation artifacts (Process Simulate® Smart Objects), which are attached to corresponding entities such as PLCs and machines, illustrated here with a common numerical identifier. As shown, the automation artifacts may also include artifacts in third- party proprietary formats, such as Studio 5000® of Rockwell Automation in this example. Although not shown, lower-level automation entities like tag tables, signal mappings, function blocks, technology objects, I / O definitions, etc. may also be captured as attributes of higher- level components, such as PLCs.

[0030] The semantic relationships needed to realize the above graph can be automatically derived from the engineering efforts already spent in the simulation design (object trees and connection mapping tables in a simulation tool) and automation programming (e.g., network and device, hardware configuration, etc.). To illustrate with an example, the object tree of a production line modeled in Process Simulate® can directly capture the hierarchical relationship between lines, machines, robots, etc. Furthermore, logical relationships between PLCs can be derived from the network and device configuration of a PLC program such as in a TIA Portal® project.

[0031] The example shown in FIG.2 is simplified. In practice, the common data model can capture multi-dimensional relationships between the entities. For example, in some embodiments, logical connections between entities can be directly derived from signal connection tables in the simulation tool. In some embodiments, mechanical relationships between entities or parts thereof may be derived from a mechanical design of the production line.

[0032] In some embodiments, repeated representations of the same entity may be identified and deduplicated by analyzing external references stored in the existing artifacts. For example, the logic controllers for a machine modeled in a simulation tool (simulation artifact) can be mapped and equatedDocket No. 202413967 to PLCs specified in the network and device configuration associated with a PLC program (automation artifact). Similarly, tags in a PLC program can be equated to signals in a simulation model. By way of example, in Process Simulate®, this can be done by processing the external connections table saved as part of the Process Simulate® file. In case certain entities cannot be automatically mapped with 100% certainty, the user may be prompted to verify or adjust the inferred mappings.

[0033] The attached versions of the respective software artifacts may define a snapshot of common data model 110. In one embodiment, the data backbone 104 may be realized by providing a dedicated repository per artifact / tool. The common data model 110 may be represented in a repository with links (e.g., URLs) to these dedicated repositories, to manage different versions of the software artifacts using the version control system 112. A change to any of the software artifacts may thus create a new snapshot or version of the common data model.

[0034] Continuing with reference to FIG. 1, the automatic conversion module 106 may include one or more automatic conversion tools that can generate automation artifacts and synchronize changes to any artifact across software targets. In some embodiments, as shown, the automatic conversion module 106 may include a suite of automatic conversion tools 106a, 106b, 106c, 106d, each dedicated to a specific task, which can broadly include (1) generating initial automation artifact(s) based on simulation models, e.g., a skeleton of a PLC program based on logic definition in a simulation artifact, and (2) propagating changes in one artifact to other affected artifacts, where the relevant dependencies and semantic relationships are indicated by the common data model 110. In some implementations, the first task may be optional, while still leveraging the common data model 110 to carry out the second task.

[0035] The dependencies indicated in the common data model 110 may be used for propagating changes to the logical behavior of a simulation artifact into changes in the component of a PLC program. For example, a simulation engineer may introduce changes to the behavior of a conveyor that is controlled by a PLC or changes to end-of-arm tooling that is directly controlled by a PLC. Additionally, changes to logical components in a simulation may necessitate changes to a PLC program even if that component is not directly represented in the PLC code as a component. For example, if the behavior of a conveyor changes in simulation (e.g., change of weight due to different loading) such that the way the PLC interfaces with that component is changed, the PLC code should be automatically updated, or the user should be notified that changes will be required. In the aboveDocket No. 202413967 examples, the changes may be introduced by a simulation engineer by changing logic definitions in the simulation artifact (e.g., a smart object representing a conveyor or machine tool), which may be propagated to the programming code of the semantically linked PLC indicated in the common data model 110. Correspondingly, if a change is made to a PLC program, the change may be propagated to a simulation artifact including logic definitions for an entity (e.g., conveyor) controlled by the PLC, or even to an HMI program (enabling the PLC and HMI programs to be validated together).

[0036] In some embodiments, one or more of the automatic conversion tools 106a-d may include a generative artificial intelligence model, such as an LLM. An LLM essentially includes a deep learning model that can recognize and generate text, among other tasks. LLMs can include a very large number (often billions) of model parameters are capable of ingesting massive amounts of data, often from the Internet. LLMs typically include a type of neural network architecture called transformers. Transformer LLMs are capable of unsupervised training on huge sets of data through a now well-known concept of self-attention, to detect subtle ways that elements (“tokens”) in a sequence relate to each other. It is through this process that transformers learn to understand basic grammar, natural languages, and knowledge. Thus, on some level, LLMs can "understand" semantics in that they can associate words and concepts by their meaning, having seen them grouped together in that way millions or billions of times. Any large, complex data set can be used to train LLMs, including programming languages.

[0037] In the present application, an LLM -based tool, such as Industrial Copilot for Engineering®, may be employed to automatically generate and / or revise automation artifacts. The LLM-based tool may be trained (e.g., by fine-tuning of model parameters on a domain specific dataset or by prompt engineering, such as by pre-prompting using one-shot or few-shot learning examples) to flexibly interpret different automation artifact formats and generate a new mapping from that artifact’s representation of known entities and properties into the common data model 110. For example, an LLM-based automatic conversion tool can be prompted to generate a PLC program by interpreting a simulation tool’s representation of the automation logic (i.e., a simulation artifact). In another example, an LLM-based automatic conversion tool can be prompted to revise a PLC program based on a change in a simulation design, e.g., if new signal is added from a new sensor, the LLM can update the PLC program to map a new tag from an analog I / O module with a tag name to describe the sensor. In some embodiments, an LLM-based automatic conversion tool can be used to generate change suggestions for affected artifacts based on a change to one of the artifacts.Docket No. 202413967

[0038] Alternately or additionally, in some embodiments, one or more of the automatic conversion tools 106a-d can include rule-based I engineered conversion recipes for automation artifact formats where a concrete mapping between entities and properties in that format to the common data model 110 is already known. For example, as described above, a “signal” defined in a simulation tool (e.g., Process Simulate®) can map on to a tag on an I / O module defined in an automation engineering tool (e.g., TIA Portal®). The automatic conversion tool may iteratively convert all signals into tags, use the data type (e.g., float or bool) to determine whether it is analog or digital, and swap inputs and outputs (i.e., a control input on the machine is an output on the PLC, and vice-versa). As another example, the automation conversion tool could be used to convert logic behavior blocks (LBs) defined in a simulation tool (e.g., Process Simulate®) to function blocks (FBs) defined in an automation engineering tool (e.g., TIA Portal®). The automatic conversion tool may first convert all signal types and names into the appropriate tags in automation engineering tool, using a rule-based architecture. Then, cyclic logic definitions defined in the LB may be converted, for example, to structured control language (SCL), and directly reused in the FB in the automation engineering tool. Such an automatic conversion tool would allow the user to reuse logic definitions created in simulation for a system component later when writing automation programs.

[0039] In some embodiments, the initial automation artifacts may be automatically generated by the automatic conversion module 106 for a specified target format (e.g., as a TIA Portal® Project), based on the logic definitions in the simulation artifacts indicated in the common data model. For example, a user may be prompted via a user interface to select which new target format to generate for a given uploaded artifact. Alternately, the target format may be specified via system configuration.

[0040] Furthermore, in some embodiments, one or more of the automatic conversion tools 106a- d may also support third-party proprietary automation artifact formats. In this case, the automation artifact in the third-party proprietary format may be automatically mapped (attached) into the common data model 110, and then equivalent automation code can be generated in any desired format (e.g., Siemens TIA Portal®) using an automatic conversion tool. The generated I converted code could then be automatically tested and virtually commissioned against a compatible simulation environment (e.g., Process Simulate®) according to the configuration of the project’s CLCD pipeline.

[0041] After each generation or revision of an artifact, the resultant snapshot of the common data model 110 with the attached (revised) artifacts may be committed to the version control system 112.Docket No. 202413967In this context, a “commit” refers to the action of saving changes to the common data model repository. When a change is committed, a snapshot of the current status of the common data model may be created. The snapshot can include a record of what artifacts were changed, added, or deleted, and can further include a message describing the changes. The version control system 112 may include features such as tagging, branching, or merging functionality to facilitate parallel development and integration processes. An example of a version control system suitable for the present application is Git. Version control may be applied to the entire repository of artifacts for a given project. The version control system 112 may thereby enable engineers from different disciplines (specializing in different simulation I automation engineering tools) to create branches, flag issues, contribute changes, submit merge requests, etc., so that engineering efforts can proceed in parallel while leveraging standard software development synchronization functions (e.g., resolving merge conflicts) and processes (e.g., reviewer and approver roles for merge requests). Also, when test cases (simulation-based or otherwise) fail, issues may be automatically created and assigned to the appropriate engineer based on who committed the changes.

[0042] On each new commit of the common data model 110, the CI-CD execution engine 114, coupled to the version control system 112, may execute a virtual commissioning pipeline to validate each automation artifact and deploy the validated automation artifact. The virtual commissioning pipeline may use a simulation environment, complete with all physical and logical components of the automation system, as a testing environment for each automation artifact. A virtual commissioning pipeline may comprise a series of processing steps, which may include running simulations by executing an automation artifact on a virtualized (or simulated) automation device interacting with the simulation environment over a number of test paths, to verify if a desired behavior or functionality is achieved. The test paths may be designed by a test case generator, which may configure the initial conditions of the simulation environment. The test paths can include both typical and atypical paths (e.g., fault and error handling, ESTOP recovery, etc.).

[0043] The continuous execution (CI) component of the CI-CD execution engine 114 may execute standard tasks, such as integrating code changes into a shared branch of the automation artifact, compiling / building an application and performing code-level tests, such as unit tests (testing logically isolated units of a piece of code), functional tests (testing the code against functional requirements) and integration tests (testing interaction between two or more unit-tested components of a piece of code). According to disclosed embodiments, the CI execution engine may configure and orchestrateDocket No. 202413967 a virtual commissioning pipeline, along with the integration, compiling and testing jobs, for each new commit, using dedicated CI-CD runners 116. According to the configured jobs, the CI-CD runners 116 may instantiate one or more simulations tool 102a-c to validate that the intended system behavior or functionality is preserved, assess the impact of the changes on performance metrics, apply quality gates, etc. For example, in some embodiments, the CI execution engine may execute the virtual commissioning pipeline in addition to code-level testing to implement a quality check I quality gate for each commit of the common data model 110 to the version control system 112 prior to deployment of an automation artifact. In some embodiments, standard software-defined infrastructure approaches (e.g., infrastructure as code / GitOps) can also be integrated to dynamically provision simulation and testing environments.

[0044] Upon successful validation, the continuous deployment / delivery (CD) component of the CI-CD execution engine 114 may deploy the validated automation artifact on a real (or even virtualized) automation device (PLC, robot, HMI, etc.), for example, when the production line is stopped. In some embodiments, a hardware-in-the-loop testing may be performed by coupling the real automation device to the simulation environment, as an additional quality gate before the automation artifact is released on a production line.

[0045] Embodiments of the system 100 described in FIG. 1 can be used to implement a number of use-cases, as illustrated in FIGS. 3 and 4.

[0046] FIG. 3 illustrates a method 300 for automatically generating and validating automation artifacts according to one or more embodiments. The various activity blocks 302-320 of the method 300, including components thereof, may be implemented by a computing system, such as described in FIG. 5. FIG. 3 is not intended to indicate that the activity blocks of the method 300 are to be executed in any particular order, or that all of the activity blocks of the method 300 are to be included in every case. Additionally, the method 300 can include any suitable number of additional operations.

[0047] The method 300 may be implemented, for example, during a line design phase after a production layout planning, wherein an automation logic is being shaped using simulation tools. The method 300 is directed to reusing the automation logic in the simulation tools to automatically generate automation artifacts.Docket No. 202413967

[0048] At 302, a simulation design of an automation system may be generated using a number of simulation tools. In some embodiments, the simulation tools may be configured to model the automation system at different levels of granularity and / or model different aspects of the automation system. Using the simulation tools, simulation artifacts may be created representing entities of the automation system. The simulation artifacts may include logic defining behaviors of the corresponding entities.

[0049] At 304, a common data model may be automatically created based on the simulation design. The common data model may include an ontology of semantic relationships between entities of the automation system captured from the simulation tools. Then, the simulation artifacts may be attached to the corresponding entities in the common data model.

[0050] At 306, an initial version of an automation artifact may be generated by an automatic conversion module utilizing logic definitions from the simulation artifacts in the common data model. The initial version of the automation artifact may be attached to a corresponding entity in the common data model. In some embodiments, the automation artifact may include programming code for a PLC, or a robot or HMI, among others. In some embodiments, the automatic conversion module may generate the automation artifact in a specified target format. In some embodiments, the automatic conversion module may include an LLM for generating the automation artifact.

[0051] At 308, a snapshot of the common data model that includes the attached simulation artifacts and the initial version of the automation artifact may be committed to the version control system.

[0052] At 310, a CI execution engine, coupled to the version control system, may perform integration, compiling / building and testing of the automation artifact. The testing may include executing a virtual commissioning pipeline for validating the automation artifact against a simulation environment in a simulation of the automation system, based on the commit of the common data model. The CI execution engine may orchestrate the virtual commissioning pipeline together with code-level testing (e.g., unit / functional / integration tests) to validate the automation artifact.

[0053] At 312, a quality gate may be implemented based on the validation outcome of the virtual commissioning pipeline as well as code-level tests executed by the CI execution engine.Docket No. 202413967

[0054] If the validation outcome at the quality gate 312 is “not passed”, activity blocks 314 and 316 may be carried out over one or multiple instances. The dashed arrows indicate that at least some of the multiple instances may be carried out in parallel, for example via different engineers working in parallel on different simulation and / or automation engineering tools in a collaborative environment.

[0055] At 314, a change may be made to an artifact, for example based on a user input. The changed artifact at any instance could be a simulation artifact (e.g., smart object) or an automation artifact (e.g., a PLC program).

[0056] At 316, the change to one artifact may be propagated via the automatic conversion module to affected artifacts in the common data model utilizing dependencies defined by the semantic relationships, to define a new commit of the common data model to the version control system.

[0057] Subsequently, at 310, the CI execution engine may again perform integration, compiling I building and testing, including executing the virtual commissioning pipeline to validate the automation artifact, based on the new commit of the common data model. The process may be repeated for each instance and may be iterated multiple times, until the validation outcome at the quality gate 312 is “passed”.

[0058] If the validation outcome at the quality gate 312 is “passed”, the validated automation artifact may be deployed on a real or virtualized automation device via a CD execution engine.

[0059] FIG. 4 illustrates a method 400 for automatically modifying and (re-)validating automation artifacts according to one or more embodiments. The various activity blocks 402-414 of the method 400, including components thereof, may be implemented by a computing system, such as described in FIG. 5. FIG. 4 is not intended to indicate that the activity blocks of the method 400 are to be executed in any particular order, or that all of the activity blocks of the method 400 are to be included in every case. Additionally, the method 400 can include any suitable number of additional operations.

[0060] The method 400 may be implemented, for example, after an automation system has been fully designed, complete with automation artifacts. The method 400 can be used to ensure that any subsequent changes made to a software artifact, e.g., based on validation outcomes, are applied consistently to other artifacts.Docket No. 202413967

[0061] At 402, a common data model is created for a simulation design of the automation system. The common data model may include an ontology of semantic relationships between entities of the automation system captured from a number of simulation tools based on a simulation design. The common data model may comprise artifacts, including one or more automation artifacts and simulation artifacts, attached to the corresponding entities.

[0062] At 404, a change may be made to at least one of the artifacts, for example, based on a user input. The changed artifact could be a simulation artifact (e.g., smart object) or an automation artifact (e.g., a PLC program). By way of example, the user input may include adding a new sensor to a production line via a simulation tool.

[0063] At 406, the change made to the artifact may be propagated to affected artifacts in the common data model utilizing dependencies defined by the semantic relationships. Continuing with the above example, the propagated change may include changing a PLC program for a semantically linked PLC (out of several PLCs on the production line), e.g., adding an I / O module for the newly added sensor and mapping the I / O module to a PLC tag. In some embodiments, propagating the change may include using an automatic conversion tool to revise or generate change suggestions for an affected artifact. The automatic conversion tool may include, for example, an LLM. In some embodiments, propagating the change may comprise visually highlighting the affected artifacts in the common data model via a GUI, for a user to manually revise an affected artifact.

[0064] At 408, a snapshot of the common data model that includes the changed artifacts may be committed to a version control system.

[0065] At 410, a CI execution engine, coupled to the version control system, may perform integration, compiling I building and testing of the automation artifact. The testing may include executing a virtual commissioning pipeline for validating each automation artifact against a simulation environment in a simulation of the automation system, based on the commit of the common data model. The CI execution engine may orchestrate the virtual commissioning pipeline together with code-level testing (e.g., unit / functional / integration tests) to validate each automation artifact.

[0066] Note that activity blocks 404 to 410 may be carried out over multiple instances. The dashed arrows indicate that at least some of the multiple instances may be carried out in parallel, for exampleDocket No. 202413967 via different engineers working in parallel on different simulation and / or automation engineering tools in a collaborative environment.

[0067] At 412, a quality gate may be implemented for each instance (i.e., each commit of the common data model) based on the validation outcome of the virtual commissioning pipeline as well as code-level tests executed by the CI execution engine.

[0068] If the validation outcome at the quality gate 412 is “not passed”, activity blocks 404 to 410 may be carried out over additional one or multiple instances, as indicated by the dashed arrows. The process may be repeated for each instance and may be iterated multiple times, until the validation outcome at the quality gate 412 is “passed”.

[0069] If the validation outcome at the quality gate 412 is “passed”, the validated automation artifact may be deployed on a real or virtualized automation device via a CD execution engine.

[0070] FIG. 5 illustrates an example of a computing environment within which embodiments of the present disclosure may be implemented. A computing environment 500 includes a computer system 510 that may include a communication mechanism such as a system bus 521 or other communication mechanism for communicating information within the computer system 510. The computer system 510 further includes one or more processors 520 coupled with the system bus 521 for processing the information.

[0071] The processors 520 may include one or more central processing units (CPUs), graphical processing units (GPUs), or any other processor known in the art. More generally, a processor as described herein is a device for executing machine-readable instructions stored on a computer readable medium, for performing tasks and may comprise any one or combination of, hardware and firmware. A processor may also comprise memory storing machine-readable instructions executable for performing tasks. A processor acts upon information by manipulating, analyzing, modifying, converting or transmitting information for use by an executable procedure or an information device, and / or by routing the information to an output device. A processor may use or comprise the capabilities of a computer, controller or microprocessor, for example, and be conditioned using executable instructions to perform special purpose functions not performed by a general purpose computer. A processor may include any type of suitable processing unit including, but not limited to,Docket No. 202413967 a central processing unit, a microprocessor, a Reduced Instruction Set Computer (RISC) microprocessor, a Complex Instruction Set Computer (CISC) microprocessor, a microcontroller, an Application Specific Integrated Circuit (ASIC), a Field-Programmable Gate Array (FPGA), a System- on-a-Chip (SoC), a digital signal processor (DSP), and so forth. Further, the processor(s) 520 may have any suitable microarchitecture design that includes any number of constituent components such as, for example, registers, multiplexers, arithmetic logic units, cache controllers for controlling read / write operations to cache memory, branch predictors, or the like. The microarchitecture design of the processor may be capable of supporting any of a variety of instruction sets. A processor may be coupled (electrically and / or as comprising executable components) with any other processor enabling interaction and / or communication there-between. A user interface processor or generator is a known element comprising electronic circuitry or software or a combination of both for generating display images or portions thereof. A user interface comprises one or more display images enabling user interaction with a processor or other device.

[0072] The system bus 521 may include at least one of a system bus, a memory bus, an address bus, or a message bus, and may permit exchange of information (e.g., data (including computerexecutable code), signaling, etc.) between various components of the computer system 510. The system bus 521 may include, without limitation, a memory bus or a memory controller, a peripheral bus, an accelerated graphics port, and so forth. The system bus 521 may be associated with any suitable bus architecture including, without limitation, an Industry Standard Architecture (ISA), a Micro Channel Architecture (MCA), an Enhanced ISA (EISA), a Video Electronics Standards Association (VESA) architecture, an Accelerated Graphics Port (AGP) architecture, a Peripheral Component Interconnects (PCI) architecture, a PCI-Express architecture, a Personal Computer Memory Card International Association (PCMCIA) architecture, a Universal Serial Bus (USB) architecture, and so forth.

[0073] Continuing with reference to FIG. 5, the computer system 510 may also include a system memory 530 coupled to the system bus 521 for storing information and instructions to be executed by processors 520. The system memory 530 may include computer readable storage media in the form of volatile and / or nonvolatile memory, such as read only memory (ROM) 531 and / or random access memory (RAM) 532. The RAM 532 may include other dynamic storage device(s) (e.g., dynamic RAM, static RAM, and synchronous DRAM). The ROM 531 may include other static storage dcvicc(s) (e.g., programmable ROM, erasable PROM, and electrically erasable PROM). In addition,Docket No. 202413967 the system memory 530 may be used for storing temporary variables or other intermediate information during the execution of instructions by the processors 520. A basic input / output system 533 (BIOS) containing the basic routines that help to transfer information between elements within computer system 510, such as during start-up, may be stored in the ROM 531. RAM 532 may contain data and / or program modules that are immediately accessible to and / or presently being operated on by the processors 520. System memory 530 may additionally include, for example, operating system 534, application modules 535, and other program modules 536. Application modules 535 may include aforementioned modules described for FIG. 1 and may also include a user portal for development of the application program, allowing input parameters to be entered and modified as necessary.

[0074] The operating system 534 may be loaded into the memory 530 and may provide an interface between other application software executing on the computer system 510 and hardware resources of the computer system 510. More specifically, the operating system 534 may include a set of computer-executable instructions for managing hardware resources of the computer system 510 and for providing common services to other application programs (e.g., managing memory allocation among various application programs). In certain example embodiments, the operating system 534 may control execution of one or more of the program modules depicted as being stored in the data storage 540. The operating system 534 may include any operating system now known or which may be developed in the future including, but not limited to, any server operating system, any mainframe operating system, or any other proprietary or non-proprietary operating system.

[0075] The computer system 510 may also include a disk / media controller 543 coupled to the system bus 521 to control one or more storage devices for storing information and instructions, such as a magnetic hard disk 541 and / or a removable media drive 542 (e.g., floppy disk drive, compact disc drive, tape drive, flash drive, and / or solid state drive). Storage devices 540 may be added to the computer system 510 using an appropriate device interface (e.g., a small computer system interface (SCSI), integrated device electronics (IDE), Universal Serial Bus (USB), or FireWire). Storage devices 541, 542 may be external to the computer system 510.

[0076] The computer system 510 may include a user input interface or graphical user interface (GUI) 561, which may comprise one or more input devices, such as a keyboard, touchscreen, tablet and / or a pointing device, for interacting with a computer user and providing information to the processors 520.Docket No. 202413967

[0077] The computer system 510 may perform a portion or all of the processing steps of embodiments of the invention in response to the processors 520 executing one or more sequences of one or more instructions contained in a memory, such as the system memory 530. Such instructions may be read into the system memory 530 from another computer readable medium of storage 540, such as the magnetic hard disk 541 or the removable media drive 542. The magnetic hard disk 541 and / or removable media drive 542 may contain one or more data stores and data files used by embodiments of the present disclosure. The data store 540 may include, but are not limited to, databases (e.g., relational, object-oriented, etc.), file systems, flat files, distributed data stores in which data is stored on more than one node of a computer network, peer-to-peer network data stores, or the like. Data store contents and data files may be encrypted to improve security. The processors 520 may also be employed in a multi-processing arrangement to execute the one or more sequences of instructions contained in system memory 530. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions. Thus, embodiments are not limited to any specific combination of hardware circuitry and software.

[0078] As stated above, the computer system 510 may include at least one computer readable medium or memory for holding instructions programmed according to embodiments of the invention and for containing data structures, tables, records, or other data described herein. The term “computer readable medium” as used herein refers to any medium that participates in providing instructions to the processors 520 for execution. A computer readable medium may take many forms including, but not limited to, non-transitory, non-volatile media, volatile media, and transmission media. Nonlimiting examples of non-volatile media include optical disks, solid state drives, magnetic disks, and magneto-optical disks, such as magnetic hard disk 541 or removable media drive 542. Non-limiting examples of volatile media include dynamic memory, such as system memory 530. Non-limiting examples of transmission media include coaxial cables, copper wire, and fiber optics, including the wires that make up the system bus 521. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0079] Computer readable medium instructions for carrying out operations of the present disclosure may be assembler instructions, instruction-set-architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, firmware instructions, state-setting data, or either source code or object code written in any combination of one or more programming languages, including an object oriented programming language such as Smalltalk, C++ or the like, andDocket No. 202413967 conventional procedural programming languages, such as the "C" programming language or similar programming languages. The computer readable program instructions may execute entirely on the user's computer, partly on the user's computer, as a stand-alone software package, partly on the user's computer and partly on a remote computer or entirely on the remote computer or server. In the latter scenario, the remote computer may be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection may be made to an external computer (for example, through the Internet using an Internet Service Provider). In some embodiments, electronic circuitry including, for example, programmable logic circuitry, field- programmable gate arrays (FPGA), or programmable logic arrays (PLA) may execute the computer readable program instructions by utilizing state information of the computer readable program instructions to personalize the electronic circuitry, in order to perform aspects of the present disclosure.

[0080] Aspects of the present disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, may be implemented by computer readable medium instructions.

[0081] The computing environment 500 may further include the computer system 510 operating in a networked environment using logical connections to one or more remote computers, such as remote computing device 580. The network interface 570 may enable communication, for example, with other remote devices 580 or systems and / or the storage devices 541, 542 via the network 571. Remote computing device 580 may be a personal computer (laptop or desktop), a mobile device, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to computer system 510. When used in a networking environment, computer system 510 may include modem 572 for establishing communications over a network 571, such as the Internet. Modem 572 may be connected to system bus 521 via user network interface 570, or via another appropriate mechanism.

[0082] Network 571 may be any network or system generally known in the art, including the Internet, an intranet, a local area network (LAN), a wide area network (WAN), a metropolitan area network (MAN), a direct connection or series of connections, a cellular telephone network, or anyDocket No. 202413967 other network or medium capable of facilitating communication between computer system 510 and other computers (e.g., remote computing device 580). The network 571 may be wired, wireless or a combination thereof. Wired connections may be implemented using Ethernet, Universal Serial Bus (USB), RJ-6, or any other wired connection generally known in the art. Wireless connections may be implemented using Wi-Fi, WiMAX, and Bluetooth, infrared, cellular networks, satellite or any other wireless connection methodology generally known in the art. Additionally, several networks may work alone or in communication with each other to facilitate communication in the network 571.

[0083] It should be appreciated that the program modules, applications, computer-executable instructions, code, or the like depicted in FIG. 5 as being stored in the system memory 530 are merely illustrative and not exhaustive and that processing described as being supported by any particular module may alternatively be distributed across multiple modules or performed by a different module. In addition, various program module(s), script(s), plug-in(s), Application Programming Interface(s) (API(s)), or any other suitable computer-executable code hosted locally on the computer system 510, the remote device 580, and / or hosted on other computing device(s) accessible via one or more of the network(s) 571, may be provided to support functionality provided by the program modules, applications, or computer-executable code depicted in FIG. 5 and / or additional or alternate functionality. Further, functionality may be modularized differently such that processing described as being supported collectively by the collection of program modules depicted in FIG. 5 may be performed by a fewer or greater number of modules, or functionality described as being supported by any particular module may be supported, at least in part, by another module. In addition, program modules that support the functionality described herein may form part of one or more applications executable across any number of systems or devices in accordance with any suitable computing model such as, for example, a client-server model, a pccr-to-pccr model, and so forth. In addition, any of the functionality described as being supported by any of the program modules depicted in FIG. 5 may be implemented, at least partially, in hardware and / or firmware across any number of devices.

[0084] It should further be appreciated that the computer system 510 may include alternate and / or additional hardware, software, or firmware components beyond those described or depicted without departing from the scope of the disclosure. More particularly, it should be appreciated that software, firmware, or hardware components depicted as forming part of the computer system 510 are merely illustrative and that some components may not be present or additional components may be provided in various embodiments. While various illustrative program modules have been depicted andDocket No. 202413967 described as software modules stored in system memory 530, it should be appreciated that functionality described as being supported by the program modules may be enabled by any combination of hardware, software, and / or firmware. It should further be appreciated that each of the above-mentioned modules may, in various embodiments, represent a logical partitioning of supported functionality. This logical partitioning is depicted for ease of explanation of the functionality and may not be representative of the structure of software, hardware, and / or firmware for implementing the functionality. Accordingly, it should be appreciated that functionality described as being provided by a particular module may, in various embodiments, be provided at least in part by one or more other modules. Further, one or more depicted modules may not be present in certain embodiments, while in other embodiments, additional modules not depicted may be present and may support at least a portion of the described functionality and / or additional functionality. Moreover, while certain modules may be depicted and described as sub-modules of another module, in certain embodiments, such modules may be provided as independent modules or as sub-modules of other modules.

[0085] Although specific embodiments of the disclosure have been described, one of ordinary skill in the art will recognize that numerous other modifications and alternative embodiments are within the scope of the disclosure. For example, any of the functionality and / or processing capabilities described with respect to a particular device or component may be performed by any other device or component. Further, while various illustrative implementations and architectures have been described in accordance with embodiments of the disclosure, one of ordinary skill in the art will appreciate that numerous other modifications to the illustrative implementations and architectures described herein are also within the scope of this disclosure. In addition, it should be appreciated that any operation, element, component, data, or the like described herein as being based on another operation, element, component, data, or the like can be additionally based on one or more other operations, elements, components, data, or the like. Accordingly, the phrase “based on,” or variants thereof, should be interpreted as “based at least in part on.

Claims

Docket No. 202413967CLAIMSWhat is claimed is:

1. A computer- implemented method for automatically generating and validating automation artifacts, comprising: generating a simulation design of an automation system via a number of simulation tools to create simulation artifacts for entities of the automation system, the simulation artifacts including logic defining behaviors of the corresponding entities, based on the simulation design, creating a common data model in a data store, the common data model including an ontology of semantic relationships between entities of the automation system captured from the simulation tools, wherein the simulation artifacts are attached to the corresponding entities in the common data model, generating, via an automatic conversion module, an initial version of an automation artifact utilizing logic definitions from the simulation artifacts in the common data model and attaching the initial version automation artifact to a corresponding entity in the common data model, committing a snapshot of the common data model that includes the attached simulation artifacts and the initial version of the automation artifact to a version control system, and executing, via a continuous integration (CI) execution engine coupled to the version control system, a virtual commissioning pipeline for validating the automation artifact against a simulation environment in a simulation of the automation system, based on the commit of the common data model.

2. The method according to claim 1, wherein the simulation tools are configured to model the automation system at different levels of granularity and / or model different aspects of the automation system.

3. The method according to any of claims 1 and 2, wherein the automation artifact comprises programming code for a PLC or a robot or an HMI.

4. The method according to any of claims 1 to 3, wherein the automatic conversion module generates the automation artifact in a specified target format.Docket No. 2024139675. The method according to any of claims 1 to 4, wherein the automatic conversion module includes a trained generative artificial intelligence model for generating the automation artifact.

6. The method according to any of claims 1 to 5, further comprising performing, over one or multiple instances: based on a validation outcome, making a change to one or more artifacts in the common data model, propagating the change, via the automatic conversion module, to affected artifacts in the common data model utilizing dependencies defined by the semantic relationships, to define a new commit of the common data model to the version control system, and executing, via the CI execution engine, the virtual commissioning pipeline to validate the automation artifact based on the new commit of the common data model.

7. The method according to claim 6, wherein at least some of the multiple instances arc executed in parallel.

8. The method according to any of claims 1 to 7, wherein CI execution engine executes the virtual commissioning pipeline in addition to code-level testing to implement a quality check for each commit of the common data model to the version control system prior to deployment of the automation artifact.

9. The method according to any of claims 1 to 8, further comprising deploying the validated automation artifact on an automation device via a continuous deployment I delivery (CD) execution engine.

10. A computer-implemented method for modifying and validating automation artifacts, comprising: creating a common data model for an automation system in a data store, the common data model including an ontology of semantic relationships between entities of the automation system captured from a number of simulation tools based on a simulation design of the automation system, the common data model comprising artifacts, including one or more automation artifacts and simulation artifacts, attached to corresponding entities, andDocket No. 202413967 performing, over one or multiple instances: making a change to at least one of the artifacts, propagating the change to affected artifacts in the common data model utilizing dependencies defined by the semantic relationships, committing a snapshot of the common data model that includes the changed artifacts to a version control system, and executing, via a continuous integration (CI) execution engine coupled to the version control system, a virtual commissioning pipeline for validating each automation artifact against a simulation environment in a simulation of the automation system, based on the commit of the common data model.

11. The method according to claim 10, wherein propagating the change comprises using an automatic conversion tool to revise or generate change suggestions for an affected artifact.

12. The method according to claim 11, wherein the automatic conversion tool comprises a trained generative artificial intelligence model.

13. The method according to claim 10, wherein propagating the change comprises visually highlighting the affected artifacts in the common data model via a GUI, for a user to manually revise an affected artifact.

14. The method according any of claims 10 to 13, wherein at least some of the multiple instances are executed in parallel.

15. The method according to any of claims 10 to 14, wherein CI execution engine executes the virtual commissioning pipeline in addition to code-level testing to implement a quality check for each commit of the common data model to the version control system prior to deployment of each automation artifact.

16. The method according to any of claims 10 to 15, further comprising deploying a validated automation artifact on an automation device via a continuous deployment I delivery (CD) execution engine.Docket No. 20241396717. A non-transitory computer-readable storage medium including instructions that, when processed by one or more processors, configure the one or more processors to perform the method according to any one of claims 1 to 16.

18. A system for generating and automatically verifying automation code, comprising: one or more processors, and memory storing instructions executable by the one or more processors to perform a method according to any of claims 1 to 16.

Images