OPC UA（IEC 62541）による産業データ相互運用アーキテクチャ

1. 概要

A. 定義

OPC UA（Open Platform Communications Unified Architecture）は、産業オートメーション機器とアプリケーションの間でデータを安全に交換し、その構造と意味を表現するプラットフォーム非依存の通信・情報モデリング標準である。

産業現場には世代やメーカーの異なるPLC、CNC、センサー、SCADA、MES、ERPが共存する。通信方式だけでなく、タグ名、単位、状態コード、設備階層も異なる。そのため、接続しただけでは両システムが値を同じ意味に解釈するとは限らない。 OPC UAは通信仕様と情報モデルを組み合わせ、信号伝達から意味的相互運用へ拡張する。

従来のOPC ClassicはWindows COM/DCOMへの依存が強かった。異種OS、ファイアウォール通過、インターネット規模の展開に制約があった。 OPC UAはOSと言語に中立な構造でこれらを改善する。組込み機器、現場サーバー、クラウドまで同じ基盤を利用できる。中核は単一のトランスポートプロトコルではない。情報モデル、サービス、メッセージ構造、通信マッピング、セキュリティ、適合性規則をまとめたアーキテクチャである。

B. 背景と必要性

スマート製造では設備、生産、品質、エネルギーのデータをシステム横断で統合する。設備更新や拠点拡大のたびに個別ドライバーを作ると統合費用が累積する。特定ベンダーへの依存も強まる。 OPC UAのアドレス空間と標準サービスは個別接続を減らし、データ再利用性を高める。

産業データには数値だけではなく、工学単位、品質状態、時刻、設備階層が必要である。例えばTemp=72だけでは摂氏か華氏か、どのセンサーの値か、正常値か判断できない。 OPC UAは変数、型、参照、メタデータを情報モデルで表し、利用側が意味を探索できるようにする。

OT接続の拡大は安全性と可用性のリスクも高める。アプリケーションの識別、暗号化、署名、ユーザー権限、監査機能をネットワーク設計と運用方針に組み込む必要がある。したがってOPC UA導入はプロトコル選定ではなく、OT・ITデータアーキテクチャとセキュリティガバナンスの設計課題である。

2. 標準構造と情報モデル

A. 階層構造

OPC UAは情報モデル、サービス、メッセージモデル、通信マッピング、セキュリティ、適合性の枠組みとして理解できる。この分離により、情報モデルを保ちながら環境に適した通信方式を選べる。 IEC 62541シリーズは概念、セキュリティ、アドレス空間、サービス、情報モデル、マッピング、プロファイルなどを複数の規格に分けている。

flowchart TB
  A[企業アプリ: MES·分析·クラウド] --> B[OPC UA Client / Server]
  B --> C[Services: Browse·Read·Write·Subscribe]
  C --> D[AddressSpace: Objects·Variables·Methods·Types]
  D --> E[Information Model·Companion Specification]
  B --> F[SecureChannel·Session·証明書·権限]
  F --> G[通信マッピング: UA TCP·HTTPS·PubSub]
  G --> H[PLC·ロボット·センサー·現場ゲートウェイ]

アプリケーションは標準サービスを呼び出し、アドレス空間を探索して値を読み書きし、通知を購読する。アドレス空間は設備、工程、変数、メソッド、型をノードと参照で表すグラフである。通信マッピングはネットワーク上でメッセージを運ぶ方法を定義する。情報の意味と通信技術を分離できる。

B. アドレス空間と意味モデル

NodeはOPC UAが管理する情報単位である。ノードクラスにはObject、Variable、Method、型定義などがある。 Variableは現在値だけでなく、型、アクセスレベル、工学単位、説明、品質、時刻を持てる。 Objectと参照は工場、ライン、設備、構成部品の階層を表す。利用側は固定タグ一覧ではなく階層を探索できる。

NodeIdはアドレス空間内のノードを識別する。 Namespace URIは異なるベンダーのモデル識別子の衝突を抑える。 QualifiedNameは名前と名前空間を組み合わせる。参照タイプは構成、型、状態などノード間の関係を示す。これらがなければ、二社のPressure変数が同じ意味かアプリケーションが推測しなければならない。

基本情報モデルは汎用的な構成要素を提供する。 Companion Specificationは業界で共有する意味を標準化する。機械、ロボット、プロセス産業のモデルにより、異なるメーカーの設備を共通の方法で発見・利用できる。ただしCompanion Modelへの対応だけで現場の意味が完全に一致するわけではない。バージョン、任意項目、単位、実装差を試験し、企業データ辞書へのマッピングを管理する必要がある。

