Software-defined integration of industrial automation and edge computing systems

Abstract

A method for engineering an automation system includes running an automation engineering tool to create an automation project based on a first user input. The automation project includes an automation program defining logic for an automation controller, and an identification of tags defining data exchange between the automation controller and an edge device to carry out an automation task. The method includes automatically generating, via an edge app configuration generator, a first edge app configuration for a protocol connector edge app for communication between the edge device and the automation controller, based on the identified tags. The method includes deploying artifacts of the automation project, including the automation program and the first edge app configuration, respectively to a target automation controller and a target edge device specified in the automation project, to implement a software-defined integration between the automation controller and the edge device.

Description

SOFTWARE-DEFINED INTEGRATION OF INDUSTRIAL AUTOMATION AND EDGE COMPUTING SYSTEMSTECHNICAL FIELD

[0001] The present disclosure is directed, in general, to industrial automation systems and, in particular, but not limited to, integration of edge computing systems and devices with industrial automation systems.BACKGROUND

[0002] IT  / OT convergence refers to the integration of Information Technology (IT) systems, which manage data-centric computing, with Operational Technology (OT) systems, which manage physical processes and machinery. This convergence aims to create a unified infrastructure that enhances operational efficiency, improves decision-making, and drives innovation in various industries

[0003] IT  / OT convergence for industrial systems often entails significant integration effort to accurately map automation-world aspects, like PLC tags or sensor datapoints, into IT-world software components, such as an API or data model in an edge-computing application. The trend of IT-like engineering, e.g., the SIMATIC  automation software product by Siemens, offers a platform and approach for not only bring IT-world technologies and approaches for programming OT systems (like programmable logic controllers (PLCs) , human-machine interfaces (HMIs) , etc. ) , but also to apply IT-world practices (such as version control, DevOps, etc. ) to the integration engineering for hybrid OT &IT systems.

[0004] Current approaches to IT  / OT convergence require multiple engineering tools and disciplines and requires substantial (manual) integration effort to commission the system. Improved systems are desirable.SUMMARY

[0005] 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 an integrated engineering system and methodology for holistically performing and managing the integration of automation and edge computing assets.

[0006] A first aspect of this disclosure provides a computer-implemented method for engineering an automation system. The method comprises running an automation engineering tool to create an automation project based on a first user input. The automation project includes an automation program defining logic for an automation controller, and an identification of tags defining data exchange between the automation controller and an edge device to carry out an automation task. The method further comprises automatically generating, via an edge app configuration generator integrated with or accessible by the automation engineering tool, a first edge app configuration for a protocol connector edge app for communication between the edge device and the automation controller, based on the identified tags. The method further comprises deploying artifacts of the automation project, including the automation program and the first edge app configuration, respectively to a target automation controller and a target edge device specified in the automation project. Thereby, the target edge device is configured to communicate with the target automation controller by executing an instance of the protocol connector edge app on the target edge device based on the deployed first edge app configuration and the automation controller is configured to execute the logic defined by the deployed automation program based on the communication with the target edge device.

[0007] Further aspects of this disclosure provide an automation engineering computer 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 schematic block diagram of a system architecture in accordance with one or more embodiments.

[0011] FIG. 2 is a flowchart illustrating a process for software-defined integration of edge and automation devices for an AI-based automation task, according to one or more embodiments.

[0012] FIG. 3 is a schematic block diagram illustrating automatic identification of tags from a PLC program to generate protocol connector edge app configuration according to one or more embodiments.

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

[0014] FIGS. 1 through 4, 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 understand 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.

[0015] The exponential growth of Internet of Things (IoT) devices and data generated has made edge computing particularly suitable for automation systems as it can meet the requirements of many real time applications by providing lower latency, higher reliability, and lower costs associated with data storage and transmission compared to remote servers or cloud infrastructure. Edge computing brings computation and data storage closer to the device where data is generated, i.e., at the edge of the network. An edge device refers to a computing device having processing capability to realize edge computing. Edge computing is a topology or location sensitive form of distributed computing. As such, the term “edge” refers to an architecture rather than a specific technology.

[0016] In automation systems, data is generated from devices at a field level, which is where edge devices may be located. An edge device can be integrated in an automation system to carry out an automation task by executing modular software components or apps which can provide integrated  connectivity with field devices and controllers (in addition to the edge management and cloud infrastructure) that the edge device needs to interact with in connection with the automation task. Integration of edge computing and automation devices may be realized via IT  / OT convergence.

