マシンデータはどのように Microsoft Fabric に届くのか - OPC UA からリアルタイム分析まで

クラウドへ工場の機械アラーム、センサー値、生産カウンター、故障イベントを送ることは、かつてないほど容易になっています。OPC UAが機械の信号を公開し、エッジレイヤーがそれを収集し、MQTTがローカルで配信でき、Microsoft Fabricがその結果生じたストリームを取り込んで分析できます。難しいのはデータが到着した後です。生のテレメトリを、実際の意思決定を支えるのに十分な生産の文脈へどう変換するのか、という問題です。

このエピソードでは、工場の現場から1つの機械信号を取り上げ、Microsoftの産業データスタックを通して追跡します。OPC UAから始まり、エッジとMQTTを経て、安全にAzureおよびMicrosoft Fabricへ渡り、Eventstream、Eventhouse、KQL、Lakehouse、Power BI、MES、ERP、保全データ、生産文脈がどのように組み合わさるかを見ていきます。目的は単に別のテレメトリパイプラインを示すことではありません。機械データが生産、保全、品質、計画にとって有用になるまでに何が起こる必要があるのかを説明することです。

機械停止から生産への影響まで

機械の停止は、コントローラーのレベルでは単純に見えます。状態が稼働から故障に変わり、故障コードが現れ、部品カウンターが止まり、同じ時期に他の値も変化するかもしれません。これらの情報は有用ですが、生産側が知りたいのは通常別の問いです。どの作業指示が影響を受けるのか、残りの数量はどれくらいか、別の機械が引き継げるか、この遅延は納期を脅かすか、といったことです。

機械は自身の状態を理解していますが、ビジネス上の影響を自動的に理解しているわけではありません。MESは工程と作業指示を把握しているかもしれません。ERPは納期と需要を把握しているかもしれません。保全は設備の履歴を理解しているかもしれません。品質は出力がまだ使用可能かどうかを判断するかもしれません。だからこそ、高速なテレメトリパイプラインは、アーキテクチャの出発点にすぎないのです。

OPC UA：信号が データパスに入る場所

OPC UAは、すべてのクラウドアプリケーションが独自のコントローラープロトコルを理解することなく設備から情報にアクセスできる、標準化された産業向けインターフェースを提供します。サーバーは、変数、機械状態、アラーム、イベント、メソッド、タイムスタンプ、品質情報、そして場合によっては構造化された設備モデルを公開できます。

この構造が重要なのは、有用な産業イベントが数値だけでなく、より多くの情報を持つべきだからです。ソースタイムスタンプ、サーバータイムスタンプ、品質ステータス、単位、ソースの識別情報、元のOPC UAノード情報はすべて、後になって「この数値はどこから来たのか」「なぜこの生産計算が妥当に見えないのか」と問われたときに重要になります。

このエピソードではまた、タグ名がデータモデルではないことも強調しています。「温度」や「機械状態」という名前のフィールドには、設備、工学単位、許容範囲、状態定義、そして信号が観測された生産状況といった文脈がなお必要です。

OT境界を制御された状態に保つ

機械の接続によって、生産ネットワークが企業やクラウド環境の延長になってしまってはいけません。産業ネットワークには、通常セグメンテーションと産業DMZを含む、制御された境界が必要です。そうすることで、承認されたエッジシステムが設備と通信できる一方、企業のアプリケーションがコントローラーへ直接アクセスすることはありません。

推奨されるパターンは、一般に外向きを基本とするものです。エッジレイヤーは承認されたOPC UAエンドポイントに接続し、その後、制御された宛先、ポート、プロトコル、ID を通じて選択した情報をクラウドサービスへ送ります。分析プラットフォームは、生産システムを閲覧または変更する広範な権限を引き継ぐことなくデータを受け取るべきです。

証明書、ファイアウォールルール、信頼関係、有効期限の処理、所有権も、一度きりの設定作業ではなく、運用プロセスとして扱う必要があります。

エッジはデータを改善すべきであり、ビジネスの意味を勝手に作るべきではない

エッジレイヤーは、機械環境と、より広範なデータプラットフォームの間に位置します。その第一の責任は接続ですが、工場から出る前に情報をフィルタリング、正規化、バッファリング、拡充、ルーティングすることもできます。

