A supervisory device deployed with a separate application container for automated control procedures

Abstract

A system and method for supervisory and control support in an industrial automation system includes a supervisory device having a software stack having a host operating system and a plurality of independent application containers. Each container includes a modular application platform associated with basic functions of the supervisory device and a guest operating system layer integrated with the modular application platform according to system integration. A one-time integration of system dependencies is performed during container development. The independent application container is portable to be directly deployed in an operating system different from the type of the host operating system and can run unchanged without any changes to component artifacts.

Description

Technical Field

[0001] The present application relates to automation control. More specifically, the present application relates to a supervisory device deployed with an independent application container for an automation control program. Background Art

[0002] In the industrial automation industry, complex systems such as Supervisory Control and Data Acquisition (SCADA) are often deployed to supervise and support industrial or manufacturing processes involving multiple levels of various control systems consisting of devices such as multi-purpose programmable logic controllers (PLCs), embedded edge devices, headless gateways, human-machine interface (HMI) panels, industrial control computers (PCs), local servers, and cloud infrastructure devices. Such control systems can supervise and support physical systems of field devices such as conveyors, robotic tools, and various sensors that monitor industrial or manufacturing processes. To facilitate the monitoring function, the supervisory device is deployed with a software stack integrated into a specified operating system (OS), where the software stack consists of components that require complex integrated interdependencies. Both inter-component integration and component-to-OS integration are required.

[0003] Figure 1 An example of a typical software stack for supervisory devices in an industrial automation control system is shown. In this example of the overall stack 111, the connection to the field device 131 is handled by a connection layer 122 with various drivers. Next, looking up, the runtime layer 124 collects data from one or more field devices 131 and provides the collected data through a variety of services (e.g., real-time publish / subscribe (pub / sub), logging, alarms, etc.). A user 132 of the runtime service can operate a graphical user interface (GUI) client running in the visualization layer 126 to present the user 132 with an up-to-date overview of the manufacturing process. The visualization layer 126 can provide services for one or more rendering hosts and can include user-defined applications, such as edge applications. The disadvantage of deploying a monolithic stack is that once integrated, the components are merged and lose independence, so any required modifications to the subcomponents require a complete reintegration of all interdependencies from the beginning of the process.

[0004] With the advent of edge computing, fog computing, and cloud computing, any automation software stack (e.g., a human-machine interface (HMI) stack or a supervisory control and data acquisition (SCADA) stack) needs to be portable and versatile enough to be easily deployed in a variety of different target hardware platforms (e.g., multi-purpose programmable logic controllers (PLCs), embedded edge devices, headless gateways, HMI panels, industrial PCs, local servers, cloud infrastructure, etc.), each of which has a variety of software operating systems (e.g., different Linux-based operating systems, different distributions of common Linux-based operating systems).

[0005] The first revolutionary attempt to reduce the complexity of automation systems was to move from a monolithic software stack to a modular and more abstract software architecture. The advent of modularity made it possible to clearly draw boundaries between all layers and design more abstract components that can be reused across multiple product lines, enabling cross-module interaction through well-designed interfaces. While modularity undoubtedly marks a turning point for the industry, many issues remain unresolved. System integration remains a major challenge in situations where a complete software stack needs to be provided for a completely new operating system (for example, when existing supervisory equipment is scheduled to be updated to deploy a new version of an operating system or a different operating system, or when a completely new operating system is introduced to serve a new supervisory equipment as a modification or add-on to an industrial system).

[0006] Figure 2 An example of a modular software stack for a target device in industrial automation is shown. Currently, when a software stack 201 is provided for a new operating system installation in a device A with a hardware platform 271, each application module 210, including a runtime module 211, a visualization module 221, and other modules 231, must be separately deployed and integrated into the target operating system 261 to ensure system compatibility and runtime correctness. Figure 2As shown, the same set of modules 210 of the modular software stack 201 can be developed to be deployed in multiple devices running different operating systems, such as operating system 262 for device B with hardware platform 272 and operating system 263 for hardware platform 273 of another target device. For example, device A can run on operating system 261, which is a new replacement operating system. As another example, device A may be part of a new monitoring system being deployed, and each application module 210 needs to be integrated to run with the new device A and its operating system 261. Each module 210 used for integration is mainly composed of three sets of artifacts: executable binaries, libraries, and resources (e.g., configuration files, images). As part of system integration 251, the dependencies of the binaries, libraries, and resources of modules 211, 221, 231 on system libraries need to be established by installing to the correct location, and the configuration files must be set accordingly, where any inconsistency may result in undesirable runtime error behavior. Conventional methods require that each module 211, 221, 231 be integrated through an installer (i.e., an installation script) at the time of integration, which copies and installs all artifacts to the correct location in the system. However, binaries and libraries may depend on other artifacts, which are typically the responsibility of the target system to provide (e.g., OpenGL, XServer, C / C++ runtime libraries, Java / Python / NodeJS runtimes, etc.). Since component artifacts are built at different times and often by different development teams than when they are integrated into the target system, it is not uncommon for the target device to have the wrong versions of individual dependencies pre-installed. In some cases, no dependencies are pre-installed at all. Because each operating system 261, 262, 263 is treated uniquely with respect to its operating system or hardware configuration, system integration 251, 252, 253 requires multiple iterations to resolve dependencies and identify the best adaptation strategy for each target device. These difficulties can lead to runtime errors when the integration team misplaces artifacts during integration, as modules cannot find unimplemented dependencies or resources (e.g., configuration files, images, etc.).

