OPC 統合アーキテクチャ – 日本語百科事典辞書

OPC_Unified_Architecture

「OPC 統合アーキテクチャ」 –
OPC Unified Architecture ( OPC UA ) は、 OPC Foundationによって開発された、センサーからクラウドアプリケーションへのデータ交換のためのクロスプラットフォームでオープンソースの IEC62541 標準です。際立った特徴は次のとおりです。
Companion Specifications を介して OPC Foundation によって公開された、60 種類を超える産業機器用に自由に利用できる標準化されたデータモデル
認証、承認、暗号化、チェックサムを含む拡張可能なセキュリティプロファイル
X.509、トークン、パスワードを含む拡張可能なセキュリティキー管理
クライアント/サーバーとパブリッシュ/サブスクライブの両方の通信パターンをサポート
通信プロトコルに依存しません。TCP/IP、UDP/IP、WebSockets、AMQP、MQTT などの複数の通信プロトコルへのマッピングが指定されています
当初は産業機器 (ディスクリート製造、プロセス製造、エネルギー) とデータ収集および制御用のシステムとの標準化されたデータ交換に成功しましたが、現在は自動化、計量、キッチン機器、およびクラウドアプリケーションの構築にも活用されています。
オープン– OPC Foundation メンバー、非メンバーが GPL 2.0 ライセンスの下で自由に利用できるオープンソースの参照実装
バイナリ (NuGet パッケージ) は、再配布可能なライセンスの下で無料で利用できます
クロスプラットフォーム– 1 つのオペレーティングシステムやプログラミング言語に縛られない
サービス指向アーキテクチャ(SOA)
仕様は OPC Foundation の Web サイトで無料で入手でき、実装を容易にするためにいくつかの部分に分割されていますが、OPC UA スタックベンダーのみがそれらを読む必要があり、エンドユーザーはすべての一般的なプログラミング言語で利用可能な既存の商用および/またはオープンソーススタックを活用するだけです。
コンテンツ
1 歴史
2 仕様
3 UA通信スタック
4 UA セキュリティ
5 組み込みデータ型
6 OPC UA API
6.1 .NET 実装 6.2 Java 実装 7 IEC62541 8 こちらもご覧ください
9 参考文献
10 文学