C. モデル中心とタグ中心の比較

従来のタグインターフェースでは、アプリケーションがタグ名とアドレスを事前に知る必要がある。設備モデルが変わるとアプリケーションコードの変更が必要になる場合がある。情報モデルの利用側は型と参照を探索し、設備の属性と関係を発見できる。統合は点対点タグ変換から、標準意味を解釈するアプリケーションへ移行する。

比較軸	タグ中心の連携	OPC UA情報モデル中心
表現	アドレス・タグ名・値	型・関係・メタデータ
発見	別一覧・手動マッピング	Browse・型探索
変更影響	アドレス変更でコード修正	モデル・名前空間変更を管理
意味の一貫性	個別プロジェクトの命名規則	共通モデル・Companion Spec
トレードオフ	初期は簡単、統合費用が増加	モデリングが必要、再利用性向上

この違いは単なるデータ形式の豊富さではない。企業が工程知識をデータ契約として管理するか、設備固有の実装詳細に依存するかの違いである。小規模で固定的な設備なら単純なタグが経済的なこともある。多拠点・多ベンダー分析ではモデルの再利用効果が高まる。

3. 通信モデルとデータ伝達

A. Client-Serverサービス

Client-ServerモデルではServerがアドレス空間とサービスを提供し、ClientがBrowse、Read、Write、Call、Subscribeなどを利用する。 Browseはノードと参照を探索する。 Readは値とメタデータを取得する。 WriteとCallは許可された変更や動作を要求する。 SubscriptionとMonitoredItemは値やイベントの変化通知を支援する。短い間隔で全データを繰り返し取得する負荷を抑える。

接続は通常、エンドポイント探索、セキュリティポリシー選択、SecureChannel確立、ユーザー認証、Session生成、サービス要求の順に進む。 ClientはServer証明書を検証する。 ServerもClientアプリケーションの信頼性を確認する。 Sessionはユーザーと権限の文脈を提供する。 Channelはメッセージの機密性と完全性を保護する。

Client-Serverは設定、オンデマンド照会、双方向制御に適している。一方、多数の利用側と機器が直接接続するとSession数と運用負荷が増える場合がある。遅延、配信保証、接続数、運用統制を考慮してPubSubと役割を分担する。

B. PubSub通信

Publish-Subscribe（PubSub）ではPublisherがデータを発行し、Subscriberが関心のあるデータセットを受け取る。両者は直接の要求・応答を行わなくてもよい。ブローカー型ミドルウェアまたはブローカーなしの配信で多くの機器に情報を配布できる。 OPC UA PubSubのメッセージモデルにはデータセット、NetworkMessage、Publisher識別子、セキュリティ設定などが含まれる。

sequenceDiagram
  participant D as PLC·設備 Publisher
  participant C as OPC UA Client
  participant B as MQTT BrokerまたはUDP網
  participant S as 分析 Subscriber
  C->>D: セキュアチャネル確立・モデル探索
  D-->>C: アドレス空間・設定を提供
  D->>B: PubSub NetworkMessageを発行
  B->>S: 購読条件に従い配信
  S->>S: データセットを復号・検証・保存

Client-ServerとPubSubは競合ではなく補完関係にある。設定やモデル探索にClient-Serverを使い、高頻度の一対多配信にPubSubを使える。産業ネットワークでは遅延、損失、重複が起こり得る。受信側でシーケンス、タイムスタンプ、品質状態、受信時刻を検証する。

C. 通信方式とプロファイル選定

OPC UAは産業用バイナリ通信、Web指向、メッセージ指向など複数の通信マッピングを支援する。機器性能、ファイアウォール、ブローカー、ネットワーク遅延、相互運用試験、セキュリティ運用能力で選定する。 MQTTやAMQPとのブローカー連携は企業・クラウドへの非同期伝達に有効な場合がある。小型組込み機器ではCPU、メモリー、証明書管理が制約となることもある。

複数のプロファイルと通信方式は柔軟性を高める一方、対応組合せの違いで接続問題が起こる。調達仕様には「OPC UA対応」だけではなくClient/Serverの役割、Companion Model、セキュリティポリシー、通信プロファイル、診断機能を明記する。適合性試験に加え、実機間の相互運用試験が必要である。

4. セキュリティと運用設計

OPC UAセキュリティは暗号化だけではない。アプリケーション識別、ユーザー権限、証明書ライフサイクル、ネットワーク分離、監査証跡を含む。 Client-ServerのSecureChannelはメッセージ署名・暗号化を提供できる。ユーザー認証は運用方針に応じてアカウント、証明書、トークンなどを用いる。セキュリティモードを無効にしたり信頼リストを過剰に広げたりすると、標準機能があっても防御は弱くなる。

