Automated control application development using IEC 61499 architecture

Abstract

The invention relates to automatic control application development using an IEC 61499 architecture. Relatively simple user inputs are used to develop automation control applications. For automated control application development using an IEC 61499 architecture, a method includes receiving system prompts, automatically retrieving related information from a large corpus including a plurality of libraries, automatically creating assets based on the related information, automatically generating a control sequence based on the related information, automatically generating a human-computer interface based on the related information, and automatically generating a test case based on the related information, and automatically generating document compilation based on the related information.

Description

[0001] Cross Reference to Related Applications

[0002] This application claims the benefit of Indian Patent Application No. 202411031775, filed April 22, 2024, and Indian Patent Application No. 202511029969, filed March 28, 2025, the entire disclosures of which are incorporated herein by reference. BACKGROUND

[0003] Control applications are developed for automating discrete machines, continuous, or batch processes. It can be tedious and time consuming to gain a thorough understanding of the automation and / or control system using known methods and systems. For example, an engineer can need to watch machine videos, read operator manuals, and / or have multiple discussions with users to gather high-level machine requirements. Further, known tools for developing automation and control systems involve time-consuming steps of defining data models, defining data relationships, creating assets, writing control sequences, and testing and validating code. Relying on human effort alone can also lead to inaccuracies, inconsistencies, or other issues. Moreover, at least some control applications do not adapt to advanced architectures, such as required by International Electrotechnical Commission (IEC) standard IEC 61499, which defines an event-driven paradigm. Strict deadlines, the rigor involved in understanding hundreds of pages of requirements, the steep learning curve involved in understanding IEC 61499 practices, and the lack of experts and expertise hinder faster control application development. SUMMARY

[0004] Aspects of the present disclosure enable development of automation control applications based on relatively simple user inputs.

[0005] In one aspect, a method for automation control application development according to IEC 61499 architecture is provided. The method includes receiving a system prompt, and automatically retrieving relevant information from a large corpus comprising a plurality of libraries. The method further includes automatically creating an asset based on the relevant information, automatically generating a control sequence based on the relevant information, automatically generating a human-machine interface based on the relevant information, automatically generating a test case based on the relevant information, and automatically generating documentation based on the relevant information.

[0006] In another aspect, a computing system is provided. The computing system includes one or more computer storage media including data and computer-executable instructions, and one or more processors configured to execute the computer-executable instructions. When executed, the instructions configure the processors to receive a system prompt and automatically retrieve relevant information from a large corpus including a plurality of libraries. The instructions further configure the processors to automatically create an asset based on the relevant information, automatically generate a control sequence based on the relevant information, automatically generate a human-machine interface based on the relevant information, automatically generate a test case based on the relevant information, and automatically generate documentation based on the relevant information.

[0007] Other objects and features of the present disclosure will be in part apparent and in part pointed out hereinafter. BRIEF DESCRIPTION OF DRAWINGS

[0008] Figure 1 is a block diagram illustrating an example system for automatically generating application code according to an embodiment;

[0009] Figure 2A is a flow diagram illustrating an example process for generating application code by the system of Figure 1 according to an embodiment;

[0010] Figure 2B illustrates an example large language model (LLM) architecture with low-rank adaptation (LoRA) for use with the system of Figure 1 and the process of Figure 2A according to an embodiment;

[0011] Figure 3 illustrates an example support library for the IEC 61499 framework according to an embodiment;

[0012] Figure 4 is a block diagram illustrating an example operation for generating application code by the system of Figure 1 according to an embodiment;

[0013] Figure 5 is a flow diagram illustrating an example process for use with the operation of Figure 4 illustrated in FIG. 7 according to an embodiment;

[0014] Figure 6 illustrates example criteria that can be used to evaluate code generated using the system of Figure 1 illustrated in FIG. 6 according to an embodiment;

[0015] Figure 7A is a block diagram illustrating an example system and process for generating a control sequence using the system of Figure 1 illustrated in FIG. 5 according to an embodiment;

[0016] Figure 7B is a block diagram illustrating an example system and process for generating a human machine interface (HMI) using Figure 1 the system shown in FIG. 1;

[0017] Figure 7C is a block diagram illustrating an example system and process for generating test cases using Figure 1 the system shown in FIG. 2;

[0018] Figure 7D is a block diagram illustrating an example system and process for generating documentation using Figure 1 the system shown in FIG. 3;

[0019] Figure 7E is a block diagram illustrating an example system and process for automated data modeling and updating using Figure 1 the system shown in FIG. 4;

[0020] Figure 8 is a block diagram illustrating example inputs and outputs associated with Figure 1 the system shown in FIG. 5;

[0021] Figures 9A to 9D is an example functional block diagram and corresponding XML output generated by Figure 1 the system of FIG. 6, according to an embodiment;

[0022] Figure 10 is a computer architecture diagram illustrating an example computing system that can be used to perform one or more computing operations in the illustrated examples, according to an embodiment.

[0023] The reference numbers refer to corresponding parts throughout the several figures. DETAILED DESCRIPTION

[0024] The features and other details of the concepts, systems, and techniques sought to be protected herein will now be more particularly described with reference to the drawings. It will be understood that the particular embodiments described herein are shown by way of example and not as limitations of the disclosure and concepts described herein. The features of the subject matter described herein can be employed in various embodiments without departing from the scope of the concepts sought to be protected.

[0025] The present disclosure relates to automation systems, and more particularly, to automation control application development according to the IEC 61499 architecture. The examples described herein enable automation end-to-end application development with minimal user intervention or involvement, utilizing existing distributed industrial automation system architectures, and taking into account batch process control standards. The methods and systems described herein can be adapted to various programming languages and / or engineering tools. The present disclosure relates to a software-defined approach to automation, developing a single, scalable industrial automation environment for continuous, hybrid, or discrete processes. The examples described herein simplify existing complexities and allow users to update or change their automation according to what they need, when they need it, and from whom they want to get it.

[0026] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this disclosure belongs. Although any methods and materials similar or equivalent to those described herein can be used in the practice or testing of the present disclosure, example systems and methods are described below.

[0027] To meet the needs of industrial systems, tools for efficient management, configuration, and control of devices within the system are needed. Ideally, interactive engineering management software provides simplified management and programming tools for users. Users refer to any entity that configures and / or manages application development. For example, users can include operators of a plant, personnel with programming expertise in an industrial environment, or other automation devices that can provide instructions for configuring or creating applications. However, each device within the system requires application code for execution in the environment. As devices can come from a variety of manufacturers, different requirements can apply. To simplify and unify management, standards create a uniform guide for creating application code or other reusable software components. For example, IEC 61499 provides a standard for management within industrial applications.

