FIWARE for Data Spaces

概要

このホワイト・ペーパーでは、複数のドメインのスマート・アプリケーションが FIWARE ソフトウェア・ビルディング・ブロックに基づくデータ・スペースの作成にどのように参加できるかについて説明します。このようなデータ・スペースに参加するスマート・アプリケーションは、NGSI-LD などの共通の標準 API を使用し、標準データモデルに依存して、デジタル・ツイン・データをリアルタイムで共有します。各スマート・ソリューションは、データを共有する現実世界の完全なデジタル・ツイン・データ表現の構築に貢献します。同時に、他のアプリケーションによって共有されているデータを活用する可能性があります。スマート・アプリケーションは、FIWARE Data Marketplace コンポーネントに依存して、価格設定やデータ使用/アクセス・ポリシーを含む具体的な条件の下でデータを公開できます。

データ・スペースを作成するには、データの主権と信頼をサポートするフェデレーション・クラウド・インフラストラクチャとメカニズムが必要です。ただし、データ・バリューチェーンの作成とデータ・エコノミーの実現を容易にするために、追加の要素を追加する必要があります。標準 APIs は、標準データモデルと組み合わせて、パーティ間の緩い結合を可能にする効果的なデータ交換、および データ・リソースとアプリケーションの再利用性と置換可能性をサポートするために不可欠です。同様に、データ・スペースには、データ・リソースの公開、検出、および取引のためのメカニズムを組み込む必要があります。これらは FIWARE が実装する要素であり、IDSA または iSHARE Satellite technology によって提案された IDS コネクタなどのアーキテクチャ要素と組み合わせて、信頼できる効果的なデータ共有をサポートするデータ・スペースを作成できます。

欧州でのデータ・スペースの作成を検討する場合、データ・スペースの FIWARE ビルディング・ブロックと Connecting Europe Facility Building Blocks との整合性が不可欠です。IDS コネクタ・テクノロジと統合された FIWARE の成熟したテクノロジは、GAIA-X の実現を加速するのに貢献できます。GAIA-X は、データへのアクセスと共有の両方の機能を安全かつ確実に強化する、欧州でのフェデレーション形式のデータ・インフラストラクチャの作成を目的としたプロジェクトです。

FIWARE の紹介

FIWARE は、パブリックでロイヤリティ・フリーの実装主導型のソフトウェア・プラットフォーム標準を中心にオープンで持続可能なエコシステムを作成することを最終目標として作成され、スマート・ソリューションの開発を容易にし、スマート・オーガナイゼーションへの移行において組織をサポートします。技術的な観点から、FIWAREは、オープンソース・ソフトウェア・コンポーネントの精選されたフレームワークをもたらします。これらのフレームワークは、他のサードパーティ・プラットフォーム・コンポーネントと組み合わせてプラットフォームを構築し、複数のアプリケーション・ドメイン (シティ、マニファクチャリング、ユーティリティ、アグリフードなど) でのスマート・ソリューションとスマート・オーガナイゼーションの開発を容易にします。2016年後半に FIWARE Foundation が設立されて以来、活気に満ちた FIWARE コミュニティは、大企業、中小企業、テクノロジ・センタ、大学を含む90を超える組織メンバと、数百の個人メンバで構成される、真の世界的側面で形成されています。この成長と並行して、FIWARE を採用する組織の数は増え続けています。

図1 – FIWARE コミュニティの現在のメンバ組織

“Powered by FIWARE” (FIWARE を搭載した) ソフトウェア・アーキテクチャはすべて、現実世界のデジタル・ツイン・データ表現の管理に引き寄せられます。このデジタル・ツイン・データ表現は、センサ、カメラ、情報システム、ソーシャル・ネットワーク、モバイル・デバイスを介したエンドユーザなど、さまざまなソースから収集された情報に基づいて構築されています。常に維持され、ほぼリアルタイムでアクセス可能です (“right-time” (適時) は、一部のデータが収集されてアクセス可能になる瞬間の間隔が適切な反応を可能にするのに十分短いことを反映して、よく使用される用語です)。アプリケーションは、特定のタスクを自動化するため、または エンドユーザによる賢明な意思決定をサポートするために、このデータ (現在の値だけでなく、時間の経過とともに生成される履歴も) を常に処理および分析します。管理される現実世界をモデル化するすべてのデジタル・ツインのコレクションはコンテキスト (Context)とも呼ばれ、デジタル・ツインの属性に関連付けられたデータはコンテキスト情報 (Context Information) とも呼ばれます。

FIWARE では、デジタル・ツインは、現実世界の物理的資産 (たとえば、都市のバス、工場のフライス盤) または概念 (たとえば、天気予報、製品の注文) をデジタルで表すエンティティです。各デジタル・ツインは:

• URI (Universal Resource Identifier) で普遍的に識別されます
• URI によって普遍的に識別されるよく知られたタイプ (たとえば、バスタイプ、ルームタイプ) に属し、
• 次のように分類されるいくつかの属性によって特徴付けられます:
  • データを保持するプロパティ (たとえば、バスの “現在の速度”、または部屋の “最高温度”) または
  • リレーションシップ。それぞれが、特定のエンティティがリンクされている第三のデジタル・ツイン・エンティティを識別する URI を保持します (たとえば、コンクリートの部屋が配置されているコンクリートの建物)

デジタル・ツインの属性は、非常に静的な属性 (バスの “ナンバー・プレート” など) から、非常に動的に変化する属性 (バスの “速度” や “乗客数​​” など)、変化するがそれほど頻繁ではない属性 (たとえば、1日に2回変更される可能性のあるバスの “ドライバー”) までさまざまです。非常に重要なのは、デジタル・ツインの属性は、観測可能なデータだけでなく、推測されたデータにも限定されないということです。したがって、たとえば、ストリートのデジタル・ツインには、センサまたはカメラを介して自動的に測定される “現在の交通量” という属性だけでなく、AI アルゴリズムに基づいて計算される “30分で予測される交通量” という属性があります。これは、現在の交通データ、交通に影響を与えるその他の関連データ (たとえば、現在の天気の観測と予測、近くのイベントのスケジュールなど)、および特定の道路の交通に関する履歴情報に基づいて、この属性の値を更新し続けます。したがって、”Powered by FIWARE” アーキテクチャで管理される世界のデジタル・ツイン・データ表現には、測定可能なデータだけでなく、時間の経過とともに 取得されたデータ、その他の拡張された洞察や知識など、スマート・アプリケーションに必要なすべての情報が含まれることが期待されます。

