OPC DAとは？OPC UAとの違いと移行ポイント

古い設備のデータを集めようとしたとき、突然「OPC DA」という名前が出てくることがあります。

PLCやSCADAの画面では問題なく値が見えているのに、別のPCや新しいシステムへ渡そうとするとつまずく場面があります。

その背景には、OPC DAがWindowsのCOM/DCOM技術を前提にした、いわゆるOPC Classic系の仕組みであることが関係しています。

一方で、現在の設備データ連携ではOPC UAが使われることも増えており、両者の違いを整理しないと移行方針を誤りやすくなります。

本記事では、OPC DAの基本、OPC UAとの違い、既設設備から安全に移行するための考え方を解説します。

1. OPC DAとは：既設設備で使われるデータアクセス技術

OPC DAは、OPC Data Accessの略です。

主にPLCやDCS、計測機器などの現在値を、監視ソフトや上位アプリケーションへ渡すために使われてきました。

ここでいう現在値とは、温度、圧力、運転状態、異常フラグ、カウンタ値などのリアルタイムなプロセスデータです。

OPC Foundationの説明では、OPC DAは値、時刻、品質情報を含むデータ交換を定義する仕様として位置づけられています。

そのため、単なる数値の受け渡しではなく、その値がいつの値か、信頼できる状態かも扱える点が重要です。

OPC Classicの一部としてのOPC DA

OPC DAは、OPC Classicと呼ばれる古いOPC仕様群の一つです。

OPC Classicには、現在値を扱うOPC DA、アラームやイベントを扱うOPC AE、履歴データを扱うOPC HDAなどがあります。

現在値を読み書きしたい場合に使われる代表がOPC DAです。

例えば、監視PCが「タンク水位」「ポンプ運転中」「ヒータ出力率」といったタグを周期的に読み取る用途に使われます。

設備の監視画面やデータ収集ソフトの裏側で長く使われてきたため、既設ラインでは今でも見かける機会があります。

OPC DAが解決してきた課題

OPC DAが普及する前は、PLCメーカーや装置ごとに専用ドライバを用意する必要がありました。

監視ソフト側は、対象機器の通信仕様に合わせて個別対応する必要があり、保守性が悪くなりやすい構造でした。

OPC DAを使うと、機器側の違いをOPCサーバが吸収し、クライアントは共通の形式でデータにアクセスできます。

つまり、PLCや装置の通信を直接扱うのではなく、OPCサーバを介してタグを読む構成にできます。

この考え方は、現在のSCADAや設備データ収集の基礎にもつながっています。

2. OPC DAの基本構成：サーバ・クライアント・タグ

OPC DAは、OPCサーバとOPCクライアントの関係で動作します。

サーバという言葉が出てきますが、必ずしも大型のサーバ機を意味するわけではありません。

PLC通信ドライバを持つソフトウェアが、Windows PC上でOPC DAサーバとして動作することもあります。

クライアント側は、SCADA、データロガー、生産管理連携ソフト、Excel連携ツールなどです。

OPCサーバ：機器固有通信を吸収する窓口

OPCサーバは、PLCやリモートI/O、計測機器などからデータを読み取り、OPC DAの形で公開します。

現場側の通信は、メーカー独自プロトコル、Modbus、Ethernet系通信、シリアル通信などさまざまです。

OPCサーバは、それらの違いを吸収して、上位ソフトへ共通のタグとして見せます。

現場機器を直接理解しなくても、クライアント側はタグ名を指定して値を取得できます。

この分離により、監視ソフトの変更とPLC通信の変更を切り分けやすくなります。

OPCクライアント：タグを読み書きする利用側

OPCクライアントは、OPCサーバが公開するタグを読み書きする側です。

例えば、監視画面はモータ運転中のタグを読み取り、画面上のランプ表示に反映します。

データ収集ソフトは、温度や圧力のタグを一定周期で読み取り、CSVやデータベースへ保存します。

操作指令を書き込む構成では、クライアントからOPCサーバ経由でPLCの制御タグへ値を書き込むこともあります。

