知財求人 - 知財ポータルサイト「IP Force」
特表2024-532757モジュール式プラントのデジタルツインモデルに基づいてシミュレーションの構成をオーケストレーションするコンピュータ実行方法及びオーケストレーションシステム
(19)【発行国】日本国特許庁(JP)
(12)【公報種別】公表特許公報(A)
(11)【公表番号】
(43)【公表日】2024-09-10
(54)【発明の名称】モジュール式プラントのデジタルツインモデルに基づいてシミュレーションの構成をオーケストレーションするコンピュータ実行方法及びオーケストレーションシステム
(51)【国際特許分類】
G06F 9/50 20060101AFI20240903BHJP
G06F 11/36 20060101ALI20240903BHJP
【ＦＩ】
G06F9/50 150Z
G06F11/36 196
【審査請求】有
【予備審査請求】未請求
(21)【出願番号】P 2024508317
(86)(22)【出願日】2022-08-08
(85)【翻訳文提出日】2024-04-09
(86)【国際出願番号】 EP2022072185
(87)【国際公開番号】W WO2023016960
(87)【国際公開日】2023-02-16
(31)【優先権主張番号】21190289.5
(32)【優先日】2021-08-09
(33)【優先権主張国・地域又は機関】EP
(81)【指定国・地域】
【公序良俗違反の表示】
（特許庁注：以下のものは登録商標）
１．ＳＩＭＵＬＩＮＫ
(71)【出願人】
【識別番号】390039413
【氏名又は名称】シーメンス アクチエンゲゼルシヤフト
【氏名又は名称原語表記】Ｓｉｅｍｅｎｓ Ａｋｔｉｅｎｇｅｓｅｌｌｓｃｈａｆｔ
(74)【代理人】
【識別番号】110003317
【氏名又は名称】弁理士法人山口・竹本知的財産事務所
(74)【代理人】
【識別番号】100075166
【弁理士】
【氏名又は名称】山口 巖
(74)【代理人】
【識別番号】100133167
【弁理士】
【氏名又は名称】山本 浩
(74)【代理人】
【識別番号】100169627
【弁理士】
【氏名又は名称】竹本 美奈
(72)【発明者】
【氏名】ボテロ ハルブラウブ，アンドレス
(72)【発明者】
【氏名】ゲッツ，ヤン
(72)【発明者】
【氏名】ヘルト，ハラルト
【テーマコード（参考）】
5B042
【Ｆターム（参考）】
5B042HH07
(57)【要約】
モジュール式プラント（Pm, PM1, PM2, PM3）のデジタルツインモデル（DTM1, DTM2, DTM3）に基づいて、モデルベースのシミュレーションの構成が自動的に生成され展開されるように、シミュレーションの構成をオーケストレーションするために、「Functional Mock-up Unit <FMU>」機能（FMU-T）と組み合わされた「Functional Mock-up Interface <FMI>」機能（FMI-T）を含むロジカル「System Structure and Parameterization <SSP>」機能（SSP-T）に基づいて、（１）モジュール式プラントの分散ＯＴ（Operational-Technology）アプリケーション（OTAd, ED1, ED2, ED3）に関して、プラントのオートメーションのためにキャプチャされるオートメーションデータ（AD1, AD2, AD3）の割り当てルール（AR1, AR2, AR3）を含んでいて分散ＯＴアプリケーションに割り当てられるシミュレーションのモデルコンポーネント（MCs,1, MCs,2, MCs,3）を生成する（grt）こと、（２）シミュレーションの構成をオーケストレーションする過程において、シミュレーションのモデルコンポーネントを分散ＯＴアプリケーションに展開（dpl）し、この展開に際し、分散ＯＴアプリケーションに対し、ＦＭＩ機能の一部として「Functional Mock-up Unit ＜ＦＭＵ＞」機能（FMU-T1, FMU-T2, FMU-T3）を有するＳＳＰ機能を使用し、及び、分散ＯＴアプリケーションに関して、サーバ－クライアント方式でＦＭＩ機能の一部として、・ＳＳＰ機能に埋め込まれた「プロキシＦＭＵ」エンティティ（PFMU-E1, PFMU-E2, PFMU-E3）及び・分散ＯＴアプリケーションで実行される対応する「被制御ＦＭＵ」エンティティ（RCFMU-E1, RCFMU-E2, RCFMU-E3）を有する「Remote Procedure Call ＜ＲＰＣ＞」技術ベースのプロキシＦＭＵ機能（PFMU-T1, PFMU-T2, PFMU-T3）を実行する。
【特許請求の範囲】
【請求項1】
モジュール式プラント（Ｐｍ、ＰＭ１、ＰＭ２、ＰＭ３）のデジタルツインモデル（ＤＴＭ１、ＤＴＭ２、ＤＴＭ３）に基づいてシミュレーションの構成をオーケストレーションするコンピュータ実行方法であって、モデルベースのシミュレーションの構成に、
ａ）ロジカル「ＳＳＰ：System Structure and Parameterization」機能（ＳＳＰ－Ｔ）
ａ１）次のａ１１）及びａ１２）を論理的に記述し
ａ１１）シミュレーションのためのモデルコンポーネントが、複合コンポーネントへの展開のためにどのように接続され構成されるか、及び、
ａ１２）モデルパラメータ化データがどのように記憶され、それぞれの前記モデルコンポーネントと前記複合コンポーネントとの間でどのように交換されるか
ａ２）ＸＭＬファイル及びコンパイルしたＣコードを包含した「ＺＩＰアーカイブ」ベースの「ＦＭＵ：Functional Mock-up Unit」機能（ＦＭＵ－Ｔ）を介してシミュレーションを共有するための「ＦＭＩ：Functional Mock-up Interface」機能（ＦＭＩ－Ｔ）を含んでいる、
が使用され、
ｂ） 前記モジュール式プラント（Ｐｍ、ＰＭ１、ＰＭ２、ＰＭ３）の分散ＯＴ（operational technology）アプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）、この分散ＯＴアプリケーションはフィールドデバイスのエッジデバイス（ＥＤ１、ＥＤ２、ＥＤ３）である、に関して、前記モジュール式プラント（Ｐｍ、ＰＭ１、ＰＭ２、ＰＭ３）のオートメーションのためにキャプチャされるオートメーションデータ（ＡＤ１、ＡＤ２、ＡＤ３）の割り当てルール（ＡＲ１、ＡＲ２、ＡＲ３）を含んでいて前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）に割り当てられるシミュレーションのモデルコンポーネント（ＭＣｓ，１、ＭＣｓ，２、ＭＣｓ，３）を生成（ｇｒｔ）し、
ｃ） シミュレーションの構成をオーケストレーションする過程において、前記シミュレーションのモデルコンポーネント（ＭＣｓ，１、ＭＣｓ，２、ＭＣｓ，３）を前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）に展開（ｄｐｌ）し、この展開に際し、前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）に対し、前記ＦＭＩ機能（ＦＭＩ－Ｔ）の一部として前記「Functional Mock-up Unit ＜ＦＭＵ＞」機能（ＦＭＵ－Ｔ）を有する前記ＳＳＰ機能（ＳＳＰ－Ｔ）を使用し、及び、前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）に関して、サーバ－クライアント方式で前記ＦＭＩ機能（ＦＭＩ－Ｔ）の一部として、
・前記ＳＳＰ機能（ＳＳＰ－Ｔ）に埋め込まれた「プロキシＦＭＵ」エンティティ（ＰＦＭＵ－Ｅ１，ＰＦＭＵ－Ｅ２，ＰＦＭＵ－Ｅ３）及び
・前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）で実行される対応する「被制御ＦＭＵ」エンティティ（ＲＣＦＭＵ－Ｅ１，ＲＣＦＭＵ－Ｅ２，ＲＣＦＭＵ－Ｅ３）
を有する「ＲＰＣ：Remote Procedure Call」技術ベースのプロキシＦＭＵ機能（ＰＦＭＵ－Ｔ１，ＰＦＭＵ－Ｔ２，ＰＦＭＵ－Ｔ３）を実行し、
ｄ） 前記オートメーションデータ（ＡＤ１、ＡＤ２、ＡＤ３）の前記割り当てルール（ＡＲ１、ＡＲ２、ＡＲ３）に従って、前記シミュレーションのモデルコンポーネント（ＭＣｓ，１、ＭＣｓ，２、ＭＣｓ，３）の展開（ｄｐｌ）の結果として、前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）に前記オートメーションデータ（ＡＤ１、ＡＤ２、ＡＤ３）を展開（ｄｐｌ）する、
ことを特徴とする、コンピュータ実行方法。
【請求項2】
請求項１に記載のコンピュータ実行方法を実行するコンピュータ実行ツール（ＣＩＴ）であって、特にＡＰＰなどのコンピュータプログラムとして設計され、・非一時的プロセッサ可読記憶媒体（ＳＴＭ）に記憶された前記コンピュータ実行方法を実行するためのプログラムモジュール（ＰＧＭ）のプロセッサ可読プログラム命令を入れた非一時的プロセッサ可読記憶媒体（ＳＴＭ）と、
・前記記憶媒体（ＳＴＭ）に接続され、前記プログラムモジュール（ＰＧＭ）の前記プロセッサ可読プログラム命令を実行して請求項１に記載のコンピュータ実行方法を実行するプロセッサ（ＰＲＣ）と、
を含む、コンピュータ実行ツール（ＣＩＴ）。
【請求項3】
モジュール式プラント（Ｐｍ、ＰＭ１、ＰＭ２、ＰＭ３）のデジタルツインモデル（ＤＴＭ１、ＤＴＭ２、ＤＴＭ３）に基づいてシミュレーションの構成をオーケストレーションするオーケストレーションシステム（ＯＳ）であって、ａ）ロジカル「ＳＳＰ：System Structure and Parameterization」ツール（ＳＳＰ－Ｔ）
ａ１）次のａ１１）及びａ１２）を論理的に記述し
ａ１１）シミュレーションのためのモデルコンポーネントが、複合コンポーネントへの展開のためにどのように接続され構成されるか、及び、
ａ１２）モデルパラメータ化データがどのように記憶され、それぞれの前記モデルコンポーネントと前記複合コンポーネントとの間でどのように交換されるか
ａ２）ＸＭＬファイル及びコンパイルしたＣコードを包含した「ＺＩＰアーカイブ」ベースの「ＦＭＵ：Functional Mock-up Unit」ツール（ＦＭＵ－Ｔ）を介してシミュレーションを共有するための「ＦＭＩ：Functional Mock-up Interface」ツール（ＦＭＩ－Ｔ）を含んでいる、
を含む、モデルベースのシミュレーションを構成するためのサーバコントローラ（ＳＣＲＴ）を有し、
ｂ） 前記モジュール式プラント（Ｐｍ、ＰＭ１、ＰＭ２、ＰＭ３）の分散ＯＴ（operational technology）アプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）、この分散ＯＴアプリケーションはフィールドデバイスのエッジデバイス（ＥＤ１、ＥＤ２、ＥＤ３）である、に関して、前記モジュール式プラント（Ｐｍ、ＰＭ１、ＰＭ２、ＰＭ３）のオートメーションのためにキャプチャされるオートメーションデータ（ＡＤ１、ＡＤ２、ＡＤ３）の割り当てルール（ＡＲ１、ＡＲ２、ＡＲ３）を含んでいて前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）に割り当てられるシミュレーションのモデルコンポーネント（ＭＣｓ，１、ＭＣｓ，２、ＭＣｓ，３）を生成（ｇｒｔ）する、生成ユニット（ＧＵ）と、
ｃ） 前記サーバコントローラ（ＳＣＲＴ）の展開ツール（ＤＴ）であって、
ｃ１） シミュレーションの構成をオーケストレーションする過程において、前記シミュレーションのモデルコンポーネント（ＭＣｓ，１、ＭＣｓ，２、ＭＣｓ，３）を前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）に展開（ｄｐｌ）し、この展開に際し、前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）に対し、前記ＦＭＩ機能（ＦＭＩ－Ｔ）の一部として前記「Functional Mock-up Unit ＜ＦＭＵ＞」機能（ＦＭＵ－Ｔ）を有する前記ＳＳＰ機能（ＳＳＰ－Ｔ）を使用し、及び、前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）に関して、サーバ－クライアント方式で前記ＦＭＩ機能（ＦＭＩ－Ｔ）の一部として、
・前記サーバコントローラ（ＳＣＲＴ）の前記ＳＳＰ機能（ＳＳＰ－Ｔ）に埋め込まれた「プロキシＦＭＵ」エンティティ（ＰＦＭＵ－Ｅ１，ＰＦＭＵ－Ｅ２，ＰＦＭＵ－Ｅ３）及び
・クライアントコントローラ（ＣＣＲＴ１、ＣＣＲＴ２、ＣＣＲＴ３）を含む前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）で実行される対応する「被制御ＦＭＵ」エンティティ（ＲＣＦＭＵ－Ｅ１，ＲＣＦＭＵ－Ｅ２，ＲＣＦＭＵ－Ｅ３）
を有する「ＲＰＣ：Remote Procedure Call」技術ベースのプロキシＦＭＵ機能（ＰＦＭＵ－Ｔ１，ＰＦＭＵ－Ｔ２，ＰＦＭＵ－Ｔ３）を実行し、
ｃ２） 前記オートメーションデータ（ＡＤ１、ＡＤ２、ＡＤ３）の前記割り当てルール（ＡＲ１、ＡＲ２、ＡＲ３）に従って、前記シミュレーションのモデルコンポーネント（ＭＣｓ，１、ＭＣｓ，２、ＭＣｓ，３）の展開（ｄｐｌ）の結果として、前記分散ＯＴアプリケーション（ＯＴＡｄ、ＥＤ１、ＥＤ２、ＥＤ３）に前記オートメーションデータ（ＡＤ１、ＡＤ２、ＡＤ３）を展開（ｄｐｌ）する、展開ツール（ＤＴ）と、
を有することを特徴とする、オーケストレーションシステム（ＯＳ）。
【請求項4】
特にＡＰＰとして設計されるコンピュータプログラムであり、・非一時的プロセッサ可読記憶媒体（ＳＴＭ）に記憶されたシミュレーションの構成をオーケストレーションするためのプログラムモジュール（ＰＧＭ）のプロセッサ可読プログラム命令を入れた非一時的プロセッサ可読記憶媒体（ＳＴＭ）と、
・前記記憶媒体（ＳＴＭ）に接続され、前記プログラムモジュール（ＰＧＭ）の前記プロセッサ可読プログラム命令を実行してシミュレーションの構成をオーケストレーションするプロセッサ（ＰＲＣ）と、
を有するコンピュータ実行ツール（ＣＩＴ）を特徴とする、請求項３に記載のオーケストレーションシステム（ＯＳ）。
【発明の詳細な説明】
【技術分野】
【0001】
本発明は、請求項１前段に係る、モジュール式プラントのデジタルツインモデルに基づいてシミュレーションの構成をオーケストレーション（構築／運用自動化）するコンピュータ実行方法（コンピュータにより実行される方法）、及び、請求項３前段に係る、モジュール式プラントのデジタルツインモデルに基づいてシミュレーションの構成をオーケストレーションするオーケストレーションシステムに関する。
【背景技術】
【0002】
産業分野（例えば、金属処理や化学処理産業）、医療分野、エネルギー分野、電気通信分野などの様々な技術分野のプラントではモジュール式が進んでおり、プラント所有者は、そのタスクを機器サプライヤに委託し、すべての自動化及び分析機能を組み込んだモジュール式機器を機器サプライヤが提供する。
【0003】
プラント所有者にとっては、オーケストレーションレイヤへのオートメーション（ＭＴＰ、ＰａｃｋＭＬ、その他の多くのもの）の統合に関するベンダアグノスティックソリューションがあるが、機器のエッジデバイスにおける分散分析及びシミュレーションに関してソリューションは存在しない。本願はこの問題を取り上げる。
【0004】
エッジデバイスにおける分散分析とシミュレーションに関しては、いくつかの特定の問題がある。
・フィールドデータにアクセスできるエッジインフラストラクチャにおいて、分散シミュレーションは現在、サポートされていない。
・このような分散型エッジアプリケーションのオートメーションへの統合には、時間がかかる－－ほとんどの場合、タグごとに指定されたOpen Platform Communications Unified Architecture ＜ＯＰＣＵＡ＞タグに従って、複雑なオーケストレーションで有効化、接続、検証を行う必要があり、同期ルーチンを開発する必要がある。
・ハードウェア、ソフトウェア、及びオペレーティングシステムへの、及びシミュレーションとシミュレーションのオーケストレーションへの、過多な依存。
・同期に起因する、多くのエッジデバイス間の分散シミュレーションの複雑な展開。
・フィールドデータにアクセスできるエッジインフラストラクチャにおいて、分散シミュレーションは現在、サポートされていない。
・このような分散型エッジアプリケーションのオートメーションへの統合には、時間がかかる－－ほとんどの場合、タグごとに指定されたOpen Platform Communications Unified Architecture ＜ＯＰＣＵＡ＞タグに従って、複雑なオーケストレーションで有効化、接続、検証を行う必要があり、同期ルーチンを開発する必要がある。
・ハードウェア、ソフトウェア、及びオペレーティングシステムへの、及びシミュレーションとシミュレーションのオーケストレーションへの、過多な依存。
・同期に起因する、多くのエッジデバイス間の分散シミュレーションの複雑な展開。
【0005】
しかし、そのようなアプリケーションの今日のソリューションが利用可能であったとしても、必要とされる機能の大多数は、具体的に１回の使用（シングルユース）のために開発されており、したがって、拡張性をもたないし、大量に広く複製可能ではない。さらに、アプリケーションが、ベンダーソフトウェアに密接に依存したポイントツーポイント通信及び同期を要する。
【発明の概要】
【0006】
本発明の目的は、モジュール式プラントのデジタルツインモデルに基づくシミュレーションの構成をオーケストレーションするコンピュータ実行方法及びオーケストレーションシステムを提案することであり、それによって、オーケストレーションの過程において、モデルベースのシミュレーションの構成が自動的に生成され、展開されるようにする。
【0007】
この目的は、請求項１の前段部分に定義されるコンピュータ実行方法に関して、請求項１の特定事項における特徴によって解決される。
【0008】
この目的は、さらに、請求項２に係るコンピュータ実行方法を実行するコンピュータ実行ツールによって解決される。
【0009】
この目的は、さらに、請求項３の前段部分に定義されるオーケストレーションシミュレータに関して、請求項３の特定事項における特徴によって解決される。
【0010】
請求項１、請求項２、及び請求項３に係る発明の要旨は、モジュール式プラントのデジタルツインモデルと、「Functional Mock-up Unit ＜ＦＭＵ＞」機能と組み合わされた「Functional Mock-up Interface ＜ＦＭＩ＞」機能を含むロジカル「System Structure and Parameterization ＜ＳＳＰ＞」機能と、に基づいてシミュレーションの構成をオーケストレーションするために、（１）モジュール式プラントの分散Operational-Technology（ＯＴ）アプリケーションに関して（ＯＴアプリケーションは、フィールドデバイスのエッジデバイスである）、プラントのオートメーションのためにキャプチャされるオートメーションデータの割り当てルールを含んでいて分散ＯＴアプリケーションに割り当てられるシミュレーションの（シミュレーションした）モデルコンポーネントを生成すること、（２）シミュレーションの構成をオーケストレーションする過程において、シミュレーションのモデルコンポーネントを分散ＯＴアプリケーションに展開し、この展開に際し、分散ＯＴアプリケーションに対し、ＦＭＩ機能の一部として「Functional Mock-up Unit ＜ＦＭＵ＞」機能を有するＳＳＰ機能を使用し、及び、分散ＯＴアプリケーションに関して、サーバ－クライアント方式のＦＭＩ機能の一部として、
・ＳＳＰ機能に埋め込まれた「プロキシＦＭＵ」エンティティ及び
・分散ＯＴアプリケーションで実行される対応する「被制御ＦＭＵ」エンティティ
を有する「Remote Procedure Call ＜ＲＰＣ＞」技術ベースのプロキシＦＭＵ機能を実行し、（３）オートメーションデータの割り当てルールに従って、シミュレーションのモデルコンポーネントの展開の結果として、分散ＯＴアプリケーションにオートメーションデータを展開する。
・ＳＳＰ機能に埋め込まれた「プロキシＦＭＵ」エンティティ及び
・分散ＯＴアプリケーションで実行される対応する「被制御ＦＭＵ」エンティティ
を有する「Remote Procedure Call ＜ＲＰＣ＞」技術ベースのプロキシＦＭＵ機能を実行し、（３）オートメーションデータの割り当てルールに従って、シミュレーションのモデルコンポーネントの展開の結果として、分散ＯＴアプリケーションにオートメーションデータを展開する。
【0011】
使用される機能の概要：
・エッジインフラストラクチャにおいて分散デジタルツインを実行するためのランタイム
・分散シミュレーション及び分析のための抽象化レイヤ
・フィールドデバイス及びフィールドデータの抽象化レイヤへの組み込み
・ＯＴインフラストラクチャ及びオートメーションシステムにおける「Operational-Technology ＜ＯＴ＞」アスペクトに対する連成シミュレーション環境の組み合せ
・リモートシミュレーションコンポーネントでもアクセス可能な「Functional Mock-up Unit ＜ＦＭＵ＞」と組み合わせた標準「Functional Mock-up Interface ＜ＦＭＩ＞」（参照：https://fmi-standard.org）のモッキング
・ＯＴインフラストラクチャにおけるシミュレーションコンポーネントの自動生成及び配置
・エッジインフラストラクチャにおいて分散デジタルツインを実行するためのランタイム
・分散シミュレーション及び分析のための抽象化レイヤ
・フィールドデバイス及びフィールドデータの抽象化レイヤへの組み込み
・ＯＴインフラストラクチャ及びオートメーションシステムにおける「Operational-Technology ＜ＯＴ＞」アスペクトに対する連成シミュレーション環境の組み合せ
・リモートシミュレーションコンポーネントでもアクセス可能な「Functional Mock-up Unit ＜ＦＭＵ＞」と組み合わせた標準「Functional Mock-up Interface ＜ＦＭＩ＞」（参照：https://fmi-standard.org）のモッキング
・ＯＴインフラストラクチャにおけるシミュレーションコンポーネントの自動生成及び配置
【0012】
デジタルエンタープライズ（Digital Enterprise）の機能、ツール、アーチファクト、及びエレメントの組み合せは、デジタルツインランタイム環境のための分散抽象化レイヤを使用することによって活用される。
【0013】
このアプリケーションにより、ＯＴエッジは、エッジデバイスに展開可能な標準化シミュレーションオブジェクトを相互接続することができ、そして、ベンダーからのインテリジェントベンダーアグノスティックオーケストレーションマスターアルゴリズム（図１、図３、及び図４参照）を介してそれらを調和させることができる。
【0014】
これらの図は、リモート機器にあるＦＭＵへのＦＭＵ呼び出し（call）を実行して処理する方式の概念を示している。
【0015】
以下の概念の説明に関し、「ｍｙＦｍｕ」と呼ばれるＦＭＵの形態のシミュレーションがあると仮定する。
【0016】
サーバ上のパラメータ化プロキシＦＭＵ
本概念は、リモートＦＭＵに対してプロキシとして機能する汎用ＦＭＵをもつことである。このプロキシもＦＭＵであるから、ＦＭＩ規格で規定されている全ての関数（functions）を実行する必要がある。このＦＭＵは、たとえその関数において実際のシミュレーションを実行せず、リモートＦＭＵへＲＰＣ呼び出し（call）のみを実行するものであっても、総合的に汎用である。したがって、このプロキシは、他のＦＭＵに対するリモートコントローラと考えることができる。
本概念は、リモートＦＭＵに対してプロキシとして機能する汎用ＦＭＵをもつことである。このプロキシもＦＭＵであるから、ＦＭＩ規格で規定されている全ての関数（functions）を実行する必要がある。このＦＭＵは、たとえその関数において実際のシミュレーションを実行せず、リモートＦＭＵへＲＰＣ呼び出し（call）のみを実行するものであっても、総合的に汎用である。したがって、このプロキシは、他のＦＭＵに対するリモートコントローラと考えることができる。
【0017】
当該プロキシＦＭＵ特有のインスタンスをなすのは基本的に２つのこと：
・リモート制御される（被リモート制御）実際のシミュレーションＦＭＵ
・リモート制御される（被リモート制御）ＦＭＵに到達するためのＵＲＩ
・リモート制御される（被リモート制御）実際のシミュレーションＦＭＵ
・リモート制御される（被リモート制御）ＦＭＵに到達するためのＵＲＩ
【0018】
したがって、「ｍｙＦｍｕ」及びエンプティの汎用プロキシＦＭＵ「proxyＦｍｕ」を仮定すると、「ｍｙＦｍｕ」に対する特定のプロキシＦＭＵインスタンスは以下のように生成され得る：
１． 適切なmodelDescription.xmlの作成：本概念は、生成されるプロキシＦＭＵが、「ｍｙＦｍｕ」と全く同じ入出力情報を有するということである。このことは、オリジナルのＦＭＵからまったく同じ「modelDescription.xml」ファイルをコピーするだけで非常に簡単に達成できる。このファイルに対する他の変更は必要ない。
２． 「proxyＭｙＦｍｕ」の作成：ＦＭＵは単なるＺＩＰアーカイブであるため、先に生成された「modelDescription.xml」ファイルを追加してある「proxyＦｍｕ」に基づいて新しいものを作成できる。さらに、ＺＩＰアーカイブに必要なその他のファイルを追加することができる。具体的に、それを利用して、被リモート制御ＦＭＵが存在する場所（すなわち、そのリモートホスト名）や、対応するＦＭＵリモートコントローラが問い合わせするポートなどの情報を含んでいるプロキシＦＭＵのリソースフォルダに、設定ファイルを追加することができる。
１． 適切なmodelDescription.xmlの作成：本概念は、生成されるプロキシＦＭＵが、「ｍｙＦｍｕ」と全く同じ入出力情報を有するということである。このことは、オリジナルのＦＭＵからまったく同じ「modelDescription.xml」ファイルをコピーするだけで非常に簡単に達成できる。このファイルに対する他の変更は必要ない。
２． 「proxyＭｙＦｍｕ」の作成：ＦＭＵは単なるＺＩＰアーカイブであるため、先に生成された「modelDescription.xml」ファイルを追加してある「proxyＦｍｕ」に基づいて新しいものを作成できる。さらに、ＺＩＰアーカイブに必要なその他のファイルを追加することができる。具体的に、それを利用して、被リモート制御ＦＭＵが存在する場所（すなわち、そのリモートホスト名）や、対応するＦＭＵリモートコントローラが問い合わせするポートなどの情報を含んでいるプロキシＦＭＵのリソースフォルダに、設定ファイルを追加することができる。
【0019】
このときに、「proxyＭｙＦｍｕ」と呼ばれる有効なＦＭＵがあり、これは、ＦＭＵベースのシミュレーションツール／ライブラリにおいてシミュレーションをオーケストレーションする他のものと同様に使用することができる。
【0020】
「proxyＦｍｕ」の実行は、すべてが基本的に次のとおりなので総合的に汎用であり得る：
１． ＲＰＣクライアントとして機能し、インスタンス化時に、「Uniform Resource Identifier ＜ＵＲＩ＞」によって与えられる、よく知られた「Remote Procedure Call ＜ＲＰＣ＞」技術（２０２１年７月２３日版のhttps://en.wikipedia.org/wiki/Remote_procedure_call参照）のリモートＲＰＣサーバに接続する。前述のように、このＵＲＩは、これを含んでいる専用ファイルから取得される。
２． ＦＭＩ規格で指定されているすべての関数を実行するが、これら関数の実行で実際に何かを行う代わりに、単に関数引数をシリアライズし、対応するＲＰＣ呼び出しをそのＲＰＣサーバに行う。
１． ＲＰＣクライアントとして機能し、インスタンス化時に、「Uniform Resource Identifier ＜ＵＲＩ＞」によって与えられる、よく知られた「Remote Procedure Call ＜ＲＰＣ＞」技術（２０２１年７月２３日版のhttps://en.wikipedia.org/wiki/Remote_procedure_call参照）のリモートＲＰＣサーバに接続する。前述のように、このＵＲＩは、これを含んでいる専用ファイルから取得される。
２． ＦＭＩ規格で指定されているすべての関数を実行するが、これら関数の実行で実際に何かを行う代わりに、単に関数引数をシリアライズし、対応するＲＰＣ呼び出しをそのＲＰＣサーバに行う。
【0021】
デバイス（クライアント）における被リモート制御ＦＭＵ
クライアント側は、「proxyＭｙＦｍｕ」のような「proxyＦｍｕ」から来るＲＰＣ呼び出しを受け入れる役割をもつ汎用ＲＰＣサーバパートで構成される。行われるのは次のとおり：
１． 関数引数をデシリアライズする。
２． 実際のＦＭＵ（これはＦＭＩ規格で指定されている関数を実行するライブラリに過ぎない）の対応する関数を呼び出す。このライブラリを抽出してランタイムで動的にロードできるように実際のＦＭＵが何であるかを知っておく必要がある。したがって、この情報は理想的には展開ステップからもらうべきであり、例えば、対応する「Ｄｏｃｋｅｒ」コンテナ（２０２１年７月７日版のhttps://en.wikipedia.org/wiki/Docker_(software) 参照）を開始するときに引数として与えられ得る。
３． 関数呼び出しの結果は、次に最終的に、ＲＰＣリクエストに対する応答として返される。
４． ＦＭＵのそれぞれは入出力の定義セットをもっており、それぞれ「modelDescription.xml」ファイルにおいて名前及び値型（例えば、整数、浮動小数点数、ブール値、文字列）で与えられる。個々のこのようなＦＭＵから構築される分散シミュレーションをオーケストレーションすることは（どこで又はどのエッジデバイスで個々のＦＭＵが実行されているかにかかわらず）、そのような入力及び出力を接続することを伴う。典型的には、前述のモジュール式プラントは、フィールドバスによって利用可能にされるフィールドデバイスから来るデータを含み、このようなデータは、自然な形で関連するシミュレーションの一部であるべきであり、言い換えれば、入力としてシミュレーションモデルに入ることになる。結果として、通常、他のＦＭＵの出力に由来するＦＭＵ入力だけではなく、フィールドデバイスからの（信号）データとして直接的に入ってくるものもある。これは、分散シミュレーション全体がオーケストレーションされているときにも設定される必要があるものである。正確には、ＦＭＵ入出力をマップする必要があるだけでなく、オートメーションデータ名を対応するＦＭＵ入力にマップする必要もある。前者の種類のマッピング、すなわち入出力マッピングは、「System Structure & Parameterization ＜ＳＳＰ＞」（https://ssp-standard.org参照）と呼ばれる規格によって適切に記述することができるが、オートメーションデータのマッピングにはこのような規格がない。ここで次のとおり提案する：
・展開プロセスにおいて、データマッピングが生成され、被リモート制御ＦＭＵの中に入れられる。ＳＳＰトポロジファイル内の情報は、どのフィールド信号がＦＭＵによって求められるかを定義することができる。これにより、多くの場合、プロセスを自動化できる。これも、ＺＩＰアーカイブの中に入れられる「ＹＡＭＬ」（２０２１年６月２３日版のhttps://en.wikipedia.org/wiki/YAML参照）のような簡単な設定ファイルにすることができる。
・リモート制御サービスは、この信号マッピングを読み取り、設定されたデータ名を定期的に読みに行き、必要に応じて実際のＦＭＵ関数呼び出しに値を渡す。新しい値が入ってくると直ちに記憶する場合、常に最新の値をＦＭＵ関数に渡すことが保証され、単純なサブスクリプションモデルで十分である。
クライアント側は、「proxyＭｙＦｍｕ」のような「proxyＦｍｕ」から来るＲＰＣ呼び出しを受け入れる役割をもつ汎用ＲＰＣサーバパートで構成される。行われるのは次のとおり：
１． 関数引数をデシリアライズする。
２． 実際のＦＭＵ（これはＦＭＩ規格で指定されている関数を実行するライブラリに過ぎない）の対応する関数を呼び出す。このライブラリを抽出してランタイムで動的にロードできるように実際のＦＭＵが何であるかを知っておく必要がある。したがって、この情報は理想的には展開ステップからもらうべきであり、例えば、対応する「Ｄｏｃｋｅｒ」コンテナ（２０２１年７月７日版のhttps://en.wikipedia.org/wiki/Docker_(software) 参照）を開始するときに引数として与えられ得る。
３． 関数呼び出しの結果は、次に最終的に、ＲＰＣリクエストに対する応答として返される。
４． ＦＭＵのそれぞれは入出力の定義セットをもっており、それぞれ「modelDescription.xml」ファイルにおいて名前及び値型（例えば、整数、浮動小数点数、ブール値、文字列）で与えられる。個々のこのようなＦＭＵから構築される分散シミュレーションをオーケストレーションすることは（どこで又はどのエッジデバイスで個々のＦＭＵが実行されているかにかかわらず）、そのような入力及び出力を接続することを伴う。典型的には、前述のモジュール式プラントは、フィールドバスによって利用可能にされるフィールドデバイスから来るデータを含み、このようなデータは、自然な形で関連するシミュレーションの一部であるべきであり、言い換えれば、入力としてシミュレーションモデルに入ることになる。結果として、通常、他のＦＭＵの出力に由来するＦＭＵ入力だけではなく、フィールドデバイスからの（信号）データとして直接的に入ってくるものもある。これは、分散シミュレーション全体がオーケストレーションされているときにも設定される必要があるものである。正確には、ＦＭＵ入出力をマップする必要があるだけでなく、オートメーションデータ名を対応するＦＭＵ入力にマップする必要もある。前者の種類のマッピング、すなわち入出力マッピングは、「System Structure & Parameterization ＜ＳＳＰ＞」（https://ssp-standard.org参照）と呼ばれる規格によって適切に記述することができるが、オートメーションデータのマッピングにはこのような規格がない。ここで次のとおり提案する：
・展開プロセスにおいて、データマッピングが生成され、被リモート制御ＦＭＵの中に入れられる。ＳＳＰトポロジファイル内の情報は、どのフィールド信号がＦＭＵによって求められるかを定義することができる。これにより、多くの場合、プロセスを自動化できる。これも、ＺＩＰアーカイブの中に入れられる「ＹＡＭＬ」（２０２１年６月２３日版のhttps://en.wikipedia.org/wiki/YAML参照）のような簡単な設定ファイルにすることができる。
・リモート制御サービスは、この信号マッピングを読み取り、設定されたデータ名を定期的に読みに行き、必要に応じて実際のＦＭＵ関数呼び出しに値を渡す。新しい値が入ってくると直ちに記憶する場合、常に最新の値をＦＭＵ関数に渡すことが保証され、単純なサブスクリプションモデルで十分である。
【0022】
サーバパートと同様に、ここで説明するサービス（「fmuRemoteController」と呼ぶ）もまた総合的に汎用である。このサービスの実際のインスタンスは、ＦＭＵライブラリがその関数を呼び出せる場所を知るだけで済む（参照：図３はＲＰＣ呼び出しのシーケンスを示している）。
【0023】
開示するオーケストレーションシステムは、モジュール式プラントのフィールドデータへアクセスできる分散ＯＴデジタルツインランタイムのエッジデバイスへの展開を可能にする。
【0024】
既知のアプリケーションは、深い依存性があり、手動拡張が多く、異なるアプリケーションに適応することが困難である。
【0025】
提案する概念は、これらの側面をすべて抽象化し、シミュレーション及び分析モデルサプライヤが、その依存フットプリントを低減するEdge Ecosystemの一部として自身のＯＴシステムを展開することを可能にする。
【0026】
１． 実際のＲＰＣ技術は、それほど交換が困難ではない。適合させる必要があるパートは、「proxyＦｍｕ」及び「fmuRemoteController」のみである。
２．「proxyＭｙＦｍｕ」のようなインスタンスは、単なる普通のＦＭＵである。これらは、シミュレーションツールの観点と異なることはしない。これらは、他のものと同様にオーケストレーションされ、実行可能であり、リモート呼び出しパートは、その中に全面的に隠される。
３． どのようなシミュレーションツールであっても、又は「Ａｍｅｓｉｍ」、「Ｓｉｍｕｌｉｎｋ」、「ｆｍｐｙ」、「ｌｉｂｃｏｓｉｍ」のようなライブラリでも、使用できる。
４． リモートＦＭＩ／ＦＭＵが自動的に生成される。
５． ＦＭＩ／ＦＭＵは、対応する（フィールド変数に応じる）ＯＴシステムに自動的に展開される。
６． ＳＳＰ規格がＯＴ信号の接続に使用される。
２．「proxyＭｙＦｍｕ」のようなインスタンスは、単なる普通のＦＭＵである。これらは、シミュレーションツールの観点と異なることはしない。これらは、他のものと同様にオーケストレーションされ、実行可能であり、リモート呼び出しパートは、その中に全面的に隠される。
３． どのようなシミュレーションツールであっても、又は「Ａｍｅｓｉｍ」、「Ｓｉｍｕｌｉｎｋ」、「ｆｍｐｙ」、「ｌｉｂｃｏｓｉｍ」のようなライブラリでも、使用できる。
４． リモートＦＭＩ／ＦＭＵが自動的に生成される。
５． ＦＭＩ／ＦＭＵは、対応する（フィールド変数に応じる）ＯＴシステムに自動的に展開される。
６． ＳＳＰ規格がＯＴ信号の接続に使用される。
【0027】
本発明のさらなる有利な発展形態が独立形式請求項によって与えられる。
【0028】
【図面の簡単な説明】
【0029】
【図1】モジュール式プラントのモデルベースシミュレーションの構成をオーケストレーションするシナリオ。
【図2】コンピュータ実行ツール、具体的には例えばＡＰＰとして設計されたコンピュータプログラム製品の原理的な表現。
【図3】サーバ－クライアント方式で「Remote Procedure Call ＜ＲＰＣ＞」技術ベースのＰｒｏｘｙ－ＦＭＵ－機能を実行することにより、シミュレートされたモデルコンポーネントを展開する、メッセージフロー図の例示。
【発明を実施するための形態】
【0030】
図１は、モジュール式構造Ｐｍを有するプラントのモデルベースシミュレーションの構成をオーケストレーションするサーバ－クライアントベースのシナリオを示している。モジュール式構造Ｐｍを有するプラントは、モジュール式プラントと見なすことができる、一例として示す３つのプラントモジュール、第１のプラントモジュールＰＭ１、第２のプラントモジュールＰＭ２、及び第３のプラントモジュールＰＭ３を含む。モジュール式プラントＰＭ１、ＰＭ２、ＰＭ３は、例外なく同じプラント構成を有する。
【0031】
第１のモジュール式プラントＰＭ１に属している第１のプラントモジュール制御システムＣＳ１は、一方で第１のデジタルツインモデルＤＴＭ１に、他方でロボットとして図１に示してある自動機器又はプロセスに、接続される又は割り当てられる。第１のプラントモジュール制御システムＣＳ１には、一般的によく知られた、第１の「Programmable Logic Controller ＜ＰＬＣ＞」ユニットＰＬＣＵ１が属し、これが第１のエッジデバイスＥＤ１を含む第１のフィールドデバイスＦＤ１と接続されている。第１のエッジデバイスＥＤ１は、本発明の好適な実施形態において、分散ＯＴアプリケーションＯＴＡｄであり、これに関して、本発明の目的に従って、そして、オーケストレーションする過程において、モデルベースシミュレーションの構成が自動的に生成され、展開される。
【0032】
同じ構成で、第２のモジュール式プラントＰＭ２と第３のモジュール式プラントＰＭ３がある。
【0033】
第２のモジュール式プラントＰＭ２に属している第２のプラントモジュール制御システムＣＳ２は、この場合も、一方で第２のデジタルツインモデルＤＴＭ２に、他方でロボットとして図１に示してある自動機器又はプロセスに、接続される又は割り当てられる。第２のプラントモジュール制御システムＣＳ２には、この場合も、第２の「Programmable Logic Controller ＜ＰＬＣ＞」ユニットＰＬＣＵ２が属し、これが第２のエッジデバイスＥＤ２を含む第２のフィールドデバイスＦＤ２と接続されている。第２のエッジデバイスＥＤ２は、本発明の好適な実施形態において、分散ＯＴアプリケーションＯＴＡｄであり、これに関して、本発明の目的に従って、そして、オーケストレーションする過程において、モデルベースシミュレーションの構成が自動的に生成され、展開される。
【0034】
第３のモジュール式プラントＰＭ３に属している第３のプラントモジュール制御システムＣＳ３は、この場合も、一方で第３のデジタルツインモデルＤＴＭ３に、他方でロボットとして図１に示してある自動機器又はプロセスに、接続される又は割り当てられる。第３のプラントモジュール制御システムＣＳ３には、この場合も、第３の「Programmable Logic Controller ＜ＰＬＣ＞」ユニットＰＬＣＵ３が属し、これが第３のエッジデバイスＥＤ３を含む第３のフィールドデバイスＦＤ３と接続されている。第３のエッジデバイスＥＤ３は、本発明の好適な実施形態において、分散ＯＴアプリケーションＯＴＡｄであり、これに関して、本発明の目的に従って、そして、オーケストレーションする過程において、モデルベースシミュレーションの構成が自動的に生成され、展開される。
【0035】
図１によれば、オーケストレーションは、オーケストレーションシステムＯＳによって実行され、オーケストレーションシステムＯＳは、例えば、好ましい最も単純な設計では、ＳＳＰ機能、ＦＭＩ／ＦＭＵ機能を含むように、モジュール式プラントＰＭ１、ＰＭ２、ＰＭ３のデジタルツインモデルＤＴＭ１、ＤＴＭ２、ＤＴＭ３に基づいてシミュレーションの構成をオーケストレーションするように、拡張されたシミュレータであり、モデルベースのシミュレーションを構成するべくサーバコントローラＳＣＲＴを含む。
【0036】
図示の「サーバ－クライアント」ベースのシナリオによれば、オーケストレーションシステムＯＳのサーバ－コントローラＳＣＲＴが「サーバ」であり、モジュール式プラントＰＭ１、ＰＭ２、ＰＭ３のエッジデバイスＥＤ１、ＥＤ２、ＥＤ３が「クライアント」である。
【0037】
オーケストレーションの過程において、サーバコントローラＳＣＲＴは、展開ツールＤＴの一部として、よく知られた（https://ssp-standard.org参照）ロジカル「System Structure and Parameterization ＜ＳＳＰ＞」ツール（tool）ＳＳＰ－Ｔを含み、どのようにシミュレーションのためのモデルコンポーネントが接続されて複合コンポーネントへの展開のために構成されるか、そして、どのようにモデルパラメータ化データがそれぞれのモデルコンポーネントと複合コンポーネントとの間で記憶され交換されるか、を論理的に記述する。ロジカル「System Structure and Parameterization ＜ＳＳＰ＞」ツールＳＳＰ－Ｔは、「ＺＩＰアーカイブ」ベースの「Functional Mock-up Unit ＜ＦＭＵ＞」ツール、ＦＭＵ－ＴパッキングＸＭＬファイル、及びコンパイルされたＣコードを介してシミュレーションを共有するための「Functional Mock-up Interface ＜ＦＭＩ＞」ツールＦＭＩ－Ｔ（https://fmi-standard.org参照）からなるか又はこれを含む。
【0038】
さらに、オーケストレーションの過程において、サーバコントローラＳＣＲＴは、生成ユニットＧＵを含む。生成ユニットＧＵは、モジュール式プラントＰＭ１、ＰＭ２、ＰＭ３のディジタルツインモデルＤＴＭ１、ＤＴＭ２、ＤＴＭ３に基づいて、モジュール式プラントＰＭ１、ＰＭ２、ＰＭ３のエッジデバイスＥＤ１、ＥＤ２、ＥＤ３のそれぞれに分散されたＯＴアプリケーションＯＴＡｄに対して、モジュール式プラントＰＭ１、ＰＭ２、ＰＭ３のオートメーションのためにそれぞれキャプチャされたシミュレーションのモデルコンポーネント、（１）第１のエッジデバイスＥＤ１のための少なくとも１つの第１のシミュレーションのモデルコンポーネントＭＣｓ，１、（２）第２のエッジデバイスＥＤ２のための少なくとも１つの第２のシミュレーションのモデルコンポーネントＭＣｓ，２、及び（３）第３のエッジデバイスＥＤ３のための少なくとも１つの第３のシミュレーションのモデルコンポーネントＭＣｓ，３、を生成ｇｒｔする。
【0039】
この目的のために、第１のシミュレーションのモデルコンポーネントＭＣｓ，１は、第１のエッジデバイスＥＤ１に割り当てられる第１のオートメーションデータＡＤ１に対する第１の割り当てルールＡＲ１を含み、第２のシミュレーションのモデルコンポーネントＭＣｓ，２は、第２のエッジデバイスＥＤ２に割り当てられる第２のオートメーションデータＡＤ２に対する第２の割り当てルールＡＲ２を含み、第３のシミュレーションのモデルコンポーネントＭＣｓ，３は、第３のエッジデバイスＥＤ３に割り当てられる第３のオートメーションデータＡＤ３に対する第３の割り当てルールＡＲ３を含む。
【0040】
これらの生成された情報ＭＣｓ，１、ＭＣｓ，２、ＭＣｓ，３、ＡＲ１、ＡＲ２、ＡＲ３、ＡＤ１、ＡＤ２、ＡＤ３は、モジュール式プラントＰＭ１、ＰＭ２、ＰＭ３のエッジデバイスＥＤ１、ＥＤ２、ＥＤ３のそれぞれに分散されたＯＴアプリケーションＯＴＡｄに情報を展開するために、サーバコントローラＳＣＲＴ内で展開ツールＤＴに転送される。
【0041】
この目的のために、サーバコントローラＳＣＲＴの展開ツールＤＴは、エッジデバイスＥＤ１、ＥＤ２、ＥＤ３のそれぞれに分散されたＯＴアプリケーションＯＴＡｄにシミュレーションのモデルコンポーネントＭＣｓ，１、ＭＣｓ，２、ＭＣｓ，３を展開ｄｐｌする。この展開に、
・ＦＭＩ機能ＦＭＩ－Ｔの一部として「Functional Mock-up Unit ＜ＦＭＵ＞」機能をもつＳＳＰ機能ＳＳＰ－Ｔ、（１）第１のエッジデバイスＥＤ１に対する第１の「Functional Mock-up Unit ＜ＦＭＵ＞」機能ＦＭＵ－Ｔ１、（２）第２のエッジデバイスＥＤ２に対する第２の「Functional Mock-up Unit ＜ＦＭＵ＞」機能ＦＭＵ－Ｔ２、及び（３）第１のエッジデバイスＥＤ３に対する第３の「Functional Mock-up Unit ＜ＦＭＵ＞」機能ＦＭＵ－Ｔ３、を使用し、
・エッジデバイスＥＤ１、ＥＤ２、ＥＤ３のそれぞれに分散されたＯＴアプリケーションＯＴＡｄに関し、クライアント－サーバ方式のＦＭＩ機能ＦＭＩ－Ｔの一部として、よく知られた「Remote Procedure Call ＜ＲＰＣ＞」技術（２０２１年７月２３日版のhttps://en.wikipedia.org/wiki/Remote_procedure_call参照）に基づいて、プロキシＦＭＵ機能、（１）サーバコントローラＳＣＲＴのＳＳＰ機能ＳＳＰ－Ｔに埋め込まれた第１の「プロキシＦＭＵ」エンティティＰＦＭＵ－Ｅ１をもつ第１のプロキシＦＭＵ機能ＰＦＭＵ－Ｔ１と、第１のエッジデバイスＥＤ１に割り当てられ展開されるべき第１のオートメーションデータＡＤ１を含む第１のエッジデバイスＥＤ１の第１のクライアントコントローラＣＣＲＴ１において実行される対応する第１の「被リモート制御ＦＭＵ」エンティティＲＣＦＭＵ－Ｅ１、（２）サーバコントローラＳＣＲＴのＳＳＰ機能ＳＳＰ－Ｔに埋め込まれた第２の「プロキシＦＭＵ」エンティティＰＦＭＵ－Ｅ２をもつ第２のプロキシＦＭＵ機能ＰＦＭＵ－Ｔ２と、第２のエッジデバイスＥＤ２に割り当てられ展開されるべき第２のオートメーションデータＡＤ２を含む第２のエッジデバイスＥＤ２の第２のクライアントコントローラＣＣＲＴ２において実行される対応する第２の「被リモート制御ＦＭＵ」エンティティＲＣＦＭＵ－Ｅ２、（３）サーバコントローラＳＣＲＴのＳＳＰ機能ＳＳＰ－Ｔに埋め込まれた第３の「プロキシＦＭＵ」エンティティＰＦＭＵ－Ｅ３をもつ第３のプロキシＦＭＵ機能ＰＦＭＵ－Ｔ３と、第３のエッジデバイスＥＤ３に割り当てられ展開されるべき第３のオートメーションデータＡＤ３を含む第３のエッジデバイスＥＤ３の第３のクライアントコントローラＣＣＲＴ３において実行される対応する第３の「被リモート制御ＦＭＵ」エンティティＲＣＦＭＵ－Ｅ３、を実行する。
・ＦＭＩ機能ＦＭＩ－Ｔの一部として「Functional Mock-up Unit ＜ＦＭＵ＞」機能をもつＳＳＰ機能ＳＳＰ－Ｔ、（１）第１のエッジデバイスＥＤ１に対する第１の「Functional Mock-up Unit ＜ＦＭＵ＞」機能ＦＭＵ－Ｔ１、（２）第２のエッジデバイスＥＤ２に対する第２の「Functional Mock-up Unit ＜ＦＭＵ＞」機能ＦＭＵ－Ｔ２、及び（３）第１のエッジデバイスＥＤ３に対する第３の「Functional Mock-up Unit ＜ＦＭＵ＞」機能ＦＭＵ－Ｔ３、を使用し、
・エッジデバイスＥＤ１、ＥＤ２、ＥＤ３のそれぞれに分散されたＯＴアプリケーションＯＴＡｄに関し、クライアント－サーバ方式のＦＭＩ機能ＦＭＩ－Ｔの一部として、よく知られた「Remote Procedure Call ＜ＲＰＣ＞」技術（２０２１年７月２３日版のhttps://en.wikipedia.org/wiki/Remote_procedure_call参照）に基づいて、プロキシＦＭＵ機能、（１）サーバコントローラＳＣＲＴのＳＳＰ機能ＳＳＰ－Ｔに埋め込まれた第１の「プロキシＦＭＵ」エンティティＰＦＭＵ－Ｅ１をもつ第１のプロキシＦＭＵ機能ＰＦＭＵ－Ｔ１と、第１のエッジデバイスＥＤ１に割り当てられ展開されるべき第１のオートメーションデータＡＤ１を含む第１のエッジデバイスＥＤ１の第１のクライアントコントローラＣＣＲＴ１において実行される対応する第１の「被リモート制御ＦＭＵ」エンティティＲＣＦＭＵ－Ｅ１、（２）サーバコントローラＳＣＲＴのＳＳＰ機能ＳＳＰ－Ｔに埋め込まれた第２の「プロキシＦＭＵ」エンティティＰＦＭＵ－Ｅ２をもつ第２のプロキシＦＭＵ機能ＰＦＭＵ－Ｔ２と、第２のエッジデバイスＥＤ２に割り当てられ展開されるべき第２のオートメーションデータＡＤ２を含む第２のエッジデバイスＥＤ２の第２のクライアントコントローラＣＣＲＴ２において実行される対応する第２の「被リモート制御ＦＭＵ」エンティティＲＣＦＭＵ－Ｅ２、（３）サーバコントローラＳＣＲＴのＳＳＰ機能ＳＳＰ－Ｔに埋め込まれた第３の「プロキシＦＭＵ」エンティティＰＦＭＵ－Ｅ３をもつ第３のプロキシＦＭＵ機能ＰＦＭＵ－Ｔ３と、第３のエッジデバイスＥＤ３に割り当てられ展開されるべき第３のオートメーションデータＡＤ３を含む第３のエッジデバイスＥＤ３の第３のクライアントコントローラＣＣＲＴ３において実行される対応する第３の「被リモート制御ＦＭＵ」エンティティＲＣＦＭＵ－Ｅ３、を実行する。
【0042】
さらに、展開ツールＤＴは、オートメーションデータＡＤ１、ＡＤ２、ＡＤ３が、オートメーションデータＡＤ１、ＡＤ２、ＡＤ３の割り当てルールＡＲ１、ＡＲ２、ＡＲ３に従って、シミュレーションのモデルコンポーネントＭＣｓ，１、ＭＣｓ，２、ＭＣｓ，３の展開ｄｐｌの結果として、エッジデバイスＥＤ１、ＥＤ２、ＥＤ３のそれぞれに分散されたＯＴアプリケーションＯＴＡｄに展開ｄｐｌされるように、設計されている。
【0043】
さらに、オーケストレーションシステムＯＳは、ハードウェアソリューションとして設計可能であるし、又は、オーケストレーションシステムＯＳがコンピュータ実行ツールＣＩＴであるようなソフトウェアソリューションとして実現可能であり、これは、好ましくはＡＰＰとして設計されるコンピュータプログラム（製品）に他ならず、サーバコントローラＳＣＲＴにアップロード可能である。
【0044】
図２は、ツールがどのように設計され得るかを、コンピュータ実行ツールＣＩＴの原理図で示す。図示によれば、コンピュータ実行ツールＣＩＴは、非一時的プロセッサ可読記憶媒体ＳＴＭに記憶されたサイバーフィジカルシステム（ＣＰＳ）の操作を特定するためにプログラムモジュールＰＧＭのプロセッサ可読プログラム命令を入れた非一時的プロセッサ可読記憶媒体ＳＴＭと、この記憶媒体ＳＴＭに接続され、プログラムモジュールＰＧＭのプロセッサ可読プログラム命令を実行してサイバーフィジカルシステムの操作を特定するプロセッサＰＲＣと、を含む。
【0045】
図３は、図１から始まり、対応する図１の説明に基づいて、サーバ－クライアント方式で「Remote Procedure Call ＜ＲＰＣ＞」技術ベースのプロキシＦＭＵ機能を実行することによりシミュレーションのモデルコンポーネントを展開するメッセージフロー図を例示する。
【0046】
図４は、図１から始まり、対応する図１の説明に基づいて、図１に示される「サーバ－クライアント」ベースのシナリオの関連するユニット間のオーケストレーションフローを例示する。オーケストレーションを担当するオーケストレーションエンティティを含むサーバコントローラＳＣＲＴと、クライアントの管理を担当する管理クライアントエンティティとの間でオーケストレーションフローは、ＴＣＰ／ＩＰベースである（２０２１年７月２５日版のhttps://en.wikipedia.org/wiki/Internet_Protocol参照）。
【図1A】
【図1B】
【図1C】
【図2】
【図3】
【図4】
【国際調査報告】