工場データ抽出

実際の工場現場は寄せ集めです。異なるベンダー、異なる世代、異なるプロトコルのコントローラが隣り合って並んでいます — あるスキッドにはSiemens S7、その隣にはAllen-BradleyのPLC、変電所にはModbusの電力メーターと可変周波数ドライブ、包装ラインにはIO-Linkセンサー、工場にはCNC工作機械、建物のHVACを動かすBACnetコントローラ。そのほとんどは、他の何かとデータを共有するようには設計されていません。

工場データ抽出の課題は、これらすべての機器から信頼できる、名前付きで、タイムスタンプの付いた測定値を取得し、1か所に集めることです — 工場を再配線したり、コントローラを交換したり、PLCプログラムを書き直したりすることなく。実際にはこれは、各機器のネイティブプロトコルを話し、生のレジスタやタグを単位付きの名前付き工学値に変換し、その値が信頼できるかどうかが分かるように品質シグナルを付与し、さらにネットワークが切断されてもエッジで確実にそれを実行することを意味します。

IronFlockはこれを、軽量でエッジに展開されるコレクターアプリのファミリーで解決します — プロトコルファミリーごとに1つずつ。それぞれが任意のLinuxゲートウェイ上で通常のDockerコンテナとして動作し、可能な範囲で自動的に検出を行い、生のアドレスを名前付きの値に正規化し、障害時にはバッファリングし、すべてをプロジェクトの時系列データベースにストリーミングします。すべてのコレクターはブラウザで完全に設定でき、デモモードを搭載しているため、ハードウェアを接続する前に全体的な使い心地を評価できます。

ブラウンフィールドの現実

工場全体をカバーする単一のプロトコルは存在しません。実際の問いは常に 「どのコレクターが自分の機器を読み取れるのか?」 です。以下の表は、現場で見つかりそうな機器を、それを処理するコレクターに対応付けています。

ModbusとOPC UAは現在利用可能であり、IO-Link、MTConnect、BACnetも同様です。Industrial CollectorのSiemens S7（S7comm）およびAllen-Bradley（EtherNet/IP）ドライバーはApache PLC4Xエンジンによって駆動され、各種デバイスで検証が進められています — S7-1200/1500コントローラは、内蔵のOPC UAサーバーを通じて今日すでに読み取ることができます。

IronFlockコレクターが共通するアプローチ

どのプロトコルを収集するにせよ、5つのアプリはすべて内部的に同じ仕組みで動作します。同じプロジェクトごとのデータベーステーブル（gateways、assets、datapoints、measurements、assetstatus）に書き込み、読み取り値をローカルにバッファリングして、プラットフォームへの上流リンクが復旧したときに順番どおりに転送し、各機器を分離して1台の到達不能なマシンが他のマシンを停滞させないようにし、設定ファイルや再起動なしでブラウザ上でライブに設定されます。これは、IronFlockがどのように展開されていても — マネージドクラウド、プライベートクラウド、または完全オフラインのオンプレミスアプライアンス — 変わりません。以下の各ページでは、各ページが単独で成立するよう、これらの共通の特性を繰り返し説明しています。

既知の制限

一部のレガシー機器には、まだ直接的な経路がありません。レガシーなAllen-Bradley MicroLogix / SLC（DF1上のPCCC）、予備のイーサネットポートがないProfibusのみのセル、プラントDCSからのみ操作されるパッケージ、そしてデジタルコントローラをまったく持たない機器（ハードワイヤードのみ）は、ゲートウェイ、プロトコルブリッジ、またはセンサーの後付けを必要とします。お使いの機器が対応しているかどうか不明な場合は、お問い合わせください — 機器がModbusまたはOPC UAを話すなら、ほぼ確実に今日動作しますし、新しいドライバーやプロファイルパックはリクエストに応じて追加されます。

コレクター