ただし、書き込みは誤操作や権限管理の影響が大きいため、読み取り以上に慎重な設計が必要です。

タグ：設備データの名前付き入口

OPC DAでは、データ項目をタグとして扱います。

タグには、ポンプ運転状態、温度現在値、圧力上限警報、積算流量などの意味を持たせます。

PLC側のアドレスはD100やM10のような内部表現でも、上位側では分かりやすいタグ名にできます。

このタグ設計が雑だと、あとからMESやデータ分析へつなぐときに意味が分かりにくくなります。

設備データ活用を考える場合は、タグ名、単位、スケール、設備名、信号の意味をそろえることが大切です。

3. OPC DAで扱うデータ：値・時刻・品質

OPC DAを理解するうえで重要なのは、値だけを読む仕組みではないという点です。

OPC DAのデータは、代表的には値、タイムスタンプ、品質情報を組み合わせて扱います。

温度が50℃と表示されていても、それが正常に取得された最新値なのか、通信異常後の古い値なのかで意味は変わります。

この違いを見分けるために、値の周辺情報を合わせて扱う必要があります。

値：設備状態を表す中心データ

値は、OPC DAで最も分かりやすいデータです。

デジタル信号ならON/OFF、アナログ信号なら温度や圧力、数値設定なら速度指令やしきい値になります。

PLCから見れば内部デバイスやレジスタの値ですが、OPC DAではタグの値として公開されます。

監視用途では、値の変化を画面表示、トレンド、帳票、アラーム判定に使います。

制御用途に近い書き込みでは、運転許可、設定値変更、モード切替などの重要操作にも関係します。

タイムスタンプ：いつの値かを示す情報

タイムスタンプは、そのデータがいつの時点の値かを示す情報です。

設備ログを後から解析するとき、時刻がずれていると原因と結果の順番を誤解しやすくなります。

例えば、異常信号が先に出たのか、圧力低下が先に起きたのかで、判断すべき原因は変わります。

OPC DAのデータを収集する場合も、PC時刻、PLC時刻、データベース保存時刻の違いを意識する必要があります。

時刻同期の考え方は、設備ログを扱うタイムスタンプ設計でも重要になります。

品質情報：その値を信用できるかの判断材料

品質情報は、その値が正常に取得できているかを示す判断材料です。

通信断、デバイス異常、アドレス不正、スケール異常などがあると、値そのものは残っていても信用できない場合があります。

画面表示で値だけを見ていると、通信が切れた後の最後の値を正常値と誤認する危険があります。

そのため、監視画面やデータ収集では、品質情報を無視しない設計が必要です。

データベースへ保存する場合も、値だけでなく品質や取得状態を一緒に残すと、後の異常解析に役立ちます。

4. DCOMが難所になる理由：OPC DAのつまずきやすい点

OPC DAで最もつまずきやすいのは、WindowsのCOM/DCOMを前提にしている点です。

ローカルPC内でOPCサーバとクライアントを動かすだけなら、比較的簡単に接続できる場合があります。

しかし、別PCからネットワーク越しに接続しようとすると、ユーザー権限、ファイアウォール、DCOM設定が絡みます。

このため、OPC DAは「動けば便利だが、設定で詰まりやすい」技術として扱われることがあります。

Windows依存：OS設定の影響を受けやすい

OPC DAは、Microsoft Windows技術であるCOM/DCOMを利用するOPC Classic系の仕様です。

そのため、OPC UAのように最初からプラットフォーム非依存を狙った仕組みとは性格が異なります。

Windowsのバージョン、ユーザーアカウント制御、サービス実行ユーザー、セキュリティ更新の影響を受けることがあります。

以前は動いていたOPC DA接続が、PC更新やドメイン変更後に接続できなくなる例もあります。

既設設備で使い続ける場合は、OS更新やPC更新を通信設定の変更リスクとして管理する必要があります。

ファイアウォール：通信経路を説明しにくい

OPC DAのDCOM通信は、単純な固定ポート通信として説明しにくい場合があります。