[0028] The need for distributed control topologies has led to the development of programming language standards such as IEC 61499, an international standard for distributed (event-based) industrial applications published by the International Electrotechnical Commission. Generally, IEC 61499 defines a generic architecture that enables application-centric design in which one or more applications (defined by networks of interconnected function blocks) are created for the entire system and then distributed to available devices. A function block is a convenient programming mechanism that integrates a set of programming instructions to perform a specific and normalized action, such as speed control, interval control, or counting. IEC 61499 addresses the topic of function block-based distributable control applications for industrial process measurement and control systems.

[0029] In the IEC 61499 architectural model, a distributable application is constructed by interconnecting instances of reusable function block types with appropriate events and data connections in the same way that circuit boards with integrated circuits are designed. Using IEC 61499 compliant software tools, these function blocks can be distributed and then deployed over a network to the runtime components of IEC 61499 compliant physical devices (controllers). In this way, distributed control and automation systems can be configured from a library of reusable IEC 61499 compliant components.

[0030] According to the standard, control application execution is event-driven, where an event represents a change in state or condition of the system, which is different from classic scan-based distributed control systems. The IEC 61499 standard also specifies a set of software components and applications that implementers of the standard must implement or develop.

[0031] While the IEC 61499 standard provides a structure for function block development, use of the standard without additional tools relies on individual user expertise with the standard. By leveraging a specially trained machine learning model, such as an LLM, in conjunction with interactive engineering management software, a system can provide easy and efficient generation of application code for implementation within an industrial automation system. Further, by leveraging fine-tuned training, such as through LoRA, the LLM can operate on relatively lightweight hardware within an industrial automation system and have a more efficient and targeted training process.

[0032] Referring to the drawings and the following description, a system 101 for generating applications is disclosed. Figure 1 is a block diagram illustrating a system 101, which can also be referred to as an engineering system. The system 101 generates applications for controlling and operating industrial automation devices 102. The industrial automation devices 102 can include control devices, such as a distributed control system (DCS), a supervisory control and data acquisition (SCADA) system, a programmable automation controller (PAC), a remote terminal unit (RTU), an industrial automation and control system (IACS), an intelligent electronic device (IED). Additionally, the industrial automation devices 102 can include industrial equipment for performing an industrial process, such as a sensor, a robot, or other machine. Examples of various industrial automation devices 102 of an industrial automation system are further described in U.S. Patent Application Publication No. 2024 / 0377808, entitled “Systems and Methods for Autonomous Anomaly Management of an Industrial Site,” assigned to Schneider Electric System USA, Inc., the entirety of which is incorporated by reference herein.

[0033] In some embodiments, the generated application code complies with the IEC 61499 standard. However, while described below with respect to the IEC 61499 standard, other software standards can define requirements for reusable software components. The engineering processor 104 generates application code (or reusable software components). In some embodiments, the engineering processor 104 monitors and controls the operation of industrial systems within an industrial facility. In other embodiments, the engineering processor 104 operates outside of the industrial facility through the cloud. The engineering processor 104 is electronically coupled with a memory that stores instructions for performing the generation of the application code.

[0034] In some embodiments, Figure 1 The engineering processor 104 of the system 100 executes interactive engineering management software that enables a user to configure and change the industrial system and its components. The engineering processor 104 is coupled with input and output devices (e.g., a keyboard, a mouse, a display, and / or a microphone) for inputting information to the processor 104 and the interactive software. Further, the interactive engineering management software enables the user to input information for the generation of the application code. The interactive software also displays aspects of the industrial automation system, including the network of functional blocks that comprise the application code. For example, Schneider Electric’s EcoStruxure Automation Expert (EAE) provides suitable interactive software for managing the system for generating the application code as well as aspects of the industrial automation system itself.

[0035] The engineering database 106 is electronically coupled with the engineering processor 104. The engineering database 106 stores information about the industrial automation system. In some embodiments, the engineering database 106 also stores standard information about the generation of the application code. The standard information includes syntax, semantics, and best practice information. In some embodiments, the syntax, semantics, and best practice information are defined by a standard such as IEC 61499. In one or more embodiments, the engineering database 106 additionally stores historical application code information, such as previously generated application code, information about devices associated with the application code, and execution information for the application code.

[0036] With further reference to Figure 1 The LLM engine 108 receives input information from a user to generate the application code. The engineering processor 104 executes the LLM engine 108. The LLM engine 108 trains on historical application code information as well as pre-generated application code designed to perform tasks within the industrial automation system. In some embodiments, the LLM engine 108 also trains on semantics, syntax, and best practice information to generate the application code. In some embodiments, the LLM engine 108 implements LoRA to update the model based on the industrial system information. By utilizing LoRA, the model updates target parameters and enables to simplify retraining and execution.

[0037] Figure 2A is a flowchart 201 illustrating a process of generating application code according to one embodiment. Beginning at step 202, the engineering processor 104 receives natural language input to generate application code. At step 204, a user (e.g., an operator) can provide information for building a particular control application. For example, the user input can include a system diagram (e.g., a P&ID), a flow sheet, a process description, etc., for building or updating a data model. In some embodiments, the user enters text into prompts of an interactive software to create the natural language input. In other embodiments, the user speaks into a microphone coupled to the engineering processor 104, and a speech-to-text engine converts the input into text. For example, the user can input the request “create an application for a cascade PID to control a tank level using a feed control valve.”

[0038] In some embodiments, the LLM engine 108 executed by the engineering processor 104 evaluates the input text at steps 206, 208, and 210. The LLM engine 108 evaluates the text to determine whether the text provides sufficient information for generating the application code. For example, to generate proper application code according to the IEC 61499 standard, the LLM engine 108 can need to identify a device for performing control, a function goal, one or more function states, and function variables. Thus, the input information can relate to components of a function block included in the application code, such as input events, input variables, state buffers, algorithmic logic, output events, and output variables.

[0039] Referring to the previous example input of “create an application for a cascade PID to control a tank level using a feed control valve,” the LLM engine 108 can determine that the input identifies a goal, namely, to perform “cascade PID control” and an input “feed control valve.” As a result, the LLM engine 108 then determines whether the information can be turned into application code. In some embodiments, if the LLM engine 108 determines that the input text is insufficient for generation, the LLM engine 108 generates a prompt to present to the user requesting more information. The LLM engine 108 can then receive supplemental or alternative input from the user to satisfy the requirements for generation. For example, if the user only requests “generate application code to perform cascade PID control,” the LLM engine 108 can request that the user indicate which feed control element to use. In other embodiments, if the input is insufficient such that it does not provide enough context for the prompt, the LLM engine 108 generates an error and returns at step 212 to receive new input from the user at 204. Figure 2A Accordingly, in response to the example insufficient request, the LLM engine 108 requests that the user input a complete generation request. Then at step 214, assuming the input is sufficient at 212, the LLM engine 108 generates the application code based on the input. In some embodiments, the LLM engine 108 generates the application code according to the IEC 61499 standard. In other embodiments, the LLM engine 108 generates the application code according to another standard or in a proprietary format. Figure 2Asufficient, the LLM engine 108 continues to generate components of the application code. The context cue generator system 252 (further discussed herein) can communicate with the application code generator system 254 (also further discussed herein) to generate a data model and output the model at step 216, which can be integrated with the system 101. At step 218, the context cue generator system 252 can communicate with the engineering database 106 to save the data model at the engineering database 106.