図2に示すように、デジタル・ツイン・アプローチは、さまざまなレベルでのデータ統合の基盤を提供します。

• バーティカル・スマート・ソリューション (vertical smart solution) 内で、アーキテクチャ内の主要なビルディング・ブロックを統合する方法を解決します
• スマート・オーガナイゼーション (smart organization) 内で、システムのシステム (system of systems)・アプローチに従ってスマート・オーガナイゼーション内のさまざまなシステムの統合をサポートします
• スマート・データ・スペース (smart data space) 内で、さまざまな組織にリンクされたシステムが話し、理解する基本的な “共通言語” を確立します

図2 – デジタル・ツイン・アプローチに従ってサポートされる統合のレベル

これら3つのレベルで効果的なデータ統合をサポートするには、2つの重要な要素を標準化する必要があります。デジタル・ツイン・データにアクセスするための API と、検討中のさまざまなタイプのデジタル・ツインに関連する属性とセマンティクスを記述するデータモデルです。FIWARE コミュニティは、両方の面で標準化を推進してきました。

• NGSI API は、コンテキスト/デジタル・ツイン・データにアクセスするためのシンプルでありながら強力な RESTful API を提供します。NGSI API 仕様は、開発者からのフィードバックと実装経験に基づいて、時間とともに進化してきました。API の最初の成熟した バージョンは NGSIv2 API です。これは、FIWARE コミュニティのメンバによって定義され、現在、複数のセクタ内の本番環境の多くのシステムで使用されています。API の進化は、ETSI CIM ISG (Context Information Management Industry Specification Group) 内で行われ、FIWARE コミュニティと FIWARE Foundation のメンバが、NGSI-LD API として知られる API の進化バージョンの定義を主導しました。その仕様は2019年に ETSI によって最初に公開され、進化し続けています。
  NGSI-LD API はデータ統合 API として使用され、”Powered by FIWARE” アーキテクチャのコア・コンポーネント、いわゆる Context Broker コンポーネントによって実装されます。Context Broker のさまざまな代替オープンソース実装、つまり Orion-LD, Scorpio および Stellio 製品が FIWARE コミュニティ内で利用できます
• FIWARE Foundation によって開始された Smart Data Models initiative (GitHub) は、JSON/JSON-LD 形式で記述されたデータモデルのライブラリを提供します。これらは、NGSIv2/NGSI-LD APIs および Open API 仕様に準拠するその 他の RESTful インターフェースとそれぞれ互換性があります。イニシアチブの下で公開されたデータモデルは、schema.org と互換性があり、存在する場合は他の既存の事実上のセクタ標準に準拠します。これらは、特定のデータモデル仕様がさまざまな方法で JSON/JSON-LD にマッピングされ、それらすべてが有効であるという事実のように、開発者が直面している1つの主要な問題を解決します。スマート・データモデル・イニシアチブのおかげで、開発者は、このライブラリ内で利用できるNGSIv2/NGSI-LD APIs と互換性のある JSON/JSON-LD への具体的なマッピングに依存でき、代替マッピングから派生する相互運用性の問題を回避できます。イニシアチブの開始以来、500を超えるデータモデルが公開されており、データモデルの説明を提供する組織の数は絶えず増加しています。TM Forum や IUDX などの関連組織は、FIWARE Foundation と協力して、オープンソースのベスト・プラクティスに従って、イニシアチブのオープン・ガバナンス・モデルをサポートしています

“Powered by FIWARE” アーキテクチャのコア必須コンポーネントである FIWARE Context Broker を中心に構築されており、FIWARE Catalogue の一部としてリストされている補完的なオープンソース・コンポーネントの豊富なセットを利用できます。これらのコンポーネントは、次のカテゴリまたはチャプターに分類できます:

• IoT (Internet of Things), ロボット, サードパーティ・システムとのインターフェースの開発を容易にするコンポーネント
• コンテキスト/デジタル・ツイン・データの処理と監視、またはデータ処理エンジン (Apache Spark, Apache Flink など)、監視ツール (Grafana など)、分析プラットフォーム (Apache Superset など) との接続をサポートするコンポーネント
• ID およびアクセス管理 (IAM)、およびデータの公開と収益化 (NGSI-LD などの APIs を介してアクセス可能なデータを含む) に関連する側面をカバーするコンポーネントです

図3は、FIWARE を利用した垂直スマート・ソリューションのリファレンス・アーキテクチャを示しています。具体的な例は、ロボットを使用して倉庫から製品をピッキングおよびパレタイズするためのスマート・ソリューションに対応しています。このリファレンス・アーキテクチャは、基本的に3つのレイヤーで構成されています:

• Context Broker コンポーネントはアーキテクチャの中核であり、取り組む特定の問題に関連する現実世界のオブジェクトと概念のデジタル・ツイン表現を維持します: AGV ロボット、パレタイザー・ロボット、製品が倉庫に保管される棚セクション、AGV ロボットが 通過する必要がある自動ドア、製造現場のオペレーター、保管されている製品のアイテム、CRM システムから生成された注文などです
• Context Broker のサウスバウンドである、FIWARE IDAS フレームワークの一部として利用可能な NGSI IoT Agent は、OPC-UA IoT プロトコルをエクスポートするロボット・システムへの接続、または棚セクションのアイテムの検出などに使用される特定のセンサやアクチュエータへの接続に使用されます。または、製造現場のドアを開けることができます。それらは、IoT プロトコルと NGSI の間で必要な変換を実行します。さらに、IDAS Agent ライブラリに基づいて開発されたシステム・アダプタは、ソリューションがインターフェースする必要のある CRM および倉庫在庫管理システムへの接続に対応します。一方、FIROS/SOSS などの FIWARE コンポーネントを使用すると、ROS/ROS2 に基づくロボット・システムへの適応を実行できます。
  最後になりましたが、FIWARE コンポーネントの Kurento は、製造現場に配置されたカメラのビデオ・ストリームを処理できます。これは、潜在的な障害物や危険な状況を検出するのに役立ちます。