証明書には初期登録、更新、期限切れ、失効、バックアップ、信頼ストア更新のライフサイクル管理が必要である。数千台の機器に手動で配布すると、期限切れ障害や誤った信頼登録を招く。自動プロビジョニングと一元的な可視化が役立つ。証明書更新は生産停止に影響し得るため、重複運用、ロールバック、期限アラートを計画する。

権限は最小権限と資産重要度に従う。読み取り専用の収集IDと設定・制御IDを分離する。危険なMethod実行には運用者承認や安全インターロックを設ける。データ収集のみのシステムにWrite権限を与えない。共有アカウントと初期パスワードを廃止する。

PubSubではメッセージ署名・暗号化、SecurityGroup、鍵配布、Subscriber検証を設計する。ブローカーTLSとメッセージ保護は異なる信頼境界を扱う場合がある。境界ごとの要求を分けて定義する。 DoS、不正メッセージ、再送、過剰購読による資源枯渇に速度制限と資源分離で対応する。

OTセキュリティはパッチ適用時間が限られる機器の現実も考慮する。工場網を企業網から分離し、産業DMZゲートウェイでデータの流れを制御する。承認済みの経路と宛先だけ通信を許可する。収集データ経路と制御コマンド経路を分離する。ログ、時刻同期、バックアップ、復旧を含む事故対応を訓練する。

5. 比較と適用事例

A. OPC UA、MQTT、Modbus

Modbusは単純なレジスターの読書きと広いレガシー対応が利点である。複雑な設備意味、認証、暗号化には別の統制が必要となる場合が多い。 MQTTは軽量なPubSub伝達とブローカー環境が強みである。トピックやペイロードの意味はアプリケーション契約で管理する。 OPC UAは情報モデルとセキュリティを統合するが、モデル化や証明書運用の負荷は大きい。

比較軸	OPC UA	MQTT	Modbus
強み	モデル・サービス・セキュリティ	軽量な非同期メッセージング	レガシーの単純なレジスター連携
データ意味	型・参照・情報モデル	トピック・ペイロード契約に依存	アドレス意味を別途文書化
通信パターン	Client-Server、PubSub	PubSub	主に要求・応答
留意点	モデル・証明書・プロファイル互換	ブローカー・トピック・スキーマ統制	セキュリティ補完・アドレス記録

現場では単一技術へ統一せず、レガシー接続にModbusゲートウェイ、企業イベントにMQTT、設備サービスと意味モデルにOPC UAを使う組合せが現実的である。ゲートウェイは変換とセキュリティの集中点となる。障害分離、原データ保持、品質メタデータ伝達を設計する。

B. 仮想スマート製造の事例

仮想工場にCNCと組立設備が120台あり、各設備が毎秒10個の状態値を送ると仮定する。個別タグ方式では名称、単位、状態コードを工場ごとに対応づける。新設備の追加で分析アプリケーションの変更が必要になる場合がある。 OPC UAサーバーで設備型、変数、単位、品質状態をモデル化すれば、MESと分析Subscriberが定義を再利用できる。

収集用Consumerには読み取り専用権限を与える。制御アプリケーションは別資格情報を用い、運用者承認後に限定Methodだけを呼び出す。生データをすべてクラウドに送る代わりに、エッジゲートウェイで異常を要約できる。品質分析に必要な時間帯だけ生信号を保管する。この例は設計の仮定であり、規範的な処理量目標ではない。実際の遅延と容量目標は機器仕様と工程リスク分析から定める。

C. エネルギー・ビル運用

ビル管理システムにはボイラー、空調機、電力計、環境センサーがある。機器ごとに通信方式とデータモデルが異なる場合がある。運用者は階、区画、設備関係、単位をOPC UAアドレス空間に表せる。エネルギー分析システムはモデルを探索して負荷を集計できる。複数ビルでモデルと命名規則を統一すると、エネルギー原単位比較と異常検知が一貫する。

6. 発展論点：OT・ITデータファブリックでの役割

OPC UAはPLCとMESのプロトコル変換にとどまらない。設備モデルを企業データ基盤へ伝えるエッジデータ契約として利用できる。現場ゲートウェイはアドレス空間探索、品質正規化、時刻同期、メッセージバッファ、アクセス制御を担う。上位分析システムはモデルから設備を発見し、共通属性で指標を計算する。

