特表 2024-523388 分散自動化システムにおける機能コントローラを接続するための方法および装置

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-06-28

(54)【発明の名称】分散自動化システムにおける機能コントローラを接続するための方法および装置

(51)【国際特許分類】

   G05B 19/042 20060101AFI20240621BHJP

【ＦＩ】

G05B19/042

【審査請求】有

【予備審査請求】有

(21)【出願番号】P 2023577819

(86)(22)【出願日】2021-06-18

(85)【翻訳文提出日】2024-02-13

(86)【国際出願番号】 EP2021066593

(87)【国際公開番号】W WO2022262993

(87)【国際公開日】2022-12-22

(81)【指定国・地域】

(71)【出願人】

【識別番号】390039413

【氏名又は名称】シーメンス アクチエンゲゼルシヤフト

【氏名又は名称原語表記】Ｓｉｅｍｅｎｓ Ａｋｔｉｅｎｇｅｓｅｌｌｓｃｈａｆｔ

(74)【代理人】

【識別番号】110003317

【氏名又は名称】弁理士法人山口・竹本知的財産事務所

(74)【代理人】

【識別番号】100075166

【弁理士】

【氏名又は名称】山口 巖

(74)【代理人】

【識別番号】100133167

【弁理士】

【氏名又は名称】山本 浩

(74)【代理人】

【識別番号】100169627

【弁理士】

【氏名又は名称】竹本 美奈

(72)【発明者】

【氏名】ブルーメンシュタイン，ミシェル

(72)【発明者】

【氏名】マウルマイヤー，マティアス

(72)【発明者】

【氏名】シュタッツ，アンドレアス

【テーマコード（参考）】

5H220

【Ｆターム（参考）】

5H220AA01

5H220CC06

5H220CX01

5H220FF09

5H220JJ12

5H220JJ16

(57)【要約】

分散自動化システムにて機能制御を接続するための方法および装置。今日の自動化システムでは、機能的な実装と、その物理的なプロセスとの接続との間に密結合が存在する。この結合は、特に、分散周辺機器の統合の選択肢が、個々のハードウェア固有の信号の統合に限定されることを特徴とする。コンポーネントに基づきまた機能をカプセル化するシステムアーキテクチャが提案され、当該システムアーキテクチャは、フィールドのますますインテリジェントなデバイスを機能コンポーネントとして関連付けることにより、現在の課題を解決する。

【特許請求の範囲】

【請求項1】

少なくとも１つの物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）を含む分散型の自動化システムにて、少なくとも１つの自動化機能を用いて、前記自動化システムの機能制御を前記物理的要素と接続するための方法であって、以下のステップ、すなわち、
-制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）における前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）の機能性を抽象化し、そして、前記物理的要素の実インタフェースを前もって標準化されたインタフェースにマッピングするステップ、
-前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）を、前記物理的要素と同じ標準化されたインタフェースを有するプレースホルダ（ＣＣＴ）に割り当てるステップ、
-前記少なくとも１つの自動化機能を、前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）に対する少なくとも１つのインタフェースと少なくとも１つのさらなる通信インタフェースとを有するサービスコンポーネント（ＳＣ）に、カプセル化するステップ、
-前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）と、前記サービスコンポーネント（ＳＣ）または前記プレースホルダ（ＣＣＴ）と、の間の通信を行うステップ、
を備え、
-物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）の設定が、前記自動化システムのランタイム中にいつでも、前記通信インタフェース（１００）によって、実行され得る、方法。

【請求項2】

前記物理的要素が、前記自動化システムにおけるセンサまたはアクチュエータの機能性を有することを特徴とする、
請求項１に記載の方法。

【請求項3】

前記標準化されたインタフェースが、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８規格に準拠して定義されていることを特徴とする、
請求項１または２に記載の方法。

【請求項4】

前記通信インタフェース（１００）が、ＯＰＣ ＵＡ規格に準拠して動作することを特徴とする、
請求項１～３の何れか１項に記載の方法。

【請求項5】

前記サービスコンポーネント（ＳＣ）が、上位の自動化機能のために、さらなるサービスコンポーネント（ＳＣ１）に対する少なくとも１つのインタフェースを有し、前記上位の自動化機能は前記さらなるサービスコンポーネントにカプセル化された下位の自動化機能にアクセスすることを特徴とする、
請求項１～４の何れか１項に記載の方法。

【請求項6】

物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）を含む分散型の自動化システムにて、少なくとも１つの自動化機能を用いて、前記自動化システムにおける機能制御を連結するための装置（ＣＡＭＬ）であって、
-少なくとも１つの制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）を備えており、当該制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）は、前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）の機能性の抽象化と、前記物理的要素の実インタフェースの前もって標準化されたインタフェースへのマッピングと、を有し、前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）は、前記物理的要素と同じ標準化されたインタフェースを有するプレースホルダ（ＣＣＴ）に割り当て可能であり、
-少なくとも１つのサービスコンポーネント（ＳＣ）を備えており、当該サービスコンポーネント（ＳＣ）は、前記少なくとも１つの自動化機能のカプセル化を有し、前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）に対する少なくとも１つのインタフェースと少なくとも１つのさらなる通信インタフェースとを含み、前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）と前記サービスコンポーネント（ＳＣ）との間での通信が可能であり、
-前記装置（ＣＡＭＬ）の設定が、前記自動化システムのランタイム中にいつでも、前記通信インタフェース（１００）によって、実行され得る、装置。

【請求項7】

前記物理的要素が、前記自動化システムにおけるセンサまたはアクチュエータの機能性を有することを特徴とする、
請求項６に記載の装置。

【請求項8】

前記標準化されたインタフェースが、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８規格に準拠して定義されていることを特徴とする、
請求項６または７に記載の装置。

【請求項9】

前記通信インタフェース（１００）が、ＯＰＣ ＵＡ規格に準拠して動作することを特徴とする、
請求項６～８の何れか１項に記載の装置。

【請求項10】

前記少なくとも１つの物理的要素（ＣＣ２）および関連する前記制御コンポーネント（ＳＣ１）が、同じコントローラ（１１０）に実装され（変形例１）、前記制御コンポーネントと前記コントローラコンポーネントとの間の通信が、コントローラ内部のインタフェース（１３３、１３４）を用いて行われることを特徴とする、
請求項６～９の何れか１項に記載の装置。

【請求項11】

前記少なくとも１つの物理的要素（ＣＣ１）および関連する前記制御コンポーネント（ＳＣ１）が同じコントローラ（１１０）には実装されず（変形例２）、制御コンポーネントとコントローラコンポーネントとの間の通信が、クロスコントローラインタフェースを介してプロバイダコンシューマアプローチを用いて行われることを特徴とする、
請求項６～９の何れか１項に記載の装置。

【請求項12】

前記少なくとも１つの物理的要素（ＣＣ３）および関連する前記制御コンポーネント（ＳＣ１）が同じコントローラ（１１０）には実装されず（変形例３）、制御コンポーネントとコントローラコンポーネントとの間の通信がコントローラワイドのインタフェースを介して（１３１、１３２、１３５）行われることを特徴とする、
請求項６～９の何れか１項に記載の装置。

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、分散自動化システムにおける機能コントローラを接続するための方法および装置に関する。

【背景技術】

【0002】

製品の個別化の強化、製品のライフサイクルの短期化および市場のボラティリティの上昇化の傾向は、初めは生産自動化において認められ、現在ではプロセス産業でも認められている。これらの市場開発には生産プラントのさらなる可変性が必要とされる。この可変性は、普遍性、モビリティ、スケーラビリティ、モジュール性および互換性という５つのイネーブラ特徴（英：enabling feature、独：Befaehigungsmerkmal）に依存する。
-普遍性は、製品および技術の様々な要件に合わせるためのプラントのサイジングおよび設定を示す（例えば、変形例の多様性）。
-モビリティは、物体（例えば、ローラ上の機器）について局所的に制限されることがない可動性を提供する。
-スケーラビリティにおいては、技術的、空間的および人材的な通気性（＝拡張性と縮小性）が望まれる（例えば、支配的な市場需要に従ってプラントのサイズを経済的に調整すること）。
-モジュール性に関しては、標準化された機能性の単位または要素が、作成されることになる（例えば、「プラグアンドプロデュース」モジュール）。
-最後に、互換性は材料、情報、媒体およびエネルギの相互接続性を保証する（例えば、統一ソフトウェアインタフェース）。

【0003】

これらの特徴は、生産プラントのハードウェア構成においてだけでなく、特に自動化エンジニアリングの構成においても有効である。このことは、最近の自動化システムにおける課題となる。

【0004】

最近の自動化システムにおいては、機能的な実装と、物理的なプロセスとのその接続との間に密連結が存在する。この連結は、特に、分散周辺機器を統合するための選択肢が、個々のハードウェア固有の信号の統合に限定されることを特徴とする。ここで、異なるセンサおよびアクチュエータは、同様のまたは同一のタスクを実行する場合でも、異なるインタフェースを介して制御される。この点は多くの変更イネーブラ（英：change enabler、独：Wandlungsbefaehiger）の妨げとなる。

【0005】

普遍性に関して、センサロジックおよびアクチュエータロジックの実装において変形例の多様性がほぼ実現不可能であるという問題がり、その理由は、異なる信号インタフェースに変形例の多様性が反映されるからである。同じ理由から、よりインテリジェントなフィールドデバイスまたはより高性能の技術の使用も限定されるため、スケーラビリティの変更イネーブラの妨げとなる。

【0006】

分散周辺機器と自動化システムとの間の情報フローに関しては、それに対応する信号インタフェースが一致する場合にのみ互換性がある。異なるセンサタイプおよび／またはアクチュエータタイプの違いと、それに伴う信号インタフェースの違いがある場合、互換性は保証されない。

【0007】

個々の信号に基づく自動化システムとの分散周辺機器の接続は、多数の個々の配線および追加のリモートＩ／Ｏアセンブリの使用と関係する。これにより、センサおよびアクチュエータをプラントの別の場所に単純に再接続することが制限されるため、センサおよびアクチュエータのモビリティが制限される。

【0008】

上記変更イネーブラを実装する上でプラントのモジュール性が決定的に重要である。現在多くの場合、モジュール性はプラントの物理的構造に限定されており、自動化ソフトウェアには反映されていない。

【0009】

まとめると、自動化システムとの分散周辺機器の接続は、従来は直接的にセンサおよびアクチュエータを制御する個々の信号に基づいて行われると結論付けられる。これが従来では十分であったのは、自動化ソフトウェアが、入力信号を単純な信号変換ロジックを用いて出力信号に変換することに基づいていたためである。しかし、プラントに可変性の要求があると直ちに、この概念は上記課題を呈する。

【0010】

従来技術
上記課題を解決するための既存のアプローチは、インテリジェントフィールドデバイスの使用、つまり分散インテリジェンスの使用、である。個々の小型のセンサおよびアクチュエータを制御するためのロジックは、自動化システムにではなく、直接的にフィールドに、つまり、このロジックが必要とされるところに、実装される。そのようなアプローチは、例えばエッジ環境から、知られている。このことは、自動化システムには分散周辺機器を制御するための個々の信号を処理する必要がなくなるという有利な点を有する。その代わりに、センサ、アクチュエータまたは制御ループ全体の機能性は、抽象化され、定義され、最も良くて標準化されたインタフェースを介して自動化システムに利用可能となる。

【0011】

この思想を既に現在アプローチに使用する技術がＰＲＯＦＩＢＵＳ ＰＡである。この場合、自動化システムに統合されずにフィールドで通信を実装する機能モジュールが標準化されている。その一方、ＰＲＯＦＩＢＵＳ ＰＡにおいては、依然として信号に基づく抽象化が存在する。製造産業の分野では、分散インテリジェンスの基礎はＩＯ－Ｌｉｎｋ技術に置かれている。現在、これらのアプローチの使用は、現在の統合技術がインテリジェント機器の統合された機能を部分的にのみしか考慮に入れていないかまたは全く考慮に入れていないことによって、限定されている。

【0012】

これらのフィールドバスシステムに加えて、いくつかのメーカが、フィールドでの分散インテリジェンスの実装に非常に良好なマイクロコントローラも、例えば、Ｔｕｒｃｋ社のＴＢＥＮ－Ｌ－ＰＬＣ等も、提供している。ＴＢＥＮ－Ｌ－ＰＬＣは、ＣＯＤＥＳＹＳに基づく制御コンポーネントに加えて、様々なプロトコル（例えば、ＰＲＯＦＩＮＥＴ、イーサネット、Ｍｏｄｂｕｓ等）を用いて、他のプログラマブルロジックコントローラ（ＰＬＣ）または直接的にクラウドと通信する選択肢も有している。

【0013】

最後に、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８規格に従って、プロセスプラントの全体機能の一部は、分散インテリジェンスとして、プロセス装置アセンブリ（ＰＥＡ：Ｐｒｏｃｅｓｓ Ｅｑｕｉｐｍｅｎｔ Ａｓｓｅｍｂｌｉｅｓ）と称されるモジュールにアウトソースされる。また、同様のアプローチが、生産自動化分野のスキルおよび能力に関する研究分野でも採用されている。ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８に基づくモジュール式オートメーションの概念は、今後自動化システムに分散インテリジェンスを実装して、これにより上記課題を解決する非常に優れたアプローチと考えられる。

【0014】

また、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８のアーキテクチャ概念は図５に詳細に説明されている。

【0015】