• Context Broker のノースバウンドでは、コンテキスト/デジタル・ツイン情報が時間の経過とともに進化するにつれて生成される履歴データのストリームのリアルタイム・ビッグデータ処理をサポートするために、多くのツールが対象とされています。
  サードパーティのオープンソース・コンポーネント (Apache Superset, Grafana) と FIWARE コンポーネント (Wirecloud など) の組み合わせが、プロセスを監視するための運用ダッシュボードと高度なデータ・マップの作成をサポートすることを目的として図に示されています。多数の FIWARE データコネクタ (Cygnus, Draco, Cosmos, STH Comet, QuantumLeap) が、FIWARE の一部として利用可能であり、これらのツールへの履歴コンテキスト/デジタル・ツイン情報の転送を容易にします

これらすべてのレイヤーを横断して、多くの FIWARE コンポーネントが ID 管理およびアクセス管理をサポートします。これらは、さまざまなレイヤー間のデータの流れを制御します。Context Broker へのアクセスに関しては、ユーザがコンテキスト/デジタル・ツイン・データの変更を更新、クエリ、またはサブスクライブできるものを確立するポリシーを適用します。図のデータの流れはサウスバウンドからノースバウンドだけではないことに注意してください。ノースバウンド・アプリケーションは、コンテキスト・データの更新を実行できます。これにより、サウスバウンドに接続されているデバイス、ロボット、またはシステムの変更がトリガーされます。

強調すべき重要な点は、FIWARE はそれをすべて使うか、使わないかではありません。上記のすべての補完的な FIWARE コンポーネントを使用する必要はありませんが、他のサードパーティ・プラットフォーム・コンポーネントを自由に使用して、選択したハイブリッド・プラットフォームを設計できます。したがって、たとえば、IDAS IoT Agent の代わりに具体的な IoT プラットフォームを使用して、図に示されているようにセンサやアクチュエーターとインターフェースすることを選択できます。FIWARE Context Broker テクノロジを使用してコンテキスト情報を管理している限り、プラットフォームに “Powered by FIWARE” というラベルを付けることができ、ソリューションもその上に構築されます。

図3 – 倉庫から製品をピッキングしてパレタイズするためのスマート・ソリューション

図4は、FIWARE を搭載したスマート・シティのリファレンス・アーキテクチャを示しています。繰り返しになりますが、Context Broker コンポーネントはアーキテクチャの中核であり、現実世界のオブジェクトと概念のデジタル ・ツイン表現を保持し、都市で何が起こっているかを記述します: ストリート、ごみ箱とコンテナ、ごみ収集車、バス、電気自動車充電器、建物、イベント、市民の主張などです。都市に展開されているさまざまな垂直スマート・ソリューション (空気品質監視、スマート・トラフィック管理、スマート・パーキング、スマート廃棄物管理など) は、Context Broker に接続され、管理する情報を提供します。街全体の全体的なコンテキスト/デジタル・ツイン表現を作成することに関連しており、それによって情報のサイロを壊します。これらの垂直スマート・ソリューションの一部は、FIWARE (図のトラフィック・コントロール、および廃棄物管理システムなど) を利用している場合があります。その場合、グローバルな都市レベルの Context Broker とのインターフェースを調整する必要はありません。他のシステムは FIWARE を使用していない場合がありますが、これらのシステムが NGSI-LD にエクスポートする API から変換を行う NGSI システム・アダプタの作成は難しくないことが証明されているため、これは大きな問題にはなりません。大事なことを言い忘れましたが、都市は貴重なデータを抽出するためのセンサ/カメラ・インフラストラクチャを展開する必要があります。

都市の完全なコンテキスト/デジタル・ツイン表現を活用して、スマート・シティ・ガバナンス・システム、または都市オペレーション・センターを開発できます。リアルタイムのビッグデータ処理ツールは、複数のソースからのデータに依存して使用でき、意思決定をサポートするためのより価値のある洞察を抽出します。同様に、監視ツールは、都市のこの全体的なコンテキスト/デジタル・ツイン表現で活用できます。

図4 – スマート・シティ・リファレンス・アーキテクチャ

これまで、FIWARE コンポーネントを使用して、デジタル・ツイン・アプローチを使用してデータ統合の2つの最初のレベルを実現する方法について詳しく説明してきました (図2を参照)。次のセクションでは、最初の2つの自然な拡張としてのデータ・スペースの作成にリンクされた、FIWARE がデータ統合の第3レベルの達成にもどのように役立つかについて詳しく説明します。実際、図4では、都市のコンテキスト/デジタル・ツイン・データ表現の一部をデータ・スペースで利用できるようにして、データ・マーケット・プレイスを通じて公開することができます。

FIWARE とデータ・スペース

データ・スペース (data space) は、参加者間で効果的かつ信頼できるデータ共有を可能にする、一般的に合意されたビルディング・ブロック (technology building blocks) を中心に構築された分散型データ・エコシステムとして定義できます。

技術的な観点から、次のことを保証するために、いくつかのテクノロジ・ビルディング・ブロックが必要です。

• データの相互運用性 (Data interoperability) – データ・スペースは、参加者間でデータを効率的に交換するための強固なフレームワークを提供し、データ・プロバイダとコンシューマの完全な分離をサポートする必要があります。これには、すべての参加者が使用する “共通言語” の採用、データ交換のための共通 APIs の採用、および共通データモデルの定義が必要です。データ交換トランザク ションとデータ出所のトレーサビリティのための一般的なメカニズムも必要です
• データの主権と信頼 (Data Sovereignty and trust) – データ・スペースは、データ・スペースの参加者がお互いを信頼し、共有するデータに対して主権を行使できることを保証するための技術的手段をもたらす必要があります。これには、参加者の ID を管理するための共通の標準の採用、参加者の真実性の検証、およびデータ・アクセスと使用制御について合意されたポリシーの実施が必要です
• データ価値の創造 (Data value creation) – データ・スペースは、参加者がデータの共有から価値を生み出すことができる多面的な市場の創造、つまり、データ・バリューチェーンの作成をサポートする必要があります。これには、データ・オファリングにリンクされた契約条件 (価格設定を含む) の定義、そのようなオファリングの公開と発見、および特定の参加者が確立された契約のライフ・サイクルをサポートするすべての必要なステップの管理を可能にする共通のメカニズムの採用が必要です。データにアクセスして使用する権利を取得します

