Core Context Management (コア・コンテキスト管理)

アプリケーションを "スマート" (smart) にしたい場合は、まずアプリケーションを"アウェア" (aware) にする必要があります。FIWARE は、コンテキスト情報を大量に生成、収集、公開、消費する手段を提供し、アプリケーションを真にスマートなアプリケーションに変換するために利用できます。

コンテキスト情報は、アプリケーションに関連するエンティティを特徴付ける属性に割り当てられた値によって表されます。

コア・コンテキスト管理のイネーブラの詳細については、ドキュメントを参照してください。

Orion

License

| :octocat: Git リポジトリ | 🐳 Docker Hub | 📚 ドキュメント | 🎓 アカデミー | 🎯 ロードマップ |

Orion とは何ですか？

Orion Context Broker は、NGSI インタフェースを提供する Publish/Subscribe Context Broker GE の実装です。これらのインタフェースを使用して、クライアントはいくつかの操作を実行できます :

  • コンテキスト・プロデューサ・アプリケーションを登録、たとえば、室内の温度センサ
  • コンテキスト情報を更新、たとえば、温度の更新を送信
  • コンテキスト情報の変化が起こったとき (たとえば、温度が変化したとき)、または所定の頻度で (たとえば、1分ごとに温度を取得するとき) 通知
  • コンテキスト情報をクエリ。Orion Context Broker は、アプリケーションから更新されたコンテキスト情報を格納するため、クエリはその情報に基づいて解決されます

Orion を使う理由

データ/コンテキストのシナリオを開発する場合は、Orion Context Broker のようなブローカーが必須です。コンシューマ・プロデューサ (センサなど) とコンテキスト・コンシューマ・アプリケーション (センサが提供するコンテキスト情報を利用するスマートフォン・アプリケーションなど) を仲介できるアーキテクチャ内のコンポーネントが必要です。Orion Context Brokerは、あなたのアーキテクチャでこの機能を実現します。

Orion は、FIWARE Publish/Subscribe Context Broker Generic Enabler の実装です。具体的には、次のAPI と オープン仕様を実装しています。

コンテキスト・データ管理のために、NGSI と Orion Context Broker は、さまざまな独立した標準化団体の標準または勧告として受け入れられています。たとえば、GSMA は IoT Big Data アーキテクチャの関連部分の標準として NSGI を推奨し、標準の主要な例として、Orion Context Broker を推進し、NGSI 仕様は、欧州員会によって、新しいスマート・アプリケーションと公的期間の管理のために CEF Building Block として選ばれました。

Orion context broker の使用は、FIWARE マーケットプレイスで "Powered by FIWARE" と表示されるプラットフォームまたはソリューションにとって必須です。

品質保証

Orion プロジェクトは、FIWARE の一部であり、次のように評価されています :

  • Version Tested:
  • Documentation:
  • Responsiveness:
  • FIWARE Testing:

Cygnus

License

| :octocat: Git リポジトリ | 🐳 Docker Hub | 📚 ドキュメント | 🎓 アカデミー | 🎯 ロードマップ |

Cygnus とは何ですか？

Cygnus は、コンテキスト・データ・ソースを他のサードパーティのデータベースやストレージ・システムに保存し、コンテキストの履歴ビューを作成するコネクタです。内部的には、Cygnus は、Apache Flume に基づいており、Flume はフロー・ベースのプログラミングの概念に基づくデータ・フロー・システムです。データ・ルーティング、変換、およびシステム・メディエーション・ロジックの強力でスケーラブルな有向グラフをサポートしています。システム間のデータの流れを自動化するために作られたものです。"データフロー" という用語はさまざまな文脈で使用できますが、ここではシステム間での情報の自動化された管理フローを意味します。

Cygnus 内の各データ永続性エージェントは、データの受信を担当するリスナまたはソース、Flume イベントに変換されたソースがデータを格納するチャネル、および Flume イベントを受け取るシンクの3つの部分で構成されます。そのチャネル内のデータをサードパーティ・ストレージに保存することができます。

Cygnus を使う理由