[0017] As described above, current approaches to IT  / OT convergence require multiple engineering tools and disciplines and require substantial manual integration effort to commission the automation system. As a specific example, consider the integration of an edge-based artificial intelligence (AI) vision system into an automated production line. Today, this process spans multiple tools and disciplines and must be manually integrated.

[0018] In such a typical case, first the user may wire a trigger signal from the digital input  / output (I / O) module of their production line's PLC into the camera's hardware trigger input. Then, the user may create a PLC program using an automation engineering tool and identify the tags that the PLC is expected to receive from the edge device. Next, using a connectivity configurator tool, the user may configure a PLC protocol connector app on the edge device (for supporting communication with the PLC based on a specific protocol) with those tags and note down the associated messaging topics, such as might be used by an MQTT messaging protocol.

[0019] Next, using a vision connector app on the edge device, the user may configure the camera and note down the messaging topics assigned to that camera, such as might be used by a ZeroMQ protocol. Then, the user may upload an AI pipeline into an AI Inference Server app on the edge device. Using the AI Inference Server app, the user may specify the appropriate messaging topics (e.g., the ZeroMQ topics) noted earlier to receive images from the vision connector app. Similarly, the user may specify the messaging topics (e.g., the MQTT topics) in the AI Inference Server app to return results to the PLC protocol connector app. Next, the user may run the AI pipeline. The user can then trigger the camera, e.g., using "force tables" on the messaging tag which is wired to the camera's hardware trigger input.

[0020] To confirm that the entire system is functioning properly, the user may then need to check the vision connector app to see images being produced by the camera, the AI Inference Server app to see pipelines being triggered, a messaging client app that can subscribe to the MQTT and ZeroMQ topics (e.g., based on node-RED) to see results being published, and watch-tables in the automation engineering tool to see tags being updated.

[0021] As is evident, current approaches can often be inefficient, time-consuming, error-prone, and require significant manual efforts to integrate and coordinate multiple disparate systems.

[0022] The present disclosure provides an automation engineering system and methodology that allows the integration of automation and edge computing assets to be carried out and managed more comprehensively and holistically. The proposed edge-automation integration methodology makes it possible to perform the entire integration engineering workflow from a single software tool. In particular, the methodology can be used to implement software-defined integration of automation controllers (e.g., PLCs) and edge devices using an automation engineering tool that can support IT-like features. The methodology can be further extended to implement integration of other field devices (e.g., cameras or other types of sensors) and data processing applications on the edge devices, to carry out AI-based automation or data processing tasks.

[0023] A key distinguishing feature of the proposed methodology is the provision of a single IT-like engineering interface for automation and edge devices. For example, configurations for the protocol connector edge app may be automatically generated from the tags defined in the original automation program (e.g., PLC code) or otherwise identified in the automation project. This ensures consistency between PLC tags and the protocol connector edge app, allowing the entire automation program and the edge app configurations to be deployed as a consistent automation project. The target devices for deployment may be specified in the automation project (e.g., in the automation program) , which allows seamless migration from virtual to physical assets by simply switching the deployment target. The use of virtual targets may enable the user to virtually commission the integrated automation and edge system using digital twin simulation tools, which can further de-risks deployment to the physical world. In some embodiments, artifacts of the automation project, including the automation program and the edge app configurations, may be versioned via a version control system. This can enable the user to leverage continuous integration-continuous deployment  / delivery (CI-CD) infrastructure to automatically perform compilation, verification and validation, and deployment to virtual or physical assets.

[0024] Turning now to the drawings, FIG. 1 shows the architecture of a system 100 for engineering an automation system to carry out an automation task. In the described example, the automation system components include an edge device 102 that can be integrated with an automation controller (such as PLC) 104 and at least one field device (such as a camera) 106 operable as a data  source, to execute an automation task that includes a control loop.

[0025] The edge device 102 may provide local computing and data storage to carry out the automation task. In some embodiments, the edge device 102 may include a runtime software layer 108 configured to deploy a number of modular (e.g., containerized) applications, referred to as edge apps, that provide integrated connectivity for data exchange with various automation system components as well as data processing logic to perform the specified task. The edge apps may include, in this case: (1) a protocol connector (PC) 110 to enable data exchange with the automation controller 104 based on a specific communication protocol (which may be standard or proprietary) such as S7+, Profinet IO, Ethernet  / IP, etc., (2) a field device connector, such as a vision connector (VC) 112, to enable data exchange with the camera 106 in this example, and (3) a data processing app, such as an AI inference server (AI IS) 114 that can run an AI pipeline, which may include an AI model such as a deep neural network. Depending on the actual implementation, the edge device 102 may include any number of additional edge apps, such as one or more messaging client apps, analytical apps, dashboard apps, among others.