共通のテクノロジ基盤の採用に加えて、データ・スペースにはガバナンスも必要です。つまり、参加者間で多数のビジネス、運用、および組織の合意を採用する必要があります。たとえば、ビジネス契約では、参加者間のデータの共有と、データ・スペースを通じて確立された契約をサポートする法的枠組みを規制できる利用規約の種類を指定します。一方、運用契約は、たとえば GDPR (General Data Protection Regulation: 一般データ保護規則) や金融セクタの第2決済サービス指令 (2nd Payment Services Directive: PSD2) への準拠など、データ・スペースの運用中に実施する必要のあるポリシーを規制します。また、クラウド・インフラストラクチャまたはデータ・スペースをサポートするグローバル・サービスのオペレーターが、特定のプロセスの監査またはサイバー・セキュリティ慣行の採用を可能にするために実装する必要のあるツールの定義を含む場合もあります。大事なことを言い忘れましたが、組織の合意によりガバナンス機関が設立されます (インターネットの ICANN と非常によく似ています)。それらは、データ・スペースにテクノロジ・ビルディング・ブロックを実装する製品が準拠する必要がある具体的な仕様の特定、および採用されるビジネスおよび運用上の合意を扱います。データ・スペースの作成に必要なビルディング・ブロックの完全な分類法を図5に示します。

図5 – データ・スペースのビルディング・ブロック

特定のデータ・スペース内でのデータの共有は、単一のドメインに限定されるべきではありません。これは新しい革新的なサービスの作成を大幅に制限します。個人や組織は通常同時に複数のドメインで行動し、特定のドメインで運営されている組織内で生成されたデータ (都市のトラフィックの管理など) が他のドメイン (たとえば、ロジスティクス) に関連するプロセスで活用するために共有されると、多くの機会が生まれるためです。したがって、データ・スペースのテクノロジ・ビルディング・ブロックは、ドメインに依存しない必要があります。一方、オープン・スタンダードに依存する必要があります。これにより、特定のプロバイダに縛られることなく、複数のインフラストラクチャおよびグローバル・サービス・プロバイダが出現し、データ・スペースをサポートできるようになります。これを考えると、リビング・ラボやパイロット・プロジェクトで物事を機能させることは比較的簡単ですが、成功するデータ・スペースの定義に向けた主な課題は、すべての参加者に受け入れられる必要があるため、どの具体的な標準と設計原則を採用するかを決定することです。

次のセクションでは、FIWARE がデータ・スペースの作成に必要なさまざまな技術的ビルディング・ブロックを具体化するさまざまなコンポーネントについて詳しく説明します。i4Trust イニシアチブは、これらのコンポーネントに基づいてキュレートされたフレームワークを作成しており、2021年から2023年の間にデータ・スペースの作成と先駆的な実験に利用できるようになります。

データの相互運用性のビルディング・ブロック

データ・スペースに参加するデータ・プロバイダは、事前に知られていないデータ・コンシューマがそれらのエンドポイントを介してデータを取得および消費する方法を知っていることを理解して、明確に定義されたエンドポイントでデータ・リソースを公開できる必要があります。一方、データ・コンシューマは、検出したエンドポイントを介して利用可能なデータをどのように消費できるかを知っている必要があります。これは、ワールド・ワイド・ウェブの設計で観察された重要な原則です。コンテンツ・プロバイダは、Web ブラウザがそれらに接続し、コンテンツをレンダリングおよび表示できるウェブページを取得できることを知って、エンドユーザに対して、Web サーバ (エンドポイント) に Web ページを公開します。これは、データ・スペースのすべての参加者が “同じ言語を話す” 必要があることを意味します。これは、ドメインに依存しない共通 APIs と、データ交換 (センテンスの作成方法) 用のセキュリティ・スキーマを、それらの APIs と互換性のあるデータ形式で表されるデータモデル (構築されたセンテンスで使用される語彙) とともに採用することを意味します。

NGSI API はドメインに依存しません。実際、スマート・シティ、スマート・インダストリ、スマート・エネルギ、スマート・ウォーター、スマート・アグリフード、スマート・ポート、スマート・ヘルスなどのドメインで、NGSI を使用してさまざまなシステムが開発されています。これにより、データ・ スペースに参加している各システムが、データ・スペースに接続している他のシステムがアクセス方法を知っている世界のデジタル・ツイン・データ表現を単純に強化するデータを公開するため、データ共有が容易になります。データ・スペースに参加しているシステムは、公開するデータを他のシステムが消費する可能性があることを事前に知りません。ただし、次のセクションで説明するように、データにアクセス/使用するための具体的な条件を設定できます。

図6は “Powered by FIWARE” のデータ・スペースに参加しているさまざまなシステムがどのようにデータを交換するかを示しています。Context Broker サーバは、データ・スペースに接続されたシステムがデジタル・ツイン・データを公開するためのエンドポイントです。これは、Web サーバがワールド・ワイド・ウェブ上で HTML コンテンツを公開するのと非常によく似ています。これらのシステムは、必要な情報を取得するために Context Broker サーバに接続できます。FIWARE を利用したデータ・スペースは、参加者間で非常に動的なデータ交換を要求する革新的なバリューチェーンの設計の基本であるデジタル・ツイン・データのほぼリアルタイム (right time: 適切な時間) の交換を可能にすることに注意してください。到着してタクシーに乗る旅行者が目的地に早く出発できるようにするために、特定の駅に近いストリートの信号を管理する都市のようなシナリオを考えてみてください。NGSI-LD は非常にシンプルで、作成のための使いやすい操作をもたらします。コンテキスト/デジタル・ツイン・データの更新と消費だけでなく、ジオ・クエリを含む高度なクエリや、デジタル・ツイン・エンティティの変更に関する通知を受け取るサブスクリプションなどのより強力な操作も可能です。一方、”Powered by FIWARE” のデータ・スペースは、標準のファイル転送プロトコルを使用した大きなファイルの交換もサポートできます。これは、AI アルゴリズムのトレーニングなど、特定のシナリオでこの種のファイル転送が必要になる場合があるためです。

