JP7467660B2 - 産業用オートメーションプラットフォームのオートメーションプログラムを管理する方法および装置 - Google Patents

Description

本発明は、請求項１の前提部分に係る産業用オートメーションプラットフォームのオートメーションアプリケーションを管理する方法、および、請求項１０の前提部分に係る産業用オートメーションプラットフォームのオートメーションアプリケーションを管理する装置、に関する。

オートメーションシステムのオートメーションアプリケーションは、１つまたは複数の、例えばＩＥＣ ６１１３１規格に準拠しているオートメーションプログラムであって、産業用オートメーションプラットフォームで実行されるオートメーションプログラム、からなる。そのような産業用オートメーションプラットフォームは、例えば、プログラマブルロジックコントローラ（英：Programmable Logic Controller（略してＰＬＣ）、独：Speicherprogrammierbare Steuerungen）であってよい。このオートメーションプログラムの作成および管理、例えば、個別のコントローラへのプログラムの割り当て、プログラムのロード／起動／停止、プログラムのアップデート等は、一般に、いわゆるエンジニアリングシステムにおいて、例えばシーメンス株式会社（Ｓｉｅｍｅｎｓ ＡＧ）のＴＩＡポータルにおいて、行われる。これらアクティビティは、一般的にエンジニアリングと称され、通常、手動制御で行われる、すなわち、低い自動化レベルで、そして対応的に長い変更時間と高い変更コストで行われる。また、エンジニアリングシステムは、通常、産業用オートメーションプラットフォームにローカル接続する必要もあり、エンジニアリングシステムのバージョンは、使用されるオートメーションプラットフォーム（コントローラ）のそれぞれのバージョンおよびタイプと一致すること等、が必要とされる。

以下、少なくとも、既に作成されたオートメーションプログラムを目的地又は「ターゲット」へ、つまり産業用オートメーションプラットフォーム（ＳＰＳ、ＰＬＣ等）へ、送信するプロセス、オートメーションプログラムのプロセスを開始および終了（スタート／ストップ）するステップ、制御エンティティ（英：control entity、独：Kontrollinstanz）（例えば、ＨＭＩデバイス（ＨＭＩ：Human Machine Interface））に対するオートメーションプログラムを処理するプロセスの間の産業用オートメーションプラットフォームの肯定応答メッセージ（独：Quittierungsmeldungen、英：acknowledgment messages）を受信及び転送するステップを、まとめて、オートメーションプログラムの「管理」および「制御」と称する。

ＩＴベースのモジュラーシステムに対しては、つまり従来のコンピュータ技術によるシステムに対しては、既にしばらく前から、ソフトウェアコンテナ技術が導入されている。特に、複数のコンピューティングノードを備える分散システムにおいては、コンテナベースのプログラムは、いわゆるコンテナオーケストレーション技術（独：Container-Orchestration-Techniken、英：container orchestration technologies）、例えばＫｕｂｅｒｎｅｔｅｓ（登録商標）（https://kubernetes.io/de/）、を用いて、コンピューティングノードに分散され、実行され、監視される。Ｋｕｂｅｒｎｅｔｅｓでは、これらは、中央コンポーネント、いわゆるマスタまたはＫｕｂｅｒｎｅｔｅｓマスタ、を介して行われる。これは、実行されるソフトウェアコンポーネントの説明、いわゆるマニフェスト、を取得する。マスタは、適切なノード（独：Knoten、英：Nodes）を選択し、そこにあるソフトウェアコンポーネントを有するコンテナを実行させるが、これは「デプロイメント」と称される。さらに、Ｋｕｂｅｒｎｅｔｅｓマスタは、コンポーネントを監視し、必要に応じて、リカバリするためのアクションを実行する。さらに、ランタイムに、コンポーネントの変更を行うことができる、例えば、アップデートされたバージョンの起動、スケーリング（スループットを増減させるためのインスタンスのスタート／ストップ）等を、行うことができる。

Ｋｕｂｅｒｎｅｔｅｓを使用するために基本的なことは、完全なソフトウェアが１つまたは複数のソフトウェアコンテナ（例えば、Ｄｏｃｋｅｒコンテナ（https://www.docker.com/resources/what-container））に統合されており、このコンテナが、ランタイム環境、いわゆるコンテナランタイムに、コンピュータハードウェア（通常の場合「ノード」と称される）で送信されることである。ここで、「ノード」の構成要素は、いわゆるｋｕｂｅｌｅｔであり、当該ｋｕｂｅｌｅｔはローカルで実行されるソフトウェアであり、当該ソフトウェアは管理を行うＫｕｂｅｒｎｅｔｅｓマスタおよびローカルコンテナランタイムと協働し、ソフトウェアを含むコンテナをローカルにダウンロードし、実行し、動作を監視する。