[0040] Figure 2B An example machine learning system 219 having an LLM architecture with low-rank adaptation (LoRA) is shown in accordance with an embodiment, which is used to Figure 2A the process and / or Figure 1 the system 101.

[0041] In some examples, the machine learning system 219 can include a retriever augmented generation (RAG) system 220 that receives the user input at 204. The RAG system 220 can include or be in communication with at least one LLM 222 that is configured to analyze the user input 204 and determine one or more machine requirements or specifications for effectively performing one or more functions. Such machine requirements can include one or more of hardware specifications, operating systems, software libraries, software frameworks, runtime environments, network connectivity, environmental considerations (e.g., temperature, humidity, vibration tolerance, etc.), regulatory compliance, industry standards, etc., retrieved from a database. In some examples, the RAG system 220 can determine whether there is sufficient context to understand the user input 204 and / or determine the one or more machine requirements. If there is not sufficient context, the RAG system 220 can prompt the user for additional user input.

[0042] Further reference is made to Figure 2B, the RAG system 220 is configured to generate accurate, relevant, and contextually appropriate prompts based on the user input 204 (or a functional design specification (FDS) or a hardware design specification (HDS)). The RAG system 220 can include or be in communication with a retrieval / generator component 224 that is configured to retrieve relevant information from a large corpus or database 226 (e.g., based on the user input) and that is configured to generate a response in the form of a finalized prompt 228 based on the retrieved relevant information (e.g., RAG). The RAG system 220 can also include or be in communication with a choreographer component (not shown) that is configured to manage or control the flow of information and / or control between the retrieval and / or generator components. In some examples, the RAG system 220 can include or be in communication with an LLM 222 that is configured to analyze the enhanced prompt 228 for generating code that is output as a final response 230 in the form of, for example, a series of functional blocks that comprise a complete application.

[0043] In embodiments, the machine learning system 219 is configured to generate accurate, relevant, and contextually appropriate code based on the prompt 228. The prompt 228 is used, for example, to translate the machine requirements from industry terminology into simpler but sufficient details for the LLM 222 to understand. The RAG-based LLM has sufficient context (e.g., libraries, code databases, lookup tables, etc.) for converting the user prompt into software terminology.

[0044] During operation, the various components of the machine learning system 219 can perform their respective operations in a “black box.” In this way, a user can interact with the input and output of the system 219 without understanding the inner workings of the system 219. From the user’s perspective, the user provides user input to the system 219 and then sees the response 230 including code on a display.

[0045] Figure 3 Example support libraries for the IEC 61499 framework for generating code are shown. In Figure 3 In examples, the system 101 accesses the support libraries to obtain functionality useful to the system 101, such as sorting algorithms, timer / counter sequences, array / string operations, LIFO / FIFO, motors, PID, valve information, sequencers, etc. These are common elements depending on the protocol or standard used. The code generator-evaluator process accesses various libraries for generating code.

[0046] Automatic code generation promotes consistency between different parts of the system 101, which can lead to a more reliable and maintainable system and / or reduce the likelihood of errors caused by inconsistencies in manual coding, especially in complex systems with many interdependent components. For example, development of automation control applications according to the IEC 61499 architecture can ensure consistency in code structure by enforcing coding conventions, naming conventions, and / or design patterns. The system 101 can also be used to generate documentation alongside the code, providing additional information about the system architecture, signal flow, and / or logical structure, which can assist in troubleshooting, maintenance, and / or knowledge transfer. In some examples, the system 101 can enhance interoperability and / or streamline the development process by facilitating integration with other software tools and systems such as simulation software, HMI / SCADA systems, and / or database interfaces.

[0047] Figure 4 Example operations that may be performed by the system described herein for automated process control application development are shown. In some examples, one or more operations may be performed based on a user-driven activity selection. For example, upon receiving a selection of "asset creation," the system may analyze one or more specifications in the context of asset creation and contextualize the specifications in one or more system prompts to create one or more assets. Additionally or alternatively, upon receiving a selection of "control sequence generation," the system may analyze one or more specifications in the context of control sequence generation and contextualize the specifications in one or more system prompts to generate one or more control sequences by designing the system prompts to ask questions about sequence managers, starts, stops, aborts, or other sequences and interlocks. Additionally or alternatively, upon receiving a selection of "test case generation," the system may analyze one or more specifications in the context of test case generation and contextualize the specifications in one or more system prompts to generate one or more test cases for validating the generated control sequences. Additionally or alternatively, upon receiving a selection to "Complete Control Application Development," the system may analyze one or more specifications in the context of application development and contextualize the specifications in one or more system prompts to develop one or more applications by sequentially executing each operation (e.g., data extraction, asset creation, control sequence generation, HMI generation, test case generation, and / or documentation). In this manner, one or more operations may be executed to provide various aspects of application development, including guided execution, assisted debugging, and / or contextual help.

[0048] Figure 5An example method for generating application code according to aspects of the present disclosure is shown. In some examples, one or more system requirements can be obtained at 502. For example, the system requirements can be received by the RAG system 220 as user input. Example system requirements can include user requirements at 504, hardware requirements and / or network requirements, and / or software requirements at 506. In some examples, the system requirements can be used to determine and / or identify one or more control objectives and functionality of each automation device 102, including input / output requirements and interaction with one or more other devices (e.g., field devices, supervisory computers, etc.). The system requirements can then be used at 504, 506 to set and / or define one or more hardware parameters, network parameters, software parameters, etc. for drafting an application module architecture at 508 to establish a project. In some examples, the RAG system 220 can use or coordinate with one or more libraries (e.g., I / O libraries, project libraries, etc.) to facilitate establishing a project for automation application code generation at 510 and evaluation at 512. The code can then be generated and / or evaluated according to predefined frameworks, templates, standards, and / or best practices. For example, in some embodiments, Figure 6 criteria shown in FIG. 6 (further discussed herein) can be used to evaluate the resulting code, where a total code score can be generated based on an automated or manual evaluation of the code. The code can be used to depict one or more operational sequences, including a main operational mode and an initialization routine. In some examples, at 514, the system 101 can generate documentation alongside the code.

[0049] Figure 6 An example criteria that can be used to evaluate code generated using the system shown in FIG. 6 according to embodiments is shown. Figure 1