[0026] The edge infrastructure may be realized via a centralized edge management system 134. The edge management system 134 may include an on-site computer or a virtual machine to supervise one or more edge devices in one or more automation systems. The edge management system 134 may provide a framework to manage and optimize the deployment, configuration and operation of the edge apps in the one or more edge devices, among other functions.

[0027] FIG. 2 illustrates a workflow 200 for software-defined integration of the edge device 102 with the automation controller 104 and the camera 106 for an automation task, such as AI-based visual quality inspection on a production line. The various activity blocks 202-218 of the workflow 200, including components thereof, may be implemented using an automation engineering computer system, such as described in FIG. 4. FIG. 2 is not intended to indicate that the activity blocks of the workflow 200 are to be performed in the order as shown, or that all of the activity blocks of the workflow 200 are to be included in every case. Additionally, the workflow 200 can include any suitable number of additional activities. The workflow 200 is described referring jointly to FIG. 1 and FIG. 2.

[0028] At block 202, an automation engineering tool 116 may be run on the automation  engineering computer system to create an automation project 118 based on a user input. The automation engineering tool 116 may include an integrated development environment (IDE) to allow a user to create, edit and manage automation programs and other artifacts such as configuration files, etc. In a suitable, non-limiting implementation, the automation engineering tool 116 may include the SIMATIC tool developed by Siemens, which provides an IT-like engineering platform with a Visual Studio Code-based IDE for programming PLCs. From a single SIMATIC project, a user can specify target PLCs, named tags and data structures, I / O mappings, and automation logic. The project artifacts typically consist of structured text (ST) code and configuration (YAML) files, which can be version controlled (e.g., via git) and integrated with standard DevOps  / CI-CD frameworks for automatically compiling, testing, validating, packaging, and deploying the automation program.

[0029] Having created an automation project 118, the system components involved in the automation task may be specified. The system components may include, in this case, the edge device 102 and the automation controller 104, as well as the camera 106 or any other component not shown, such as a distributed I / O module of the automation controller 104, among others. The system components may be specified, for example, by specifying an address (e.g., IP address) as well as a hardware configuration of the particular system component, in one or more configuration (e.g., YAML) files 120 in the automation project 118. The specified automation controller 104 and the edge device 102 may define the respective target devices for subsequently deploying the automation program and the edge app configurations. The target automation controller might include a physical controller, a virtualized controller or a software-defined controller. The target edge device might include a physical edge device or a virtualized edge device. For example, in case of a virtualized PLC, the automation logic may be executed on the same physical device as the edge apps. The use of virtual targets can enable virtual commissioning of the integrated automation and edge system using digital twin simulation tools prior to deployment of the automation artifacts on the actual production line.

[0030] At block 204, the user may create an automation program 122 defining logic for the automation controller 104. To illustrate with an example AI-based automation task, the automation logic may include activating an alarm or an actuator (e.g., a “rejects” conveyor) by the automation controller 104 if the AI pipeline on the edge device 102 detects a defect in a manufactured part based on an image captured by the camera 106. The automation program 122 may be written in an automation programming language such as structured text (ST) , structured control language (SCL) , ladder logic, among others.

[0031] The automation program 122 may define tags for data exchange with other devices. A “tag” refers to a name assigned to a variable stored in the memory of an automation controller, and may represent various elements such as inputs, outputs, memory locations, timers, and control signals within the automation controller. The automation program 122 may also define the configuration for hardware triggers for the automation controller’s I / O module.

[0032] In some embodiments, the automation engineering tool 116 may include a function block library 136 comprising user-defined function blocks for particular type of integrated edge-automation system, such as an edge-based AI vision system in this example. Each function block may include predefined data structures (e.g., tags, such as user-defined types (UDT) , etc. ) , and an automation programming code template for handling communication with an edge device for the particular type of integrated edge-automation system. The automation engineering tool 116 may provide an interface to create the automation program 122 by utilizing one or more function blocks from the function block library 136.

