FIWARE Context Information Management

FIWAREによるコンテキスト情報管理
(Context Information Management with FIWARE)
José Manuel Cantera Fonseca (@jmcantera)
Senior Expert - Technical Lead & Architect
FIWARE Foundation e.V.
May 2018 (Aligned with ETSI ISG CIM)
(Translated into Japanese by Kazuhito Suda k@fisuda.jp)

2
新しいデジタルライフは、コンテキスト・データを重視します
コンテキスト・データは表現します、何が起きているのか、どこで、
いつ、なぜ...

3
Tractor
• Location
• Speed
• Direction
Crop
• Humidity
• Leaf area
• Age
Drone
• Location
• Battery level
• Speed
• Direction
… アグリフード
でも
都市だけでなく
…

4
Tanker
• Driver
• Location
• Max Volume
• Current Level
• Speed
• Direction
Gas Tank
• Station
• Max Volume
• Current Level
• Min Threshold
• Temperature
Station
• Location
• Owner
• SLA
… インダストリー
やエネルギーでも
都市だけでなく
…

FIWARE:コンテキスト情報管理の標準を推進
 FIWARE NGSI は、コンテキスト情報管理のためのオープンでロイヤリティフリーのシンプ
ルで強力な標準 API です  ETSI 仕様として公開
 JSON を使用した RESTful API は、どの Web /バックエンド開発者もすぐに使用できます
 パワフル: FIWARE NGSI geo-queries と Linked Data (JSON-LD) をサポートしています
5
アプリケーション/サービス
Bus
• Location
• No. passengers
• Driver
• Licence plate
Parking
• name
• totalSpotNumber
• availableSpotNumber
• location
• floorNumber
Shop
• Location
• Business name
• Franchise
• Offerings
コンテキスト情報
FIWARE NGSI API
コンテキスト情報は、IoT だけでなく、
さまざまなソースから来る可能性が
あります
ETSI : European Telecommunications Standards Institute

7
コンテキスト情報管理のアーキテクチャ (I)
集中 (Centralized) 分散 (Distributed)

8
コンテキスト情報管理のアーキテクチャ (II)
フェデレーション (Federated)

10
情報モデル (UML として)

11
情報モデル - ハイライト
 NGSI Entity  物理オブジェクトまたは仮想オブジェクト
 (1つの) Entity Type を持ちます
 Entity ID によって一意に識別されます (URI)
 Entity には、name で識別される0個以上の attributes があります
 Property --> Entitiy の静的または動的な特性
 GeoProperty (地理空間的コンテキスト)
 TemporalProperty (時間コンテキスト)
 Relationship リンクされたエンティティとの関連付け (単方向性)
 Properties には value があります
 NGSIの値は単一 (Number, String, boolean), または複雑 (Array, Structured Value) にすることがで
きます
 Relationships には object があります
 別の entity (relationship のターゲット)。ターゲットはコレクションにすることができます

12
情報モデル - ハイライト (II)
 クロスドメイン, 情報にコンテキストを与えるためのコア・プロパティ
 location  地理空間ロケーション, GeoJSON としてエンコード
 observedAt  観測タイムスタンプ, ISO8601 としてエンコード (timestamp)
 createdAt  (entity, attribute の) 作成タイムスタンプ. Orion では dateCreated
 modifiedAt  (entity, attribute の) 更新タイムスタンプ. Orion では dateModified
 unitCode 測定単位, UN/CEFACT によって義務付けられているようにエンコード
 推奨する方法
 エンティティを識別するために URIs を使用する.
 既製の URN スキーマを提供しています。id が参照するエンティティ・タイプを事前に
知ることができます
 urn:ngsi-ld:<Entity_Type_Name>:<Entity_Identification_String>

1
3
例
Source: ETSI
Specification

