System and method for hierarchical modular automation system

Abstract

A method for implementing an automation system (152) and a corresponding system (100) and computer readable medium (126). The method includes: activating (602) a system orchestrator (168); and reading (604) the system configuration definition (156) and the system manifest (158). The method includes reading (606) an application configuration definition (156) and an application manifest (158) for one or more applications (154) based on a system configuration definition (156). The method includes defining (610) an application configuration definition (156) for one or more applications (154) based on a system configuration definition (156); and executing (614) the one or more applications (154) based on the application configuration definition (156) and the application manifest (158). The method includes controlling (618) at least one external physical device (570) based on the one or more executed applications (154).

Description

Technical Field

[0001] The present disclosure relates generally to software automation systems, and in particular to their use in monitoring and controlling physical manufacturing plants. Background Art

[0002] Traditional automation systems, including manufacturing systems, are implemented using a hierarchical control architecture of automation devices implemented with dedicated hardware controllers. For example, a programmable logic controller (PLC) is typically used to build an overall control system to execute production tasks by communicating with sensors and actuators, and higher-level PLCs can be used to control manufacturing-level PLCs. Because each PLC is specifically programmed to perform its discrete tasks, modifying or improving the entire system is extremely complex and expensive, as many or all of the affected PLCs must be replaced, reprogrammed, or reconfigured. Even in systems that use general-purpose processors under software control, the interrelationships among the processors in the hierarchical system make it difficult to modify or upgrade the system, as the software control system itself does not easily adapt to changes in software or hardware configurations.

[0003] Furthermore, industrial system configurations are created within the context of often proprietary applications with closed and undisclosed configuration storage formats. Industrial systems themselves are implemented in a closed, encapsulated manner. PLCs are often inherently connected to the rest of the automation system and the physical world, hindering efficient modification, improvement, or reconfiguration of the automation system. Because automation systems are configured in a closed and rigid manner, reusing components and functionality is complex and often impossible. This creates a need for improved systems. Summary of the Invention

[0004] Various disclosed embodiments include methods for implementing an automation system, as well as corresponding systems and computer-readable media. The method includes: launching a system orchestrator and reading a system configuration definition and a system manifest. The method includes: reading application configuration definitions and an application manifest for one or more applications based on the system configuration definition. The method includes: defining application configuration definitions for the one or more applications based on the system configuration definition; and executing the one or more applications based on the application configuration definitions and the application manifest. The method includes: controlling at least one external physical device based on the one or more executed applications.

[0005] The foregoing has provided a rather broad overview of the features and technical advantages of the present disclosure so that those skilled in the art may better understand the detailed description that follows. Additional features and advantages of the present disclosure will be described below, and these features and advantages form the subject matter of the claims. Those skilled in the art will appreciate that they can readily use the disclosed concepts and specific embodiments as a basis for modifying or designing other structures to achieve the same purposes of the present disclosure. Those skilled in the art will also recognize that these equivalent constructions do not depart from the spirit and scope of the present disclosure in its broadest form.

[0006] Before beginning the following detailed description, it may be helpful to set forth definitions of certain words and phrases used throughout this patent document: the terms "include" and "comprising" and their derivatives mean including, but not limited to; the term "or" is inclusive, meaning and / or; the phrases "associated with" and "associated therewith" and their derivatives may mean including, being included, interconnected with, containing, being contained within, connected to or connected with, coupled to or coupled with, communicable with, cooperating with, interleaved with, juxtaposed, proximate, bound to or bound with, having, having a characteristic of, and the like; the term "controller" means any device, system, or portion thereof that controls at least one operation, whether such device is implemented in hardware, firmware, software, or some combination of at least two thereof. It should be noted that the functionality associated with any particular controller may be centralized or distributed, whether locally or remotely. Definitions for certain words and phrases are provided throughout this patent document, and those skilled in the art should understand that these definitions apply in many, if not most, instances to prior and future uses of such defined words and phrases. While some terms may include a wide variety of embodiments, the appended claims may expressly limit these terms to specific embodiments. BRIEF DESCRIPTION OF THE DRAWINGS

[0007] For a more complete understanding of the present disclosure and its advantages, reference is now made to the following description taken in conjunction with the accompanying drawings, wherein like numerals represent like objects, and wherein:

[0008] Figure 1 A block diagram illustrating a data processing system in which embodiments may be implemented is shown;

[0009] Figure 2 An example of an automation system according to the disclosed embodiments is shown;

[0010] Figure 3 An example of a multi-system automation system according to the disclosed embodiments is shown;

[0011] Figure 4An example of a hierarchical automation system 400 according to the disclosed embodiments is shown;

[0012] Figure 5 An example of a process according to the disclosed embodiments is shown;

[0013] Figure 6 An example of a process according to the disclosed embodiments is shown. DETAILED DESCRIPTION

[0014] Discussed below Figures 1 to 6 The various embodiments used to describe the principles of the present disclosure in this patent document are intended to be illustrative only and should not be construed in any way to limit the scope of the present disclosure. Those skilled in the art will appreciate that the principles of the present disclosure can 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] To increase the flexibility of production and other systems, the disclosed embodiments enable physical devices (e.g., machines or robots) to be adapted to become more modular and flexible, shifting their operation from isolated assets to gridded systems. Centralized management of automation systems / infrastructure (e.g., computing nodes, networks, applications, etc.) provides a unified operating environment.

[0016] To support flexibility in hardware configuration and operational control, the disclosed embodiments provide a layered software system comprising modular software applications linked and orchestrated by a system orchestrator. These systems are also modular and can be linked to other systems and applications to form higher-level, more complex software control systems, which offer significant technical advantages for automated configuration and assembly of application modules.

[0017] Rebuilding complex processes and automation infrastructure into subsets of modular automation units and easily configurable building blocks significantly reduces the cost and time to market for generating new value for manufacturing plants. The disclosed embodiments enable next-generation manufacturing strategies that support global competitiveness, innovation, and new product introductions with faster market responsiveness.

[0018] Disclosed embodiments include a modular automation system that uses an overall orchestration process to ensure that the system operates as expected and that each component is in the correct state at all times. Various embodiments include multiple modular applications organized hierarchically and controlled by a system orchestrator to execute corresponding processes in a given order, thereby creating higher-order, complex systems.

[0019] Figure 1A block diagram of a data processing system in which embodiments may be implemented is shown, for example, as a computer system configured, inter alia, by software or otherwise, to perform processes as described herein, and as an automation system implemented, inter alia, by each of a plurality of interconnection and communication systems as described herein. The depicted data processing system includes a processor 102 connected to a level 2 cache / bridge 104, which in turn is connected to a local system bus 106. Local system bus 106 may be, for example, a Peripheral Component Interconnect (PCI) architecture bus. In the depicted example, main memory 108 and a graphics adapter 110 are also connected to the local system bus. Graphics adapter 110 may be connected to a display 111.

[0020] Other peripheral devices, such as a local area network (LAN) / wide area network / wireless (e.g., WiFi) adapter 112, can also be connected to the local system bus 106. An expansion bus interface 114 connects the local system bus 106 to an input / output (I / O) bus 116. The I / O bus 116 connects to a keyboard / mouse adapter 118, a disk controller 120, and an I / O adapter 122. The disk controller 120 can be connected to a storage device 126, which can be any suitable machine-usable or machine-readable storage medium, including, but not limited to, non-volatile, hard-coded type media such as read-only memory (ROM) or erasable electrically programmable read-only memory (EEPROM), magnetic tape storage devices, and user-recordable type media such as floppy disks, hard drives, and compact disk read-only memories (CD-ROMs) or digital versatile disks (DVDs), as well as other known optical, electrical, or magnetic storage devices. I / O adapter 122 may be connected to control, read, write, or otherwise communicate or interact with any number of external devices, including controllable devices, sensors, motors, actuators, and other physical devices as described herein.

[0021] In the example shown, an audio adapter 124 is also connected to I / O bus 116 to which speakers (not shown) may be connected for playing sound. A keyboard / mouse adapter 118 provides a connection for a pointing device (not shown) such as a mouse, trackball, trackpointer, touch screen, or the like.

[0022] Those skilled in the art will understand that Figure 1 The hardware depicted in the examples may vary for a particular implementation. For example, other peripheral devices such as optical disk drives may be used in addition to or in place of the depicted hardware. The depicted examples are provided for illustrative purposes only and are not meant to impose architectural limitations on the present disclosure.