[0033] The principle of using the user-defined function blocks may be as follows. For a given type of edge-automation system (e.g., edge-based AI vision system) , an automation controller would always execute a known routine, which may be defined by a sequence of function blocks. Each function block in this case can be considered as a proxy for what actually happens on the edge device, e.g., processing an image. Hence, the function block in that case just has to implement some basic logic, such as: set a trigger on a tag “X” to start, start a timer, wait for a response on a tag “Y” , and, if there is no response on tag “Y” within n seconds, then execute some default logic, else execute logic according to the value of tag “Y” . In this case, the function block may include input and output tags (e.g., “X” and “Y” ) and some basic logic (template) to handle cases where the edge device failed to provide a response in time. An automation engineer, when integrating the system, just has to link “X” and “Y” to the actual datapoints that will be exchanged with the edge device. The function block may include an indicator for where a user is to insert their automation programming code.

[0034] In one implementation, to create the automation program 122, a function block may be imported from the FB library 136, and an AI pipeline for the edge-based AI vision system may be declared in the automation program 122, for example, in a “configure” area of an ST code. The imported function block may act as a proxy for the edge workload in the automation program 122. For example, it may handle all communication with the AI pipeline from within the automation  program 122, including control commands, inference results handling and conversion, configuration commands, a heartbeat to ensure constant communication with the AI pipeline, a timeout to execute a default logic if the AI pipeline cannot provide an inference result on time (to maintain determinism) , etc. By abstracting basic functions for the edge-based AI vision system communication and control and providing a standardized programming interface inside the automation program 122 using the automation programming code template, the function block library 136 can streamline the programming experience, allowing users to spend less time on “boilerplate” code, and more time on the specifics of their implementation.

[0035] At block 206, the tags that define data exchange with the edge device may be identified to generate a tag list 124. The tag list 124 may define a signal map between the automation controller 104 and the AI pipeline. The tag list 124 may be generated manually or automatically (e.g., by rule-based parsing) from the automation program 122 and stored in a defined file format (e.g., YAML) in the automation project 118. In one implementation, in addition to the tag list, the stored file can also include parameters such as the protocol for communication between the automation controller 104 and the edge device 102 (e.g., S7+, Profinet IO, Ethernet  / IP, OPC UA) , the databus to which the automation controller 104 is to be connected, messaging protocol (e.g., MQTT) topics assigned to the automation controller 104, among others. In other implementations, such parameters may be separately specified.

[0036] At block 208, based on the tag list 124 and the specified parameters, an edge app configuration generator 128 may automatically generate an edge app configuration 126a for the PC app 110 for communication between the automation controller 104 and the edge device 102 in the specified protocol. The edge app configuration generator 128 may comprise a software routine integrated with or accessible by the automation engineering tool 116. In some embodiments, the edge app configuration generator 128 may generate the edge app configuration 126a as a configuration file utilizing a configuration schema (e.g., a JSON schema) of the PC app 110. The configuration schema may be obtained from an app configuration schema library 130, which may, for example, be integrated in automation engineering tool 116. Alternately, the configuration schema may be obtained via an API request from the PC app 110. The edge app configuration 126a returned by the edge app configuration generator 128 may be stored as an artifact of the automation project 118.

[0037] FIG. 3 shows an example of a process 300 for executing blocks 206 and 208 of the  workflow 200 according to an example embodiment. In this example, the identification of tags for mapping between a PLC and an edge device is automated by leveraging pre-existing semantic information in the automation project, such as the location of tags inside an ST program. As shown, the automation logic is defined in a PLC program, which comprises an ST file 302. An ST parser 304 automatically performs a rule-based (e.g., grammar-based) parsing of the ST file 302 to extract tag locations (in PLC memory) and datatypes, to generate a list of PLC tags 306 as a YAML file. For illustration, the identified tags are highlighted within dashed boxes in the PLC program (in ST) 302 and the resultant PLC tag list (in YAML) 306. Finally, an S7 configuration generator 308 automatically generates the edge S7 connector configuration utilizing the JSON configuration schema of the S7 connector app.