上述のように、従来、オートメーションプログラムの管理（作成、ロード、スタート、ストップ）は、産業用オートメーションプラットフォーム（産業用コントローラ、ＳＰＳ、ＰＬＣ等）にローカル接続される特別なエンジニアリングシステムを用いて、通常の場合大部分が手動（マニュアル）で、行われる。通常の場合、個別のオートメーションプラットフォーム（例えば、ＰＬＣ（プログラマブルロジックコントローラ））へのオートメーションプログラムの割り当ては、手動で行われる。

また、従来のエンジニアリングシステムを使用することは、多くの場合、このエンジニアリングシステムのインスタンスが産業用ネットワークにローカルで存在することと関連付けられており、「遠隔制御」は、特にはクラウドベースのアプローチにおいては、遠隔作業場からのローカルエンジニアリングシステムへの専用アクセスを必要とし、これは、システム全体の高コストな構成を必要とする。

非特許文献１は、「オーケストレーション」のための、つまり、リソースが限られているデバイスでのソフトウェアを有するコンテナの展開および稼働のための、仮想ｋｕｂｅｌｅｔの使用、を記載している。

非特許文献２は、プロプライエタリ制御プログラムを実行するためのコンテナでのプロプライエタリＰＬＣハードウェアのエミュレーション、を開示している。

Goethals et al."FLEDGE: Kubernetes Compatible Container Orchestration on Low-Resource Edge Devices"(ISBN:978-3-642-36741-0) Goldschmidt et al. "Container-based architecture for flexible industrial control applications"（Journal of Systems Architecture Bd. 84 (2018),28-36頁）

従って、本発明の課題は、従来のオートメーションプログラムを高い自動化レベルで管理し、制御することであり、その際、可能な限り確立されており、広く普及しており、簡単に学習可能な方法を使用し、管理される産業用オートメーションプラットフォームに対してのエンジニアリングシステムの依存性を低下させ、エンジニアリングシステムへのローカルな依存性を軽減または除去することである。

本発明の課題は、原則的に、Ｋｕｂｅｒｎｅｔｅｓマスタとｋｕｂｅｌｅｔとからなる周知のシステムによって、解決され、そのような周知のシステムは、コンテナベースのプログラムをコンテナランタイム環境において管理および制御するように意図されている。本発明によれば、仮想ｋｕｂｅｌｅｔ（https://github.com/virtual-kubeletを参照）が使用され、当該仮想ｋｕｂｅｌｅｔは、Ｋｕｂｅｒｎｅｔｅｓマスタに対して「本物の」ｋｕｂｅｌｅｔのように振る舞う一方、特別なプロバイダインタフェース（https://virtual-kubelet.io/docs/providers/#provider-interfaceを参照）を備えており、当該プロバイダインタフェースは、本発明においては、産業用オートメーションプラットフォームの、特にはプログラマブルロジックコントローラの、オートメーションプログラムを管理および制御するように調整されている。１つ以上の仮想ｋｕｂｅｌｅｔが、原則的に、周知であり、また、ほぼ任意のプラットフォームにソフトウェアコンテナを導入するために、従来使用されている。当該プラットフォームは、コンテナランタイム環境を、特には、クラウド環境において、すなわちＡＷＳ（登録商標）（Amazon Web Service（登録商標））等のようなクラウドサービスプロバイダにおいて、エミュレートされたコンテナランタイム環境を、提供することができる。

本発明においては、しかしながら、プロバイダインタフェースまたはプロバイダプラグインが仮想ｋｕｂｅｌｅｔのために提供され、当該プロバイダインタフェースまたはプロバイダプラグインは、コンテナではなくオートメーションプログラムを管理し、オートメーションプログラムは、特別な方法によって、管理されて、産業用オートメーションプラットフォームに送信されて、そこで起動（スタート）、停止（ストップ）等される必要がある。これは、本発明によれば、少なくとも、従来の産業用エンジニアリングシステムの以下のような機能性、すなわち、オートメーションプラットフォームで実行するソフトウェアの「デプロイメント」（ソフトウェア展開）および制御を備えて調整されている機能性、が、プロバイダインタフェースを用いて提供される必要があること、を意味する。この場合、そのように設計された仮想ｋｕｂｅｌｅｔは、産業用オートメーション装置の領域で実行可能である、つまり、例えば、対応して設けられたプログラマブルロジックコントローラまたは一般にオートメーションプラットフォームそれ自体において実行可能である一方、実用的には、別個のサーバでも、特には産業用エッジデバイスでも、実行可能である。代替的に、産業領域外での実行が可能であり、その場合、プロバイダインタフェースは、例えばＶＰＮアクセスを用いての、オートメーションプラットフォームへのデータアクセスを必要とする。

本課題は、特には、請求項１に記載の方法および請求項１０に記載の装置によって、解決される。