図6 – “Powered by FIWARE” のデータ・スペースでのデータ交換

“Powered by FIWARE” のデータ・スペースに参加しているシステムは、それ自体が “Powered by FIWARE” である必要はないことに注意してください。FIWARE を使用して設計されていないシステムでも、NGSI API を使用して、処理する世界のその部分を表すデジタル・ツイン・エンティティの属性に関連付けられたデータの形式で、必要なデータを生成および消費するデータを共有できます。これは、システムによって直接実行することも、システムがデータ管理のためにネイティブにサポートする NGSI と API 間の変換を実行するようにプログラムされた NGSI システム・アダプタを介して実行することもできます。

理論的な観点から、データ・スペースに接続されたシステムは、好みの API を使用してデータを共有できる必要があります。各 API の仕様 (情報モデル) は、システムがデータ・スペースに接続するために使用するプラットフォームの一部として統合された特定のコンポーネントが、APIs から/への自動適応を実行するために動的に処理できる、ある種のマニフェストとして公開できます。ただし、このようなアプローチは重要な課題に直面しています。そもそも、このようなアプローチは、非常に単純なシナリオで、非常に単純な APIs を使用してのみ実証されています。したがって、NGSI-LD がデジタル・ツイン・データにアクセスするためにサポートするような高度な機能を活用する機能はかなり制限されます。一方、”共通言語” を作成することは、私たちが追求する種類のエコシステムを作成するのに役立つことが証明されています。HTTP と HTML が採用されていなかった場合、ワールド・ワイド・ウェブが採用のスピードを経験したかどうかを自問します。Web サーバとブラウザおよび各 Web サーバの “共通言語” には、HTTP ではなく異なるプロトコルまたは HTML ではなく異なるドキュメ ント形式を選択する機能がありました。NGSI-LD には、オープン・スタンダード (ETSI で定義) であるという利点があり、背後に強力なオープンソース・コミュニティ (FIWARE) があり、欧州内で非常に関連性があり、Connecting Europe Facility (CEF) プログラ ムの開発との整合性を確立します。特定の APIs から変換するシステム・アダプタの作成では、NGSI-LD との間で使用する必要がある場合がありますが、複雑な作業ではないことが証明されています。

前述のように、NGSI-LD API はドメインに依存しないため、あらゆるタイプのデジタル・ツインで機能するように設計されています。したがって、完全な相互運用性を実現するには、API と互換性のある形式で表現される一般的なデータモデルの採用も必要です。ここで、前のセクションですでに紹介した Smart Data Models initiative が非常に重要になります。これは、データモデル仕様がイニシアチブの下で具体的な JSON および JSON-LD 構造にマッピングされる方法に依存できる開発者に強力なリソースをもたらし、それぞれ NGSIv2 および NGSI-LD と互換性があります。

図7は、GitHub の Smart Data Models initiative 内でリソースがどのように構成されているかを示しています。データモデルは “対象” (天気、駐車場、水産養殖など) にグループ化され、検討中の複数のアプリケーション・ドメイン (スマート・シティ、スマート ・アグリフード、スマート・インダストリ、スマート・ウォーター、スマート・エネルギなど) に関連付けられたリポジトリから参照されます。特定のアプリケーション・ドメインに非常に固有の主題 (スマート・シティやコミュニティに関する “街灯” など) があり、複数のドメインに関連する主題 (たとえば、ほぼすべてのドメインに関連する “天気” または、スマート・シティおよびスマート・ウォーター・ドメインに関連する “下水”があることに注意してください)。公開されたデータモデルは、コントリビューションでロイヤリティフリーとしてオープンになっています。

オープン・ガバナンス・モデルは、新しいデータモデルのインキュベーションとさまざまな貢献の調和によるデータモデルのキュレーションを含むデータモデルのライフ・サイクルを定義するスマート・データモデル・イニシアチブのために定義されています。さまざまな活動を管理するためのプロセスと手順は、透明性と実力主義の原則に基づいて、オープンソース・コミュニティのベスト・プラクティスに従います。

図7 – GitHub の Smart Data Models の構成

データの相互運用性のビルディング・ブロックの全体像を完成させるために、FIWARE は、データの提供とデータの消費/使用のプロセスで追跡および追跡する手段を提供するコンポーネントを提供します。これは、データの出所の識別から NGSI-LD トランザクション の監査に耐えるロギングまで、多くの重要な機能の基礎を提供します。透明性と認証に強い要件があるデータ・スペースの場合、FIWARE は、トランザクション・ログのさまざまな分散台帳/ブロックチェーンへの記録を容易にするコンポーネント (つまり、Canis Major) を提供します。

データの主権と信頼のビルディング・ブロック

データ・スペースは、データ・スペースに参加する組織が他の参加者を信頼でき、データに対して主権を行使できることを保証する手段を提供する必要があります。そのためには、データ・スペースのすべての参加者が使用する成熟したセキュリティ標準に基づいて、共通のビルディング・ブロックを定義する必要があります。

データ・スペース内でサポートする最初の基本的なビルディング・ブロックは、ID管理 (IM) に関係しています。このビルディング・ブロックにより、データ・スペースに参加している組織、個人、マシン、およびその他のアクターの識別、認証、および認可が可能になります。このビルディング・ブロックは、KeyCloak などのサードパーティのオープンソース・テクノロジに基づいて実装できます が、1つの一般的な例を挙げれば、FIWARE は OpenId Connect, SAML 2.0 および OAuth2 標準をサポートする Keyrock コンポーネントを提供します。Keyrock は、欧州に配備されたデータ・スペースに非常に関連しており、欧州委員会が提供するビルディング・ブロックである eIDAS との統合も解決します。これにより、国境を越えて国の電子識別スキーム (eID) を相互承認できるため、欧州市民は、他の欧州諸国からのオンライン・サービスへのアクセス時に国の eIDs を使用できます。

2番目の基本的なビルディング・ブロックは、参加者間の信頼できるデータ交換を容易にし、データ交換に関与する参加者が本人であり、定義されたルール/契約に準拠していることを確認するものです。信頼とは、データ・プロバイダとデータ・コンシューマが、異なるセキュリティ・ドメイン間で、データ・エコシステムのメンバの ID に依存し、それを超えて信頼できるという事実を指します。ここでは、IDS Reference Architecture Model (RAM) で説明されている IDS Connector technology が確固たる基盤として出現しました。FIWARE コミュニティは、他のコア FIWARE コンポーネントと統合する方法がすでにテストされている、このテクノロジのオープンソース実装をインキュベートしました。

