UNSとMQTTによる産業データアーキテクチャの再構築

Augmented Opsポッドキャストの最近のエピソードでは、Litmus Automationの創設者兼CEOであるVatsal Shah氏と共に、急速に進化する産業用データアーキテクチャの状況を探りました。MQTT、Unified Namespace、そして新しい産業用データスタック」と題されたシャー氏とのディスカッションでは、Unified Namespace（UNS）のようなアーキテクチャや、Message Queuing Transport Telemetry（MQTT）のような通信プロトコルについて詳しく見ていきます。

自動化エンジニアとしてこの分野の既存ベンダーの多くと働いた経験から、最終的にリトマスを設立し、新しいツール群を構築したシャーは、多くのメーカーが直面するデータ統合の課題についての洞察を提供します。特に、オープンで相互運用可能なデータアーキテクチャによって、情報技術（IT）と運用技術（OT）の世界を橋渡しすることが急務であることを強調しています。

Shah氏は、産業オートメーション分野でレガシーベンダーの既存ツールを使用する際に経験した大きな制限について説明し、それが最終的にLitmusを立ち上げるきっかけとなりました。彼が遭遇した問題の中心は、異なるプラットフォームやベンダーにまたがるコンポーネントとシステムを統合することの難しさでした。Shah氏は、ある石油・ガスプロジェクトに携わっていたとき、彼と彼のチームは、Emerson、Honeywell、Fisher、Rosemount、Siemensのシステムを統合し、1つのデータベースを共有するという課題に直面したと語ります。これには、既存のツールでは効率的に達成できない、複数の異なるシステムにわたるレベルの統合が必要でした。

当時の唯一のソリューションは、Visual Basicでカスタムコードを書くことでしたが、このプロセスは時間がかかるだけでなく、現代の産業オペレーションに必要な拡張性と柔軟性に欠けていました。既存のソリューションはすべて、合理的な方法でITや他のシステムからOTデータをすぐに利用できるようにするには不十分でした。

シャーにとって、当時、会社を設立することは、技術的な課題を解決することよりも二の次でした：「会社を設立するかどうかはわかりませんでしたが、とにかくこの問題を解決することだけを考えていました」。彼は最終的に、よりシームレスな統合体験を提供し、組織が異なるシステムやプラットフォーム間でOTデータをより効果的に活用できるようにする接続プラットフォームを構築することを目標に、リトマスオートメーションを設立しました。

シャー氏は、産業データ・アーキテクチャの近代化におけるUNS（Unified Namespace）の重要な役割を強調。「OTは混乱しています。ITは今すぐデータを必要としています。両者の間には共通基盤が必要です」とシャー氏はUNSの必要性を説明。

従来のISA-95やPurdueモデルとは異なり、UNSは中央のメッセージブローカーを持つハブ＆スポークアーキテクチャを活用し、現場の機械からQMSやERP システムまで、あらゆるものがオープンな通信プロトコルで接続できます。これにより、ネームスペース内の2つのノード間でデータを交換する必要がある場合はいつでも、専用のポイント・ツー・ポイント接続を作成する必要がなくなり、より柔軟でスケーラブルなインフラストラクチャが実現します。

シャー氏は、メーカーには幅広いシステム間でのデータ交換と統合を容易にするオープンで相互運用可能なフレームワークが必要だと考えています。UNSの登場により、メーカーは新しいシステムをより迅速に統合することができ、また、組織のどの部分からでもデータへのアクセスを容易にすることで、市民開発者にも力を与えることができます。

同氏が説明するように、Unified Namespaceでは、「OTは、どのような種類のデータをプッシュし、どのように整理するかを決定します。IT部門は、データがどのように消費され、どのように安全で、どのようにスマート・アプリケーションが必要とする適切なコンテキストを持つかを決定します。

このアーキテクチャの革命的な可能性にもかかわらず、シャーは、それが活用するデータ転送プロトコルの制限のために持続する課題を認めています：MQTTです。このプロトコルはオープンで、軽量で、パブリッシュ・サブスクライブで、例外報告するように設定できるため、UNSのユースケースには理想的です。しかし、MQTTの仕様はUnified Namespaceの実装を大規模にサポートするために改良を続けなければならないと主張しています。

彼は、「MQTTは長い道のりを歩んできました......しかし、その上には長い道のりがあります」と指摘します。エンタープライズ・スケールのインフラストラクチャの要求を満たし、Kafkaのようなデータ・ストリーム・プロセッサの機能と一致させるためには、プロトコルの耐障害性とスケーラビリティを強化する必要があるとShahは主張しています。これが、IT組織がMQTTを、必要とされる包括的で将来性のある基盤をまだ提供していないと認識する原因になっていると彼は考えています。製造業者の要求を満たすことを目的としたMQTTのさらなる発展の1つが、Sparkplug B仕様です。

シャー氏は、MQTTはトランスポート層ではデータにとらわれないが、Sparkplug Bはデータを整理するための構造化フォーマットを導入しており、統合をより簡単にすることができると説明。しかし、彼はSparkplug Bの限界、特にその範囲の狭さも指摘しました。エッジデバイスやSCADAシステムからの標準化されたデータを整理するのには適していますが、「より分析されたデータ、派生データ、文脈化されたデータ、メタデータを扱うようになると、Sparkplug Bの少し先を考える必要があります」とシャー氏は主張します。

結局のところ、Sparkplug Bの柔軟性に欠けるペイロード構造では、Unified Namespaceが目指すようなOTとITの橋渡しに必要な幅広いユースケースには不十分であるというのが、彼の仕様に対する見解です。UNSアーキテクチャが約束する利点を組織が十分に活用できるようになるには、データ・トランスポート・プロトコルのさらなる開発が必要です。