[0007] Following system integration 251 is cross-module integration, through which individual modules 211, 221, 231 are integrated together to form the final software stack 201. In terms of overall system integration, there are significant challenges in addressing the inherent differences of each target operating system 261, 262, 263, which may affect how the various components of the modules 211, 221, 231 interact with each other (e.g., different OS distributions, system libraries, network configurations, memory configurations, file systems). Unless each individual module / layer explicitly supports it, the stack 201 is unlikely to be multi-OS compatible.

[0008] In summary, current automation and control programs are built with very complex software stacks that entail cumbersome integration and configuration processes. Portability of these programs cannot be achieved without overcoming inherent inefficiencies and lack of component modularity. Currently, deployment of automation software components in new operating systems is achieved through customized integration strategies that perfectly match the characteristics of the operating system platform (such as Microsoft Windows, Ubuntu, Debian, CentOS, etc.). Figure 3 An example of a flow chart of a development process for software components of an automation system is shown. System configuration 301 may include the configuration of resources (e.g., network, file system, memory) and the identification of required system dependencies. For example, a specific module execution may require the deployment of a Java runtime. For another example, a web server may require Node.JS to run. Another example is a rendering host that requires an OpenGL library to present content on a display screen. The resources of such modules can be allocated to be provided by the host system rather than being included in the application module. The determined dependencies must then be installed on the target system, with special attention paid to the version requirements of each individual system library to avoid runtime error behavior. In addition, the installed dependencies must be correctly configured so that the modules that need to use them can find them. These steps of system configuration 351 are usually performed as a manual process when each target system is integrated. After system configuration 301, as described above, each software module is integrated with the system integration 302 system. In order to integrate each module system into the operating system, it is then necessary to verify the component functionality through a set of predefined tests to ensure that no runtime error behavior is recorded. After all modules are integrated and verified, cross-module integration 303 is performed to connect all application modules to each other. This ensures proper configuration of the infrastructure (eg, networking) for inter-module communication.

[0009] While all of these steps are not necessary for every OS deployment, any one of them is extremely time consuming and there is a high likelihood of crashes and runtime misbehavior due to inconsistent or conflicting configurations that may be overlooked during the integration process. Part of the most advanced solution to this problem is to use an installer or installation script, which can simplify the installation process of the automation software stack across multiple devices. However, if the system is misconfigured, problems may still occur at runtime. In fact, the current integration process needs to be improved. Regarding cross-OS compatibility, current solutions can only handle this issue specifically at compile time by using a cross-OS framework (e.g., the Qt framework). There is currently no solution that can easily deploy the same automation software stack across multiple operating systems. Summary of the invention

[0010] According to aspects of an embodiment of the present disclosure, a supervisory device for supervisory and control support in an industrial automation system is included, wherein the supervisory device includes a processor, and a computer-readable medium on which a software stack including a host operating system is stored, and a plurality of independent application containers. Each container includes a modular application associated with the basic functions of the supervisory device and a plurality of components configured to perform sub-functions, respectively, wherein each component has an artifact, and the artifact includes a set of binary files, libraries, and resources. Each container also includes a guest operating system layer integrated with the artifact of the component, and the guest operating system is independent of the platform of the operating system. The software stack also includes a container daemon, which is configured to perform a one-time system integration between the guest operating system and the component artifact by generating a hierarchy of image layers during the development of each container to create a container image artifact for each container. For each container, the container daemon executes the container image artifact at runtime to integrate the container into the host operating system. The independent application container can be ported to be directly deployed in an operating system of a type different from the host operating system, and can run unchanged without any changes to the component artifact. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] Non-limiting and non-exhaustive embodiments of the present invention are described with reference to the following figures, wherein like reference numerals refer to like elements throughout the various figures unless otherwise specified.

[0012] Figure 1 A schematic diagram showing an example of a conventional overall software stack for industrial automation.

[0013] Figure 2 A schematic diagram showing an example of a general modular software stack for industrial automation.