• Industrial Collector — 現場全体を1つのアプリで：Siemens S7、Allen-Bradley、Modbus、OPC UAを並べて扱い、事前マッピングされた機器プロファイルのカタログを備えています。
• IO-Link Collector — IO-Linkマスターとスマートセンサーを、自動検出とHTTP、OPC UAまたはMQTT経由の自動IODDデコードで扱います。
• Modbus Collector — 膨大な既設のModbusメーター、ドライブ、コントローラを読み取る最も軽量な方法です。
• MTConnect Collector — オープンなMTConnect標準を介して、CNC工作機械や現場設備を、ゼロ設定の検出で扱います。
• BACnet Collector — BACnet/IPを介したビルオートメーション、HVAC、エネルギーシステムを、自動的なネットワークおよびポイント検出で扱います。

データの行き先

すべてのコレクターは読み取り値をプロジェクトのプライベートな時系列データベースに保存し、そこからプラットフォームの他の部分ですぐに利用できます：Data Backendを介してクエリやモデリングを行い、IoTダッシュボードやSCADAボードでライブに可視化し、Alarmsアプリで監視してSMS/メール通知を受け取ります。デバイスをオンラインにしてこれらのアプリをインストールするには、デバイス管理とアプリ管理を参照してください。

収集からインサイトへ：典型的な実装パターン

抽出は基盤であって、ゴールではありません。誰もレジスタやタグそのものが欲しいわけではありません — 工場が求めているのはOEEの数値、スピンドルが故障する前の早期警告、製品1個あたりのエネルギー、自動的に書き上がるシフトレポートです。そのため、典型的なIronFlockの導入はきれいに分離された2つのレイヤーで構成されます：

レイヤー1 — 収集。 お使いの機器に合ったコレクターアプリを、その機器のそばのゲートウェイにインストールし、ブラウザで機械をマッピングします。この時点から、名前付きで、タイムスタンプ付きで、品質フラグ付きの測定値が、プロジェクトの標準化されたデータベースに継続的に蓄積されていきます — すべてのプロジェクトが同じデータベースを持つため、コレクターはどこにインストールされても同一に動作し、プロジェクト所有者は収集されているすべてを検査できる1つの中心点を得ます。その内部では、各アプリのデータは独自の分離されたスキーマに保存されます：あなたのものである、成長し続ける単一の資産で、デフォルトではアプリごとにプライベートです。

レイヤー2 — 利用。 それらの測定値を意思決定に変えるアプリをインストール（または構築）し、クロスアプリデータアクセスを通じてコレクターのデータを読み取らせます：

• 既製のOEEダッシュボードアプリは、機械状態と生産カウンターを利用し、ラインごとの可動率、性能、品質を提供します — 統合ミーティングを一度も開くことなく、壁のディスプレイにライブで。
• 予知保全アプリは、コレクターがすでに集めた数か月分の振動・電流・温度履歴で学習し、次にライブストリームをスコアリングして、ドリフトし始めたベアリングを警告します。
• エネルギー分析は、Modbusメーターの消費量と機械の生産カウンターを結合し、製品1個あたりのエネルギー、アイドル負荷の無駄、ピーク負荷リスクをレポートします。
• レポート・品質アプリは、同じテーブルを読み取り、シフト記録、バッチレコード、監査証跡を自動的に埋めます。
• Node-RED ランタイム（または任意の汎用ワークベンチ）は、単一のワイルドカードですべてのプロジェクトデータを利用すると宣言し、その後、利用可能なテーブルを実行時に検出します — これにより、エンジニアはそれぞれに個別の統合を書くことなく、現場のあらゆるコレクターや分析アプリにまたがってフローを組めます。

各利用側アプリは、どのコレクターデータが必要か — 特定のリスト、またはすべてを指す - app: "*" — を宣言します。そのアクセスは、プロジェクトごとにスイッチで承認または取り消しできます — 常に読み取り専用です。すべてのIronFlockコレクターは同じテーブルスキーマ（gateways、assets、datapoints、measurements、assetstatus）に書き込むため、1つのコレクター向けに書かれた利用側アプリはすべてのコレクターで動作します：OEEダッシュボードは、機械状態がS7、Modbus、MTConnect、IO-Linkのどれ経由で届いたかを気にしません。

その結果として得られるのは、あなたをロックインするのではなく、あなたと共に成長するアーキテクチャです：1つのラインの1つのコレクターから始め、準備ができたら分析アプリを追加し、どのレイヤーも独立して交換・拡張できます — そして既製アプリが合わなければ、すでに収集しているデータの上に独自の利用側アプリを構築できます。