図8は、それぞれが異なる組織でホストされ、”Powered by FIWARE” 共通のデータ・スペースに参加している AI サービス・プロバイダ・アプリケーションと AI サービス・コンシューマ・アプリケーションがどのように相互作用するかを示しています。これは、インキュベーションされた FIWARE IDS コネクタ実装の一部であるコンポーネントの役割と他の FIWARE コンポーネントとの統合を示しています。提供される AI サービスは、高度な交通予測サービスである可能性がありますが、AI サービス・コンシューマ・アプリケーションは、特定の都市で実行される交通管理システムである可能性があります。AI サービスの消費者は、ストリートに配置された IoT センサを介して測定された現在のトラフィック・レベルに基づいて、ほぼリアルタイムのトラフィック予測を組み込むことを望んでいます。コンシューマ・アプリケーションで実行されている Context Broker コンポーネントは、特定のストリートの属性 “現在のトラフィック” の更新に基づいて通知を送信します。これらの更新は AI サービスに通知され、AI アルゴリズムを適用して (たとえば Apache Spark を使用して) 値がリアルタイムで処理されます。約30分で予測される交通量が計算され (たとえば、”低”, “中”, “高” の値が生成されます)、変更が発生すると、指定された通りの属性 “30分での交通量” の値が更新されます。

図8 – FIWARE IAM と IDS コネクタ機能の統合

FIWARE では、IDS コネクタの実装は Kubernetes クラスタのデプロイと密接に関連しています。この点で、IDS コネクタの概念の実 装は、IDS コネクタ間でデータを交換するために使用される手順の実装だけでなく、関連するクラスタに展開されるものの監視と制御にも限定されません (たとえば、認定されたもののみを保証するコンポーネント/アプリケーションがデプロイされます)、およびクラスタ内のデータ・フローの制御により、データ・アクセス/使用制御ポリシーの実施が保証されます。この最後の目的のために、Istio のようなサービス・メッシュの概念をサポートする製品の使用が不可欠です。図8では、このようなコンポーネントは “トラフィック・ルーター” として識別されています。

IDS RAM では、現在、ID とアクセス/使用の制御が組織レベルで実行されています。認証局 (Certification Authority: CA) と動的属性プロビジョニング・サービス (Dynamic Attribute Provisioning Service: DAPS) は、データを交換する組織が既知で信頼できることを確認する責任があります。IDS コネクタは、データ交換が組織レベルで許可されていることを確認します。たとえば、図8では、AI サービスのコンシューマ側で実行されている FIWARE IDS コネクタにより、IoT Agent がローカルの Context Broker (1) でコンテキスト/デジタル・ツイン属性を更新すると、更新の転送 (2) が、この例での AI サービス・プロバイダなどの承認された組織にのみ送信されます。サービス・プロバイダ側​​で実行されている FIWARE IDS コネクタは、更新の受信元の組織が信頼できる当事者であることを確認し、そのような更新を行う権限がある、FIWARE Cosmos コンポーネントを介して Spark に転送されます。Spark ではトラフィック予測用の AI アルゴリズムが使用されます。目的が実行されます。同様に、コンシューマ側にデプロイされた Context Broker の更新が AI アルゴリズムから呼び出されると (3)、AI サービス・プロバイダ側​​の FIWARE IDS コネクタは、送信が許可されたリクエストのみが送信さ れることを確認します。AI コンシューマ側の FIWARE IDS コネクタは、受信した更新要求が信頼できる承認された組織からのもので あることを確認します。これらの検証はすべて、データ・スペースのグローバル CA + DAPS サービスに依存して行われます。

IDS コネクタを介して組織レベルで実行されるこの認証およびデータ・アクセス/使用制御手順に加えて、FIWARE セキュリティ・コ ンポーネントは、エンドユーザ・レベルでの追加のよりきめ細かい認証およびアクセス制御を可能にします。したがって、図8に戻る と、AI サービス・コンシューマ・アプリケーション側で処理される更新要求と同じように、AI サービス・プロバイダ側​​で受信される通知には、通知/要求が発行されたユーザにリンクされた追加のセキュリティ・トークン (つまり、Json Web Tokens – JWT) が含まれます。コンシューマ側とプロバイダ側​​の両方の API プロキシ・コンポーネントは、これらのトークンを検証し、FIWARE Keyrock コンポーネントでサポートされている標準の ID プロバイダ・サービスに依存する対応するユーザに関連付けられた情報を取得しま す。アクセス制御を管理するために、標準の XACML プロセスが実装されています。API プロキシはPolicy Enforcement Point (PEP) の役割を果たし、FIWARE AuthZForce コンポーネント (または Keyrock) は、Policy Decision Point (PDP) 機能を実装します。つまり、プロキシは特定のユーザのユーザ情報を具体的な通知/要求に関する情報とともに PDP に転送し、PDP はそれらの資格を持つユーザが特定の操作を実行する資格があるかどうかを確認します。FIWARE は、API プロキシの代替実装、つまり Wilma, API Umbrella, CoatRack を提供します。これらはすべて、Keyrock または OpenID Connect, OAuth2, XACML 標準を実装するサードパーティ製品と互換性があります。Keyrock は、Policy Administration Point（PAP）および Policy Management Point（PMP）の標準 XACML 機能も実装しています。

データ価値創造のビルディング・ブロック