[0014] Figure 3 A flow chart illustrating an example process for developing an industrial automation software component.

[0015] Figure 4 A schematic diagram illustrating an example of a supervisory device having a deployed software stack using standalone application containers according to an embodiment of the present disclosure is shown.

[0016] Figure 5 A schematic diagram showing a one-time system integration of an application container according to an embodiment of the present disclosure is shown.

[0017] Figure 6 A block diagram illustrating an example of a computing environment in which embodiments of the present disclosure may be implemented is shown.

[0018] Figure 7 A block diagram illustrating an example of an application container component configuration according to an embodiment of the present disclosure. DETAILED DESCRIPTION

[0019] The method and apparatus disclosed herein provide an improved software application system integration process for supervisory devices of industrial automation systems. Independent application containers are the product of a one-time system integration, rather than the product of separate system integration of modular applications for each target system platform. This avoids problems caused by the inherent differences that characterize each target system platform, because the disclosed container-based deployment process requires only a single integration that is independent of the final target operating system platform and abstract. A guest operating system component is introduced to be included in an independent application container, where the guest operating system is independent of the platform of the target operating system. The guest operating system for each container can be generated as a separate layer during the development phase of the application platform, and through a one-time integration with the application module, the container is ready to be deployed to a variety of host operating systems. At runtime, the container is integrated with the host operating system and handled by the container daemon application, avoiding troublesome configuration conflicts between the application module components and the host operating system. Therefore, the atomic application container is ready to execute "out-of-the-box" on any architecture-compatible platform that has a container daemon application installed.