[0023] According to embodiments of the present disclosure, a data processing system includes an operating system capable of employing a graphical user interface. The operating system allows multiple display windows to be displayed simultaneously within the graphical user interface, each display window providing an interface for a different application or a different instance of the same application. A cursor within the graphical user interface can be manipulated by the user using a pointing device. The cursor's position can be changed and / or events, such as mouse button clicks, can be generated to trigger desired responses. In other embodiments disclosed herein, the disclosed applications can be run within a data processing system without a display or other human-computer interface. Such systems can read configurations pushed to them via a data distribution system (e.g., RTI DDS or similar), obtain input from the same data distribution system or from physical devices, and provide their output to the same data distribution system or the physical world without requiring any user interface. Applications with user interfaces (including applications created solely to provide a human interface (HMI) with a machine or system) can also connect to the data distribution system and read and publish data.

[0024] If appropriately modified, one of various commercially available operating systems may be used, such as a version of Microsoft Windows™, a product of Microsoft Corporation of Redmond, Washington. Various embodiments may be implemented using the oldest Debian operating system based on the Linux kernel. The operating system may be modified or created based on the content described in this disclosure.

[0025] LAN / WAN / wireless adapter 112 can connect to network 130 (not part of data processing system 100), which can be any public or private data processing system network or combination of networks known to those skilled in the art, including the Internet. Data processing system 100 can communicate via network 130 with server system 140, which is also not part of data processing system 100 but can be implemented as, for example, a separate data processing system 100.

[0026] Storage device 126 may contain any of the data, programs, or other software elements described herein, such as automation system 152, application 154, configuration definition 156, manifest 158, gateway configuration 160, executable code 162, gateway 164, data for an application, system, system orchestrator, or gateway 166, system orchestrator 168, connector 170, and others.

[0027] As used herein, an "automation system" refers to a software product that is executable by one or more data processing systems (alone or in combination) and controls physical devices such as sensors, actuators, motors, and more complex mechanical assemblies, as well as other software layers such as data acquisition, communication, and other layers. An automation system is a modular software control unit that includes a system manifest, system configuration definitions, a system orchestrator, and one or more user-specified services ("applications") for implementing automation tasks using physical devices. Each application has an associated manifest and configuration definition (also referred to simply as a "configuration" for the corresponding system, subsystem, or application). The automation system itself can communicate with or be controlled by higher-level automation systems, or communicate with or be controlled by other systems, such as supervisory control and data acquisition systems, enterprise systems, human-machine interface systems, data distribution systems, or other systems.

[0028] Figure 2 A non-limiting example of an automation system 200 according to the disclosed embodiments is shown. Figure 2 In the example of FIG, automation system 200 includes system orchestrator 210 and associated system manifest 212 and system configuration definition 214. In this example, automation system 200 also includes three applications 220, 230, and 240. Each application has an associated manifest and configuration definition—application 220 is associated with manifest 222 and configuration definition 224, application 230 is associated with manifest 232 and configuration definition 234, and application 240 is associated with manifest 242 and configuration definition 244. Note that in other implementations, any number of applications may be present. Applications or subsystems in an automation system may be referred to as automation objects in the present disclosure.

[0029] Traditionally, software applications have been divided into independent subroutines that perform a single task. Each of these subroutines (whether integrated into the application or called as an external routine) is designed to meet that specific requirement and thoroughly tested to perform well. However, programmers must be familiar with the specific requirements and functionality of each subroutine, and these traditional structures are not easily understood as modular components of larger software systems.

[0030] According to the disclosed embodiment, in contrast, each application 220 includes additional associated files—a manifest 222 and a configuration definition 224—that together define the functionality and interface of application 220, so that applications 220 can be viewed as modular components of the overall automation system 200. System orchestrator 210 can use, instantiate, and configure applications 220 / 230 / 240 on the fly during system startup or execution, according to user, programmer, or other definitions.

[0031] The disclosed embodiments include a file-based description of an automation system 200 and a system orchestrator 210 that performs the overall tasks within the automation system 200. Note that while Figure 2 An example of a is a single automation system with multiple applications, but each automation system can be a modular component subsystem of another higher-level automation system and controlled by the system orchestrator of that higher-level system.