参加者の緩い結合は、データ・スペースの基本原則です。データ・プロバイダとコンシューマは、必ずしもお互いを知っているとは限りません。したがって、データ・リソースをビジネス価値のある真のアセットとして管理できるようにするビルディング・ブロックを組み込むことが不可欠になります。公開、発見、そして最終的には取引できるアセットです。このようにして、革新的なサービスを生み出すことができる多面的な市場の創造を後押しします。FIWARE Business Application Ecosystem (BAE) コンポーネントを使用すると、データ・スペースの参加者が、所有するデータ・アセットに関するオファリングを公開するために信頼できるマーケットプレイス・サービスを作成できます。プラグインを介してさまざまなタイプのデータ・アセットを定義できますが、デフォルトでは3種類の標準データ・アセット・タイプがサポートされています。つまり、静的データ・ファイル、明確に定義されたエンドポイントで NGSI-LD を介して提供される適切なタイミングのデータ・リソース、およびデータ処理サービスです。NGSI-LD を使用して、入力データを提供し、結果を適切なタイミングで公開するための明確に定義されたエンドポイントを関連付けました。マーケットプレイス・サービスには、ポータルまたは APIs を介してアクセスできます。マーケットプレイス・サービスのユーザは、ポータルを介したエンドユーザ または APIs を介したアプリケーションのいずれかで、次の主なアクションを実行できます:

• プラグインを介して新しいデータ・アセット・タイプを定義
• 定義されたデータ・アセット・タイプに関するオファリングの登録。これは通常、アセットの説明、背後にあるデータモデル、データ・アセットを介したエンドポイント (URLs) にアクセスできることを意味し、非常に重要なこととして、SLA を含むデータ・アセットに関する契約条件が法的に定義されます。条項、アセットのユーザが準拠する必要のあるアクセス制御ポリシー、および関連する価格設定スキーマで、これは以下に基づく場合があります:
  • 無料アクセス (Free access) (オープンデータ): ユーザはお金を払わない
  • 1回限りの支払い (One-time payments): ユーザは1回だけ支払います。
  • 定期的な支払い (Recurring payments): ユーザは、一部のデータにアクセスするために定期的 (月次、年次など) に支払います。さらに、ユーザはサブスクリプションをキャンセルできますが、データにアクセスできなくなります
  • 使用量支払い (Usage payment): ユーザは使用量ごとに支払います。支払いは、消費された情報の量に基づいています
• 選択した基準に基づいて既存のオファリングをナビゲートおよび検索/検出する機能

以下は、FIWARE BAE マーケットプレイスに関連付けられているバックエンド・コンポーネントと APIs のリストです:

• マーケットプレイスの構成をサポートする標準の TM Forum APIs を実装するバックエンド:
  • カタログ管理 API
  • プロダクト注文管理 API
  • 製品在庫管理 API
  • パーティ管理 API
  • 顧客管理 API
  • 請求管理 API
  • 使用管理 API
• 評価、課金、および請求のバックエンド
• 収益決済および共有システム
• 認証、API オーケストレーター、および Web ポータル

図9は、i4Trust プロジェクト用にデプロイおよび構成された FIWARE データ・マーケット・プレイス・ポータルを示しています。

図9 – FIWARE データマーケットプレイスポータル

FIWARE は、データ・アセットにリンクされたデータ・リソースを公開するためのコンポーネントも備えており、その周りのオファリングは FIWARE データ・マーケット・プレイスを通じて管理されます。この目的のために、Idra パブリケーション・プラットフォー ムを用意し、市場で広く採用されているオープンデータ・パブリケーション・プラットフォームである CKAN オープンデータ・プラットフォームの拡張機能も開発しました。これらの拡張機能は、強化されたデータ管理機能と、NGSI を含む FIWARE テクノロジとの統合をサポートします。特に、CKAN が提供するデータ公開および検出機能は、次の機能で強化されています:

• 適時 (ほぼリアルタイム) のデータ公開 – この拡張機能のおかげで、CKAN は、静的ファイルにリンクされたデータ・リソースをカタログの一部として一覧表示するだけでなく、デプロイされた Context Broker コンポーネントによって提供される NGSI-LD リクエストにリンクされたデータ・リソースも一覧表示します。データ・スペースで。これにより、パブリケーション・プラットフォームがサポートする DCAT 機能に依存するデータ・リソースを検出できるようになります
• Keyrock コンポーネントに基づく ID 管理、認証、およびアクセス制御機能 – したがって、全体的なデータ・スペース・レベルで採 用されている OpenId Connect, OAuth2 および XACML 標準をサポートします
• 価格設定されたデータ・リソースの公開 – この拡張機能のおかげで、カタログの一部としてリストされているデータ・リソースを、データ・マーケット・プレイスに表示されるオファリングにリンクされているものとしてマークすることができます。したがって、ユーザはこれらのデータ・リソースをクリックし、マーケットプレイスに移動してアクセス権の取得を続行できます
• 強化されたデータ視覚化 – この拡張機能を実現する WireCloud (構成可能なダッシュボード・コンポーネント) のおかげで、適応性のある増分データを視覚化を作成できます。このようにして、売り手はデータの表示方法を決定できます

欧州のデータ・スペースの開発に向けて

Connecting Europe Facility (CEF) プログラムとの連携

CEF Telecom program の一部として作成された ConnectingEurope Facility (CEF) Digital programme は、市民、企業（中小企業を 含む) の日常生活と、公的または私的組織が使用できる成熟した技術的および組織的 Building Blocks に基づく堅固な欧州横断デジタル・サービス・インフラストラクチャ（DSI）の展開による管理の真の改善を追求することを目的としています。CEF Digital は、すぐに導入でき、持続可能で長期的に維持される運用サービスの提供に重点を置いています。CEF Telecom program を明確にする両方の法的文書 (CEF Regulation と CEF Regulation) は、デジタル・シングル・マーケットの達成へのプログラムの貢献を繰り返し認識しています。進行中のタスクとして、CEF Digital Building Blocks に基づくCEF DSIs の展開のおかげで、すべてのレベルでのデータの 使用と処理が改善され、これにより加盟国間と相互運用可能なクロス・フロンティアで複製可能なソリューションの作成が可能になることが意図されています。このイニシアチブは、欧州経済の競争力を強化し、欧州社会を前進させるインターナル・デジタル・シングル・マーケットの完成と持続可能性を効果的にサポートします。

欧州委員会 (European Commission: EC) は、Digital CEF (Connecting Europe Facility) Building Blocks program 内の CEF Building Block として FIWARE Context Broker テクノロジを正式に採用しました。一方、FIWARE Keyrock コンポーネントは eID CEF Building Block と正常に統合されており、欧州全土のユーザ (組織または個人) を電子的に識別する手段を提供します。大事なことを言い忘れましたが、FIWARE には、コーディングなしの構成によって、ブロックチェーンまたは分散型台帳に格納する Context Broker トランザクション (更新, クエリ, 通知など) の具体的なログを定義するのに役立つコンポーネントが組み込まれています。このようなコンポーネントは、2019年に CEF ビルディング・ブロックの一部として組み込まれた European Blockchain Service Infrastructure (EBSI) との統合をサポートします。

