アーキテクチャ
IronFlockは分散システムであり、2つのレイヤーで構成されています:運用現場でアプリケーションを実行する自律的なエッジデバイスと、フリート全体のデータストレージ、ダッシュボード、AI、調整を提供する中央サービスです。リアルタイムメッセージブローカーがすべてを接続します。
これは純粋なエッジプラットフォームでも純粋なクラウドプラットフォームでもありません。その両方です — そしてアーキテクチャは、各レイヤーが最も得意とすることを行うように設計されています。
システムの全体像
┌─────────────────────────────────────────────────────────┐ ┌──────────┐
│ 中央サービス │ │ 仮想 │
│ │ │ デバイス │
│ ┌──────────┐ ┌──────────┐ ┌──────────┐ ┌────────┐ │ │┌────────┐│
│ │ FleetDB │ │ Backend │ │ AI │ │ Web │ │ ││ Custom ││
│ │ Cluster │ │ Service │ │ Service │ │ UI │ │ ││ Service││
│ │(Timescale│ │ │ │ │ │ │ │ │└────────┘│
│ │ DB) │ │ │ │ │ │ │ │ │ Agent │
│ └────┬─────┘ └────┬─────┘ └────┬─────┘ └───┬────┘ │ └────┬─────┘
│ │ │ │ │ │ │
│ └─────────────┴──────┬──────┴────────────┘ │ │
│ │ │ │
│ ┌───────┴───────┐ │ │
│ │ WAMP Message ├────────────────────────────┘
│ │ Broker │ │
│ └───────┬───────┘ │
│ │ │
└────────────────────────────┼────────────────────────────┘
│
┌──────────────┼─────────────┐
│ │ │
┌───────┴──┐ ┌───────┴──┐ ┌──────┴───┐
│ Edge │ │ Edge │ │ Edge │
│ Device 1 │ │ Device 2 │ │ Device 3 │
│┌────────┐│ │┌────────┐│ │┌────────┐│
││ Apps ││ ││ Apps ││ ││ Apps ││
││(Docker)││ ││(Docker)││ ││(Docker)││
│└────────┘│ │└────────┘│ │└────────┘│
│ Agent │ │ Agent │ │ Agent │
└──────────┘ └──────────┘ └──────────┘3つのレイヤー
1. エッジデバイス — 自律的なアプリケーション実行ノード
エッジデバイスはIronFlockの中核的な実行ノードです。各デバイスは軽量なエージェントと1つ以上のコンテナ化されたアプリケーション(Docker)を実行します。デバイスは自律的です:中央サービスから切断されても動作を継続し、ネットワークが復旧すると自動的に再接続します。
エッジデバイスはLinux対応の任意のハードウェアです — Raspberry Pi、産業用PC、NVIDIA Jetson、x86ゲートウェイ、カスタムARMボードなど。
エッジデバイスで動作するもの:
- IronFlockエージェント — デバイスのライフサイクルを管理し、OTAアップデートを処理し、コンテナを実行し、メッセージブローカーへの接続を維持します
- お客様のアプリケーション — 任意のプログラミング言語でDockerコンテナとしてデプロイされます。これらのアプリはPLCやセンサーからデータを収集し、制御ロジックを実行し、ローカルHMIを提供し、AIモデルを実行するなど、Linuxアプリケーションが実行できるあらゆることを行います
エッジデバイスはデフォルトですべての接続を外向きに開始します — インバウンドポートを開く必要はありません。ただし、ローカルHMIやAPIエンドポイントを公開するなど、必要に応じてデバイスポートを選択的に開くことができます。詳細はエッジデバイス&エージェントを参照してください。
2. 中央サービス — フリート全体のデータ、UI、インテリジェンス
中央レイヤーは、フリート全体のビューまたは永続的なインフラストラクチャを必要とする機能を提供します。各中央サービスは独立してスケーラブルです — サービスは互いに影響を与えることなく、成長するフリートに対応するために水平方向にスケールできます:
- FleetDB — デバイスから収集されたすべてのテレメトリデータを保存するPostgreSQL/TimescaleDBデータベースのクラスター。各プロジェクトは専用のテーブルと認証情報を持つ独自の隔離されたデータベースインスタンスを取得します。クラスターアーキテクチャにより、プロジェクト間での水平スケーリングが可能です。FleetDBは時系列ストレージ、スケジュールされた集計を処理し、ダッシュボードとAIクエリのデータバックエンドとして機能します。
- バックエンドサービス — デバイス、プロジェクト、アプリ、ユーザーアカウント、リリース、およびすべてのフリートレベルの操作を管理します。Web APIを公開し、ビジネスロジック層を処理します。増加するAPI負荷とデバイス登録に対応するために水平方向にスケールします。
- FleetDBサービス — デバイスからの受信データストリームを処理し、データ変換を処理し、フロントエンドにリアルタイムダッシュボードデータを提供し、アラーム評価を管理します。データ取り込み量に合わせて独立してスケールします。
- AIサービス — AIエージェントの会話をオーケストレーションし、会話の展開に応じて専門エージェントを動的に追加・削除します。自然言語クエリをルーティングし、メッセージブローカーを介してデバイス側の関数を呼び出し、リアルタイムでチャートと分析を生成します。プロジェクト間の同時AI会話をサポートするためにスケールします。
- Web UI — オペレーターがフリートを管理し、ダッシュボードを表示し、アラームを設定し、アプリを開発し、AIアシスタントと対話するブラウザベースのコントロールプレーン。
- コンテナレジストリ — すべてのアプリのDockerイメージを保存し、フリート内の任意のデバイスへのOTAデプロイメントを可能にします。アプリカタログの成長に合わせてストレージとスループットを独立してスケールします。
中央サービスはIronFlock Cloud(IronFlockが管理)またはお客様のインフラストラクチャでオンプレミスデプロイメントとして実行できます。詳細は中央サービスを参照してください。
3. 仮想デバイス — カスタム中央コンピュートノード
物理エッジデバイスに加えて、IronFlockでは仮想デバイスをプロビジョニングできます — 物理フリートと一緒にプロジェクトに参加するクラウドホスト型コンピュートノードです。仮想デバイスは物理デバイスと同じIronFlockエージェントを実行し、同じメッセージルーティングに参加し、任意のコンテナ化されたアプリケーションを実行できます。
仮想デバイスの一般的な用途:
- フリート全体の視点を必要とするGrafana、Node-RED、Netdata、Jupyterなどの中央フリートサービスの実行
- 複数の物理デバイスからデータを集約するデータ処理パイプラインのホスティング
- エッジハードウェアには計算負荷が高すぎるAI推論サービスの実行
- 外部システム(SAP、ERP、クラウドAPI)をIronFlockプロジェクトに接続するプロトコルブリッジとしての使用
仮想デバイスは別の機能ではなく、プロジェクトの完全な参加者です。デバイスリストに表示され、OTAアップデートを受信し、そのアプリは同じメッセージブローカーを通じてエッジデバイスアプリと通信します。
詳細は仮想デバイスを参照してください。
メッセージブローカー — 接着剤
IronFlockのすべてのコンポーネントは、中央のWAMP(Web Application Messaging Protocol)メッセージブローカーを通じて通信します。ブローカーは以下を提供します:
- リアルタイムPub/Subメッセージング — デバイスがテレメトリを公開し、ダッシュボードがライブデータをサブスクライブし、アプリが双方向に通信
- RPC(リモートプロシージャコール) — AIサービスがデバイス側の関数を呼び出し、バックエンドがデバイス上のコンテナ操作をトリガーし、オペレーターがコマンドを送信
- プロジェクト隔離 — 各プロジェクト-アプリの組み合わせが独自の暗号学的に隔離されたメッセージングレルムを取得。あるプロジェクトのデバイスは別のプロジェクトのメッセージを見ることができません
- 認証 — ブローカーへのすべての接続に有効な認証情報が必要
メッセージブローカーこそが、IronFlockを切断されたパーツの集まりではなく分散システムにしているものです。中央クラウドで実行されるAIエージェントは、工場フロアの物理デバイス上の関数を呼び出し、リアルタイムで結果を受け取ることができます — 両方が同じブローカーに接続されているからです。
詳細はメッセージブローカー(WAMP)を参照してください。
スケーラビリティと無停止アップデート
IronFlockアーキテクチャのすべてのコンポーネントは水平スケーリングを前提に設計されています。バックエンド、FleetDB、AIサービス、メッセージブローカー、コンテナレジストリはそれぞれ独立してスケールでき、フリートの拡大、データ量の増加、同時接続ユーザーの増加に対応できます——他のシステム部分に影響を与えることなく。
現在、すべてのシステムコンポーネントがほぼ無停止アップデートをサポートしており、アクティブな接続やデータフローをほとんど中断することなく新バージョンにアップグレードできます。クラスタ化されたメッセージブローカーがこの方式へ移行した最後のコンポーネントであり、プラットフォーム全体をほぼサービス中断なしで更新できるようになりました。
アーキテクチャ vs. 従来のSCADA
従来のSCADAプラットフォーム(Ignition、WinCC、Wonderware)はゲートウェイ中心モデルに従います:1つの中央サーバーがすべてを行います — タグ収集、履歴保存、画面表示、アラーム処理、スクリプティング。「エッジ」はその中央サーバーにデータを供給するPLCに過ぎません。
IronFlockはこれを逆転させます。エッジデバイスは完全な計算能力を持つ自律的なアプリケーション実行ノードです。中央サービスはフリート全体のビューが必要なものを処理します:永続的なデータストレージ、ダッシュボード、AIオーケストレーション、フリート管理。どちらのレイヤーも他方に従属していません — 相互補完的です。
| 側面 | 従来のSCADA | IronFlock |
|---|---|---|
| エッジの役割 | ダムデータソース(PLC → ゲートウェイ) | 完全なアプリケーションを実行する自律的なコンピュートノード |
| 中央の役割 | すべてを行う(ゲートウェイサーバー) | フリート全体のデータ、UI、AI、調整 |
| アプリデプロイ | 中央ゲートウェイ上のモジュール | エッジデバイス上のDockerコンテナ |
| オフライン動作 | ゲートウェイなしではエッジが停止 | エッジデバイスは自律的に動作を継続 |
| スケーリング | ゲートウェイサーバーを追加 | エッジデバイスを追加 |
| 通信 | ゲートウェイからPLCへのポーリング/OPC | リアルタイム双方向メッセージング(WAMP) |
デプロイメントオプション
IronFlockの中央サービスは、3つの構成で実行できます:
| モード | 中央サービス | エッジデバイス | ユースケース |
|---|---|---|---|
| クラウド(デフォルト) | IronFlockマネージドクラウド | インターネット経由で接続 | ほとんどのデプロイメント |
| アプライアンス | 現場に設置する事前設定済みボックス — エッジデバイスとしても機能 | ローカルネットワーク経由で接続 | 機械メーカー / OEM |
| プライベートクラウド | お客様のDMZ / VPC / データセンター | ローカルネットワーク経由で接続 | エアギャップ、規制環境 |
3つのモデルの詳細な比較についてはデプロイメントオプションを参照してください。