[0020] Figure 4 A schematic diagram of an example of a supervisory device with a deployed container-based software stack using independent application containers according to an embodiment of the present disclosure is shown. The supervisory device 401 (e.g., an HMI unit) for an automated control system is shown with a software stack 451 deployed on a hardware platform 471 for cooperating with an interconnected control system (such as a remote client 461 (e.g., a web-based user interface) running on a remote host 462 hardware platform (e.g., a remote personal computer (PC)), or a controller 463 (e.g., a programmable logic controller) to implement monitoring functions. The software stack 451 may include a native application 402, a container daemon 403, an optional hypervisor 404, application containers 411, 421, 431, and a host operating system kernel 441.

[0021] In an embodiment, when developing a software stack for a supervisory device 401 given a target device 401 with a predetermined operating system, the technical problem to be solved is to avoid repeated system integration of the same application module when deploying to a new target device with a completely new operating system. To solve this technical problem, an application container is built and configured with application components that are fully system integrated with the guest operating system, which can be deployed on the target device memory and executed when the device is turned on.

[0022] The software stack 451 includes a plurality of native applications 402 (e.g., user applications and / or system applications) that can be developed and stored outside of any container. These native applications 402, which may include user and / or system applications, are directly integrated into the host operating system via an abstraction layer (not shown). A set of modular applications APP1, APP2, ..., APPn can be identified and assigned according to the corresponding basic functions of the supervisory device 401. For example, the first application module 413 may include components configured to perform runtime server functions as shown in Table 1. The second application module 423 may include components such as Figure 7 The components shown in FIG. 7 are configured to execute a web-based rendering host 710 to expose a user interface to a remote browser. In an embodiment, the application module 710 includes components: a rendering subsystem 712 and a rendering subsystem adapter 714 having a logical screen manager 715 and a channel manager 716. Back to Figure 4 , the third application module 433 may include components configured for visualization functions, such as executing a graphical user interface (GUI) rendering host (e.g., the rendering host may be implanted using a Qt framework application on a rich client platform), which exposes a user interface on a primary display (e.g., a display screen) of the supervisory device 401. As an example, Figure 7 A visualization core service (VCS) application module 720 is shown, which is configured to implement visualization functions through the following components: a domain logic manager 726, a screen logic manager 727, a component framework 728, and a VCS business logic component 721 having a rendering abstraction layer 722, an object model manager 723, a screen object model 724, an RDF processor 725, and a CDS loader 729.

[0023] Table 1

[0024]

[0025]

[0026]

[0027] In an embodiment, the development of application module containers can be assigned to development experts of corresponding application functions, so that the one-time integration of each container is handled by experts, which is different from the conventional system integration that is usually performed by a team of system integrators who are not involved in application development. Therefore, the integration and verification process can more effectively avoid mismatches in the configuration and interdependency of application components.

[0028] Each container includes a guest operating system 415, 425, 435, which is integrated with the artifacts of the application components and is independent of the platform of the target host operating system specified by the supervisory device 401. For example, the container 411 includes an application 413 with component artifacts such as binaries 412, libraries 414, and resources 416, all of which are integrated into the guest operating system 415. During the one-time system integration process between the guest operating system 415 and the component artifacts of the container performed by the container daemon 403, a hierarchy of image layers is generated during the development of each container to create a container image artifact for each container. This integration replaces the conventional integration with the target platform operating system (such as the operating system platform 471). Therefore, a separation is established between the guest operating system and the host operating system. In an embodiment, the guest operating system 415 can be defined during the container artifact image build. Due to the functionality of the container daemon 403, the selection of the type of the guest operating system 415 can be platform-independent. While the host operating system may be a complete Linux distribution, the guest operating system 415 may consist of a hierarchy of layers that are overlaid with the layers of the application 413 to form a merged file system package that is then installed on top of the host file system when the container daemon 403 launches the container 411. In addition, the guest operating system 415 and the host operating system may share the host operating system kernel 441.

[0029] The container daemon 403 provides functionality for the container both during the development phase and at runtime. During the development of the software stack 451, the container daemon 403 can build individual container image artifacts 411, 421, 431 for each application 413, 423, 433. The container daemon 403 includes program modules that perform system integration processes during the development phase, and other program modules (e.g., runtime managers) that execute container image artifacts during runtime during the operation phase. In an embodiment, a synthesizer module 405 and a coordinator module 406 can be used to implement multi-container integration and coordination, respectively. The synthesizer module 405 can perform bridging of multi-component applications so that application containers are started simultaneously. The interconnection between containers can be achieved through inter-process communication technology provided by the container runtime manager. For a software stack to be divided into multiple containers, a prerequisite can be defined so that the communication is divided at the container's demarcation line by using one of the multiple options provided, including network (e.g., TCP / IP), shared memory, or file mapping. For example, a configuration such as Figure 4The TCP / IP bridge network shown includes interfaces 417, 427, 437 and a host kernel interface 442. The coordinator module 406 can control the application life cycle of a single container or multiple containers through controllable startup and shutdown monitoring. For example, the coordinator module 406 can start a container in response to a user request and can monitor the container throughout the execution process. The coordinator 406 can be programmed to restart the container application in response to early termination. Therefore, the coordinator module 406 simplifies the startup procedure of container-based applications.

[0030] In an embodiment, the container daemon 403 is based on the way that the application is integrated with the guest operating system 415 to operate on the host operating system kernel 441, thereby increasing security and resource control. Containers 411, 421, and 431 can run directly on the host operating system kernel 441 without an additional abstraction layer. The host operating system kernel 441 may include a namespace kernel feature for implementing isolation between containers. For example, the namespace feature may specify which resource sets are visible to a specific process. Through the isolation between the application containers 411, 421, and 431, a process running in one container cannot see or affect the processes running in the remaining containers or on the host operating system kernel 441. The process groups in different namespaces are isolated from each other, so each process group can have a unique network stack, a dedicated mount point, a dedicated IPC (inter-process communication), and a separate process ID subset. For the network stack, the following embodiments can be implemented using the namespace feature through the container daemon 403. As a first option, a non-networking solution can be implemented so that each container is completely isolated and has no interface for talking to the outside world. As a second option, a host networking solution can be configured so that the container and the host operating system share the same network stack. From a network perspective, there is no isolation. As a third option, the dedicated networking solution configures the container networking and the host operating system to have different network stacks that are completely independent and can be interconnected using Linux concepts such as "veth pairs", "bridges" and "ip routing". In an embodiment, unless otherwise specified by the developer, the container daemon 403 can select the dedicated networking solution by default.

[0031] The host operating system kernel 441 may include a cgroups kernel feature for implementing resource control. For example, the cgroups feature may be configured to limit the amount of resources (e.g., CPU, memory, disk I / O, network, etc.) allocated to a particular process hierarchy.

[0032] As an optional feature, the software stack 451 may include a hypervisor component 404 or similar virtualization component configured to support interaction between the guest operating system 415 and the host operating system of different platform types. For example, in the case where the guest operating system 415 is selected to be based on Linux and the target device operating system is based on MS Windows, the hypervisor 404 is configured to operate to support overlaying the container image layer onto the host operating system at runtime.

[0033] Figure 5 A schematic diagram of a one-time system integration of an application container according to an embodiment of the present disclosure is shown. In an embodiment, a one-time integration 510 of native artifacts (such as libraries, binaries, and resource allocations) of an application 512 with a guest operating system 514 is performed during the coding development of the application 512. As a result of the one-time integration 510, a container image artifact 520 is built, which is platform-independent with various target operating systems 551, 552, 553, 554 (e.g., an OS for deployment on various target supervisory devices). In contrast, a repeated integration scheme 530 of native artifacts of an application 532 created by a development process without performing a one-time integration 510 according to an embodiment of the present disclosure requires repeated system integrations 501, each of which is required for a corresponding target operating system 551, 552, 553, 554. Another significant advantage of the container artifact 520 is the ease with which the atomic container can be updated to a newer version, such as when the application is required to support new features. For example, an application update can be reintegrated with the guest operating system 514 as a one-time integration 510 to produce an updated container image artifact 520. Examples of situations where an update to the application 512 is required include, but are not limited to, when new features or functionality need to be added to the application 512, when the latest vulnerability fixes need to be provided to the application 512, and when security patches are provided to the application 512. To perform an application update on all deployed platforms, the old container image artifact is discarded, replaced with the updated container image artifact 520, and the application is ready to execute without additional platform-specific integration. In contrast, updating the application 512 through conventional integration 501 requires updating each host platform on which the application is developed, where multiple platforms may have different operating systems 551, 552, 553, 554, different update mechanisms (scripts, installers, etc.), or may even have slightly different system libraries installed, which has not caused any problems so far. These inconsistencies can translate into lengthy update cycles that can easily lead to incorrect behavior or failures when executing the updated version of the application.

[0034] In an embodiment, the container daemon 403 can support container updates for both public and private image registries, which involves swapping out an old container with one, whether for a single container or for a group of affected containers. For example, a registry can be a server-side application that stores and distributes images across target devices. Developers can provide each new version by simply pushing it to the registry, from which the device container manager can extract it and store it locally. Due to the atomicity and abstraction of containers, multiple versions of the same container can coexist on the device, letting the system decide which version to launch at runtime.

[0035] Container-based application building and deployment as disclosed herein works in a completely transparent manner to real-time kernel features (e.g., FIFO / RR schedulers, real-time priorities), bringing similar determinism without any performance loss, such as additional execution time or quality degradation. In addition, the high portability of application containers extends to various operating systems. For example, Linux-based containers can run unchanged on any distribution of Linux-based or Windows-based host operating systems that can support container runtimes, making cross-operating system integration an instant process without making any changes to the application binary or its existing guest operating system integration. Portability provides a standardized execution environment, whereby the same container can run on various levels of automated control systems, where supervisory devices can be deployed in panels (e.g., HMI panels), edge devices (e.g., embedded SCADA devices), or cloud-based devices (cloud-based SCADA devices).

[0036] Container-based application building and deployment as disclosed herein also improves security benefits by providing better application isolation via a single container. For example, refer to Figure 4 , processes running in container 411 cannot see or affect processes running in other containers 421, 431 or in the host system kernel 441. In addition, unless otherwise specified, a dedicated networking configuration for a container may be selected as a default option.

[0037] An additional benefit of container deployment according to embodiments of the present disclosure is that resources are universally allocated to each container, which enables better allocation of resources across different system components.

[0038] Figure 6 An exemplary computing environment in which embodiments of the present disclosure may be implemented is shown. A computer system 610 is shown, which may be implemented as an HMI unit or other type of control system device for industrial automation as described above. Figure 6As shown, computer system 610 may include a communication mechanism such as a system bus 621 or other communication mechanism for communicating information within computer system 610. Computer system 610 also includes one or more processors 620 coupled to system bus 621 for processing information.

[0039] Processor 620 may include one or more central processing units (CPUs), graphics processing units (GPUs), or any other processors known in the art. In general, the processor described herein is a device for executing machine-readable instructions stored on a computer-readable medium to perform tasks, and may include any one or combination of hardware and firmware. The processor may also include a memory storing machine-readable instructions that can be used to perform tasks. The processor acts on information by operating, analyzing, modifying, converting, or transmitting information for use by an executable program or information device and / or by routing the information to an output device. The processor may, for example, use or include the capabilities of a computer, a controller, or a microprocessor, and use executable instructions to adjust to perform special functions that are not performed by a general-purpose computer. The 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), etc. In addition, processor 620 can have any suitable micro-architecture design, and it comprises any number of constituent components, such as register, multiplexer, arithmetic logic unit, cache controller, branch predictor etc. for controlling the read / write operation to cache memory.The micro-architecture design of processor can support any one in multiple instruction sets.Processor can be coupled (electrically coupled and / or coupled to comprise executable component) with any other processor that can interact and / or communicate between them.User interface processor or maker are the known elements that comprise electronic circuit or software or both combinations for generating display image or its part.User interface comprises one or more display images that enable user to interact with processor or other equipment.