これは、提案されたデータ・スペースのビジョンが、欧州連合に関して CEF デジタル・ビジョンと戦略との強力な整合性をもたらすことを意味します。

欧州のデータ・スペースの具体化

2020年2月、欧州委員会は、EU 内で効率的かつ安全にセクタ間で共有および交換されるデータのシングル・マーケットを作成することを目的とした European Strategy for Data (データに関する欧州戦略) を発表しました。この取り組みの背後には、自己決定、プライバシー、公正な競争という欧州の価値観に適合する方法で欧州のデータ経済を推進するという委員会の目標があります。これを実現するには、データへのアクセスと使用のルールが公正、明確、かつ実用的である必要があります。これは、欧州のデータ経済が急速に成長し続けているため、特に重要です。2018年の3,100億ユーロ (GDP の2.4%) から2025年までに推定8,290億ユーロ (GDP の5.8%) になります。

欧州データ戦略の目玉は “データ・スペース” の概念であり、委員会は9つの初期ドメインを定義し、すべてセクタ固有の要件によって推進されています。実際、委員会は、次の9つセクタから始めて、戦略的経済セクタと公益領域のための欧州のデータ・スペースの開発を推進しています: インダストリ (マニファクチャリング), グリーン・ディール, モビリティ, 健康, 金融, エネルギ, 農業, 行政, スキルの９セクタ。データ・スペースは、ドメイン固有の課題や法律に対処するデータ・プール, 技術ツール, インフラストラクチャの可用性を高める一方で、欧州のデータ戦略は、これらのデータ・スペースを相互接続する必要があり、この課題には特別な注意が必要であることを認めています。しかし、欧州はゼロから始める必要はありません。特定のドメインやセクタ内でのデータ共有と交換は、既存のイニシアチブですでに行われています。ただし、これらのイニシアチブはそれぞれ独自のアプローチに従っているため、常に相互運用できるとは限りません。

他のテクノロジ・インフラストラクチャ (インターネットなど) と同様に、データ・スペースは基本的にセクタに依存せず、多くの要件と機能は、異なるセクタやデータ・スペース間で類似または同一ですらあります。したがって、利用可能な技術ソリューションと標準がたくさんあるため、データ・スペースの基盤を作成することは、主に技術的な課題ではありません。相互運用可能なデータ・スペースに向けた主な課題は、すべての参加者に受け入れられるオープン・スタンダード・ベースのビルディング・ブロックと設計原則について合意することです。パイロット・アプリケーション、概念実証、およびリビング・ラボで機能させるのは比較的簡単ですが、本当の課題は、相互運用性を新しい基準に収束させ、大量の採用とスケーラビリティを可能にすることにあります。CEF (Connecting Europe Facility) Digital program との連携は、このプログラムが欧州でデジタル・サービス・インフラストラクチャを作成するためのビルディング・ブロックをもたらすことに正確に専念しているため、非常に望ましいでしょう。

一方、GAIA-X は、欧州でデータ・インフラストラクチャのフェデレーション形式を作成することを目的としており、データへのアクセスと共有の両方の機能を安全かつ確実に強化します。このイニシアチブは、創設以来、力を合わせ、既存のアセットを活用して市場へのソリューションの提供を加速する機会をもたらすため、多くの認識を高めてきました。

前に説明したように、IDSA は、信頼とデータ主権が最も重要なもののいくつかであるデータ・スペースを作成するために必要ないくつかのアーキテクチャ要素を提供しています。これらは必要ですが、市場で受け入れられ、適応されている実際のリビング・データ・スペースを作成するには十分ではありません。標準 API、標準データモデル、およびマーケットプレイス機能も必要であり、これが FIWARE エコシステムのコアの強みです。テクノロジ・ビルディング・ブロックに関する両方のイニシアチブの補完性を図10に示します。FIWARE Context Broker テクノロジは、Connecting Europe Facility (CEF) program のビルディング・ブロックの1つとして2019年に採用され、データ・スペース (eIDAS, EBSI など) の作成のために他の関連するCEF Building Block とスムーズに統合されることが証明されています。これは、この重要なプログラムと連携する機会をもたらすでしょう。その結果、FIWARE と IDSA の緊密なパートナーシップにより、GAIA-X に基づくデータ・スペースの成功に対する両方のエコシステムの協調的な貢献が保証されています。

図10 – データ・スペースを作成するためのIDSAと FIWARE の配置

IDSA ロゴの付いたビルディング・ブロックのラベル付けは、IDSA が仕様を作成したか、仕様に取り組んでいることを意味します。FIWARE ロゴのラベル付けは、FIWARE コミュニティがコンポーネントのオープンソース実装を作成し、最終的には標準化活動を推進していることを意味します。両方のロゴが存在する場合、オープンソース実装アプローチに従った仕様の進化に関連するコラボレーションの機会が特定されています。

結論

FIWARE は、効果的かつ信頼できる方法でデータへのアクセスと共有を可能にするデータ・スペースの作成に役立つ重要なビルディング・ブロックをもたらします。FIWARE テクノロジのオープンソースの性質は、少数のプレーヤーだけでなく、複数のプロバイダが関与できるフェデレーション・インフラストラクチャとしてこれらのデータ・スペースの作成を促進します。FIWARE は今日、IDS および CEF Building Block と互換性のある成熟したテクノロジをもたらし、市場へのデータ・スペースの提供と、欧州での GAIA-X のようなイニシアチブの実現を加速する可能性があります。さらに、FIWARE エコシステムは、その間に世界規模で受け入れられ、適応される標準を作成する能力を証明しました。実際、南北アメリカ、アフリカ、インド、またはアジアのソリューション・プロバイダとエンドユーザは、FIWARE の標準とテクノロジに基づいてスマート・ソリューションを構築しています。FIWARE を活用することで、ソリューションを作成し、グローバル規模でも採用できるデータ・スペースの標準を定義する同じ可能性があります。