歴史
OPC UA は同じ組織によって開発されましたが、その前身であるOpen Platform Communications (OPC) とは大きく異なります。Foundation の OPC UA の目標は、産業オートメーションの新たなニーズをより適切に満たす、元のOPC通信モデル (つまり、Microsoft Windows専用のプロセス交換 COM/ DCOM ) から前進する道を提供することでした。
仕様策定作業に 3 年以上、プロトタイプ実装にさらに 1 年を費やした後、統合アーキテクチャの最初のバージョンが 2006 年にリリースされました。
仕様の現在のバージョンは 1.04 （2017 年 11 月 22 日 ) です。OPC UA の新しいバージョンでは、クライアント/サーバー通信インフラストラクチャに加えて、パブリッシュ/サブスクライブが追加されました。
COM/ DCOMへの元のバインディングはOPCの配布に役立ちましたが、いくつかの欠点がありました。
DCOM で頻繁に発生する構成の問題。
構成可能なタイムアウトはありません。
Microsoft Windowsのみ。
セキュリティが低い。
DCOM を制御できません (COM/DCOM は一種のブラックボックスです。開発者はソースにアクセスできないため、バグや不十分な実装に対処する必要があります)。
これらの欠点と他の多くの考慮事項により、COM/DCOM に代わる OPC UA 用の新しい独立したスタックを開発する決定が下されました。この通信スタックの主な特徴は次のとおりです。
移植可能なANSI C、Java、および.NET実装を含むマルチプラットフォーム実装。
スケーラビリティ: スマートセンサーとスマートアクチュエーターからメインフレームまで。
マルチスレッドおよびシングルスレッド/シングルタスク操作 – スタックを組み込みデバイスに移植するために必要。
新しい標準に基づくセキュリティ。
各サービスの構成可能なタイムアウト。
大きなデータグラムのチャンク。
この通信スタックは、さまざまなイノベーションの始まりを反映しています。OPC UA アーキテクチャはサービス指向アーキテクチャ (SOA) であり、さまざまな論理レベルに基づいています。
OPC Base Services は、プロトコルに依存しない抽象的なメソッド記述であり、OPC UA 機能の基礎を提供します。トランスポート層は、これらのメソッドをプロトコルに入れます。つまり、データをシリアル化/逆シリアル化し、ネットワーク経由で送信します。この目的のために、 2 つのプロトコルが指定されています。1 つはハイパフォーマンス向けに最適化されたバイナリTCPプロトコルで、もう 1 つはWeb サービス指向です。
OPC 情報モデルは、ノードに基づくメッシュネットワークです。これらのノードには、あらゆる種類のメタ情報を含めることができ、オブジェクト指向プログラミング(OOP)のオブジェクトに似ています。ノードは、読み取りアクセス (DA、HDA)、呼び出し可能なメソッド (コマンド)、および送信可能なトリガーイベント (AE、DataAccess、DataChange) の属性を持つことができます。ノードは、プロセスデータと他のすべてのタイプのメタデータを保持します。OPC 名前空間には型モデルが含まれています。
クライアントソフトウェアは、サーバーがサポートするプロファイルを確認できます。これは、サーバーが DA 機能のみをサポートしている場合、または追加で AE、HDA などをサポートしている場合に、情報を取得するために必要です。さらに、サーバーが特定のプロファイルをサポートしているかどうかに関する情報を取得できます。OPC UA の新しい重要な機能は次のとおりです。
冗長性のサポート
両方向の接続のハートビート (相手側が「生きている」かどうかを示すため)。これは、サーバーとクライアントの両方が割り込みを認識することを意味します。
データのバッファリングと送信データの確認応答。接続が失われても、データが失われることはありません。失われたデータグラムは再取得できます。
2006 年 10 月にミュンヘンで開催された OPC UA DevCon で、最初のプロトタイプがライブで発表されました。さまざまな UA サーバーが、Beckhoffプログラマブルロジックコントローラーと Euros の組み込みテストボードで示されています。Beckhoff PLC は Windows XP Embedded に基づいており、組み込みコントローラはリアルタイムオペレーティングシステムEurosに基づいています。Embedded Labs Ltd は、64kB RAMを搭載したシングルチップARMマイクロコントローラ上で実行される独自の C++ UA スタックに基づく OPC UA サーバーのデモを行いました。2012 年 10 月、ドイツのフラウンホーファーアプリケーションセンター IOSB-INA と産業情報技術研究所 (inIT) は、OPC UA サーバーが 15 kB の RAM と 10 kB の ROM まで拡張可能であるため、チップレベルで使用できることを示しました。

仕様
OPC UA 仕様はマルチパート仕様であり、次のパートで構成されています。
コンセプト
セキュリティモデル
アドレス空間モデル
サービス
情報モデル
マッピング
プロファイル
データアクセス
アラームと状態
プログラム
歴史的アクセス
発見とグローバルサービス
凝集体 PubSub 安全性
ステートマシン (まだ公開されていません)
エイリアス名
ユーザー認証 (未公開)
辞書参照
さらに、パート 100 デバイスとパート 200 産業オートメーションも利用できます。これらは仕様のコアセットに基づいて構築され、新しい共通の定義が追加され、さまざまな関連仕様で使用されます。たとえば、OPC UA for Analyzer DevicesとOPC UA for Machinery の両方が、パーツ 100 に直接組み込まれています。
COM ベースの仕様とは対照的に、UA 仕様は純粋なアプリケーション仕様ではありません。それらは通常、通信スタックを介して処理される UA 内部メカニズムを記述し、通常、スタックを特定のターゲットに移植するもの、または独自の UA スタックを実装したいもののみに関係します。
OPC UA アプリケーション開発者は、OPC UA API に対してコードを作成するため、主に API ドキュメントを使用します。それでも、パート 3、4、および 5 は、アプリケーション開発者にとって興味深いものになる可能性が

