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

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

Info

Publication number
JP2023518198A
JP2023518198A JP2022555049A JP2022555049A JP2023518198A JP 2023518198 A JP2023518198 A JP 2023518198A JP 2022555049 A JP2022555049 A JP 2022555049A JP 2022555049 A JP2022555049 A JP 2022555049A JP 2023518198 A JP2023518198 A JP 2023518198A
Authority
JP
Japan
Prior art keywords
automation
program
platform
kubelet
virtual
Prior art date
Legal status (The legal status 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 status listed.)
Granted
Application number
JP2022555049A
Other languages
English (en)
Other versions
JP7467660B2 (ja
Inventor
ゲッツ，ヤン
アンドレアス ミッターマイアー，ルートヴィヒ
ミュラー，ハラルド
プレムナド，スリーナス
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Siemens AG
Original Assignee
Siemens AG
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 Siemens AG filed Critical Siemens AG
Publication of JP2023518198A publication Critical patent/JP2023518198A/ja
Application granted granted Critical
Publication of JP7467660B2 publication Critical patent/JP7467660B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • 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
    • 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
    • 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/052—Linking several PLC's
    • 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
    • G05B2219/00—Program-control systems
    • G05B2219/10—Plc systems
    • G05B2219/13—Plc programming
    • G05B2219/13125—Use of virtual, logical connections
    • 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/45587—Isolation or security of 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

Abstract

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

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））に統合されており、このコンテナが、ランタイム環境、いわゆるコンテナランタイムに、コンピュータハードウェア（通常の場合「ノード」と称される）で送信されることである。ここで、「ノード」の構成要素は、いわゆるｋｕｂｅｌｅｔであり、当該ｋｕｂｅｌｅｔはローカルで実行されるソフトウェアであり、当該ソフトウェアは管理を行うＫｕｂｅｒｎｅｔｅｓマスタおよびローカルコンテナランタイムと協働し、ソフトウェアを含むコンテナをローカルにダウンロードし、実行し、動作を監視する。
上述のように、従来、オートメーションプログラムの管理（作成、ロード、スタート、ストップ）は、産業用オートメーションプラットフォーム（産業用コントローラ、ＳＰＳ、ＰＬＣ等）にローカル接続される特別なエンジニアリングシステムを用いて、通常の場合大部分が手動（マニュアル）で、行われる。通常の場合、個別のオートメーションプラットフォーム（例えば、ＰＬＣ（プログラマブルロジックコントローラ））へのオートメーションプログラムの割り当ては、手動で行われる。
また、従来のエンジニアリングシステムを使用することは、多くの場合、このエンジニアリングシステムのインスタンスが産業用ネットワークにローカルで存在することと関連付けられており、「遠隔制御」は、特にはクラウドベースのアプローチにおいては、遠隔作業場からのローカルエンジニアリングシステムへの専用アクセスを必要とし、これは、システム全体の高コストな構成を必要とする。
従って、本発明の課題は、従来のオートメーションプログラムを高い自動化レベルで管理し、制御することであり、その際、可能な限り確立されており、広く普及しており、簡単に学習可能な方法を使用し、管理される産業用オートメーションプラットフォームに対してのエンジニアリングシステムの依存性を低下させ、エンジニアリングシステムへのローカルな依存性を軽減または除去することである。
本発明の課題は、原則的に、Ｋｕｂｅｒｎｅｔｅｓマスタとｋｕｂｅｌｅｔとからなる周知のシステムによって、解決され、そのような周知のシステムは、コンテナベースのプログラムをコンテナランタイム環境において管理および制御するように意図されている。本発明によれば、仮想ｋｕｂｅｌｅｔ（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-kubeletVirtual Kubelet/）では、これは、いわゆるプロバイダにより、解決される。従来の方法では、このプロバイダは、より大きなユニット（クラスタまたはＦａｒｇａｔｅのようなサーバレスコンテナ環境）を、単一のノードのように表示させるか、または、(例えば、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅコンテナのために）非互換性を解決するかの、何れかの役割を果たす。
ノード１、ノード３の図示された本発明による解決手段では、仮想ｋｕｂｅｌｅｔは、オートメーションプログラムのまたはオートメーションプログラムの一部の管理のために、使用される。この目的のために、特別なＰＬＣプロバイダが実装されており、当該ＰＬＣプロバイダは、オートメーションプログラムを、対応するオートメーションプラットフォーム（以下および図中において「ＰＬＣランタイム」と称する）において、起動、停止、監視等をすることができる。プロバイダが満たす必要がある基本機能は、https://github.com/virtual-kubelet/virtual-kubelet、に説明されている。
本実施例では、この特別なプロバイダは、それぞれ仮想ｋｕｂｅｌｅｔ用のプラグインとして実装されているが、他の実装においては、このための別個のコンポーネントを設けてもよい。プラグイン、つまりここでは「ＰＬＣプロバイダ」、は、それ自体、モジュラで構成されていてもよく、特には、ホストである仮想Ｋｕｂｅｌｅｔに接続するための汎用コンポーネントを有していてもよく、他方では、それぞれ特別なタイプのオートメーションプラットフォームを管理するための特定のモジュールを有していてもよい。
具体的には、プロバイダプラグインであるＰＬＣプロバイダは、ここで、アドレス指定されたオートメーションプラットフォーム、いわゆるＰＬＣランタイム、の、オートメーションプログラムの実行環境と、通信する。ここでノード１を用いて、以下の場合について説明する、すなわち、仮想ｋｕｂｅｌｅｔがＰＬＣプロバイダと共に、管理されるオートメーションプラットフォーム（ノード１）それ自体にインストールされている場合について、説明する。仮想ＫｕｂｅｌｅｔとＰＬＣプロバイダは、この場合、ファームウェアの構成部であってよいし、または、別個のプログラムとしてインストールされていてもよい。反対に、ノード３を用いて、以下の場合が与えられている、すなわち、仮想ｋｕｂｅｌｅｔとＰＬＣプロバイダが、別個のマシン、例えば、産業用エッジデバイス、で実行される場合が与えられており、当該エッジデバイスは、オートメーションプラットフォームであるノード３を含む産業レベルに対するインタフェースと、Ｋｕｂｅｒｎｅｔｅｓマスタに対するさらなるインタフェースと、を有し、後者はクラウドプロバイダのサーバ上でも実行可能である。
プログラミング準備のため、オートメーションプラットフォーム（ＰＬＣ）のオートメーションプログラムが、例えば、産業用エンジニアリングシステムのプロジェクト（例えばＴＩＡポータルプロジェクト）内で、生成され、「ポッド」にマッピングされ、参照可能なソースに格納される。オートメーションプラットフォーム（ＰＬＣまたは仮想ＰＬＣ）それ自体は、構成済みであり、使用可能であるようにネットワーク技術的に設定済みである。仮想ＰＬＣは、この場合、仮想マシンで実行される純粋にソフトウェアベースのＰＬＣインスタンスである。仮想ＰＬＣの機能と論理インタフェースは、実ＰＬＣに対応する。オートメーションプラットフォームであるノード１、ノード３を管理するためのＰＬＣプロバイダのいくつかの基本機能のマッピングは、以下のようにして、可能である。
・ ＣｒｅａｔｅＰｏｄ －＞ 存在するＰＬＣまたは仮想ＰＬＣインスタンスにオートメーションプログラムをロードし、それを起動させる。その際、ＰＬＣ／ＰＬＣインスタンスの対応するリソースが確保され、確保済みとしてマークされる。
・ ＵｐｄａｔｅＰｏｄ －＞ ＰＬＣ／仮想ＰＬＣインスタンスで実行中のオートメーションプログラムを変更する。変更は、ソフトウェアの状態、および／または、オートメーションプログラムの構成または実行パラメータ、に関連し得る。
・ ＤｅｌｅｔｅＰｏｄ －＞ 実行中のオートメーションプログラムを停止し、ＰＬＣ／仮想ＰＬＣインスタンスにおいて確保されたリソースを解放する。
・ ＧｅｔＣｏｎｔａｉｎｅｒＬｏｇｓ －＞ ＰＬＣの診断バッファを転送する、または、それに対応するオートメーションプログラムに関連するＰＬＣの診断バッファの一部分を転送する。
・ ＧｅｔＰｏｄＳｔａｔｕｓ －＞ 関連するオートメーションプログラムの現在の実行詳細、例えば、サイクルタイム、メモリ要件、診断ステータス、表示コンテンツ、を表示する。
・ ＮｏｄｅＣｏｎｄｉｔｉｏｎｓ －＞ ＰＬＣ／仮想ＰＬＣインスタンスの抽象化状態（実行可能、停止済み、起動中、メモリ不足）を表示する。
・ ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ －＞ ＰＬＣのバージョンを表示する。
このマッピングでは、存在するエンジニアリングツール（例えばＴＩＡポータル、ＳＴＥＰ７）を完全にＰＬＣプロバイダにおいて使用できる。その一方で、モジュールコンポーネントは、ＰＬＣプロバイダをスリムに保ち、またコンピューティング容量が小さいノード上で実行可能とするために、有利である。従って、例えば、上記の基本機能は、モジュールまたはプラグインとして、ＰＬＣプロバイダに、設けられてよい。また、これらの基本機能を少なくとも部分的に、それに対応するサービスをクラウドまたはその他の稼働中のエンジニアリングシステムで呼び出すことによって、実装することもできる。
ＰＬＣプロバイダは、従って、ポッドの起動時に、そのために設けられているか参照されるＰＬＣプログラムをロードし、ＰＬＣランタイムに転送することができるようにするため、動作プロセスを実装している。これは、参照されるソース（リポジトリ）によって、または、他のソースやディレクトリを介して、行われ得る、代替的に、少なくとも部分的にＰＬＣプログラムそれ自体が動作されるようにＫｕｂｅｒｎｅｔｅｓコンポーネント（Ｋｕｂｅｒｎｅｔｅｓマスタ、仮想Ｋｕｂｅｌｅｔ）を変更することもできる。追加的に、ＰＬＣプロバイダによって、または、ＰＬＣプロバイダによってアドレス指定されたサービスによって、オートメーションプログラムを変更することもでき、特には、ＰＬＣランタイムのタイプや現在の状態（ステータス、例えば、空きメモリ容量、ファームウェアのバージョン等）に応じて、つまり実行環境またはオートメーションプラットフォーム自体に応じて、プログラムコードをプラットフォーム固有に適合すること又はコンパイルすることができる。
特には、混在システム（異なるＰＬＣタイプ、ソフトウェアコンテナシステムと混在するＰＬＣ、標準ＰＣ、クラウドでのコンテナランタイム）では、ランタイムの特定のタイプの区別／識別が、可能となる必要がある。これは、例えばＫｕｂｅｒｎｅｔｅｓにおけるラベルを介して、行うことができる。また、ＰＬＣプロバイダは、実行環境のタイプと他のパラメータをそれ自体で決定し、オートメーションプログラムおよびアドレス指定または、一般に、実行環境とのデータ交換、を対応的に適合することもできる。
ＰＬＣプロバイダは、オートメーションプラットフォーム（ＰＬＣ）に統合可能であり、このことは、特には新しいタイプのオートメーションプラットフォームにおいて、ファームウェアと共にプリインストールすることによって、または、ファームウェアの一部としてプリインストールするによって、納品時に既に容易に実行できる。上述したように、このことは、ノード１の例に見ることができる。既存のシステムの場合、ＰＬＣプロバイダは、ネットワークを介してオートメーションプラットフォーム／ＰＬＣおよびそこでの実行環境と接続するために、既存のコンピューティングノードで、又は、代替的に追加のノードで、起動され得る。この場合、例えば、エッジデバイス（産業用エッジデバイス）またはクラウドノードを、ＰＬＣプロバイダのプラットフォームとして、または、対応して設計された仮想ｋｕｂｅｌｅｔのプラットフォームとして、使用することができる、これについては図のノード３を参照されたい。
ソフトウェア展開のルート、すなわち少なくとも１つのオートメーションプログラムを有するポッドの「デプロイメント」のルートについて上述したが、それとは逆方向のルートで、制御情報、ステータスメッセージ、デバッグ値等を、「ターゲット」から関係する仮想ｋｕｂｅｌｅｔのＰＬＣプロバイダへと、そしてそこから必要に応じて処理された形でさらにＫｕｂｅｒｎｅｔｅｓマスタまたは代替ターゲットへと、送信することができる。そのような代替ターゲットは、特に、オートメーションネットワークの内部または外部の駆動装置及び監視装置（ＨＭＩ；ＳＣＡＤＡ；ＭＥＳ）であってよい。クラウドベースのアプリケーションにも到達され得る。ターゲットは、Ｋｕｂｅｒｎｅｔｅｓマスタを用いて、設定可能であり、代替的に、Ｋｕｂｅｒｎｅｔｅｓマスタは、このデータを、必要に応じて変更した形で、転送することもできる。
本発明によれば、このようにして、ＰＬＣプログラムは、コンテナオーケストレーションシステムの手段を用いて、管理されそして動作され得る。その際、ＰＬＣプログラムをソフトウェアコンテナと共に混在操作することも可能である。
これにより、ノード容量（英：node capacity、独：Knotenkapazitaet）、システムの負荷、可用性等に応じて（つまり、一般に、サービスパラメータの品質に応じて）、ノードへのＰＬＣプログラムの（部分的）自動化割り当てが、可能である。これは、ＰＬＣプログラムまたはＰＬＣプログラムの一部の自動化された「デプロイメント」（初期インストール、アップデート、トラブルシューティング、テスト等）により、より迅速なコミッショニング時間とアップデート時間を、を可能とする。さらなる有利な点は、現在可能な代替切り換え手法による、すなわち、ＰＬＣプログラムの監視、同じまたは他のノードでの再起動による、可用性の向上である。今や、ＣＩ／ＣＤシステムまたはＤｅｖＯｐｓへの簡潔な統合、つまり、ソースコード変更、変換、テスト、コミッショニングの自動化チェーンへの簡潔な統合、も可能である。
産業用オートメーションプラットフォーム用に設定されたプロバイダプラグインを備える仮想ｋｕｂｅｌｅｔの使用は、例えば、モニタリング、トレース、ロールアウト戦略、バージョニング、ロールバックのための既に存在するツールを用いた、ＰＬＣプログラムの管理のためのＫｕｂｅｒｎｅｔｅｓ「エコシステム」を開発するＰＬＣプログラムの管理は、従って、オープンソース環境から、確立された標準ツールを用いて、実行可能であり、当該オープンソース環境では広範な能力基盤（英：competence base、独：Kompetenzbasis）が与えられており、使用されるソフトウェアツールが絶えず開発されている。（コンテナと従来のＰＬＣを備えるＩＴベースの）混在システムでの一元的なソフトウェア管理は、一元的なインフラストラクチャによる、そして、ＩＴシステム専門家の追加的な教育訓練の必要性が低いことによる、利点をもたらす。さらに、現場の既存ＰＬＣシステムは、ＩＴメカニズムを用いて、ＰＬＣシステムを変更することなく、開発され得る。
本発明は、請求項１の前提部分に係る産業用オートメーションプラットフォームのオートメーションアプリケーションを管理する方法、および、請求項１０の前提部分に係る産業用オートメーションプラットフォームのオートメーションアプリケーションを管理する装置、に関する。
オートメーションシステムのオートメーションアプリケーションは、１つまたは複数の、例えばＩＥＣ ６１１３１規格に準拠しているオートメーションプログラムであって、産業用オートメーションプラットフォームで実行されるオートメーションプログラム、からなる。そのような産業用オートメーションプラットフォームは、例えば、プログラマブルロジックコントローラ（英：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-kubeletVirtual Kubelet/）では、これは、いわゆるプロバイダにより、解決される。従来の方法では、このプロバイダは、より大きなユニット（クラスタまたはＦａｒｇａｔｅのようなサーバレスコンテナ環境）を、単一のノードのように表示させるか、または、(例えば、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅコンテナのために）非互換性を解決するかの、何れかの役割を果たす。
ノード１、ノード３の図示された本発明による解決手段では、仮想ｋｕｂｅｌｅｔは、オートメーションプログラムのまたはオートメーションプログラムの一部の管理のために、使用される。この目的のために、特別なＰＬＣプロバイダが実装されており、当該ＰＬＣプロバイダは、オートメーションプログラムを、対応するオートメーションプラットフォーム（以下および図中において「ＰＬＣランタイム」と称する）において、起動、停止、監視等をすることができる。プロバイダが満たす必要がある基本機能は、https://github.com/virtual-kubelet/virtual-kubelet、に説明されている。
本実施例では、この特別なプロバイダは、それぞれ仮想ｋｕｂｅｌｅｔ用のプラグインとして実装されているが、他の実装においては、このための別個のコンポーネントを設けてもよい。プラグイン、つまりここでは「ＰＬＣプロバイダ」、は、それ自体、モジュラで構成されていてもよく、特には、ホストである仮想Ｋｕｂｅｌｅｔに接続するための汎用コンポーネントを有していてもよく、他方では、それぞれ特別なタイプのオートメーションプラットフォームを管理するための特定のモジュールを有していてもよい。
具体的には、プロバイダプラグインであるＰＬＣプロバイダは、ここで、アドレス指定されたオートメーションプラットフォーム、いわゆるＰＬＣランタイム、の、オートメーションプログラムの実行環境と、通信する。ここでノード１を用いて、以下の場合について説明する、すなわち、仮想ｋｕｂｅｌｅｔがＰＬＣプロバイダと共に、管理されるオートメーションプラットフォーム（ノード１）それ自体にインストールされている場合について、説明する。仮想ＫｕｂｅｌｅｔとＰＬＣプロバイダは、この場合、ファームウェアの構成部であってよいし、または、別個のプログラムとしてインストールされていてもよい。反対に、ノード３を用いて、以下の場合が与えられている、すなわち、仮想ｋｕｂｅｌｅｔとＰＬＣプロバイダが、別個のマシン、例えば、産業用エッジデバイス、で実行される場合が与えられており、当該エッジデバイスは、オートメーションプラットフォームであるノード３を含む産業レベルに対するインタフェースと、Ｋｕｂｅｒｎｅｔｅｓマスタに対するさらなるインタフェースと、を有し、後者はクラウドプロバイダのサーバ上でも実行可能である。
プログラミング準備のため、オートメーションプラットフォーム（ＰＬＣ）のオートメーションプログラムが、例えば、産業用エンジニアリングシステムのプロジェクト（例えばＴＩＡポータルプロジェクト）内で、生成され、「ポッド」にマッピングされ、参照可能なソースに格納される。オートメーションプラットフォーム（ＰＬＣまたは仮想ＰＬＣ）それ自体は、構成済みであり、使用可能であるようにネットワーク技術的に設定済みである。仮想ＰＬＣは、この場合、仮想マシンで実行される純粋にソフトウェアベースのＰＬＣインスタンスである。仮想ＰＬＣの機能と論理インタフェースは、実ＰＬＣに対応する。オートメーションプラットフォームであるノード１、ノード３を管理するためのＰＬＣプロバイダのいくつかの基本機能のマッピングは、以下のようにして、可能である。
・ ＣｒｅａｔｅＰｏｄ －＞ 存在するＰＬＣまたは仮想ＰＬＣインスタンスにオートメーションプログラムをロードし、それを起動させる。その際、ＰＬＣ／ＰＬＣインスタンスの対応するリソースが確保され、確保済みとしてマークされる。
・ ＵｐｄａｔｅＰｏｄ －＞ ＰＬＣ／仮想ＰＬＣインスタンスで実行中のオートメーションプログラムを変更する。変更は、ソフトウェアの状態、および／または、オートメーションプログラムの構成または実行パラメータ、に関連し得る。
・ ＤｅｌｅｔｅＰｏｄ －＞ 実行中のオートメーションプログラムを停止し、ＰＬＣ／仮想ＰＬＣインスタンスにおいて確保されたリソースを解放する。
・ ＧｅｔＣｏｎｔａｉｎｅｒＬｏｇｓ －＞ ＰＬＣの診断バッファを転送する、または、それに対応するオートメーションプログラムに関連するＰＬＣの診断バッファの一部分を転送する。
・ ＧｅｔＰｏｄＳｔａｔｕｓ －＞ 関連するオートメーションプログラムの現在の実行詳細、例えば、サイクルタイム、メモリ要件、診断ステータス、表示コンテンツ、を表示する。
・ ＮｏｄｅＣｏｎｄｉｔｉｏｎｓ －＞ ＰＬＣ／仮想ＰＬＣインスタンスの抽象化状態（実行可能、停止済み、起動中、メモリ不足）を表示する。
・ ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ －＞ ＰＬＣのバージョンを表示する。
このマッピングでは、存在するエンジニアリングツール（例えばＴＩＡポータル、ＳＴＥＰ７）を完全にＰＬＣプロバイダにおいて使用できる。その一方で、モジュールコンポーネントは、ＰＬＣプロバイダをスリムに保ち、またコンピューティング容量が小さいノード上で実行可能とするために、有利である。従って、例えば、上記の基本機能は、モジュールまたはプラグインとして、ＰＬＣプロバイダに、設けられてよい。また、これらの基本機能を少なくとも部分的に、それに対応するサービスをクラウドまたはその他の稼働中のエンジニアリングシステムで呼び出すことによって、実装することもできる。
ＰＬＣプロバイダは、従って、ポッドの起動時に、そのために設けられているか参照されるＰＬＣプログラムをロードし、ＰＬＣランタイムに転送することができるようにするため、動作プロセスを実装している。これは、参照されるソース（リポジトリ）によって、または、他のソースやディレクトリを介して、行われ得る、代替的に、少なくとも部分的にＰＬＣプログラムそれ自体が動作されるようにＫｕｂｅｒｎｅｔｅｓコンポーネント（Ｋｕｂｅｒｎｅｔｅｓマスタ、仮想Ｋｕｂｅｌｅｔ）を変更することもできる。追加的に、ＰＬＣプロバイダによって、または、ＰＬＣプロバイダによってアドレス指定されたサービスによって、オートメーションプログラムを変更することもでき、特には、ＰＬＣランタイムのタイプや現在の状態（ステータス、例えば、空きメモリ容量、ファームウェアのバージョン等）に応じて、つまり実行環境またはオートメーションプラットフォーム自体に応じて、プログラムコードをプラットフォーム固有に適合すること又はコンパイルすることができる。
特には、混在システム（異なるＰＬＣタイプ、ソフトウェアコンテナシステムと混在するＰＬＣ、標準ＰＣ、クラウドでのコンテナランタイム）では、ランタイムの特定のタイプの区別／識別が、可能となる必要がある。これは、例えばＫｕｂｅｒｎｅｔｅｓにおけるラベルを介して、行うことができる。また、ＰＬＣプロバイダは、実行環境のタイプと他のパラメータをそれ自体で決定し、オートメーションプログラムおよびアドレス指定または、一般に、実行環境とのデータ交換、を対応的に適合することもできる。
ＰＬＣプロバイダは、オートメーションプラットフォーム（ＰＬＣ）に統合可能であり、このことは、特には新しいタイプのオートメーションプラットフォームにおいて、ファームウェアと共にプリインストールすることによって、または、ファームウェアの一部としてプリインストールするによって、納品時に既に容易に実行できる。上述したように、このことは、ノード１の例に見ることができる。既存のシステムの場合、ＰＬＣプロバイダは、ネットワークを介してオートメーションプラットフォーム／ＰＬＣおよびそこでの実行環境と接続するために、既存のコンピューティングノードで、又は、代替的に追加のノードで、起動され得る。この場合、例えば、エッジデバイス（産業用エッジデバイス）またはクラウドノードを、ＰＬＣプロバイダのプラットフォームとして、または、対応して設計された仮想ｋｕｂｅｌｅｔのプラットフォームとして、使用することができる、これについては図のノード３を参照されたい。
ソフトウェア展開のルート、すなわち少なくとも１つのオートメーションプログラムを有するポッドの「デプロイメント」のルートについて上述したが、それとは逆方向のルートで、制御情報、ステータスメッセージ、デバッグ値等を、「ターゲット」から関係する仮想ｋｕｂｅｌｅｔのＰＬＣプロバイダへと、そしてそこから必要に応じて処理された形でさらにＫｕｂｅｒｎｅｔｅｓマスタまたは代替ターゲットへと、送信することができる。そのような代替ターゲットは、特に、オートメーションネットワークの内部または外部の駆動装置及び監視装置（ＨＭＩ；ＳＣＡＤＡ；ＭＥＳ）であってよい。クラウドベースのアプリケーションにも到達され得る。ターゲットは、Ｋｕｂｅｒｎｅｔｅｓマスタを用いて、設定可能であり、代替的に、Ｋｕｂｅｒｎｅｔｅｓマスタは、このデータを、必要に応じて変更した形で、転送することもできる。
本発明によれば、このようにして、ＰＬＣプログラムは、コンテナオーケストレーションシステムの手段を用いて、管理されそして動作され得る。その際、ＰＬＣプログラムをソフトウェアコンテナと共に混在操作することも可能である。
これにより、ノード容量（英：node capacity、独：Knotenkapazitaet）、システムの負荷、可用性等に応じて（つまり、一般に、サービスパラメータの品質に応じて）、ノードへのＰＬＣプログラムの（部分的）自動化割り当てが、可能である。これは、ＰＬＣプログラムまたはＰＬＣプログラムの一部の自動化された「デプロイメント」（初期インストール、アップデート、トラブルシューティング、テスト等）により、より迅速なコミッショニング時間とアップデート時間を、を可能とする。さらなる有利な点は、現在可能な代替切り換え手法による、すなわち、ＰＬＣプログラムの監視、同じまたは他のノードでの再起動による、可用性の向上である。今や、ＣＩ／ＣＤシステムまたはＤｅｖＯｐｓへの簡潔な統合、つまり、ソースコード変更、変換、テスト、コミッショニングの自動化チェーンへの簡潔な統合、も可能である。
産業用オートメーションプラットフォーム用に設定されたプロバイダプラグインを備える仮想ｋｕｂｅｌｅｔの使用は、例えば、モニタリング、トレース、ロールアウト戦略、バージョニング、ロールバックのための既に存在するツールを用いた、ＰＬＣプログラムの管理のためのＫｕｂｅｒｎｅｔｅｓ「エコシステム」を開発するＰＬＣプログラムの管理は、従って、オープンソース環境から、確立された標準ツールを用いて、実行可能であり、当該オープンソース環境では広範な能力基盤（英：competence base、独：Kompetenzbasis）が与えられており、使用されるソフトウェアツールが絶えず開発されている。（コンテナと従来のＰＬＣを備えるＩＴベースの）混在システムでの一元的なソフトウェア管理は、一元的なインフラストラクチャによる、そして、ＩＴシステム専門家の追加的な教育訓練の必要性が低いことによる、利点をもたらす。さらに、現場の既存ＰＬＣシステムは、ＩＴメカニズムを用いて、ＰＬＣシステムを変更することなく、開発され得る。
Ｋｕｂｅｒｎｅｔｅｓを拡張する場合、いわゆる仮想ｋｕｂｅｌｅｔが導入され、これらは、図中、ノード１、ノード３により示されている。仮想ｋｕｂｅｌｅｔは、従来、互換性のないコンテナ環境のソフトウェアコンテナ(例えば、オペレーティングシステムMicrosoft Windows（登録商標）を搭載したコンピュータのWindows（登録商標）コンテナ、を管理するために使用される。仮想ｋｕｂｅｌｅｔの原則は、Ｋｕｂｅｒｎｅｔｅｓマスタに対するそのインタフェースが、従来のｋｕｂｅｌｅｔのインタフェースのように、設計されていることである。それは、従って、「上位へは」、従来のｋｕｂｅｌｅｔと同じインタフェースを有し、そして、マスタは、逆方向に、また従来のＫｕｂｅｒｎｅｔｅｓノードと、つまり、コンテナ（またはポッド）を管理可能なノードと、通信する、ノード２の例を参照。「下位」へは、つまり、「ターゲット」との通信においては、仮想ｋｕｂｅｌｅｔは、原則的に、任意のインタフェースを有することができる。現行の実装（https://github.com/virtual-kubelet/virtual-kubelet）では、これは、いわゆるプロバイダにより、解決される。従来の方法では、このプロバイダは、より大きなユニット（クラスタまたはＦａｒｇａｔｅのようなサーバレスコンテナ環境）を、単一のノードのように表示させるか、または、(例えば、Ｍｉｃｒｏｓｏｆｔ Ａｚｕｒｅコンテナのために）非互換性を解決するかの、何れかの役割を果たす。

Claims (10)

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

JP2022555049A 2020-03-20 2021-02-25 産業用オートメーションプラットフォームのオートメーションプログラムを管理する方法および装置 Active JP7467660B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
EP20164384.8 2020-03-20
EP20164384.8A EP3882766A1 (de) 2020-03-20 2020-03-20 Verfahren und anordnung zum verwalten von automatisierungs-programmen für industrielle automatisierungsplattformen
PCT/EP2021/054633 WO2021185547A1 (de) 2020-03-20 2021-02-25 Verfahren und anordnung zum verwalten von automatisierungs-programmen für industrielle automatisierungsplattformen

Publications (2)

Publication Number Publication Date
JP2023518198A true JP2023518198A (ja) 2023-04-28
JP7467660B2 JP7467660B2 (ja) 2024-04-15

Family

ID=69941163

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2022555049A Active JP7467660B2 (ja) 2020-03-20 2021-02-25 産業用オートメーションプラットフォームのオートメーションプログラムを管理する方法および装置

Country Status (6)

Country Link
US (1) US20230324870A1 (ja)
EP (2) EP3882766A1 (ja)
JP (1) JP7467660B2 (ja)
KR (1) KR20220154233A (ja)
CN (1) CN115335807A (ja)
WO (1) WO2021185547A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20240103491A1 (en) * 2022-09-22 2024-03-28 Rockwell Automation Technologies, Inc. Automation device firmware as a service via a container implementation

Family Cites Families (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2004280305A (ja) 2003-03-13 2004-10-07 Omron Corp プログラマブルコントローラ用機器及びプログラマブルコントローラ並びにデータの受渡方法
JP6417256B2 (ja) 2015-03-30 2018-11-07 東洋電機製造株式会社 電動機駆動装置
EP3418833B1 (de) 2017-06-20 2021-04-07 Siemens Aktiengesellschaft Verfahren und anordnung zum zugriff eines ersten computers auf eine virtuelle maschine eines zweiten computers
JP7020198B2 (ja) 2018-03-09 2022-02-16 オムロン株式会社 制御装置および制御システム

Also Published As

Publication number Publication date
EP4091050B1 (de) 2023-11-15
CN115335807A (zh) 2022-11-11
US20230324870A1 (en) 2023-10-12
EP3882766A1 (de) 2021-09-22
EP4091050C0 (de) 2023-11-15
EP4091050A1 (de) 2022-11-23
KR20220154233A (ko) 2022-11-21
JP7467660B2 (ja) 2024-04-15
WO2021185547A1 (de) 2021-09-23

Similar Documents

Publication Publication Date Title
CN108549717B (zh) 自动化部署运维Hadoop生态圈组件的方法及系统
US10705511B2 (en) Abstraction layers for automation applications
US20140228978A1 (en) Method for generating and handling applications for components of a distributed control system and engineering system for implementing the process
US11307550B2 (en) Sequence control of program modules
US9720404B2 (en) Gateway offering logical model mapped to independent underlying networks
US20160103431A1 (en) System and method for point by point hot cutover of controllers and ios
CN109565526B (zh) 用于将数据源系统连接到it系统上的方法和网关
US20170351508A1 (en) Method for updating firmware of devices
CN109964181B (zh) 用于工业自动化设备的控制器和对这种控制器编程和运行的方法
US20200278891A1 (en) Dynamic Load Balancing In Network Centric Process Control Systems
US9389604B2 (en) Method and system for the dynamic allocation of program functions in distributed control systems
JP7467660B2 (ja) 産業用オートメーションプラットフォームのオートメーションプログラムを管理する方法および装置
Koziolek et al. Dynamic updates of virtual plcs deployed as kubernetes microservices
Schäfer et al. Migration and synchronization of plant segments with asset administration shells
WO2013068023A1 (en) Arrangement and method for distributing a control system engineering tool and/or a control application software
CN111897565A (zh) 基于物联网的数据处理方法、装置和设备
Mayrhofer et al. Assessing adaptability of software architectures for cyber physical production systems
JP2023055628A (ja) 産業用オートメーション装置用の更新されたアプリケーションをコミッショニングする方法および装置
EP3239864A1 (en) Method for generating a petri net simulation model of an industrial control system
US11651006B2 (en) Method of visualizing screen content on a data visualization system, and data visualization system for visualizing screen content
US11880676B1 (en) Containerized modeling of device updates or modifications via digital twins
US11947342B1 (en) Container registry and subscription service for industrial systems
EP3940471A1 (en) Control system, support device, and support program
US20230421615A1 (en) Systems and methods for automatically deploying security updates in an operations technology network
US20240134630A1 (en) Containerized modeling of device updates or modifications via digital twins

Legal Events

Date Code Title Description
A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20221128

A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20221128

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20231025

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20231128

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20231212

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20240305

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20240403

R150 Certificate of patent or registration of utility model

Ref document number: 7467660

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150