[0032] Figure 3 1 shows an example of such a "system of systems", showing an automation system 300 including a plurality of subsystems 320, 330 and 340. Figure 3 In the example of FIG, automation system 300 includes a system orchestrator 310 and an associated system manifest 312 and system configuration definition 314. In this example, automation system 300 also includes three subsystems 320, 330, and 340. Each subsystem has an associated manifest and configuration definition—subsystem 1 320 is associated with manifest 1 322 and configuration definition 1 324, subsystem 2 330 is associated with manifest 2 332 and configuration definition 2 334, and subsystem 3 340 is associated with manifest 3 342 and configuration definition 3 344. Note that in other implementations, any number of subsystems may be present.

[0033] Each subsystem's manifest and configuration definition is the system manifest and system configuration for that subsystem, and each subsystem itself can include one or more applications, each with an associated manifest and configuration definition. This allows each subsystem to have multiple functions, inputs, and outputs, which can be implemented by its applications and managed and presented to the parent system by the subsystem's system orchestrator and its associated system manifest and system configuration definitions.

[0034] Thus, each subsystem 320 includes additional associated files—manifest 322 and configuration definition 324—which together define the functionality and interface of subsystem 320, so that subsystem 320 can be viewed as a modular component of the overall automation system 300. System orchestrator 310 can use, instantiate, and configure subsystems 320 / 330 / 340 on the fly during system startup or execution.

[0035] According to various embodiments, manifests (such as manifest 222 or system manifest 212) are maintained as static files that describe general details of the corresponding system or application and are immutable. For example, a system manifest may contain general metadata, services or applications used within the system, and interface definitions consisting of named ports, interface directions, and definitions of their types. Similarly, an application manifest may contain general metadata, functions or procedures performed by the application, interface definitions defining the required inputs and outputs of the functions, named ports, interface directions, and definitions of their types. A system manifest may include or contain information from each of its application manifests and may be created in whole or in part by reading and combining the manifests of its subordinate subsystems and applications.

[0036] According to various implementations, a configuration file (whether a configuration definition or a system configuration definition) describes a specific system instance and is mutable (and may be referred to simply as a "configuration" in this disclosure). For example, it may contain instance-specific metadata as well as instructions for middleware used within the system. To instantiate two separate system instances from the same manifest, two separate configuration files are required.

[0037] With the help of the manifests and configuration files described in the present invention, developers or other users can describe the content of a system and specific runtime characteristics, such as parameters for authentication or the startup order of services, functions, applications or subsystems within the system.

[0038] A system orchestrator is defined for each system, whether it is the system orchestrator 210 of the automation system 200 including applications or the system orchestrator 310 of the automation system 300 including subsystems. The system orchestrator manages the communication and coordination between the modular components of the automation system. The system orchestrator reads two files: the system manifest and the system configuration. The system orchestrator runs as another service within the automation system and operates within the automation system boundary. Note that Figure 2 and Figure 3 The examples do not show the hierarchy between various applications or subsystems. The system orchestrator disclosed in the present invention can bind all applications and configurations together and can derive the configuration of each application from the system configuration. The system orchestrator can control other functions as described in the present invention, including creating gateways for communicating with other systems and processes, creating connectors between applications and subsystems, and other functions. In some cases, the system orchestrator can create "virtual" connectors that replace connectors that may be required by an application or subsystem but are not yet available due to the startup or execution state of another application or subsystem.

[0039] Thus, the modular automation system disclosed in the present invention may include a system inventory, a system configuration, a system orchestrator, and one or more user-specified applications or subsystems that can perform the current automation task. The system is completely self-sustaining.

[0040] In various implementations, an automation system may include any combination of subsystems and applications. Figure 4 An example of a hierarchical automation system 400 is shown in accordance with the disclosed embodiments. The automation system 400 includes a system orchestrator 410 at a top level having a system manifest 412 and a system configuration 414 .

[0041] At the next level are subsystem 1 420 (with subsystem 1 manifest 422 and subsystem 1 configuration 424), subsystem 2 430 (with subsystem 2 manifest 432 and subsystem 2 configuration 434), and application 1 450 (with application 1 manifest 452 and application 1 configuration 454).

[0042] At the third level is Application 2 460, which has Application 2 Manifest 462 and two configurations: Application 2 Configuration 1 464 and Application 2 Configuration 2 466. This shows that Application 2 460 exists or functions in two instances—the first instance defined by Application 2 Manifest 462 and Application 2 Configuration 1 464, and the second instance defined by Application 2 Manifest 462 and Application 2 Configuration 2 466.