[0040] The system bus 621 may include at least one of a system bus, a memory bus, an address bus, or a message bus, and may allow the various components of the computer system 610 to exchange information (e.g., data (including computer executable code), signaling, etc.). The system bus 621 may include, but is not limited to, a memory bus or a memory controller, a peripheral bus, an accelerated graphics port, etc. The system bus 621 may be associated with any suitable bus architecture, including, but not limited to, an industry standard architecture (ISA), a micro channel architecture (MCA), an enhanced ISA (EISA), a video electronics standard association (VESA) architecture, an accelerated graphics port (AGP) architecture, a peripheral component interconnect (PCI) architecture, a PCI-Express architecture, a personal computer memory card international association (PCMCIA) architecture, a universal serial bus (USB) architecture, and the like.

[0041] Continue to refer Figure 6 , the computer system 610 may also include a system memory 630 coupled to the system bus 621 for storing information and instructions to be executed by the processor 620. The system memory 630 may include computer-readable storage media in the form of volatile and / or non-volatile memory, such as a read-only memory (ROM) 631 and / or a random access memory (RAM) 632. RAM 632 may include other dynamic storage devices (e.g., dynamic random access memory, static RAM, and synchronous DRAM). ROM 631 may include other static storage devices (e.g., programmable ROM, erasable PROM, and electrically erasable PROM). In addition, the system memory 630 may be used to store temporary variables or other intermediate information during the execution of instructions by the processor 620. A basic input / output system (BIOS) 633 containing basic routines that help transfer information between elements within the computer system 610 (e.g., during startup) may be stored in ROM 631. RAM 632 may contain data and / or program modules that are immediately accessible to and / or currently being operated by the processor 620. As shown, software stack 639 may include operating system 634 , containerized applications 635 , and other program modules 636 .

