IT/OTコンバージェンスは単なるバズワードか？ その真の価値を解き明かす

では、「IT/OTコンバージェンス」は単なるギミックなバズ用語なのでしょうか？

そう主張することもできます。誰かが新しいアイデアをキャッチすると、それを記憶に残し、「スライスされたパン以来の最高の新しいもの」のように聞こえさせようと試みます。だから当然、変革を促すキャッチーなフレーズを考え出し、マーケティングに利用しようとするでしょう。

しかし、このITとOTの「コンバージェンス」は、実際のところデータを利用可能にするための単なる次のステップに過ぎません。

IT/OTコンバージェンスとは何か？

少し前、製造業でのオートメーションの始まりを見ました。自動化装置は、人間では達成できない速度や出力レベルで特定機能を実行するよう設計されました。しかし、自動化装置が故障すると、制御エンジニアはシステムに入り、何が悪かったかを特定する必要がありました。これにはPLCシステムのレジスタを調べ、故障の手がかりを探ることが必要でした。これが運用技術（OT）データ活用の始まりでした。

故障に至るまでのデータがあることは、診断に役立ちました——それ以前に何が起きたかを知るためです。その結果、PLCシステムはヒストリアンを使用し、センサー、ヒーター、オートメーションアクチュエータからの長いデータストリームを保持するようになりました——大量のOTデータを用いて。

ヒストリアンからのOTデータを監視することで、SCADA機能はオペレーターに装置の運転状況に関する洞察を提供できるようになりました。故障が差し迫っているとき、SCADA機能はオペレーター（またはスーパーバイザー）に故障発生前に対処する機会を与えました。これにはSCADAシステムがヒストリアンからのデータにアクセスし、MODBUSやPROFIBUSなどの独自通信でそのデータをHMI（ヒューマンマシンインターフェース）を通じてオペレーターに提供する必要がありました。しかし、監視は装置の性能に限定され、OTデータの利用がさらに拡大しました。

これらのデータストリーム（ゲージ、オペレーター画面など）を観察し、データのドリフトをより理解することで、SCADAシステムを通じて、装置故障が差し迫っていることだけでなく、データが製品品質のテスト・検査での故障分析にも利用できることを認識できるようになりました——これらはプロセスの数ステップ後段にある操作かもしれません。

これにより、OTデータをITデータとリンクさせる必要が生じました。PLCやSCADAからMESなどの情報技術（IT）システムへの複雑なインターフェースが作られ、製品故障の関係データを装置の運用データとリンクできるようになりました。ERPへの直接接続も試みられました（今も試みられています）が、ERPシステムはそのデータを他の製造プロセス中のイベントと関連づけて、十分な速さと詳細で処理・提示する装備がありません。

MESへのインターフェースの問題は、高度にカスタマイズされ高コストで、プロジェクト実装コストの40〜50%を追加で占めることさえあります。データアクセス改善の次のステップは、PLCデータをMESや他のリレーショナルデータベースによりアクセスしやすくすることでした。このアクセスニーズが、コンピューティングコストとメモリコストの低下、ネットワーク通信の安定化（5Gネットワークの登場）と合わさり、PLCセンサーとアクチュエータを直接ITネットワーク（いわゆるIIoT）に接続し、そのデータを……必要な誰にでも利用可能にすることが合理的になりました。

この全ての背景は、OTデータをITシステムにより容易に利用可能にすることが、インダストリー4.0へと至った技術進化の長いプロセスにおける単なる次のステップであることを強調するためです。

IT/OTコンバージェンスをどう活用するか？

OTデータをITシステムにインターフェースする際、新たな問題に直面しました。

ヒストリアンでセンサーを監視するPLC/SCADAシステムは、数秒以内に大量のデータストリーム（メガバイト単位）を生成できます。しかし、イベントの特性をITシステムに理解させる観点からは、このデータストリーム——短い時間枠でも——は、MESなどのITシステムのリレーショナルデータベースが扱うには単純に多すぎます。多くの実装では、データストリームからセンサーデータのインスタンスを記録して単一データ要素を取得し、OTイベントをITレベルで何らかの形で表現しようと試みました。しかし多くの場合、OTデータのインスタンスを製造中の製品品質イベントにリンクさせることは、プロセス品質の一般的な監視にはあまり効果的ではありませんでした。

今、OTシステムからのデータストリームを、生産イベントの重要な特性を保持した形で集約する方法を決定する必要があります。OEE（総合設備効率）の報告は、このような集約の試みの一つです。データ集約のいずれの形を用いる場合も、品質イベントの重要な詳細が一部失われることは認識すべきです。だからこそOEEは監視レベルのデータオブジェクトとして用いられ、分析レベルのオブジェクトではありません。しかし、OEE値がリアルタイムで変化することを監視することで、ITシステムは変化の率と大きさを認識し、問題を知らせるアラームを生成できます。

実際の問題を分析するには、OEE値を作成するために使用された元のデータストリームに遡る必要があります。少なくともOEE値がリアルタイムで提供されていれば、製造エンジニアと制御エンジニアは、OTデータストリームのさらなるデータによってイベントが埋もれる前に、ヒストリアンに遡って分析できるほど早期に問題を可視化できます。