[0043] Hierarchies can be identified or defined through references between configuration files. In this non-limiting example, system configuration 414 references subsystem 1 configuration 424, subsystem 2 configuration 434, and application 1 configuration 454. Subsystem 1 configuration 424 references application 2 configuration 1 464 (as the first instance of application 2), and subsystem 2 configuration 434 references application 2 configuration 2 465 (as the second instance of application 2).

[0044] The relevant content for each system and each application within the automation system can be stored in a configuration file for the highest-level system, such as system configuration 414. During the deployment process, relevant portions of the configuration from the aggregate configuration file can be passed down to the lower-level systems and applications. That is, system configuration 414 can reference subsystem 1 configuration 424, subsystem 2 configuration 434, and application 1 configuration 454. When system orchestrator 410 invokes or instantiates each of these systems or applications, system orchestrator 410 can define instance-specific metadata, configuration data, instructions, or other data and insert it into the configuration files of the corresponding lower-level systems or applications.

[0045] To enable the system to communicate as a modular unit with other applications and systems across system boundaries, the system orchestrator for a given system can set any required configuration data in the system configuration 414 to maintain a system "gateway" 470 or communication with other applications, systems, and devices 480 based on the system's defined interface names, types, and connections. As non-limiting examples, a higher-level control system can communicate with and use the automation system 400 via the gateway 470, or the automation system 400 can control physical devices such as sensors, actuators, and other devices via the gateway 470. The gateway 470 can include any connectors or data "translators" to enable proper communication between the automation system and other or external devices or systems. The gateway 470 can be implemented as an application with its own manifest and configuration for interfacing with internal or external systems that do not support the system's native format or are not directly accessible from within the current system, such as when separation, partitioning, or other security techniques are used to isolate systems and applications.

[0046] Gateway 470 can be implemented as an application with its own configuration and manifest, as disclosed herein. In various embodiments, gateway 470 is used to interface with systems that do not support communication in the system's native format via the automation system's data distribution system. In many cases, all applications and subsystems in an automation system exchange data via the same data distribution system, so gateway 470 can perform any necessary data translation or conversion to enable all systems to communicate via the DSS as needed. Various embodiments can be implemented using Real-Time Innovations' RTI CONNEXT DDS software.

[0047] Figure 5 An example of a process for launching an automation system 570 and generating an automation system gateway 508 according to the disclosed embodiments is shown, both of which are implemented in one or more data processing systems (hereinafter referred to in the singular). Each process described below as being performed by a software component running one or more data processes can be considered to be performed by a data processing system.

[0048] As shown in this example, the process may begin when a programmer or other user 502 initiates or invokes system orchestrator 510 of automation system 570 during system deployment phase 520, and system orchestrator 510 begins executing on the data processing system 522. In other cases, system orchestrator 510 may be initiated by another device or process.

[0049] The data processing system enters the system startup and verification phase 530. System orchestrator 510 reads the system configuration and manifest (532), such as from system repository 506 on the data processing system file system. This may also include reading any application configurations and manifests that are directly or indirectly indicated or linked to by the system configuration or manifest, such as from application repository 504 on the data processing system file system.

[0050] System orchestrator 510 receives the system configuration and manifest 534. This may also include receiving any application configuration and manifests as described above.

[0051] System orchestrator 510 may create gateway 508 that exposes the defined interface of automation system 570 to other systems, devices, and processes, such as for controlling physical devices or interacting with other systems and processes ( 550 ).

[0052] As part of gateway creation 550 , system orchestrator 510 can add the gateway to any automation system application 512 (if the application configuration or system configuration so defines) and create a gateway configuration 552 . The gateway configuration can be stored in system repository 506 .

[0053] System orchestrator 510 launches one or more applications 512 (536) from system repository 506 based on the application configuration or system configuration. Application 512 is referred to herein in the singular, but may refer to any number of independently running applications or subsystems. In particular, it is noted that when multiple applications 512 (or subsystems) are present, system orchestrator 510 may execute the launch process in a desired order or timing to ensure that dependencies between applications 512 (or subsystems) are satisfied.