[0038] Continuing with joint reference to FIGS. 1 and 2, in some embodiments, at block 210, the configuration of the field device connector  / VC app 112 may also be generated via the automation engineering tool 116. The automation engineering tool 116 may provide a user interface for receiving a user input specifying configuration parameters of the field device  / camera 106. For instance, in the present example, the camera configuration parameters can include exposure time, image size  / resolution, color format, trigger mode, frame rate, messaging protocol (e.g., ZeroMQ) topics assigned to the camera 106, among others. The specified configuration parameters may be stored in a defined file format (e.g., YAML) . Based on the specified configuration parameters, the edge app configuration generator 128 may generate an edge app configuration 126b for the field device connector  / VC app 112 for communication between the edge device 102 and the field device  / camera 106. In some embodiments, the edge app configuration generator 128 may generate the edge app configuration 126b as a configuration file utilizing a configuration schema (e.g., a JSON schema) of the field device connector  / VC app 112. The configuration schema may be obtained from the app configuration schema library 130 or via an API request from the field device connector  / VC app 112. The edge app configuration 126b returned by the edge app configuration generator 128 may be stored as an artifact of the automation project 118.

[0039] In some embodiments, at block 212, the configuration of the data processing app 114 may also be generated via the automation engineering tool 116. The automation engineering tool 116 may provide a user interface for receiving a user input specifying mappings of an input and an output of the data processing app 114 respectively to one or more data sources (e.g., sensors) and one or more automation devices, where the one or more data sources include the field device  / camera 106, and the  one or more automation devices include the automation controller 104.

[0040] Consistent with the disclosed embodiments, the data processing app may include an AI IS app 114 configured to run an AI pipeline on the edge device 102. In this case, the specified input and output mappings may pertain, respectively, to inputs and outputs of the AI pipeline. Additionally, the user input may specify an ID and  / or version of the AI pipeline to be downloaded to the AI IS app 114 (e.g., via the edge management system 134) . For example, the input mapping should be consistent with the messaging protocol (e.g., ZeroMQ) topics assigned to the field device  / camera 106, which the AI pipeline would receive via the field device connector  / VC app 112. Likewise, the output mapping should be consistent with the messaging protocol (e.g., MQTT) topics assigned to automation controller 104 (e.g., including classification result, quality  / confidence, error code) , which the AI pipeline would return the PC app 110 via the databus. For example, the AI pipeline may expect as input a certain image size which needs to match the camera resolution set in the configuration 126b of VC app 112. Or similarly, the set of tags listed in the configuration 126a of the PC app 110 need to match the AI pipeline’s outputs. This kind of consistency check could be applied automatically, or at least the configuration files of these apps can be version controlled together (as described below) .

[0041] The specified input and output mappings may be stored in a defined file format (e.g., YAML) . Based on the input and output mappings, the edge app configuration generator 128 may generate an edge app configuration 126c for the AI IS app 114 to run the specified AI pipeline. In some embodiments, the edge app configuration generator 128 may generate the edge app configuration 126c as a configuration file utilizing a configuration schema (e.g., a JSON schema) of the AI IS app 114. The configuration schema may be obtained from the app configuration schema library 130 or via an API request from the AI IS app 114. The edge app configuration 126c returned by the edge app configuration generator 128 may be stored as an artifact of the automation project 118.

[0042] In some embodiments, the automation tool 116 may include an AI model client 138 configured submit a user query to an AI model training platform 140 to provide attributes of the AI pipeline, to therefrom determine at least some of the mappings for the inputs and  / or outputs of the AI pipeline. In the present example, a remote (cloud-based) AI model training platform 140 may provide attributes of the available AI pipelines via a REST API, such that the AI model client 138 can learn integration-relevant information like input image sizes and color formats supported by the  pipeline and number and datatype of outputs generated by the AI pipeline. The AI model client added to the automation engineering tool 116 can allow the user to interactively query the AI training platform 140 and engineer the AI pipeline integration accordingly. The attributes received by the AI model client 138 may also be utilized to automatically populate some of the configuration parameters of other apps (e.g., the PC app 110 and  / or the VC app 112) based on the input and output mappings of the AI IS app 114. For example, the image size expected by the AI pipeline could be set as the camera resolution in the app configuration 126b of the VC app 112. Also, the AI pipeline outputs could all be instantiated as tags in the app configuration 126a of the PC app 110. The tags may not necessarily have the same names, but at least the data types and array sizes may be retrieved from the AI pipeline API.

[0043] In some embodiments, the artifacts of the automation project 118, including the automation program 122 and the edge app configuration (s) 126a, 126b, 126c may be versioned in a data repository via a version control system 142. The version control system 142 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 a Git server. Version control may be applied to the entire repository of artifacts for a given automation project 118. The version control system 142 may thereby enable multiple users, e.g., engineers from different disciplines 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) .