有用なエッジの責任には次のものがあります。

• 定義されたユースケースに必要な信号だけを選択する
• 不要な高頻度データをフィルタリングする
• 合意された単位変換を適用する
• ソースタイムスタンプと品質指標を保持する
• 安定した工場、ライン、設備の識別子を追加する
• クラウド障害時にデータをバッファリングする
• 再試行とバックプレッシャーの動作を扱う
• コネクタとキューの状態を公開する
• 遅延や切断時の運用が必要とする場合に、選択的なローカル計算やAI推論を実行する

重要な境界は、エッジが確実に把握している事実を追加すべきだということです。古い情報に基づいて現在有効な製造指示を推測したり、MES、ERP、計画、品質システムに属する業務文脈を密かに作り出したりすべきではありません。

Azure IoT EdgeとAzure IoT Operationsの比較

このエピソードでは、産業エッジワークロードを実行するためのMicrosoftの2つのアプローチを比較しています。

Azure IoT Edgeは、要件がゲートウェイまたは個々のデバイスを中心としている場合にうまく機能します。コンテナ化されたモジュールがデータを収集し、ローカルロジックを適用し、情報をバッファリングし、Azure IoT Hubを通じて上流へ送信できます。定義された生産セルや小規模なワークロードで、組織がより軽量な運用基盤を望む場合に実用的な選択肢となり得ます。

Azure IoT Operationsは、むしろサイトレベルの産業データ環境として位置付けられています。Azure Arc対応のKubernetes環境上で動作し、OPC UA接続、MQTT、データフロー、設備やデバイスの管理に関する機能を含みます。サイトに複数のラインがあり、複数の機械ベンダーが存在し、ローカルの利用者がおり、統制されたエッジのパターンを複数の工場で繰り返す必要がある場合に、より適している可能性があります。

この決定は、どのプラットフォームの機能一覧が最も長いかに基づくべきではありません。組織が運用を支えられる準備があるかどうかという運用モデルに基づくべきです。Azure IoT Operationsはより広範なサイトレベルの機能を提供しますが、同時にKubernetes、Arc、クラスター運用、監視、ストレージ、パッチ適用、復旧の責任も持ち込みます。

工場のイベントバックボーンとしてのMQTT

同じ機械イベントを複数の利用者が必要とする場合、MQTTはアーキテクチャを大幅に単純化できます。機械コネクタは一度ブローカーへ発行し、保全アプリケーション、ローカルのヒストリアン、クラウドのデータフロー、またはその他の承認された利用者がそれぞれ独立して購読します。

これにより、多くの1対1の依存関係が取り除かれます。新しいアプリケーションは、PLCやOPC UAサーバーへの別の直接リンクを作ることなく、承認されたトピックを購読できます。

とはいえ、トピック設計は依然として重要です。階層構造で工場、エリア、ライン、セル、設備を表現できますが、トピックが全体のデータモデルになってしまってはいけません。イベントの識別情報、ソースタイムスタンプ、設備ID、品質、契約バージョン、イベントタイプといった重要な事実はメッセージのペイロードに残し、保存、再生、他所への転送がされてもイベントが理解可能であり続けるようにすべきです。

統合名前空間は、トピックツリーではなく契約である

Unified Namespaceパターンは、産業システム全体で共有される運用上の契約を提供できます。有用なのは、単に1つの巨大なMQTT階層を持つことではありません。価値は、設備をどう識別するか、イベントをどう形作るか、データの所有者は誰か、スキーマがどう変わるか、どのシステムがどの事実について正式な情報源かを合意することから生まれます。

優れた統合名前空間は、設備を安定した方法で識別し、統制された運用イベントを発行できる一方で、ソースシステムが自身の記録の所有権を保持できるようにします。

その契約は次のような事項を定義すべきです。

• 設備の識別情報
• イベントタイプ
• メッセージの形式
• タイムスタンプの規則
• 品質情報
• 所有権
• セキュリティ
• バージョン管理
• 変更管理

MQTTはその契約を転送できますが、MQTTが契約を作り出すわけではありません。

OPC UAの通知からMQTTイベントへ

OPC UAの通知をMQTTイベントに変換することは、単なるプロトコル変換以上のものです。コネクタは…