[0054] Automation system 570 instantiates application 512 from system repository 506, and the application begins running in automation system 570 (538). Based on the configuration and manifest, the system orchestrator can ensure that each application 512 executes on the appropriate hardware according to its requirements.

[0055] The application 512 can read any secondary / middleware requirements (540) from the system orchestrator 510. In some embodiments, the application can have its initial or default configuration in a file-based application configuration format that is derived from the system configuration. Based on the initial configuration, the application can begin running and connect to middleware, such as the data distribution system described herein. The initial configuration can include data such as a connection string and / or connection parameters.

[0056] After successfully connecting to the middleware, the application can read the secondary configuration (540), which can modify / override the initial configuration. In various embodiments, this is read from the external middleware rather than from the system orchestrator 510 (542).

[0057] Once application 512 has successfully configured itself from multiple configuration sources, it may publish the complete configuration back to the middleware and may return system information to system orchestrator 510 (542).

[0058] Applications 512 continue to execute as configured under the control of system orchestrator 510 (544). In particular, system orchestrator 510 can control the operation of each application 512 (or subsystem) to ensure that data and timing dependencies between them are met. For example, system orchestrator 510 can ensure that application 512 has reached its desired run level. Once application 512 has reached its desired run level, system orchestrator 510 can start other applications 512 that require the given run level to ensure that dependencies between applications are met. Timing requirements are met by middleware (such as the data distribution system).

[0059] Thereafter, the various applications 512 may communicate among each other and with external devices 570 either directly or through gateway 508 ( 546 ).

[0060] While various embodiments may include manifests and configurations maintained in any machine-readable format, implementations that create and use manifests and configurations that are both human-readable and machine-readable are particularly advantageous. Automation objects (such as applications, subsystems, and the like) in software-defined automation and industrial systems have state and behavior and can have multiple connections to other automation objects as well as to external devices and processes. The state and behavior of automation objects and connections determine how the system operates. As disclosed in this invention, configurations are used to specify the initial state and parameters of the behavior in automation objects and to establish connections between automation objects and between automation objects and the physical world. These configurations are used by the system orchestrator to instantiate, start, and control automation objects and gateways.

[0061] Various embodiments may implement inventory and configuration using existing, open, human-readable and understandable text standards such as YAML, JSON, or XML to declaratively declare, initialize, and configure automation objects.

[0062] Each automation object has a manifest artifact (eg, a file) that is a declaration for a given automation object type.

[0063] An automation object manifest (whether an application manifest or a system / subsystem manifest) declares the automation object's meta-information, possible state variables (including variables that can be initialized), data points to which the automation object can connect as a reader, writer, or both, the automation object's behaviors that can be consumed by external partners (such as other connected automation objects), and the stateful and stateless signals produced by the automation object.

[0064] The following is a non-limiting example of a YAML-formatted manifest in accordance with the disclosed embodiments:

[0065]

[0066] As described above, the disclosed automation objects can have instances, and each instance is described or defined by a corresponding configuration definition, whether an application configuration or a system configuration. A manifest-based configuration specifies the settings required for a particular instance. For example, the configuration can provide meta-information about the automation object instance, provide values ​​for state variables, provide values ​​for parameters of behaviors, declare details of signals, and provide connection information to data points, other automation objects and / or physical devices. A system manifest can be used to configure common parameters for some or all of its subordinate subsystems and applications using specific declarations or reusable variable settings. The system configuration can also include information such as dependencies between applications and subsystems, the required readiness state of applications and subsystems, and the order and / or timing in which applications and subsystems must be started.

[0067] The following is a non-limiting example of a YAML-formatted configuration according to the disclosed embodiments:

[0068]

[0069] Using separate manifests and configurations ensures that the creator of an automation object (e.g., an automation application developer) only needs to specify the inputs that the automation object requires and supports, while the user of the automation object (e.g., an automation system designer) only needs to specify these parameters. This ensures a strict separation between creation and consumption, eliminating the need to recompile the automation object when integrating it into an automation system.