[0044] In those embodiments, at block 214, generated (or modified) artifacts of the automation project 118, including the automation program 122 and the edge app configuration (s) 126a, 126b, 126c, may be committed to the version control system 142. A “commit” refers to the action of saving changes to the artifacts in the data repository. At block 216, a CI-CD pipeline may be executed to test and validate the artifacts committed to the version control system 142.

[0045] The CI-CD pipeline may include standard stages, 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) . In some embodiments, the CI-CD pipeline may be executed to deploy the tested versions of the artifacts including the automation program 122 and the edge app configuration (s) 126a, 126b, 126c respectively to a virtualized automation controller and a virtualized edge device specified as target devices in the automation project 118, for validating the artifacts and the integration of the edge and automation devices. The validation may be performed using a virtual commissioning pipeline that utilizes a simulation environment (e.g., Process  developed by Siemens) complete with all physical and logical components of the automation system, as a testing environment for each artifact. A virtual commissioning pipeline may comprise a series of processing steps, which may include running simulations by executing an artifact on a virtualized device (edge device and  / or automation controller) interacting with the simulation environment over a number of test paths, to verify if a desired behavior or functionality is achieved. The virtual commissioning pipeline may be executed (in addition to code testing) to implement a quality gate for each commit of the artifacts to the version control system 142, prior to deployment of the artifacts on the production line.

[0046] At block 218, the artifacts of the automation project 118 may be deployed to respective target devices specified in the automation project 118. The automation program 122 may be deployed to a target automation controller 104 and the edge app configurations 126a, 126b, 126c may be deployed to a target edge device 102. The specified AI pipeline may be downloaded from the AI model training platform 140 to an instance of the AI IS app 114 on the target edge device 102, for example, via the edge management system 134. For example, as described above, if the deployment is executed via a CI-CD pipeline, the specified target devices may initially include one or more virtualized devices for validating the integration and subsequently include physical devices.

[0047] In some embodiments, as shown herein, the configuration file containing each edge app configuration 126a, 126b, 126c may be deployed to the target edge device 102 via the edge management system 134 using a command-line configuration tool 132. The command-line configuration tool 138 may be implemented, for example, as a wrapper defining an extension of the automation engineering tool 116. In alternate embodiments, the edge app configuration generator 128 may comprise an API client, which can deploy each app configuration 126a, 126b, 126c by generating an appropriate API request to a respective endpoint associated with an instance of each edge app on the target edge device 102 (target app) . For example, in one implementation, the edge app configuration generator may generate each app configuration 126a, 126b, 126c based on a  configuration schema of the respective app 110, 112, 114 (as described above) and submit the complete configuration payload to the APIs of the target apps. In another implementation, instead of a schema-based approach, the edge app configuration generator 128 may provide the configuration parameters individually to the APIs of the target apps, e.g., through an interactive process. In this case, the edge app configuration generator  / API client 128 may know the API specification of the target app, whereby it can generate appropriate API requests to set any subset of the configuration parameters individually rather than as a full configuration payload.

[0048] Upon deployment of the artifacts, the target edge device 102 may be configured to communicate with the target automation controller 104 by executing an instance of the PC app 110 on the target edge device 102 based on the deployed edge app configuration 126a and the automation controller 104 may be configured to execute the logic defined by the deployed automation program 122 based on the communication with the target edge device 102, to execute a control loop. In some embodiments, based on the deployment of the edge app configuration 126b, the target edge device 102 may be configured to communicate with the field device  / camera 106 by executing an instance of the field device connector  / VC app 112 on the target edge device 102. In some embodiments, based on the deployment of the edge app configuration 126c, an instance of the data processing  / AI IS app 114 may be configured to communicate with instances of the PC app 110 and the field device connector  / VC app 112 on the target edge device 102.

[0049] FIG. 4 illustrates an example of a computing environment within which embodiments of the present disclosure may be implemented. A computing environment 400 includes an automation engineering computer system 410 that may include a communication mechanism such as a system bus 421 or other communication mechanism for communicating information within the computer system 410. The computer system 410 further includes one or more processors 420 coupled with the system bus 421 for processing the information.

[0050] The processors 420 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, 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) 420 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.