[0050] Referring again to Figure 2A , the flowchart 201 and example process also incorporate an example code system 251 for generating code or text in a predefined format (e.g., JavaScript Object Notation (JSON), Extensible Markup Language (XML), etc.), which can be used in conjunction with the system 101 of Figure 1 , the process of Figure 2A , and / or the LLM architecture of Figure 2B The generated code or text can be used by one or more functions in the system 101 to generate a final output. As Figure 2A ​As shown, the code system 251 can include a contextual cue generator system 252 (e.g., requirement checker and / or RAG orchestrator) that generates accurate, relevant, and contextually appropriate cues by analyzing one or more specifications and / or user inputs. In some examples, the user can have the option to override or add one or more cues. The code system 251 can also include a code or formatted text generator system (e.g., code generator-evaluator) (not shown) that generates code based on the cues generated by the contextual cue generator system 252. In this way, the code system 251 can be configured to evaluate one or more process descriptions, extract one or more control narratives, generate one or more control sequences, and / or request user verification and receive input to update code, text, as requested. For example, when the contextual cue generator system 252 identifies that there is no match for a valve function (or “valve function”) or HMI in one or more libraries, the contextual cue generator system 252 can generate one or more cues for the application code generator system 254 to generate a new valve function or HMI symbol for the valve as code. In some examples, the application code generator system 254 can be configured to generate code according to an event-based architecture, as referenced in the IEC 61499 framework.

[0051] Figure 7A An example control sequence generation using the systems and processes described herein is shown. In response to a system prompt providing a higher-level machine requirement (e.g., “control sequence generation”), the contextual cue generator system 252 can employ an elastic search system to query and retrieve relevant inputs (e.g., control sequence related documents, user inputs) and generate accurate, relevant, and contextually appropriate cues for generating a suitable control application code in structured text.

[0052] Figure 7B An example HMI creation using the systems and processes described herein is shown. In response to a system prompt providing a higher-level machine requirement (e.g., “HMI screen creation”), the contextual cue generator system 252 can employ an elastic search system to query and retrieve relevant inputs (e.g., HMI related documents, user inputs) and generate accurate, relevant, and contextually appropriate cues for generating a suitable HMI screen.

[0053] Figure 7CExample test case generation using the systems and processes described herein is shown. In response to a system prompt providing a higher level machine requirement (e.g., "test case generation"), the contextual cue generator system 252 can analyze one or more specifications in the data model and / or user interactions to generate accurate, relevant, and contextually appropriate cues for generating one or more test cases. In some examples, the system can be configured to assist in a wide range of testing. For example, the system can be configured to assist in testing adherence to design specifications and user expectations by generating both exception and non-exception test cases. For another example, the system can be configured to assist in fault injection testing by generating test cases that simulate various fault scenarios, etc. The system can also be used to assist in generating unit and complex scenarios, performance testing, etc. The system can be configured to integrate with an automation framework to perform guided execution of the generated test cases, further streamlining the testing process and reducing manual effort.

[0054] Figure 7D Example document generation using the systems and processes described herein is shown. In response to a system prompt providing a higher level machine requirement (e.g., "documentation"), the contextual cue generator system 252 can analyze one or more specifications in the data model and / or user interactions to generate accurate, relevant, and contextually appropriate cues for generating suitable documentation. In some examples, the user interactions can include user input describing the type of documentation (e.g., maintenance manual, operations manual, code documentation, updated functional specification, etc.) and / or including references to templates. The system can be configured to generate technical documentation with high-level contextual understanding capabilities. For example, the contextual cue generator system 252 can analyze source code and automatically generate technical documentation including comments that explain functionality, interlocks, alarms, etc. The system can also be configured to reorganize, review existing documentation, and make suggestions for improvements that are not limited to the documentation but also include adapting to technical changes in the application architecture. In some examples, the system can employ an enhanced search capability system to quickly and accurately index and search large amounts of documentation, helping application engineers to more efficiently locate relevant information.

[0055] Figure 7E Example systems for automatic data modeling and updating using the systems and processes described herein are shown. In response to a system prompt providing a higher level machine requirement (e.g., "perform artifact analysis"), the contextual cue generator system 252 can employ an elastic search system to query and retrieve relevant inputs (e.g., control sequence related documents, user input) and generate accurate, relevant, and contextually appropriate cues for extracting data and using the data to perform automatic data modeling and updating. The systems described herein can be configured to use data from a wide range of data sources to construct or update one or more data models, including one or more pre-defined inputs and / or user inputs.

[0056] Figure 8 As shown in reference Figure 4 The representative data models mentioned for data extraction. Figure 8 As shown, exemplary predefined inputs may include International Society of Automation (ISA) standards, IEC 61499 architectural elements, proprietary libraries, other standards or specifications, and / or system prompts, and exemplary user inputs may include piping (or process) and instrumentation diagrams (P&IDs), process descriptions, input / output (IO) lists, instrument indexes, and other user specifications of the automation process (e.g., hardware specifications, control principles, etc.). The predefined inputs and / or user inputs may be in various forms, such as portable document format (PDF) documents, extensible markup language (XML) files, Word documents (e.g., *.doc), Excel worksheets (e.g., *.xls), image files (e.g., *.gif, *.jpeg, *.png), and / or other software tool-related files.

[0057] Application creation involves, for example, multiple interrelated operations that may vary by tool. In some examples, the operations may include data modeling and updating, asset creation, control sequence generation / control logic generation, HMI creation, test case generation, and / or documentation generation.

[0058] Reference again Figure 2A , an example process illustrates building a data model (e.g., an apple juice making data model) according to another embodiment. To configure the system 101 to build a batch process control application, predefined inputs may be used to construct the data model. In some examples, the predefined inputs may include a proprietary library that includes functionality and help documentation related to assets such as valves, pumps, sensors, process control units, and the like. Example help documentation may include industry technical standard documentation (e.g., PackML, ISA-5.1, ISA-88, ISA-95, ISA-106, IEC 61499), design guides, sequence diagrams, communication protocols, and the like. For example, ISA-88 may be used to define assets (hardware and virtual) and processes (e.g., a recipe for running these assets to make apple juice) in a hierarchy, and attribute certain properties and standards to the assets.

[0059] At step 202 , a data extraction prompt is triggered, and at steps 206 and 208 , the contextual prompt generator system 252 communicates with a database (eg, the engineering database 106 of the system 101 ) to extract relevant data (eg, the ISA-88 standard).

[0060] At step 204, the user can provide information for building a particular control application. For example, the user input can include a system diagram (e.g., P&ID), flow sheet, process description, etc. for building or updating the apple juice making data model. Additionally, the user can provide a high-level hint: "Develop a batch control application for apple juice mixing using ISA88 standards and IEC 61499 architecture."