[0042] The operating system 634 may be loaded into the memory 630, retrieved from the memory 640, and may provide an interface between other application software executed on the computer system 610 and the hardware resources of the computer system 610. More specifically, the operating system 634 may include a set of computer executable instructions for managing the hardware resources of the computer system 610 and for providing common services to other applications (e.g., managing memory allocations between various applications). In certain example embodiments, the operating system 634 may control the execution of one or more program modules 636 or other program modules (not shown) stored in the data storage device 640. The operating system 634 may include any operating system now known or that 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.

[0043] The containerized application 635 may include a set of computer executable instructions for performing basic functions of the automated control process, which is the basis for defining any specific application container as described above. According to an embodiment of the present disclosure, each containerized application 635 can run independently and can interface with other applications in the containerized application 635.

[0044] The computer system 610 may also include a disk / media controller 643, which is coupled to the system bus 621 to control one or more storage devices for storing information and instructions, such as a hard disk 641 and / or a removable media drive 642 (e.g., a floppy disk drive, an optical drive, a tape drive, a flash drive, and / or a solid-state drive). The storage device 640 may be added to the computer system 610 using an appropriate device interface (e.g., a small computer system interface (SCSI), an integrated device electronics (IDE), a universal serial bus (USB), or FireWire). According to an embodiment of the present disclosure, the storage devices 641, 642 may be external to the computer system 610 and may be used to store image processing data.

[0045] The computer system 610 may also include a display controller 665, which is coupled to the system bus 621 to control a display or monitor 666, such as a cathode ray tube (CRT) or a liquid crystal display (LCD), for displaying information to a computer user. The computer system 610 includes a user input interface 660 and one or more input devices, such as a user terminal 661, which may include a keyboard, a touch screen, a tablet computer and / or a pointing device, for interacting with a computer user and providing information to the processor 620. The user terminal 661 may provide a touch screen interface. The display 666 and / or the user terminal 661 may be provided as separate devices, or as part of a single independent unit enclosing the computer system 610.

[0046] The computer system 610 may perform some or all of the processing steps of an embodiment of the present invention in response to the processor 620 executing one or more sequences of one or more instructions contained in a memory such as a system memory 630. Such instructions may be read into the system memory 630 from another computer-readable medium (such as a hard disk 641 or a removable media drive 642). The hard disk 641 may contain one or more data stores and data files used by embodiments of the present invention. The data stores may include, but are not limited to, databases (e.g., relational databases, object-oriented databases, etc.), file systems, flat files, distributed data stores where data is stored on more than one node of a computer network, peer-to-peer network data stores, etc. The processor 620 may also be used in a multiprocessing device to execute one or more sequences of instructions contained in the system memory 630. In an alternative embodiment, hardwired circuits may be used in place of or in conjunction with software instructions. Therefore, the embodiments are not limited to any particular combination of hardware circuits and software.

[0047] As described above, the computer system 610 may include at least one computer-readable medium or memory for storing instructions programmed according to embodiments of the present 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 processor 620 for execution. Computer-readable media can take a variety of forms, including but not limited to non-temporary, 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 hard disks 641 or removable media drives 642. Non-limiting examples of volatile media include dynamic memory, such as system memory 630. Non-limiting examples of transmission media include coaxial cables, copper wires, and optical fibers, including wires that make up the system bus 621. Transmission media can also take the form of sound waves or light waves, such as those generated during radio wave and infrared data communications.