これによると、産業用オートメーションプラットフォーム用のオートメーションプログラムを管理する方法が提供され、オートメーションプログラムは、オートメーションプラットフォームへ送信され、オートメーションプログラムの実行は、オートメーションプラットフォーム上で制御される。その際、第１ステップでは、オートメーションプログラムまたはこのオートメーションプログラムへのリファレンスが、Ｋｕｂｅｒｎｅｔｅｓマスタから仮想ｋｕｂｅｌｅｔへ送信され、第２ステップでは、仮想ｋｕｂｅｌｅｔのプロバイダインタフェースによって、送信されたまたは参照されたオートメーションプログラムが、産業用オートメーションプラットフォームへ送信され、第３ステップでは、送信されたオートメーションプログラムの実行は、産業用オートメーションプラットフォーム上で制御され、プロバイダインタフェースによって、制御命令が産業用オートメーションプラットフォームへ送信され、産業用オートメーションプラットフォームの肯定応答メッセージが受信され、そして処理されるかまたは制御インスタンスへ、特にはＫｕｂｅｒｎｅｔｅｓマスタまたは制御監視装置（ＨＭＩ装置）へ、転送される。本方法により、オートメーションプログラムを、コンテナオーケストレーションシステムの手段を用いて管理し、展開し、実行させることができる。

また、本課題は、更に、以下のような産業用オートメーションプラットフォームのオートメーションプログラムを管理する装置によって、解決される、すなわち、オートメーションプログラムまたはオートメーションプログラムへのリファレンスを仮想ｋｕｂｅｌｅｔへ送信するＫｕｂｅｒｎｅｔｅｓマスタを備え、オートメーションプログラムまたはオートメーションプログラムへのリファレンスを受信するための、そして、オートメーションプラットフォームでのオートメーションプログラムのインストールのための命令を受信するための、オートメーションプログラムのプロセスをオートメーションプラットフォーム上での制御のための、仮想Ｋｕｂｅｌｅｔを備え、オートメーションプログラムのオートメーションプラットフォームへの送信のための、オートメーションプログラムのプログラムプロセスの制御のための、そして、オートメーションプログラムのプロセスの実行中にオートメーションプラットフォームの肯定応答メッセージを受信及び転送するための、仮想Ｋｕｂｅｌｅｔのプロバイダインタフェースを備える、装置によって、解決される。

本発明に係る方法の有利な構成は、従属請求項に記載されている。そこに記載されている特徴およびそれらの有利な点は、本発明に係る装置にも、同様に適用される。有利な構成は、個別にも、そしてまた明白な組み合わせにおいても、実現することができる。

適切に設計されたＫｕｂｅｒｎｅｔｅｓマスタ、及びそれに対応して設計されたカウンターパート、つまり仮想ｋｕｂｅｌｅｔ、を用いて、原理的には、オートメーションプログラムまたはそのソースコードを直接的に供給することができるが、実用的には、Ｋｕｂｅｒｎｅｔｅｓマスタによって、参照はオートメーションプログラムへ送信される。リファレンスは、記憶場所への任意の適切な参照または「リンク」にして、そこから仮想ｋｕｂｅｌｅｔまたはそのプロバイダインタフェースがオートメーションプログラムまたはそのソースコードをロードすることができる参照または「リンク」であってよい、特に、ＵＲＬ、メモリパス情報、インターネットアドレス、ＦＴＰアドレス等であってよい。

有利な構成においては、送信されるまたは参照されるオートメーションプログラムは、オートメーションプラットフォームへの送信前に、前処理される。これは、特には、異なるプロパティを有する異なるオートメーションプラットフォームをアドレス指定することを可能とする。このようにして、例えば、オートメーションプログラムをそれぞれのターゲットハードウェアに関して適切にコンパイルすることができ、また、異なるオートメーションプラットフォームが、異なる方法でアドレス指定されそしてプログラムされることも、考慮に入れることができる。特に、有利な構成においては、プロバイダインタフェースは、最終的なオートメーションプログラムを複数のソースから「アセンブル」すること、つまり、例えば参照されるオブジェクトまたはライブラリを統合すること、プログラムをまとめてコンパイルすること、個別の要素のアップデートをリロードすること等を行うことができる。

有利な変形例においては、プロバイダインタフェース、または、統合されたプロバイダインタフェース（プロバイダインタフェースプラグイン）を有する対応して拡張された仮想ｋｕｂｅｌｅｔ、は、異なるタイプの複数のオートメーションプラットフォームに、オートメーションプログラムを供給し、そのプロセスを制御することができる。その一方、他の有利な変形例においては、異なるタイプまたはタイプシリーズのオートメーションプラットフォームに対して、異なる特化したプロバイダインタフェースを提供するとともに、その際、異なる仮想ｋｕｂｅｌｅｔも設けるか、または代替的に複数の異なる特化したプロバイダインタフェースプラグインを共通の仮想ｋｕｂｅｌｅｔに統合すること、も可能である。この柔軟性により、対応するシステムは、広範に適用可能であるだけでなく、ほぼ任意にスケーラブルでもある。