[0061] At step 210, the contextual hint generator system 252 determines whether particular conditions are satisfied (e.g., whether there is sufficient context to understand the input and / or determine one or more machine requirements). If all of the particular conditions are satisfied (e.g., sufficient context for generating an acceptable hint), the process can jump to step 214. However, if one or more conditions are not satisfied, the contextual hint generator system 252 can prompt the user for additional user input at step 212 (e.g., "Please provide an ISA88 physical model for apple juice mixing"). Then, step 204 is repeated, the user can provide additional user input (e.g., an ISA88 physical model for apple juice mixing), which triggers another data extraction hint at steps 206 and 208, and the contextual hint generator system 252 can repeat step 210 to determine whether the particular conditions are satisfied.

[0062] When it is determined that all of the particular conditions are satisfied (e.g., the "good context" decision box is satisfied), the contextual hint generator system 252 can communicate with the application code generator system 254 to generate a data model and output the model at step 216, which can be integrated with the system 101. At step 218, the contextual hint generator system 252 can communicate with the database to save the data model at the database.

[0063] According to another embodiment, Figure 2A The example process of FIG. 2B can also be used to create an asset (e.g., a custom valve FV01). In some examples, asset creation involves creating a virtual functional copy of an asset provided in the P&ID. The asset can be created autonomously by utilizing the data model, predefined inputs, and / or system hints. Example predefined inputs for creating an asset can include materials related to the engineering tool and sample representations of input-output data for few-shot learning (e.g., a representation of a custom valve generated in structured text using the IEC 61499 specification).

[0064] At step 204, a create asset function hint is triggered, and at steps 206 and 208, the contextual hint generator system 252 communicates with the database to extract relevant data (e.g., asset tags). In some examples, the create asset function can run autonomously until a predetermined set or sets of assets are created.

[0065] At step 210, the contextual cue generator system 252 can identify the list of asset tags and communicate with the application code generator system 254 to output, at step 216, application code associated with the valve function FV01, which can be integrated with the system 101. In some examples, the output application code can be PLC code. Additionally or alternatively, the output application code can be any other file type compatible with the system 101, including *.fbt files, *.xml files, *.html files, *.pdf files, *.xlsx files, *.json files, and the like. At step 218, the contextual cue generator system 252 can communicate with the database to save the application code at the database.

[0066] In one embodiment, Figure 2A The example process of FIG. 2 can also be used to illustrate a process for generating a control sequence. In some examples, control sequence generation involves studying a process description and creating sequential control functions based on the process description. The control sequence can be created autonomously by utilizing a data model, predefined inputs, and / or system cues. Example predefined inputs for creating a control sequence can include materials related to the engineering tool and sample representations of input-output data for few-shot learning (e.g., representations of batch process control sequential control code generated in structured text utilizing the IEC 61499 specification).

[0067] At step 204, a create control sequence cue is triggered, and at steps 206 and 208, the contextual cue generator system 252 communicates with the database to extract relevant data (e.g., data model, process description). In some examples, the create control sequence function can run autonomously until a predetermined set of one or more steps in the sequence are created.

[0068] At step 210, the contextual cue generator system 252 can validate the process with tags and phrases and communicate with the application code generator system 254 to output, at step 216, application code associated with the structured text code, which can be integrated with the system 101. At step 218, the contextual cue generator system 252 can communicate with the database to save the application code at the database.

[0069] According to another embodiment, Figure 2AThe example process can also be used to illustrate a process for generating one or more test cases. In some examples, test case generation involves identifying multiple possible scenarios to test to verify the batch process control being developed. Test cases can be autonomously created by utilizing a data model, predefined inputs, and / or system prompts. Exemplary predefined inputs for creating test cases may include materials related to engineering tools and sample representations of input-output data for few-shot learning (e.g., a representation of a custom valve and generated code generated using structured text according to the IEC 61499 specification).

[0070] At step 204, a create test case prompt is triggered, and the context prompt generator system 252 communicates with the database to extract relevant data (e.g., data model, process description, batch process control code) at steps 206 and 208. In some examples, the create test case function can run autonomously until a predetermined set or more test cases are created.

[0071] At step 210, the contextual hint generator system 252 may determine relevant test cases and communicate with the application code generator system 254 to output structured text code associated with the relevant test cases at step 216, which may be integrated with the system 101. At step 218, the contextual hint generator system 252 may communicate with a database to save the structured text code at the database.

[0072] In yet another embodiment, Figure 2A The example process can also be used to illustrate a process for generating documentation (e.g., code documentation, operator manuals, maintenance manuals, control narratives, etc.). In some examples, the documentation can support operators and process engineers in operating and debugging any problems that may occur. By default, the system generates documents in a predefined structure. Documents can be created autonomously by utilizing data models, predefined inputs, and / or system prompts. Alternatively, a user can force the development of a document by loading a reference that triggers the create document prompt at step 204. Example predefined inputs for creating documents can include materials related to engineering tools and sample representations of input-output data for few-shot learning (e.g., representations of code documents, operator manuals, maintenance manuals, control narratives, etc.).

[0073] At step 204, a create document prompt is triggered, and the contextual prompt generator system 252 communicates with a database to extract relevant data (e.g., data model, process description, batch process control code) at steps 206 and 208. In some examples, the create asset function can run autonomously until a predetermined set or more documents are created.

[0074] At step 210, the contextual prompt generator system 252 can identify the generated document and communicate with the application code generator system 254 to output, at step 216, application code associated with the document that can be integrated with the system 101. In some examples, the output application code can be a *.pdf file. At 218, the contextual prompt generator system 252 can communicate with a database to save the application code at the database.

[0075] For this apple juice making example, various workflows are presented herein, including different types of user input enhancements to contextualize data and generate outputs, and how the same data repository can be leveraged to generate a wide range of application code.

[0076] Figure 9A is an example application generated by the system 101 according to one or more embodiments, such as those shown in Figures 7A-7E Figure 1 Figure 9B represents the XML output from the LLM engine 108 corresponding to the application of Figure 9A Figure 9C is another example application generated by the system 101 according to one or more embodiments, such as those shown in Figures 7A-7E Figure 1 Figure 9D represents the XML output from the LLM engine 108 corresponding to the application of Figure 9C Figures 9A to 9D It is understood that

[0077] Figure 9A and 9B Input for an example use case of a motor control system: In an industrial process, precise motor control based on tank level is critical to maintain consistent product quality. The developed control system manages motor operation with exceptional reliability. The analog input block AI 3051 conditions the input signal, carefully suppressing potential noise from the level measurement system. The tank level is maintained at predefined set points, the system is programmed to stop the motor when a low level (30%) is detected, and restart the motor when a high level (70%) is reached, resulting in intelligent logic triggers for motor control. The motor block M 3051 serves as the final execution point, precisely controlling the start and stop operations of the motor. This integrated system ensures that the motor runs only under specific level conditions, effectively preventing issues such as dry running or overfilling, thereby protecting critical equipment and maintaining process consistency. In operation, the system 101 responds to these inputs, for example, in certain embodiments, according to the process and Figure 2A Figure 2B ​​​​​​​LLM architecture of FIG. 1 to generate application code exemplified by function blocks connected together to form an application of FIG. 2. Figure 9B