[0048] The computer-readable medium instructions for performing the operation of the present disclosure can be source code or object code written in any combination of assembly instructions, instruction set architecture (ISA) instructions, machine instructions, machine-related instructions, microcode, firmware instructions, state setting data or one or more programming languages, including object-oriented programming languages ​​such as Smalltalk, C++ and conventional program programming languages ​​such as "C" programming language or similar programming languages. Computer-readable program instructions can be executed completely on the user's computer, partly on the user's computer, as an independent software package, partly on the user's computer, partly on a remote computer or completely on a remote computer or server. In the latter case, the remote computer can 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 can be connected to an external computer (for example, using an Internet service provider through the Internet). In certain embodiments, the electronic circuit including, for example, a programmable logic circuit, a field programmable gate array (FPGA) or a programmable logic array (PLA) can execute computer-readable program instructions to personalize the electronic circuit by utilizing the state information of the computer-readable program instructions, so as to perform various aspects of the present disclosure.

[0049] Various aspects of the present disclosure are described herein with reference to flowcharts and / or block diagrams of methods, devices (systems) and computer program products according to embodiments of the present disclosure. It should be understood that each block of the flowchart and / or block diagram and the combination of blocks in the flowchart and / or block diagram can be implemented by computer-readable medium instructions.

[0050] The computing environment 600 may also include a computer system 610 operating in a network environment using logical connections to one or more remote computers, such as a remote computing device 680. The network interface 670 may enable, for example, communication with other remote devices 680 or systems and / or storage devices 641, 642 via a network 671. The remote computing device 680 may be a personal computer (laptop or desktop), a mobile device, an embedded edge device, a web-based server, a gateway, a router, a network PC, a peer device, or other public network node, typically including many or all of the elements described above with respect to the computer system 610. When used in a networked environment, the computer system 610 may include a modem 672 for establishing communications via a network 671, such as the Internet. The modem 672 may be connected to the system bus 621 via the user network interface 670 or via another appropriate mechanism.

[0051] The network 671 can be any network or system well 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 a series of connections, a cellular telephone network, or any other network or medium that can facilitate communication between the computer system 610 and other computers (e.g., remote computing device 680). The network 671 can be wired, wireless, or a combination thereof. The wired connection can be implemented using Ethernet, a universal serial bus (USB), RJ-6, or any other wired connection well known in the art. The wireless connection can be implemented using Wi-Fi, WiMAX, and Bluetooth, infrared, cellular networks, satellites, or any other wireless connection methods well known in the art. In addition, several networks can work alone or communicate with each other to facilitate communication in the network 671.

[0052] It should be understood that Figure 6 The program modules, applications, computer executable instructions, codes, etc., depicted as stored in system memory 630 are merely illustrative and not exhaustive, and the processing described as supported by any particular module may be distributed across multiple modules or performed by different modules. In addition, various program modules, scripts, plug-ins, application programming interfaces (APIs), or any other suitable computer executable code hosted locally on computer system 610, remote devices 680, and / or hosted on other computing devices accessible via one or more networks 671 may be used to support, for example, Figure 6 The functions and / or additional or alternative functions provided by the program modules, applications or computer executable codes depicted in the embodiment. In addition, the functions can be divided into different modules, so that the functions described as being provided by Figure 6 The processing collectively supported by the collection of program modules depicted in the description may be performed by a fewer or greater number of modules, or the functionality described as supported by any particular module may be supported at least in part by another module. In addition, the program modules supporting the functionality described herein may form part of one or more application programs that may be executed across any number of systems or devices according to any suitable computing model (e.g., client-server model, peer-to-peer model, etc.). In addition, the functions described as being supported by Figure 6 Any functionality supported by any program module depicted in the may be implemented at least in part in hardware and / or firmware across any number of devices.

[0053] As used herein, an executable application includes code or machine-readable instructions for regulating a processor to implement predetermined functions in response to user commands or inputs, such as those of an operating system, a contextual data acquisition system, or other information processing system. An executable program is a section of code or machine-readable instructions, a subroutine, or other different code segments or portions of an executable application that are used to perform one or more specific processes. These processes may include receiving input data and / or parameters, performing operations on received input data, and / or performing functions in response to received input parameters, and providing resulting output data and / or parameters.

[0054] The functions and process steps herein may be automatically or fully or partially executed in response to user commands. Automatically executed activities (including steps) are executed in response to one or more executable instructions or device operations without the user directly initiating the activity.