UA通信スタック
UA アプリケーションのアーキテクチャは、それがサーバー部分であるかクライアント部分であるかに関係なく、レベルに構造化されています。
いくつかの部分は、以前の COM プロキシ/スタブに等しくなり、OPC Foundation によって提供されます。移植性レベルは新しいものです。これにより、UA ANSI C スタックを他のターゲットプラットフォームに簡単に移植できます。Windows およびLinux用のポート層も OPC Foundation によって提供されています。

UA セキュリティ
UA セキュリティは、署名による認証と承認、暗号化、およびデータの整合性で構成されます。Web サービスの場合、WS-SecureConversation が使用されるため、.NETおよびその他のSOAP実装と互換性がバイナリバリアントでは、WS-SecureConversation のアルゴリズムに従い、同等のバイナリに変換されています。これは、UA Secure Conversation と呼ばれます。
コードがバイナリである混合バージョンもありますが、トランスポート層は SOAP です。これは、効率的なバイナリコーディングとファイアウォールに適した伝送との間の妥協点です。バイナリコーディングには常に UA Secure Conversation が必要です。認証では、 X.509証明書のみが使用されます。UA アプリケーションがバインドされる証明書ストアの選択は、アプリケーション開発者に依存します。たとえば、Active Directoryの公開鍵基盤(PKI)を使用できます。

組み込みデータ型
OPC UA 標準では、25 の組み込みデータ型が定義されています。
OPC UA の組み込みデータ型
ビルトインタイプ
C/C++ 相当詳細
NodeId タイプ
ブール値
ブール
0/1 (偽または真)
0 (数値)
Sバイト int8_t -128～127
バイトuint8_t 0～255 Int16 int16_t-32768 ～ 32767UInt16 uint16_t 0～65535 Int32 int32_t-2147483648 ～ 2147483647UInt32 uint32_t
0 ～ 4294967295Int64 int64_t-9223372036854775808 ～ 9223372036854775807UInt64 uint64_t
0 ～ 18446744073709551615 浮く浮く
IEEE 単精度 (32 ビット) 浮動小数点値ダブルダブル
IEEE 倍精度 (64 ビット) 浮動小数点値
ステータスコードuint32_t 弦
uint8_t* / std::string
3 (文字列)
日付時刻 int64_t 1601 年 1 月 1 日 (UTC) からの 100 ナノ秒間隔の数 GUID 実装依存
一意の識別子として使用される 16 バイトの数値 4 (GUID) ByteString (文字列と同じ)
5 (バイト文字列) XmlElement (文字列と同じ)
ノード ID
名前空間インデックスと NodeId タイプ ExpandedNodeId (NodeId に類似)
限定名
名前空間のインデックスと文字列
ローカライズされたテキスト
文字列とロケールインジケータ
数値範囲
文字列 (例: 配列の場合は「0:4，1:5」)
変異体(組み込みデータ型のみ) ExtensionObject 任意のタイプのスカラー
データ値
値、タイムスタンプ、およびステータスコードの合成
診断情報
詳細なエラー/診断情報

OPC UA API
UA API は、いくつかのプログラミング言語で利用できます。C、C++、Java、および .NET 用の商用 SDK を利用できます。オープンソーススタックは、少なくとも C、C++、Java、Javascript(node)、Tcl、および Python で利用できます。

.NET 実装
.NET 実装では、下位レベルに ANSI C を使用し、残りを .NET でネイティブに実装します。これは、ソケットの処理のみを意味し、Message-Chunking は ANSI C スタックから統合されます。逆シリアル化は .NET で直接行われるため、直接 .NET 構造とオブジェクトに変換されます。これにより、最初に C 構造体にデシリアライズしてからデータを .NET 構造体にコピーするよりもパフォーマンスが向上します。