過去のコンテキスト・データを持続することは、大規模なデータ分析に役立ちます。傾向を発見するために使用することができます。また、データをサンプリングして集約して、外部データ測定の影響を取り除くこともできます。ただし、各スマート・ソリューションでは、各エンティティ型の重要性が異なり、エンティティと属性を異なるレートでサンプリングする必要があります。

コンテキスト・データを使用するためのビジネス要件はアプリケーションごとに異なるため、履歴データの永続性の標準的な使用例はありません。したがって、Context Broker に、ヒストリカルなコンテキスト・データの永続性を与えるのではなく、この役割は、構成可能な別のコンポーネント (Cygnus) に分離されています。

Cygnus は、Orion Context Broker (データの NGSI ソース) と MySQL, MongoDB などの広範な外部システムとの間のコネクタの役割を果たします。履歴データを保存できるように、コンテキスト・データを処理して永続化する必要がある場合は、Cygnus を使用する必要があります。また、Cygnus はフィルタに使用し、コンテキスト・データを Orion に再送信することもできます。

MongoDB

Cygnus プロジェクトは、FIWARE の一部であり、次のように評価されています :

  • Version Tested:
  • Documentation:
  • Responsiveness:
  • FIWARE Testing:

STH Comet

License License

| :octocat: Git リポジトリ | 🐳 Docker Hub | 📚 ドキュメント | 🎓 アカデミー | 🎯 ロードマップ |

STH Comet とは何ですか？

Short Time Historic (STH) - Cometは、Orion Context Broker インスタンスに登録されているコンテキスト・データ (すなわち、エンティティ属性値) の時間的変化に関する履歴の未処理および集約された時系列コンテキスト情報を管理、格納、検索する FIWARE エコシステムのコンポーネントです。

STH Comet を使う理由

トレンド・データの作成と分析は、コンテキスト駆動型システムの一般的な要件です。したがって、FIWARE プラットフォームは、時系列データの永続化と解釈の問題に特化した Generic Enabler (STH-Comet) を提供します。

FIWARE プラットフォーム内では、履歴コンテキスト・データをデータベースに保存することができます。これにより一連のデータ・ポイントが作成されます。各タイムスタンプ付きデータ・ポイントは、与えられた瞬間におけるコンテキスト・エンティティの状態を表します。個々のデータ・ポイントはそれ自体では無意味であり、最大値、最小値および傾向などの意味のある統計値が観測されることができるのは、一連のデータ・ポイントを組み合わせたときです。

品質保証

STH-Comet プロジェクトは、FIWARE の一部であり、次のように評価されています :

  • Version Tested:
  • Documentation:
  • Responsiveness:
  • FIWARE Testing:

Draco

License

| :octocat: Git リポジトリ | 🐳 Docker Hub | 📚 ドキュメント | 🎓 アカデミー | 🎯 ロードマップ |

Draco? とは何ですか？

コンテキスト・データ・ソースを他のサードパーティのデータベースやストレージ ・システムに永続化するコネクタであり、コンテキストの履歴ビューを作成します。 内部的には、Draco は NiFi をベースにしています。 NiFi は、複数のソースからのデータ管理と処理のための一般的なフレームワークです。

Dracoは、Orion Context Broker ( NGSI のデータ・ソース) データ・ソースと、MySQL, MongoDB などの広範な外部システム との間のコネクタの役割を果たします。コンテキスト・データを処理して永続化する 必要がある場合は、Draco を使用できます。ヒストリカルなレコードを残すことが できます。Draco はまた、コンテキスト・データをフィルタリングして再送信して、 Orion に戻すこともできます。

Draco を使う理由

ヒストリカルなコンテキスト・データを永続化することは、大規模なデータ分析に 役立ちます。傾向を発見するために使用できます。また、データをサンプリング して集約して、外在するデータ測定の影響を取り除くこともできます。 ただし、 各スマート・ソリューションでは、各エンティティ型の重要性が異なり、 エンティティと属性を様々なレートでサンプリングする必要があります。

コンテキスト・データを使用するためのビジネス要件はアプリケーションごとに 異なるため、履歴データの永続化のための標準的な使用例はありません。 したがって、Context Broker に履歴コンテキスト・データの永続化の作業を オーバーロードするのではなく、このロールは別のイネーブラに分離されています。 コンポーネントの利点の中で、Draco は柔軟なグラフィカル・インターフェイスを 提供しているため、現在のビジネス・ニーズに合わせてデータ・フローを修正する ことができます。

