工場データダイオードの導入を検討するとき、最初に決めるべきことは製品名ではありません。「生産データをどこからどこへ、何のために送るか」と「逆方向に流す必要がある情報は何か」です。タイの工場では、設備データを本社、品質管理システム、クラウド分析基盤へ届けたい一方、外部ネットワークから制御設備への経路を増やしたくないという相談が増えています。本稿は、OTからITへの片方向境界が適する条件、OPC UA・MQTTの実装上の注意、見積依頼書（RFP）と受入試験（FAT/SAT）の作り方を、導入担当者が判断できる形に整理します。
工場データダイオード導入で最初に確かめる「方向」
データダイオードは、NISTの用語ではデータが一方向にだけ進むネットワーク装置です。製品によって光送信器と受信器、転送ソフト、プロトコル変換器などの構成は異なりますが、購入判断の中心は「OT側からIT側へ物理的に片方向の通信経路をつくる」ことにあります。ファイアウォールの許可ルールで片方向に見せる構成と、片方向の物理リンクを使う構成は、設計・試験・運用で検証すべき内容が違います。NISTの定義を出発点にし、見積書には、どの機器が片方向性を担保し、どの機器がデータを収集・複製するかを分けて書いてもらいます。
重要なのは「工場から出すデータがある」ことと「工場への指令が要らない」ことを混同しないことです。設備稼働、アラーム、品質測定値、保全ログを上位側へ送る用途は候補になります。一方、上位側の画面からPLCの設定変更、レシピ配布、遠隔保守の対話セッションを行う用途は、その境界だけでは成立しません。インターネット接続の有無だけで決めず、業務の操作手順を時系列で書き、戻り通信があるかを確認します。
NIST SP 800-82 Rev.3は、OTの安全性・信頼性・性能を考慮したセキュリティ設計を求め、境界における一方向ゲートウェイをファイアウォールの代替選択肢として説明しています。ただし、これを入れれば全てのOTリスクが消えるという意味ではありません。設備側の端末管理、保守端末の持ち込み、OT内の権限、現場の変更管理は別に残ります。タイの複数拠点を横断して検討する場合にも、工場ごとの制御要件を確認してから共通設計を作る必要があります。NIST SP 800-82 Rev.3
*図のオレンジの矢印は遮断される逆方向の試行を示し、許可された戻り経路ではありません。*
片方向境界が合う業務と、別経路の設計が要る業務
| 業務 | OT→ITの片方向境界との相性 | 設計時に確かめる点 |
|---|---|---|
| 生産実績・設備状態の可視化 | 合いやすい | タグ定義、時刻、欠損、受信先の更新周期 |
| ヒストリアンのデータ複製 | 合いやすい | 履歴の再送、スキーマ変更、障害後の追いつき |
| アラーム・セキュリティログの上位集約 | 合いやすい | 発生順序、優先度、送達確認の方法 |
| クラウドへの分析用テレメトリ | 合いやすい | OT側ゲートウェイとクラウド側ブローカーの役割 |
| 本社からのレシピ投入 | その境界だけでは不可 | 承認済みの別運用または別設計が必要 |
| 遠隔PLC操作・双方向の保守 | その境界だけでは不可 | リモートアクセス設計と監査を別に行う |
「上位で見られるようにする」と「上位から制御する」は別の要件です。RFPで両方を同じ「データ連携」という語にまとめると、試験時に要求の衝突が見つかります。最初のワークショップでは、各画面やAPIが読むデータ、書くデータ、操作の主体、障害時に現場が何を続けるかを一行ずつ列挙すると、片方向化できる部分が見えます。
タイ工場でのOT→IT境界はどこに置くか
典型的な検討順は、センサーやPLCに近い制御ネットワーク、SCADA・ヒストリアンがある監視ネットワーク、工場IT、社内IT・クラウドの順に、既存の接続を描くことです。境界は「最も下流の機器のすぐ横」に置けばよいわけではありません。OT側にすでにデータを正規化できるヒストリアンや収集サーバーがあれば、そこから必要な情報だけを出すほうが、PLCごとの改造を減らせる場合があります。一方、複数の設備群を一つのゲートウェイに集中させると、収集障害の影響範囲が広がります。工程停止への影響を見て粒度を決めます。
まず、線図に現実の接続を残します。保守会社のリモート回線、USBで持ち込む設定ファイル、工場ITからの時刻同期、ウイルス対策更新、バックアップの戻し経路まで記入します。データダイオードを一カ所に置いても、別の双方向経路が同じOT領域につながるなら、「その領域は完全に片方向で隔離した」という説明は成立しません。選定時に守りたい対象と残存経路を明記するほうが、過剰な安心感を避けられます。
建屋・ラインごとに分かれた工場では、通信盤の設置場所、電源、ラック、光ファイバー配線、予備機の保管場所、夜間の交換手順も決めます。現場保全が扱う装置とIT部門が扱う装置の責任分界を曖昧にしたまま導入すると、通信断の際に対応が止まります。OT機器への負荷が増えるか、データ収集周期が制御ネットワークへ影響しないかを導入前に確認します。
データフロー表に書くべき列
表の一行は「送信元システム／送信元タグまたはファイル／意味と単位／発生時刻の扱い／最大許容遅延／欠損時の扱い／OT側の取得方法／境界を越える形式／IT側の受信先／保持期間／責任者」で構成します。たとえば温度の数値だけを流しても、測定点ID、摂氏か華氏か、時刻、品質フラグが欠ければ上位側の判断に使えません。「通信できた」だけを受入条件にせず、データの意味が保存されるかを試験します。
製造現場で「リアルタイム」と呼ぶ範囲は業務で変わります。設備状態を監視画面に出す要件と、月次の品質分析に取り込む要件を同じ遅延基準にしないでください。必要な更新間隔と障害後の追いつき時間を現場が承認し、その条件で転送・蓄積・再送を設計します。公開された製品資料の理論上の帯域値を、自社のデータ品質や復旧時間の保証と読み替えないことが大切です。
OPC UA・MQTTを片方向境界でどう扱うか
OPC UAのクライアント／サーバー方式では、一般にクライアントがサーバーへ接続し、読み取りやサブスクリプションを要求し、応答を受けます。その対話を物理的な片方向リンクの上にそのまま通す、という説明は正確ではありません。現実的な構成は、OT側のソフトがOT内のOPC UAサーバーに接続して値を取得し、必要な値を片方向に送り、IT側に複製サーバーや受信アプリを立てるものです。IT側クライアントはその複製先に接続します。WaterfallのOPC UA Data Access資料は、この送信元クライアントと受信側サーバー複製の役割を具体的に示しています。これは一つの製品実装例であり、全製品が同じ機能を持つという意味ではありません。
OPC UA PubSubは別の通信モデルです。OPC FoundationのPart 14仕様では、Publisherがデータセットを発行し、Subscriberが受け取り、MQTTブローカーを使う方式も定義されています。このため「OPC UAなら全て双方向必須」でも「PubSubなら装置を挟むだけで自動的に一方向化できる」でもありません。具体的な製品が対応するプロファイル、データ型、メタデータ、セキュリティ方式、構成変更の方法を確認します。OT側のPublisher、境界の転送、IT側のSubscriber・ブローカーを別の箱として設計します。
MQTTでも同じです。ブローカーへ向かう通常のMQTT接続には接続確立や確認応答などの往復があります。「MQTTパケットを光の一方向線に直結する」と言えば済む問題ではありません。ゲートウェイの送信側でデータを受け、片方向転送用に包み、受信側でIT側ブローカーへ再発行する構成か、製品が提供する別のアダプター構成を確認します。Owl Cyber Defenseは、データダイオードを含むクラウドゲートウェイでMQTTなどを扱う用途を説明していますが、公開資料は自社構成の説明です。採用候補には実データと宛先ブローカーでの動作確認を求めます。Owlのクラウド接続資料
*図のオレンジの矢印は遮断される逆方向の試行を示し、許可された戻り経路ではありません。*
プロトコル名だけで選ばないための確認表
| 項目 | ベンダーに示してもらう証拠 | FATで再現すること |
|---|---|---|
| OPC UAクライアント／サーバー | OT側で何を読むか、IT側に何を複製するかの構成図 | 値・品質・時刻・ノード構造の照合 |
| OPC UA PubSub | 対応するトランスポートとエンコーディング、メタデータの扱い | 定義変更後もSubscriberが正しく解釈するか |
| MQTT | ブローカー接続点、Topic、QoS、再送・重複処理 | 通信断と再接続時の欠損・重複を確認 |
| ヒストリアン | 対応する製品・バージョン、履歴再送の方法 | 蓄積値とIT側複製値の突合 |
| ファイル転送 | ファイル完成の判定、改ざん検出、感染対策 | 不完全ファイルと再送時の処理 |
データの流れが片方向でも、運用手順には双方向の人間系ワークフローが残ります。新しいタグをIT側から依頼し、OT側で承認して設定する場合、その変更はメールやチケット、現場作業として処理できます。しかしそれを「片方向リンクを通じてIT側から自動設定できる」とは書けません。仕様書には技術的なデータ経路と人による変更手順を別々に表現します。OPC UAをクラウドに連携する際の基本設計やMQTT Sparkplug B導入の整理も、プロトコル側の事前検討に役立ちます。
データダイオードとファイアウォールを比較するときの判断軸
比較は「どちらが安全か」という一問では終わりません。ファイアウォールは許可する通信をルールで制御し、業務上必要な双方向通信にも対応できます。一方向ゲートウェイは、その境界について逆方向のネットワーク通信を前提にしない設計です。設備からデータを出すだけで済む場合には明確な利点がありますが、戻り通信を要する業務を代替するわけではありません。多くの現場では、境界ごとに両者の役割を分けて設計します。
選定時には、防御だけでなく可用性、データ完全性、運用負荷を同じ表に並べます。たとえば「片方向であること」は、IT側で生じた侵害がそのリンクを通ってOTへ戻る経路を遮る性質です。ただしOT側で作成された不正なデータ、誤ったセンサー値、収集ソフトの不具合を自動で直す性質ではありません。IT側に出るデータの機密性や個人情報も、別途制御する必要があります。公開事例の「絶対安全」といった宣伝文句を自社の保証条件に転記せず、境界の対象、試験方法、残る経路を具体的に書きます。
比較見積には、機器本体だけでなく両端のサーバー／仮想マシン、ライセンス、プロトコルアダプター、光配線、予備品、ログ監視、保守契約、FAT/SAT、停止期間中の作業、将来のタグ追加費用を含めます。価格は規模や製品構成で変わるため、本稿では相場額を示しません。見積明細を同じ範囲にそろえ、初期費用と継続費用を分けて比較するほうが実務に役立ちます。
「一方向」の証明範囲を言語化する
RFPでは「OT→ITの物理リンクにIT→OTの送信素子または信号経路が存在しないことを、構成図と試験で示す」といった検証可能な文にします。ただし装置ごとに検証手順は異なるので、認証名だけで代替しません。また、管理ポート、保守回線、冗長化用リンク、別のネットワーク経路が安全境界を迂回しないかを確認します。二台構成の各機器に管理アクセスが必要な場合、その管理元とアクセス制御も図面に入れます。
公開資料の「OPC UA対応」「MQTT対応」は、プロトコル全機能の適合を保証する短文ではありません。読めるタグの種類、セキュリティ証明書、暗号化、データ型、再接続、接続台数など、必要な条件を明記してからベンダー回答を評価します。WaterfallのOPC UAサーバー複製例と、Owlのクラウド向けアダプター例は、同じ「一方向」でも周辺ソフトの構成が違うことを示しています。
RFPにそのまま使える要件の書き方
見積依頼書は、装置の型番を先に指定するより、守る境界とデータの受渡しを定義してから回答させると比較しやすくなります。最初のページに対象工場、対象ライン、現在のOT/IT接続図、停止可能時間、既存のOPC UA・MQTT・ヒストリアン構成を示します。機器ベンダー、システムインテグレーター、工場の設備担当が同じ前提を見られるようにします。
次に必須要件と提案要件を分けます。必須要件には「OT→IT以外のデータ流を作らない」「指定データの意味を保存する」「異常時に制御へ影響させない」「装置障害を検知して通知する」「ログを保存する」などを置きます。提案要件には追加の解析機能や管理画面、将来の拡張などを置きます。クラウド接続が目標でも、最初からクラウドの認証情報をOTのPLCへ持たせる必要があるかは再検討します。OT側の収集とIT側の送信を分離できるかを問います。
ベンダー回答欄を含むRFPチェックリスト
| 要件群 | 発注側が記入する条件 | ベンダー回答で求めるもの |
|---|---|---|
| 対象境界 | OTセグメント、IT/DMZセグメント、既存迂回路 | 物理・論理構成図、管理ポートの位置 |
| データ | タグ／ファイル一覧、更新条件、時刻・単位 | 対応表、変換・欠損時の仕様 |
| プロトコル | OPC UAの方式、MQTTの宛先など | 実装するアダプターと動作範囲 |
| セキュリティ | 認証、権限、ログ、更新手順 | 設定例、脆弱性対応、変更記録 |
| 可用性 | 許容停止、復旧目標、冗長化の要否 | 単一障害点、切替条件、復旧手順 |
| 検証 | FAT/SATの対象データと合格基準 | 試験手順、証跡、未達時の是正方法 |
| 運用 | 担当部門、保守時間、拠点追加予定 | 監視項目、保守分界、教育内容 |
「最大タグ数」「最大スループット」のような仕様は、製品カタログの数値と稼働条件を同時に確認します。実際には更新頻度、値のサイズ、履歴バッファ、変換処理、暗号化、冗長化構成によって必要な余裕が変わります。目標値は現場データを測定して決め、試験条件をRFPに添付します。根拠のない一般的な件数や速度を要件に書くと、過大設計または不足設計になり得ます。
タイ工場の調達では、英語の技術仕様と現地の保全手順書が別々に更新されることがあります。RFPに納品言語、構成図の形式、現地作業者向け手順、障害時の連絡方法、予備機の所在を明記します。日本本社側のセキュリティ承認だけで終わらせず、現地OT責任者が「停止時にどう運転を続けるか」を承認することが肝心です。
FATとSATで何を合格にするか
FAT（工場出荷前試験）は、実機または実機に近い構成でデータ変換と障害時の動作を確認する場です。SAT（現地受入試験）は、実際の配線、電源、宛先、運用手順で同じ要件が満たされることを確かめます。どちらも「画面に値が出た」だけでは不足です。送信元と受信先のデータの意味が一致し、データが止まったときに現場が気づき、復旧後に何が欠けたかを説明できることまで試験します。
FAT前には、代表的な正常値だけでなく、通信途絶、瞬間的な大量データ、タグ名変更、NULLや不良品質フラグ、タイムスタンプのずれを含むデータセットを準備します。OPC UAなら値と品質と時刻を組で比較し、MQTTならTopic、ペイロード、再送・重複を照合します。ヒストリアン複製なら短い障害だけでなく、長い停止後に履歴を追いつかせる条件を確認します。過去データの自動補完は全製品の標準機能ではないため、必要なら明示的に購入要件へ入れます。
*図のオレンジの矢印は遮断される逆方向の試行を示し、許可された戻り経路ではありません。*
受入試験の例
| 試験 | 操作 | 合格判定の考え方 |
|---|---|---|
| 通常転送 | 指定タグやイベントを発生させる | 意味、単位、品質、時刻が一致する |
| 逆方向遮断 | IT側からOT側サービスへの接続を試みる | 対象境界を通る経路が成立しない |
| 受信側停止 | IT側アプリを停止し再起動する | 損失・重複・再送が仕様どおり記録される |
| 送信側停止 | 収集ソフトや装置を停止する | OT制御は所定の状態を維持し、異常を検知できる |
| 回線切断 | 光リンクを切り戻す | アラーム、復旧、バッファ動作が仕様どおり |
| スキーマ変更 | テスト用タグを追加・変更する | 変更申請からIT側反映まで追跡可能 |
| 予備系切替 | 冗長系へ切り替える | 想定した時間・データ品質で復旧する |
合格基準には測定方法と証跡を付けます。「遅延が短い」ではなく、対象データごとの許容遅延、測定開始・終了点、時計の同期方法を記載します。「データが落ちない」ではなく、障害の長さ、バッファ容量、再送期限、欠損を知らせる仕組みを示します。ここで数値を置く場合は自社の工程と実測から決め、本稿の一般論を契約値として使わないでください。
SATではセキュリティ試験だけに偏らず、交換部品の手配、夜間連絡、電源復帰、管理者アカウント引継ぎ、設定バックアップの復元まで試します。特に「逆方向に通らない」試験は、片方向リンクだけでなく、同じOTセグメントへ到達する別回線がないかの構成確認と一緒に行います。制御設備に危険な負荷や予期しない指令を与えないよう、試験方法は工場側が事前承認します。
冗長化・障害復旧・保守で見落としやすい点
一方向境界でも可用性は自動では得られません。送信側の収集サービス、片方向リンク、受信側の再発行サービス、宛先ヒストリアンやブローカーのどこが止まっても、上位側のデータは古くなる可能性があります。各箇所の状態を「正常／遅延／停止／復旧中」として監視し、最後に正常データを受信した時刻を上位側へ示します。値が更新されていないのに正常そうに表示される状態は、単なる通信断より業務上危険なことがあります。
冗長化を求める場合、二本の片方向リンクだけでなく、どのコンポーネントを二重化するかを決めます。送信元サーバーが一台なら、その故障は二本の光リンクでは救えません。逆に宛先ブローカーが止まった場合、受信側のバッファがどこまで保持するかが重要です。切替時に同じイベントが二度届く可能性を認めるなら、イベントIDや時刻と設備IDで重複を見分ける設計が必要です。厳密に一度だけの処理を求めるなら、アプリケーション側まで含めて検証します。
パッチ適用や証明書更新の手順も、片方向境界の仕様に含めます。IT側からOT側へ更新ファイルを流し込めない構成なら、OT側の承認を経た別の持込手順が必要です。USBなどの媒体を使う場合は、その媒体の検査・記録・保管も設計対象です。遠隔保守用に一時的な双方向回線を開けるなら、その開始・終了・承認・ログを別途管理し、「常に一方向」という説明を変更期間にも適用しないようにします。
変更管理では、新しいタグの追加、タグ名の変更、設備更新後の値域変更、クラウド側のTopic変更を一連の依頼として扱います。IT部門だけで宛先を追加できても、OT側の取得負荷や情報分類が変わる可能性があります。責任分界表に「要求者・承認者・実装者・試験者・運用者」を置き、変更後にデータが正しく届くことを確認します。既存のOTセキュリティRFPの進め方も、調達範囲を整理する際の参考になります。
導入前に作る小さな実証計画
初回から工場全体の全タグを移行するより、意思決定に必要な一つのデータ経路を選びます。たとえば一ラインの停止・稼働状態と品質実績を、OT側収集点から工場ITの受信点まで通します。元データ、受信データ、更新時刻、通信断の記録を並べ、現場の利用者が「このデータで判断できるか」を確認します。実証の目的はデモ画面の美しさではなく、境界・データ品質・復旧・保守の不確実性を減らすことです。
実証開始前に、選定対象の機器とソフトのバージョン、接続するOT機器、ネットワーク変更、試験期間、ロールバック条件を固定します。FATで通った構成とSATで設置する構成が異なるなら、差分を記録して再試験項目を決めます。クラウドへの送信を含める場合は、個人情報や取引先情報が混ざらないよう、送信データの分類と権限も先に確認します。片方向性はデータの公開範囲を自動で制限しません。
意思決定会議には、セキュリティ担当だけでなく、設備保全、生産、品質、IT、調達、導入ベンダーを入れます。導入の可否を「セキュリティが強いか」だけで決めず、取得したデータを誰が使い、運転中に障害が起きたら誰が対応し、変更費用を誰が負担するかまで合意します。タイ工場と日本本社の間で担当者が分かれる場合は、時差や言語よりも承認権限と現地実行権限の食い違いを解消することが先です。
逆方向の業務を残す場合の承認設計
片方向化の検討で最も扱いが難しいのは、日常のデータ収集ではなく、まれに発生する逆方向の業務です。たとえば新製品のレシピ、設備メーカーからの設定変更、セキュリティパッチ、証明書、時刻設定、アラーム確認の応答があります。頻度が少ないからといって要件表から消してしまうと、稼働後に非公式な抜け道が作られます。まず「誰が、どの情報を、どのOT資産へ、どのタイミングで入れるか」を整理し、技術的に遮断する経路と、承認を経て実施する経路を明確に分けます。
逆方向に必要なものをすべてネットワーク接続にする必要もありません。変更内容をオフラインで審査し、現地担当者が管理された媒体から投入する運用もあります。ただし媒体を使えば無条件に安全という意味ではなく、入手元の確認、マルウェア検査、ファイルのハッシュ照合、持込履歴、適用前後のバックアップ、二人承認、ロールバックを設計します。ネットワークを使う場合は、接続可能な時間帯、接続先、認証、操作ログ、緊急停止の責任者を定めます。片方向境界に穴を開けるのではなく、別の管理対象として扱うことが判断を明瞭にします。
アラームも区別が必要です。アラームの発生をOTからITへ送ることと、IT側で見た人の確認操作をOTのアラーム状態へ返すことは別のデータフローです。上位画面に「既読」を付けるだけならIT内で完結できるかもしれません。一方、OTの制御ロジック上の確認状態を変えるなら戻り経路が必要です。RFPとFATでは、どちらの意味の「アラーム確認」かを明記します。この区別は、運転員が緊急時に依存する画面ほど重要です。
発注前の最終判定を一枚にまとめる
ベンダー比較の最終会議では、製品紹介の資料を並べるより、以下の判定表を各候補に埋めると差が見えます。判定を「適合／条件付き適合／未確認／不適合」に分け、条件付きには追加ソフトや運用手順、未確認にはFATで得る証拠を書きます。未確認を適合に読み替えないことが、導入後の手戻りを減らします。
| 判定項目 | 合格とする根拠 | 未確認なら次に行うこと |
|---|---|---|
| 境界の片方向性 | 実機構成図と逆方向遮断試験 | 管理ポート・予備系を含む線図を再提出 |
| データの意味 | 値・単位・品質・時刻の突合記録 | 代表タグで送受の比較試験 |
| 障害からの復旧 | 停止、警報、再送、欠損表示の記録 | 長時間停止を模したFAT |
| 運用責任 | 現地OTとITの署名済み分界表 | 夜間障害の演習と手順修正 |
| 逆方向業務 | 別経路または別手順の承認記録 | レシピ・保守・パッチを個別に設計 |
この表は「機器が動くか」と「工場で使い続けられるか」を同時に見るためのものです。たとえば片方向性の証明があっても、障害時の古い値を上位画面が現在値として表示するなら、運転判断には使えません。逆に、データ品質が高くても保守担当が夜間に復旧できないなら、展開対象ラインを増やす前に手順を改善する必要があります。導入判定には、現場責任者が何を根拠に承認したかを残してください。
よくある質問：工場データダイオード導入
Q1. データダイオードがあればファイアウォールは不要ですか？
不要とは言えません。片方向境界は、その境界における逆方向通信をなくすための設計です。OT内のセグメント分離、管理ポート、必要な双方向通信、IT側のアクセス制御には、別のネットワーク制御が必要になる場合があります。工場全体の接続図で役割を決めます。
Q2. OPC UAの既存クライアントをIT側からそのままOTサーバーへ接続できますか？
物理的な片方向リンクを跨いで、通常の対話型クライアント接続をそのまま成立させる想定は避けます。OT側で取得し、IT側に複製サーバーを作る方式など、製品に適した構成を確認してください。参照するノード、品質、時刻、証明書、変更時の同期が要件を満たすか試験します。
Q3. MQTTなら設定だけで片方向にできますか？
MQTTの標準的なブローカー接続には往復の通信があります。片方向境界では、両側のアダプターやブローカーを含めた構成が必要です。対応をうたう製品でも、Topic、QoS、再接続、重複、セキュリティ設定まで実データで確認します。
Q4. 本社からレシピや設定ファイルを工場へ送れますか？
OT→ITの片方向境界を逆向きの投入経路として使うことはできません。その業務が必要なら、承認された別の方法を設計します。媒体による持込、別の管理された接続、現地での変更作業など、工程とリスクに応じて選びます。
Q5. 導入費用はどのように比較すればよいですか？
本体価格だけでなく、収集・複製ソフト、プロトコルアダプター、両端サーバー、配線、FAT/SAT、保守、将来のタグ追加を同じ範囲で見積もります。工程停止の条件と復旧要件も共有します。条件がない概算金額同士の比較は判断を誤らせます。
Q6. 障害時に生産ラインは止まりますか？
設計によります。監視用の複製経路なら、境界側の停止が制御ループに影響しない構成を目指せますが、OT側収集が制御ネットワークに負荷をかける場合や、上位システムが運転判断に使われている場合は影響評価が必要です。FAT/SATで送信側停止と復旧を試し、現場の継続運転手順を決めてください。
まとめ：装置の前にデータと受入条件を決める
工場データダイオードの導入では、OT→ITで出したいデータと、IT→OTで戻したい操作を分けることが出発点です。データの意味、プロトコルの終端位置、片方向リンクの証明範囲、障害後の再送、FAT/SATの合格基準まで明確にすれば、製品比較と現場の承認が進みます。逆方向を要する業務は別経路・別手順として設計し、境界の説明に混ぜないことが重要です。
タイ工場でのデータフロー図やRFPがまだ固まっていない段階でも、既存のOPC UA・MQTT構成と必要な受信データを整理するところからご相談いただけます。TOMAS TECHへのお問い合わせをご利用ください。