[0078] Figure 9C and 9D An example use case input: In a complex industrial process such as chemical or water treatment, precise multi-loop tank level control becomes necessary. The cascaded PID control system shown with blocks LI 1101, PID 1102, and FV 1101 represents an advanced strategy for managing tank liquid levels with superior precision. The analog input block LI 1101 conditions the input signal, suppressing potential noise and false alarms from the level measurement system. The first PID controller (PID 1101) operates as the master (outer) loop, monitoring the overall tank level and generating a flow rate setpoint based on the deviation from the desired level. The second PID controller (PID 1102) receives this setpoint and focuses on the inner loop, precisely controlling the feed control valve position to achieve the required flow rate. The valve control block FV 1101 translates these calculated control signals into actual valve movements, ensuring fine adjustments to maintain consistent tank levels. This cascaded control method allows for fast response to process disturbances, with the inner loop compensating for valve nonlinearities and the outer loop maintaining overall system stability, resulting in a robust and intelligent tank level management solution. In operation, the system 101 responds to these inputs, for example, in some embodiments, according to the process of FIG. 1 and the LLM architecture of FIG. 1 to generate application code exemplified by function blocks connected together to form an application of FIG. 2. Figure 2A Figure 2B An example use case input: In a complex industrial process such as chemical or water treatment, precise multi-loop tank level control becomes necessary. The cascaded PID control system shown with blocks LI 1101, PID 1102, and FV 1101 represents an advanced strategy for managing tank liquid levels with superior precision. The analog input block LI 1101 conditions the input signal, suppressing potential noise and false alarms from the level measurement system. The first PID controller (PID 1101) operates as the master (outer) loop, monitoring the overall tank level and generating a flow rate setpoint based on the deviation from the desired level. The second PID controller (PID 1102) receives this setpoint and focuses on the inner loop, precisely controlling the feed control valve position to achieve the required flow rate. The valve control block FV 1101 translates these calculated control signals into actual valve movements, ensuring fine adjustments to maintain consistent tank levels. This cascaded control method allows for fast response to process disturbances, with the inner loop compensating for valve nonlinearities and the outer loop maintaining overall system stability, resulting in a robust and intelligent tank level management solution. In operation, the system 101 responds to these inputs, for example, in some embodiments, according to the process of FIG. 1 and the LLM architecture of FIG. 1 to generate application code exemplified by function blocks connected together to form an application of FIG. 2. Figure 9D

[0079] An example computing system

[0080] Figure 10 An example computing system 600 (e.g., automation device 102, engineering processor 104, engineering database 106, LLM engine 108, machine learning system 219) configured to perform one or more computing operations described herein is shown. In some examples, the computing system 600 includes a processor 610, a system memory 620, and a bus 630 coupling the various system components including the system memory 620 to the processor 610.

[0081] The processor 610 is configured to perform general computing functions and process data and instructions to perform one or more operations and / or provide other functionality described herein. For example, the processor 610 can access the system memory 620 to read data and instructions from and / or write data and instructions to the system memory 620 for execution of one or more computer-executable instructions. In this way, the processor 610 can be programmed to perform any of the aspects of the software components described herein, including to implement the RAG system 220 Figure 2B ​​​The processor 610 implements a software stack of the machine learning system 219 (shown in FIG. 6) in accordance with one or more aspects of the present disclosure. According to one or more aspects of the present disclosure, the processor 610 implements a code generation processor.

[0082] In some examples, the processor 610 can be or include any number of processing units, including central processing units, graphics processing units, field-programmable gate arrays (FPGAs), digital signal processors (DSPs), or other hardware logic components, including but not limited to application-specific integrated circuits (ASICs), application-specific standard products (ASSPs), system-on-a-chip (SOCs), complex programmable logic devices (CPLDs), and the like.

[0083] The system memory 620 includes any combination of computer readable media accessible by the processor 610. In some examples, the system memory 620 includes a read-only memory (ROM) 632 that stores instructions for performing basic functions and a random access memory (RAM) 634 that temporarily stores data and instructions for active use.

[0084] Computer readable media includes communication media and computer storage media. Communication media typically embodies computer readable instructions, data structures, program modules or other data in a modulated data signal such as a carrier wave or other transport mechanism. The term “modulated data signal” means a signal that has one or more of its characteristics set or changed in such a manner as to encode information in the signal. By way of example, and not limitation, communication media includes wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, radio frequency, and infrared media.