問題は、どうデータを集約するか？

答えはいつも通り……「ケースバイケース」です！

データの集約方法は、何を集約し、プロセス内で何を監視しようとしているかに依存します。また、データ集約モデルの変化を解釈できるかどうかにも依存します。

このセクションでは、一つの集約手法を取り上げ、このデータセットの変化を解釈するいくつかの方法を提示します。

「自然分布曲線」またはヒストグラムは、センサーのようなデバイスからのデータの最も一般的なグラフィック表現の一つです。この曲線の主要な前提は、もしプロセスに正常なランダム変動のみがあるなら、データインスタンスの分布は自然分布曲線に類似したパターンに収まるということです。

図1は、正常な変動下での炉センサーからの読み取り値分布がヒストグラムでプロットされたときの様子を描いています。

図1：平均値、中央値、最頻値を示す炉温度分布曲線。著者提供。

この曲線の主要な特徴は、平均値、中央値（データストリームの中央値）、最頻値（最も出現頻度の高い値）がすべてほぼ等しいことです。これはプロセスが問題を抱えているかどうかを判断する基準として使用できます。プロセスが管理下にあるという兆候がある限り、±3シグマ値を決定し、上下管理限界と製品仕様限界と比較する価値があります。

シナリオ例

焼き付け炉を通過する生産ユニットのプロセスを監視するため、MESシステムはユニットが炉に入った時刻と出た時刻を記録します。この間、PLCシステム（スマートセンサーを使用）が一定の温度センサーデータストリームを作成し、センシングデバイスのローカルヒストリアンデータベースに保存します。生産ユニットが炉を出ると、MESはその定義された期間中の温度データの集約をデバイスに要求します。デバイスレベルで利用可能な計算能力が限られていても、数百〜数千のデータポイントを取り、センサーデータの単一インスタンスを提供するのではなく（典型的）、またはデータストリーム全体を処理しようとするのではなく、一組の集約データをMESに返却できます。

この生産ユニットに対する集約データ値のセットは以下のようになります：

• 平均値：90.0
• 中央値：90.0に非常に近い
• 最頻値：約90.0度
• ±3シグマ分布：87.0、93.0（UCLとLCLで検証）

平均値、中央値、最頻値の差異を迅速に分析することで、MESは許容可能なプロセス管理監視と、すでに炉を通過した過去の生産ユニットからのトレンド変化を検出できます。±3シグマ値が許容限界を超える場合、MESは自動的にその生産ユニットを疑わしいとしてフラグします。同様に、平均値、中央値、最頻値が互いに、または過去の製品から大きく異なる場合もフラグします。

図2は、これらの値が制御外のプロセスをどう示すかの例です。この場合でも、±3シグマ値が許容限界内である可能性があります。

図2：歪んだプロセスにおける平均値、中央値、最頻値の差異例。著者提供。

技術的には、データセットの歪みにより±3シグマ値が有効でないと見なされる可能性があります。しかし、デバイスによる即時分析は、管理限界が違反されたかどうかを判断するために依然として利用できます。

重要なポイント：スマートセンサーからこの種のデータセットが提供されるなら、炉がランダム変動のみで動作していないことの兆候であり、したがって調査すべきです。

平均値と中央値が等しいが最頻値が異なるなど、平均・中央・最頻値の他の差異（例：二峰性分布を示唆し、複数のプロセス影響が働いている）も、製造エンジニアがプロセスを調査すべき条件を示します。

上記データセットがMESレベルで生産ユニットに直接リンクされていれば、このデータをテスト・検査結果と共に用いて、炉温度変動と生産ユニット故障の関連を示唆できます。

製品故障がプロセス問題の結果かどうかに関わらず、生産ラン中のデータ値ドリフトを見ることは、調査が必要な根本的なプロセス管理問題を示すこともあります。

まとめ

前出のデータ集約例は特定シナリオのみを反映していますが、OTとITデータのコンバージェンスの理由と、このコンバージェンスの潜在的価値への視点を提供することを意図しています。各生産シナリオでは、適切なデータ集約手法を評価し、スマートデバイスのプログラミングでこの機能を利用可能にする必要があります。あるいは代替として、エッジコンピューティングシステムをプログラミングし、スマートデバイスで説明した機能を置き換えます。

結論として、業界が「IT/OTコンバージェンス」を変化する技術を説明するバズ用語として多用している一方で、バズ用語の背後にある技術がもたらすデータ処理における正当な変化があります。コンバージェンスの技術を活用し、コンバージェンスを通じて提示されるデータを適切に集約・解釈することを学ぶ企業は、品質管理と設備管理プログラムの有効性において実践的な優位性を得られます。今日の競争的なグローバル環境では、あらゆる優位性を活用することはボトムラインにとって良いことです。

したがって、答えはノーです。IT/OTコンバージェンスは単なるバズ用語ではありません。 データ取得と管理技術の進化における貴重なツールであり、製造企業に大きな利益をもたらす可能性があります。OTレベルからのデータを集約し、ITレベルのシステムが扱える形にする方法を学ぶことは、コンバージェンスの重要な部分です。