特化したプロバイダインタフェースは、つまり、仮想ｋｕｂｅｌｅｔ拡張用プラグインは、有利には複数の機能を含んでおり、当該機能は、産業用オートメーションプラットフォーム用の従来のエンジニアリングシステムの機能に対応するか、又は、それどころかそれらから取り出されている。特に有利な変形例においては、プロバイダインタフェースは、実際に利用可能なエンジニアリングシステムの、プログラミングインターフェース、いわゆるＡＰＩ（Application Programming Interface）、をアドレス指定して、これにより、その機能性を使用（例えば、ソフトウェアのコンパイル）する、または、オートメーションプログラムをオートメーションネットワークにおいてローカルに展開させそして制御しさえする。

有利な変形例においては、プログラマブルロジックコントローラのリソースを管理するためにおよび／またはオートメーションプログラムを複数のオートメーションプラットフォームに割り当てるために、Ｋｕｂｅｒｎｅｔｅｓのカスタムリソース定義（ＣＲＤ：Custom Resource Definitions）（https://kubernetes.io/docs/concepts/extend-kubernetes/api-extension/custom-resources/を参照）が使用される。これにより、コンテナベースのプラットフォームの使用との比較において考慮する必要があるオートメーションプラットフォームの特徴を、データ技術的に定義し自動的に考慮に入れることができる。

有利には、いわゆるＣｕｓｔｏｍ Ｓｃｈｅｄｕｌｅｒ（https://kubernetes.io/docs/concepts/scheduling/kube-scheduler/を参照）を、つまり、オートメーションプラットフォームの使用に適合されたスケジューラを、そのターゲットでのオートメーションプログラムのデプロイメント（展開）に使用することも可能である。Ｋｕｂｅｒｎｅｔｅｓを用いて「ポッド」ごとにスケジューラを指定することが可能であり、当該スケジューラを用いてこのポッドは処理される。ＰＬＣプログラムに対して、固有の、つまりオートメーションプラットフォームの要件に特有の、適合されたスケジューラを使用する場合、次のことを達成できる。一方では、ＰＬＣプログラムを他のポッドから容易に区別できる。これにより、ＰＬＣプログラムの適切なＰＬＣノードへの割り当てを実行することができる。他方では、カスタムスケジューラでＰＬＣプログラムをスケジューリングする際、特徴を考慮に入れることができ、特に、オートメーションプラットフォームは、コンテナの意味において、多くの場合、パケットの「ダウンロード」によってではなく、複数の段階からなるシーケンスで充填されること、を考慮に入れることができる。

実施バリエーションにおいては、サービス品質パラメータ（ＱｏＳパラメータ）が、ＰＬＣプログラムを適切なＰＬＣノードまたは適したオートメーションプラットフォームに割り当てるために、使用される。ＱｏＳパラメータの一例は、コンピューティング容量、遅延時間（英：latency times、独：Latenzzeiten）、サイクル時間、可用性、プライバシー／セキュリティ等である。これにより、独立した、つまり自動的な、とりわけ機能的に信頼性高い、負荷分散が可能である。

本発明に係る方法の実施形態例を、以下において図面を用いて説明する。実施例は、同時に、本発明に係る装置の説明にも、適用される。

図１は、異なるタイプのプログラムを有する３つの異なるノードを備えかつ制御するＫｕｂｅｒｎｅｔｅｓマスタを概略図で示す。