15
クラシカルな JSON 表現 (別名 Orion / NGSIv2)
{
"id": "urn:ngsi-ld:Vehicle:A4567",
"type": "Vehicle",
"brandName": {
"type": "Property",
"value": "Mercedes"
},
"isParked": {
"type": "Relationship",
"value": "urn:ngsi-ld:OffStreetParking:Downtown1",
"metadata": {
"observedAt": {
"value" : "2017-07-29T12:00:04",
"type" : "DateTime"
},
"providedBy": {
"type" : "Relationship",
"value" : "urn:ngsi-ld:Person:Bob"
}
}
}
}
{
"id": "urn:ngsi-ld:OffStreetParking:Downtown1",
"type": "OffStreetParking",
"availableSpotNumber": {
"type": "Property",
"value": 121,
"metadata" : {
"observedAt": {
"value" : "2017-07-29T12:00:04",
"type" : "DateTime"
},
"reliability": {
"type" : "Property",
"value" : 0.7
},
"providedBy": {
"type" : "Relationship",
"value" : "urn:ngsi-ld:Camera:C1"
}
}
},
"location": {
"type": "geo:json",
"value": {
"type": "Point",
"coordinates": [-8.5, 41.2]
}
}
}

16
注釈 – NGSIv2 表現
 metadata ディクショナリでは、ネストされたプロパティおよび/またはネストされた
リレーションシップ
 整数、浮動小数点数などのデータ型名を使用して属性にラベルを付ける必要がありますか
、または、API 実装でそれらを埋めることができますか？
 それは本当に必要なのでしょうか？ランタイムは JSON メンバのデータ型をすでに提供しています
 タイムスタンプの例外は “DateTime” です (Orionの実装にはこれが必要です)
 注: NGSI-LD では “DateTime” は “TemporalProperty” にマップされます
 “location”, “observedAt” などとは異なる他のメタデータか属性名を使用するべきですか？
 私たちはそれをお勧めしません。あなたの状況を調和させてください！
 単純なエンティティ識別子、つまり URIs を使用することは可能ですか？
 私たちはそれをお勧めしません
 JSON-LD (NGSI-LD) へのスムーズな移行を有効にしてください!!

17
JSON-LD (RDF フレンドリー) 表現 (別名 NGSI-LD)
{
"type": "Vehicle",
"brandName": {
"type": "Property",
"value": "Mercedes"
},
"isParked": {
"object": "urn:ngsi-ld:OffStreetParking:Downtown1",
"observedAt": "2017-07-29T12:00:04",
"providedBy": {
"object": "urn:ngsi-ld:Person:Bob"
}
},
"@context": [
"http://uri.etsi.org/ngsi-ld/coreContext.jsonld",
"http://example.org/cim/commonTerms.jsonld",
"http://example.org/cim/vehicle.jsonld",
"http://example.org/cim/parking.jsonld"
]
}
{
"availableSpotNumber": {
"type": "Property",
"value": 121,
"observedAt": "2017-07-29T12:05:02",
"reliability": {
"type": "Property",
"value": 0.7
},
"providedBy": {
"object": "urn:ngsi-ld:Camera:C1"
}
},
"location": {
"type": "GeoProperty",
"value": {
"type": "Point",
}
},
"@context": [
]
}

18
注釈 – NGSI-LD vs NGSIv2 (Orion)
 NGSI-LD: NGSIv2 との主な構文上の違い:
 metadata 辞書は不要になりました
 リレーションシップのターゲットをエンコードする “object”フィールド
