JP2022091301A

JP2022091301A - 制御システムおよび制御方法

Info

Publication number: JP2022091301A
Application number: JP2020204061A
Authority: JP
Inventors: 弓束重森; Yumitsuka Shigemori
Original assignee: Omron Corp; Omron Tateisi Electronics Co
Current assignee: Omron Corp
Priority date: 2020-12-09
Filing date: 2020-12-09
Publication date: 2022-06-21
Also published as: CN116490830A; EP4261631A1; US20240004688A1; WO2022123803A1

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

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