[0085] In contrast, computer storage media includes tangible forms of media that can store information such as computer readable instructions, data structures, program modules or other data. By way of example, and not limitation, computer storage media includes ROM 632, RAM 634, a hard disk drive (HDD), a solid state drive (SSD), external hard drives, flash memory drives, optical storage media (e.g., compact disc (CD), digital versatile disc (DVD), and magnetic storage media (e.g., tape drives). For the purposes of this disclosure, computer storage media is non-excludable from computer readable media, and excludes waves, signals, and other transitory or intangible forms of media.

[0086] It should be appreciated that the software components described herein may, when loaded into the processor 610 and executed, transform the processor 610 and the overall computing system 600 from a general-purpose computing system into a special- purpose computing system customized to facilitate the functionality presented herein. Specifically, the computer-executable instructions constituting the software components described herein may, when executed by the processor 610, transform the processor 610 into a special purpose processor by defining circuitry in the processor 610 that is optimized to perform the tasks described herein.

[0087] Encoding the software components presented herein also can transform the physical structure of the computer-readable media presented herein. The specific transformation of a computer-readable medium depends, at least in part, on the technology used to implement the computer-readable medium. Examples of transformation scenarios for the various computer-readable media described herein include, but are not limited to, transformation of an electrical signal carrying software from a transitory medium to a non-transitory medium, and transformation of data from an inoperative state to an operative state or vice versa.

[0088] As another example, the computer-readable media disclosed herein can be implemented using magnetic or optical technology. In such implementations, the software presented herein can transform the physical state of magnetic or optical media, when the software is encoded or stored in the media. These transformations can include altering a magnetic or optical property of a particular location within given magnetic or optical media. These transformations also can include altering the physical structure of the computer-readable media. For example, implementing the software using magnetic technology can result in transformations to the magnetization of particular locations in the magnetic storage media as necessary to store or maintain the software presented herein. Similarly, implementing the software using optical technology can result in transformations to the physical structure of the computer-readable media, such as alterations to the length or shape of the physical structures to encode or store the software presented herein. Other transformations of physical media are possible without departing from the scope and spirit of the present description, with the foregoing examples provided only to facilitate this discussion.

[0089] In some examples, the computing system 600 includes a mass storage device 640 coupled to the processor 610 for storing data and instructions, such as an operating system 642, one or more programs 644 (e.g., the RAG system 220), and / or data 646. Those skilled in the relevant art will appreciate that at least some of the data and / or instructions stored in the mass storage device 640 can also be stored in the system memory 620 and / or other storage devices in the computing system 600. The data and / or instructions stored in the mass storage device 640 can be executed by the processor 610 to cause the computing system 600 to perform the functions described herein.

[0090] As Figure 10As shown, the computing system 600 can be connected to a network 650 (e.g., network 130) via a network interface unit 652 connected to the bus 630. In this way, the computing system 600 can operate in a networked environment in which the computing system 600 can use one or more remote devices (not shown) to host or store at least some data and / or execute at least some instructions. For example, the computing system 600 may include one or more client-side applications that perform one or more operations at the computing system 600 while one or more operations are performed remotely (e.g., in the "cloud"). Computer communications between computing systems can be network transmissions, file transfers, applet transmissions, emails, Hypertext Transfer Protocol (HTTP) transmissions, and the like.

[0091] In some examples, the computing system 600 may include one or more input / output (I / O) controllers 660 that facilitate communication and data transfer between the processor 610 and one or more I / O devices (not shown) configured to provide input and / or output capabilities. For example, a user may input commands and information into the computing system 600 using one or more input devices, such as a keyboard, a pointing device (e.g., a mouse, a trackball, a touchpad, a stylus), a microphone, a camera, a scanner, an accelerometer, and the like. Additionally or alternatively, the computing system 600 may use one or more output devices, such as a monitor, a projector, a printer, a speaker, an actuator, and the like, to present various forms of information, such as text, images, audio, video, alarms, and the like. In some examples, the output device may be integrated with the input device (e.g., in a touch screen panel or in a controller that includes a vibration component).

[0092] Although some examples are shown and described herein with reference to the computing system 600 as including or included in the automation device 102, the engineering processor 104, the engineering database 106, the LLM engine 108, and / or the RAG system 220, aspects of the present disclosure may operate with any computing system capable of executing computer-executable instructions to implement the operations and functions associated with the computing system 600. It is also contemplated that the computing system 600 may not include Figure 10 All components shown in the Figure 10 Other components not explicitly shown in the figure or may be used in conjunction with Figure 10 The computing system 600 should not be interpreted as having a completely different architecture than that shown in FIG. Figure 10 Figure 10 The computing system 600 is only one example of a computing and networking environment for performing one or more computing operations and is not intended to suggest any limitation as to the scope of use or functionality of the present disclosure.

[0093] Example methods and systems for generating automation control applications are described herein. Examples described herein take user input and generate one or more instructions or hints for constructing an entire application based, at least in part, on the user input. Additionally, examples described herein enable control applications to be built in an efficient and user-friendly manner. When working on batch or continuous processes, engineers use a set of documents, such as P&IDs, IO lists, user requirement specifications, instrument index, standard definitions of ISA88, ISA106 for batch and continuous processes, etc., to build these control applications. However, at least some control applications are not amenable to advanced architectures, such as IEC 61499, which discusses future event-driven paradigms that help better IT / OT convergence and secure automation, primarily due to tight deadlines, rigor involved in traversing hundreds of pages to understand requirements, steep learning curve involved in understanding IEC 61499 practices, and lack of expertise and specialization for faster control application development.

[0094] IT (information technology) is the backbone of technology for any organization that manages electronic data. OT (operational technology), on the other hand, controls physical processes and equipment in industrial operations. IT / OT convergence integrates data management systems with industrial operations systems, allowing real-time data exchange and improved decision making.

[0095] Examples described herein allow control applications to be amenable to advanced architectures like IEC 61499. Automated text / code generation can result in cost savings by reducing development time, reducing errors, and / or improving system reliability. Furthermore, it can facilitate engineers to reduce learning curve. In view of the above, several advantages of implementing aspects of the present disclosure will be realized and other beneficial results will be attained.

[0096] Examples illustrated and described herein, as well as examples not specifically described herein but within the scope of aspects of the present disclosure, constitute example means for managing cryptographic identities. For example, elements shown in the figures, when programmed, encoded, or configured to perform the shown operations, constitute at least one example means for receiving input data defining a set of specifications, analyzing the input data to retrieve relevant information from a large corpus, generating one or more hints based on the relevant information, and using the one or more hints to generate application code according to an advanced architecture, such as IEC 61499.

[0097] Embodiments of the present disclosure can include special purpose computers that include various computer hardware, as described in greater detail herein.

[0098] For explanatory purposes, procedures and other executable program components can be shown to be discrete blocks. It should be recognized that such procedures and components can exist in various combinations of hardware and software in different systems and each system can implement a combination of the components and procedures in different ways.

[0099] Although described in connection with an example computing system environment, embodiments of aspects of the disclosure can be operational with other general purpose or special purpose computing system environments. The computing system environment is not intended to suggest any limitation as to the scope of use or functionality of any aspect of the disclosure. Moreover, the computing system environment should not be interpreted as having any dependency or requirement relating to any one or combination of components illustrated in the example operating environment. Examples of computing systems, environments, and / or configurations that can be suitable for use with aspects of the disclosure include, but are not limited to, personal computers, server computers, hand-held or laptop devices, multiprocessor systems, microprocessor-based systems, set top boxes, programmable consumer electronics, mobile telephones, network PCs, minicomputers, mainframe computers, distributed computing environments that include any of the above systems or devices, and the like.

[0100] Embodiments of aspects of the disclosure can be described in the general context of data and / or processor-executable instructions, such as program modules, being stored on memory (i.e., one or more tangible, non-transitory storage mediums) and being executed by one or more processors or other devices. Generally, program modules include, but are not limited to, routines, programs, objects, components, and data structures that perform particular tasks or implement particular abstract data types. Aspects of the disclosure can also be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules can be located in both local and remote memory storage devices.

[0101] In operation, processors, computers, and / or servers can execute processor-executable instructions, such as those illustrated herein, to implement aspects of the disclosure.

[0102] Embodiments can be implemented in processor-executable instructions. The processor-executable instructions can be organized into one or more processor-executable components or modules on a tangible processor-readable storage medium. Also, any number and organization of such components or modules can be employed and embodiments can be implemented as a component- or module- based system as well as an object- or object- based system. For example, aspects of the disclosure are not limited to the particular processor-executable instructions or particular components or modules illustrated in the figures and described herein. Other embodiments can include different processor-executable instructions or components having more or less functionality than that described herein.

[0103] The order of execution or performance of the operations in accordance with the aspects of the disclosure illustrated and described above are not essential, unless otherwise specified. That is, unless otherwise specified, the operations can be performed in any order, and embodiments can include more or fewer operations than those disclosed herein. For example, it is contemplated that executing or performing a particular operation before, contemporaneously with, or after another operation is within the scope of aspects of the disclosure.

[0104] When introducing elements of the disclosure or the embodiments thereof, the articles "a," "an," "the" and "said" are intended to mean that there are one or more of the elements. The terms "comprising," "including" and "having" are intended to be inclusive and mean that there can be additional elements other than the listed elements.

[0105] Not all illustrated components shown or described can be required. Additionally, some implementations and embodiments can include additional components. Variations in the arrangement and types of components can be made without departing from the spirit or ambit of the claims as set forth herein. Additionally, different or fewer components can be provided, and components can be combined. Alternatively, or additionally, components can be implemented by several components.

[0106] The above description illustrates embodiments by way of example and not by way of limitation. This description enables others skilled in the art to make and use aspects of the disclosure, and describes several embodiments, modifications, variations, alternatives, and uses of aspects of the disclosure, including presently preferred ones. Additionally, it is to be understood that aspects of the disclosure apply to other than the specifically enumerated embodiments described herein. It is to be understood that the phraseology and terminology employed herein are for the purpose of description and not of limitation. Any and all modifications, variations, or changes that fall within the purview of the disclosure are intended to be included herein.

[0107] However, it is apparent that modifications and changes can be made without departing from the scope of the disclosure as defined in the following claims. Since many modifications, variations, and changes in detail can be made to the described and illustrated construction and method, without departing from the scope of the disclosure, it is intended that all such modifications, variations, and changes be considered as within the scope of the disclosure as defined in the following claims.

[0108] In light of the above, it will be seen that the aspects of the disclosure achieve several advantages and other desirable results.

[0109] The abstract and summary are provided to assist the reader in quickly ascertaining the nature of the technical disclosure. They are submitted with the understanding that they will not be used to interpret or limit the scope or meaning of the claims. The summary is provided in order to present some concepts of the disclosure in a simplified form as a prelude to the more detailed description that is to follow. The summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used in determining the scope of the claimed subject matter.

Claims

1. A computing system for automatically generating code for use in an industrial control system, the computing system comprising: a database storing data related to an industrial control system; a code generation processor; a memory storing processor-executable instructions that, when executed, configure the code generation processor to: receive a generalized system prompt; in response to the system prompt, automatically retrieve relevant information from the database, the retrieved relevant information including a predefined code format; automatically derive a contextual prompt based on the retrieved relevant information; and in response to the contextual prompt, generate code according to the predefined code format. the memory stores processor-executable instructions that, when executed, further configure the code generation processor to receive one or more user inputs, and wherein the processor-executable instructions to automatically derive the contextual prompt include processor-executable instructions that, when executed, configure the code generation processor to automatically derive the contextual prompt based on the retrieved relevant information and the received user inputs.

2. The computing system of claim 1, wherein, 3. The computing system of claim 2, wherein the user inputs include at least one of the following types of inputs: P&IDs, process descriptions, IO lists, instrument indexes, hardware specifications, control principles, or user specifications, and wherein the user inputs include at least one of the following input forms: portable document format (PDF) documents, extensible markup language (XML) files, text documents, spreadsheets, image extensions, or other software tool-related file extensions. a plurality of predefined inputs, the predefined inputs including one or more of: previously processed user inputs; International Society of Automation (ISA) standards; International Electrotechnical Commission (IEC) 61499 architecture elements, code libraries, or predefined system prompts.

4. The computing system of any one of claims 1 to 3, wherein the data related to an industrial control system stored in the database comprises: the processor-executable instructions to generate the code include processor-executable instructions that, when executed, further configure the code generation processor to:

5. The computing system of any one of claims 1 to 4, wherein, automatically create an asset based on the retrieved relevant information; and / or automatically generate a control sequence based on the retrieved relevant information. the processor-executable instructions to automatically derive the contextual prompt include processor-executable instructions that, when executed, further configure the code generation processor to query the database for data related to one or more of a sequence manager, a start, a stop, an abort, another sequence, or an interlock of the control sequence.

6. The computing system of claim 5, wherein, the processor-executable instructions to generate the code include processor-executable instructions that, when executed, further configure the code generation processor to automatically generate at least one of:

7. The computing system of any one of claims 1 to 6, wherein, one or more test cases based on the retrieved relevant information, the test cases configured to validate the control sequence; a human-machine interface based on the retrieved relevant information; documentation based on the retrieved relevant information; or a control application based on the retrieved relevant information. ​ 8. The computing system of any one of claims 1 to 7, wherein, The processor-executable instructions for automatically deriving contextual cues include processor-executable instructions that, when executed, further configure the code generation processor to query the database to analyze one or more of specifications in the data model and previous user interactions.

9. The computing system of any one of claims 1 to 8, wherein the database storing data related to the industrial control system includes a data model comprising one or more of asset data, hardware descriptions, IO lists, or physical model hierarchies related to the industrial control system.

10. A method for automatically generating code for use in an industrial control system, the method comprising: receiving a summarized system cue; in response to the system cue, automatically retrieving relevant information from a database, wherein the database stores data related to the industrial control system, and wherein the retrieved relevant information includes a predefined code format; automatically deriving contextual cues based on the retrieved relevant information; and generating code according to the predefined code format in response to the contextual cues.

11. The method of claim 10, further comprising receiving one or more user inputs, and wherein automatically deriving contextual cues includes automatically deriving contextual cues based on the retrieved relevant information and the received user inputs.

12. The method of claim 10 or claim 11, further comprising storing data related to the industrial control system in the database, wherein the data includes a plurality of predefined inputs, and wherein the predefined inputs include one or more of: previously processed user inputs; International Society of Automation (ISA) standards; International Electrotechnical Commission (IEC) 61499 architecture elements, code libraries, or predefined system cues.

13. The method of any one of claims 10 to 12, wherein, generating code includes at least one of: automatically creating an asset based on the retrieved relevant information; or automatically generating a control sequence based on the retrieved relevant information.

14. The method of claim 13, automatically deriving contextual cues includes at least one of: querying the database for at least one of data related to one or more of a sequence manager, a start, a stop, an abort, another sequence, or an interlock of the control sequence; or querying the database to analyze one or more of specifications in the data model and previous user interactions.

15. The method of any one of claims 10 to 14, wherein, generating code includes one or more of: automatically generating one or more test cases based on the retrieved relevant information, wherein the test cases are configured to validate the control sequence; automatically generating a human-machine interface based on the retrieved relevant information; automatically generating documentation based on the retrieved relevant information; or automatically generating a control application based on the retrieved relevant information.

Images