WO2022123803A1 - 制御システムおよび制御方法 - Google Patents

制御システムおよび制御方法 Download PDF

Info

Publication number
WO2022123803A1
WO2022123803A1 PCT/JP2021/008916 JP2021008916W WO2022123803A1 WO 2022123803 A1 WO2022123803 A1 WO 2022123803A1 JP 2021008916 W JP2021008916 W JP 2021008916W WO 2022123803 A1 WO2022123803 A1 WO 2022123803A1
Authority
WO
WIPO (PCT)
Prior art keywords
container
plc
server
runtime
control
Prior art date
Application number
PCT/JP2021/008916
Other languages
English (en)
French (fr)
Inventor
弓束 重森
Original Assignee
オムロン株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by オムロン株式会社 filed Critical オムロン株式会社
Priority to US18/039,653 priority Critical patent/US20240004688A1/en
Priority to EP21902910.5A priority patent/EP4261631A1/en
Priority to CN202180078958.0A priority patent/CN116490830A/zh
Publication of WO2022123803A1 publication Critical patent/WO2022123803A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G—PHYSICS
    • G05—CONTROLLING; REGULATING
    • G05B—CONTROL OR REGULATING SYSTEMS IN GENERAL; FUNCTIONAL ELEMENTS OF SUCH SYSTEMS; MONITORING OR TESTING ARRANGEMENTS FOR SUCH SYSTEMS OR ELEMENTS
    • G05B19/00—Programme-control systems
    • G05B19/02—Programme-control systems electric
    • G05B19/04—Programme control other than numerical control, i.e. in sequence controllers or logic controllers
    • G05B19/05—Programmable logic controllers, e.g. simulating logic interconnections of signals according to ladder diagrams or function charts
    • G05B19/056—Programming the PLC
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F8/00—Arrangements for software engineering
    • G06F8/60—Software deployment
    • G06F8/61—Installation
    • G06F8/63—Image based installation; Cloning; Build to order
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45562—Creating, deleting, cloning virtual machine instances
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F9/00—Arrangements for program control, e.g. control units
    • G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
    • G06F9/44—Arrangements for executing specific programs
    • G06F9/455—Emulation; Interpretation; Software simulation, e.g. virtualisation or emulation of application or operating system execution engines
    • G06F9/45533—Hypervisors; Virtual machine monitors
    • G06F9/45558—Hypervisor-specific management and integration aspects
    • G06F2009/45595—Network integration; Enabling network access in virtual machine instances