Quality Assurance

Draco プロジェクトは FIWARE の一部であり、 次のリリースの一部として評価されます。

  • Version Tested:
  • Documentation:
  • Responsiveness:
  • FIWARE Testing:

🆕 QuantumLeap (Incubated)

License

| :octocat: Git リポジトリ | 🐳 Docker Hub | 📚 ドキュメント | 🎓 アカデミー |

QuantumLeap とは何ですか？

QuantumLeap Generic Enabler は、スケーラブルなアーキテクチャの維持と Grafana などのビジュアライゼーション・ツールとの互換性に関して、CrateDB などの時系列データーベースに履歴コンテキスト・データを永続化することに重点を置いています。

QuantumLeap を使う理由

時系列データ分析を適切に使用するかどうかは、ユースケースと受け取るデータ測定の信頼性によって異なります。時系列データ分析を使用して、次のような質問に答えることができます。

  • 一定期間内のデバイスの最大測定値は何でしたか？
  • 一定期間内のデバイスの平均測定値は何ですか？
  • 一定の期間内にデバイスから送信された測定値の合計はどれくらいですか？

QuantumLeapは、時系列データの測定と監視に大きな柔軟性を提供し、既存の時系列ベースのデータベースを活用して、エンティティ間クエリ (たとえば、平均値の平均) などの複雑なクエリをサポートできるようにします。

QuantumLeap プロジェクトは、FIWARE の一部であり、次のリリースの一部として評価されます。

🆕 Scorpio (Incubated)

License

:octocat: Git リポジトリ 🐳 Docker Hub 📚 ドキュメント

Scorpi とは？

Scorpio は、コンテキスト情報の管理とリクエストを可能にする NGSI-LD Broker です。コンテキスト・プロデューサは、 コンテキスト情報を作成、更新、追加、削除するコンテキストを管理できます。コンテキスト・コンシューマは、必要な コンテキスト情報をリクエストし、エンティティを特定するか、エンティティ・タイプを提供して関連エンティティを 検出します。場合によっては、プロパティ値、既存のリレーションシップ、および/または GeoJSON 機能として提供される 地理的範囲に従ってフィルタリングします。

同期クエリ・レスポンス、非同期サブスクライブ/通知の2つの対話スタイルがサポートされています。通知は、プロパティや リレーションシップの変更、または固定の時間間隔に基づいて行うことができます。Scorpio は、各エンティティの最新の プロパティとリレーションシップを提供する通常のコンテキスト・インターフェースに加えて、履歴情報を要求するための NGSI-LD のオプションの一時的インターフェース(temporal interface) を実装し>ています。たとえば、指定された時間間隔内に 測定されたプロパティ値です。

Scorpio は、集中型 (centralized)、分散型 (distributed)、およびフェデレート型 (federated) を含む複数のデプロイ構成を サポートしています。上記のコンテキスト・プロデューサに加えて、NGSI-LD インターフェイスを実装するコンテキスト・ソースが 存在する場合があります。これらのコンテキスト・ソースは、リクエストに応じて提供できる情報 (情報 (値) 自体ではない) に登録できます。

分散設定の Scorpio Broker は、レジストレーションに基づいてリクエストにレスポンスするための情報を持つコンテキスト・ ソースを検出し、異なるコンテキスト・ソースからの情報をリクエストおよび集約し、リクエスト側のコンテキスト・ コンシューマに提供できます。フェデレート設定では、コンテキスト・ソースそれ自体が NGSI-LD Broker になることが できます。フェデレーションを使用して、情報を (部分的に) 共有したい複数のプロバイダからの情報を組み合わせることが できます。重要な違いは、通常、レジストレーションの粒度にあります。 たとえば、"X の建物に関する情報を持っている" の代わりに、"地理的領域内の建物のエンティティ・タイプのエンティティに関する情報を持っている" ということです。

Scorpio を使用する理由