Java 実装
Java 用のさまざまなスタックが開発されていました。 .NET と同様に、主に 3 つのバリアントが
JNIを介して完全な ANSI C スタックをカプセル化するため、移植性が複雑になります。スタックはさまざまなオペレーティングシステムに移植できますが、個別にコンパイルする必要がまた、データを JNI 境界にコピーする必要がありますが、逆シリアル化中の C のパフォーマンスの恩恵を受けます。
ネットワーク層で直接コーディングし (現在の .Net 実装と同様)、Java でデシリアライズします。これにより、データコピーの実行が 1 回節約されますが、それでも C スタックに依存します。
ネイティブ Java OPC UA スタックを記述します。これは最も移植性が高いことが観察されましたが、実装には最も多くのエンジニアリング作業が必要であると推定されました。Eclipse Milo プロジェクトは、UA 1.03 クライアントおよびサーバー仕様のピュア Java オープンソース実装を提供します。
または、WebService プロトコルのみをサポートする単純なバリアントがそのためには、 WS-Securityをサポートする SOAP Toolkit が必要です。

IEC62541
IEC 62541 は、 OPC 統合アーキテクチャの標準です。
IEC62541の概要 ID 発売日
タイトル
IEC/TR 62541-1 2016年 OPC 統合アーキテクチャ – パート 1: 概要と概念
IEC/TR 62541-2 2016年 OPC 統合アーキテクチャ – パート 2: セキュリティモデルIEC62541-3 2020年
OPC 統合アーキテクチャ – パート 3: アドレス空間モデルIEC62541-4 2020年
OPC 統合アーキテクチャ – パート 4: サービスIEC62541-5 2020年
OPC 統合アーキテクチャ – パート 5: 情報モデルIEC62541-6 2020年
OPC 統合アーキテクチャ – パート 6: マッピングIEC62541-7 2020年
OPC 統合アーキテクチャ – パート 7: プロファイルIEC62541-8 2020年
OPC 統合アーキテクチャ – パート 8: データアクセスIEC62541-9 2020年
OPC 統合アーキテクチャ – パート 9: アラームと状態IEC62541-10 2020年
OPC 統合アーキテクチャ – パート 10: プログラムIEC62541-11 2020年
OPC 統合アーキテクチャ – パート 11: 履歴アクセスIEC62541-12 2020年
OPC 統合アーキテクチャ – パート 12: 発見とグローバルサービスIEC62541-13 2020年
OPC 統合アーキテクチャ – パート 13: 集計IEC62541-14 2020年
OPC 統合アーキテクチャ – パート 14: PubSubIEC62541-100 2015年
OPC 統合アーキテクチャ – パート 100: デバイスインターフェイス

こちらもご覧ください
OPC データアクセス
プロセス制御用の OLE
OPC財団

参考文献
^ 「OPC Foundation 参照実装」 .
^ 「OPC Foundation 再頒布可能ライセンス」 . ^ マーンケ、ヴォルフガング。Leitner， Stefan-Helmut https://library.e.abb.com/public/75d70c47268d78bfc125762d00481f78/56-61%203M903_ENG72dpi.pdf OPC 統合アーキテクチャ – オートメーションにおける通信および情報モデリングの将来の標準]、2009 年 3 月ABB レビュー 3 /2009、ページ 56-61
^ 「統合財団 – OPC 財団」 . OPC財団。2021年12月13日閲覧。
^ 「メンバー」 . ^ 世界最小のOPC UAサーバーはドイツから ^ Massaro， Simone OPC UA とは何ですか? また、それはあなたの世界にどのように影響しますか? 、2008 年 5 月 15 日、 planetengineering.com
^ 「任意の JVM ベースのプロジェクトにおける OPC 統合アーキテクチャ (UA) クライアントおよび/またはサーバー機能」 . 2016 年 2 月 26 日。2016 年8 月 22 日閲覧。
^ 「IEC 62541 の IEC ウェブストア」. 2018年6月1日閲覧。

文学
Wolfgang Mahnke、Stefan-Helmut Leitner、Matthias Damm: OPC 統合アーキテクチャ。スプリンガー社 2009 年。
ISBN 978-3-540-68898-3
Lange， J.、Iwanitz， F.、Burke， T. OPC From Data Access to Unified Architecture 2010;
ISBN 978-3-8007-3242-5 ·