ネットワーク機器やファイアウォール越しに接続する場合、通信に必要な許可設定が複雑になりがちです。

現場の保全担当者から見ると、PLCとは通信できるのにOPCだけ通らないという状態に見えることがあります。

これはOPC DAサーバとクライアントの間に、WindowsのDCOM通信設定が入っているためです。

セキュリティを強化したネットワークでは、OPC DAを広い範囲に直接通す設計は避けた方が安全です。

権限設定：接続できても読めないことがある

OPC DAでは、DCOMの起動権限、アクセス権限、実行ユーザーが接続可否に影響します。

同じPC名、同じIPアドレスでも、ユーザー権限が変わると接続できない場合があります。

また、OPCサーバがWindowsサービスとして動くのか、ログオン中のユーザーアプリとして動くのかでも挙動が変わります。

一度動いた設定を手順書に残さないと、PC交換時に再現できなくなりやすい点に注意が必要です。

OPC DAを維持する場合は、OPC設定だけでなくWindows側の設定も保守対象として扱いましょう。

5. OPC DAとOPC UAの違い：古い新しいだけではない

OPC DAとOPC UAの違いは、単に古いか新しいかだけではありません。

OPC DAはOPC Classicの一部であり、主に現在値のデータアクセスを扱います。

OPC UAは、OPC Classicの各機能を一つの拡張可能な枠組みに統合する考え方で作られています。

そのため、通信方式、データモデル、セキュリティ、プラットフォーム依存性が大きく異なります。

通信基盤：COM/DCOMとUA通信の違い

OPC DAは、COM/DCOMを利用したWindows中心のアプリケーション連携として使われます。

一方、OPC UAはプラットフォーム非依存のサービス指向アーキテクチャとして位置づけられています。

この違いにより、OPC UAはWindows以外の環境、組込み機器、サーバ、クラウド連携でも扱いやすくなります。

もちろん、OPC UAを使えば設計不要になるわけではありません。

証明書、エンドポイント、名前空間、セキュリティポリシーなど、OPC DAとは別の設計項目が増えます。

データ表現：タグ中心と情報モデル中心の違い

OPC DAでは、設備データはタグの一覧として扱われることが多くなります。

タグ名と値を読めれば監視はできますが、そのタグがどの設備の何を意味するかは別途管理が必要です。

OPC UAでは、ノード、階層、属性、参照関係を使って、データの意味をより構造的に表現できます。

例えば、設備、ユニット、センサ、測定値、単位、状態を階層的に整理できます。

これはMESやデータ分析基盤へデータを渡すときに有利です。

比較表：現場で見るべき違い

項目	OPC DA	OPC UA
世代	OPC Classic系	Unified Architecture
主な用途	現在値の読み書き	データ連携、情報モデル、監視、履歴、イベント
基盤技術	COM/DCOM	プラットフォーム非依存のサービス指向アーキテクチャ
接続で詰まりやすい点	DCOM、権限、ファイアウォール	証明書、エンドポイント、セキュリティ設定
向いている場面	既設Windows設備の延命	新規データ連携、上位連携、標準化

この表から分かる通り、OPC DAは既設設備での実用性が強く、OPC UAは将来の拡張性に向いた技術です。

どちらか一方だけを覚えるのではなく、既設設備では両者を橋渡しする発想が必要になります。

関連記事

instant.engineer

6. 既設設備でOPC DAが残る理由：移行前に理解すべき現実

OPC UAが増えているからといって、すべてのOPC DAをすぐ置き換えられるわけではありません。

既設設備では、監視ソフト、PLCドライバ、帳票ソフト、古いWindows PCが一体で動いていることがあります。

このような環境では、通信だけを単純に入れ替えると、画面表示や帳票、アラーム履歴に影響する可能性があります。

移行の第一歩は、古いから消すのではなく、どこで何に使われているかを棚卸しすることです。

PLCやSCADAとの結びつきが強い

OPC DAは、PLCとSCADAの間で現在値を受け渡す用途に多く使われてきました。

PLC側のデバイスアドレスをOPCサーバが読み取り、SCADAやHMIが画面表示に使う構成です。