[0055] The systems and processes of the accompanying drawings are not exclusive. Other systems, processes, and menus may be obtained according to the principles of the present invention to achieve the same goals. Although the present invention has been described with reference to specific embodiments, it should be understood that the embodiments and variations shown and described herein are for illustrative purposes only. Without departing from the scope of the present invention, modifications to the current design may be implemented by those skilled in the art. As described herein, various systems, subsystems, agents, managers, and processes may be implemented using hardware components, software components, and / or combinations thereof. Any claim element herein shall not be interpreted according to the provisions of 35 USC 112(f) unless the element is explicitly described using the phrase "device for..."

Claims

1. A supervisory device for supervisory and control support in an industrial automation system, the supervisory device comprising: processor; and A computer-readable medium having stored thereon a software stack executable by a processor, the software stack comprising a host operating system, a plurality of independent application containers, and a container daemon, wherein each container comprises a modular application and a guest operating system layer, wherein the modular application is associated with a basic function of the supervisory device and comprises a plurality of components, each component being configured to perform a sub-function, wherein each component has an artifact, the artifact comprising a set of binaries, libraries, and resources; wherein the guest operating system layer is integrated with the artifacts of the plurality of components, wherein the guest operating system is independent of the platform of the operating system, wherein the container daemon is configured to perform a one-time system integration between the guest operating system and component artifacts by generating a hierarchy of image layers during the development of each container to create a container image artifact for each container; wherein, for each container, the container daemon executes the container image artifact at runtime to integrate the container into the host operating system; wherein the independent application container can be ported to be directly deployed in an operating system of a different type from the host operating system and can run unchanged without making any changes to the component artifact.

2. The monitoring device according to claim 1, wherein: Each of the independent application containers includes: A container interface, used to network with another container interface; The container daemon integrates each container into the guest operating system to operate on the host operating system, and uses a namespace kernel feature to isolate between the containers according to a networking scheme.

3. The monitoring device according to claim 2, wherein: The namespace kernel feature specifies a set of resources visible to a specific process group and isolates process groups in different namespaces by allocating a unique network stack, dedicated mount points, dedicated IPC inter-process communication, and a separate subset of process IDs to each process group.

4. The monitoring device according to claim 1, wherein: The container daemon includes a compositor module configured to perform bridging of multi-component applications so that the multiple independent application containers are started simultaneously.

5. The monitoring device according to claim 4, wherein: The container daemon also includes an orchestrator module configured to schedule, proactively monitor, and restart container applications in response to premature termination.

6. The monitoring device according to claim 1, wherein: The supervision device is implemented as a panel device, an edge device, or a cloud-based device.

7. The monitoring device according to claim 1, wherein: At least one of the modular applications includes a component for performing runtime server functionality in the automation system.

8. The monitoring device according to claim 1, wherein: At least one of the modular applications includes a component for executing a web-based rendering host to expose a user interface to a remote browser.

9. The monitoring device according to claim 1, further comprising a display, wherein: At least one of the modular applications includes a component for performing a visualization function that exposes a user interface on the display.

10. A computer-implemented method for a supervisory device of an industrial automation system, the method comprising: building a software stack of a host operating system, the software stack comprising a plurality of independent application containers and a container daemon, wherein each container comprises a modular application and a guest operating system layer, wherein the modular application is associated with a basic function of the supervisory device and comprises a plurality of components, each component being configured to perform a sub-function, wherein each component has an artifact, the artifact comprising a set of binaries, libraries, and resources; and the guest operating system layer is integrated with the artifacts of the plurality of components, wherein the guest operating system is platform-independent of the operating system; performing, by the container daemon, a one-time system integration between the guest operating system layer and component artifacts by generating a hierarchy of image layers during development of each container to create a container image artifact for each container; The container image artifacts are executed by the container daemon at runtime to integrate each container into the host operating system; wherein the independent application container is portable to be directly deployed in an operating system of a different type than the host operating system and can run unchanged without any changes to component artifacts.

11. The method according to claim 10, further comprising: identifying an update request for one of the modular applications; performing a one-time integration of the guest operating system with the application to build an updated container; as well as The container is replaced with the updated container.

12. The method according to claim 10, further comprising: Networking with another container interface through a container interface; as well as Each container is integrated into the guest operating system by the container daemon to run on the host operating system, and a namespace kernel feature is used to isolate between the containers according to a networking scheme.

13. The method according to claim 12, wherein: The namespace kernel feature specifies a set of resources visible to a specific process group and isolates process groups in different namespaces by allocating a unique network stack, dedicated mount points, dedicated IPC inter-process communication, and a separate subset of process IDs to each process group.

14. The method according to claim 10, further comprising: The container daemon process performs bridging of the multi-component application so that the multiple independent application containers are started simultaneously.

15. The method according to claim 10, further comprising: Container applications are scheduled, proactively monitored, and restarted by the container daemon in response to premature termination.

Images