(JSON-LDに準拠するために "value“ フィールドをオーバーロードできません)
 GeoProperty 対 geo:json
 TemporalProperty 対 DateTime
 JSON-LD @context を含む  “Unambiguous Semantics”
 古典的な表現と JSON-LD 表現の間には直接のマッピングがあります
 ネストされたプロパティとリレーションシップが直接の子である場合
（1つのネストレベルのみ）
 FIWARE が提供するプラグイン (proxy-wrapper) があり、これを使用して
JSON-LD 表現で直接作業することができます。次のスライドを参照してください

19
注釈 – NGSI-LD
 JSON-LD “@context” メンバとは何ですか?
 これは、(ローカル)用語から URIs (完全修飾名)への明確なマッピングを提供
します
 “Vehicle”: “http://myvocabulary.org/Vehicle”
 メインの JSON ドキュメントの外部にあるプロパティのデータ型を指定する
ことができます
 例. http://schema.org/DateTime
 一般的に、あなたはそれについて心配するべきではありません！
 ドメイン固有のデータモデル設計者が既製品として提供しています,
例. Schema.org
 デフォルトの @context は常に暗黙的に存在します

20
簡略化された表現 (keyValues)
{
"name": "Downtown One",
"availableSpotNumber": 121,
"totalSpotNumber": 200,
"location": {
"type": "Point",
},
"@context": [
]
}
NGSI-LDおよびNGSIv2に相当

コンテキスト情報のプロビジョン
21

22
HTTP バインディング (I)
 エンティティの作成
 POST {apiEndPoint}/entities/
 201 Created. Location /entities/{entityId}
 エンティティの削除
 DELETE {apiEndPoint}/entities/{entityId}
 204 No Content
 404 if entity does not exist
 エンティティに新しい属性を追加
 POST {apiEndPoint}/entities/{entityId}/attrs/
 201 Created. エンティティが存在しなければ、404
 ペイロードには、追加される新しい属性を持つエンティティの断片が含まれます
 属性が既に存在する場合は上書きされます..
注: Orion では、API エンドポイントは /v2 です

23
HTTP バインディング (II)
 エンティティ属性の更新
 PATCH {apiEndPoint}/entities/{entityId}/attrs/
 204 No Content
 ペイロードには、属性の新しいコンテンツとエンティティの断片が含まれます
 属性は既に存在していなければなりません。それ以外の場合は 404 エラー
 エンティティ属性の削除
 DELETE {apiEndPoint}/entities/{entityId}/attrs/{attributeName}
 204 No Content
 属性またはエンティティが存在しない場合、404

コンテキスト情報の消費
24

25
HTTP バインディング (I)
 id でエンティティを取得
 GET {apiEndPoint}/entities/{entityId}?attrs=<attrList>
 関連エンティティを表す JSON オブジェクトを返します
 attrs は、検索される属性のリスト(コンマ区切り)です。各リスト要素は、Property
または Relationship の名前です
 attrs が存在しない場合、すべてのエンティティの属性が取得されます。

26
HTTP バインディング (II)
 エンティティのクエリ
 GET {apiEndPoint}/entities/?
 type<typeList>
 &id=<idList>
 &idPattern=<RegExp>
 &q=<Expression>
 &attrs=<attrList>
 リストはコンマ区切りです
 q 受け入れられた式
 <attribute>==<value>, !=, <, <=, >=, パターン・マッチング
 タームを分離するために ; を使用します (論理積)
 エンティティリストを JSON 配列として返します。ページネーションが利用可能です
(limit, offset パラメータ)

27
HTTP バインディング (III)
 ジオ・クエリ
 GET {apiEndPoint}/entities/?
 &georel. ジオ・リレーションシップ (near, contains, intersects, overlaps, etc.)
 &geometry. GeoJSON リファレンス・ジオメトリ (Point, Polygon, etc.)
 &coordinates. 文字列としてエンコードされた GeoJSON 座標の配列
 &coords (Orion Broker). 注意してください. 順序は lat,long (GeoJSONの反対).
 例
 参照点の半径 2km にあるエンティティを取得
 georel=near;maxDistance==2000&geometry=Point&coordinates=[-4,55]  ETSI
 georel=near;maxDistance:2000&geometry=point&coords=55,-4 <– Orion はこれをサポート
 ジオ・クエリは、コンテンツ・ベースのフィルタ・クエリと組み合わせることが
できます

コンテキストのサブスクリプション
28

29
コンテキストのサブスクリプション – 説明
 コンテキスト情報の変更をサブスクライブすることができます。
つまり、通知を受け取るよう依頼することができます
 以下において、サブスクリプションできます
 特定の Entity id / Entity のセット / 任意の Entity
 Entity Type / Entity Types のセット
 特定の監視対象の attribute のセット /エンティティまたはすべてのエンティティの任意の attribute
 さらに、提供することができます
 通知されたエンティティによって満たされなければならないクエリ
 例: temperature > 20 ときのみ通知
 通知されたエンティティによって満たされなければならないジオ・クエリ
 例:エンティティはこのエリアにあるときのみ通知 (GeoJSON polygon としてエンコード)
 通知は、サブスクリプションによって記述された通知の詳細に従って、影響を受ける
エンティティの JSON 配列として、HTTP POST リクエストを介して配信されます

30
コンテキストのサブスクリプション – JSON 表現
{
"id": "urn:ngsi-ld:Subscription:5aeb0ee97",
"type": "Subscription",
"entities": [
{
"type": "Vehicle"
}
],
"watchedAttributes": ["speed"],
"q": "speed>50",
"geoQ": {
"georel": "near;maxDistance==2000",
"geometry": "Point",
"coordinates": [-1,100]
},
"notification": {
"attributes": ["speed"],
"format": "keyValues",
"endpoint": {
"uri": "https://putsreq.com/2ZvwbG0bl1NvZF1KLTjo",
"accept": "application/json"
}
},
"@context": [
"http://example.org/cim/vehicle.jsonld"
]
}
{
"id": "5aeb0ee97",
"subject": {
"entities": [
{
"idPattern": ".*",
"type": "Vehicle"
}
],
"condition": {
"attrs": ["speed"],
"expression": {
"q": "speed>50",
"georel": "near;maxDistance:2000",
"geometry": "point",
"coords": "100,-1"
}
}
},
"notification": {
"attrs": ["speed"],
"attrsFormat": "keyValues",
"http": {
"url": "https://putsreq.com/2ZvwbG0bl1NvZF1KLTjo"
}
}
}

31
コンテキストのサブスクリプション -
HTTP バインディング
 サブスクリプションの作成
 POST {apiEndPoint}/subscriptions/  201 Created
 サブスクリプションの更新
 PATCH {apiEndPoint}/subscriptions/{subscriptionId}  204 No Content. 見つからなければ 404
 サブスクリプションの削除
 DELETE {apiEndPoint}/subscriptions/{subscriptionId}  204 No Content. 見つからなければ 404
 サブスクリプションの一覧
 GET {apiEndPoint}/subscriptions/
 JSON 配列を返します
 id でサブスクリプションを取得
 GET {apiEndPoint}/subscriptions/{subscriptionId}
 JSON オブジェクトを返します
 Note: In Orion the API endpoint is : /v2

コンテキスト・ソースのレジストレーション
32

33
コンテキスト・ソースのレジストレーション – 説明
 コンテキスト情報を提供できるコンテキスト・ソースを登録することができます
 特定の Entity id / Entities のセット / 任意の Entity
 Entity Type / Entity Type のセット
 特定の Entity Attribute のセット。例. Properties また Relationships / エンティティ
または任意のエンティティの任意の Attribute
 さらに、提供することができます
 コンテキストソースに関連付けられた地理的エリア。
すなわち、コンテキスト・ソースがコンテキスト情報を有する領域です。
 例: スマート・シティ全体のコンテキスト情報を提供できるコンテキスト・ソース
 (時間範囲。最終的なNGSI-LD仕様で洗練されます)
 Orion Broker の実装では、エンティティをクエリするときにコンテキスト・ソースに
リクエストを転送することもできます

34
コンテキスト・ソースのレジストレーション – 表現
{
"id": "urn:ngsi-ld:ContextSourceRegistration:csr1a3456",
"type": "ContextSourceRegistration",
"information": [
{
"entities": [
{
"type": "Vehicle"
}
],
"properties": ["brandName","speed"],
"relationships": ["isParked"]
}
],
"endpoint": "http://my.csource.org:1026",
"location": {
"type": "Polygon",
"coordinates": [
[ [100.0, 0.0], [101.0, 0.0], [101.0, 1.0],
[100.0, 1.0], [100.0, 0.0] ] ]
},
"@context": [
"http://example.org/cim/commonTerms.jsonld",
"http://example.org/cim/vehicle.jsonld",
]
}
{
"id”: "csr1a3456"
"dataProvided": {
"entities": [
{
"type": "Vehicle"
}
],
"attrs": [
"brandName", "speed", "isParked"
]
},
"expression": {
"geometry": "polygon",
"georel": "within",
"coords": "0.0,100.0;0.0,100;1.0,101.0;1.0,100.0;0.0,100.0"
},
"provider": {
"http": {
"url": "http://contextsource.example.org"
},
"legacyForwarding": true
}
}

35
コンテキスト・ソースのレジストレーション - HTTP
バインディング
 コンテキスト・ソースのレジストレーションの作成
 POST {apiEndPoint}/registrations/  201 Created
 コンテキスト・ソースのレジストレーションの更新
 PATCH {apiEndPoint}/registrations/{registrationId}  204 No Content. 見つからなければ 404
 コンテキスト・ソースのレジストレーションの削除
 DELETE {apiEndPoint}/registrations/{registrationId}  204 No Content. 見つからなければ 404
 コンテキスト・ソースのレジストレーションのクエリ
 GET {apiEndPoint}/registrations/?<Same as Query Entities>
 ContextSourceRegistrations の JSON 配列を返します
 コンテキスト・ソースのレジストレーションの取得
 GET {apiEndPoint}/registrations/{registrationId}
 JSON オブジェクトを返します
 Note: In Orion the API endpoint is : /v2

37
FIWARE Context Broker (Orion)
MongoDB

38
注釈 – Orion
 永続的なデータストアとしての MongoDB
 “NGSIv2 フレーバー”を実装します。将来的にNGSI-LD
 マルチテナント (Fiware-Service HTTP header) 複数の Mongo データベース
 バトルテスト済み。さまざまなスマート・シティのプロジェクトに展開
 セントラル・ブローカーまたはディストリビューション・ブローカーの役割を果たすこと
ができます。フェデレーション。
 ソースコード
 https://github.com/fiware/context.Orion
 実行方法
$ wget https://raw.githubusercontent.com/Fiware/context.Orion/master/docker/docker-
compose.yml
$ docker-compose up
$ curl localhost:1026/version

39
その他の実装
 Aeron Broker (別名 IoT Broker)
 https://github.com/Aeronbroker/Aeron
 ディストリビューション・ブローカー (Distribution broker)
 実験的
 OMA NGSI10/9 準拠
 IoT Discovery
 https://github.com/Aeronbroker/NEConfMan
 ディストリビューション・ブローカーのレジストリ
 実験的
 OMA NGSI9 準拠

41
NGSI-LD 実装ロードマップ
 短期.迅速な勝利. 2018年6月予定
 Orion Context Broker の上にあるプラグイン (プロキシ・ラッパー)
 Scala / Scalatraで実装された NGSI-LD.既存のJava / Jersey 実装を削除.
 NGSIv2 表現とNGSI-LD 表現との間の自動マッピング
 docker-composeは、2つのサービスをシームレスに連携させるように構成します
 中期. 2018年12月予定
 ネイティブ実装, Orion Context Broker の新しいリリース.
 NGSIv2 表現をNGSI-LD 表現に収束させる
 目標 : 後方互換性と前方互換性のための設計
 長期. 2019年第1四半期予定
 完全な @context. 名前空間のサポート. 高度なクエリ.
 QuantumLeap プラグインによる、履歴データのサポート

42
関連コンテンツ
 Open API 仕様 (NGSIv2. NGSI-LD 近日公開)
 https://bit.ly/2I9ZWfe
 HA モードの Orion
 https://fiware-orion.readthedocs.io/en/master/admin/extra/ha/index.html
 チュートリアル (NGSIv2 フレイバー. NGSI-LD 近日公開)
 https://github.com/Fiware?utf8=%E2%9C%93&q=tutorials&type=&language=
 履歴データの生成
 http://fiwaretourguide.readthedocs.io/en/latest/generating-historical-context-information-sth-comet/how-to-
generate-the-history-of-Context-Information-using-STH-Comet/ (古い API. MongoDB ベース)
 http://fiwaretourguide.readthedocs.io/en/latest/storing-data-cygnus-mysql/how-to-store-data-cygnus-mysql/
 https://github.com/smartsdk/ngsi-timeseries-api (NGSIv2 対応, CrateDB, Grafana Ready!)
 ハーモナイズド・データモデル (NGSIv2 フレイバー. まもなく NGSI-LD)
 https://schema.fiware.org

Thank you!
http://fiware.org
Follow @FIWARE on Twitter
José Manuel Cantera Fonseca
FIWARE Foundation Senior Expert
Josemanuel.cantera@fiware.org

FIWARE Context Information Management

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Similar to FIWARE Context Information Management

Similar to FIWARE Context Information Management (20)

More from fisuda

More from fisuda (12)

FIWARE Context Information Management