業界モデルをそのまま統合しても、すべての意味衝突が解消するとは限らない。例えばStateが生産中、停止、故障、待機のどれを意味するかは拠点で異なり得る。 Companion Modelをデータカタログ、単位標準、資産階層に接続する。業務上の意味を統制する必要がある。

大規模導入ではモデル版とサーバー機能プロファイルを資産台帳に登録する。スキーマ変更は本番設備へ反映する前に互換性試験を通す。ゲートウェイで旧版と新版を一定期間併用すれば、Consumerの移行を管理できる。ただし重複運用のセキュリティ・性能コストも評価する。

性能試験では平均遅延だけを測定してはならない。収集周期、同時購読数、通知集中、ネットワーク断後の再接続、証明書検証、サーバー再起動を試験する。 p95/p99遅延とデータ欠落を測る。制御経路では最悪遅延と安全インターロックを検証する。分析経路と制御経路に同じサービスレベルを仮定しない。

規格版は調達・開発時点で公式カタログを確認する。 IECカタログにはOPC UAの概要・概念を扱うIEC 62541-1:2025が2025年12月19日発行として掲載されている。他のパートは版や改訂時期が異なるため、適用パートごとに現行版とプロファイルを確認する。

7. 考慮事項と示唆

A. 意味モデルのガバナンス

モデルが豊富でも設備属性、単位、品質コードが不統一なら相互運用性は低い。参照モデル、名前空間、版管理、必須属性、品質規則を企業標準にする。供給者契約にも反映する。

B. セキュリティ優先設定

本番現場で初期設定を放置してはならない。証明書信頼、ユーザー権限、暗号方針、監査ログを導入前に確認する。読み取り収集と制御を分離する。資産重要度に応じ許可経路を最小化する。

C. 安全と可用性の分離

一般的なOPC UA通信が機能安全システムや決定論的制御を自動的に代替すると考えてはならない。安全機能は適用される安全規格に従って検証する。通信障害時の安全状態と手動運転手順を定義する。

D. 相互運用試験

標準対応というベンダー宣言だけでは実機間の互換性を保証しない。役割、ポリシー、モデル版、通信マッピング、エラー処理、再接続を調達・検収試験に含める。複数ベンダー間の相互運用試験を行う。

E. 証明書・鍵の運用

機器識別と鍵ライフサイクルの責任者を明確にする。期限、失効、侵害対応を自動化する。個別証明書と工場共有鍵を区別する。鍵侵害時の影響Publisher・Subscriberを特定できるようにする。

F. ブラウンフィールドの段階移行

PLCとSCADAを一斉に置き換えることは避ける。まず読み取り中心のゲートウェイ接続から始める。品質・セキュリティ・可用性を確認して範囲を広げる。変換規則、元タグ、データ欠損の可能性を記録する。新モデルが既存運用を壊さないようにする。

G. 技術士の導入ロードマップ

第1段階：資産、プロトコル、データフロー、制御重要度を調査する。結果を用いてリスクに基づく適用範囲を定める。第2段階：優先設備のモデル、セキュリティプロファイル、証明書運用、相互運用試験を定義する。第3段階：現場ゲートウェイと企業基盤を接続する。データ品質、運用可視性、復旧性を検証する。第4段階：モデルカタログ、変更承認、脆弱性管理、証明書ライフサイクルで複数拠点展開を標準化する。

技術士は成果を接続機器数ではなく、再利用可能な意味モデル、統合保守費用、データ信頼性、安全・セキュリティリスクの低減で評価する。調達要件、アーキテクチャ、セキュリティ運用、試験証跡を追跡可能なガバナンスに統合する。

参考資料

OPC Foundation, “OPC UA Overview” — https://opcfoundation.org/about/opc-technologies/opc-ua/
OPC Foundation, “OPC UA Part 1: Overview and Concepts” — https://reference.opcfoundation.org/specs/OPC-10000-1/full
OPC Foundation, “OPC UA Part 2: Security Model” — https://reference.opcfoundation.org/specs/OPC-10000-2/4
OPC Foundation, “OPC UA Part 14: PubSub Concepts” — https://reference.opcfoundation.org/specs/OPC-10000-14/5
IEC, “IEC 62541-1:2025 — OPC unified architecture — Part 1: Overview and concepts” — https://webstore.iec.ch/en/publication/81513

一言まとめ: OPC UAは安全な通信と探索可能な産業情報モデルを組み合わせ、IEC 62541のClient-ServerとPubSubを現場要件に応じて選択し、異種OTデータの相互運用を実現する。