図には、３つの異なるコンピューティングノードであるノード１、ノード２、ノード３(ノード（英：Node、独：Knoten）；ターゲットハードウェア、「ターゲット」）でのソフトウェアの展開が示されている。このプロセスは、中央管理デバイスであるＫｕｂｅｒｎｅｔｅｓマスタによって、制御される。このアプリケーション（図中「Ｋｕｂｅｒｎｅｔｅｓ」と記載されている）では、このプロセスのローカル制御は、コンピューティングノードであるノード１、ノード２、ノード３（英：Node、独：Knoten）で、つまり、実行されるプログラムのターゲットハードウェアで、各ノードに存在するエージェント（いわゆるｋｕｂｅｌｅｔ）によって、行われる。

図では、ノード２のローカルで、ソフトウェアコンテナを管理するように設定されている従来のｋｕｂｅｌｅｔが実行される。ｋｕｂｅｌｅｔは、その際、Ｋｕｂｅｒｎｅｔｅｓマスタの命令（「マニフェスト」）によって指定されたソフトウェアコンテナを、ローカル実行環境「コンテナランタイム」で実行できる。ソフトウェアコンテナは、ｋｕｂｅｌｅｔの命令に従って、指定されたソースからロードされる。

また、ノードのｋｕｂｅｌｅｔは、そのために、マスタから、例えばマニフェストとともにまたは後ほど、ノードで実行中のソフトウェアコンポーネントを起動、停止、変更するための対応する命令を、取得する。これらは、通常の場合、Ｋｕｂｅｒｎｅｔｅｓにおいては、ソフトウェアコンテナまたはソフトウェアコンテナのグルーピング（いわゆるポッド）である。Ｋｕｂｅｒｎｅｔｅｓマスタとｋｕｂｅｌｅｔ間のインタフェースは定義されている。ｋｕｂｅｌｅｔは、ソフトウェアコンテナを起動および操作できるように、ノード（「Node」）での実行環境(「コンテナランタイム」)に対して定義されたインタフェースを備える。

Ｋｕｂｅｒｎｅｔｅｓを拡張する場合、いわゆる仮想ｋｕｂｅｌｅｔが導入され、これらは、図中、ノード１、ノード３により示されている。仮想ｋｕｂｅｌｅｔは、従来、互換性のないコンテナ環境のソフトウェアコンテナ(例えば、オペレーティングシステムMicrosoft Windows（登録商標）を搭載したコンピュータのWindows（登録商標）コンテナ、を管理するために使用される。仮想ｋｕｂｅｌｅｔの原則は、Ｋｕｂｅｒｎｅｔｅｓマスタに対するそのインタフェースが、従来のｋｕｂｅｌｅｔのインタフェースのように、設計されていることである。それは、従って、「上位へは」、従来のｋｕｂｅｌｅｔと同じインタフェースを有し、そして、マスタは、逆方向に、また従来のＫｕｂｅｒｎｅｔｅｓノードと、つまり、コンテナ（またはポッド）を管理可能なノードと、通信する、ノード２の例を参照。「下位」へは、つまり、「ターゲット」との通信においては、仮想ｋｕｂｅｌｅｔは、原則的に、任意のインタフェースを有することができる。現行の実装（https://github.com/virtual-kubelet/virtual-kubelet）では、これは、いわゆるプロバイダにより、解決される。従来の方法では、このプロバイダは、より大きなユニット（クラスタまたはＦａｒｇａｔｅのようなサーバレスコンテナ環境）を、単一のノードのように表示させるか、または、(例えば、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅコンテナのために）非互換性を解決するかの、何れかの役割を果たす。

ノード１、ノード３の図示された本発明による解決手段では、仮想ｋｕｂｅｌｅｔは、オートメーションプログラムのまたはオートメーションプログラムの一部の管理のために、使用される。この目的のために、特別なＰＬＣプロバイダが実装されており、当該ＰＬＣプロバイダは、オートメーションプログラムを、対応するオートメーションプラットフォーム（以下および図中において「ＰＬＣランタイム」と称する）において、起動、停止、監視等をすることができる。プロバイダが満たす必要がある基本機能は、https://github.com/virtual-kubelet/virtual-kubelet、に説明されている。

本実施例では、この特別なプロバイダは、それぞれ仮想ｋｕｂｅｌｅｔ用のプラグインとして実装されているが、他の実装においては、このための別個のコンポーネントを設けてもよい。プラグイン、つまりここでは「ＰＬＣプロバイダ」、は、それ自体、モジュラで構成されていてもよく、特には、ホストである仮想Ｋｕｂｅｌｅｔに接続するための汎用コンポーネントを有していてもよく、他方では、それぞれ特別なタイプのオートメーションプラットフォームを管理するための特定のモジュールを有していてもよい。

具体的には、プロバイダプラグインであるＰＬＣプロバイダは、ここで、アドレス指定されたオートメーションプラットフォーム、いわゆるＰＬＣランタイム、の、オートメーションプログラムの実行環境と、通信する。ここでノード１を用いて、以下の場合について説明する、すなわち、仮想ｋｕｂｅｌｅｔがＰＬＣプロバイダと共に、管理されるオートメーションプラットフォーム（ノード１）それ自体にインストールされている場合について、説明する。仮想ＫｕｂｅｌｅｔとＰＬＣプロバイダは、この場合、ファームウェアの構成部であってよいし、または、別個のプログラムとしてインストールされていてもよい。反対に、ノード３を用いて、以下の場合が与えられている、すなわち、仮想ｋｕｂｅｌｅｔとＰＬＣプロバイダが、別個のマシン、例えば、産業用エッジデバイス、で実行される場合が与えられており、当該エッジデバイスは、オートメーションプラットフォームであるノード３を含む産業レベルに対するインタフェースと、Ｋｕｂｅｒｎｅｔｅｓマスタに対するさらなるインタフェースと、を有し、後者はクラウドプロバイダのサーバ上でも実行可能である。

プログラミング準備のため、オートメーションプラットフォーム（ＰＬＣ）のオートメーションプログラムが、例えば、産業用エンジニアリングシステムのプロジェクト（例えばＴＩＡポータルプロジェクト）内で、生成され、「ポッド」にマッピングされ、参照可能なソースに格納される。オートメーションプラットフォーム（ＰＬＣまたは仮想ＰＬＣ）それ自体は、構成済みであり、使用可能であるようにネットワーク技術的に設定済みである。仮想ＰＬＣは、この場合、仮想マシンで実行される純粋にソフトウェアベースのＰＬＣインスタンスである。仮想ＰＬＣの機能と論理インタフェースは、実ＰＬＣに対応する。オートメーションプラットフォームであるノード１、ノード３を管理するためのＰＬＣプロバイダのいくつかの基本機能のマッピングは、以下のようにして、可能である。
・ ＣｒｅａｔｅＰｏｄ －＞ 存在するＰＬＣまたは仮想ＰＬＣインスタンスにオートメーションプログラムをロードし、それを起動させる。その際、ＰＬＣ／ＰＬＣインスタンスの対応するリソースが確保され、確保済みとしてマークされる。
・ ＵｐｄａｔｅＰｏｄ －＞ ＰＬＣ／仮想ＰＬＣインスタンスで実行中のオートメーションプログラムを変更する。変更は、ソフトウェアの状態、および／または、オートメーションプログラムの構成または実行パラメータ、に関連し得る。
・ ＤｅｌｅｔｅＰｏｄ －＞ 実行中のオートメーションプログラムを停止し、ＰＬＣ／仮想ＰＬＣインスタンスにおいて確保されたリソースを解放する。
・ ＧｅｔＣｏｎｔａｉｎｅｒＬｏｇｓ －＞ ＰＬＣの診断バッファを転送する、または、それに対応するオートメーションプログラムに関連するＰＬＣの診断バッファの一部分を転送する。
・ ＧｅｔＰｏｄＳｔａｔｕｓ －＞ 関連するオートメーションプログラムの現在の実行詳細、例えば、サイクルタイム、メモリ要件、診断ステータス、表示コンテンツ、を表示する。
・ ＮｏｄｅＣｏｎｄｉｔｉｏｎｓ －＞ ＰＬＣ／仮想ＰＬＣインスタンスの抽象化状態（実行可能、停止済み、起動中、メモリ不足）を表示する。
・ ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ －＞ ＰＬＣのバージョンを表示する。

このマッピングでは、存在するエンジニアリングツール（例えばＴＩＡポータル、ＳＴＥＰ７）を完全にＰＬＣプロバイダにおいて使用できる。その一方で、モジュールコンポーネントは、ＰＬＣプロバイダをスリムに保ち、またコンピューティング容量が小さいノード上で実行可能とするために、有利である。従って、例えば、上記の基本機能は、モジュールまたはプラグインとして、ＰＬＣプロバイダに、設けられてよい。また、これらの基本機能を少なくとも部分的に、それに対応するサービスをクラウドまたはその他の稼働中のエンジニアリングシステムで呼び出すことによって、実装することもできる。

ＰＬＣプロバイダは、従って、ポッドの起動時に、そのために設けられているか参照されるＰＬＣプログラムをロードし、ＰＬＣランタイムに転送することができるようにするため、動作プロセスを実装している。これは、参照されるソース（リポジトリ）によって、または、他のソースやディレクトリを介して、行われ得る、代替的に、少なくとも部分的にＰＬＣプログラムそれ自体が動作されるようにＫｕｂｅｒｎｅｔｅｓコンポーネント（Ｋｕｂｅｒｎｅｔｅｓマスタ、仮想Ｋｕｂｅｌｅｔ）を変更することもできる。追加的に、ＰＬＣプロバイダによって、または、ＰＬＣプロバイダによってアドレス指定されたサービスによって、オートメーションプログラムを変更することもでき、特には、ＰＬＣランタイムのタイプや現在の状態（ステータス、例えば、空きメモリ容量、ファームウェアのバージョン等）に応じて、つまり実行環境またはオートメーションプラットフォーム自体に応じて、プログラムコードをプラットフォーム固有に適合すること又はコンパイルすることができる。

特には、混在システム（異なるＰＬＣタイプ、ソフトウェアコンテナシステムと混在するＰＬＣ、標準ＰＣ、クラウドでのコンテナランタイム）では、ランタイムの特定のタイプの区別／識別が、可能となる必要がある。これは、例えばＫｕｂｅｒｎｅｔｅｓにおけるラベルを介して、行うことができる。また、ＰＬＣプロバイダは、実行環境のタイプと他のパラメータをそれ自体で決定し、オートメーションプログラムおよびアドレス指定または、一般に、実行環境とのデータ交換、を対応的に適合することもできる。

ＰＬＣプロバイダは、オートメーションプラットフォーム（ＰＬＣ）に統合可能であり、このことは、特には新しいタイプのオートメーションプラットフォームにおいて、ファームウェアと共にプリインストールすることによって、または、ファームウェアの一部としてプリインストールするによって、納品時に既に容易に実行できる。上述したように、このことは、ノード１の例に見ることができる。既存のシステムの場合、ＰＬＣプロバイダは、ネットワークを介してオートメーションプラットフォーム／ＰＬＣおよびそこでの実行環境と接続するために、既存のコンピューティングノードで、又は、代替的に追加のノードで、起動され得る。この場合、例えば、エッジデバイス（産業用エッジデバイス）またはクラウドノードを、ＰＬＣプロバイダのプラットフォームとして、または、対応して設計された仮想ｋｕｂｅｌｅｔのプラットフォームとして、使用することができる、これについては図のノード３を参照されたい。

ソフトウェア展開のルート、すなわち少なくとも１つのオートメーションプログラムを有するポッドの「デプロイメント」のルートについて上述したが、それとは逆方向のルートで、制御情報、ステータスメッセージ、デバッグ値等を、「ターゲット」から関係する仮想ｋｕｂｅｌｅｔのＰＬＣプロバイダへと、そしてそこから必要に応じて処理された形でさらにＫｕｂｅｒｎｅｔｅｓマスタまたは代替ターゲットへと、送信することができる。そのような代替ターゲットは、特に、オートメーションネットワークの内部または外部の駆動装置及び監視装置（ＨＭＩ；ＳＣＡＤＡ；ＭＥＳ）であってよい。クラウドベースのアプリケーションにも到達され得る。ターゲットは、Ｋｕｂｅｒｎｅｔｅｓマスタを用いて、設定可能であり、代替的に、Ｋｕｂｅｒｎｅｔｅｓマスタは、このデータを、必要に応じて変更した形で、転送することもできる。

本発明によれば、このようにして、ＰＬＣプログラムは、コンテナオーケストレーションシステムの手段を用いて、管理されそして動作され得る。その際、ＰＬＣプログラムをソフトウェアコンテナと共に混在操作することも可能である。

これにより、ノード容量（英：node capacity、独：Knotenkapazitaet）、システムの負荷、可用性等に応じて（つまり、一般に、サービスパラメータの品質に応じて）、ノードへのＰＬＣプログラムの（部分的）自動化割り当てが、可能である。これは、ＰＬＣプログラムまたはＰＬＣプログラムの一部の自動化された「デプロイメント」（初期インストール、アップデート、トラブルシューティング、テスト等）により、より迅速なコミッショニング時間とアップデート時間を、を可能とする。さらなる有利な点は、現在可能な代替切り換え手法による、すなわち、ＰＬＣプログラムの監視、同じまたは他のノードでの再起動による、可用性の向上である。今や、ＣＩ／ＣＤシステムまたはＤｅｖＯｐｓへの簡潔な統合、つまり、ソースコード変更、変換、テスト、コミッショニングの自動化チェーンへの簡潔な統合、も可能である。

産業用オートメーションプラットフォーム用に設定されたプロバイダプラグインを備える仮想ｋｕｂｅｌｅｔの使用は、例えば、モニタリング、トレース、ロールアウト戦略、バージョニング、ロールバックのための既に存在するツールを用いた、ＰＬＣプログラムの管理のためのＫｕｂｅｒｎｅｔｅｓ「エコシステム」を開発するＰＬＣプログラムの管理は、従って、オープンソース環境から、確立された標準ツールを用いて、実行可能であり、当該オープンソース環境では広範な能力基盤（英：competence base、独：Kompetenzbasis）が与えられており、使用されるソフトウェアツールが絶えず開発されている。（コンテナと従来のＰＬＣを備えるＩＴベースの）混在システムでの一元的なソフトウェア管理は、一元的なインフラストラクチャによる、そして、ＩＴシステム専門家の追加的な教育訓練の必要性が低いことによる、利点をもたらす。さらに、現場の既存ＰＬＣシステムは、ＩＴメカニズムを用いて、ＰＬＣシステムを変更することなく、開発され得る。

Claims (10)

1. プログラマブルロジックコントローラのオートメーションプログラムを管理する方法であって、
   前記オートメーションプログラムは、前記プログラマブルロジックコントローラに送信され、前記オートメーションプログラムの実行は、前記プログラマブルロジックコントローラ上で制御される方法において、
   第１ステップにて、前記オートメーションプログラムまたは前記オートメーションプログラムへのリファレンスが、Ｋｕｂｅｒｎｅｔｅｓ（登録商標）マスタから仮想ｋｕｂｅｌｅｔへ、送信され、
   第２ステップにて、リファレンスを送信する場合、前記仮想ｋｕｂｅｌｅｔのプロバイダインタフェースによって、参照される前記オートメーションプログラムは、前記プログラマブルロジックコントローラに送信され、
   第３ステップにて、送信された前記オートメーションプログラムの実行は、前記プログラマブルロジックコントローラで制御され、前記プロバイダインタフェースによって、制御命令が前記プログラマブルロジックコントローラに送信され、前記プログラマブルロジックコントローラの肯定応答メッセージが受信され、そして処理されるか、または、制御インスタンスへ、転送される、
   ことを特徴とする方法。
2. 請求項１に記載の方法において、
   前記第１ステップにて、前記オートメーションプログラムへの前記リファレンスとして、メモリアドレス、メモリパス情報、アプリストアのコンテンツに関する仕様、インターネットアドレス、またはＦＴＰアドレス、が使用されること、
   を特徴とする方法。
3. 請求項１または２に記載の方法において、
   前記第２ステップにて、前記仮想ｋｕｂｅｌｅｔへ送信されるかまたはそれに前記リファレンスとして指定される前記オートメーションプログラムは、前記プログラマブルロジックコントローラへの送信前に、前処理されること、
   を特徴とする方法。
4. 請求項３に記載の方法において、
   前記第２ステップにて、前記オートメーションプログラムは、前記送信前に、コンパイルされること、を特徴とする方法。
5. 請求項３または４に記載の方法において、
   前記第２ステップにて、送信される前記オートメーションプログラムは、参照される複数のソースから、および／または、前記Ｋｕｂｅｒｎｅｔｅｓマスタによって送信されるプログラムの一部から、作成されること、
   を特徴とする方法。
6. 請求項１～５の何れか１項に記載の方法において、
   複数の前記プログラマブルロジックコントローラを備える装置で、個別の前記プログラマブルロジックコントローラの各々に対して、または、同じタイプまたは同様の前記プログラマブルロジックコントローラのグループに対して、それぞれ固有の前記プロバイダインタフェースが使用され、使用される前記プロバイダインタフェースの各々は、それぞれの前記プログラマブルロジックコントローラへ送信される前記オートメーションプログラムを、それぞれのターゲットプログラマブルロジックコントローラのタイプおよび特別なプロパティへの適合のために、実行すること、
   を特徴とする方法。
7. 請求項１～６の何れか１項に記載の方法において、
   前記仮想ｋｕｂｅｌｅｔによって、産業用のエンジニアリングシステムまたはその一部が、前記プロバイダインタフェースとして使用され、前記エンジニアリングシステムまたは前記その一部は、前記Ｋｕｂｅｒｎｅｔｅｓマスタから前記仮想ｋｕｂｅｌｅｔへ送信される命令を用いて、制御されること、
   を特徴とする方法。
8. 請求項１～７の何れか１項に記載の方法において、
   前記プログラマブルロジックコントローラのリソースを管理するために、および／または、前記オートメーションプログラムを複数の前記プログラマブルロジックコントローラのうちの１つに割り当てるために、Ｋｕｂｅｒｎｅｔｅｓのカスタムリソース定義（ＣＲＤ）が使用されること、
   を特徴とする方法。
9. 請求項１～８の何れか１項に記載の方法において、
   前記プログラマブルロジックコントローラの使用に適合されたスケジューラ（Kubernetes Custom Scheduler）が、前記プログラマブルロジックコントローラへの前記オートメーションプログラムへの展開に使用されること、
   を特徴とする方法。
10. プログラマブルロジックコントローラのオートメーションプログラムを管理する装置であって、
    前記オートメーションプログラムまたは前記オートメーションプログラムへのリファレンスを仮想Ｋｕｂｅｌｅｔへ送信するＫｕｂｅｒｎｅｔｅｓマスタを備え、
    前記オートメーションプログラムまたは前記オートメーションプログラムへの前記リファレンスを受信するための、前記プログラマブルロジックコントローラでの前記オートメーションプログラムのインストールのための命令を受信するための、及び、前記プログラマブルロジックコントローラでの前記オートメーションプログラムのプロセスを制御するための、前記仮想Ｋｕｂｅｌｅｔを備え、
    前記オートメーションプログラムを前記プログラマブルロジックコントローラへ送信するための、前記オートメーションプログラムのプログラムプロセスを制御するための、及び、前記オートメーションプログラムのプロセスの実行中に、前記プログラマブルロジックコントローラの肯定応答メッセージを受信及び転送するための、前記仮想Ｋｕｂｅｌｅｔのプロバイダインタフェースを備える、
    装置。