Definitions

  • the present invention relates to a control system including a control device and a server, and a control method in the control system.
  • a series of work such as design, implementation, and verification is required.
  • the control device and the device are combined after designing, mounting, and verifying the control device alone.
  • it is necessary to complete the work for each control device but it is difficult to make the work progress the same due to the complexity and characteristics of each control device. Therefore, due to variations in work progress, a waiting time may occur before the system is combined.
  • Patent Document 1 discloses a method for managing computer cloud resources.
  • One object of the present invention is to provide a solution to meet such a demand.
  • a control system including one or more control devices and one or more servers.
  • the control system is for a generator module that creates a container containing a runtime image containing a user program that defines a control operation for a controlled object and an execution environment that executes the user program, and one or both of the control device and the server.
  • the controller and server have a container engine that deploys the container, and by deploying the container released by the orchestrator, an instance of the runtime is created and the control operation is executed.
  • the container containing the image of the runtime can be deployed and executed by either the control device or the server, it is possible to facilitate the verification of the execution of the control operation even in the absence of the control device. It is also possible to easily move the control operation executed on the server to the control device.
  • the server container engine may generate an instance of the emulator that emulates the input / output data exchanged with the controlled object together with the instance of the runtime. According to this configuration, even if there is no device connected to the control device, it is possible to easily verify the control operation on the server.
  • the container engine of the server creates an instance of the runtime
  • the container engine of the controller creates an instance of the network server that mediates the input / output data exchanged through the device connected to the controller to the server. good.
  • the control operation itself can be executed by the server while using the I / O data exchanged with the device connected to the control device, so that the resources provided by the server can be used.
  • the server's container engine may create an instance of a virtual I / O driver that emulates the I / O driver responsible for accessing the device connected to the controller. .. According to this configuration, it is possible to provide an execution environment that is substantially the same as executing a control operation on a control device, so that a runtime for realizing the control operation can be commonly used in the server.
  • the container may include at least one of an image deployed only by the container engine of the control device and an image deployed only by the container engine of the server. According to this configuration, by including the image redundantly in the container, the control operation can be realized regardless of the deployment destination.
  • the control system may further include a repository that manages the address for accessing the container engine of the server when the container engine of the server creates an instance of the runtime. According to this configuration, when executing a control operation on the server, the difference in the address assigned to the execution environment can be absorbed by referring to the repository.
  • control system may further include a node manager that virtually creates a node including the container engine if the container engine for deploying the container does not exist. According to this configuration, a node that executes a control operation can be arbitrarily generated in response to a request.
  • the control system may further include a container hub that registers the container generated by the generation module in association with the identification information of the releaseable controller. This configuration facilitates the reuse of once created containers.
  • the orchestrator may select the container to be released and determine the release destination according to the user operation. With this configuration, the user can release the required container to the required execution environment depending on the situation of the control system.
  • a control method executed in a control system including one or more control devices and one or more servers.
  • the control method is for one or both of the step of creating a container containing a runtime image containing the user program that defines the control operation for the controlled object and the execution environment that executes the user program. Includes steps to release the container.
  • the control unit and server have a container engine that deploys a container, and by deploying a released container, an instance of the runtime is generated and a control operation is executed.
  • the resources of the controller can be made available in a scalable manner.
  • FIG. 12A It is a schematic diagram which outlines an example of another processing procedure in the use case shown in FIG. 12A. It is a schematic diagram which outlines an example of the processing procedure in the use case shown in FIG. 12B. It is a schematic diagram which outlines an example of another processing procedure in the use case shown in FIG. 12B. It is a schematic diagram which outlines an example of the processing procedure in the use case shown in FIG. 12C. It is a flowchart which shows an example of the processing procedure about the generation of PLC run-time container in the control system which follows this embodiment. It is a flowchart which shows an example of the processing procedure about release and execution management of PLC run-time container in the control system which follows this embodiment.
  • FIG. 1 is a schematic diagram showing an overall configuration example of the control system 1 according to the present embodiment.
  • the control system 1 according to the present embodiment is referred to as one or a plurality of PLC systems 2-1, 2, 2-3 (hereinafter, also collectively referred to as “PLC system 2”).
  • PLC system 2 includes one or more servers 200 and a development / maintenance terminal 300.
  • the related components are referred to as "-1", "-2" and "-3". In some cases, a subscript such as is added.
  • Each of the PLC systems 2 is also referred to as a line and may control the entire factory or may control specific manufacturing equipment or manufacturing equipment installed in the factory.
  • the PLC systems 2-1, 2, 2-3 are the main components of the PLC (Programmable Logic Controller) 100-1, 100-2, 100-3 (Programmable Logic Controller) 100-1, 100-2, 100-3, which is a typical example of a control device that controls a control target. Hereinafter, it is also collectively referred to as “PLC100”).
  • the PLC 100 is connected to the field device 10.
  • the field device 10 includes any device necessary for controlling a controlled object. More specifically, the field device 10 includes a device for exchanging information with a controlled object (for example, a manufacturing facility, a manufacturing device, a sensor and an actuator included in the manufacturing facility or the manufacturing device). In the example shown in FIG. 1, the field device 10 includes a remote I / O (Input / Output) 12, a relay group 14, a servo driver 16, and a servomotor 18.
  • I / O Input / Output
  • the PLC 100 acquires information from the field device 10 and executes a control operation according to a user program created in advance to generate information given to the field device 10.
  • the information acquired by the PLC 100 from the field device 10 is also referred to as “input data”, and the information given to the field device 10 is also referred to as “output data”.
  • input data and output data are also collectively referred to as "input / output data" or "I / O data”.
  • the PLC 100 and the field device 10 are connected via the control system network 4, but the present invention is not limited to this, and the PLC 100 may be connected by a hard wire.
  • the field device 10 is not limited to the device shown in FIG. 1, and may include any device.
  • EtherCAT registered trademark
  • EtherNet / IP registered trademark
  • DeviceNet registered trademark
  • CompoNet registered trademark
  • Each of the PLC systems 2 can access the server 200 existing on the Internet 8 via the information system network 6 and the gateway 20.
  • the information system network 6 a general-purpose communication protocol such as Ethernet (registered trademark) may be adopted.
  • the server 200 manages the release of the container while providing an environment in which the container can be deployed and executed.
  • the "release" of a container includes a process of providing a target container to an execution destination and a process of instructing execution at the execution destination (for example, a process of instructing deployment). Details of these processes and functions will be described later.
  • the server 200 may be arranged on the cloud via the Internet 8 or may be arranged in the local network where the PLC system 2 exists without going through the Internet 8.
  • the implementation form of the server 200 can be arbitrarily determined according to the required performance and functions.
  • the development / maintenance terminal 300 can access the server 200 and perform user operations for realizing various processes as described later.
  • FIG. 2 is a diagram for explaining an outline of processing using a container in the control system 1 according to the present embodiment.
  • PLC runtime the programs and libraries required to execute control operations on the PLC100 of the PLC system 2 are referred to as "PLC runtime".
  • PLC runtime may include an entity that realizes a control operation and an execution environment, in addition to a program and a library necessary for executing the control operation.
  • the "PLC runtime” is a user program (for example, a program arbitrarily created according to IEC61131-3) that defines a control operation for a control target by the PLC 100, and a PLC engine that is an execution environment for executing the user program. Includes (firmware).
  • a PLC runtime packaged so that it can be realized not only in the PLC 100 but also in the virtual environment provided by the server 200 is referred to as a "PLC runtime container".
  • PLC runtime container By deploying the "PLC runtime container” to the host OS (Operating System), it is possible to realize a logically independent application execution environment.
  • the term "PLC runtime container” may include the execution environment of the realized application. Details of the programs (applications) and libraries that make up the "PLC runtime container”, details of how to generate the "PLC runtime container", and the like will be described later.
  • the PLC runtime container 50 can be released to either the PLC 100 of the PLC system 2 or the server 200.
  • the deployment destination and deployment contents of the PLC runtime container 50 can be realized.
  • FIG. 3 is a diagram for explaining a mode provided in the control system 1 according to the present embodiment.
  • the local execution mode corresponds to a state in which the PLC 100 executes a control operation using the I / O data exchanged via the field device 10. More specifically, the PLC 100 has a PLC runtime 510 and a physical I / O 160.
  • the physical I / O 160 is an abstracted layer that also includes the field device 10 and the control network 4 (both see FIG. 1).
  • the local execution mode corresponds to so-called actual operation.
  • (2) the cloud execution mode exchanges I / O data via the field device 10 connected to the PLC 100, while the control operation itself is executed by the server 200.
  • the physical I / O 160 is realized in the PLC 100
  • the PLC runtime 510 is realized in the server 200.
  • the cloud execution mode can be used for actual operation, or can be used for developing or checking a user program.
  • the simulation mode does not require the field device 10 connected to the PLC 100, and the server 200 also emulates the field device 10 while the server 200 also executes control operations.
  • the PLC runtime 510 and the virtual I / O emulator 550 are realized in the server 200.
  • the virtual I / O emulator 550 is a module that emulates the behavior of the physical I / O 160.
  • the simulation mode can be used for developing and checking user programs.
  • control system 1 by using the PLC runtime container 50, it is easy to develop and check the user program even if a part or all of the PLC system 2 does not exist. In addition to being able to do this, it is also possible to seamlessly move to actual operation.
  • FIG. 4 is a block diagram showing a hardware configuration example of the PLC 100 constituting the control system 1 according to the present embodiment.
  • the PLC 100 includes a processor 102 such as a CPU (Central Processing Unit) and an MPU (Micro-Processing Unit), a chip set 104, a main memory 106, a storage 110, and an information system network controller 120.
  • a control system network controller 122 a USB (Universal Serial Bus) controller 124, and a memory card interface 126.
  • USB Universal Serial Bus
  • the processor 102 realizes a control operation for controlling a controlled object by reading various programs stored in the storage 110, expanding them in the main memory 106, and executing the programs.
  • the chipset 104 controls data transmission and the like between the processor 102 and each component.
  • the storage 110 typically stores an OS 112 for realizing basic processing and a system program 114 for performing processing such as deploying a PLC runtime container.
  • the information system network controller 120 controls the exchange of data with the development / maintenance terminal 300 or the like via the information system network 6.
  • the USB controller 124 controls the exchange of data with an external device (for example, a support device) via a USB connection.
  • an external device for example, a support device
  • the memory card interface 126 is configured so that the memory card 128 can be attached and detached, and data can be written to the memory card 128 and various data (user programs, trace data, etc.) can be read from the memory card 128. There is.
  • FIG. 4 shows a configuration example in which the necessary processing is provided by the processor 102 executing the program, and a part or all of the provided processing is provided by a dedicated hardware circuit (for example, ASIC). It may be implemented using (Application Specific Integrated Circuit) or FPGA (Field-Programmable Gate Array). Alternatively, the main part of the PLC 100 may be realized by using hardware that follows a general-purpose architecture (for example, an industrial personal computer based on a general-purpose personal computer). In this case, virtualization technology may be used to execute a plurality of OSs having different uses in parallel, and to execute necessary applications on each OS.
  • a general-purpose architecture for example, an industrial personal computer based on a general-purpose personal computer.
  • virtualization technology may be used to execute a plurality of OSs having different uses in parallel, and to execute necessary applications on each OS.
  • FIG. 5 is a block diagram showing a hardware configuration example of the server 200 constituting the control system 1 according to the present embodiment.
  • the server 200 includes one or more processors 202 such as a CPU or MPU, a main memory 206, a storage 210, one or more network controllers 220, an input unit 226, and a display unit 228. And include. These components are connected via bus 208.
  • the processor 202 realizes various processes as described later by reading various programs stored in the storage 210, expanding them in the main memory 206, and executing the programs.
  • the storage 210 is composed of, for example, an HDD (Hard Disk Drive) or an SSD (Flash Solid State Drive).
  • the storage 210 typically stores an OS 212 for realizing basic processing and a container application 214 for realizing various processing provided by the server 200 as described later.
  • the network controller 220 controls the exchange of data with various devices via the network.
  • the input unit 226 is composed of a keyboard, a mouse, etc., and receives instructions from the user.
  • the display unit 228 is composed of a display or the like, and outputs a processing result or the like from the processor 202.
  • FIG. 5 shows a configuration example in which the necessary processing is provided by the processor 202 executing the program, and a part or all of the provided processing is provided by a dedicated hardware circuit (for example, ASIC). Alternatively, it may be implemented using FPGA or the like).
  • FIG. 6 is a block diagram showing a hardware configuration example of the development / maintenance terminal 300 constituting the control system 1 according to the present embodiment.
  • the development / maintenance terminal 300 includes a processor 302 such as a CPU and an MPU, a main memory 306, a storage 310, a network controller 320, a USB controller 324, an input unit 326, and a display unit 328. including. These components are connected via bus 308.
  • the processor 302 reads various programs stored in the storage 310, expands them in the main memory 306, and executes them to realize the processing required by the development / maintenance terminal 300.
  • the storage 310 is composed of, for example, an HDD or an SSD.
  • the storage 310 typically stores an OS 312 and a development program 314 for instructing a process as described later.
  • a necessary program other than the program shown in FIG. 6 may be stored in the storage 310.
  • the network controller 320 controls the exchange of data with the PLC 100 or the like via an arbitrary control system network 4.
  • the USB controller 324 controls the exchange of data with an external device via a USB connection.
  • the input unit 326 is composed of a mouse, keyboard, touch panel, etc., and receives instructions from the user.
  • the display unit 228 is composed of a display, various indicators, and the like, and outputs a processing result from the processor 202 and the like.
  • the development / maintenance terminal 300 may have an optical drive 304.
  • the optical drive 304 reads a program from a recording medium 305 (for example, an optical recording medium such as a DVD (Digital Versatile Disc)) that temporarily stores a computer-readable program, and stores the program in a storage 310 or the like.
  • a recording medium 305 for example, an optical recording medium such as a DVD (Digital Versatile Disc)
  • DVD Digital Versatile Disc
  • Various programs executed by the development / maintenance terminal 300 may be installed via a computer-readable recording medium 305, but may also be installed by downloading from any server on the network.
  • FIG. 6 shows a configuration example in which the necessary processing is provided by the processor 302 executing the program, and a part or all of the provided processing is provided by a dedicated hardware circuit (for example, ASIC). Alternatively, it may be implemented using FPGA or the like).
  • FIG. 7 is a schematic diagram showing an example of the functional configuration in the control system 1 according to the present embodiment.
  • each of the PLCs 100 has a container engine 150.
  • the container engine 150 provides an execution environment for a container, deploys an image of a module based on a manifest included in the PLC runtime container 50, and generates a module (instance) for executing a process. ..
  • the server 200 has a container engine 250, a container generation module 260, and an orchestrator 270.
  • the container engine 250 deploys an image of the module based on the manifest included in the PLC runtime container 50 and generates a module (instance) for executing the process.
  • the container engines 150 and 250 are the basis of Software as a Service (CaaS). In the context of releasing the PLC runtime container 50, each of the container engines 150 and 250 may be referred to as a "node”.
  • the container generation module 260 generates the PLC runtime container 50 according to the user operation.
  • the container generation module 260 generates a PLC runtime container 50 including an image of the PLC runtime from a user program to be executed by the PLC 100 and related setting information. That is, the container generation module 260 generates a PLC runtime container 50 including an image of a PLC runtime including a user program that defines a control operation for a controlled object and an execution environment for executing the user program.
  • the orchestrator 270 is in charge of the process of managing the PLC runtime container 50.
  • the orchestrator 270 performs processing such as registering the PLC runtime container 50 generated by the container generation module 260 in the container hub, and any one of the PLC runtime containers 50 registered in the container hub according to a user operation or the like.
  • the host in the present embodiment, the container engine 150 of the PLC 100 or the container engine 250 of the server 200 manages whether to execute the process.
  • the orchestor 270 releases the PLC runtime container 50 to one or both of the PLC 100 and the server 200.
  • the PLC 100 and the server 200 have container engines 150 and 250 for deploying the PLC runtime container 50, respectively, and generate an instance of the PLC runtime image by deploying the PLC runtime container 50 released by the orchestrator 270. And execute the control operation.
  • the orchestrator 270 manages the start / stop of the PLC runtime container 50, manages the network connection between hosts, manages the storage, schedules the host to execute the PLC runtime container 50, and executes the PLC runtime container 50 on the host. Responsible for status management, etc.
  • the PLC runtime container 50 may be released by the orchestrator 270 according to a predetermined schedule, or the PLC runtime container 50 to be released may be selected and the release destination may be determined according to the user operation.
  • FIG. 8 is a schematic diagram showing a functional configuration example for realizing the mode provided in the control system 1 according to the present embodiment.
  • the PLC 100 has a local OS 140 and a container engine 150.
  • an instance of PLC runtime 510 is generated on the container engine 150. Further, the PLC 100 is also provided with a physical I / O driver 142 for realizing the exchange between the PLC runtime 510 and the physical I / O 160. With the functional configuration as shown in FIG. 8A, the control calculation by the PLC 100 is realized.
  • an instance of the virtual I / O network server 540 is generated on the container engine 150 of the PLC 100 instead of the PLC runtime 510.
  • the virtual I / O network server 540 is in charge of a process of mediating the exchange between the server 200 and the physical I / O 160.
  • the virtual I / O network server 540 synchronizes the results of I / O processing including the physical I / O 160 with the virtual I / O network client 530.
  • the container engine 250 of the server 200 creates an instance of the image of the PLC runtime 510
  • the container engine 150 of the PLC 100 servers the I / O data exchanged via the field device 10 connected to the PLC 100.
  • the server 200 has a server OS 240 and a container engine 250.
  • an instance of the PLC runtime 510 is generated on the container engine 250.
  • an instance of the virtual I / O driver 520 and the virtual I / O network client 530 is generated on the container engine 250.
  • the instance of the PLC runtime 510 is generated in the server 200, and the instance of the virtual I / O network server 540 is also generated in the PLC 100.
  • the virtual I / O network client 530 exchanges I / O data with the virtual I / O network server 540.
  • the virtual I / O driver 520 emulates the physical I / O driver 142 of the PLC 100 shown in FIG. 8 (A) and responds to an internal command for accessing I / O data from the PLC runtime 510. Then, the same process as accessing the physical I / O 160 of the PLC 100 is performed. In this way, when the container engine 250 of the server 200 creates an instance of the image of the PLC runtime 510, the virtual that emulates the physical I / O driver 142 that is in charge of the process of accessing the field device 10 connected to the PLC 100. Create an instance of the I / O driver 520.
  • the interaction between the virtual I / O network server 540 and the virtual I / O network client 530 is transparent with respect to the PLC runtime 510. That is, the access instruction to the physical I / O 160 is the same in the PLC runtime 510 executed by the PLC 100 and the PLC runtime 510 executed by the server 200.
  • the virtual I / O driver 520, the virtual I / O network client 530, and the virtual I / O network server 540 are substantially the same as the processing executed by the physical I / O driver 142 of the PLC 100 in response to the same access instruction. Realize the processing of. Due to the identity of these processes, even if the PLC runtime 510 is operated in different execution environments as shown in FIGS. 8 (A) to 8 (C), it is not necessary to make the processing contents different.
  • an instance of the virtual I / O emulator 550 and the virtual I / O network server 540 is generated on the container engine 250.
  • the virtual I / O emulator 550 is a module that simulates the physical I / O 160 of the PLC 100, and executes processing such as generating input data in response to output data from the PLC runtime 510. Since the virtual I / O emulator 550 only needs to be able to realize a simulation using the PLC runtime 510, even if the output data given from the PLC runtime 510 is returned as input data as it is (so-called wrapping process). good. Alternatively, the virtual I / O emulator 550 has a model such as a servo driver, and even if the output data given from the PLC runtime 510 is input to the model and the result obtained is returned as input data. good.
  • the container engine 250 of the server 200 also generates an instance of the virtual I / O emulator 550 that emulates the I / O data exchanged with the controlled object together with the instance of the PLC runtime 510. do.
  • the virtual I / O network server 540 executes the same processing as the virtual I / O network server 540 of the PLC 100 shown in FIG. 8 (B). That is, a communication path for exchanging I / O data between the virtual I / O network client 530 and the virtual I / O network server 540 is virtually formed.
  • the virtual I / O network server 540 synchronizes the result of I / O processing by the virtual I / O emulator 550 with the virtual I / O network client 530.
  • connection destination of the virtual I / O network client 530 is appropriately changed to the virtual I / O network server 540 of the PLC 100 or the virtual I / O network server 540 of the server 200.
  • FIG. 9 is a schematic diagram showing a configuration example of the PLC runtime container 50 used in the control system 1 according to the present embodiment.
  • the PLC runtime container 50 includes a PLC runtime image 51, a virtual I / O driver image 52, a virtual I / O network client image 53, a virtual I / O network server image 54, and a virtual I. Includes / O emulator image 55. These images are data in a format that can perform the necessary processing by being deployed.
  • the PLC runtime container 50 further includes a manifest 56.
  • the manifest 56 includes definitions such as which image is enabled and what resources are used in each execution environment and each mode.
  • the container engines 150 and 250 refer to the manifest 56 and select a necessary image from the images of each module included in the PLC runtime container 50.
  • the manifest 56 includes definitions of the functions utilized in each of the modes shown in FIGS. 8 (A) to 8 (C).
  • the PLC runtime container 50 may include an image (for example, a virtual I / O network server image 54) deployed only by the container engine 150 of the PLC 100. Further, the PLC runtime container 50 includes an image (for example, a virtual I / O driver image 52, a virtual I / O network client image 53, a virtual I / O emulator image 55, etc.) deployed only by the container engine 250 of the server 200. You may be.
  • an image for example, a virtual I / O driver image 52, a virtual I / O network client image 53, a virtual I / O emulator image 55, etc.
  • FIG. 9 shows a configuration example using the same PLC runtime container 50
  • the configuration of the PLC runtime container 50 may be different depending on the release destination and the selected mode. That is, the PLC runtime container 50 containing the required image and the corresponding manifest 56 in the selected mode may be generated and released.
  • FIG. 10 is a schematic diagram showing a functional configuration example related to the generation of the PLC runtime container 50 in the control system 1 according to the present embodiment.
  • the container generation module 260 (FIG. 7) of the server 200 includes a development environment 262 and a system configuration manager 264.
  • the development environment 262 generates and outputs the user program 266 executed by the PLC system 2 and the PLC system configuration information 268 that defines the configuration of the PLC system 2 according to the user operation.
  • the development environment 262 includes an editor function, a debugging function, a simulation function, a consistency check function, and the like.
  • the development environment 262 may be realized on the server 200, or may be realized by the development / maintenance terminal 300 executing the development program.
  • the user defines the configuration of the PLC system 2 included in the control system 1 on the development environment 262.
  • the contents to be defined include the number of PLCs 100 and the resources used on the server 200.
  • the user creates a user program 266 according to the control target on the development environment 262.
  • the user can also instruct the release and deployment of the PLC runtime container 50 via the development environment 262.
  • the system configuration manager 264 generates the PLC runtime container 50 based on the user program 266 and the PLC system configuration information 268 according to the user operation.
  • the PLC runtime container 50 contains a manifest 56 in addition to the image of each module.
  • the system configuration manager 264 generates and outputs the system configuration profile 60 in addition to the generation of the PLC runtime container 50.
  • the system configuration profile 60 includes the release destination of the PLC runtime container 50, the identification information of the PLC 100, and the like.
  • system configuration profile 60 may include identification information of the container hub 276 to be used, identification information of the PLC runtime container 50 to be used, information indicating whether or not the virtual node can be used, the maximum number of virtual nodes to be used, and the like. .. At this time, the system configuration profile 60 also includes information on the repository in which information about the PLC runtime container 50 is registered.
  • the system configuration profile 60 may be generated for each control system 1 or for each PLC system 2 included in the control system 1.
  • the system configuration profile 60 may include a container configuration profile.
  • the container configuration profile includes identification information for identifying the PLC runtime container 50, information such as the PLC 100 targeted by the PLC runtime container 50 and devices (motors, robots, etc.) connected to each PLC 100.
  • the container configuration profile may include information such as the necessity of additional necessary functions (hereinafter, also referred to as “functional modules”) in the development environment in controlling the device.
  • FIG. 11 is a schematic diagram showing a functional configuration example related to the release and execution management of the PLC runtime container 50 in the control system 1 according to the present embodiment.
  • the orchestra 270 (FIG. 7) of the server 200 includes a container manager 272 and a node manager 274.
  • the container manager 272 manages the release, deployment, execution, etc. of the PLC runtime container 50.
  • the container manager 272 manages the container hub 276 that registers the PLC runtime container 50 and the repository 278 that manages the state of the PLC runtime container 50 registered in the container hub 276.
  • the container manager 272 registers the PLC runtime container 50 with the container hub 276 and registers the PLC runtime container 50 with the container hub 276 by referring to the accompanying system configuration profile 60, and also registers the PLC runtime container 50 with the repository. Add the entry corresponding to 278.
  • the container hub 276 registers the PLC runtime container 50 generated by the container generation module 260 in association with the identification information of the PLC100 that can be released.
  • Each entry in the repository 278 is a container name for identifying the PLC runtime container 50 registered in the container hub 276, a namespace for associating a node name with a node address, and a container state indicating the state of the PLC runtime container 50. And include.
  • the namespace maps the node name specification from the PLC runtime 510 to the corresponding node address. In this way, the repository 278 manages the address for accessing the container engine 250 when the container engine 250 of the server 200 creates an instance of the PLC runtime 510.
  • the node manager 274 searches for the node (container engine 150 of the PLC 100 or the container engine 250 of the server 200) to which the PLC runtime container 50 is released, acquires the node state, and virtualizes the node in response to a request from the container manager 272. Generate nodes, etc.
  • the node manager 274 releases the PLC runtime container 50 to the server 200, and if the container engine 250 for deploying the PLC runtime container 50 does not exist, the node manager 274 includes the node including the container engine 250. Is virtually generated.
  • FIG. 12 is a schematic diagram showing a typical use case of the control system 1 according to the present embodiment. In the use case shown in FIG. 12, it is assumed that PLC100-1, 100-2, and 100-3 control the control target.
  • Use case 2 shown in FIG. 12B shows an example in which the control operation executed by the PLC100-1 is executed on the server 200 while using the physical I / O160-1 of the PLC100-1. That is, for PLC100-1, a cloud execution mode is realized. For PLC100-2 and 100-3, a simulation mode is realized as in FIG. 12A. In this case, PLC100-2 and 100-3 do not necessarily have to exist.
  • PLC100-2 executes using the physical I / O160-2 of its own device. That is, for PLC100-1, a local execution mode is realized. For PLC100-1, a cloud execution mode is realized as in FIG. 12B, and for PLC100-3, a simulation mode is realized as in FIG. 12A. In this case, PLC100-3 does not necessarily have to exist.
  • FIG. 13 is a schematic diagram illustrating an example of the processing procedure in the use case 1 shown in FIG. 12 (A).
  • FIG. 13 shows a case where a PLC runtime 510 (PLC runtime container 50) including a user program 266 is newly created. Also, the PLC runtime container 50 is released in simulation mode.
  • PLC runtime container 50 PLC runtime container 50
  • the user inputs the definition of the configuration of the PLC system 2 to be designed ((1) configuration definition). Then, the system configuration manager 264 generates the system configuration profile 60 corresponding to the input PLC system 2 ((2) system configuration profile generation).
  • the user creates a user program 266 using the development environment 262 ((3) user program creation). Then, the system configuration manager 264 generates the PLC runtime container 50 ((4) PLC runtime container generation). Further, the container manager 272 registers the generated PLC runtime container 50 in the container hub 276 ((5) PLC runtime container registration). By the above processing, the generation and registration of the PLC runtime container 50 are completed.
  • the node manager 274 creates a virtual node to be released ((7) virtual.
  • the node address of the generated virtual node is associated with the node name and registered in the repository 278 ((8) node name registration).
  • the selected PLC runtime container 50 is transmitted to the virtual node of the release destination ((9) PLC runtime container release).
  • the container engine 250-1 of the virtual node deploys the PLC runtime container 50 ((10) PLC runtime container deployment).
  • the container engine 250-1 of the virtual node registers the container name of the deployed PLC runtime container 50 in the repository 278 ((11) container name registration).
  • the container engine 250-1 of the virtual node can resolve the node address corresponding to the node name of the transmission destination or the reception destination in the exchange of I / O data.
  • the container engine 250-1 of the virtual node reflects the contents of the instance of the PLC runtime container 50 generated by deploying to the container hub 276 ((12) Reflecting the contents of deployment). By reflecting it on the container hub 276 in this way, it becomes easy to reuse it the next time it is started on the virtual node.
  • FIG. 14 is a schematic diagram illustrating an example of another processing procedure in use case 1 shown in FIG. 12 (A).
  • FIG. 14 shows a case where the PLC runtime container 50 created by the processing procedure as shown in FIG. 13 is reused. Also, the PLC runtime container 50 is released in simulation mode.
  • the user instructs to reuse the created PLC system 2 ((1) reuse instruction). Then, the system configuration manager 264 loads the system configuration profile 60 corresponding to the instructed PLC system 2 ((2) system configuration profile load).
  • the user updates the user program 266 using the development environment 262 ((3) user program update).
  • the system configuration manager 264 updates the PLC runtime container 50 ((4) PLC runtime container update).
  • the container manager 272 registers the updated PLC runtime container 50 in the container hub 276 ((5) PLC runtime container registration).
  • PLC runtime container 50 In this case, simulation mode ((6) release instruction), the selected PLC runtime container 50 is sent to the virtual node to be released (((6) release instruction). 7) PLC runtime container release).
  • the PLC runtime has already been realized in the virtual node, so it is not necessary to newly generate the virtual node to be the release destination.
  • the virtual node container engine 250-1 deploys the PLC runtime container 50 ((8) PLC runtime container deployment). As a result, the PLC runtime corresponding to the updated user program is realized. In many cases, it is not necessary to update the contents of the repository 278.
  • the container engine 250-1 of the virtual node reflects the contents of the instance of the PLC runtime container 50 generated by deploying to the container hub 276 ((9) Reflecting the contents of deployment).
  • FIG. 15 is a schematic diagram illustrating an example of the processing procedure in the use case 2 shown in FIG. 12 (B).
  • FIG. 15 shows a case where a PLC runtime 510 (PLC runtime container 50) including a user program 266 is newly created.
  • the PLC runtime container 50 is released in the cloud execution mode.
  • the user inputs the definition of the configuration of the PLC system 2 to be designed ((1) configuration definition). Then, the system configuration manager 264 generates the system configuration profile 60 corresponding to the input PLC system 2 ((2) system configuration profile generation).
  • the user creates a user program 266 using the development environment 262 ((3) user program creation). Then, the system configuration manager 264 generates the PLC runtime container 50 ((4) PLC runtime container generation). Further, the container manager 272 registers the generated PLC runtime container 50 in the container hub 276 ((5) PLC runtime container registration). By the above processing, the generation and registration of the PLC runtime container 50 are completed.
  • the node manager 274 When the user instructs the release of any PLC runtime container 50 (in this case, the cloud execution mode) ((6) release instruction), the node manager 274 creates a virtual node to be released ((7)). Along with the virtual node generation), the node address of the generated virtual node is associated with the node name and registered in the repository 278 ((8) node name registration).
  • the selected PLC runtime container 50 is transmitted to the virtual node of the release destination ((9) PLC runtime container release).
  • the container engine 250-1 of the virtual node deploys the PLC runtime container 50 ((10) PLC runtime container deployment). Deployment by the container engine 250-1 creates instances of the PLC runtime 510, virtual I / O driver 520, and virtual I / O network client 530 (see FIG. 8B).
  • the selected PLC runtime container 50 is also transmitted to the release destination PLC100-1 ((11) PLC runtime container release).
  • the PLC 100-1 container engine 150 deploys the PLC runtime container 50 ((12) PLC runtime container deployment). Deployment by the container engine 150 creates an instance of the virtual I / O network server 540.
  • the container engine 250-1 of the virtual node registers the container name of the deployed PLC runtime container 50 in the repository 278 ((13) container name registration). Further, the container engine 250-1 of the virtual node reflects the contents of the instance of the PLC runtime container 50 generated by deploying to the container hub 276 ((14) Reflecting the contents of deployment).
  • FIG. 16 is a schematic diagram illustrating an example of another processing procedure in use case 2 shown in FIG. 12 (B).
  • FIG. 16 shows a case where the PLC runtime 510 is released in the local execution mode, but is changed to the cloud execution mode due to lack of resources in the PLC100.
  • the user inputs the definition of the configuration of the PLC system 2 to be designed ((1) configuration definition). Then, the system configuration manager 264 generates the system configuration profile 60 corresponding to the input PLC system 2 ((2) system configuration profile generation).
  • the user creates a user program 266 using the development environment 262 ((3) user program creation). Then, the system configuration manager 264 generates the PLC runtime container 50 ((4) PLC runtime container generation). Further, the container manager 272 registers the generated PLC runtime container 50 in the container hub 276 ((5) PLC runtime container registration). By the above processing, the generation and registration of the PLC runtime container 50 are completed.
  • the selected PLC runtime container 50 is sent to the release destination PLC100-1.
  • PLC runtime container release The PLC100-1 container engine 150 deploys the PLC runtime container 50 ((8) PLC runtime container deployment).
  • PLC runtime container deployment it is assumed that the deployment of the PLC runtime container 50 fails due to the capacity exceeding of the PLC100-1.
  • the system configuration manager 264 changes the process from the local execution mode to the cloud execution mode.
  • the node manager 274 generates a virtual node to be released ((9) virtual node generation) and registers the node address of the generated virtual node in the repository 278 in association with the node name ((10) node). Name registration).
  • the selected PLC runtime container 50 is transmitted to the virtual node of the release destination ((11) PLC runtime container release).
  • the container engine 250-1 of the virtual node deploys the PLC runtime container 50 ((12) PLC runtime container deployment).
  • the selected PLC runtime container 50 is sent again to the release destination PLC100-1 ((13) PLC runtime container release).
  • the PLC100-1 container engine 150 deploys the PLC runtime container 50 in the cloud execution mode ((14) PLC runtime container deployment). Deployment by the container engine 150 creates an instance of the virtual I / O network server 540.
  • the container engine 250-1 of the virtual node registers the container name of the deployed PLC runtime container 50 in the repository 278 ((15) container name registration). Further, the container engine 250-1 of the virtual node reflects the contents of the instance of the PLC runtime container 50 generated by deploying to the container hub 276 ((16) Reflecting the contents of deployment).
  • FIG. 17 is a schematic diagram illustrating an example of the processing procedure in the use case 3 shown in FIG. 12 (C).
  • FIG. 17 shows the case where the PLC runtime 510 is released in the local execution mode, the cloud execution mode, and the simulation mode, respectively.
  • the user inputs the definition of the configuration of the PLC system 2 to be designed ((1) configuration definition). Then, the system configuration manager 264 generates the system configuration profile 60 corresponding to the input PLC system 2 ((2) system configuration profile generation).
  • the user creates a user program 266 using the development environment 262 ((3) user program creation). Then, the system configuration manager 264 generates the PLC runtime container 50 ((4) PLC runtime container generation). Further, the container manager 272 registers the generated PLC runtime container 50 in the container hub 276 ((5) PLC runtime container registration). By the above processing, the generation and registration of the PLC runtime container 50 are completed.
  • the node manager 274 generates a virtual node to be released ((7) virtual node generation) and registers the node address of the generated virtual node in the repository 278 in association with the node name ((8) node name registration). ).
  • the PLC runtime container 50 selected in the local execution mode is sent to the release destination PLC100-1 ((9) PLC runtime container release), and the PLC100-1 container engine 150 deploys the PLC runtime container 50 ((10). ) PLC runtime container deployment).
  • the PLC runtime container 50 selected in the cloud execution mode is sent to the release destination PLC100-2 ((11) PLC runtime container release), and the PLC100-2 container engine 150 deploys the PLC runtime container 50 ((12) PLC runtime container release). ) PLC runtime container deployment).
  • the PLC runtime container 50 selected in the cloud execution mode is also sent to the release destination virtual node ((13) PLC runtime container release), and the container engine 250-2 of the virtual node deploys the PLC runtime container 50. ((14) PLC runtime container deployment).
  • the PLC runtime container 50 selected in the simulation mode is also sent to the release destination virtual node ((15) PLC runtime container release), and the container engine 250-3 of the virtual node deploys the PLC runtime container 50 ((16). ) PLC runtime container deployment).
  • the virtual node container engines 250-2 and 250-3 register the container name of the deployed PLC runtime container 50 in the repository 278 ((17) container name registration). Further, the container engines 250-2 and 250-3 of the virtual node reflect the contents of the instance of the PLC runtime container 50 generated by deployment to the container hub 276 ((18) Reflection of the deployment contents).
  • FIG. 18 is a flowchart showing an example of a processing procedure relating to the generation of the PLC runtime container 50 in the control system 1 according to the present embodiment.
  • FIG. 19 is a flowchart showing an example of a processing procedure related to release and execution management of the PLC runtime container 50 in the control system 1 according to the present embodiment.
  • Each step shown in FIGS. 18 and 19 is typically realized by the processor 202 of the server 200 executing the program.
  • the user accesses the development environment 262 and defines the configuration of the PLC system 2. That is, the development environment 262 of the server 200 receives the definition of the configuration of the PLC system 2 from the user (step S100). More specifically, the user specifies the target PLC100 and a device (motor, robot, etc.) connected to each PLC100.
  • the development environment 262 of the server 200 In response to the user's definition, the development environment 262 of the server 200 generates and outputs PLC system configuration information 268 (step S102). Subsequently, the system configuration manager 264 of the server 200 generates and outputs the system configuration profile 60 corresponding to each of the designated PLC 100 (step S104). That is, the system configuration profile 60 is generated by the number of the specified PLC100. Also, each of the system configuration profiles 60 contains information about the devices connected to the corresponding PLC100.
  • the development environment 262 of the server 200 provides an editor environment for generating an IEC program, and accepts a user program 266 created by the user (step S106).
  • the development environment 262 of the server 200 refers to the system configuration profile 60 and determines whether or not there is a functional module associated with any device connected to the PLC 100 (step S108). If there is a functional module associated with any device (YES in step S108), the development environment 262 of the server 200 provides an editor environment associated with the associated functional module and makes various settings from the user. Accept (step S110).
  • the system configuration manager 264 of the server 200 loads the standard template required for the PLC runtime (step S112).
  • the system configuration manager 264 of the server 200 refers to the system configuration profile 60 to determine if a template associated with any device connected to the PLC 100 is required (step S114). If a template associated with any device is required (YES in step S114), the system configuration manager 264 of the server 200 loads the required template (step S116).
  • the system configuration manager 264 of the server 200 generates the PLC runtime container 50 based on the user program generated by the user and the loaded template (step S118).
  • the container manager 272 of the server 200 registers the PLC runtime container 50 generated by the container generation module 260 in the container hub 276 (step S120).
  • the server 200 generates a container including an image of the PLC runtime including the user program that defines the control operation for the controlled object and the execution environment that executes the user program.
  • the development environment 262 of the server 200 refers to the container hub 276 and the repository 278 to display a list of the PLC runtime containers 50 prepared in advance in response to the user operation (step S200). ).
  • the system configuration manager 264 of the server 200 determines which mode is selected (step S202).
  • the node manager 274 of the server 200 refers to the system configuration profile 60, and the PLC100 to which the selected PLC runtime container 50 is released is valid. It is determined whether or not it exists in (step S204).
  • the container manager 272 of the server 200 updates the contents of the repository 278 according to the release of the PLC runtime container 50 (step S206). Subsequently, the system configuration manager 264 of the server 200 sends the selected PLC runtime container 50 to the release destination PLC100 (step S208).
  • the container engine 150 of the destination PLC 100 deploys the PLC runtime container 50 with reference to the manifest 56 included in the PLC runtime container 50 (step S210). As a result, the PLC runtime 510 is realized in the PLC100 of the release destination. Then, the process ends.
  • step S204 if the release destination PLC100 is validly present (NO in step S204), the development environment 262 of the server 200 notifies the user that the resource destination PLC100 is not validly present (NO). Step S212). Then, the process ends.
  • the node manager 274 of the server 200 refers to the system configuration profile 60, and the PLC 100 to which the selected PLC runtime container 50 is released is released. It is determined whether or not it exists effectively (step S214).
  • the node manager 274 of the server 200 refers to the system configuration profile 60 and refers to the virtual destination of the selected PLC runtime container 50. It is determined whether or not the node is effectively present on the server 200 (step S216).
  • the node manager 274 of the server 200 generates the required number of virtual nodes (step S218).
  • the virtual node provides an environment in which the PLC runtime container 50 including the container engine 250 can be deployed.
  • step S216 If the virtual node to be released exists effectively on the server 200 (YES in step S216), the process of step S218 is skipped.
  • the container manager 272 of the server 200 updates the contents of the repository 278 according to the release of the PLC runtime container 50 (step S220). Then, the system configuration manager 264 of the server 200 sends the selected PLC runtime container 50 to the release destination PLC 100 and the virtual node on the server 200 (step S222). On the other hand, the container engine 250 included in the virtual node of the destination server 200 also deploys the PLC runtime container 50 with reference to the manifest 56 included in the PLC runtime container 50 (step S224). As a result, the virtual I / O network server 540 is realized in the PLC 100 of the release destination, and the PLC runtime 510 is realized in the virtual node on the server 200.
  • step S214 if the release destination PLC100 does not exist effectively (NO in step S214), the development environment 262 of the server 200 notifies the user that the resource destination PLC100 does not exist effectively (NO). Step S226). Then, the process ends.
  • the node manager 274 of the server 200 refers to the system configuration profile 60, and the virtual node to which the selected PLC runtime container 50 is released is the server. It is determined whether or not it is effectively present on the 200 (step S228).
  • the node manager 274 of the server 200 generates the required number of virtual nodes (step S230).
  • step S230 If the virtual node to be released exists effectively on the server 200 (YES in step S228), the process of step S230 is skipped.
  • the container manager 272 of the server 200 updates the contents of the repository 278 according to the release of the PLC runtime container 50 (step S232). Then, the system configuration manager 264 of the server 200 transmits the selected PLC runtime container 50 to the virtual node on the server 200 (step S234).
  • the container engine 250 included in the virtual node of the destination server 200 deploys the PLC runtime container 50 with reference to the manifest 56 included in the PLC runtime container 50 (step S236).
  • the virtual node on the release destination server 200 realizes a simulationable environment including the PLC runtime 510 and the virtual I / O emulator 550. In this way, the process of releasing the PLC runtime container 50 to one or both of the PLC 100 and the server 200 is executed.
  • server 200 has a container engine 250, a container generation module 260, and an orchestrator 270 (see FIG. 7), but when the actual server 200 is cloud-based and virtualized. It is not necessary for the same hardware to implement all of these modules, but it can be implemented using one or more processors as appropriate.
  • a control system (1) comprising one or more control devices (100) and one or more servers (200).
  • a generation module (260) that generates a container (50) including an image (51) of a runtime (510) that includes a user program (266) that defines a control operation for a controlled object and an execution environment that executes the user program.
  • It comprises an orchestrator (270) that releases the container to one or both of the controller and the server.
  • the control device and the server have a container engine (150, 250) for deploying the container, and by deploying the container released by the orchestrator, an instance of the runtime (510) is generated.
  • a control system that executes the control calculation.
  • the container engine (250) of the server emulates a virtual I / O driver (520) that emulates an I / O driver in charge of accessing a device connected to the control device when creating an instance of the runtime. ) Is generated, the control system according to any one of the configurations 1 to 3.
  • the container includes at least one of an image (54) deployed only by the container engine of the control device and an image (52, 53, 55) deployed only by the container engine of the server, configurations 1 to 4.
  • the control system according to any one of the above items.
  • the configuration 1 to 6 further includes a node manager (274) that virtually generates a node including the container engine.
  • the control system according to any one of the above items.
  • a control method performed in a control system (1) comprising one or more control devices (100) and one or more servers (200). Steps (S100 to S120) to generate a container containing a runtime image containing a user program that defines a control operation for a controlled object and an execution environment that executes the user program. A step (S200 to S234) of releasing the container to one or both of the control device and the server is provided.
  • control operation itself can be executed by the server while using the device connected to the PLC, so that the PLC arranged on the field side can be miniaturized and simplified. can.
  • the control operation can be executed in three modes of the local execution mode, the cloud execution mode, and the simulation mode for each of the PLCs, so that a plurality of PLCs can be executed. Even when it is necessary to perform verification in combination with PLC, verification can be performed by combining in a mode possible in the situation at that time. By verifying with such a combination, it becomes possible to detect and solve problems at the time of system connection at an early stage, and it is possible to shorten the time until the operation of the control system starts.
  • Manager 276 container hub, 278 repository, 300 development and maintenance terminal, 304 optical drive, 305 recording medium, 314 development program, 510 PLC runtime, 520 virtual I / O driver, 530 virtual I / O network client, 540 virtual I / O Network server, 550 virtual I / O emulator.

