データ処理とアーキテクチャ

IronFlock は、スケーラビリティ、セキュリティ、明確なデータ所有権を目的として設計された、エッジからクラウドまでのエンドツーエンドなデータ収集・保管インフラを提供します。数千のセンサーからのテレメトリを配信するケースでも、リアルタイム SCADA インターフェースを構築するケースでも、IronFlock のデータアーキテクチャは安全で分離された、アクセス可能な情報を保証します。

メッセージルーティングとセキュアレルム

IronFlock のリアルタイム通信の中核には、堅牢なメッセージルーティングクラスターがあります。このメッセージングインフラは、プロジェクト内の多様なエッジデバイスを相互に接続し、また IronFlock クラウドインフラにも接続します。

厳格なデータセキュリティと分離を確保するため、ルーティングクラスターはセキュアレルムに意味的に分割されています。レルムは隔離されたサブネットワークであり、メッセージは厳密にその中に閉じ込められます。データやコマンドはレルムを越えて移動することはありません。

エッジデバイス上で動作するアプリケーションは、ironflock-sdk を利用してこれらのメッセージングレルム上で次のいずれかの方式で通信できます：

• Publish/Subscribe (Pub/Sub)： センサーのテレメトリや状態変化を継続的にブロードキャストするのに最適です。
• Remote Procedure Calls (RPC)： アクションを直接トリガーしたり、デバイス状態を安全に問い合わせたりするのに最適です。

動的にプロビジョニングされるプロジェクトデータベース

永続的な保存と履歴分析のために、IronFlock はプロジェクトごとに専用の物理的な TimescaleDB データベースをプロビジョニングします。

このプロジェクトデータベースはデータ収集の中心拠点となります：

• アプリのデータバックエンド： プロジェクト内にインストールされたすべてのアプリのデータバックエンドは、このデータベース内に安全に格納されます。
• 直接インジェスト： デバイスアプリが ironflock-sdk でデータをパブリッシュすると、そのストリームはプロジェクトデータベースに直接受信され、整理されます。

プロジェクトデータベースはオペレーションの唯一のソース・オブ・トゥルースとして機能するため、高度な機能が開放されます：

• SQL クエリ： 履歴テーブルに対して直接強力なクエリを書けます。
• Physical AI 統合： IronFlock AI エージェントに自然言語でデータを抽出・分析・問い合わせさせられます。
• 可視化のソース： プロジェクトデータベースは、ライブボード、IoT ダッシュボード、SCADA ボードの究極のデータソースです。

データ所有権と EU データ法

IronFlock は明確な原則に基づいて構築されています：プロジェクトオーナーがデータ所有者であり、アプリ開発者ではありません。

アプリが生成するすべてのデータ — エッジデバイスからのテレメトリストリーム、イベントログ、派生的な分析結果 — は、プロジェクトオーナーに属するプロジェクトデータベースに保存されます。アプリ開発者はアプリを書きますが、そのアプリがプロジェクト内で実行中に生成したデータは、それをホストするプロジェクトだけの所有物です。

このモデルは、EU データ法（EU Data Act） の要件に直接整合します。この法は、コネクテッド製品および関連サービスの利用者に対し、デバイスが生成するデータへの完全な管理権を付与します。IronFlock では：

• 排他的コントロール。 プロジェクトオーナーはプロジェクトデータベースに対して完全な管理権を持ち、格納されているすべてのデータを読み取り、エクスポート、削除、バックアップできます。
• サイレントなデータ収集は一切なし。 アプリ開発者は、明示的に招待されない限り、プロジェクトのデータにアクセスできません。プロジェクトからアプリ開発者への隠れたデータパイプラインは存在しません。
• ポータビリティ。 すべてのデータが標準的な TimescaleDB インスタンスに格納されているため、SQL で問い合わせ、オープンフォーマットでエクスポートし、自在に移行できます — プロジェクトオーナーがロックインされることはありません。
• 粒度の細かい共有。 プロジェクトオーナーは、アプリ開発者、統合パートナー、その他の関係者をプロジェクトに招待し、特定のデータ領域に対してきめ細かなアクセス権限を付与できます。これにより、サードパーティの技術サポート、リモートメンテナンス、専門のアナリティクスサービスを、オーナーが定義し、いつでも取り消せる条件のもとで活用できます。

つまり、アプリはデータを生成しますが、そのデータを所有、コントロール、共有するのはプロジェクトオーナーです。この所有権モデルは、IronFlock プラットフォームの後付けではなく、第一級の設計目標です。

オプトアウト：IronFlock データパイプラインをバイパスする

IronFlock のメッセージング層とプロジェクトデータベースは推奨される経路です — リアルタイムルーティング、永続ストレージ、ダッシュボード対応のデータ、組み込みの所有権保証を標準で提供します。しかし IronFlock は、アプリにこのパイプラインの使用を強制しません。

IronFlock 管理下のデバイス上で動作するアプリは通常のコンテナワークロードであり、ネットワーク・システムの自由を完全に保持します。プロジェクトオーナーやアプリ開発者が別のデータ処理スタックを好む場合、アプリは次のようなことを行えます：

• 外部システムへプッシュ。 データをサードパーティブローカー（MQTT、Kafka、AMQP）、クラウドインジェストエンドポイント（AWS IoT、Azure IoT Hub、Google Cloud IoT）、またはカスタム REST / gRPC API に直接送信する。
• 代替ストレージを使用。 外部データベース（InfluxDB、MongoDB、S3、顧客所有の TimescaleDB など）に書き込む — IronFlock プロジェクトデータベースの代わりに、または併用して。
• オンプレミスシステムへのブリッジ。 既存の MES、ERP、ヒストリアン、SCADA システムとローカルネットワーク経由で直接連携し、IronFlock クラウドを経由しない。
• ミックス & マッチ。 ダッシュボードや AI 分析のためのサブセットを IronFlock に送りつつ、フル忠実度のデータを別所にストリーミングする。

この柔軟性により、IronFlock はプラットフォームをエンドツーエンドで採用するグリーンフィールド展開にも、データ送信先が譲れない既存のエンタープライズデータアーキテクチャへの統合にも適します。

IoT ダッシュボードと SCADA ボードでデータを活用する

データを視覚的に活用するのは簡単です。IoT ボードや SCADA ボードのウィジェットを構成する際、ほぼすべてのプロパティ（タイトル、値、色など）はプロジェクトデータベースのライブデータに動的にバインドできます。

Board Studio でウィジェットを編集すると、設定フィールドの下にデータバインディングスイッチがあります。テーブルの特定のカラムを選択すると、そのプロパティのためのリアルタイムチャネルが確立されます。新しいテレメトリがデータベースに到着するたびに、バインド済みのプロパティは自動的にリアルタイムで更新され、UI の手動リフレッシュは不要です。

注： ウィジェットのプロパティをデータベースに接続する詳細については、IoT ダッシュボードドキュメントのデータバインディングのセクションをご覧ください。