[0070] This structure also enables the creation of unlimited chains of user-defined configurations and enables the construction of systems of applications as described above. Portions of a configuration can be inherited by one application or system from another application or system. During the deployment process, relevant portions of the configuration from the aggregate configuration file can be passed down to lower-level systems and applications. That is, the relevant content of each system and each application within the automation system can be stored in a configuration file of a higher-level or top-level system, such as in the system configuration 414. Figure 4 In the example shown in FIG4 , system configuration 414 may reference subsystem 1 configuration 424, subsystem 2 configuration 434, and application 1 configuration 454. When system orchestrator 410 invokes or instantiates each of these systems or applications, system orchestrator 410 may define instance-specific metadata, configuration data, instructions, or other data and insert them into the configuration of the corresponding lower-level system or application. In various embodiments, system manifest 412 may reference or incorporate other manifests of the automation system, such as subsystem 1 manifest 422, subsystem 2 manifest 432, application 1 manifest 452, and application 2 manifest 462.

[0071] In various embodiments, the disclosed configurations may be created, stored, transmitted, or received in a variety of different ways, such as as a file, as a message in a messaging system, as a parameter in a REST call, and the like.

[0072] Figure 6 An example of a process 600 for implementing an automation system 152 and generating an automation system gateway 164, according to the disclosed embodiments, is shown, both being implemented in one or more data processing systems 100 (hereinafter referred to in the singular). Each process step described below as being performed by a software component running one or more data processes can be considered to be performed by a data processing system. According to the disclosed embodiments, any application, along with its configuration and manifest, can be implemented by a subsystem that is considered an application by the system orchestrator.

[0073] The process begins by launching the system orchestrator 168 (602). The system orchestrator may be launched by a user, by another automation system that is part of a subsystem, or by another device or process.

[0074] The system orchestrator 168 may read the system configuration definition 156 and the system manifest 158 ​​( 604 );

[0075] System orchestrator 168 may read application configuration definitions 156 and / or application manifests 158 for one or more applications 154 based on system configuration definition 156 (606). Application configuration definition 156 may be a default configuration.

[0076] System orchestrator 168 may update system manifest 156 based on application manifests 156 of one or more applications 154 ( 608 ).

[0077] System orchestrator 168 may define application configuration definitions 156 for one or more applications 164 based on system configuration definitions 156 (610). This may include updating default configuration definitions based on specific requirements of the applications. This may include defining multiple instances of the same application 164 using different application configuration definitions 156, thereby creating multiple application instances, each using a different application configuration definition.

[0078] System orchestrator 168 may define connectors 170 for one or more applications 164 ( 612 ). This may include defining a virtual connector 170 for at least one of the one or more applications 164 .

[0079] System orchestrator 168 may execute one or more applications 164 based on application configuration definition 156 and application manifest 158 ​​(614). This may include controlling the timing of execution of individual applications in one or more applications 164.

[0080] System orchestrator 168 may create gateway 164 ( 616 ).

[0081] The system orchestrator 168 or the automation system 152 may control at least one external physical device 570 (618) based on the one or more executed application programs 164. The external physical device may be controlled via a gateway.

[0082] The systems and methods disclosed herein offer numerous technical advantages over existing technologies. For example, automated systems using modular automated applications enable the flexible and efficient creation and deployment of complex solution structures. This technical advantage provides a business advantage in enabling the creation of automated systems in a more flexible and efficient manner, thereby responding to ever-changing market demands, time-to-market pressures, the continuous emergence of new technologies, and, most importantly, global competition.

[0083] The system orchestrator disclosed in the present invention allows for overall, system-wide control and coordination of the automation system's functionality beyond that of any single application within the automation system. Beyond the actual automation applications, aspects such as launching each application in the correct configuration on the correct hardware in a user-defined or system-defined order can be implemented solely using the disclosed system orchestrator. The system orchestrator operates to ensure that the automation system as a whole is less error-prone and more cost-effective. At runtime, the system orchestrator oversees each application and subsystem to ensure they are in a functional state. The system orchestrator verifies the operation and interaction of each of the applications (and gateways, if necessary) to ensure that the applications and the automation system as a whole are interconnected in the correct manner to fully support the automation system's functionality. In this way, the system orchestrator ensures that within the automation system, applications can communicate correctly and efficiently with each other, and that the automation system as a whole can communicate correctly and efficiently with external systems, devices, and processes.

[0084] Application repositories and system repositories (which include manifests and system / application configurations stored as discrete files) enable individual applications and systems to be versioned, shared, and deployed across multiple versions and variants.