この構成では、OPC DAサーバが止まると監視画面の値が更新されなくなります。

また、データ収集ソフトが同じOPC DAサーバを参照している場合、監視と収集が同時に影響を受けます。

既設設備を調べるときは、どのクライアントがどのOPCサーバを参照しているかを図にすることが有効です。

専用ドライバ資産を捨てにくい

古い設備では、PLCメーカー専用の通信ドライバを持つOPC DAサーバが使われている場合があります。

このサーバが安定して動いている場合、短期的には置き換えよりも延命の方が現実的なことがあります。

特に、装置停止が難しいラインでは、通信方式の変更だけでも大きなリスクになります。

ただし、古いPCや古いOSへ依存し続けると、故障時の復旧が難しくなります。

延命する場合でも、バックアップ、設定手順、代替PC、ライセンス状態を確認しておく必要があります。

7. OPC DAからOPC UAへの移行ポイント

OPC DAからOPC UAへの移行は、一度に全更新する方法だけではありません。

既設設備では、停止リスクを抑えるために、段階的な移行やゲートウェイ利用が現実的です。

重要なのは、OPC DAを悪者として扱うのではなく、どの範囲を残し、どの範囲をUA化するかを決めることです。

その判断には、設備停止リスク、データ活用の目的、ネットワーク分離、保守期限を合わせて考える必要があります。

Step 1：現在の接続関係を棚卸しする

最初に行うべきことは、OPC DAサーバとクライアントの接続関係を整理することです。

どのPCにOPCサーバがあり、どのPLCと通信し、どのSCADAや帳票ソフトが参照しているかを確認します。

タグ数、更新周期、読み取り専用か書き込みありか、停止時の影響範囲も記録します。

この棚卸しをしないままUA化すると、使っていないと思っていたタグが実は帳票に使われていた、という事故が起きます。

特に書き込みタグは、操作権限と安全設計に関わるため、読み取りタグとは分けて管理しましょう。

Step 2：OPC DAラッパーやゲートウェイを検討する

既設のOPC DAサーバをすぐ置き換えられない場合は、OPC UAへの変換ゲートウェイを使う方法があります。

これは、下位側ではOPC DAで既設設備と接続し、上位側ではOPC UAサーバとして公開する考え方です。

この方式なら、既設SCADAやPLC通信を大きく変えずに、上位システムへUAの形でデータを渡せます。

ただし、ゲートウェイは万能ではありません。

タグの意味、品質情報、タイムスタンプ、更新周期、エラー時の扱いがどこまで正しく変換されるかを検証する必要があります。

Step 3：新規設備からOPC UAを標準にする

既設設備を急いで全更新できない場合でも、新規設備からOPC UAを標準にすることはできます。

新しいPLC、SCADA、データ収集サーバを導入するときは、OPC UA対応、証明書管理、タグ命名ルールを最初に決めます。

EtherNet/IPやフィールドバスからPLCへ集めたデータを、OPC UAで上位へ渡す構成も考えられます。

このとき、制御ネットワークと情報ネットワークを無計画につなげないことが重要です。

将来のMES連携やクラウド連携を想定するなら、最初からデータ名、単位、時刻、品質情報を標準化しておきましょう。

8. OPC DA連携で確認すべき設計ポイント

OPC DAを使い続ける場合も、OPC UAへ移行する場合も、設計ポイントは共通しています。

値が読めることだけを確認して終わると、運用後に品質、時刻、停止時動作で問題が出やすくなります。

現場で安定して使うには、通信、権限、タグ、周期、障害時の扱いを事前に決めることが重要です。

特に生産実績や異常解析に使うデータは、監視画面用の表示データより厳密な扱いが必要になります。

更新周期：速くすればよいわけではない

OPC DAでは、クライアントがタグを周期的に読み取る構成が一般的です。

更新周期を短くすればリアルタイム性は上がりますが、OPCサーバ、PC、ネットワーク、PLC通信の負荷も増えます。

全タグを一律に高速更新すると、本当に必要な重要データの取得が不安定になることがあります。