Landscapes

  • Engineering & Computer Science (AREA)
  • Software Systems (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • Automation & Control Theory (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Programmable Controllers (AREA)
  • Stored Programmes (AREA)
  • Test And Diagnosis Of Digital Computers (AREA)

Abstract

制御システムは、制御対象に対する制御演算を定義するユーザプログラムと当該ユーザプログラムを実行する実行環境とを内包するランタイムイメージを含むコンテナを生成する生成モジュールと、制御装置およびサーバの一方または両方に対してコンテナをリリースするオーケストレータとを含む。制御装置およびサーバは、コンテナをデプロイするコンテナエンジンを有しており、オーケストレータによりリリースされたコンテナをデプロイすることで、ランタイムイメージのインスタンスを生成して制御演算を実行する。

Description

制御システムおよび制御方法
　本発明は、制御装置およびサーバを含む制御システムおよびその制御システムにおける制御方法に関する。
　複数の制御装置（典型的には、ＰＬＣ（プログラマブルロジックコントローラ））からなる制御システムの運用を開始するには、設計、実装、検証などの一連の作業が必要である。これらの一連の作業では、制御装置単体について設計、実装、検証を行った後に、制御装置およびデバイスを組み合わせる。このようなシステムとして結合するためには、各制御装置についての作業が完了している必要があるが、制御装置毎の複雑さや特性などによって、作業進捗を同じにすることは難しい。そのため、作業進捗のばらつきによって、システムとして結合するまでに待ち時間が発生し得る。
　ところで、制御装置の技術分野ではなく、一般的なＩＴ技術の分野では、コンテナおよびオーケストレーションといった技術を利用して、コンピュータリソースの動的に拡張および縮退することで、スケーラブルなソフトウェアサービスの提供が実現されている。例えば、特表２０１５－５１２０９１号公報（特許文献１）は、コンピュータクラウドリソースを管理する方法を開示する。
特表２０１５－５１２０９１号公報
　上述したような複数の制御装置および複数の制御装置を組み合わせたシステムについての設計、実装、検証などの一連の作業を容易化するとともに、制御装置のリソースをスケーラブルに利用可能にする構成が要望されている。
　本発明の一つの目的は、このような要望に応える解決手段を提供することである。
　本発明の一例に従えば、１または複数の制御装置と１または複数のサーバとを備える制御システムが提供される。制御システムは、制御対象に対する制御演算を定義するユーザプログラムと当該ユーザプログラムを実行する実行環境とを内包するランタイムのイメージを含むコンテナを生成する生成モジュールと、制御装置およびサーバの一方または両方に対してコンテナをリリースするオーケストレータとを含む。制御装置およびサーバは、コンテナをデプロイするコンテナエンジンを有しており、オーケストレータによりリリースされたコンテナをデプロイすることで、ランタイムのインスタンスを生成して制御演算を実行する。この構成によれば、ランタイムのイメージを含むコンテナを制御装置およびサーバのいずれでもデプロイして実行できるので、制御装置が存在しない状態であっても、制御演算の実行の検証などを容易化できる。また、サーバで実行されている制御演算を制御装置へ容易に移動させることもできる。
　サーバのコンテナエンジンは、ランタイムのインスタンスとともに、制御対象とやり取りされる入出力データをエミュレートするエミュレータのインスタンスも生成してもよい。この構成によれば、制御装置に接続されるデバイスが存在しなくても、サーバ上で制御演算の検証などを容易に行うことができる。
　サーバのコンテナエンジンがランタイムのインスタンスを生成する場合に、制御装置のコンテナエンジンが制御装置に接続されたデバイスを介してやり取りされる入出力データをサーバに仲介するネットワークサーバのインスタンスを生成してもよい。この構成によれば、制御装置に接続されたデバイスとの間でやり取りされるＩ／Ｏデータを利用しつつ、制御演算自体はサーバで実行できるので、サーバが提供するリソースを利用できる。
　サーバのコンテナエンジンは、ランタイムのインスタンスを生成する場合に、制御装置に接続されたデバイスへアクセスする処理を担当するＩ／Ｏドライバをエミュレートする仮想Ｉ／Ｏドライバのインスタンスを生成してもよい。この構成によれば、制御装置上で制御演算を実行するのと実質的に同じ実行環境を提供できるので、制御演算を実現するためのランタイムをサーバにおいても共通に利用できる。
　コンテナは、制御装置のコンテナエンジンのみがデプロイするイメージと、サーバのコンテナエンジンのみがデプロイするイメージとのうち、少なくとも一方を含んでいてもよい。この構成によれば、コンテナに冗長にイメージを含ませておくことで、デプロイ先に依存せず制御演算を実現できる。
　制御システムは、サーバのコンテナエンジンがランタイムのインスタンスを生成する場合に、当該コンテナエンジンにアクセスするためのアドレスを管理するリポジトリをさらに含んでいてもよい。この構成によれば、サーバ上で制御演算を実行する場合に、実行環境に割り当てられるアドレスの違いをリポジトリの参照により吸収できる。
　制御システムは、サーバに対してコンテナをリリースする場合に、当該コンテナをデプロイするコンテナエンジンが存在しなければ、コンテナエンジンを含むノードを仮想的に生成するノードマネージャをさらに含んでいてもよい。この構成によれば、要求に応じて、制御演算を実行するノードを任意に生成できる。
　制御システムは、生成モジュールにより生成されるコンテナをリリース可能な制御装置の識別情報と関連付けて登録するコンテナハブをさらに含んでいてもよい。この構成によれば、一度生成されたコンテナの再利用が容易になる。
　オーケストレータは、ユーザ操作に従って、リリースするコンテナを選択するとともに、リリース先を決定してもよい。この構成によれば、ユーザは、制御システムの状況に応じて、必要なコンテナを必要な実行環境にリリースできる。
　本発明の別の一例に従えば、１または複数の制御装置と１または複数のサーバとを備える制御システムにおいて実行される制御方法が提供される。制御方法は、制御対象に対する制御演算を定義するユーザプログラムと当該ユーザプログラムを実行する実行環境とを内包するランタイムのイメージを含むコンテナを生成するステップと、制御装置およびサーバの一方または両方に対してコンテナをリリースするステップとを含む。制御装置およびサーバは、コンテナをデプロイするコンテナエンジンを有しており、リリースされたコンテナをデプロイすることで、ランタイムのインスタンスを生成して制御演算を実行する。
　本発明のある局面によれば、複数の制御装置および複数の制御装置を組み合わせたシステムについての設計、実装、検証などの一連の作業を容易化できる。本発明の別の局面によれば、制御装置のリソースをスケーラブルに利用可能にできる。
本実施の形態に係る制御システムの全体構成例を示す模式図である。 本実施の形態に係る制御システムにおけるコンテナを利用した処理の概要を説明するための図である。 本実施の形態に係る制御システムにおいて提供されるモードを説明するための図である。 本実施の形態に係る制御システムを構成するＰＬＣのハードウェア構成例を示すブロック図である。 本実施の形態に係る制御システムを構成するサーバのハードウェア構成例を示すブロック図である。 本実施の形態に係る制御システムを構成する開発保守端末のハードウェア構成例を示すブロック図である。 本実施の形態に係る制御システムにおける機能構成の一例を示す模式図である。 本実施の形態に係る制御システムにおいて提供されるモードを実現するための機能構成例を示す模式図である。 本実施の形態に係る制御システムにおいて利用されるＰＬＣランタイムコンテナの構成例を示す模式図である。 本実施の形態に係る制御システムにおけるＰＬＣランタイムコンテナの生成に係る機能構成例を示す模式図である。 本実施の形態に係る制御システムにおけるＰＬＣランタイムコンテナのリリースおよび実行管理に係る機能構成例を示す模式図である。 本実施の形態に係る制御システムの典型的なユースケースを示す模式図である。 図１２（Ａ）に示すユースケースにおける処理手順の一例を概略する模式図である。 図１２（Ａ）に示すユースケースにおける別の処理手順の一例を概略する模式図である。 図１２（Ｂ）に示すユースケースにおける処理手順の一例を概略する模式図である。 図１２（Ｂ）に示すユースケースにおける別の処理手順の一例を概略する模式図である。 図１２（Ｃ）に示すユースケースにおける処理手順の一例を概略する模式図である。 本実施の形態に従う制御システムにおけるＰＬＣランタイムコンテナの生成に関する処理手順の一例を示すフローチャートである。 本実施の形態に従う制御システムにおけるＰＬＣランタイムコンテナのリリースおよび実行管理に関する処理手順の一例を示すフローチャートである。
　本発明の実施の形態について、図面を参照しながら詳細に説明する。なお、図中の同一または相当部分については、同一符号を付してその説明は繰り返さない。
　＜Ａ．適用例＞
　まず、本発明が適用される場面の一例について説明する。
　図１は、本実施の形態に係る制御システム１の全体構成例を示す模式図である。図１を参照して、本実施の形態に係る制御システム１は、１または複数のＰＬＣシステム２－１，２－２，２－３（以下、「ＰＬＣシステム２」とも総称する。）と、１または複数のサーバ２００と、開発保守端末３００とを含む。以下の説明において、ＰＬＣシステム２－１，２－２，２－３のそれぞれを区別する必要がある場合には、関係する構成要素について、「－１」，「－２」，「－３」といった添え字を付与することもある。
　ＰＬＣシステム２の各々は、ラインとも称され、工場全体を制御するものであってもよいし、工場に設置された特定の製造設備や製造装置を制御するものであってもよい。ＰＬＣシステム２－１，２－２，２－３は、主たる構成要素として、制御対象を制御する制御装置の典型例であるＰＬＣ（Programmable　Logic　Controller）１００－１，１００－２，１００－３（以下、「ＰＬＣ１００」とも総称する。）をそれぞれ主体に構成される。
　ＰＬＣ１００は、フィールドデバイス１０に接続される。フィールドデバイス１０は、制御対象を制御するために必要な任意の装置を包含する。より具体的には、フィールドデバイス１０は、制御対象（例えば、製造設備、製造装置、製造設備あるいは製造装置に含まれるセンサおよびアクチュエータなど）との間で情報をやり取りするための装置を含む。図１に示す例では、フィールドデバイス１０は、リモートＩ／Ｏ（Input/Output）１２と、リレー群１４と、サーボドライバ１６およびサーボモータ１８とを含む。
　ＰＬＣ１００は、フィールドデバイス１０から情報を取得し、予め作成されたユーザプログラムに従って制御演算を実行することで、フィールドデバイス１０へ与えられる情報を生成する。以下では、ＰＬＣ１００がフィールドデバイス１０から取得する情報を「入力データ」とも称し、フィールドデバイス１０へ与えられる情報を「出力データ」とも称す。また、入力データおよび出力データを「入出力データ」あるいは「Ｉ／Ｏデータ」とも総称する。
　図１に示す例では、ＰＬＣ１００とフィールドデバイス１０とは、制御系ネットワーク４を介して接続されているが、これに限らず、ハードワイヤーで接続されていてもよい。また、フィールドデバイス１０は、図１に示されるデバイスに限らず、任意のデバイスを包含し得る。
　制御系ネットワーク４としては、産業用の通信プロトコルを採用することが好ましい。このような通信プロトコルとしては、ＥｔｈｅｒＣＡＴ（登録商標）、ＥｔｈｅｒＮｅｔ／ＩＰ（登録商標）、ＤｅｖｉｃｅＮｅｔ（登録商標）、ＣｏｍｐｏＮｅｔ（登録商標）などが知られている。
　ＰＬＣシステム２の各々は、情報系ネットワーク６およびゲートウェイ２０を介して、インターネット８上に存在するサーバ２００にアクセス可能になっている。情報系ネットワーク６としては、イーサネット（登録商標）などの汎用的な通信プロトコルを採用してもよい。
　サーバ２００は、コンテナをデプロイして実行可能な環境を提供するとともに、コンテナのリリースを管理する。本明細書において、コンテナの「リリース」は、対象のコンテナを実行先に提供する処理および実行先での実行可能化を指示する処理（例えば、デプロイを指示する処理）を包含する。これらの処理および機能の詳細については、後述する。
　サーバ２００は、インターネット８を介してクラウド上に配置してもよいし、インターネット８を介することなく、ＰＬＣシステム２が存在するローカルネットワーク内に配置してもよい。サーバ２００の実装形態としては、要求される性能および機能などに応じて、任意に決定できる。
　開発保守端末３００は、サーバ２００にアクセスして、後述するような各種処理を実現するためのユーザ操作が可能になっている。
　図２は、本実施の形態に係る制御システム１におけるコンテナを利用した処理の概要を説明するための図である。
　本明細書においては、ＰＬＣシステム２のＰＬＣ１００で制御演算を実行するために必要なプログラムおよびライブラリなどを「ＰＬＣランタイム」と称す。なお、「ＰＬＣランタイム」との用語は、制御演算の実行に必要なプログラムおよびライブラリなどに加えて、制御演算を実現する実体および実行環境を包含し得る。典型的には、「ＰＬＣランタイム」は、ＰＬＣ１００による制御対象に対する制御演算を定義するユーザプログラム（例えば、ＩＥＣ６１１３１－３に従って任意に作成されるプログラム）と、ユーザプログラムを実行する実行環境であるＰＬＣエンジン（ファームウェア）とを含む。
　本実施の形態に従う制御システム１においては、ＰＬＣランタイムをＰＬＣ１００だけではなく、サーバ２００が提供する仮想環境においても実現できるようにパッケージ化したものを「ＰＬＣランタイムコンテナ」と称す。「ＰＬＣランタイムコンテナ」をホストＯＳ（Operating　System）にデプロイすることで、論理的に独立したアプリケーションの実行環境を実現できる。なお、「ＰＬＣランタイムコンテナ」との用語は、実現されたアプリケーションの実行環境を包含し得る。「ＰＬＣランタイムコンテナ」を構成するプログラム（アプリケーション）およびライブラリなどの詳細、ならびに、「ＰＬＣランタイムコンテナ」の生成方法の詳細などについては、後述する。
　図２を参照して、ＰＬＣランタイムコンテナ５０は、ＰＬＣシステム２のＰＬＣ１００およびサーバ２００のいずれにもリリース可能である。要求される状況に応じて、ＰＬＣランタイムコンテナ５０のデプロイ先およびデプロイ内容を最適化することで、少なくとも、（１）ローカル実行モード、（２）クラウド実行モード、（３）シミュレーションモードの３つのモードを実現できる。
　図３は、本実施の形態に係る制御システム１において提供されるモードを説明するための図である。
　図３（Ａ）を参照して、（１）ローカル実行モードは、ＰＬＣ１００がフィールドデバイス１０を介してやり取りされるＩ／Ｏデータを利用して制御演算を実行する状態に相当する。より具体的には、ＰＬＣ１００にＰＬＣランタイム５１０および物理Ｉ／Ｏ１６０が実現される。物理Ｉ／Ｏ１６０は、フィールドデバイス１０および制御系ネットワーク４（いずれも図１参照）も含む抽象化されたレイヤである。ローカル実行モードは、いわゆる実運用に相当する。
　図３（Ｂ）を参照して、（２）クラウド実行モードは、ＰＬＣ１００に接続されたフィールドデバイス１０を介してＩ／Ｏデータをやり取りする一方で、制御演算自体は、サーバ２００で実行する状態に相当する。より具体的には、ＰＬＣ１００に物理Ｉ／Ｏ１６０が実現されるとともに、サーバ２００にＰＬＣランタイム５１０が実現される。クラウド実行モードは、実運用として用いることもできるし、ユーザプログラムの開発やチェックなどに用いることもできる。
　図３（Ｃ）を参照して、（３）シミュレーションモードは、ＰＬＣ１００に接続されたフィールドデバイス１０を必要とせず、サーバ２００がフィールドデバイス１０をエミュレートしつつ、サーバ２００が制御演算も実行する状態に相当する。より具体的には、サーバ２００にＰＬＣランタイム５１０および仮想Ｉ／Ｏエミュレータ５５０が実現される。仮想Ｉ／Ｏエミュレータ５５０は、物理Ｉ／Ｏ１６０の挙動をエミュレートするモジュールである。シミュレーションモードは、ユーザプログラムの開発やチェックに用いることができる。
　このように、本実施の形態に従う制御システム１においては、ＰＬＣランタイムコンテナ５０を利用することで、ＰＬＣシステム２の一部または全部が存在しない状態であっても、ユーザプログラムの開発やチェックを容易に行うことができるとともに、シームレスで実運用へ移行することもできる。
　＜Ｂ．ハードウェア構成＞
　次に、本実施の形態に係る制御システムを構成する装置のハードウェア構成の一例について説明する。
　（ｂ１：ＰＬＣ１００）
　図４は、本実施の形態に係る制御システム１を構成するＰＬＣ１００のハードウェア構成例を示すブロック図である。図４を参照して、ＰＬＣ１００は、ＣＰＵ（Central　Processing　Unit）やＭＰＵ（Micro-Processing　Unit）などのプロセッサ１０２と、チップセット１０４と、主メモリ１０６と、ストレージ１１０と、情報系ネットワークコントローラ１２０と、制御系ネットワークコントローラ１２２と、ＵＳＢ（Universal　Serial　Bus）コントローラ１２４と、メモリカードインターフェイス１２６とを含む。
　プロセッサ１０２は、ストレージ１１０に格納された各種プログラムを読み出して、主メモリ１０６に展開して実行することで、制御対象を制御するための制御演算を実現する。チップセット１０４は、プロセッサ１０２と各コンポーネントとのデータ伝送などを制御する。
　ストレージ１１０には、典型的には、基本的な処理を実現するためのＯＳ１１２と、ＰＬＣランタイムコンテナのデプロイなどの処理を行うシステムプログラム１１４とが格納される。
　情報系ネットワークコントローラ１２０は、情報系ネットワーク６を介した開発保守端末３００などとのデータのやり取りを制御する。
　制御系ネットワークコントローラ１２２と、制御系ネットワーク４を介したフィールドデバイス１０とのデータのやり取りを制御する。
　ＵＳＢコントローラ１２４は、ＵＳＢ接続を介した外部装置（例えば、サポート装置）とのデータのやり取りを制御する。
　メモリカードインターフェイス１２６は、メモリカード１２８を着脱可能に構成されており、メモリカード１２８に対してデータを書き込み、メモリカード１２８から各種データ（ユーザプログラムやトレースデータなど）を読み出すことが可能になっている。
　図４には、プロセッサ１０２がプログラムを実行することで必要な処理が提供される構成例を示したが、これらの提供される処理の一部または全部を、専用のハードウェア回路（例えば、ＡＳＩＣ（Application　Specific　Integrated　Circuit）またはＦＰＧＡ（Field-Programmable　Gate　Array）など）を用いて実装してもよい。あるいは、ＰＬＣ１００の主要部を、汎用的なアーキテクチャに従うハードウェア（例えば、汎用パソコンをベースとした産業用パソコン）を用いて実現してもよい。この場合には、仮想化技術を用いて、用途の異なる複数のＯＳを並列的に実行させるとともに、各ＯＳ上で必要なアプリケーションを実行させるようにしてもよい。
　（ｂ２：サーバ２００）
　図５は、本実施の形態に係る制御システム１を構成するサーバ２００のハードウェア構成例を示すブロック図である。図５を参照して、サーバ２００は、ＣＰＵやＭＰＵなどの１または複数のプロセッサ２０２と、主メモリ２０６と、ストレージ２１０と、１または複数のネットワークコントローラ２２０と、入力部２２６と、表示部２２８とを含む。これらのコンポーネントは、バス２０８を介して接続される。
　プロセッサ２０２は、ストレージ２１０に格納された各種プログラムを読み出して、主メモリ２０６に展開して実行することで、後述するような各種処理を実現する。
　ストレージ２１０は、例えば、ＨＤＤ（Hard　Disk　Drive）やＳＳＤ（Flash　Solid　State　Drive）などで構成される。ストレージ２１０には、典型的には、基本的な処理を実現するためのＯＳ２１２と、後述するようなサーバ２００が提供する各種処理を実現するためのコンテナアプリケーション２１４とが格納される。
　ネットワークコントローラ２２０は、ネットワークを介した各種装置とのデータのやり取りを制御する。
　入力部２２６は、キーボード、マウスなどで構成され、ユーザからの指示を受け付ける。表示部２２８は、ディスプレイなどで構成され、プロセッサ２０２からの処理結果などを出力する。
　図５には、プロセッサ２０２がプログラムを実行することで必要な処理が提供される構成例を示したが、これらの提供される処理の一部または全部を、専用のハードウェア回路（例えば、ＡＳＩＣまたはＦＰＧＡなど）を用いて実装してもよい。
　（ｂ３：開発保守端末３００）
　図６は、本実施の形態に係る制御システム１を構成する開発保守端末３００のハードウェア構成例を示すブロック図である。図６を参照して、開発保守端末３００は、ＣＰＵやＭＰＵなどのプロセッサ３０２と、主メモリ３０６と、ストレージ３１０と、ネットワークコントローラ３２０と、ＵＳＢコントローラ３２４と、入力部３２６と、表示部３２８とを含む。これらのコンポーネントは、バス３０８を介して接続される。
　プロセッサ３０２は、ストレージ３１０に格納された各種プログラムを読み出して、主メモリ３０６に展開して実行することで、開発保守端末３００で必要な処理を実現する。
　ストレージ３１０は、例えば、ＨＤＤやＳＳＤなどで構成される。ストレージ３１０には、典型的には、ＯＳ３１２と、後述するような処理を指示などするための開発プログラム３１４とが格納される。なお、ストレージ３１０には、図６に示すプログラム以外の必要なプログラムが格納されてもよい。
　ネットワークコントローラ３２０は、任意の制御系ネットワーク４を介したＰＬＣ１００などとのデータのやり取りを制御する。
　ＵＳＢコントローラ３２４は、ＵＳＢ接続を介した外部装置とのデータのやり取りを制御する。
　入力部３２６は、マウス、キーボード、タッチパネルなどで構成され、ユーザからの指示を受け付ける。表示部２２８は、ディスプレイ、各種インジケータなどで構成され、プロセッサ２０２からの処理結果などを出力する。
　開発保守端末３００は、光学ドライブ３０４を有していてもよい。光学ドライブ３０４は、コンピュータ読取可能なプログラムを非一過的に格納する記録媒体３０５（例えば、ＤＶＤ（Digital　Versatile　Disc）などの光学記録媒体）からプログラムを読み取って、ストレージ３１０などに格納する。
　開発保守端末３００で実行される各種プログラムは、コンピュータ読取可能な記録媒体３０５を介してインストールされてもよいが、ネットワーク上の任意のサーバからダウンロードする形でインストールするようにしてもよい。
　図６には、プロセッサ３０２がプログラムを実行することで必要な処理が提供される構成例を示したが、これらの提供される処理の一部または全部を、専用のハードウェア回路（例えば、ＡＳＩＣまたはＦＰＧＡなど）を用いて実装してもよい。
　＜Ｃ．制御システム１の機能構成＞
　図７は、本実施の形態に係る制御システム１における機能構成の一例を示す模式図である。図７を参照して、ＰＬＣ１００の各々は、コンテナエンジン１５０を有している。コンテナエンジン１５０は、コンテナの実行環境を提供するものであり、ＰＬＣランタイムコンテナ５０に含まれるマニフェストなどに基づいて、モジュールのイメージをデプロイして、処理を実行するためのモジュール（インスタンス）を生成する。
　一方、サーバ２００は、コンテナエンジン２５０と、コンテナ生成モジュール２６０と、オーケストレータ２７０とを有している。
　コンテナエンジン２５０は、コンテナエンジン１５０と同様に、ＰＬＣランタイムコンテナ５０に含まれるマニフェストなどに基づいて、モジュールのイメージをデプロイして、処理を実行するためのモジュール（インスタンス）を生成する。
　コンテナエンジン１５０，２５０は、ＣａａＳ（Containers　as　a　Service）としての基盤である。ＰＬＣランタイムコンテナ５０をリリースする文脈においては、コンテナエンジン１５０，２５０の各々を「ノード」と称することもある。
　コンテナ生成モジュール２６０は、ユーザ操作に応じて、ＰＬＣランタイムコンテナ５０を生成する。本実施の形態においては、コンテナ生成モジュール２６０は、ＰＬＣ１００で実行されるべきユーザプログラムおよび関連する設定情報などから、ＰＬＣランタイムのイメージを含むＰＬＣランタイムコンテナ５０を生成する。すなわち、コンテナ生成モジュール２６０は、制御対象に対する制御演算を定義するユーザプログラムと当該ユーザプログラムを実行する実行環境とを内包するＰＬＣランタイムのイメージを含むＰＬＣランタイムコンテナ５０を生成する。
　オーケストレータ２７０は、ＰＬＣランタイムコンテナ５０を管理する処理を担当する。オーケストレータ２７０は、コンテナ生成モジュール２６０により生成されたＰＬＣランタイムコンテナ５０をコンテナハブに登録するなどの処理を行うとともに、ユーザ操作などに応じて、コンテナハブに登録されたＰＬＣランタイムコンテナ５０をいずれかのホスト（本実施の形態においては、ＰＬＣ１００のコンテナエンジン１５０あるいはサーバ２００のコンテナエンジン２５０）で実行するのかを管理する処理などを行う。このように、オーケストレータ２７０は、ＰＬＣ１００およびサーバ２００の一方または両方に対してＰＬＣランタイムコンテナ５０をリリースする。
　ＰＬＣ１００およびサーバ２００は、ＰＬＣランタイムコンテナ５０をデプロイするコンテナエンジン１５０および２５０をそれぞれ有しており、オーケストレータ２７０によりリリースされたＰＬＣランタイムコンテナ５０をデプロイすることで、ＰＬＣランタイムのイメージのインスタンスを生成して制御演算を実行することになる。
　さらに、オーケストレータ２７０は、ＰＬＣランタイムコンテナ５０の起動／停止の管理、ホスト間のネットワーク接続の管理、ストレージの管理、ＰＬＣランタイムコンテナ５０を実行させるホストのスケジューリング、ＰＬＣランタイムコンテナ５０のホストでの実行状態の管理などを担当する。
　なお、オーケストレータ２７０によるＰＬＣランタイムコンテナ５０のリリースは、予め定められたスケジュールに従って行われてもよいし、ユーザ操作に従って、リリースするＰＬＣランタイムコンテナ５０の選択およびリリース先の決定を行ってもよい。
　それぞれの構成要素による処理の詳細については、後述する。
　＜Ｄ．ＰＬＣランタイムコンテナの利用＞
　次に、ＰＬＣランタイムコンテナ５０を利用して、図２および図３に示すようなそれぞれのモードを実現する例を説明する。以下の説明では、主として、ＰＬＣ１００のコンテナエンジン１５０あるいはサーバ２００のコンテナエンジン２５０により提供される機能および処理について説明する。
　図８は、本実施の形態に係る制御システム１において提供されるモードを実現するための機能構成例を示す模式図である。
　図８（Ａ）を参照して、ＰＬＣ１００は、ローカルＯＳ１４０およびコンテナエンジン１５０を有している。
　（１）ローカル実行モードにおいては、コンテナエンジン１５０上にＰＬＣランタイム５１０のインスタンスが生成される。また、ＰＬＣ１００には、ＰＬＣランタイム５１０と物理Ｉ／Ｏ１６０とのやり取りを実現するための物理Ｉ／Ｏドライバ１４２も用意される。図８（Ａ）に示すような機能構成によって、ＰＬＣ１００による制御演算が実現される。
　図８（Ｂ）を参照して、（２）クラウド実行モードでは、ＰＬＣ１００のコンテナエンジン１５０上には、ＰＬＣランタイム５１０に代えて、仮想Ｉ／Ｏネットワークサーバ５４０のインスタンスが生成される。仮想Ｉ／Ｏネットワークサーバ５４０は、サーバ２００と物理Ｉ／Ｏ１６０のやり取りを仲介する処理を担当する。仮想Ｉ／Ｏネットワークサーバ５４０は、物理Ｉ／Ｏ１６０を含むＩ／Ｏ処理の結果を仮想Ｉ／Ｏネットワーククライアント５３０との間で同期する。
　このように、サーバ２００のコンテナエンジン２５０がＰＬＣランタイム５１０のイメージのインスタンスを生成する場合に、ＰＬＣ１００のコンテナエンジン１５０はＰＬＣ１００に接続されたフィールドデバイス１０を介してやり取りされるＩ／Ｏデータをサーバ２００に仲介する仮想Ｉ／Ｏネットワークサーバ５４０のインスタンスを生成する。
　一方、サーバ２００は、サーバＯＳ２４０およびコンテナエンジン２５０を有している。（２）クラウド実行モードにおいては、コンテナエンジン２５０上にＰＬＣランタイム５１０のインスタンスが生成される。さらに、コンテナエンジン２５０上には、仮想Ｉ／Ｏドライバ５２０および仮想Ｉ／Ｏネットワーククライアント５３０のインスタンスが生成される。
　このように、（２）クラウド実行モードにおいては、サーバ２００において、ＰＬＣランタイム５１０のインスタンスを生成するとともに、ＰＬＣ１００においても、仮想Ｉ／Ｏネットワークサーバ５４０のインスタンスを生成する。
　仮想Ｉ／Ｏネットワーククライアント５３０は、仮想Ｉ／Ｏネットワークサーバ５４０との間で、Ｉ／Ｏデータのやり取りを行う。
　仮想Ｉ／Ｏドライバ５２０は、図８（Ａ）に示すＰＬＣ１００の物理Ｉ／Ｏドライバ１４２をエミュレートするものであり、ＰＬＣランタイム５１０からのＩ／Ｏデータにアクセスするための内部コマンドに応答して、ＰＬＣ１００の物理Ｉ／Ｏ１６０へアクセスするのと同様の処理を行う。このように、サーバ２００のコンテナエンジン２５０がＰＬＣランタイム５１０のイメージのインスタンスを生成する場合に、ＰＬＣ１００に接続されたフィールドデバイス１０へアクセスする処理を担当する物理Ｉ／Ｏドライバ１４２をエミュレートする仮想Ｉ／Ｏドライバ５２０のインスタンスを生成する。
　仮想Ｉ／Ｏネットワークサーバ５４０と仮想Ｉ／Ｏネットワーククライアント５３０との間のやり取りは、ＰＬＣランタイム５１０に関して透過性を有している。すなわち、ＰＬＣ１００で実行されるＰＬＣランタイム５１０およびサーバ２００で実行されるＰＬＣランタイム５１０において、物理Ｉ／Ｏ１６０へのアクセス命令は同一である。仮想Ｉ／Ｏドライバ５２０、仮想Ｉ／Ｏネットワーククライアント５３０および仮想Ｉ／Ｏネットワークサーバ５４０は、当該同一のアクセス命令に応答してＰＬＣ１００の物理Ｉ／Ｏドライバ１４２が実行する処理と実質的に同一の処理を実現する。これらの処理の同一性によって、ＰＬＣランタイム５１０を図８（Ａ）～図８（Ｃ）のように互いに異なる実行環境上で動作させても、処理内容をそれぞれ異ならせる必要がない。
　図８（Ｃ）を参照して、（３）シミュレーションモードでは、コンテナエンジン２５０上に、仮想Ｉ／Ｏエミュレータ５５０および仮想Ｉ／Ｏネットワークサーバ５４０のインスタンスが生成される。
　仮想Ｉ／Ｏエミュレータ５５０は、ＰＬＣ１００の物理Ｉ／Ｏ１６０を模擬するモジュールであり、ＰＬＣランタイム５１０からの出力データに応答して、入力データを生成するといった処理を実行する。なお、仮想Ｉ／Ｏエミュレータ５５０は、ＰＬＣランタイム５１０を用いたシミュレーションを実現できればよいので、ＰＬＣランタイム５１０から与えられた出力データをそのまま入力データとして戻す処理（いわゆる、折り返し処理）を実行してもよい。あるいは、仮想Ｉ／Ｏエミュレータ５５０は、例えば、サーボドライバなどのモデルを有しており、ＰＬＣランタイム５１０から与えられた出力データを当該モデルに入力して得られる結果を入力データとして応答してもよい。
　このように、（３）シミュレーションモードでは、サーバ２００のコンテナエンジン２５０は、ＰＬＣランタイム５１０のインスタンスとともに、制御対象とやり取りされるＩ／Ｏデータをエミュレートする仮想Ｉ／Ｏエミュレータ５５０のインスタンスも生成する。
　仮想Ｉ／Ｏネットワークサーバ５４０は、図８（Ｂ）に示すＰＬＣ１００の仮想Ｉ／Ｏネットワークサーバ５４０と同様の処理を実行する。すなわち、仮想Ｉ／Ｏネットワーククライアント５３０と仮想Ｉ／Ｏネットワークサーバ５４０との間でＩ／Ｏデータをやり取りするための通信路を仮想的に形成する。仮想Ｉ／Ｏネットワークサーバ５４０は、仮想Ｉ／Ｏエミュレータ５５０によるＩ／Ｏ処理の結果を仮想Ｉ／Ｏネットワーククライアント５３０との間で同期する。
　なお、モードに応じて、仮想Ｉ／Ｏネットワーククライアント５３０の接続先は、ＰＬＣ１００の仮想Ｉ／Ｏネットワークサーバ５４０またはサーバ２００の仮想Ｉ／Ｏネットワークサーバ５４０に適宜変更される。
　図９は、本実施の形態に係る制御システム１において利用されるＰＬＣランタイムコンテナ５０の構成例を示す模式図である。図９を参照して、ＰＬＣランタイムコンテナ５０は、ＰＬＣランタイムイメージ５１と、仮想Ｉ／Ｏドライバイメージ５２と、仮想Ｉ／Ｏネットワーククライアントイメージ５３と、仮想Ｉ／Ｏネットワークサーバイメージ５４と、仮想Ｉ／Ｏエミュレータイメージ５５とを含む。これらのイメージは、デプロイされることで必要な処理を実行可能形式のデータである。
　ＰＬＣランタイムコンテナ５０は、マニフェスト５６をさらに含む。マニフェスト５６は、各実行環境および各モードにおいて、いずれのイメージを有効化するのか、および、どのようなリソースを利用するのかといった定義を含む。
　コンテナエンジン１５０，２５０は、マニフェスト５６を参照して、ＰＬＣランタイムコンテナ５０に含まれる各モジュールのイメージのうち、必要なイメージを選択する。典型的には、マニフェスト５６は、図８（Ａ）～図８（Ｃ）に示されるそれぞれのモードで利用される機能の定義を含む。
　図９に示すように、ＰＬＣランタイムコンテナ５０は、ＰＬＣ１００のコンテナエンジン１５０のみがデプロイするイメージ（例えば、仮想Ｉ／Ｏネットワークサーバイメージ５４）を含んでいてもよい。また、ＰＬＣランタイムコンテナ５０は、サーバ２００のコンテナエンジン２５０のみがデプロイするイメージ（例えば、仮想Ｉ／Ｏドライバイメージ５２、仮想Ｉ／Ｏネットワーククライアントイメージ５３、仮想Ｉ／Ｏエミュレータイメージ５５など）を含んでいてもよい。
　なお、図９には、同一のＰＬＣランタイムコンテナ５０を利用する構成例を示すが、リリース先および選択されるモードに応じて、ＰＬＣランタイムコンテナ５０の構成を異ならせてもよい。すなわち、選択されたモードにおいて必要なイメージおよび対応するマニフェスト５６を含むＰＬＣランタイムコンテナ５０を生成およびリリースするようにしてもよい。
　＜Ｅ．ＰＬＣランタイムコンテナの生成＞
　次に、ＰＬＣランタイムコンテナ５０の生成に係る機能および処理について説明する。
　図１０は、本実施の形態に係る制御システム１におけるＰＬＣランタイムコンテナ５０の生成に係る機能構成例を示す模式図である。図１０を参照して、サーバ２００のコンテナ生成モジュール２６０（図７）は、開発環境２６２と、システム構成マネージャ２６４とを含む。
　開発環境２６２は、ユーザ操作に従って、ＰＬＣシステム２で実行されるユーザプログラム２６６、および、ＰＬＣシステム２の構成を定義するＰＬＣシステム構成情報２６８を生成および出力する。典型的には、開発環境２６２は、エディタ機能、デバッグ機能、シミュレーション機能、整合性チェック機能などを含む。
　開発環境２６２は、サーバ２００上に実現されてもよいし、開発保守端末３００が開発プログラムを実行することで実現されてもよい。
　ユーザは、開発環境２６２上で、制御システム１に含まれるＰＬＣシステム２の構成を定義する。定義される内容としては、ＰＬＣ１００の台数およびサーバ２００上で利用するリソースなどを含む。また、ユーザは、開発環境２６２上で、制御対象に応じたユーザプログラム２６６を作成する。
　また、ユーザは、開発環境２６２を介して、ＰＬＣランタイムコンテナ５０のリリースやデプロイの指示を行うこともできる。
　システム構成マネージャ２６４は、ユーザ操作に従って、ユーザプログラム２６６およびＰＬＣシステム構成情報２６８に基づいて、ＰＬＣランタイムコンテナ５０を生成する。ＰＬＣランタイムコンテナ５０は、各モジュールのイメージに加えて、マニフェスト５６を含む。
　システム構成マネージャ２６４は、ＰＬＣランタイムコンテナ５０の生成に加えて、システム構成プロファイル６０を生成および出力する。システム構成プロファイル６０は、ＰＬＣランタイムコンテナ５０のリリース先およびＰＬＣ１００の識別情報などを含む。
　また、システム構成プロファイル６０は、利用するコンテナハブ２７６の識別情報、利用するＰＬＣランタイムコンテナ５０の識別情報、仮想ノードの使用許否を示す情報、利用する仮想ノードの最大数などを含んでいてもよい。このとき、システム構成プロファイル６０は、ＰＬＣランタイムコンテナ５０に関する情報が登録されるリポジトリの情報も含まれる。
　なお、システム構成プロファイル６０は、制御システム１毎に生成されてもよいし、制御システム１に含まれるＰＬＣシステム２毎に生成されてもよい。
　システム構成プロファイル６０は、コンテナ構成プロファイルを含んでいてもよい。コンテナ構成プロファイルは、ＰＬＣランタイムコンテナ５０を特定するための識別情報と、ＰＬＣランタイムコンテナ５０が対象とするＰＬＣ１００および各ＰＬＣ１００に接続されるデバイス（モータやロボットなど）などの情報を含む。また、コンテナ構成プロファイルは、デバイスを制御するにあたって、開発環境上で追加の必要機能（以下、「機能モジュール」とも称す。）の要否などの情報を含んでいてもよい。
　＜Ｆ．ＰＬＣランタイムコンテナのリリースおよび実行管理＞
　次に、ＰＬＣランタイムコンテナ５０のリリースおよび実行管理に係る機能および処理について説明する。
　図１１は、本実施の形態に係る制御システム１におけるＰＬＣランタイムコンテナ５０のリリースおよび実行管理に係る機能構成例を示す模式図である。図１１を参照して、サーバ２００のオーケストレータ２７０（図７）は、コンテナマネージャ２７２と、ノードマネージャ２７４とを含む。
　コンテナマネージャ２７２は、ＰＬＣランタイムコンテナ５０のリリース、デプロイ、実行などを管理する。コンテナマネージャ２７２は、ＰＬＣランタイムコンテナ５０を登録するコンテナハブ２７６と、コンテナハブ２７６に登録されたＰＬＣランタイムコンテナ５０の状態を管理するリポジトリ２７８とを管理する。
　コンテナマネージャ２７２は、コンテナ生成モジュール２６０（図１０参照）からＰＬＣランタイムコンテナ５０が提供されると、付随するシステム構成プロファイル６０を参照して、ＰＬＣランタイムコンテナ５０をコンテナハブ２７６に登録するとともに、リポジトリ２７８に対応するエントリを追加する。
　コンテナハブ２７６は、コンテナ生成モジュール２６０により生成されるＰＬＣランタイムコンテナ５０をリリース可能なＰＬＣ１００の識別情報と関連付けて登録する。
　リポジトリ２７８の各エントリは、コンテナハブ２７６に登録されているＰＬＣランタイムコンテナ５０を特定するためのコンテナ名と、ノード名とノードアドレスとを対応付ける名前空間と、ＰＬＣランタイムコンテナ５０の状態を示すコンテナ状態とを含む。名前空間は、ＰＬＣランタイム５１０からのノード名の指定と、対応するノードアドレスとをマッピングするものである。このように、リポジトリ２７８は、サーバ２００のコンテナエンジン２５０がＰＬＣランタイム５１０のインスタンスを生成する場合に、コンテナエンジン２５０にアクセスするためのアドレスを管理する。
　ノードマネージャ２７４は、コンテナマネージャ２７２からの要求などに応じて、ＰＬＣランタイムコンテナ５０のリリース先のノード（ＰＬＣ１００のコンテナエンジン１５０あるいはサーバ２００のコンテナエンジン２５０）の探索、ノード状態を取得、仮想的なノードの生成などを行う。
　仮想的なノードの生成に関して、ノードマネージャ２７４は、サーバ２００に対してＰＬＣランタイムコンテナ５０をリリースする場合に、ＰＬＣランタイムコンテナ５０をデプロイするコンテナエンジン２５０が存在しなければ、コンテナエンジン２５０を含むノードを仮想的に生成する。
　＜Ｇ．ユースケース＞
　次に、いくつかのユースケースについて説明する。
　図１２は、本実施の形態に係る制御システム１の典型的なユースケースを示す模式図である。図１２に示すユースケースでは、ＰＬＣ１００－１，１００－２，１００－３が制御対象を制御する場合を想定する。
　図１２（Ａ）に示すユースケース１では、ＰＬＣ１００－１，１００－２，１００－３が実行する制御演算のすべてをサーバ２００でシミュレーションする例を示す。すなわち、ＰＬＣ１００－１，１００－２，１００－３のいずれについても、シミュレーションモードが実現される。この場合、ＰＬＣ１００－１，１００－２，１００－３は必ずしも実在しなくてもよい。
　図１２（Ｂ）に示すユースケース２では、ＰＬＣ１００－１が実行する制御演算を、ＰＬＣ１００－１の物理Ｉ／Ｏ１６０－１を利用しつつ、サーバ２００上で実行する例を示す。すなわち、ＰＬＣ１００－１については、クラウド実行モードが実現される。なお、ＰＬＣ１００－２，１００－３については、図１２（Ａ）と同様に、シミュレーションモードが実現される。この場合、ＰＬＣ１００－２，１００－３は必ずしも実在しなくてもよい。
　図１２（Ｃ）に示すユースケース３では、ＰＬＣ１００－２が自装置の物理Ｉ／Ｏ１６０－２を利用して実行する例を示す。すなわち、ＰＬＣ１００－１については、ローカル実行モードが実現される。なお、ＰＬＣ１００－１については、図１２（Ｂ）と同様に、クラウド実行モードが実現され、ＰＬＣ１００－３については、図１２（Ａ）と同様に、シミュレーションモードが実現される。この場合、ＰＬＣ１００－３は必ずしも実在しなくてもよい。
　（ｇ１：ユースケース１）
　図１３は、図１２（Ａ）に示すユースケース１における処理手順の一例を概略する模式図である。図１３には、ユーザプログラム２６６を含むＰＬＣランタイム５１０（ＰＬＣランタイムコンテナ５０）を新規作成する場合を示す。また、ＰＬＣランタイムコンテナ５０は、シミュレーションモードでリリースされる。
　図１３を参照して、ユーザは、設計するＰＬＣシステム２の構成の定義を入力する（（１）構成定義）。すると、システム構成マネージャ２６４は、入力されたＰＬＣシステム２に対応するシステム構成プロファイル６０を生成する（（２）システム構成プロファイル生成）。
　続いて、ユーザは、開発環境２６２を利用してユーザプログラム２６６を作成する（（３）ユーザプログラム作成）。そして、システム構成マネージャ２６４は、ＰＬＣランタイムコンテナ５０を生成する（（４）ＰＬＣランタイムコンテナ生成）。さらに、コンテナマネージャ２７２は、生成されたＰＬＣランタイムコンテナ５０をコンテナハブ２７６に登録する（（５）ＰＬＣランタイムコンテナ登録）。以上の処理によって、ＰＬＣランタイムコンテナ５０の生成および登録が完了する。
　ユーザがいずれかのＰＬＣランタイムコンテナ５０のリリース（この場合には、シミュレーションモード）を指示すると（（６）リリース指示）、ノードマネージャ２７４は、リリース先となる仮想ノードを生成する（（７）仮想ノード生成）とともに、生成した仮想ノードのノードアドレスをノード名と対応付けてリポジトリ２７８に登録する（（８）ノード名登録）。そして、選択されたＰＬＣランタイムコンテナ５０がリリース先の仮想ノードへ送信される（（９）ＰＬＣランタイムコンテナリリース）。仮想ノードのコンテナエンジン２５０－１は、ＰＬＣランタイムコンテナ５０をデプロイする（（１０）ＰＬＣランタイムコンテナデプロイ）。仮想ノードのコンテナエンジン２５０－１は、デプロイしたＰＬＣランタイムコンテナ５０のコンテナ名をリポジトリ２７８に登録する（（１１）コンテナ名登録）。仮想ノードのコンテナエンジン２５０－１は、リポジトリ２７８の内容を参照することで、Ｉ／Ｏデータのやり取りにおいて、送信先または受信先のノード名に対応するノードアドレスを解決できる。
　また、仮想ノードのコンテナエンジン２５０－１は、デプロイして生成されたＰＬＣランタイムコンテナ５０のインスタンスの内容をコンテナハブ２７６に反映する（（１２）デプロイ内容反映）。このように、コンテナハブ２７６に反映することで、仮想ノードで次回起動する際に再利用が容易になる。
　図１４は、図１２（Ａ）に示すユースケース１における別の処理手順の一例を概略する模式図である。図１４には、図１３に示すような処理手順で作成したＰＬＣランタイムコンテナ５０を再利用する場合を示す。また、ＰＬＣランタイムコンテナ５０は、シミュレーションモードでリリースされる。
　図１４を参照して、ユーザは、作成済のＰＬＣシステム２の再利用を指示する（（１）再利用指示）。すると、システム構成マネージャ２６４は、指示されたＰＬＣシステム２に対応するシステム構成プロファイル６０をロードする（（２）システム構成プロファイルロード）。
　続いて、ユーザは、開発環境２６２を利用してユーザプログラム２６６を更新する（（３）ユーザプログラム更新）。そして、システム構成マネージャ２６４は、ＰＬＣランタイムコンテナ５０を更新する（（４）ＰＬＣランタイムコンテナ更新）。さらに、コンテナマネージャ２７２は、更新されたＰＬＣランタイムコンテナ５０をコンテナハブ２７６に登録する（（５）ＰＬＣランタイムコンテナ登録）。以上の処理によって、ＰＬＣランタイムコンテナ５０の更新（再生成）および登録が完了する。
　ユーザがいずれかのＰＬＣランタイムコンテナ５０のリリース（この場合には、シミュレーションモード）を指示すると（（６）リリース指示）、選択されたＰＬＣランタイムコンテナ５０がリリース先の仮想ノードへ送信される（（７）ＰＬＣランタイムコンテナリリース）。この例では、既に仮想ノードにおいてＰＬＣランタイムが実現されている場合を想定しているため、リリース先となる仮想ノードを新たに生成する必要はない。
　仮想ノードのコンテナエンジン２５０－１は、ＰＬＣランタイムコンテナ５０をデプロイする（（８）ＰＬＣランタイムコンテナデプロイ）。これによって、更新後のユーザプログラムに対応するＰＬＣランタイムが実現される。なお、多くの場合において、リポジトリ２７８の内容を更新する必要はない。
　また、仮想ノードのコンテナエンジン２５０－１は、デプロイして生成されたＰＬＣランタイムコンテナ５０のインスタンスの内容をコンテナハブ２７６に反映する（（９）デプロイ内容反映）。
　（ｇ２：ユースケース２）
　図１５は、図１２（Ｂ）に示すユースケース２における処理手順の一例を概略する模式図である。図１５には、ユーザプログラム２６６を含むＰＬＣランタイム５１０（ＰＬＣランタイムコンテナ５０）を新規作成する場合を示す。また、ＰＬＣランタイムコンテナ５０は、クラウド実行モードでリリースされる。
　図１５を参照して、ユーザは、設計するＰＬＣシステム２の構成の定義を入力する（（１）構成定義）。すると、システム構成マネージャ２６４は、入力されたＰＬＣシステム２に対応するシステム構成プロファイル６０を生成する（（２）システム構成プロファイル生成）。
　続いて、ユーザは、開発環境２６２を利用してユーザプログラム２６６を作成する（（３）ユーザプログラム作成）。そして、システム構成マネージャ２６４は、ＰＬＣランタイムコンテナ５０を生成する（（４）ＰＬＣランタイムコンテナ生成）。さらに、コンテナマネージャ２７２は、生成されたＰＬＣランタイムコンテナ５０をコンテナハブ２７６に登録する（（５）ＰＬＣランタイムコンテナ登録）。以上の処理によって、ＰＬＣランタイムコンテナ５０の生成および登録が完了する。
　ユーザがいずれかのＰＬＣランタイムコンテナ５０のリリース（この場合には、クラウド実行モード）を指示すると（（６）リリース指示）、ノードマネージャ２７４は、リリース先となる仮想ノードを生成する（（７）仮想ノード生成）とともに、生成した仮想ノードのノードアドレスをノード名と対応付けてリポジトリ２７８に登録する（（８）ノード名登録）。
　そして、選択されたＰＬＣランタイムコンテナ５０がリリース先の仮想ノードへ送信される（（９）ＰＬＣランタイムコンテナリリース）。仮想ノードのコンテナエンジン２５０－１は、ＰＬＣランタイムコンテナ５０をデプロイする（（１０）ＰＬＣランタイムコンテナデプロイ）。コンテナエンジン２５０－１によるデプロイによって、ＰＬＣランタイム５１０、仮想Ｉ／Ｏドライバ５２０および仮想Ｉ／Ｏネットワーククライアント５３０のインスタンスが生成される（図８（Ｂ）参照）。
　また、選択されたＰＬＣランタイムコンテナ５０はリリース先のＰＬＣ１００－１へも送信される（（１１）ＰＬＣランタイムコンテナリリース）。ＰＬＣ１００－１のコンテナエンジン１５０は、ＰＬＣランタイムコンテナ５０をデプロイする（（１２）ＰＬＣランタイムコンテナデプロイ）。コンテナエンジン１５０によるデプロイによって、仮想Ｉ／Ｏネットワークサーバ５４０のインスタンスが生成される。
　仮想ノードのコンテナエンジン２５０－１は、デプロイしたＰＬＣランタイムコンテナ５０のコンテナ名をリポジトリ２７８に登録する（（１３）コンテナ名登録）。また、仮想ノードのコンテナエンジン２５０－１は、デプロイして生成されたＰＬＣランタイムコンテナ５０のインスタンスの内容をコンテナハブ２７６に反映する（（１４）デプロイ内容反映）。
　図１６は、図１２（Ｂ）に示すユースケース２における別の処理手順の一例を概略する模式図である。図１６には、ＰＬＣランタイム５１０をローカル実行モードでリリースしたものの、ＰＬＣ１００でのリソース不足により、クラウド実行モードに変更する場合を示す。
　図１６を参照して、ユーザは、設計するＰＬＣシステム２の構成の定義を入力する（（１）構成定義）。すると、システム構成マネージャ２６４は、入力されたＰＬＣシステム２に対応するシステム構成プロファイル６０を生成する（（２）システム構成プロファイル生成）。
　続いて、ユーザは、開発環境２６２を利用してユーザプログラム２６６を作成する（（３）ユーザプログラム作成）。そして、システム構成マネージャ２６４は、ＰＬＣランタイムコンテナ５０を生成する（（４）ＰＬＣランタイムコンテナ生成）。さらに、コンテナマネージャ２７２は、生成されたＰＬＣランタイムコンテナ５０をコンテナハブ２７６に登録する（（５）ＰＬＣランタイムコンテナ登録）。以上の処理によって、ＰＬＣランタイムコンテナ５０の生成および登録が完了する。
　ユーザがいずれかのＰＬＣランタイムコンテナ５０のリリース（この場合には、ローカル実行モード）を指示すると（（６）リリース指示）、選択されたＰＬＣランタイムコンテナ５０はリリース先のＰＬＣ１００－１へ送信される（（７）ＰＬＣランタイムコンテナリリース）。ＰＬＣ１００－１のコンテナエンジン１５０は、ＰＬＣランタイムコンテナ５０をデプロイする（（８）ＰＬＣランタイムコンテナデプロイ）。ここで、ＰＬＣ１００－１の容量オーバにより、ＰＬＣランタイムコンテナ５０のデプロイに失敗したとする。
　ここで、システム構成マネージャ２６４は、ローカル実行モードからクラウド実行モードに処理を変更したとする。すると、ノードマネージャ２７４は、リリース先となる仮想ノードを生成する（（９）仮想ノード生成）とともに、生成した仮想ノードのノードアドレスをノード名と対応付けてリポジトリ２７８に登録する（（１０）ノード名登録）。
　そして、選択されたＰＬＣランタイムコンテナ５０がリリース先の仮想ノードへ送信される（（１１）ＰＬＣランタイムコンテナリリース）。仮想ノードのコンテナエンジン２５０－１は、ＰＬＣランタイムコンテナ５０をデプロイする（（１２）ＰＬＣランタイムコンテナデプロイ）。
　また、選択されたＰＬＣランタイムコンテナ５０はリリース先のＰＬＣ１００－１へも再度送信される（（１３）ＰＬＣランタイムコンテナリリース）。ＰＬＣ１００－１のコンテナエンジン１５０は、ＰＬＣランタイムコンテナ５０をクラウド実行モードでデプロイする（（１４）ＰＬＣランタイムコンテナデプロイ）。コンテナエンジン１５０によるデプロイによって、仮想Ｉ／Ｏネットワークサーバ５４０のインスタンスが生成される。
　仮想ノードのコンテナエンジン２５０－１は、デプロイしたＰＬＣランタイムコンテナ５０のコンテナ名をリポジトリ２７８に登録する（（１５）コンテナ名登録）。また、仮想ノードのコンテナエンジン２５０－１は、デプロイして生成されたＰＬＣランタイムコンテナ５０のインスタンスの内容をコンテナハブ２７６に反映する（（１６）デプロイ内容反映）。
　（ｇ３：ユースケース３）
　図１７は、図１２（Ｃ）に示すユースケース３における処理手順の一例を概略する模式図である。図１７には、ＰＬＣランタイム５１０をローカル実行モード、クラウド実行モードおよびシミュレーションモードでそれぞれリリースした場合を示す。
　図１７を参照して、ユーザは、設計するＰＬＣシステム２の構成の定義を入力する（（１）構成定義）。すると、システム構成マネージャ２６４は、入力されたＰＬＣシステム２に対応するシステム構成プロファイル６０を生成する（（２）システム構成プロファイル生成）。
　続いて、ユーザは、開発環境２６２を利用してユーザプログラム２６６を作成する（（３）ユーザプログラム作成）。そして、システム構成マネージャ２６４は、ＰＬＣランタイムコンテナ５０を生成する（（４）ＰＬＣランタイムコンテナ生成）。さらに、コンテナマネージャ２７２は、生成されたＰＬＣランタイムコンテナ５０をコンテナハブ２７６に登録する（（５）ＰＬＣランタイムコンテナ登録）。以上の処理によって、ＰＬＣランタイムコンテナ５０の生成および登録が完了する。
　ユーザは、ＰＬＣ１００－１についてローカル実行モードを選択し、ＰＬＣ１００－２についてクラウド実行モードを選択し、ＰＬＣ１００－３についてシミュレーションモードを選択したとする（（６）リリース指示）。
　ノードマネージャ２７４は、リリース先となる仮想ノードを生成する（（７）仮想ノード生成）とともに、生成した仮想ノードのノードアドレスをノード名と対応付けてリポジトリ２７８に登録する（（８）ノード名登録）。
　ローカル実行モードで選択されたＰＬＣランタイムコンテナ５０は、リリース先のＰＬＣ１００－１へ送信され（（９）ＰＬＣランタイムコンテナリリース）、ＰＬＣ１００－１のコンテナエンジン１５０がＰＬＣランタイムコンテナ５０をデプロイする（（１０）ＰＬＣランタイムコンテナデプロイ）。
　クラウド実行モードで選択されたＰＬＣランタイムコンテナ５０は、リリース先のＰＬＣ１００－２へ送信され（（１１）ＰＬＣランタイムコンテナリリース）、ＰＬＣ１００－２のコンテナエンジン１５０がＰＬＣランタイムコンテナ５０をデプロイする（（１２）ＰＬＣランタイムコンテナデプロイ）。また、クラウド実行モードで選択されたＰＬＣランタイムコンテナ５０は、リリース先の仮想ノードへも送信され（（１３）ＰＬＣランタイムコンテナリリース）、仮想ノードのコンテナエンジン２５０－２がＰＬＣランタイムコンテナ５０をデプロイする（（１４）ＰＬＣランタイムコンテナデプロイ）。
　シミュレーションモードで選択されたＰＬＣランタイムコンテナ５０は、リリース先の仮想ノードへも送信され（（１５）ＰＬＣランタイムコンテナリリース）、仮想ノードのコンテナエンジン２５０－３がＰＬＣランタイムコンテナ５０をデプロイする（（１６）ＰＬＣランタイムコンテナデプロイ）。
　仮想ノードのコンテナエンジン２５０－２および２５０－３は、デプロイしたＰＬＣランタイムコンテナ５０のコンテナ名をリポジトリ２７８に登録する（（１７）コンテナ名登録）。また、仮想ノードのコンテナエンジン２５０－２および２５０－３は、デプロイして生成されたＰＬＣランタイムコンテナ５０のインスタンスの内容をコンテナハブ２７６に反映する（（１８）デプロイ内容反映）。
　＜Ｈ．処理手順＞
　次に、本実施の形態に従う制御システム１における処理手順の一例について説明する。
　図１８は、本実施の形態に従う制御システム１におけるＰＬＣランタイムコンテナ５０の生成に関する処理手順の一例を示すフローチャートである。図１９は、本実施の形態に従う制御システム１におけるＰＬＣランタイムコンテナ５０のリリースおよび実行管理に関する処理手順の一例を示すフローチャートである。図１８および図１９に示す各ステップは、典型的には、サーバ２００のプロセッサ２０２がプログラムを実行することで実現される。
　図１８を参照して、ユーザは、開発環境２６２にアクセスして、ＰＬＣシステム２の構成を定義する。すなわち、サーバ２００の開発環境２６２は、ユーザからＰＬＣシステム２の構成の定義を受け付ける（ステップＳ１００）。より具体的には、ユーザは、対象とするＰＬＣ１００および各ＰＬＣ１００に接続されるデバイス（モータやロボットなど）などを指定する。
　ユーザの定義に応答して、サーバ２００の開発環境２６２は、ＰＬＣシステム構成情報２６８を生成および出力する（ステップＳ１０２）。続いて、サーバ２００のシステム構成マネージャ２６４は、指定されたＰＬＣ１００にそれぞれ対応するシステム構成プロファイル６０を生成および出力する（ステップＳ１０４）。すなわち、システム構成プロファイル６０は、指定されたＰＬＣ１００の数だけ生成される。また、システム構成プロファイル６０の各々は、対応するＰＬＣ１００に接続されるデバイスの情報を含む。
　サーバ２００の開発環境２６２は、ＩＥＣプログラムを生成するためのエディタ環境を提供し、ユーザにより作成されるユーザプログラム２６６を受け付ける（ステップＳ１０６）。
　サーバ２００の開発環境２６２は、システム構成プロファイル６０を参照して、ＰＬＣ１００に接続されるいずれかのデバイスに関連付けられた機能モジュールが存在するか否かを判断する（ステップＳ１０８）。いずれかのデバイスに関連付けられた機能モジュールが存在すれば（ステップＳ１０８においてＹＥＳ）、サーバ２００の開発環境２６２は、当該関連付けられた機能モジュールに関連するエディタ環境を提供し、ユーザからの各種設定を受け付ける（ステップＳ１１０）。
　ユーザによる設定操作が完了すると、サーバ２００のシステム構成マネージャ２６４は、ＰＬＣランタイムに必要な標準テンプレートをロードする（ステップＳ１１２）。サーバ２００のシステム構成マネージャ２６４は、システム構成プロファイル６０を参照して、ＰＬＣ１００に接続されるいずれかのデバイスに関連付けられたテンプレートが必要であるか否かを判断する（ステップＳ１１４）。いずれかのデバイスに関連付けられたテンプレートが必要であれば（ステップＳ１１４においてＹＥＳ）、サーバ２００のシステム構成マネージャ２６４は、必要なテンプレートをロードする（ステップＳ１１６）。
　そして、サーバ２００のシステム構成マネージャ２６４は、ユーザが生成したユーザプログラムと、ロードしてテンプレートとに基づいて、ＰＬＣランタイムコンテナ５０を生成する（ステップＳ１１８）。
　続いて、サーバ２００のコンテナマネージャ２７２は、コンテナ生成モジュール２６０により生成されたＰＬＣランタイムコンテナ５０をコンテナハブ２７６に登録する（ステップＳ１２０）。
　以上の手順により、ＰＬＣランタイムコンテナ５０の生成に関する処理は完了する。すなわち、サーバ２００は、制御対象に対する制御演算を定義するユーザプログラムとユーザプログラムを実行する実行環境とを内包するＰＬＣランタイムのイメージを含むコンテナを生成する。
　図１９を参照して、サーバ２００の開発環境２６２は、ユーザ操作に応答して、コンテナハブ２７６およびリポジトリ２７８を参照して、予め用意されているＰＬＣランタイムコンテナ５０の一覧を表示する（ステップＳ２００）。
　ユーザがいずれかのＰＬＣランタイムコンテナ５０およびモードを選択すると、サーバ２００のシステム構成マネージャ２６４は、いずれのモードが選択されたかを判断する（ステップＳ２０２）。
　ローカル実行モードが選択されると（ステップＳ２０２において「ローカル実行」）、サーバ２００のノードマネージャ２７４は、システム構成プロファイル６０を参照して、選択されたＰＬＣランタイムコンテナ５０のリリース先となるＰＬＣ１００が有効に存在しているか否かを判断する（ステップＳ２０４）。
　リリース先となるＰＬＣ１００が有効に存在していれば（ステップＳ２０４においてＹＥＳ）、サーバ２００のコンテナマネージャ２７２は、ＰＬＣランタイムコンテナ５０のリリースに応じて、リポジトリ２７８の内容を更新する（ステップＳ２０６）。続いて、サーバ２００のシステム構成マネージャ２６４は、選択されたＰＬＣランタイムコンテナ５０をリリース先のＰＬＣ１００へ送信する（ステップＳ２０８）。送信先のＰＬＣ１００のコンテナエンジン１５０は、ＰＬＣランタイムコンテナ５０に含まれるマニフェスト５６を参照して、ＰＬＣランタイムコンテナ５０をデプロイする（ステップＳ２１０）。これにより、リリース先のＰＬＣ１００では、ＰＬＣランタイム５１０が実現される。そして、処理は終了する。
　一方、リリース先となるＰＬＣ１００が有効に存在していれば（ステップＳ２０４においてＮＯ）、サーバ２００の開発環境２６２は、ユーザに対してリソース先のＰＬＣ１００が有効に存在していない旨を通知する（ステップＳ２１２）。そして、処理は終了する。
　クラウド実行モードが選択されると（ステップＳ２０２において「クラウド実行モード」）、サーバ２００のノードマネージャ２７４は、システム構成プロファイル６０を参照して、選択されたＰＬＣランタイムコンテナ５０のリリース先となるＰＬＣ１００が有効に存在しているか否かを判断する（ステップＳ２１４）。
　リリース先となるＰＬＣ１００が有効に存在していれば（ステップＳ２１４においてＹＥＳ）、サーバ２００のノードマネージャ２７４は、システム構成プロファイル６０を参照して、選択されたＰＬＣランタイムコンテナ５０のリリース先となる仮想ノードがサーバ２００上に有効に存在しているか否かを判断する（ステップＳ２１６）。
　リリース先となる仮想ノードがサーバ２００上に有効に存在していなければ（ステップＳ２１６においてＮＯ）、サーバ２００のノードマネージャ２７４は、必要な数の仮想ノードを生成する（ステップＳ２１８）。仮想ノードは、コンテナエンジン２５０を含む、ＰＬＣランタイムコンテナ５０をデプロイ可能な環境を提供するものである。
　リリース先となる仮想ノードがサーバ２００上に有効に存在していれば（ステップＳ２１６においてＹＥＳ）、ステップＳ２１８の処理はスキップされる。
　サーバ２００のコンテナマネージャ２７２は、ＰＬＣランタイムコンテナ５０のリリースに応じて、リポジトリ２７８の内容を更新する（ステップＳ２２０）。そして、サーバ２００のシステム構成マネージャ２６４は、選択されたＰＬＣランタイムコンテナ５０をリリース先のＰＬＣ１００およびサーバ２００上の仮想ノードへ送信する（ステップＳ２２２）。一方、送信先のサーバ２００の仮想ノードに含まれるコンテナエンジン２５０も、ＰＬＣランタイムコンテナ５０に含まれるマニフェスト５６を参照して、ＰＬＣランタイムコンテナ５０をデプロイする（ステップＳ２２４）。これにより、リリース先のＰＬＣ１００では、仮想Ｉ／Ｏネットワークサーバ５４０が実現され、サーバ２００上の仮想ノードでは、ＰＬＣランタイム５１０が実現される。
　一方、リリース先となるＰＬＣ１００が有効に存在していなければ（ステップＳ２１４においてＮＯ）、サーバ２００の開発環境２６２は、ユーザに対してリソース先のＰＬＣ１００が有効に存在していない旨を通知する（ステップＳ２２６）。そして、処理は終了する。
　シミュレーションモードが選択されると（ステップＳ２０２において「シミュレーションモード」）、サーバ２００のノードマネージャ２７４は、システム構成プロファイル６０を参照して、選択されたＰＬＣランタイムコンテナ５０のリリース先となる仮想ノードがサーバ２００上に有効に存在しているか否かを判断する（ステップＳ２２８）。
　リリース先となる仮想ノードがサーバ２００上に有効に存在していなければ（ステップＳ２２８においてＮＯ）、サーバ２００のノードマネージャ２７４は、必要な数の仮想ノードを生成する（ステップＳ２３０）。
　リリース先となる仮想ノードがサーバ２００上に有効に存在していれば（ステップＳ２２８においてＹＥＳ）、ステップＳ２３０の処理はスキップされる。
　サーバ２００のコンテナマネージャ２７２は、ＰＬＣランタイムコンテナ５０のリリースに応じて、リポジトリ２７８の内容を更新する（ステップＳ２３２）。そして、サーバ２００のシステム構成マネージャ２６４は、選択されたＰＬＣランタイムコンテナ５０をサーバ２００上の仮想ノードへ送信する（ステップＳ２３４）。送信先のサーバ２００の仮想ノードに含まれるコンテナエンジン２５０は、ＰＬＣランタイムコンテナ５０に含まれるマニフェスト５６を参照して、ＰＬＣランタイムコンテナ５０をデプロイする（ステップＳ２３６）。これにより、リリース先のサーバ２００上の仮想ノードでは、ＰＬＣランタイム５１０および仮想Ｉ／Ｏエミュレータ５５０を含む、シミュレーションできる環境が実現される。このように、ＰＬＣ１００およびサーバ２００の一方または両方に対してＰＬＣランタイムコンテナ５０をリリースする処理が実行される。
　＜Ｉ．その他の実施の形態＞
　説明の便宜上、サーバ２００がコンテナエンジン２５０と、コンテナ生成モジュール２６０と、オーケストレータ２７０（図７参照）とを有しているとしてしたが、サーバ２００の実体がクラウド化および仮想化されている場合には、同一のハードウェアがこれらのモジュールのすべてを実現する必要はなく、１または複数のプロセッサを適宜用いて実現することができる。
　＜Ｊ．付記＞
　上述したような本実施の形態は、以下のような技術思想を含む。
　［構成１］
　１または複数の制御装置（１００）と１または複数のサーバ（２００）とを備える制御システム（１）であって、
　制御対象に対する制御演算を定義するユーザプログラム（２６６）と当該ユーザプログラムを実行する実行環境とを内包するランタイム（５１０）のイメージ（５１）を含むコンテナ（５０）を生成する生成モジュール（２６０）と、
　前記制御装置および前記サーバの一方または両方に対して前記コンテナをリリースするオーケストレータ（２７０）とを備え、
　前記制御装置および前記サーバは、前記コンテナをデプロイするコンテナエンジン（１５０，２５０）を有しており、前記オーケストレータによりリリースされたコンテナをデプロイすることで、前記ランタイム（５１０）のインスタンスを生成して前記制御演算を実行する、制御システム。
　［構成２］
　前記サーバのコンテナエンジン（２５０）は、前記ランタイムのインスタンスとともに、前記制御対象とやり取りされる入出力データをエミュレートするエミュレータ（５５０）のインスタンスも生成する、構成１に記載の制御システム。
　［構成３］
　前記サーバのコンテナエンジン（２５０）が前記ランタイムのインスタンスを生成する場合に、前記制御装置のコンテナエンジンが前記制御装置に接続されたデバイス（１０）を介してやり取りされる入出力データを前記サーバに仲介するネットワークサーバ（５４０）のインスタンスを生成する、構成１に記載の制御システム。
　［構成４］
　前記サーバのコンテナエンジン（２５０）は、前記ランタイムのインスタンスを生成する場合に、前記制御装置に接続されたデバイスへアクセスする処理を担当するＩ／Ｏドライバをエミュレートする仮想Ｉ／Ｏドライバ（５２０）のインスタンスを生成する、構成１～３のいずれか１項に記載の制御システム。
　［構成５］
　前記コンテナは、前記制御装置のコンテナエンジンのみがデプロイするイメージ（５４）と、前記サーバのコンテナエンジンのみがデプロイするイメージ（５２，５３，５５）とのうち、少なくとも一方を含む、構成１～４のいずれか１項に記載の制御システム。
　［構成６］
　前記サーバのコンテナエンジンが前記ランタイムのインスタンスを生成する場合に、当該コンテナエンジンにアクセスするためのアドレスを管理するリポジトリ（２７８）をさらに備える、構成１～５のいずれか１項に記載の制御システム。
　［構成７］
　前記サーバに対して前記コンテナをリリースする場合に、当該コンテナをデプロイするコンテナエンジンが存在しなければ、コンテナエンジンを含むノードを仮想的に生成するノードマネージャ（２７４）をさらに備える、構成１～６のいずれか１項に記載の制御システム。
　［構成８］
　前記生成モジュールにより生成されるコンテナをリリース可能な制御装置の識別情報と関連付けて登録するコンテナハブ（２７６）をさらに備える、構成１～７のいずれか１項に記載の制御システム。
　［構成９］
　前記オーケストレータは、ユーザ操作に従って、リリースするコンテナを選択するとともに、リリース先を決定する、構成１～８のいずれか１項に記載の制御システム。
　［構成１０］
　１または複数の制御装置（１００）と１または複数のサーバ（２００）とを備える制御システム（１）において実行される制御方法であって、
　制御対象に対する制御演算を定義するユーザプログラムと当該ユーザプログラムを実行する実行環境とを内包するランタイムのイメージを含むコンテナを生成するステップ（Ｓ１００～Ｓ１２０）と、
　前記制御装置および前記サーバの一方または両方に対して前記コンテナをリリースするステップ（Ｓ２００～Ｓ２３４）とを備え、
　前記制御装置および前記サーバは、前記コンテナをデプロイするコンテナエンジンを有しており、前記リリースされたコンテナをデプロイすることで、前記ランタイムのインスタンスを生成して前記制御演算を実行する、制御方法。
　＜Ｋ．利点＞
　本実施の形態によれば、コンテナ技術およびオーケストレーション技術を利用可能な制御システムを実現できる。これらの技術を利用することで、例えば、制御演算のシミュレーションなどを行う場合には、サーバ（クラウド）のリソースをスケーラブルに利用できるので、より複雑および大規模なシミュレーションであっても、実時間で行うことができる。
　本実施の形態によれば、ＰＬＣに接続されたデバイスを利用しつつ、制御演算自体はサーバで実行することもできるので、フィールド側に配置されるＰＬＣの小型化および簡素化などを行うこともできる。
　本実施の形態によれば、複数のＰＬＣから構成される場合であっても、ＰＬＣの各々について、ローカル実行モード、クラウド実行モード、シミュレーションモードの３つのモードで制御演算を実行できるので、複数のＰＬＣを組み合わせて検証する必要がある場合でも、そのときの状況で可能なモードでの組み合わせで検証を行うことができる。このような組み合わせでの検証によって、システム結合時の問題を早期に発見および解決などが可能となり、制御システムの運用開始までの時間を短縮できる。
　今回開示された実施の形態はすべての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は、上記した説明ではなく、請求の範囲によって示され、請求の範囲と均等の意味および範囲内でのすべての変更が含まれることが意図される。
　１　制御システム、２　ＰＬＣシステム、４　制御系ネットワーク、６　情報系ネットワーク、８　インターネット、１０　フィールドデバイス、１２　リモートＩ／Ｏ、１４　リレー群、１６　サーボドライバ、１８　サーボモータ、２０　ゲートウェイ、５０　ランタイムコンテナ、５１　ＰＬＣランタイムイメージ、５２　仮想Ｉ／Ｏドライバイメージ、５３　仮想Ｉ／Ｏネットワーククライアントイメージ、５４　仮想Ｉ／Ｏネットワークサーバイメージ、５５　仮想Ｉ／Ｏエミュレータイメージ、５６　マニフェスト、６０　システム構成プロファイル、１００　ＰＬＣ、１０２，２０２，３０２　プロセッサ、１０４　チップセット、１０６，２０６，３０６　主メモリ、１１０，２１０，３１０　ストレージ、１１２，２１２，３１２　ＯＳ、１１４　システムプログラム、１２０　情報系ネットワークコントローラ、１２２　制御系ネットワークコントローラ、１２４，３２４　ＵＳＢコントローラ、１２６　メモリカードインターフェイス、１２８　メモリカード、１４０　ローカルＯＳ、１４２　物理Ｉ／Ｏドライバ、１５０，２５０　コンテナエンジン、１６０　物理Ｉ／Ｏ、２００　サーバ、２０８，３０８　バス、２２０，３２０　ネットワークコントローラ、２２６，３２６　入力部、２２８，３２８　表示部、２４０　サーバＯＳ、２６０　コンテナ生成モジュール、２６２　開発環境、２６４　システム構成マネージャ、２６６　ユーザプログラム、２６８　システム構成情報、２７０　オーケストレータ、２７２　コンテナマネージャ、２７４　ノードマネージャ、２７６　コンテナハブ、２７８　リポジトリ、３００　開発保守端末、３０４　光学ドライブ、３０５　記録媒体、３１４　開発プログラム、５１０　ＰＬＣランタイム、５２０　仮想Ｉ／Ｏドライバ、５３０　仮想Ｉ／Ｏネットワーククライアント、５４０　仮想Ｉ／Ｏネットワークサーバ、５５０　仮想Ｉ／Ｏエミュレータ。

Claims (10)

  1. 　１または複数の制御装置と１または複数のサーバとを備える制御システムであって、
    　制御対象に対する制御演算を定義するユーザプログラムと当該ユーザプログラムを実行する実行環境とを内包するランタイムのイメージを含むコンテナを生成する生成モジュールと、
    　前記制御装置および前記サーバの一方または両方に対して前記コンテナをリリースするオーケストレータとを備え、
    　前記制御装置および前記サーバは、前記コンテナをデプロイするコンテナエンジンを有しており、前記オーケストレータによりリリースされたコンテナをデプロイすることで、前記ランタイムのインスタンスを生成して前記制御演算を実行する、制御システム。
  2. 　前記サーバのコンテナエンジンは、前記ランタイムのインスタンスとともに、前記制御対象とやり取りされる入出力データをエミュレートするエミュレータのインスタンスも生成する、請求項１に記載の制御システム。
  3. 　前記サーバのコンテナエンジンが前記ランタイムのインスタンスを生成する場合に、前記制御装置のコンテナエンジンが前記制御装置に接続されたデバイスを介してやり取りされる入出力データを前記サーバに仲介するネットワークサーバのインスタンスを生成する、請求項１に記載の制御システム。
  4. 　前記サーバのコンテナエンジンは、前記ランタイムのインスタンスを生成する場合に、前記制御装置に接続されたデバイスへアクセスする処理を担当するＩ／Ｏドライバをエミュレートする仮想Ｉ／Ｏドライバのインスタンスを生成する、請求項１～３のいずれか１項に記載の制御システム。
  5. 　前記コンテナは、前記制御装置のコンテナエンジンのみがデプロイするイメージと、前記サーバのコンテナエンジンのみがデプロイするイメージとのうち、少なくとも一方を含む、請求項１～４のいずれか１項に記載の制御システム。
  6. 　前記サーバのコンテナエンジンが前記ランタイムのインスタンスを生成する場合に、当該コンテナエンジンにアクセスするためのアドレスを管理するリポジトリをさらに備える、請求項１～５のいずれか１項に記載の制御システム。
  7. 　前記サーバに対して前記コンテナをリリースする場合に、当該コンテナをデプロイするコンテナエンジンが存在しなければ、コンテナエンジンを含むノードを仮想的に生成するノードマネージャをさらに備える、請求項１～６のいずれか１項に記載の制御システム。
  8. 　前記生成モジュールにより生成されるコンテナをリリース可能な制御装置の識別情報と関連付けて登録するコンテナハブをさらに備える、請求項１～７のいずれか１項に記載の制御システム。
  9. 　前記オーケストレータは、ユーザ操作に従って、リリースするコンテナを選択するとともに、リリース先を決定する、請求項１～８のいずれか１項に記載の制御システム。
  10. 　１または複数の制御装置と１または複数のサーバとを備える制御システムにおいて実行される制御方法であって、
    　制御対象に対する制御演算を定義するユーザプログラムと当該ユーザプログラムを実行する実行環境とを内包するランタイムのイメージを含むコンテナを生成するステップと、
    　前記制御装置および前記サーバの一方または両方に対して前記コンテナをリリースするステップとを備え、
    　前記制御装置および前記サーバは、前記コンテナをデプロイするコンテナエンジンを有しており、前記リリースされたコンテナをデプロイすることで、前記ランタイムのインスタンスを生成して前記制御演算を実行する、制御方法。
PCT/JP2021/008916 2020-12-09 2021-03-08 制御システムおよび制御方法 WO2022123803A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
US18/039,653 US20240004688A1 (en) 2020-12-09 2021-03-08 Control system and control method
EP21902910.5A EP4261631A1 (en) 2020-12-09 2021-03-08 Control system and control method
CN202180078958.0A CN116490830A (zh) 2020-12-09 2021-03-08 控制系统以及控制方法

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
JP2020-204061 2020-12-09
JP2020204061A JP2022091301A (ja) 2020-12-09 2020-12-09 制御システムおよび制御方法

Publications (1)

Publication Number Publication Date
WO2022123803A1 true WO2022123803A1 (ja) 2022-06-16

Family

ID=81974338

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2021/008916 WO2022123803A1 (ja) 2020-12-09 2021-03-08 制御システムおよび制御方法

Country Status (5)

Country Link
US (1) US20240004688A1 (ja)
EP (1) EP4261631A1 (ja)
JP (1) JP2022091301A (ja)
CN (1) CN116490830A (ja)
WO (1) WO2022123803A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240103455A1 (en) * 2022-09-22 2024-03-28 Rockwell Automation Technologies, Inc. Application driven enhancement to industrial automation device via container implementation

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140222408A1 (en) * 2011-06-09 2014-08-07 Siemens Aktiengesellschaft Simulation system, method of carrying out a simulation, guidance system and computer program product
JP2015512091A (ja) 2012-02-13 2015-04-23 オラクル・インターナショナル・コーポレイション クラウドコンピューティング環境におけるプロセスの調整
WO2019099111A1 (en) * 2017-11-16 2019-05-23 Intel Corporation Distributed software-defined industrial systems
JP2019128863A (ja) * 2018-01-26 2019-08-01 株式会社インテック ロボットアプリケーション管理装置、システム、方法及びプログラム
EP3722951A1 (en) * 2019-04-08 2020-10-14 Schneider Electric Industries SAS Service deployment in a cluster of i/o devices

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20140222408A1 (en) * 2011-06-09 2014-08-07 Siemens Aktiengesellschaft Simulation system, method of carrying out a simulation, guidance system and computer program product
JP2015512091A (ja) 2012-02-13 2015-04-23 オラクル・インターナショナル・コーポレイション クラウドコンピューティング環境におけるプロセスの調整
WO2019099111A1 (en) * 2017-11-16 2019-05-23 Intel Corporation Distributed software-defined industrial systems
JP2019128863A (ja) * 2018-01-26 2019-08-01 株式会社インテック ロボットアプリケーション管理装置、システム、方法及びプログラム
EP3722951A1 (en) * 2019-04-08 2020-10-14 Schneider Electric Industries SAS Service deployment in a cluster of i/o devices

Also Published As

Publication number Publication date
JP2022091301A (ja) 2022-06-21
CN116490830A (zh) 2023-07-25
EP4261631A1 (en) 2023-10-18
US20240004688A1 (en) 2024-01-04

Similar Documents

Publication Publication Date Title
CN107784152B (zh) 包括多个模拟器的模拟
US7823023B2 (en) Test framework for testing an application
US9298482B2 (en) Plug-in based templatization framework for automating the creation of open virtualization format virtual appliances
Lin et al. ABS-YARN: A formal framework for modeling Hadoop YARN clusters
JP2012256148A (ja) 運用管理装置、及び方法
CN111679889B (zh) 一种虚拟机的转换迁移方法和系统
Marshall Mastering VMware VSphere 6
WO2022123803A1 (ja) 制御システムおよび制御方法
JP2012093899A (ja) 計算機システム、シミュレーション方法、及びプログラム
CN112764981B (zh) 一种协同测试系统及方法
Junghanns et al. Building virtual ECUs quickly and economically
KR102054980B1 (ko) 가상화된 시스템 상에서 임베디드 소프트웨어를 자동으로 생성하는 방법 및 컴퓨팅 시스템
US7447618B2 (en) Method and system for ASIC simulation
WO2020179581A1 (ja) 制御装置およびソフトウェアのデプロイ方法
CN116157774A (zh) 用于在云计算环境中提供工业设备的工程的方法和系统
US20210141710A1 (en) Development support device
JPH09330243A (ja) 計算機システム
US9424016B2 (en) Methods, apparatuses, and systems relating to automation in distributed systems
Priller et al. Towards perfectly scalable real-time systems
JP7441981B2 (ja) 切り替え可能モデルを有する自律運転シミュレーションアーキテクチャを提供するためのシステムと方法
JP6985685B2 (ja) 情報環境の管理システム及びその作動方法
KR20240009766A (ko) 차량용 소프트웨어 플랫폼의 시뮬레이션을 위한 네트워크 가상화 장치 및 방법
WO2020246096A1 (ja) サポート装置およびサポートプログラム
KR20230101667A (ko) 소프트웨어 기반의 개별분리 아키텍처 시스템 시뮬레이터 및 그의 방법
JP2000295242A (ja) 汎用品を用いた監視制御システム及びその評価装置

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 21902910

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 202180078958.0

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 18039653

Country of ref document: US

NENP Non-entry into the national phase

Ref country code: DE

ENP Entry into the national phase

Ref document number: 2021902910

Country of ref document: EP

Effective date: 20230710