[0085] By enforcing type and instance configuration for configuring automation objects, the disclosed embodiments ensure easy creation, distribution, and reuse of automation software. Separating the configuration of automation objects into separate artifacts—configuration and manifest—enables the design of industrial and other automation systems using flexible, modular, and distributed architectures. This approach also enables the linking and embedding of automation objects. Using configuration to specify the functional details of automation objects eliminates the need to recompile them during integration into industrial automation systems.

[0086] Of course, those skilled in the art will recognize that certain steps in the above processes may be omitted, performed simultaneously or sequentially, or performed in a different order unless the order of execution is specifically indicated or required.

[0087] Those skilled in the art will recognize that, for the sake of simplicity and clarity, the present disclosure does not depict or describe the complete structure and operation of all data processing systems suitable for use with the present disclosure. Instead, only the portions of the data processing system that are unique to the present disclosure or necessary for understanding the present disclosure are depicted and described. The remainder of the construction and operation of the data processing system 100 may conform to various current implementations and practices known in the art.

[0088] It is important to note that while the present disclosure includes a description in the context of a fully functional system, those skilled in the art will appreciate that at least portions of the mechanisms of the present disclosure can be distributed in the form of instructions embodied in a machine-usable, computer-usable, or computer-readable medium in any of a variety of forms, and that the present disclosure applies equally regardless of the particular type of instruction or signal-bearing medium or storage medium used to actually perform the distribution. Examples of machine-usable / readable or computer-usable / readable media include non-volatile, hard-coded type media such as read-only memory (ROM) or erasable electrically programmable read-only memory (EEPROM), and user-recordable type media such as floppy disks, hard drives, and compact disk read-only memories (CD-ROMs) or digital versatile disks (DVDs).

[0089] Although the exemplary embodiments of the present disclosure have been described in detail, those skilled in the art will understand that they can make various changes, substitutions, alterations, and improvements herein without departing from the spirit and scope of the disclosure in its broadest form.

[0090] Nothing in this application should be construed as implying that any particular element, step, or function is essential to the scope of the claims: the scope of patented subject matter is limited solely by the claims that issue. Furthermore, none of the claims should be construed as a "means-plus-function" type limitation unless the precise phrase "means for..." is followed by a participle. When terms such as (but not limited to) "mechanism," "module," "device," "unit," "component," "element," "member," "device," "machine," "system," "processor," or "controller" are used within the claims, they are understood and intended to refer to structures known to those skilled in the art that are further modified or enhanced by the features of the claims themselves.

Claims

1. A method for implementing an automation system (152), the method being performed by a data processing system (100) and comprising: Start (602) the system orchestrator (168); reading (604) the system configuration definition (156) and the system manifest (158) by the system orchestrator (168); Reading (606) application configuration definitions (156) and application manifests (158) of one or more applications (154) by the system orchestrator (168) based on the system configuration definition (156); defining (610) an application configuration definition (156) for one or more applications (154) based on the system configuration definition (156) by the system orchestrator (168); executing (614) the one or more applications (154) based on the application configuration definition (156) and the application manifest (158); as well as At least one external physical device (570) is controlled (618) by the automation system (152) based on one or more executed application programs (154).

2. The method according to claim 1, further comprising: A gateway (164) is created (616) by the system orchestrator (168).

3. The method according to claim 2, wherein: The at least one external physical device (570) is controlled via the gateway (164).

4. The method according to claim 1, further comprising: The system manifest (158) is updated (608) based on the application manifest (158) of the one or more applications (154).

5. The method according to claim 1, wherein The system orchestrator (168) controls the execution timing of individual applications among the one or more applications (154).

6. The method according to claim 1, wherein The system orchestrator (168) defines (612) connectors for the one or more applications (154).

7. The method according to claim 1, wherein The system orchestrator (168) defines (612) a virtual connector for at least one of the one or more applications (154).

8. The method according to claim 1, wherein Defining an application configuration definition (156) for one or more applications (154) includes defining multiple instances of the same application (154) using different application configuration definitions (156).

9. A data processing system (100), comprising: a processor (102), and Accessible to a memory (108), the data processing system is in particular configured to execute the method according to any one of claims 1 to 8.

10. A non-transitory computer-readable medium (126) encoded with executable instructions (162) that, when executed, cause one or more data processing systems (100) to perform the method of any one of claims 1 to 8.

Images