階層モデルは、下から上へと下記のように構成されている。個々のモジュールのより詳細な説明は、以下に続く：
ハードウェア設定、ＨＷＣ
入力のプロセスイメージ、ＰＡＥ |[MM(PTD1)／出力のプロセスイメージ ＰＡＡ
信号抽象化層 ＳＡＬ
サービスモジュール ＳＭ１
制御モジュール ＣＭ１、ＣＭ２、ＣＭ３
制御モジュールタイプ ＣＭＴ１、．．．

【0016】

図の例では、通信はＯＰＣ ＵＡ規格に従い行われる。

【0017】

モジュール式オートメーションの現在の概念は、プロセスエンジニアリング機能を分散インテリジェンスとして利用可能とすることに基づいている。ここで、これらの機能は、モジュール式プロセスユニットＰＥＡでのサービスの形態で実装される。

【0018】

サービスモジュールＳＭと制御モジュールＣＭ：
いわゆるサービスは、この場合、サービスモジュールＳＭと任意の数の制御モジュールＣＭからなる。サービスモジュールには、サービスの制御ロジックが、標準化された状態機械に基づいて実装されている。しかしここでは、サービスを実行するためにどのセンサおよびアクチュエータを使用するかはまだ決定されていない。その一方、制御モジュールは、センサおよび／またはアクチュエータを制御するためのロジックをカプセル化し、このようにして、サービスを物理的プロセスに接続する役割を果たす。

【0019】

完全なサービスを実装するには、サービスモジュールに対して、必要な制御モジュールを割り当てる必要がある。この割り当ては、本明細書において提示されるアーキテクチャ概念において柔軟に実装されている。この目的のために、サービスモジュールのプログラムは、センサおよびアクチュエータ用のタイプインタフェース（英：type interface、独：Typ-Schnittstelle）に対して開発されている。このプログラムは、生産プロセスと相互作用する必要がある場所に、従って制御モジュールを統合する必要がある場所に、これに対応するプレースホルダモジュール（英：placeholder module、独：Platzhalter-Baustein）を含む。これらのプレースホルダは、制御モジュールタイプＣＭＴとして実装され、プレースホルダを後から埋める制御モジュールと同じ標準化されたインタフェースを有する。その際、例えば、バルブ、モータ、センサまたは制御ループ全体用の様々なインタフェースを備える様々な制御モジュールタイプＣＭＴが利用可能である。サービスを実装するために、所望の制御モジュールＣＭのインタフェースは、プレースホルダＣＭＴのインタフェースにマッピングされる。このようにして、ＳＭには、実際に制御されるセンサおよびアクチュエータが、割り当てられる。

【0020】

しかし、この手順は、割り当てがシステムのエンジニアリング中に一度実行されると、その後は、制御プログラムの調整なしでは割り当てを調整することは最早不可能である、という不利な点を有する。

【0021】

サービスモジュールＳＭ用の設定・ランタイムインタフェースは、同様にモジュール式プロセスユニットＰＥＡに含まれるＯＰＣ ＵＡサーバにより、提供される。この設定・ランタイムインタフェースを介して、サービスモジュールＳＭの設定パラメータ及びプロシージャパラメータを設定することができ、サービスモジュールＳＭの状態機械を制御（開始、停止等）することができる。

【0022】

信号抽象化層ＳＡＬ（Signal Abstraction Layer）
生産プロセスのセンサおよびアクチュエータと制御モジュールＣＭとの間の相互作用は、従来のメカニズムに基づいている。ハードウェア設定ＨＷＣに関して、ハードウェアアドレスが定義され、当該ハードウェアアドレスのもとで、使用されるセンサおよびアクチュエータを見つけることができる。これらのアドレスの後方の現在値は、各ＰＬＣ制御サイクルの開始時に、センサ信号の場合は入力のプロセスイメージＰＡＥに、アクチュエータ信号の場合は出力のプロセスイメージＰＡＡに、記録される。ここで、ＰＡＥとＰＡＡに格納された値は、制御モジュールＣＭの制御プログラムにおいて使用され得る。その一方、これらの信号の使用を単純化するため、プログラムにおいてはハードウェアアドレスそれ自体が使用されるのではなく、ハードウェアアドレスに割り当てられているユーザ定義シンボルが使用される。ＨＷＣで定義されたハードウェアアドレスとプログラムで使用されるシンボルとの関係は、信号抽象化層ＳＡＬと称されるメカニズムを用いて実現される。

【0023】

従って、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８の意味でのモジュール式プロセスユニットＰＥＡは、標準化されたインタフェースを介して抽象化される分散インテリジェンスを提供する。このようにして、ＰＥＡレベルの上記課題は解決される。ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８の意味でのモジュール式プラントは、ＰＥＡ全体が統合、分解および交換され得るように、可変である。

【0024】

前節において、モジュール式プロセスユニットＰＥＡ内では、生産プロセスとの相互作用は依然としてセンサおよびアクチュエータに対する個々の制御信号に基づいていることが示された。

【0025】

従って、ＰＥＡは、個々のセンサおよびアクチュエータの統合、分解および交換に関しては、可変ではない。これは、制御モジュールＣＭとフィールドレベルとの間の相互作用に必要な信号が、使用されるセンサおよびアクチュエータのタイプおよび変形例に応じて変化し得るからである。例えば、フィードバック信号を有しないバルブ、１つのフィードバック信号を有するバルブまたは２重フィードバック信号を有するバルブ、が存在する。モータは、回転速度の仕様、回転速度フィードバックまたは回転方向の切り替えの有無に関係なく、実装され得る。この変形例の多様性を信号抽象化層が保持することはできないのは、信号抽象化層は個々の信号のレベルで抽象化を行うからである。このことにより、センサおよびアクチュエータの交換の自由度、従って、ＰＥＡの可変性は大きく制限される。

【発明の概要】

【発明が解決しようとする課題】

【0026】

従って、本発明の課題は、従来技術において示される不利な点を克服する方法およびシステムを示すことである。

【課題を解決するための手段】

【0027】

本発明は、独立請求項１の特徴を備える方法により定義される。

【0028】

また、本システムは、請求項６の特徴により示される。

【0029】

本発明のさらなる有利な構成は、従属請求項に記載される。

【0030】

コンポーネントに基づく機能カプセル化システムアーキテクチャが示され、当該システムアーキテクチャは、フィールドのますますインテリジェントなデバイスを機能コンポーネントとして関連付けることにより現在の課題を解決する。

【0031】

基本的なアーキテクチャアプローチ：
信号抽象化層ＳＡＬとは対照的に、制御モジュールＣＭとサービスモジュールＳＭ（以下、コンポーネント抽象化・管理層ＣＡＭＬ（Component Abstraction and Management Layer）とも称する）との間の遷移は、センサおよびアクチュエータの上記変形例の多様性を抽象化することができる。これに基づいて、本発明の開示の範囲内で、ＣＡＭＬをセンサ・アクチュエータ機能性の抽象化レベルとして提供するシステムが示される。考えられる自動化アーキテクチャを図３に示し、以下においてより詳細に説明する。

【0032】

このアーキテクチャの基本構造は、本明細書の導入で記載したＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８のアーキテクチャに大きく依拠している。その一方、両方のアプローチを区別すると、サービスモジュールＳＭ、制御モジュールＣＭおよび制御モジュールテンプレートＣＭＴという概念は、最早選択されず、以下においては、その代わりに、サービスコンポーネントＳＣ（Service Component）、制御コンポーネントＣＣ（Control Component）および制御コンポーネントタイプＣＣＴ（Control Component Type）が言及される。ここで、コンポーネントという概念は、ＶＤＩ ２７７６ （プロセスエンジニアリングプラント－モジュール式プラント、モジュール式プラントの基礎およびプラニング（英：Process engineering plants - Modular plants, Fundamentals and planning modular plants、独：Verfahrenstechnische Anlagen - Modulare Anlagen, Grundlagen und Planung modularer Anlagen））に準拠したモジュール式プラントの構造モデルにおける最下位レベルに依拠している。制御コンポーネントタイプＣＣＴにより、例えば、オープンな標準化されたインタフェースを用いて制御コンポーネント要素を実装することができ、この実装においては、具体的な適用のリアルデータの割り当ては、後の時点において初めて（インタフェースを介して）可能である。

【0033】

制御コンポーネント
自動化デバイス（センサ、アクチュエータ、パッケージユニット、ＩＯステーション）はますますインテリジェントになり、独自の計算能力を有しているため、それらのファームウェアは、単に信号を提供することを遥かに超える能力を有する。

【0034】

ＣＣは、自動化デバイスのソフトウェア表現である。この表現はデバイス自体またはコントローラ等でも実装できる。自動化デバイスおよび表現はアドレス指定可能である。

【0035】

このコンポーネントはアドレス指定可能なユニットであり、（例えば、２６５８に準拠の）標準化されたインタフェースを有しており、このことは従来技術から知られる制御モジュールＣＭとの本質的な相違点である。

【0036】

デバイス固有の特殊性は局所的にコンポーネントにおいて解決されるため、コンポーネントは外側からは常に同一に見える。このデバイスは、それ自体が固有の計算機資源（組み込みデバイス）であってもよく、または既存のフィールドバスシステムを介して外部の計算機資源分だけ拡張されてもよい。

【0037】

まとめると、制御コンポーネントは次の技術的特徴：
-産業プロセス（生産エンジニングプロセスまたはプロセスエンジニアリングプロセス）との接続、
-ソフトウェア（組み込みデバイス、ＰＬＣ、エッジデバイス）の処理用の固別の計算機能力、
-標準化された通信技術（例えば、ＯＰＣ ＵＡサーバ／クライアント、ＯＰＣ ＵＡ Ｐｕｂ／Ｓｕｂ等）、
-標準化された機能指向のコンポーネントインタフェース（例えば、ＶＤＩ／ＶＤＥ／ＮＥＭＵＲ ２６５８に準拠）、
-標準化されたコンポーネントインタフェースに対応するためのデバイス固有の調整が、固別の計算機能力で局所的に解決される（例えば、バルブはフィードバックを有しないか、１つのフィードバックを有するか、２つのフィードバックを有する）こと、
-機能単位としての制御コンポーネントは、エンティティとしてアドレス指定可能である（例えば、ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．１：４８４０／ｎｓ＝１：ｓ＝ＴＩ００１）こと、
を有する。
制御コンポーネントアドレスは、基礎となる通信技術に依存する。

【0038】

サービスコンポーネント
サービスは、多様な構成において、プロセスエンジニアリングと生産エンジニアリングの両面において、自動化エンジニアリング機能をカプセル化する。

【0039】

個々のセンサ／アクチュエータ機能からプラント全体の制御機能まで、基本的に全てが、サービスとしてカプセル化され得る。

【0040】

サービスは、ソフトウェアに実装される機能であり、入力プロセス変数を出力プロセス変数へと処理するようなロジックを記述する。従って、サービスは、最初はプロセスと直接的に接触しない。自動化されるプロセスとの直接的な接続を有さないそのようなサービスは、以下においてサービスコンポーネントと称される。

【0041】

サービスコンポーネントは、専用の計算機能力で実装され、同じく一意にアドレス指定可能である。

【0042】

さらに、サービスコンポーネントは、制御コンポーネントの統合のための複数のオープンインタフェースを有し、それらのデバイスには、自動化された機能の実装において定義された役割が与えられる。

【0043】

まとめると、サービスコンポーネントは以下の技術的特徴、
-プロセスとの直接的な接続はなく、接続された制御コンポーネントを介した間接的な接続のみであること、
-サービスコンポーネントのソフトウェアは、計算機資源（組み込みデバイス、ＰＬＣ、エッジデバイス）で実行されること、
-標準化された通信技術（例えば、ＯＰＣ ＵＡサーバ／クライアント、ＯＰＣ ＵＡ Ｐｕｂ／Ｓｕｂ等）、
-標準化された機能指向のコンポーネントインタフェース（例えば、ＶＤＩ／ＶＤＥ／ＮＥＭＵＲ ２６５８に準拠）、
-機能単位としての制御コンポーネントは、エンティティとしてアドレス指定可能である（例えば、ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．１：４８４０／ｎｓ＝１：ｓ＝Ｍｉｘｉｎｇ）こと、
を有する。
サービスコンポーネントアドレスは、基礎となる通信技術に依存する。

【0044】

制御コンポーネントは、自動化デバイスを表現し、基本的な機能を提供する（プロバイダ）。

【0045】

サービスコンポーネントは、より高品質な自動化機能を表現し、この目的のために制御コンポーネントを使用する（コンシューマ）。サービスコンポーネントは、より高度な自動化機能であり得て、当該より高度な自動化機能は、それ自体がサービスコンポーネントを使用する（従って、サービスコンポーネントプロバイダかつコンシューマである）。

【0046】

制御コンポーネントおよびサービスコンポーネントのアドレス指定及び統合は、新しく導入される統合層ＣＡＭＬを介して行われ、当該統合層ＣＡＭＬは上記プロバイダコンシューマメカニズムを実装している。以下、有利に実装される３つの変形例を説明する。

【0047】

プロバイダコンシューマメカニズムは以下の特徴、
-標準化された通信技術に基づくこと、
-標準化されたインタフェース定義に基づくこと、
-プロバイダとコンシューマは、一意にエンティティとしてアドレス指定可能である（個々の信号ではなくエンティティのアドレス指定）こと、
-プロバイダとコンシューマの相互作用は、片方向と双方向の両方で実装できる（論文の５．２．４章）こと、
-相互作用の実装に応じて、一方側でのみアドレスを設定する必要があるかまたは両側でアドレスを設定する必要があること、
-制御コンポーネントはプロバイダ部を有すること、
-サービスコンポーネントは、制御コンポーネントおよび他のサービスコンポーネントの接続のためのコンシューマ部を有すること、
-サービスコンポーネントはプロバイダ部も有すること、
を有する。

【0048】

（制御モジュールにカプセル化された）センサ／アクチュエータロジックを（サービスモジュールにカプセル化）機能ロジックに柔軟に割り当てる上記原理は、このアーキテクチャにおいても同様に用いられる。このようにして、分散周辺機器にアクセスするための機能性は制御コンポーネントＣＣにカプセル化される。サービスコンポーネントＳＣのプログラムは、対応するインタフェースを有するプレースホルダＣＣＴを含み、当該プレースホルダＣＣＴには、システムのエンジニアリングの過程で制御コンポーネントＣＣを割り当てることができる。このようにして、どのセンサおよびアクチュエータを実際にシステムで使用すべきか、が決定される。

【0049】

コンポーネント抽象化・管理層
このアプローチの拡張として、いわゆるコンポーネント抽象化・管理層ＣＡＭＬの導入が提案される。このコンポーネント抽象化・管理層ＣＡＭＬは、例えば、ＰＬＣにシステム機能性として実装されてもよい。

【0050】

新規層ＣＡＭＬを用いることにより、分散インテリジェンスをカプセル化して、標準化されたインタフェースを有するコンポーネントとして制御プログラム（例えば、サービスコンポーネントＳＣ等）に対して利用可能にすることができる。この実装に際し、ＣＡＭＬは以下のタスクを行うことができる。

【0051】

抽象化機能性：
コンポーネント抽象化・管理層ＣＡＭＬは、抽象化層を構成する。抽象化層は、センサ、アクチュエータおよび制御ループ全体の機能性を抽象化すること、及び、標準化されたインタフェースを有するコンポーネントとして機能ロジック（この場合は、サービスコンポーネントＳＣ）に対して利用可能にすること、ができる。ここで、ＣＡＭＬのこの抽象化機能性は、制御モジュールの必要に応じて専有のインタフェースを標準化されたインタフェースにマッピングすることを含み、これによりＣＭからの抽象化に関してＣＣを作成する。

【0052】

ここで、標準化されたインタフェースは、例えば、以下のような形態を有してもよい。

【0053】

ここで、ＣＣは多数の異なる機能性をカプセル化できることに注意すべきである。

【0054】

これには、（例えば、温度または圧力測定用の）様々なセンサ、（例えば、バルブまたはドライブの制御用の）アクチュエータまたは制御ループ全体が属する。

【0055】

これらの異なるタイプのＣＣには異なるインタフェースを提供する必要があり、当該インタフェースにはＣＣ機能性が適切に抽象化され得る。この目的のために、有利な構成では、ＭＴＰ規格第３部［７］に記載のインタフェースが提案される。

【0056】

表５．１は、概要を示しており、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８－３に規定の「データオブジェクトのインタフェース」によると

インタフェースファミリ 基本インタフェース（拡張）
アナログ値表示 ＡｎａＶｉｅｗ、（ＡｎａＭｏｎ）
アナログ値演算子 ＡｎａＭａｎ、（ＡｎａＭａｎＩｎｔ）
バイナリ値表示 ＢｉｎＶｉｅｗ、（ＢｉｎＭｏｎ）
バイナリ値演算子 ＢｉｎＭａｎ、（ＢｉｎＭａｎＩｎｔ）
デジタル値表示 ＤＩｎｔＶｉｅｗ、（ＤＩｎｔＭｏｎ）
デジタル値演算子 ＤＩｎｔＭａｎ、（ＤＩｎｔＭａｎＩｎｔ）
文字列表示 ＳｔｒｉｎｇＶｉｅｗ
制御 ＰＩＤＣｔｒｌ
バイナリバルブ ＢｉｎＶｌｖ、（ＭｏｎＢｉｎＶｌｖ）
制御可能バルブ ＡｎａＶｌｖ、（ＭｏｎＡｎａＶｌｖ）
バイナリドライブ ＢｉｎＤｒｖ、（ＭｏｎＢｉｎＤｒｖ）

である。

【0057】

組み込む制御コンポーネントＣＣがサービスコンポーネントＳＣと同じコントローラに存在しない場合、この離れて位置する制御コンポーネントＣＣとの通信も、ＣＡＭＬにより抽象化される。このようにして、ＣＣの実装がどのような態様であるか、またはＣＣがどのコントローラに実装されるか、に依存せずに、サービスコンポーネントＳＣにより、制御コンポーネントＣＣの常に同じ制御を行うことができる。

【0058】

割り当て機能性：
従来技術として知られているアーキテクチャでは、制御モジュールＣＭと制御モジュールタイプＣＭＴとの間の割り当ては、エンジニアリングプロセス中に一度決定され、その後は、制御プログラムを変更することによってのみ、調整され得る。本開示において提案される新しいタイプのアーキテクチャでは、ＣＡＭＬが、制御モジュールＣＣと制御モジュールタイプＣＣＴとの間の設定可能な割り当てを可能にする。このようにして、制御コードを調整する必要なしに、システムに組み込まれたセンサおよびアクチュエータをプラントの稼働時に柔軟に再設定することが可能であることは有利である。このためには、対応する設定・ランタイムインタフェースが必要である。これの前提条件となるのが、制御コンポーネントＣＣのアドレス指定可能性である。

【0059】

通信機能性：
制御コンポーネントＣＣが、それが統合されることが見込まれるサービスコンポーネントＳＣと同じコントローラには実装されていない場合、これら２つのコントローラ間の通信が必要である。この通信機能性は、ＣＡＭＬによって引き受けられ得る。

【0060】

自動化プログラムに分散実装ロジックを統一的に統合するメカニズムを示す。ここで、このロジックの機能的抽象化が、従来のように個々の制御信号に基づいて行われるのではなく、その代わりに、コンポーネントが、標準化されたインタフェースを有する自動化システムによって利用可能になる。これらのインタフェースは、例えば、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８、ＰａｃｋＭＬまたはＯＰＣ ＵＡコンパニオン仕様の記載に基づいてよい。このアプローチにより、プロセスエンジニアリングプラントのモジュール化概念であって、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８に関して既にプロセス機能全体のレベルで実装されているモジュール化概念が、フィールドレベルまたは個々の制御レベルまで拡張される。これは、本開示のメカニズムを、個々の信号とイベントのみに基づくＩＥＣ ６１４９９とも異なるものにする。

【0061】

まとめると、以下の考察から特許請求の主題が得られると言うことができる。

【0062】

個々の制御レベル（アクチュエータ、センサ、コントローラ）は、設備制御レベル（オートメーションサービス）から分離される。

【0063】

個々の制御要素（フィールドデバイス、センサ、アクチュエータ、ＩＯステーション）を自動化エンジニアリングの設備機能から分離するが、実装システムの分離を可能にする。個々の制御要素は、設備機能とは別のプログラマブルロジックコントローラＰＬＣで処理できる。

【0064】

個々の制御レベルのカプセル化は、機能インタフェースを用いて行われる、つまり、従来の信号統合、最近のモノ統合、すなわち、一意に識別可能な物理的オブジェクト、を用いて行われる。

【0065】

今日のシステムにおける個々の制御要素の接続は信号に基づいて行われる。異なる装置は、異なる数の信号（入力信号と出力信号）を用いて接続される。この違いは、例えば、高度に柔軟なシステムにおけるセンサおよびアクチュエータの交換可能性の妨げとなる。機能レベルでのカプセル化により、信号レベルでの違いを常に一定の機能インタフェースの背後に隠蔽するインタフェースが、必要になる。

【0066】

このインタフェースは理想的には標準化されているべきである。この場合、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８－３が考えられる。

【0067】

以下において「コンポーネント抽象化・管理層」（ＣＡＭＬ）とも称される中間層の導入は、信号と同等にいわゆる「モノ」を処理することを約束する。

【0068】

今日のシステムは専用のハードウェア構成に従属し、その一方、この専用のハードウェア構成は決定論的バスシステムを設定するために使用される情報を導出する。より高性能のネットワーク技術に関しては、ＩＰに基づくプロトコルの使用が増加している。ハードウェアとソフトウェアとの間の密結合が解決される場合にのみ、高い柔軟性は達成可能である。この課題を、提案される中間層であるコンポーネント抽象化・管理層ＣＡＭＬが有利に引き受ける。コンポーネント抽象化・管理層ＣＡＭＬは、設備機能（サービスコンポーネント）と個々の制御機能（制御コンポーネント）との間の媒介（英：mediator、独：Vermittler）としての役割を果たす。

【0069】

また、本解決手段を有利な例示的な実施形態において以下に示す。

【0070】

図面を参照して本発明を説明するが、図中に記載されている例示的な実施形態は本発明を限定することを意図するものではない。

【図面の簡単な説明】

【0071】

【図1】図１は、ＯＰＡＳ／ＭＴＰの概念の比較と共に例示的なプラントを示す。

【図2】図２は、転送値との比較を示す。

【図3】図３は、ＣＡＭＬを実装するためのアーキテクチャの変形例を示す。

【図4】図４は、２つの温度センサを備えた例示的な実施形態を示す。

【図5】図５は、比較として、従来技術によるアーキテクチャ概念を示す。

【発明を実施するための形態】

【0072】

図１は、例示的な自動化プラントであって、リアクタＲとリアクタ内の温度を測定するための第１のセンサＳ１とを備える第１の制御ループＰＣＬから構成される自動化プラントを示す。ここでの測定値をコントローラＬ１が受け取る。パイプラインＰを介し、リアクタに含まれる内容物の温度を上昇させる（または場合によっては低下させる）加熱装置Ａを用いて、リアクタＲの内容物をポンプ操作可能である。このパイプラインは第２のセンサＳ２を有し、第２のセンサＳ２はその固有のコントローラＬ２と接続されている。これは第２の制御ループＳＣＬである。

【0073】

例示的な構成において、コントローラと測定データがどのように用いられるかが比較して配置されている。左側において、第１のボックスＯＡには、上記のＯＰＡＳ規格ＯＡによる適用が示されている。入力用機能ブロックＡＩ、出力用機能ブロックＡＯ、制御回路ＰＩＤがある。

【0074】

これに対して右側において、ＭＴＰサービスＭＳによる構成が示されている。ここに含まれている機能ブロックは、ブラックボックスのように外部からはアクセスできず、要素レベルではなく機能レベルにおいてのみアクセス可能であるように、カプセル化される。

【0075】

中央のボックス１１０は、本発明による解決手段であって、モジュール性が様々な段階で可能であることも示す解決手段を示している。左側のボックスＳ１’は、左側のセンサＳ１のみに関係し、右側のボックスＳＣＬ’は、さらなる下位要素ＡＩ、ＰＩＤ、ＡＯを備えるＳＣＬの下位の完全な制御ループに関係する。

【0076】

図２は、２つの制御ループＰＣＬおよびＳＣＬを含む例示的な自動化システムの同じ構造を再度示す。ここでも、ボックスＯＡおよびボックスＭＳは、ＯＰＡＳ規格（信号指向）と各々のＭＴＳ規格（機能指向）による解決手段に関係する。

【0077】

左側には使用される変数、例えば、
-値（Value）、
-エンジニアリングユニット（Engineering unit）、
-範囲（Range）、
-シミュレーション値（Simulation value）または
-シミュレーション状態（Simulation state）、
が示されている。

【0078】

右側にはこれに対応する値
-ＷＱＣ (Ｎａｍｕｒ規格に基づく最下位の品質コード（Worst Quality Code））、
-コマンド（Command）、
-プロシージャ（Procedure）、
-状態（State）、
が示されている。

【0079】

この図は、提案されるコンポーネントにフォーカスした解決手段の相互運用性を示すものであり、様々な可能な実装が示されている。

【0080】

図３は、ＣＡＭＬアプローチの３つの異なる実装変形例を示し、ＣＡＭＬは様々な上記タスクを引き受ける。システムにおいてはこれらの変形例の任意の組合せが可能である。

【0081】

ここで、下位層ＳＡＬ、ＰＡＥ、ＰＡＡおよびＨＷＣは、図５および上述の層と同じである。

【0082】

変形例１：この変形例では、サービスコンポーネントＳＣ１および統合される制御コンポーネントＣＣ２は同じコントローラに実装されている。この場合、コントローラの境界を超える通信は必要とされない。その一方、ＣＣ機能性を、標準化されたインタフェースにマッピングし、ＳＣにおいて所望のＣＣＴ（ＣＣＴｂ）に割り当てることが重要である。このようにして、ＣＡＭＬは抽象化機能性と割り当て機能性を引き受ける。この変形例は公知のアーキテクチャと類似しているものの、ＣＡＭＬが抽象化レベルとして追加されており、これによりＣＣとＣＣＴとの間の設定可能な割り当てが可能であるという違いがある。

【0083】

変形例２：別の有利な変形例では、ＣＣ（ＣＣ１）が示されており、当該ＣＣ（ＣＣ１）は、それが統合されるＳＣ（ＳＣ１）とは別のコントローラに実装されている。この場合、ＣＣ（ＣＣＴ１）とＣＣＴ（ＣＣＴａ）との間でデータを交換するためには、クロスコントローラ通信（英：cross-controller communication、独：controlleruebergreifende Kommunikation）が必要とされる。しかし、本変形例においてこの通信はＣＡＭＬを介してではなく、プロバイダコンシューマアプローチを介して行われる。プロバイダコンシューマアプローチは、プロバイダモジュール（Ｐｒｏｖ）とコンシューマモジュール（Ｃｏｎｓ）を提供する。Ｐｒｏｖは、以下のようなタスクを有する、つまり、制御モジュールＣＭが標準化されたインタフェースを元々有していない場合に、ＣＣの機能性を、抽象化する、そして、標準化されたインタフェースにマッピングする、というタスクを有する。また、ＰｒｏｖおよびＣｏｎｓは、通信接続を設定するために、そして、それによりＣＣのデータをＳＣが実装されているコントローラにおいて提供するために、用いられる。この場合、Ｃｏｎｓは、ＣＣ機能性を表現しており、あたかもＣＣ自体がこのコントローラに実装されているかのように、使用できる。この通信は、ＣＡＭＬの背後で抽象化される。また、変形例１と同様に、ＣＡＭＬはＣＣ（ＣＣＴ１）とＣＣＴ（ＣＣＴａ）との間の割り当て機能を引き受ける。

【0084】

変形例３：変形例２と同様に、この場合も、サービスコンポーネントＳＣ１および統合される制御コンポーネントＣＣ３は異なるコントローラに実装されている。従って、本変形例においても、クロスコントローラ通信が必要とされる。しかし、この場合、変形例２とは対照的に、この通信機能性はＣＡＭＬ自体により実装される。ＣＣが実装されているコントローラに、ＣＡＭＬが実装されており、当該ＣＡＭＬは、必要に応じて、ＣＣ機能性を標準化されたインタフェースにマッピングする。このＣＡＭＬは、ＳＣが実装されているコントローラのＣＡＭＬと通信できる。このようにして、その一方でＣＡＭＬは、ＣＣの機能性を抽象化すること、及び、標準化されたインタフェースを有するコンポーネントとしてＳＣに対して利用可能にすること、ができる。その後、このコンポーネントは、上述の２つの場合と同様に、ＣＡＭＬによってＣＣＴに割り当てられ得る。従って、この場合、２つのＣＡＭＬは、抽象化・割り当て機能性および通信機能性の両方を引き受ける。

【0085】

主要プログラム（この場合はＳＣ）の観点からすれば、上記変形例の何れがシステムに実装されているかは重要ではない。全ての変形例においてＣＡＭＬによって利用可能になる抽象化機能性によって、ＳＣには、いずれの場合でも、統合可能な、標準化されたインタフェースを有するコンポーネントが提供される。ＣＣがＳＣと同じコントローラに存在する（変形例１）かまたは他のコントローラにアウトソースされているか（変形例２および３）否か、ＣＣが厳密にどのように実装されているかは、ＳＣにとっては重要ではない。このことは、上記変形例の間で柔軟な変更が可能であるという有利な点を提供する。例えば、コントローラ内部に接続されたセンサ（変形例１）に障害が発生した場合には、障害のあるセンサを一時的または継続的に置き換える外部センサを、例えば変形例３を用いて、問題なく接続することができる。

【0086】

設定・ランタイムインタフェース
上述したように、本開示において提案されるアーキテクチャには、サービスコンポーネントのパラメータ化および調整の役割を果たす設定・ランタイムインタフェースも存在する。更に、ＣＡＭＬの設定を引き受けるインタフェースを提供する必要がある。このインタフェースは、どの制御コンポーネントをどのＣＣＴに割り当てるべきか、を決定するために用いられる。このインタフェースは、例えばＯＰＣ ＵＡサーバを用いて、実装できる。

【0087】

図４において、上述の例示的なプラントに基づいて、明示的な実施形態例を、仮想値を用いてより詳細に説明する。以下では、第１の温度センサＣＣＳ１から代替の第２の温度センサＣＣＳ１^＊へと再構成することを意図している。

【0088】

設定は、設定管理ツール４００によって実行され、必要な値は設定ファイル４１９（層Ｆインポート／エクスポートＡＭＬファイル）によって提供される。

【0089】

２つの制御コンポーネント、つまりセンサ１とセンサ１^＊は、ＡｎａＭｏｎプロバイダとしての制御コンポーネントである。

【0090】

「温度調整」（ＳＣ）方法の制御４０３は、分散制御ノード（Distributed Control Node）ＤＣＮ１「リアクタ」によって行われ、当該分散制御ノードＤＣＮ１は、好適なインタフェース４１１、ＡｎａＭｏｎを用いて、センサおよびコントローラＤＣＮ３、ＤＣＮ４と接続する。

【0091】

ＳＣ温度調整コンシューマ
ＡｎａＭｏｎ－Ｃｏｎ．： ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＲＥＡＣ″
ＰＩＤＣｔｒｌ－Ｃｏｎ．： ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＲＥＡＣ″

【0092】

ＳＣ温度調整は、リアクタにおいて実際の温度を検出するためのＡｎａＭｏｎコンシューマと、インレット温度を制御するためのＰＩＤＣｔｒｌコンシューマとを有する。
コンシューマ＝ＣＣ要件／プレースホルダ

【0093】

制御コンポーネント「ＣＣセンサ１」４０１は、以下によりアドレス指定可能なプロバイダを有する。
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．１０：４８４０／ｎｓ＝３：ｓ＝″ＴＩ００１″｝

【0094】

制御コンポーネント「ＣＣセンサ１^＊」４０２は、以下によりアドレス指定可能なプロバイダを有する。
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．１１：４８４０／ｎｓ＝３：ｓ＝″ＴＩ００２″｝

【0095】

制御コンポーネント「ＰＩＤ Ｃｔｒｌ」４０４は、以下によりアドレス指定可能なプロバイダ（提供者）を有する。
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．２０：４８４０／ｎｓ＝３：ｓ＝″ＴＩＣ１０１″｝

【0096】

サービスコンポーネント「温度調整」４０３は、以下によりアドレス指定可能な２つのコンシューマ（ユーザ）を有する。
-リアクタの実際の温度の役割のＡｎａＭｏｎコンシューマ４１１：
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＲＥＡＣ″｝
-リアクタのインレット温度の役割のＰＩＤＣｔｒｌコンシューマ４１２：
｛ｏｐｃ．ｔｃｐ：//１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＥＭＰＣ″｝
サービスのプロバイダ機能は、図中には明示されていない。

【0097】

プロバイダコンシューマ関係を結合するには、対応するパートナにおいて、それぞれ別のアドレスを設定する必要がある。
プロバイダのＡｎａＭｏｎコンシューマ設定：
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．１０：４８４０／ｎｓ＝３：ｓ＝″ＴＩ００１″｝．

【0098】

コンシューマのＡｎａＭｏｎプロバイダ設定：
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＲＥＡＣ″｝

【0099】

プロバイダのＰＩＤＣｔｒｌコンシューマ設定：
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．２０：４８４０／ｎｓ＝３：ｓ＝″ＴＩＣ１０１″｝

【0100】

コンシューマのＰＩＤＣｔｒｌプロバイダ設定：
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＥＭＰＣ″｝．

【0101】

このようにして、以下の関係を新規に設定した：
温度調整ＴＲＥＡＣは″ＴＩ００１″を使用する。
温度調整ＴＥＭＰＣは″ＴＩＣ１０１″を使用する。

【0102】

本例では、アクティブな双方向の実装が選択された。つまり、コンシューマとプロバイダはそれぞれ、そのパートナにより処理されることになる値を読み取ったことを意味している（ＯＰＣ ＵＡでは、読み取りは通信のアクティブな部分である）。

【0103】

このようにして、関係は両側でも監視され得る。
相互作用の有効化後、リアクタ温度調整例のカスケード制御は機能した。

【0104】

ＣＡＭＬアプローチの一般化
まとめると、ＣＡＭＬアプローチは、自動化ソフトウェアを、ハードウェア固有のロジック（この場合はＣＣ）と機能固有のロジック（この場合はＳＣ）の、２つの部分に細分化すると言える。ＣＡＭＬは、基本的に、以下のようなタスクを有している、すなわち、ハードウェア固有のロジックを、その具体的な形式およびその実装場所に関して抽象化するような、そして、標準化されたインタフェースを有するコンポーネントの形式で、機能固有のロジックに対して利用可能とするような、タスクを有する。本発明の開示においては、本思想の考えられる実装の１つを、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８のガイドラインに依拠するアーキテクチャに基づいて、示した。

【0105】

しかし、ＣＡＭＬアプローチはモジュール式プラントの概念のみに適用可能であるわけではない。また本発明の開示おいて示される概念は、従来のＰＬＣプログラムにおいても付加価値を提供する。本概念により、その機能が直接的にフィールドで分散インテリジェントとして実装されているインテリジェントデバイスを、迅速、簡潔かつ柔軟に制御コードに統合することが可能になる。

【0106】

そのような分散インテリジェンスの統合メカニズムは、先駆的なものであり、現在の潮流に沿うものである。例えば、産業用モノのインターネット（ＩＩｏＴ（Industrial Internet of Things））のアプローチは、インテリジェントデバイスを用いてセンサおよびアクチュエータのアクセスロジックを直接的にフィールドで実装することに、大きく基づいている。そのため、ＰＬＣプログラムに分散インテリジェンスを統合することは不可欠である。また、オープンプロセスオートメーション規格（Open Process Automation Standard（ＯＰＡＳ））［６］は、自動化機能性を非常に細分化して多数の分散制御ノード（ＤＣＮ）に分散することにますます基づいている。分散インテリジェンスが焦点となり、これに対応する統合メカニズムが必要とされている。

【0107】

産業環境における本開示の概念の将来的な使用に関して、ＣＡＭＬをエンジニアリングするのに有用な選択肢を設計することが必要である。この設計はまだ未解決である。１つのアプローチは、新しいタグタイプの導入である。最近のエンジニアリングツールでは、タグタイプとして、一般的に、入力、出力およびフラグは利用可能である。将来的には、さらに「コンポーネント」のタグタイプが存在する可能性があり、当該タグタイプは、フィールドの分散実装インテリジェントコンポーネントの全てを統合することを可能にする。

【0108】

本開示の導入部では、可変性のための５つのイネーブラ特徴に関して、最近の自動化システムにどのような課題が存在するかを示した。以下では、どのようにしてこれらの課題を本開示のアプローチを用いて解決できるか、改めてまとめる。

【0109】

センサアクセスロジックおよびアクチュエータアクセスロジックの抽象化と、標準化されたインタフェースへのそのマッピングが企図されている。このようにして、例えば、バルブ機能の詳細な実装態様やフィードバック信号の有無に依存することなく、各バルブは同じインタフェースにより表現される。従って、異なるタイプ（例えば、異なるバルブタイプ）のセンサ／アクチュエータは、同じ方法で、自動化システムに統合され得て、普遍性の変更イネーブラに対応する交換可能性が得られる。

【0110】

センサ機能性およびアクチュエータ機能性のより、本開示の対象に基づき、普遍的なインタフェースを用いて、より高性能またはより複雑なセンサおよびアクチュエータを自動化システムに組み込むことも、容易に可能であり、これによりスケーラビリティが支援される。

【0111】

統一的に標準化されたインタフェース（例えば、全てのバルブタイプに「１つの」インタフェース、全てのモータタイプに「１つの」インタフェース）を用いることにより、異なるセンサタイプおよびアクチュエータタイプに渡る互換性を確保することもできる。

【0112】

また、本開示の概念においては、更に、センサとアクチュエータにアクセスするためのロジックの分散実装が提案されている。これによると、このロジックは、直接的にフィールドにおいて、例えば小型コントローラまたはマイクロコントローラ上で、直接的にセンサまたはアクチュエータに実装される。このようにして、センサとアクチュエータは、その制御に必要な全てのロジックを備える。これにより、センサおよびアクチュエータをプラントの別の場所へと移動させることがより容易に可能である。これによりモビリティの変更イネーブラが支援される。

【0113】

ＣＡＭＬアプローチは、標準化されたコンポーネントにおけるセンサ／アクチュエータアクセスロジックの抽象化を実装する。このようにして、モジュール性の概念は、フィールドレベルまたは個々の制御レベルに拡張される。

【0114】

本開示の概念に基づきプロセスプラントの変更イネーブラに関する課題を解決できることが、明らかとなった。従って、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８のアーキテクチャ概念に記載されているような、モジュール式プロセスユニットＰＥＡのレベルのみではなく、個々の制御ユニット、つまり、アクチュエータ、センサおよび制御ループ、のレベルでも、可変性が実現可能である。

【0115】

さらなる有利な点は、センサおよびアクチュエータ用アクセスロジックの提案される分散実装において明らかになる。これは、機能固有のロジック（例えば、ＳＣ）とハードウェア固有のロジック（例えば、ＣＣ）とが分離されていることを含む。この分離により、多くのさらなる有利な点が得られる。

【0116】

機能固有のロジックの再利用性を向上させることができ、機能固有のロジックの更新性を改善することができる。

【0117】

ハードウェアまたはプロセス接続の構成における自由度を向上させることができる。

【0118】

デバイス固有のロジックと機能固有のロジックの分離を導入することにより、両方のロジック部分についてエンジニアリングを、大幅に、互いに独立して行うことができる。

【0119】

これにより、機能指向のロジックは、予めエンジニアリングされ、予めテストされたコンポーネントとして外部に供給され得る。

【0120】

デバイス固有のロジックは、予めエンジニアリングして、デバイスのファームウェアによって、供給され得る。

【0121】

中央計算システム上で機能固有のロジックを実装することにより（例えば、ＯＰＡＳ ＡＣＰを参照）、ハードウェア上で複数の「仮想」モジュール／スキッド／ＰＵを実装することが可能になる。この場合、以下の有利な点が得られる。

【0122】

機械メーカまたはモジュールメーカのコストが削減される。スケーラブルなＰＬＣ資源によって、柔軟性が達成される。デバイス固有のロジックと機能固有のロジックの分離が、様々なデバイスへのロジック部分の分散を可能とする。従来はＰＬＣ資源上で実装されていたロジックの一部を分散してデバイス資源上で実装することにより、デバイス資源を効率的に使用できる。故障が発生した場合、故障したデバイスを簡単に交換できる。

【0123】

標準化されたコンポーネントインタフェースの導入により、分散周辺機器の診断に制限が生じる可能性がある。標準化されたインタフェースにおいても提供されている情報のみをコンポーネントから読み取ることができるに過ぎない。

【0124】

また、迅速かつ容易に分散周辺機器をランタイムに交換することができるので、クロスシステムハードウェア構成（英：cross-system hardware configuration、独：systemuebergreifende Hardware-Konfiguration）がエンジニアリングの時点では最早実装可能ではない。従って、このような柔軟なシステムにおいてハードウェアを構成するための新しいアプローチを作成する必要がある。

【図1】

【図2】

【図3】

【図4】

【図5】

【手続補正書】

【提出日】2023-04-18

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

少なくとも１つの物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）を含む分散型の自動化システムにて、少なくとも１つの自動化機能を用いて、前記自動化システムの機能制御を前記物理的要素と接続するための方法であって、
前記自動化システムが自動化ソフトウェアを有し、当該自動化ソフトウェアが、２つの部分に、すなわち、少なくとも１つの制御コンポーネント（ＣＣ）用のハードウェア固有のロジックと少なくとも１つのサービスコンポーネント（ＳＣ）用の機能固有のロジックの２つの部分に、細分化され、
以下のステップ、すなわち、
-制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）における前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）の機能性を抽象化し、そして、前記物理的要素の実インタフェースを前もって標準化されたインタフェースにマッピングするステップ、
-前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）を、前記物理的要素と同じ標準化されたインタフェースを有するプレースホルダ（ＣＣＴ）に割り当てるステップ、
-前記少なくとも１つの自動化機能を、前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）に対する少なくとも１つの第１のインタフェース（１３３、１３４、１３５）と少なくとも１つのさらなる通信インタフェースとを有するサービスコンポーネント（ＳＣ）に、カプセル化するステップ、
-前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）と、前記サービスコンポーネント（ＳＣ）または前記プレースホルダ（ＣＣＴ）と、の間の通信を行うステップ、
を備え、
-物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）の設定が、前記自動化システムのランタイム中にいつでも、前記通信インタフェース（１００）によって、実行され得る、方法。

【請求項2】

前記物理的要素が、前記自動化システムにおけるセンサまたはアクチュエータの機能性を有することを特徴とする、
請求項１に記載の方法。

【請求項3】

前記標準化されたインタフェースが、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８規格に準拠して定義されていることを特徴とする、
請求項１または２に記載の方法。

【請求項4】

前記通信インタフェース（１００）が、ＯＰＣ ＵＡ規格に準拠して動作することを特徴とする、
請求項１～３の何れか１項に記載の方法。

【請求項5】

前記サービスコンポーネント（ＳＣ）が、上位の自動化機能のために、さらなるサービスコンポーネント（ＳＣ１）に対する少なくとも１つのインタフェースを有し、前記上位の自動化機能は前記さらなるサービスコンポーネントにカプセル化された下位の自動化機能にアクセスすることを特徴とする、
請求項１～４の何れか１項に記載の方法。

【請求項6】

分散型の自動化システムにて、少なくとも１つの自動化機能を用いて、前記自動化システムにおける機能制御を連結するための装置（ＣＡＭＬ）であって、前記自動化システムが自動化ソフトウェアを有し、当該自動化ソフトウェアが、２つの部分に、すなわち、少なくとも１つの制御コンポーネント（ＣＣ）用のハードウェア固有のロジックと少なくとも１つのサービスコンポーネント（ＳＣ）用の機能固有のロジックの２つの部分に、細分化され、
物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）を含む前記自動化システムにて、
-少なくとも１つの制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）を備えており、当該制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）は、前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）の機能性の抽象化と、前記物理的要素の実インタフェースの前もって標準化されたインタフェースへのマッピングと、を有し、前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）は、前記物理的要素と同じ標準化されたインタフェースを有するプレースホルダ（ＣＣＴ）に割り当て可能であり、
-少なくとも１つのサービスコンポーネント（ＳＣ）を備えており、当該サービスコンポーネント（ＳＣ）は、前記少なくとも１つの自動化機能のカプセル化を有し、前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）に対する少なくとも１つのインタフェース（１３３、１３４、１３５）と少なくとも１つのさらなる通信インタフェースとを含み、前記物理的要素（ＣＣ１、ＣＣ２、ＣＣ３）と前記サービスコンポーネント（ＳＣ）との間での通信を可能とし、
-前記装置（ＣＡＭＬ）の設定が、前記自動化システムのランタイム中にいつでも、前記通信インタフェース（１００）によって、実行され得る、装置。

【請求項7】

前記物理的要素が、前記自動化システムにおけるセンサまたはアクチュエータの機能性を有することを特徴とする、
請求項６に記載の装置。

【請求項8】

前記標準化されたインタフェースが、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８規格に準拠して定義されていることを特徴とする、
請求項６または７に記載の装置。

【請求項9】

前記通信インタフェース（１００）が、ＯＰＣ ＵＡ規格に準拠して動作することを特徴とする、
請求項６～８の何れか１項に記載の装置。

【請求項10】

前記少なくとも１つの物理的要素（ＣＣ２）および関連する前記制御コンポーネント（ＳＣ１）が、同じコントローラ（１１０）に実装され（変形例１）、制御コンポーネントとコントローラコンポーネントとの間の通信が、コントローラ内部のインタフェース（１３３、１３４）を用いて行われることを特徴とする、
請求項６～９の何れか１項に記載の装置。

【請求項11】

前記少なくとも１つの物理的要素（ＣＣ１）および関連する前記制御コンポーネント（ＳＣ１）が同じコントローラ（１１０）には実装されず（変形例２）、前記制御コンポーネントと前記コントローラコンポーネントとの間の通信が、クロスコントローラインタフェースを介してプロバイダコンシューマアプローチを用いて行われることを特徴とする、
請求項６～９の何れか１項に記載の装置。

【請求項12】

前記少なくとも１つの物理的要素（ＣＣ３）および関連する前記制御コンポーネント（ＳＣ１）が同じコントローラ（１１０）には実装されず（変形例３）、制御コンポーネントとコントローラコンポーネントとの間の通信がコントローラワイドのインタフェースを介して（１３１、１３２、１３５）行われることを特徴とする、
請求項６～９の何れか１項に記載の装置。

【手続補正2】

【補正対象書類名】明細書

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【発明の詳細な説明】

【技術分野】

【0001】

本発明は、分散自動化システムにおける機能コントローラを接続するための方法および装置に関する。

【背景技術】

【0002】

製品の個別化の強化、製品のライフサイクルの短期化および市場のボラティリティの上昇化の傾向は、初めは生産自動化において認められ、現在ではプロセス産業でも認められている。これらの市場開発には生産プラントのさらなる可変性が必要とされる。この可変性は、普遍性、モビリティ、スケーラビリティ、モジュール性および互換性という５つのイネーブラ特徴（英：enabling feature、独：Befaehigungsmerkmal）に依存する。
-普遍性は、製品および技術の様々な要件に合わせるためのプラントのサイジングおよび設定を示す（例えば、変形例の多様性）。
-モビリティは、物体（例えば、ローラ上の機器）について局所的に制限されることがない可動性を提供する。
-スケーラビリティにおいては、技術的、空間的および人材的な通気性（＝拡張性と縮小性）が望まれる（例えば、支配的な市場需要に従ってプラントのサイズを経済的に調整すること）。
-モジュール性に関しては、標準化された機能性の単位または要素が、作成されることになる（例えば、「プラグアンドプロデュース」モジュール）。
-最後に、互換性は材料、情報、媒体およびエネルギの相互接続性を保証する（例えば、統一ソフトウェアインタフェース）。

【0003】

これらの特徴は、生産プラントのハードウェア構成においてだけでなく、特に自動化エンジニアリングの構成においても有効である。このことは、最近の自動化システムにおける課題となる。

【0004】

最近の自動化システムにおいては、機能的な実装と、物理的なプロセスとのその接続との間に密連結が存在する。この連結は、特に、分散周辺機器を統合するための選択肢が、個々のハードウェア固有の信号の統合に限定されることを特徴とする。ここで、異なるセンサおよびアクチュエータは、同様のまたは同一のタスクを実行する場合でも、異なるインタフェースを介して制御される。この点は多くの変更イネーブラ（英：change enabler、独：Wandlungsbefaehiger）の妨げとなる。

【0005】

普遍性に関して、センサロジックおよびアクチュエータロジックの実装において変形例の多様性がほぼ実現不可能であるという問題がり、その理由は、異なる信号インタフェースに変形例の多様性が反映されるからである。同じ理由から、よりインテリジェントなフィールドデバイスまたはより高性能の技術の使用も限定されるため、スケーラビリティの変更イネーブラの妨げとなる。

【0006】

分散周辺機器と自動化システムとの間の情報フローに関しては、それに対応する信号インタフェースが一致する場合にのみ互換性がある。異なるセンサタイプおよび／またはアクチュエータタイプの違いと、それに伴う信号インタフェースの違いがある場合、互換性は保証されない。

【0007】

個々の信号に基づく自動化システムとの分散周辺機器の接続は、多数の個々の配線および追加のリモートＩ／Ｏアセンブリの使用と関係する。これにより、センサおよびアクチュエータをプラントの別の場所に単純に再接続することが制限されるため、センサおよびアクチュエータのモビリティが制限される。

【0008】

上記変更イネーブラを実装する上でプラントのモジュール性が決定的に重要である。現在多くの場合、モジュール性はプラントの物理的構造に限定されており、自動化ソフトウェアには反映されていない。

【0009】

まとめると、自動化システムとの分散周辺機器の接続は、従来は直接的にセンサおよびアクチュエータを制御する個々の信号に基づいて行われると結論付けられる。これが従来では十分であったのは、自動化ソフトウェアが、入力信号を単純な信号変換ロジックを用いて出力信号に変換することに基づいていたためである。しかし、プラントに可変性の要求があると直ちに、この概念は上記課題を呈する。

【0010】

従来技術
上記課題を解決するための既存のアプローチは、インテリジェントフィールドデバイスの使用、つまり分散インテリジェンスの使用、である。個々の小型のセンサおよびアクチュエータを制御するためのロジックは、自動化システムにではなく、直接的にフィールドに、つまり、このロジックが必要とされるところに、実装される。そのようなアプローチは、例えばエッジ環境から、知られている。このことは、自動化システムには分散周辺機器を制御するための個々の信号を処理する必要がなくなるという有利な点を有する。その代わりに、センサ、アクチュエータまたは制御ループ全体の機能性は、抽象化され、定義され、最も良くて標準化されたインタフェースを介して自動化システムに利用可能となる。

【0011】

この思想を既に現在アプローチに使用する技術がＰＲＯＦＩＢＵＳ ＰＡである。この場合、自動化システムに統合されずにフィールドで通信を実装する機能モジュールが標準化されている。その一方、ＰＲＯＦＩＢＵＳ ＰＡにおいては、依然として信号に基づく抽象化が存在する。製造産業の分野では、分散インテリジェンスの基礎はＩＯ－Ｌｉｎｋ技術に置かれている。現在、これらのアプローチの使用は、現在の統合技術がインテリジェント機器の統合された機能を部分的にのみしか考慮に入れていないかまたは全く考慮に入れていないことによって、限定されている。

【0012】

このような接続の例は特許文献１にあり、そこでは、シリアルインターフェースの背後にイーサネットインターフェースがエミュレートされ、その結果、ウェブサーバへ既知のＴＣＰ／ＩＰプロトコルを介してアクセスすることができる。

【0013】

これらのフィールドバスシステムに加えて、いくつかのメーカが、フィールドでの分散インテリジェンスの実装に非常に良好なマイクロコントローラも、例えば、Ｔｕｒｃｋ社のＴＢＥＮ－Ｌ－ＰＬＣ等も、提供している。ＴＢＥＮ－Ｌ－ＰＬＣは、ＣＯＤＥＳＹＳに基づく制御コンポーネントに加えて、様々なプロトコル（例えば、ＰＲＯＦＩＮＥＴ、イーサネット、Ｍｏｄｂｕｓ等）を用いて、他のプログラマブルロジックコントローラ（ＰＬＣ）または直接的にクラウドと通信する選択肢も有している。

【0014】

最後に、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８規格に従って、プロセスプラントの全体機能の一部は、分散インテリジェンスとして、プロセス装置アセンブリ（ＰＥＡ：Ｐｒｏｃｅｓｓ Ｅｑｕｉｐｍｅｎｔ Ａｓｓｅｍｂｌｉｅｓ）と称されるモジュールにアウトソースされる。また、同様のアプローチが、生産自動化分野のスキルおよび能力に関する研究分野でも採用されている。ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８に基づくモジュール式オートメーションの概念は、今後自動化システムに分散インテリジェンスを実装して、これにより上記課題を解決する非常に優れたアプローチと考えられる。

【0015】

また、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８のアーキテクチャ概念は図５に詳細に説明されている。

【0016】

階層モデルは、下から上へと下記のように構成されている。個々のモジュールのより詳細な説明は、以下に続く：
ハードウェア設定、ＨＷＣ
入力のプロセスイメージ、ＰＡＥ／出力のプロセスイメージ ＰＡＡ
信号抽象化層 ＳＡＬ
サービスモジュール ＳＭ１
制御モジュール ＣＭ１、ＣＭ２、ＣＭ３
制御モジュールタイプ ＣＭＴ１、．．．

【0017】

図の例では、通信はＯＰＣ ＵＡ規格に従い行われる。

【0018】

モジュール式オートメーションの現在の概念は、プロセスエンジニアリング機能を分散インテリジェンスとして利用可能とすることに基づいている。ここで、これらの機能は、モジュール式プロセスユニットＰＥＡでのサービスの形態で実装される。

【0019】

サービスモジュールＳＭと制御モジュールＣＭ：
いわゆるサービスは、この場合、サービスモジュールＳＭと任意の数の制御モジュールＣＭからなる。サービスモジュールには、サービスの制御ロジックが、標準化された状態機械に基づいて実装されている。しかしここでは、サービスを実行するためにどのセンサおよびアクチュエータを使用するかはまだ決定されていない。その一方、制御モジュールは、センサおよび／またはアクチュエータを制御するためのロジックをカプセル化し、このようにして、サービスを物理的プロセスに接続する役割を果たす。

【0020】

完全なサービスを実装するには、サービスモジュールに対して、必要な制御モジュールを割り当てる必要がある。この割り当ては、本明細書において提示されるアーキテクチャ概念において柔軟に実装されている。この目的のために、サービスモジュールのプログラムは、センサおよびアクチュエータ用のタイプインタフェース（英：type interface、独：Typ-Schnittstelle）に対して開発されている。このプログラムは、生産プロセスと相互作用する必要がある場所に、従って制御モジュールを統合する必要がある場所に、これに対応するプレースホルダモジュール（英：placeholder module、独：Platzhalter-Baustein）を含む。これらのプレースホルダは、制御モジュールタイプＣＭＴとして実装され、プレースホルダを後から埋める制御モジュールと同じ標準化されたインタフェースを有する。その際、例えば、バルブ、モータ、センサまたは制御ループ全体用の様々なインタフェースを備える様々な制御モジュールタイプＣＭＴが利用可能である。サービスを実装するために、所望の制御モジュールＣＭのインタフェースは、プレースホルダＣＭＴのインタフェースにマッピングされる。このようにして、ＳＭには、実際に制御されるセンサおよびアクチュエータが、割り当てられる。

【0021】

しかし、この手順は、割り当てがシステムのエンジニアリング中に一度実行されると、その後は、制御プログラムの調整なしでは割り当てを調整することは最早不可能である、という不利な点を有する。

【0022】

サービスモジュールＳＭ用の設定・ランタイムインタフェースは、同様にモジュール式プロセスユニットＰＥＡに含まれるＯＰＣ ＵＡサーバにより、提供される。この設定・ランタイムインタフェースを介して、サービスモジュールＳＭの設定パラメータ及びプロシージャパラメータを設定することができ、サービスモジュールＳＭの状態機械を制御（開始、停止等）することができる。

【0023】

信号抽象化層ＳＡＬ（Signal Abstraction Layer）
生産プロセスのセンサおよびアクチュエータと制御モジュールＣＭとの間の相互作用は、従来のメカニズムに基づいている。ハードウェア設定ＨＷＣに関して、ハードウェアアドレスが定義され、当該ハードウェアアドレスのもとで、使用されるセンサおよびアクチュエータを見つけることができる。これらのアドレスの後方の現在値は、各ＰＬＣ制御サイクルの開始時に、センサ信号の場合は入力のプロセスイメージＰＡＥに、アクチュエータ信号の場合は出力のプロセスイメージＰＡＡに、記録される。ここで、ＰＡＥとＰＡＡに格納された値は、制御モジュールＣＭの制御プログラムにおいて使用され得る。その一方、これらの信号の使用を単純化するため、プログラムにおいてはハードウェアアドレスそれ自体が使用されるのではなく、ハードウェアアドレスに割り当てられているユーザ定義シンボルが使用される。ＨＷＣで定義されたハードウェアアドレスとプログラムで使用されるシンボルとの関係は、信号抽象化層ＳＡＬと称されるメカニズムを用いて実現される。

【0024】

従って、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８の意味でのモジュール式プロセスユニットＰＥＡは、標準化されたインタフェースを介して抽象化される分散インテリジェンスを提供する。このようにして、ＰＥＡレベルの上記課題は解決される。ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８の意味でのモジュール式プラントは、ＰＥＡ全体が統合、分解および交換され得るように、可変である。

【0025】

前節において、モジュール式プロセスユニットＰＥＡ内では、生産プロセスとの相互作用は依然としてセンサおよびアクチュエータに対する個々の制御信号に基づいていることが示された。

【0026】

従って、ＰＥＡは、個々のセンサおよびアクチュエータの統合、分解および交換に関しては、可変ではない。これは、制御モジュールＣＭとフィールドレベルとの間の相互作用に必要な信号が、使用されるセンサおよびアクチュエータのタイプおよび変形例に応じて変化し得るからである。例えば、フィードバック信号を有しないバルブ、１つのフィードバック信号を有するバルブまたは２重フィードバック信号を有するバルブ、が存在する。モータは、回転速度の仕様、回転速度フィードバックまたは回転方向の切り替えの有無に関係なく、実装され得る。この変形例の多様性を信号抽象化層が保持することはできないのは、信号抽象化層は個々の信号のレベルで抽象化を行うからである。このことにより、センサおよびアクチュエータの交換の自由度、従って、ＰＥＡの可変性は大きく制限される。

【先行技術文献】

【特許文献】

【0027】

【特許文献1】独国特許出願公開第１０ ２００８ ０５８ ０３３号明細書

【発明の概要】

【発明が解決しようとする課題】

【0028】

従って、本発明の課題は、従来技術において示される不利な点を克服する方法およびシステムを示すことである。

【課題を解決するための手段】

【0029】

本発明は、独立請求項１の特徴を備える方法により定義される。

【0030】

また、本システムは、請求項６の特徴により示される。

【0031】

本発明のさらなる有利な構成は、従属請求項に記載される。

【0032】

コンポーネントに基づく機能カプセル化システムアーキテクチャが示され、当該システムアーキテクチャは、フィールドのますますインテリジェントなデバイスを機能コンポーネントとして関連付けることにより現在の課題を解決する。

【0033】

基本的なアーキテクチャアプローチ：
信号抽象化層ＳＡＬとは対照的に、制御モジュールＣＭとサービスモジュールＳＭ（以下、コンポーネント抽象化・管理層ＣＡＭＬ（Component Abstraction and Management Layer）とも称する）との間の遷移は、センサおよびアクチュエータの上記変形例の多様性を抽象化することができる。これに基づいて、本発明の開示の範囲内で、ＣＡＭＬをセンサ・アクチュエータ機能性の抽象化レベルとして提供するシステムが示される。考えられる自動化アーキテクチャを図３に示し、以下においてより詳細に説明する。

【0034】

このアーキテクチャの基本構造は、本明細書の導入で記載したＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８のアーキテクチャに大きく依拠している。その一方、両方のアプローチを区別すると、サービスモジュールＳＭ、制御モジュールＣＭおよび制御モジュールテンプレートＣＭＴという概念は、最早選択されず、以下においては、その代わりに、サービスコンポーネントＳＣ（Service Component）、制御コンポーネントＣＣ（Control Component）および制御コンポーネントタイプＣＣＴ（Control Component Type）が言及される。ここで、コンポーネントという概念は、ＶＤＩ ２７７６ （プロセスエンジニアリングプラント－モジュール式プラント、モジュール式プラントの基礎およびプラニング（英：Process engineering plants - Modular plants, Fundamentals and planning modular plants、独：Verfahrenstechnische Anlagen - Modulare Anlagen, Grundlagen und Planung modularer Anlagen））に準拠したモジュール式プラントの構造モデルにおける最下位レベルに依拠している。制御コンポーネントタイプＣＣＴにより、例えば、オープンな標準化されたインタフェースを用いて制御コンポーネント要素を実装することができ、この実装においては、具体的な適用のリアルデータの割り当ては、後の時点において初めて（インタフェースを介して）可能である。

【0035】

制御コンポーネント
自動化デバイス（センサ、アクチュエータ、パッケージユニット、ＩＯステーション）はますますインテリジェントになり、独自の計算能力を有しているため、それらのファームウェアは、単に信号を提供することを遥かに超える能力を有する。

【0036】

ＣＣは、自動化デバイスのソフトウェア表現である。この表現はデバイス自体またはコントローラ等でも実装できる。自動化デバイスおよび表現はアドレス指定可能である。

【0037】

このコンポーネントはアドレス指定可能なユニットであり、（例えば、２６５８に準拠の）標準化されたインタフェースを有しており、このことは従来技術から知られる制御モジュールＣＭとの本質的な相違点である。

【0038】

デバイス固有の特殊性は局所的にコンポーネントにおいて解決されるため、コンポーネントは外側からは常に同一に見える。このデバイスは、それ自体が固有の計算機資源（組み込みデバイス）であってもよく、または既存のフィールドバスシステムを介して外部の計算機資源分だけ拡張されてもよい。

【0039】

まとめると、制御コンポーネントは次の技術的特徴：
-産業プロセス（生産エンジニングプロセスまたはプロセスエンジニアリングプロセス）との接続、
-ソフトウェア（組み込みデバイス、ＰＬＣ、エッジデバイス）の処理用の固別の計算機能力、
-標準化された通信技術（例えば、ＯＰＣ ＵＡサーバ／クライアント、ＯＰＣ ＵＡ Ｐｕｂ／Ｓｕｂ等）、
-標準化された機能指向のコンポーネントインタフェース（例えば、ＶＤＩ／ＶＤＥ／ＮＥＭＵＲ ２６５８に準拠）、
-標準化されたコンポーネントインタフェースに対応するためのデバイス固有の調整が、固別の計算機能力で局所的に解決される（例えば、バルブはフィードバックを有しないか、１つのフィードバックを有するか、２つのフィードバックを有する）こと、
-機能単位としての制御コンポーネントは、エンティティとしてアドレス指定可能である（例えば、ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．１：４８４０／ｎｓ＝１：ｓ＝ＴＩ００１）こと、
を有する。
制御コンポーネントアドレスは、基礎となる通信技術に依存する。

【0040】

サービスコンポーネント
サービスは、多様な構成において、プロセスエンジニアリングと生産エンジニアリングの両面において、自動化エンジニアリング機能をカプセル化する。

【0041】

個々のセンサ／アクチュエータ機能からプラント全体の制御機能まで、基本的に全てが、サービスとしてカプセル化され得る。

【0042】

サービスは、ソフトウェアに実装される機能であり、入力プロセス変数を出力プロセス変数へと処理するようなロジックを記述する。従って、サービスは、最初はプロセスと直接的に接触しない。自動化されるプロセスとの直接的な接続を有さないそのようなサービスは、以下においてサービスコンポーネントと称される。

【0043】

サービスコンポーネントは、専用の計算機能力で実装され、同じく一意にアドレス指定可能である。

【0044】

さらに、サービスコンポーネントは、制御コンポーネントの統合のための複数のオープンインタフェースを有し、それらのデバイスには、自動化された機能の実装において定義された役割が与えられる。

【0045】

まとめると、サービスコンポーネントは以下の技術的特徴、
-プロセスとの直接的な接続はなく、接続された制御コンポーネントを介した間接的な接続のみであること、
-サービスコンポーネントのソフトウェアは、計算機資源（組み込みデバイス、ＰＬＣ、エッジデバイス）で実行されること、
-標準化された通信技術（例えば、ＯＰＣ ＵＡサーバ／クライアント、ＯＰＣ ＵＡ Ｐｕｂ／Ｓｕｂ等）、
-標準化された機能指向のコンポーネントインタフェース（例えば、ＶＤＩ／ＶＤＥ／ＮＥＭＵＲ ２６５８に準拠）、
-機能単位としての制御コンポーネントは、エンティティとしてアドレス指定可能である（例えば、ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．１：４８４０／ｎｓ＝１：ｓ＝Ｍｉｘｉｎｇ）こと、
を有する。
サービスコンポーネントアドレスは、基礎となる通信技術に依存する。

【0046】

制御コンポーネントは、自動化デバイスを表現し、基本的な機能を提供する（プロバイダ）。

【0047】

サービスコンポーネントは、より高品質な自動化機能を表現し、この目的のために制御コンポーネントを使用する（コンシューマ）。サービスコンポーネントは、より高度な自動化機能であり得て、当該より高度な自動化機能は、それ自体がサービスコンポーネントを使用する（従って、サービスコンポーネントプロバイダかつコンシューマである）。

【0048】

制御コンポーネントおよびサービスコンポーネントのアドレス指定及び統合は、新しく導入される統合層ＣＡＭＬを介して行われ、当該統合層ＣＡＭＬは上記プロバイダコンシューマメカニズムを実装している。以下、有利に実装される３つの変形例を説明する。

【0049】

プロバイダコンシューマメカニズムは以下の特徴、
-標準化された通信技術に基づくこと、
-標準化されたインタフェース定義に基づくこと、
-プロバイダとコンシューマは、一意にエンティティとしてアドレス指定可能である（個々の信号ではなくエンティティのアドレス指定）こと、
-プロバイダとコンシューマの相互作用は、片方向と双方向の両方で実装できること、
-相互作用の実装に応じて、一方側でのみアドレスを設定する必要があるかまたは両側でアドレスを設定する必要があること、
-制御コンポーネントはプロバイダ部を有すること、
-サービスコンポーネントは、制御コンポーネントおよび他のサービスコンポーネントの接続のためのコンシューマ部を有すること、
-サービスコンポーネントはプロバイダ部も有すること、
を有する。

【0050】

（制御モジュールにカプセル化された）センサ／アクチュエータロジックを（サービスモジュールにカプセル化）機能ロジックに柔軟に割り当てる上記原理は、このアーキテクチャにおいても同様に用いられる。このようにして、分散周辺機器にアクセスするための機能性は制御コンポーネントＣＣにカプセル化される。サービスコンポーネントＳＣのプログラムは、対応するインタフェースを有するプレースホルダＣＣＴを含み、当該プレースホルダＣＣＴには、システムのエンジニアリングの過程で制御コンポーネントＣＣを割り当てることができる。このようにして、どのセンサおよびアクチュエータを実際にシステムで使用すべきか、が決定される。

【0051】

コンポーネント抽象化・管理層
このアプローチの拡張として、いわゆるコンポーネント抽象化・管理層ＣＡＭＬの導入が提案される。このコンポーネント抽象化・管理層ＣＡＭＬは、例えば、ＰＬＣにシステム機能性として実装されてもよい。

【0052】

新規層ＣＡＭＬを用いることにより、分散インテリジェンスをカプセル化して、標準化されたインタフェースを有するコンポーネントとして制御プログラム（例えば、サービスコンポーネントＳＣ等）に対して利用可能にすることができる。この実装に際し、ＣＡＭＬは以下のタスクを行うことができる。

【0053】

抽象化機能性：
コンポーネント抽象化・管理層ＣＡＭＬは、抽象化層を構成する。抽象化層は、センサ、アクチュエータおよび制御ループ全体の機能性を抽象化すること、及び、標準化されたインタフェースを有するコンポーネントとして機能ロジック（この場合は、サービスコンポーネントＳＣ）に対して利用可能にすること、ができる。ここで、ＣＡＭＬのこの抽象化機能性は、制御モジュールの必要に応じて専有のインタフェースを標準化されたインタフェースにマッピングすることを含み、これによりＣＭからの抽象化に関してＣＣを作成する。

【0054】

ここで、標準化されたインタフェースは、例えば、以下のような形態を有してもよい。

【0055】

ここで、ＣＣは多数の異なる機能性をカプセル化できることに注意すべきである。

【0056】

これには、（例えば、温度または圧力測定用の）様々なセンサ、（例えば、バルブまたはドライブの制御用の）アクチュエータまたは制御ループ全体が属する。

【0057】

これらの異なるタイプのＣＣには異なるインタフェースを提供する必要があり、当該インタフェースにはＣＣ機能性が適切に抽象化され得る。この目的のために、１つの構成では、ＭＴＰ規格第３部［７］に記載のインタフェースが提案される。

【0058】

表５．１は、概要を示しており、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８－３に規定の「データオブジェクトのインタフェース」によると

インタフェースファミリ 基本インタフェース（拡張）
アナログ値表示 ＡｎａＶｉｅｗ、（ＡｎａＭｏｎ）
アナログ値演算子 ＡｎａＭａｎ、（ＡｎａＭａｎＩｎｔ）
バイナリ値表示 ＢｉｎＶｉｅｗ、（ＢｉｎＭｏｎ）
バイナリ値演算子 ＢｉｎＭａｎ、（ＢｉｎＭａｎＩｎｔ）
デジタル値表示 ＤＩｎｔＶｉｅｗ、（ＤＩｎｔＭｏｎ）
デジタル値演算子 ＤＩｎｔＭａｎ、（ＤＩｎｔＭａｎＩｎｔ）
文字列表示 ＳｔｒｉｎｇＶｉｅｗ
制御 ＰＩＤＣｔｒｌ
バイナリバルブ ＢｉｎＶｌｖ、（ＭｏｎＢｉｎＶｌｖ）
制御可能バルブ ＡｎａＶｌｖ、（ＭｏｎＡｎａＶｌｖ）
バイナリドライブ ＢｉｎＤｒｖ、（ＭｏｎＢｉｎＤｒｖ）

である。

【0059】

組み込む制御コンポーネントＣＣがサービスコンポーネントＳＣと同じコントローラに存在しない場合、この離れて位置する制御コンポーネントＣＣとの通信も、ＣＡＭＬにより抽象化される。このようにして、ＣＣの実装がどのような態様であるか、またはＣＣがどのコントローラに実装されるか、に依存せずに、サービスコンポーネントＳＣにより、制御コンポーネントＣＣの常に同じ制御を行うことができる。

【0060】

割り当て機能性：
従来技術として知られているアーキテクチャでは、制御モジュールＣＭと制御モジュールタイプＣＭＴとの間の割り当ては、エンジニアリングプロセス中に一度決定され、その後は、制御プログラムを変更することによってのみ、調整され得る。本開示において提案される新しいタイプのアーキテクチャでは、ＣＡＭＬが、制御モジュールＣＣと制御モジュールタイプＣＣＴとの間の設定可能な割り当てを可能にする。このようにして、制御コードを調整する必要なしに、システムに組み込まれたセンサおよびアクチュエータをプラントの稼働時に柔軟に再設定することが可能であることは有利である。このためには、対応する設定・ランタイムインタフェースが必要である。これの前提条件となるのが、制御コンポーネントＣＣのアドレス指定可能性である。

【0061】

通信機能性：
制御コンポーネントＣＣが、それが統合されることが見込まれるサービスコンポーネントＳＣと同じコントローラには実装されていない場合、これら２つのコントローラ間の通信が必要である。この通信機能性は、ＣＡＭＬによって引き受けられ得る。

【0062】

自動化プログラムに分散実装ロジックを統一的に統合するメカニズムを示す。ここで、このロジックの機能的抽象化が、従来のように個々の制御信号に基づいて行われるのではなく、その代わりに、コンポーネントが、標準化されたインタフェースを有する自動化システムによって利用可能になる。これらのインタフェースは、例えば、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８、ＰａｃｋＭＬまたはＯＰＣ ＵＡコンパニオン仕様の記載に基づいてよい。このアプローチにより、プロセスエンジニアリングプラントのモジュール化概念であって、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８に関して既にプロセス機能全体のレベルで実装されているモジュール化概念が、フィールドレベルまたは個々の制御レベルまで拡張される。これは、本開示のメカニズムを、個々の信号とイベントのみに基づくＩＥＣ ６１４９９とも異なるものにする。

【0063】

まとめると、以下の考察から特許請求の主題が得られると言うことができる。

【0064】

個々の制御レベル（アクチュエータ、センサ、コントローラ）は、設備制御レベル（オートメーションサービス）から分離される。

【0065】

個々の制御要素（フィールドデバイス、センサ、アクチュエータ、ＩＯステーション）を自動化エンジニアリングの設備機能から分離するが、実装システムの分離を可能にする。個々の制御要素は、設備機能とは別のプログラマブルロジックコントローラＰＬＣで処理できる。

【0066】

個々の制御レベルのカプセル化は、機能インタフェースを用いて行われる、つまり、従来の信号統合、最近のモノ統合、すなわち、一意に識別可能な物理的オブジェクト、を用いて行われる。

【0067】

今日のシステムにおける個々の制御要素の接続は信号に基づいて行われる。異なる装置は、異なる数の信号（入力信号と出力信号）を用いて接続される。この違いは、例えば、高度に柔軟なシステムにおけるセンサおよびアクチュエータの交換可能性の妨げとなる。機能レベルでのカプセル化により、信号レベルでの違いを常に一定の機能インタフェースの背後に隠蔽するインタフェースが、必要になる。

【0068】

このインタフェースは理想的には標準化されているべきである。この場合、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８－３が考えられる。

【0069】

以下において「コンポーネント抽象化・管理層」（ＣＡＭＬ）とも称される中間層の導入は、信号と同等にいわゆる「モノ」を処理することを約束する。

【0070】

今日のシステムは専用のハードウェア構成に従属し、その一方、この専用のハードウェア構成は決定論的バスシステムを設定するために使用される情報を導出する。より高性能のネットワーク技術に関しては、ＩＰに基づくプロトコルの使用が増加している。ハードウェアとソフトウェアとの間の密結合が解決される場合にのみ、高い柔軟性は達成可能である。この課題を、提案される中間層であるコンポーネント抽象化・管理層ＣＡＭＬが有利に引き受ける。コンポーネント抽象化・管理層ＣＡＭＬは、設備機能（サービスコンポーネント）と個々の制御機能（制御コンポーネント）との間の媒介（英：mediator、独：Vermittler）としての役割を果たす。

【0071】

また、本解決手段を例示的な実施形態において以下に示す。

【0072】

図面を参照して本発明を説明するが、図中に記載されている例示的な実施形態は本発明を限定することを意図するものではない。

【図面の簡単な説明】

【0073】

【図1】図１は、ＯＰＡＳ／ＭＴＰの概念の比較と共に例示的なプラントを示す。

【図2】図２は、転送値との比較を示す。

【図3】図３は、ＣＡＭＬを実装するためのアーキテクチャの変形例を示す。

【図4】図４は、２つの温度センサを備えた例示的な実施形態を示す。

【図5】図５は、比較として、従来技術によるアーキテクチャ概念を示す。

【発明を実施するための形態】

【0074】

図１は、例示的な自動化プラントであって、リアクタＲとリアクタ内の温度を測定するための第１のセンサＳ１とを備える第１の制御ループＰＣＬから構成される自動化プラントを示す。ここでの測定値をコントローラＬ１が受け取る。パイプラインＰを介し、リアクタに含まれる内容物の温度を上昇させる（または場合によっては低下させる）加熱装置Ａを用いて、リアクタＲの内容物をポンプ操作可能である。このパイプラインは第２のセンサＳ２を有し、第２のセンサＳ２はその固有のコントローラＬ２と接続されている。これは第２の制御ループＳＣＬである。

【0075】

例示的な構成において、コントローラと測定データがどのように用いられるかが比較して配置されている。左側において、第１のボックスＯＡには、上記のＯＰＡＳ規格ＯＡによる適用が示されている。入力用機能ブロックＡＩ、出力用機能ブロックＡＯ、制御回路ＰＩＤがある。

【0076】

これに対して右側において、ＭＴＰサービスＭＳによる構成が示されている。ここに含まれている機能ブロックは、ブラックボックスのように外部からはアクセスできず、要素レベルではなく機能レベルにおいてのみアクセス可能であるように、カプセル化される。

【0077】

中央のボックス１１０は、本発明による解決手段であって、モジュール性が様々な段階で可能であることも示す解決手段を示している。左側のボックスＳ１’は、左側のセンサＳ１のみに関係し、右側のボックスＳＣＬ’は、さらなる下位要素ＡＩ、ＰＩＤ、ＡＯを備えるＳＣＬの下位の完全な制御ループに関係する。

【0078】

図２は、２つの制御ループＰＣＬおよびＳＣＬを含む例示的な自動化システムの同じ構造を再度示す。ここでも、ボックスＯＡおよびボックスＭＳは、ＯＰＡＳ規格（信号指向）と各々のＭＴＳ規格（機能指向）による解決手段に関係する。

【0079】

左側には使用される変数、例えば、
-値（Value）、
-エンジニアリングユニット（Engineering unit）、
-範囲（Range）、
-シミュレーション値（Simulation value）または
-シミュレーション状態（Simulation state）、
が示されている。

【0080】

右側にはこれに対応する値
-ＷＱＣ (Ｎａｍｕｒ規格に基づく最下位の品質コード（Worst Quality Code））、
-コマンド（Command）、
-プロシージャ（Procedure）、
-状態（State）、
が示されている。

【0081】

この図は、提案されるコンポーネントにフォーカスした解決手段の相互運用性を示すものであり、様々な可能な実装が示されている。

【0082】

図３は、ＣＡＭＬアプローチの３つの異なる実装変形例を示し、ＣＡＭＬは様々な上記タスクを引き受ける。システムにおいてはこれらの変形例の任意の組合せが可能である。

【0083】

ここで、下位層ＳＡＬ、ＰＡＥ、ＰＡＡおよびＨＷＣは、図５および上述の層と同じである。

【0084】

変形例１：この変形例では、サービスコンポーネントＳＣ１および統合される制御コンポーネントＣＣ２は同じコントローラに実装されている。この場合、コントローラの境界を超える通信は必要とされない。その一方、ＣＣ機能性を、標準化されたインタフェースにマッピングし、ＳＣにおいて所望のＣＣＴ（ＣＣＴｂ）に割り当てることが重要である。このようにして、ＣＡＭＬは抽象化機能性と割り当て機能性を引き受ける。この変形例は公知のアーキテクチャと類似しているものの、ＣＡＭＬが抽象化レベルとして追加されており、これによりＣＣとＣＣＴとの間の設定可能な割り当てが可能であるという違いがある。

【0085】

変形例２：別の変形例では、ＣＣ（ＣＣ１）が示されており、当該ＣＣ（ＣＣ１）は、それが統合されるＳＣ（ＳＣ１）とは別のコントローラに実装されている。この場合、ＣＣ（ＣＣＴ１）とＣＣＴ（ＣＣＴａ）との間でデータを交換するためには、クロスコントローラ通信（英：cross-controller communication、独：controlleruebergreifende Kommunikation）が必要とされる。しかし、本変形例においてこの通信はＣＡＭＬを介してではなく、プロバイダコンシューマアプローチを介して行われる。プロバイダコンシューマアプローチは、プロバイダモジュール（Ｐｒｏｖ）とコンシューマモジュール（Ｃｏｎｓ）を提供する。Ｐｒｏｖは、
以下のようなタスクを有する、つまり、制御モジュールＣＭが標準化されたインタフェースを元々有していない場合に、ＣＣの機能性を、抽象化する、そして、標準化されたインタフェースにマッピングする、というタスクを有する。また、ＰｒｏｖおよびＣｏｎｓは、通信接続を設定するために、そして、それによりＣＣのデータをＳＣが実装されているコントローラにおいて提供するために、用いられる。この場合、Ｃｏｎｓは、ＣＣ機能性を表現しており、あたかもＣＣ自体がこのコントローラに実装されているかのように、使用できる。この通信は、ＣＡＭＬの背後で抽象化される。また、変形例１と同様に、ＣＡＭＬはＣＣ（ＣＣＴ１）とＣＣＴ（ＣＣＴａ）との間の割り当て機能を引き受ける。

【0086】

変形例３：変形例２と同様に、この場合も、サービスコンポーネントＳＣ１および統合される制御コンポーネントＣＣ３は異なるコントローラに実装されている。従って、本変形例においても、クロスコントローラ通信が必要とされる。しかし、この場合、変形例２とは対照的に、この通信機能性はＣＡＭＬ自体により実装される。ＣＣが実装されているコントローラに、ＣＡＭＬが実装されており、当該ＣＡＭＬは、必要に応じて、ＣＣ機能性を標準化されたインタフェースにマッピングする。このＣＡＭＬは、ＳＣが実装されているコントローラのＣＡＭＬと通信できる。このようにして、その一方でＣＡＭＬは、ＣＣの機能性を抽象化すること、及び、標準化されたインタフェースを有するコンポーネントとしてＳＣに対して利用可能にすること、ができる。その後、このコンポーネントは、上述の２つの場合と同様に、ＣＡＭＬによってＣＣＴに割り当てられ得る。従って、この場合、２つのＣＡＭＬは、抽象化・割り当て機能性および通信機能性の両方を引き受ける。

【0087】

主要プログラム（この場合はＳＣ）の観点からすれば、上記変形例の何れがシステムに実装されているかは重要ではない。全ての変形例においてＣＡＭＬによって利用可能になる抽象化機能性によって、ＳＣには、いずれの場合でも、統合可能な、標準化されたインタフェースを有するコンポーネントが提供される。ＣＣがＳＣと同じコントローラに存在する（変形例１）かまたは他のコントローラにアウトソースされているか（変形例２および３）否か、ＣＣが厳密にどのように実装されているかは、ＳＣにとっては重要ではない。このことは、上記変形例の間で柔軟な変更が可能であるという有利な点を提供する。例えば、コントローラ内部に接続されたセンサ（変形例１）に障害が発生した場合には、障害のあるセンサを一時的または継続的に置き換える外部センサを、例えば変形例３を用いて、問題なく接続することができる。

【0088】

設定・ランタイムインタフェース
上述したように、本開示において提案されるアーキテクチャには、サービスコンポーネントのパラメータ化および調整の役割を果たす設定・ランタイムインタフェースも存在する。更に、ＣＡＭＬの設定を引き受けるインタフェースを提供する必要がある。このインタフェースは、どの制御コンポーネントをどのＣＣＴに割り当てるべきか、を決定するために用いられる。このインタフェースは、例えばＯＰＣ ＵＡサーバを用いて、実装できる。

【0089】

図４において、上述の例示的なプラントに基づいて、明示的な実施形態例を、仮想値を用いてより詳細に説明する。以下では、第１の温度センサＣＣＳ１から代替の第２の温度センサＣＣＳ１^＊へと再構成することを意図している。

【0090】

設定は、設定管理ツール４００によって実行され、必要な値は設定ファイル４１９（層Ｆインポート／エクスポートＡＭＬファイル）によって提供される。

【0091】

２つの制御コンポーネント、つまりセンサ１とセンサ１^＊は、ＡｎａＭｏｎプロバイダとしての制御コンポーネントである。

【0092】

「温度調整」（ＳＣ）方法の制御４０３は、分散制御ノード（Distributed Control Node）ＤＣＮ１「リアクタ」によって行われ、当該分散制御ノードＤＣＮ１は、好適なインタフェース４１１、ＡｎａＭｏｎを用いて、センサおよびコントローラＤＣＮ３、ＤＣＮ４と接続する。

【0093】

ＳＣ温度調整コンシューマ
ＡｎａＭｏｎ－Ｃｏｎ．： ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＲＥＡＣ″
ＰＩＤＣｔｒｌ－Ｃｏｎ．： ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＲＥＡＣ″

【0094】

ＳＣ温度調整は、リアクタにおいて実際の温度を検出するためのＡｎａＭｏｎコンシューマと、インレット温度を制御するためのＰＩＤＣｔｒｌコンシューマとを有する。
コンシューマ＝ＣＣ要件／プレースホルダ

【0095】

制御コンポーネント「ＣＣセンサ１」４０１は、以下によりアドレス指定可能なプロバイダを有する。
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．１０：４８４０／ｎｓ＝３：ｓ＝″ＴＩ００１″｝

【0096】

制御コンポーネント「ＣＣセンサ１^＊」４０２は、以下によりアドレス指定可能なプロバイダを有する。
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．１１：４８４０／ｎｓ＝３：ｓ＝″ＴＩ００２″｝

【0097】

制御コンポーネント「ＰＩＤ Ｃｔｒｌ」４０４は、以下によりアドレス指定可能なプロバイダ（提供者）を有する。
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．２０：４８４０／ｎｓ＝３：ｓ＝″ＴＩＣ１０１″｝

【0098】

サービスコンポーネント「温度調整」４０３は、以下によりアドレス指定可能な２つのコンシューマ（ユーザ）を有する。
-リアクタの実際の温度の役割のＡｎａＭｏｎコンシューマ４１１：
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＲＥＡＣ″｝
-リアクタのインレット温度の役割のＰＩＤＣｔｒｌコンシューマ４１２：
｛ｏｐｃ．ｔｃｐ：//１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＥＭＰＣ″｝
サービスのプロバイダ機能は、図中には明示されていない。

【0099】

プロバイダコンシューマ関係を結合するには、対応するパートナにおいて、それぞれ別のアドレスを設定する必要がある。
プロバイダのＡｎａＭｏｎコンシューマ設定：
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．１０：４８４０／ｎｓ＝３：ｓ＝″ＴＩ００１″｝．

【0100】

コンシューマのＡｎａＭｏｎプロバイダ設定：
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＲＥＡＣ″｝

【0101】

プロバイダのＰＩＤＣｔｒｌコンシューマ設定：
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．２０：４８４０／ｎｓ＝３：ｓ＝″ＴＩＣ１０１″｝

【0102】

コンシューマのＰＩＤＣｔｒｌプロバイダ設定：
｛ｏｐｃ．ｔｃｐ：／／１９２．１６８．２．５０：４８４０／ｎｓ＝３：ｓ＝″ＴＥＭＰＣ″｝．

【0103】

このようにして、以下の関係を新規に設定した：
温度調整ＴＲＥＡＣは″ＴＩ００１″を使用する。
温度調整ＴＥＭＰＣは″ＴＩＣ１０１″を使用する。

【0104】

本例では、アクティブな双方向の実装が選択された。つまり、コンシューマとプロバイダはそれぞれ、そのパートナにより処理されることになる値を読み取ったことを意味している（ＯＰＣ ＵＡでは、読み取りは通信のアクティブな部分である）。

【0105】

このようにして、関係は両側でも監視され得る。
相互作用の有効化後、リアクタ温度調整例のカスケード制御は機能した。

【0106】

ＣＡＭＬアプローチの一般化
まとめると、ＣＡＭＬアプローチは、自動化ソフトウェアを、ハードウェア固有のロジック（この場合はＣＣ）と機能固有のロジック（この場合はＳＣ）の、２つの部分に細分化すると言える。ＣＡＭＬは、基本的に、以下のようなタスクを有している、すなわち、ハードウェア固有のロジックを、その具体的な形式およびその実装場所に関して抽象化するような、そして、標準化されたインタフェースを有するコンポーネントの形式で、機能固有のロジックに対して利用可能とするような、タスクを有する。本発明の開示においては、本思想の考えられる実装の１つを、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８のガイドラインに依拠するアーキテクチャに基づいて、示した。

【0107】

しかし、ＣＡＭＬアプローチはモジュール式プラントの概念のみに適用可能であるわけではない。また本発明の開示おいて示される概念は、従来のＰＬＣプログラムにおいても付加価値を提供する。本概念により、その機能が直接的にフィールドで分散インテリジェントとして実装されているインテリジェントデバイスを、迅速、簡潔かつ柔軟に制御コードに統合することが可能になる。

【0108】

そのような分散インテリジェンスの統合メカニズムは、先駆的なものであり、現在の潮流に沿うものである。例えば、産業用モノのインターネット（ＩＩｏＴ（Industrial Internet of Things））のアプローチは、インテリジェントデバイスを用いてセンサおよびアクチュエータのアクセスロジックを直接的にフィールドで実装することに、大きく基づいている。そのため、ＰＬＣプログラムに分散インテリジェンスを統合することは不可欠である。また、オープンプロセスオートメーション規格（Open Process Automation Standard（ＯＰＡＳ））［６］は、自動化機能性を非常に細分化して多数の分散制御ノード（ＤＣＮ）に分散することにますます基づいている。分散インテリジェンスが焦点となり、これに対応する統合メカニズムが必要とされている。

【0109】

産業環境における本開示の概念の将来的な使用に関して、ＣＡＭＬをエンジニアリングするのに有用な選択肢を設計することが必要である。この設計はまだ未解決である。１つのアプローチは、新しいタグタイプの導入である。最近のエンジニアリングツールでは、タグタイプとして、一般的に、入力、出力およびフラグは利用可能である。将来的には、さらに「コンポーネント」のタグタイプが存在する可能性があり、当該タグタイプは、フィールドの分散実装インテリジェントコンポーネントの全てを統合することを可能にする。

【0110】

本開示の導入部では、可変性のための５つのイネーブラ特徴に関して、最近の自動化システムにどのような課題が存在するかを示した。以下では、どのようにしてこれらの課題を本開示のアプローチを用いて解決できるか、改めてまとめる。

【0111】

センサアクセスロジックおよびアクチュエータアクセスロジックの抽象化と、標準化されたインタフェースへのそのマッピングが企図されている。このようにして、例えば、バルブ機能の詳細な実装態様やフィードバック信号の有無に依存することなく、各バルブは同じインタフェースにより表現される。従って、異なるタイプ（例えば、異なるバルブタイプ）のセンサ／アクチュエータは、同じ方法で、自動化システムに統合され得て、普遍性の変更イネーブラに対応する交換可能性が得られる。

【0112】

センサ機能性およびアクチュエータ機能性のより、本開示の対象に基づき、普遍的なインタフェースを用いて、より高性能またはより複雑なセンサおよびアクチュエータを自動化システムに組み込むことも、容易に可能であり、これによりスケーラビリティが支援される。

【0113】

統一的に標準化されたインタフェース（例えば、全てのバルブタイプに「１つの」インタフェース、全てのモータタイプに「１つの」インタフェース）を用いることにより、異なるセンサタイプおよびアクチュエータタイプに渡る互換性を確保することもできる。

【0114】

また、本開示の概念においては、更に、センサとアクチュエータにアクセスするためのロジックの分散実装が提案されている。これによると、このロジックは、直接的にフィールドにおいて、例えば小型コントローラまたはマイクロコントローラ上で、直接的にセンサまたはアクチュエータに実装される。このようにして、センサとアクチュエータは、その制御に必要な全てのロジックを備える。これにより、センサおよびアクチュエータをプラントの別の場所へと移動させることがより容易に可能である。これによりモビリティの変更イネーブラが支援される。

【0115】

ＣＡＭＬアプローチは、標準化されたコンポーネントにおけるセンサ／アクチュエータアクセスロジックの抽象化を実装する。このようにして、モジュール性の概念は、フィールドレベルまたは個々の制御レベルに拡張される。

【0116】

本開示の概念に基づきプロセスプラントの変更イネーブラに関する課題を解決できることが、明らかとなった。従って、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８のアーキテクチャ概念に記載されているような、モジュール式プロセスユニットＰＥＡのレベルのみではなく、個々の制御ユニット、つまり、アクチュエータ、センサおよび制御ループ、のレベルでも、可変性が実現可能である。

【0117】

さらなる有利な点は、センサおよびアクチュエータ用アクセスロジックの提案される分散実装において明らかになる。これは、機能固有のロジック（例えば、ＳＣ）とハードウェア固有のロジック（例えば、ＣＣ）とが分離されていることを含む。この分離により、多くのさらなる有利な点が得られる。

【0118】

機能固有のロジックの再利用性を向上させることができ、機能固有のロジックの更新性を改善することができる。

【0119】

ハードウェアまたはプロセス接続の構成における自由度を向上させることができる。

【0120】

デバイス固有のロジックと機能固有のロジックの分離を導入することにより、両方のロジック部分についてエンジニアリングを、大幅に、互いに独立して行うことができる。

【0121】

これにより、機能指向のロジックは、予めエンジニアリングされ、予めテストされたコンポーネントとして外部に供給され得る。

【0122】

デバイス固有のロジックは、予めエンジニアリングして、デバイスのファームウェアによって、供給され得る。

【0123】

中央計算システム上で機能固有のロジックを実装することにより（例えば、ＯＰＡＳ ＡＣＰを参照）、ハードウェア上で複数の「仮想」モジュール／スキッド／ＰＵを実装することが可能になる。この場合、以下の有利な点が得られる。

【0124】

機械メーカまたはモジュールメーカのコストが削減される。スケーラブルなＰＬＣ資源によって、柔軟性が達成される。デバイス固有のロジックと機能固有のロジックの分離が、様々なデバイスへのロジック部分の分散を可能とする。従来はＰＬＣ資源上で実装されていたロジックの一部を分散してデバイス資源上で実装することにより、デバイス資源を効率的に使用できる。故障が発生した場合、故障したデバイスを簡単に交換できる。

【0125】

標準化されたコンポーネントインタフェースの導入により、分散周辺機器の診断に制限が生じる可能性がある。標準化されたインタフェースにおいても提供されている情報のみをコンポーネントから読み取ることができるに過ぎない。

【0126】

また、迅速かつ容易に分散周辺機器をランタイムに交換することができるので、クロスシステムハードウェア構成（英：cross-system hardware configuration、独：systemuebergreifende Hardware-Konfiguration）がエンジニアリングの時点では最早実装可能ではない。従って、このような柔軟なシステムにおいてハードウェアを構成するための新しいアプローチを作成する必要がある。

【手続補正書】

【提出日】2024-04-03

【手続補正1】

【補正対象書類名】特許請求の範囲

【補正対象項目名】全文

【補正方法】変更

【補正の内容】

【特許請求の範囲】

【請求項1】

少なくとも１つの物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）を含む分散型の自動化システムにて、少なくとも１つの自動化機能を用いて、前記自動化システムの機能制御を前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）と接続するための方法であって、
前記自動化システムが自動化ソフトウェアを有し、当該自動化ソフトウェアが、２つの部分に、すなわち、少なくとも１つの制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）用のハードウェア固有のロジックと少なくとも１つのサービスコンポーネント（ＳＣ）用の機能固有のロジックの２つの部分に、細分化され、
以下のステップ、すなわち、
-前記制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）における前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）の機能性を抽象化し、そして、前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）の実インタフェースを前もって標準化されたインタフェースにマッピングするステップ、
-前記制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）を、前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）と同じ標準化されたインタフェースを有するプレースホルダ（ＣＣＴ）に割り当てるステップ、
-前記少なくとも１つの自動化機能を、前記制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）に対する少なくとも１つの第１のインタフェース（１３３、１３４、１３５）と少なくとも１つのさらなる通信インタフェースとを有する前記サービスコンポーネント（ＳＣ）に、カプセル化するステップ、
-前記制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）と、前記サービスコンポーネント（ＳＣ）または前記プレースホルダ（ＣＣＴ）と、の間の通信を行うステップ、
を備え、
-前記制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）の設定が、前記自動化システムのランタイム中にいつでも、前記通信インタフェース（１００）によって、実行され得る、方法。

【請求項2】

前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）が、前記自動化システムにおけるセンサまたはアクチュエータの機能性を有することを特徴とする、
請求項１に記載の方法。

【請求項3】

前記標準化されたインタフェースが、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８規格に準拠して定義されていることを特徴とする、
請求項１または２に記載の方法。

【請求項4】

前記通信インタフェース（１００）が、ＯＰＣ ＵＡ規格に準拠して動作することを特徴とする、
請求項１～３の何れか１項に記載の方法。

【請求項5】

前記サービスコンポーネント（ＳＣ）が、上位の自動化機能のために、さらなるサービスコンポーネント（ＳＣ１）に対する少なくとも１つのインタフェースを有し、前記上位の自動化機能は前記さらなるサービスコンポーネントにカプセル化された下位の自動化機能にアクセスすることを特徴とする、
請求項１～４の何れか１項に記載の方法。

【請求項6】

分散型の自動化システムにて、少なくとも１つの自動化機能を用いて、前記自動化システムにおける機能制御を連結するための装置（ＣＡＭＬ）であって、前記自動化システムが自動化ソフトウェアを有し、当該自動化ソフトウェアが、２つの部分に、すなわち、少なくとも１つの制御コンポーネント（ＣＣ）用のハードウェア固有のロジックと少なくとも１つのサービスコンポーネント（ＳＣ、ＳＣ１）用の機能固有のロジックの２つの部分に、細分化され、
物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）を含む前記自動化システムにて、
-少なくとも１つの制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）を備えており、当該制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）は、前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）の機能性の抽象化と、前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）の実インタフェースの前もって標準化されたインタフェースへのマッピングと、を有し、前記制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）は、前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）と同じ標準化されたインタフェースを有するプレースホルダ（ＣＣＴ）に割り当て可能であり、
-少なくとも１つのサービスコンポーネント（ＳＣ）を備えており、当該サービスコンポーネント（ＳＣ）は、前記少なくとも１つの自動化機能のカプセル化を有し、前記制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）に対する少なくとも１つのインタフェース（１３３、１３４、１３５）と少なくとも１つのさらなる通信インタフェースとを含み、前記制御コンポーネント（ＣＣ１、ＣＣ２、ＣＣ３）と前記サービスコンポーネント（ＳＣ、ＳＣ１）との間での通信を可能とし、
-前記装置（ＣＡＭＬ）の設定が、前記自動化システムのランタイム中にいつでも、前記通信インタフェース（１００）によって、実行され得る、装置。

【請求項7】

前記物理的要素（Ｓ１、Ｓ２、Ａ、Ｒ）が、前記自動化システムにおけるセンサまたはアクチュエータの機能性を有することを特徴とする、
請求項６に記載の装置。

【請求項8】

前記標準化されたインタフェースが、ＶＤＩ／ＶＤＥ／ＮＡＭＵＲ ２６５８規格に準拠して定義されていることを特徴とする、
請求項６または７に記載の装置。

【請求項9】

前記通信インタフェース（１００）が、ＯＰＣ ＵＡ規格に準拠して動作することを特徴とする、
請求項６～８の何れか１項に記載の装置。

【請求項10】

前記少なくとも１つの制御コンポーネント（ＣＣ２）および関連する前記サービスコンポーネント（ＳＣ、ＳＣ１）が、同じコントローラ（１１０）に実装され、前記制御コンポーネント（ＣＣ２）と前記サービスコンポーネント（ＳＣ、ＳＣ１）との間の通信が、コントローラ内部のインタフェース（１３３、１３４）を用いて行われることを特徴とする、
請求項６～９の何れか１項に記載の装置。

【請求項11】

前記少なくとも１つの制御コンポーネント（ＣＣ１）および関連する前記サービスコンポーネント（ＳＣ、ＳＣ１）が同じコントローラ（１１０）には実装されず、前記制御コンポーネントと前記サービスコンポーネント（ＳＣ、ＳＣ１）との間の通信が、クロスコントローラインタフェースを介してプロバイダコンシューマアプローチを用いて行われることを特徴とする、
請求項６～９の何れか１項に記載の装置。

【請求項12】

前記少なくとも１つの制御コンポーネント（ＣＣ３）および関連する前記サービスコンポーネント（ＳＣ、ＳＣ１）が同じコントローラ（１１０）には実装されず、前記制御コンポーネントと前記サービスコンポーネント（ＳＣ、ＳＣ１）との間の通信がコントローラワイドのインタフェース（１３１、１３２、１３５）を介して行われることを特徴とする、
請求項６～９の何れか１項に記載の装置。

【手続補正2】

【補正対象書類名】明細書

【補正対象項目名】００８５

【補正方法】変更

【補正の内容】

【0085】

変形例２：別の変形例では、ＣＣ（ＣＣ１）が示されており、当該ＣＣ（ＣＣ１）は、それが統合されるＳＣ（ＳＣ１）とは別のコントローラに実装されている。この場合、ＣＣ（ＣＣ１）とＣＣＴ（ＣＣＴａ）との間でデータを交換するためには、クロスコントローラ通信（英：cross-controller communication、独：controlleruebergreifende Kommunikation）が必要とされる。しかし、本変形例においてこの通信はＣＡＭＬを介してではなく、プロバイダコンシューマアプローチを介して行われる。プロバイダコンシューマアプローチは、プロバイダモジュール（Ｐｒｏｖ）とコンシューマモジュール（Ｃｏｎｓ）を提供する。Ｐｒｏｖは、以下のようなタスクを有する、つまり、制御モジュールＣＭが標準化されたインタフェースを元々有していない場合に、ＣＣの機能性を、抽象化する、そして、標準化されたインタフェースにマッピングする、というタスクを有する。また、ＰｒｏｖおよびＣｏｎｓは、通信接続を設定するために、そして、それによりＣＣのデータをＳＣが実装されているコントローラにおいて提供するために、用いられる。この場合、Ｃｏｎｓは、ＣＣ機能性を表現しており、あたかもＣＣ自体がこのコントローラに実装されているかのように、使用できる。この通信は、ＣＡＭＬの背後で抽象化される。また、変形例１と同様に、ＣＡＭＬはＣＣ（ＣＣ１）とＣＣＴ（ＣＣＴａ）との間の割り当て機能を引き受ける。

【国際調査報告】