運転表示、トレンド、帳票、異常解析では、必要な周期がそれぞれ異なります。

設備データ収集では、用途ごとにタググループと更新周期を分ける設計が有効です。

異常時動作：通信断を画面とログに残す

通信断が起きたときに、最後の値を表示し続けるだけでは危険です。

画面では通信異常や品質不良を明確に表示し、ログには異常開始時刻と復旧時刻を残す必要があります。

値が正常に取れていない時間帯を記録しておくと、あとからデータ分析するときに誤判定を避けられます。

また、書き込みタグを使う場合は、通信断時に指令が残るのか、無効になるのかを確認しなければなりません。

安全に関わる信号は、OPC連携だけで成立させず、PLC側のインターロックや現場機器側の保護を優先します。

セキュリティ：工場ネットワーク全体で考える

OPC DAは既設設備で便利ですが、DCOM接続を広いネットワークへ開放する設計は避けるべきです。

制御ネットワーク、監視ネットワーク、情報系ネットワークを分け、必要な範囲だけを中継する構成にします。

上位連携が必要な場合は、OPC DAを直接外へ出すのではなく、DMZや中継サーバでOPC UA化する方が管理しやすくなります。

また、Windows PCのアカウント、パスワード、サービス実行権限、リモート接続権限も保守対象です。

設備データ活用では、通信できることよりも、誰がどこまで読み書きできるかを明確にすることが重要です。

9. OPC DAと他の産業通信の関係

OPC DAは、PLC同士を直接つなぐフィールドネットワークではありません。

現場の制御通信と、上位のアプリケーション連携の間にあるデータアクセス技術として理解すると整理しやすくなります。

例えば、PLCは現場機器から信号を集め、OPC DAサーバはそのPLCデータをWindowsアプリへ公開します。

この階層の違いを混同すると、OPC DAを使えば現場配線やPLC通信が不要になる、と誤解してしまいます。

Modbusやシリアル通信との違い

シリアル通信やModbusは、機器と機器の間でデータを運ぶ通信方式として使われます。

一方、OPC DAは、機器通信そのものというより、ソフトウェア間で設備データを扱うためのインターフェースです。

実際には、OPC DAサーバの下位側でModbusやメーカー独自通信を使ってPLCからデータを取得することがあります。

そして、上位側ではOPC DAクライアントがタグとして値を読み取ります。

このため、ModbusとOPC DAは競合するというより、階層が違う技術として組み合わせて使われることがあります。

SCADA・MESとの関係

SCADAは、設備の監視、操作、アラーム、トレンドを扱うシステムです。

OPC DAは、そのSCADAがPLCから値を取り込むための入口として使われることがあります。

MESは、製造指図、実績、品質、工程進捗など、製造管理寄りの情報を扱います。

MESへ設備データを渡す場合、OPC DAの値をそのまま渡すだけではなく、品番、ロット、工程、時刻と結びつける必要があります。

つまり、OPC DAはデータを取る手段であり、SCADAやMESはそのデータを業務目的に使うシステムです。

関連記事

instant.engineer

10. まとめ

OPC DAは、OPC Classic系のデータアクセス仕様であり、PLCや設備の現在値をWindowsアプリケーションへ渡すために広く使われてきました。

値だけでなく、タイムスタンプや品質情報を扱えるため、監視画面やデータ収集で重要な役割を持ちます。

一方で、COM/DCOMに依存するため、Windows設定、権限、ファイアウォール、PC更新の影響を受けやすい点があります。

OPC UAは、プラットフォーム非依存で拡張性のある仕組みとして、現在の設備データ連携で重要性が高まっています。

ただし、既設設備ではOPC DAがSCADAや帳票と深く結びついているため、急な全面置き換えはリスクがあります。

まずは接続関係、タグ、更新周期、書き込み有無、障害時動作を棚卸しし、必要に応じてゲートウェイや段階移行を検討しましょう。

OPC DAを理解してからOPC UAへ移行すると、古い設備を活かしながら、設備データ活用へつなげやすくなります。