[0051] The system bus 421 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 computer-executable code) , signaling, etc. ) between various components of the computer system 410. The system bus 421 may include, without limitation, a memory bus or a memory controller, a peripheral bus, an accelerated graphics port, and so forth. The system bus 421 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.

[0052] Continuing with reference to FIG. 4, the computer system 410 may also include a system memory 430 coupled to the system bus 421 for storing information and instructions to be executed by  processors 420. The system memory 430 may include computer readable storage media in the form of volatile and  / or nonvolatile memory, such as read only memory (ROM) 431 and  / or random access memory (RAM) 432. The RAM 432 may include other dynamic storage device (s) (e.g., dynamic RAM, static RAM, and synchronous DRAM) . The ROM 431 may include other static storage device (s) (e.g., programmable ROM, erasable PROM, and electrically erasable PROM) . In addition, the system memory 430 may be used for storing temporary variables or other intermediate information during the execution of instructions by the processors 420. A basic input  / output system 433 (BIOS) containing the basic routines that help to transfer information between elements within computer system 410, such as during start-up, may be stored in the ROM 431. RAM 432 may contain data and  / or program modules that are immediately accessible to and  / or presently being operated on by the processors 420. System memory 430 may additionally include, for example, operating system 434, application modules 435, and other program modules 436. Application modules 435 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.

[0053] The operating system 434 may be loaded into the memory 430 and may provide an interface between other application software executing on the computer system 410 and hardware resources of the computer system 410. More specifically, the operating system 434 may include a set of computer-executable instructions for managing hardware resources of the computer system 410 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 434 may control execution of one or more of the program modules depicted as being stored in the data storage 440. The operating system 434 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.

[0054] The computer system 410 may also include a disk  / media controller 443 coupled to the system bus 421 to control one or more storage devices for storing information and instructions, such as a magnetic hard disk 441 and  / or a removable media drive 442 (e.g., floppy disk drive, compact disc drive, tape drive, flash drive, and  / or solid state drive) . Storage devices 440 may be added to the computer system 410 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 441, 442 may be external to the computer system 410.

[0055] The computer system 410 may include a user input interface or graphical user interface (GUI) 461, 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 420.

[0056] The computer system 410 may perform a portion or all of the processing steps of embodiments of the invention in response to the processors 420 executing one or more sequences of one or more instructions contained in a memory, such as the system memory 430. Such instructions may be read into the system memory 430 from another computer readable medium of storage 440, such as the magnetic hard disk 441 or the removable media drive 442. The magnetic hard disk 441 and  / or removable media drive 442 may contain one or more data stores and data files used by embodiments of the present disclosure. The data store 440 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 420 may also be employed in a multi-processing arrangement to execute the one or more sequences of instructions contained in system memory 430. 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.

[0057] As stated above, the computer system 410 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 420 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. Non-limiting examples of non-volatile media include optical disks, solid state drives, magnetic disks, and magneto-optical disks, such as magnetic hard disk 441 or removable media drive 442. Non-limiting examples of volatile media include dynamic memory, such as system memory 430. Non-limiting examples of transmission media include coaxial cables, copper wire, and fiber optics, including the wires that make up the system bus 421. Transmission media may also take the form of acoustic or light waves, such as those generated during radio wave and infrared data communications.

[0058] 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, and 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.

[0059] 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.

[0060] The computing environment 400 may further include the computer system 410 operating in a networked environment using logical connections to one or more remote computers, such as remote computing device 480. The network interface 470 may enable communication, for example, with other remote devices 480 or systems and  / or the storage devices 441, 442 via the network 471. Remote computing device 480 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 410. When used in a networking environment, computer system 410 may include modem 472 for establishing communications over a network 471, such as the Internet. Modem 472 may be connected to system bus 421 via user network interface 470, or via another appropriate mechanism.

[0061] Network 471 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 any other network or medium capable of facilitating communication between computer system 410 and other computers (e.g., remote computing device 480) . The network 471 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 471.

[0062] It should be appreciated that the program modules, applications, computer-executable instructions, code, or the like depicted in FIG. 4 as being stored in the system memory 430 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 410, the remote device 480, and  / or hosted on other computing device (s) accessible via one or more of the network (s) 471, may be provided to support functionality provided by the program modules, applications, or computer-executable code depicted in FIG. 4 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. 4 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 peer-to-peer model, and so forth. In addition, any of the functionality described as being supported by any of the program modules depicted in FIG. 4 may be implemented, at least partially, in hardware and  / or firmware across any number of devices.