Scorpio は　NGSI-LD を実装します。これは、NGSI v2 および OMA NGSI コンテキスト・インターフェイスの以前のバージョンの 進化版です。この標準化されたバージョンは、コンテキスト情報管理に関する ETSI Industry Specification Group によって 公開されたNGSI-LD 仕様に基づいています。

NGSI-LD には、NGSI v2 と比較して多くの新機能があります。 NGSI-LD は、属性のみを持つのではなく、プロパティと リレーションシップを区別しま>す。プロパティには値がありますが、リレーションシップは明示的に他のエンティティを参照 します。その結果、専門のナレッジ・グラフ (specialized knowledge graph) として、明示的なエンティティ・グラフがあります。 リレーションシップを追跡して、関連する関連エンティティを見つけること>ができます。NGSI-LD は JSON-LD に基づいており、 LD はリンクト・データを表します。 JSON-LD での必要に応じて、NGSI-LD は一意の URI として定義されたエンティティ・タイプ、 リレーションシップ、およびプロパティを使用します。ショートネーム文字列を使用できるため、データの表現は依然として 簡潔です。URI へのマッピングは、JSON の一部またはヘッダとして参照できる @context 要素で行われます。JSON-LD は RDF のシリアル化であるため、NGSI-LD はセマンティック・グラウンディング (a semantic grounding) を提供し、セマンティック・ ツールを使用して他の情報と組み合わせることができます。

Scorpio はさまざまなデプロイ構成をサポートしており、進化的な方法でシナリオのスケーラビリティと拡張をサポートします。 たとえば、2つの別々>のデプロイを組み合わせたり、スケーラビリティ上の理由から、単一のアクセス・ポイントを使用できる コンテキスト・コンシューマに対して完全に透過的に異なる Broker を使用したりできます。Scorpio はオプションのテンポラル NGSI-LD インターフェースも実装しているため、更新されたコンテキスト情報は、テンポラル・インターフェースを介して履歴 情報として自動的に利用可能になります。

Scorpio プロジェクトは FIWARE の一部であり、次のリリースの一部として評価されます。

🆕 Orion-LD (Incubated)

License

:octocat: Git リポジトリ 🐳 Docker Hub 📚 ドキュメント 🎓 アカデミー 🎯 ロードマップ

Orion-LD とは?

Orion-LD は、C/C++ で記述された NGSI-LD Context Broker です。 スタンドアロンの実行可能ファイルであるため、小さく、高速で、 軽量で、扱いやすいです。Context Broker により、NGSI-LD 仕様に準拠したリンクト・データ標準に基づいて、構造化された方法で 情報のコンテキストを管理およリクエストできます。 Orion-LD は、小規模なインストールや組み込み環境に適しています。現在、 標準の NGSI-LD エンドポイントのサブセットのみをサポートしています。

Orion-LD を使用する理由

Orion-LDは、NGSI-LD リンクト・データ・インターフェイスを実装します。これは、NGSI v2 および OMA NGSI コンテキスト・ インターフェイスの以前のバージョンの進化版です。この標準化されたバージョンは、コンテキスト情報管理に関する ETSI Industry Specification Group によって公開された NGSI-LD 仕様に基づいています。

NGSI-LD には、NGSI v2 と比較して多くの新機能があります。 NGSI-LD は、属性のみを持つのではなく、プロパティと リレーションシップを区別しま>す。プロパティには値がありますが、リレーションシップは明示的に他のエンティティを参照 します。その結果、専門のナレッジ・グラフ (specialized knowledge graph) として、明示的なエンティティ・グラフがあります。 リレーションシップを追跡して、関連する関連エンティティを見つけること>ができます。NGSI-LD は JSON-LD に基づいており、 LD はリンクト・データを表します。 JSON-LD での必要に応じて、NGSI-LD は一意の URI として定義されたエンティティ・タイプ、 リレーションシップ、およびプロパティを使用します。ショートネーム文字列を使用できるため、データの表現は依然として 簡潔です。URI へのマッピングは、JSON の一部またはヘッダとして参照できる @context 要素で行われます。JSON-LD は RDF のシリアル化であるため、NGSI-LD はセマンティック・グラウンディング (a semantic grounding) を提供し、セマンティック・ ツールを使用して他の情報と組み合わせることができます。