[0063] It should further be appreciated that the computer system 410 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 410 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 and described as software modules stored in system memory 430, 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.

[0064] 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

1.A computer-implemented method for engineering an automation system, comprising:running an automation engineering tool to create an automation project based on a first user input, the automation project including an automation program defining logic for an automation controller, and an identification of tags defining data exchange between the automation controller and an edge device to carry out an automation task,automatically generating, via an edge app configuration generator integrated with or accessible by the automation engineering tool, a first edge app configuration for a protocol connector edge app for communication between the edge device and the automation controller, based on the identified tags, anddeploying artifacts of the automation project, including the automation program and the first edge app configuration, respectively to a target automation controller and a target edge device specified in the automation project,whereby the target edge device is configured to communicate with the target automation controller by executing an instance of the protocol connector edge app on the target edge device based on the deployed first edge app configuration and the automation controller is configured to execute the logic defined by the deployed automation program based on the communication with the target edge device.2.The method according to claim 1, wherein the tags for generating the first edge app configuration are automatically identified via rule-based parsing of the automation program and stored in a defined file format in the automation project.3.The method according to any of claims 1 and 2, further comprising:receiving a second user input by the automation engineering tool specifying configuration parameters for a field device operable as a data source,automatically generating, via the edge app configuration generator, a second edge app configuration for a field device connector edge app for communication between the target edge device and the field device, based on the specified configuration parameters for the field device, anddeploying the second edge app configuration to the target edge device,whereby the target edge device is configured to communicate with the field device by executing an instance of the field device connector edge app on the target edge device based on the deployed second edge app configuration.4.The method according to claim 3, further comprising:receiving a third user input by the automation engineering tool specifying mappings of an input and an output of a data processing edge app respectively to one or more data sources and one or more automation devices, wherein the one or more data sources include the field device, and the one or more automation devices include the automation controller,automatically generating, via the edge app configuration generator, a third edge app configuration for the data processing app, based on the specified input and output mappings, anddeploying the third edge app configuration to the target edge device to configure an instance of the data processing edge app to communicate with instances of the protocol connector edge app and the field device connector edge app on the target edge device.5.The method according to claim 4, wherein the data processing edge app comprises an AI inference server edge app configured to run an AI pipeline on the target edge device, wherein the specified input and output mappings pertain, respectively, to inputs and outputs of the AI pipeline.6.The method according to claim 5, wherein the automation tool includes an AI model client configured submit a user query to an AI model training platform to provide attributes of the AI pipeline, to therefrom determine at least some of the mappings for the inputs and  / or outputs of the AI pipeline.7.The method according to any of the preceding claims, wherein the edge app configuration generator generates each edge app configuration as a configuration file utilizing a configuration schema of the respective edge app.8.The method according to claim 7, wherein the configuration schema of the respective edge app is obtained from an app configuration schema library or via an API request to the respective edge app.9.The method according to any of claims 7 and 8, wherein each configuration file is deployed via centralized edge management system utilizing a command-line configuration tool.10.The method according to any of claims 1 to 6, wherein the edge app configuration generator comprises an API client configured to deploy each app configuration by generating an appropriate API request to a respective endpoint associated with an instance of each edge app on the target edge device.11.The method according to any of the preceding claims, wherein the automation engineering tool includes a function block library comprising user-defined function blocks for a particular type of integrated edge-automation system, each function block including predefined data structures and an automation programming code template for handling communication with an edge device for the particular type of integrated edge-automation system,wherein the automation engineering tool provides an interface to create the automation program by utilizing one or more function blocks from the function block library.12.The method according to any of the preceding claims, further comprising versioning the artifacts of the automation project, that include the automation program and the edge app configuration (s) , in a data repository via a version control system.13.The method according to claim 12, comprising executing a continuous integration-continuous deployment  / delivery (CI-CD) pipeline for testing and deploying versions of the artifacts committed to the version control system.14.The method according to claim 13, comprising executing the CI-CD pipeline for deploying the tested versions of the artifacts including the automation program and the edge app configuration (s) respectively to a virtualized automation controller and a virtualized edge device specified as target devices in the automation project, for validating the artifacts against a simulation environment representing the automation system.15.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 14.16.An automation engineering computer system, comprising:one or more processors, andmemory storing instructions executable by the one or more processors to perform a method according to any of claims 1 to 14.

Images