Things Cloudのドメインモデル

概要

次の図は、IoTのデバイスやアセットの関連性を示しています。

model

インベントリ はデバイス、設定、接続など、関連するすべてのマスター・データを保存します。関連するすべてのアセットと構造情報も含んでいます。（車両、機械、ビルなど）
メジャーメント はセンサーが生成した数値データ（気温など）、またはデバイス情報をもとに生成された数値データ（デバイスの使用可否など）を含んでいます。
イベント はドアセンサートリガーなどセンサーネットワークから抽出した他のリアルタイム情報を含みます。イベントを元に、ユーザーやシステムオペレーターが行動を起こすことを要請するアラームを発生させることもできます（停電など）。さらに、セキュリティー監視のイベントは 監視ログ として保存されます。
オペレーション は実行または処理のためにデバイスに送信されるデータに関連します。例えば電力メーターのスイッチの変更オペレーション、クレジットカード情報の自動販売機への送信オペレーションなどが該当します。

Things Cloud の最も優れたアーキテクチャは、一般のデバイスやセンサーに対応する標準化された表現を定義しており、またこの表現を柔軟に拡張・改良できる設計としていることです。Things Cloud は気温センサー、スマートメーター、トラッカーなど多くの定義済み表現を持っており、ローカルのカスタマイズに適合する多くのオプションがあります。

これにより、さまざまなWeb構成やメーカーのさまざまなデバイスの特殊事例に合わせてカスタマイズされた基盤のセンサーネットワークと接続デバイスから独立してIoTアプリケーションが作成できます。

以下では上記概念をひとつひとつ詳細に、例を上げて説明していきたいと思います。Things Cloud の REST APIフォーマットとして使用する例を示します。別のプログラミング言語での使用については、Things Cloud OpenAPI仕様内の該当サンプルをご覧ください。

インベントリ

マネージドオブジェクト

インベントリではIoTソリューションに関連するデバイスや管理資産情報を保存することができます。これらをマネージドオブジェクトと呼びます。

マネージドオブジェクトは、スマート電力メーター、ホームオートメーションゲートウェイ、GPSデバイスなどの「スマートオブジェクト」である場合があります。または、センサーが設置されている部屋やGPSデバイスが搭載されている車など、監視したいアセットである場合もあります。

下記のJSONコードはマネージドオブジェクトの最も簡単な例、単純なスイッチになります。

{
	"id": "47635",
	"name": "Smart switch",
	"type": "ge_45609",
	"c8y_Relay" : {
		"state" : "OPEN"
	}
}

インベントリに保存されたアセットの他の例としてスイッチが備え付けられている部屋を考えてみましょう。（以下の子アセットリファレンスのmanagedObjectの参照しているプロパティとスイッチのidプロパティを比較してみましょう）

{
	"id": "59436",
	"type": "resortenergymgmt_Room",
	"name": "Sauna room",
	"childAssets": {
		"references" : [
			{ 
				"managedObject": { 
					"id": "47635"
				}
			} 
		]
	},
	"resortenergymgmt_RoomProperty": {
		"size": 56,
		...
	}
}

マネージドオブジェクトには一般的に下記が含まれます

オブジェクトを参照できる一意のID
オブジェクトの名前
マネージドオブジェクトの最も具体的なタイプ
オブジェクトの最終更新時間
特定の意味を持つフラグメント (例: c8y_IsDevice)
追加のカスタムフラグメント

フラグメント

例えば、メーカーにより単相電力メーターと三相電力メーターの区別がある場合、ベンダーごとに電力メーターを見分けたいとします。メーカーにより単相電力メーターと三相電力メーターの区別があるとします。これらの特性は以下のようにそれぞれの特性をフラグメントとして定義し、保存することで判別できるようになります。

{
	"id": "47035",
	"type": "elstermetering_AS220",
	"lastUpdated": "2010-11-13T18:28:36.000Z",
	"c8y_Position": {
		"alt": 67,
		"lng": 6.15173,
		"lat": 51.211977
	},
	"c8y_ThreePhaseElectricitySensor": {},
	"c8y_Relay": {
		"state": "CLOSED"
	}
}

上記の例では、c8y_ThreePhaseElectricitySensor というフラグメントが三相電力メーターの識別名となります。さらに、電源のオン・オフ用のスイッチも追加されています。

この手法により、デバイスのモデリングは、基本となるセンサーとフラグメントで表されるコントロールのモデル、センサーの集合体であるデバイス全体、コントロール、デバイス固有の外観のモデルとに分けることができます。

この手法で汎用的なアプリケーションコンポーネントの開発を可能にします。例えば、マネージドオブジェクトに位置フラグメント (c8y_Position)を追加すれば地図上に表示できますし、リレー(c8y_Relay) があれば、そのデバイスの制御コマンド（下記参照）を使って電源のオン・オフが可能になります。

フラグメントとマネージドオブジェクトの構造の詳細については、リファレンスガイドのデバイス管理ライブラリをご覧ください。

備考

インベントリ管理オブジェクトのデータモデルを設計する際には、以下を考慮してください。

1つのフラグメントにはサイズや長さの制約はありませんが、インベントリコレクション内の1つのマネージドオブジェクトエントリに対して16MiBを超えないように、JSONドキュメント全体のサイズには制限があります。1MiB未満に抑えることをお勧めします。
フラグメント内に要素の配列を含める場合は、そのようなコレクションの長さを 1k要素未満にしてください。
ルートレベルでマネージドオブジェクトに追加されたフラグメントが連続するごとに、そのようなアイテムのクエリに一定の遅延が発生します。クエリのパフォーマンスが重要な場合は、選択した1つのフラグメント内に情報を持つカスタムフラグメントを入れ子にし、ルートフラグメントの数を効果的に制限することをお勧めします。　例：

{ 
    "id": "47035", 
    "type": "elstermetering_AS220", 
    "lastUpdated": "2010-11-13T18:28:36.000Z", 
    "c8y_ThreePhaseElectricitySensor": {}, 
    "c8y_DeviceMetrics": { 
        "c8y_ConnectionMetrics": { 
            "failures": 0, 
            "successful": 1403, 
            "total": 1403 
        }, 
        "c8y_Alarms": { 
            "requested": 100, 
            "successful": 100 
        }, 
        "c8y_Measurements": { 
            "requested": 1303, 
            "successful": 1303 
        } 
    }, 
    "c8y_DeviceMetricsConfiguration": { 
        "deviceRepresentationUpdateIntervalCron": "0 22 * * *", 
        "monitorApi": [ 
            "measurements", 
            "alarms" 
        ] 
    } 
} 
```

フラグメントの命名規則

フラグメントは、Javaや他のプログラム言語と同様に、フラグメント情報を提供する異なる関係者間の競合を避けるために命名規則を使用します。

上記の例c8y_Position は「c8y」(Things Cloud で予約している文字列)とアンダースコアと「Position」の組み合わせです。これらが1つの標準フラグメントを形成します。フラグメントの定義については、「リファレンスガイド」内のセンサー・ライブラリとデバイス管理ライブラリをご覧ください。

重要

フラグメント名には、空白文字や . , * [ ] ( ) @ $ / ' のような特殊文字を含めることはできません。また、日本語の使用も非推奨です。

Things Cloud はデータを保存するときにドキュメント指向の考え方を使用します。すなわち、すべてのオブジェクトの特性はオブジェクトデータ構造から推測することができます。特定のメタ・データのモデルを別に設定・管理する必要はありません。もちろん、アプリケーションによって独自のメタ・データを追加しインベントリへ保存することも可能です。例えば、自動販売機アプリケーションが多彩な自動販売機のスロット設定をインベントリにメタ・データとして保存することができます。

オブジェクトの識別

インベントリにある各マネージドオブジェクトはそれぞれ Things Cloud によって作成された一意でグローバルなIDを持っています。

このIDは、ネットワークの再構築やハードウェア部品の変更に関係なく、常にオブジェクトに残ります。

Identity service

アプリケーションを複数のIDから保護するために、Things Cloud には、1つのアセットが外部で使用するIDをすべて登録し、これらすべてをアプリケーションが使用する単一のグローバルIDへマッピングする識別サービスが提供されています。

このサービスは、(外部IDの登録をするため)エージェントおよび、(外部IDのマップをグローバルIDへ変更するため)デバイスの再編成や変更を伴うビジネスプロセスによって使用されます。

例えば、とある家のスマートメーターが不良品だとします。そして、この家に別のメーター番号を持った新たなスマートメーターを導入するとします。この不良メーターと新メーターの交換は業務上では識別サービスの顧客に関連するアセットタグとメーター番号の変更のみで可能となるのです。その後、すでに収集されたデータも新しく読み込まれるデータも適切な顧客に関連付けられます。

詳細はThings Cloud OpenAPI仕様の IdentityAPI をご覧ください。

オブジェクト階層

インベントリ・モデルは次の2つのデフォルト階層に対応しています：通信階層(childDevices) とアセット階層(childAssets)。

通信階層はデバイスが通信上どのようにM2Mプラットフォームに接続されているか追跡することができます。エージェントはセンサーネットワークを Things Cloud に繋げます。そして、多くの場合ゲートウェイ装置やモデムを介してセンサーネットワークと通信します。逆に、ゲートウェイはセンサーネットワークにあるセンサーや制御装置などのデバイスと接続します。この典型的な通信階層を下の図に示します。

Example communication hierarchy

アセット階層はM2Mデバイスにより遠隔監視や操作をされているアセットを構成します。

例えば、建築管理のアセット階層には部屋の含まれたビルがあるとします。ビルは Things Cloud と接続しているゲートウェイと関連付けられ、部屋はセンサーや制御装置と関連付けられます。この階層例は下図をご覧ください。

Example asset hierarchy

階層の子のオブジェクト

上記の2つの階層は階層内の子を追加および削除するための手法を提供するインベントリインターフェースとクライアントライブラリに対応しています。階層自身はクライアントアプリケーションで規定されます。通信階層はエージェントによって構築され、アセット階層はアプリケーションにより追加されます。

なお、オブジェクト階層は必ずしもツリー構造である必要はありません。1つのアセットが複数の親アセットの子になってもかまいません。これによりアプリケーションで稼動グループやバーチャルネットワークなどユーザー定義のグループを追加できます。さらに、フラグメントを使えば、任意の別の階層構造を定義することも可能です。

オブジェクトのライフサイクル

先ほど記述した識別と階層のメカニズムによりどんな業務プロセスにも対応できる柔軟なデバイス・ライフサイクルのメカニズムの作成が可能になります。デバイスは初回起動時、アセットやシステムには接続されていません。新デバイスを通信階層にあるエージェントと（できればゲートウェイより間接的に）接続して初めて新デバイスが関連付けられます。関連付けられたデバイスのみ遠隔操作が可能です。デバイスをアセット階層を使用し、アセットへ関連付けることで物理的にデバイスが導入されたことが確認できます。

接続を切断してアンインストールしたデバイスは必ずしも捨てられ、システムから削除するとは限りません。デバイスが倉庫に返品され後日別の場所で再利用されるかもしれません。デバイスのデータやデバイス情報を維持されるか否かは業務プロセスや事例によって決まります。物理的にデバイスをインベントリから削除するということは関連データをすべて失うことになります。これは古いデータのクリーンアップの場合でのみ必要でしょう。切断したデバイスのデータを維持したい場合はデバイスの識別マッピングを識別サービスから削除します。新デバイスが古いデバイスと入れ替わる場合、新しいグローバルIDが作成されます。

エージェントを構築する際、デバイス・ライフサイクルをきちんと表記することが重要です。例えば、デバイスと接続しているエージェントはデバイスが通信できなくなったときにインベントリのデバイス情報を自動的に削除できると仮定してはなりません。同様に、CRMシステムと連携しているエージェントはCRMシステムから削除されたデバイスを削除できると仮定してはなりません。

詳細情報

Things Cloud OpenAPI仕様内のInventory APIにインベントリに関する詳細情報が記載されています。

イベント

イベントは Things Cloud を介してリアルタイムに情報送信する時に使用されます。

イベントには次の3つのタイプがあります:

基本の イベント は何かが起きたことを通知します。例えば、スイッチのオン・オフでトリガーする、などです。
アラーム は人手の対応が必要なイベントです。例えば、メーター改ざんを検知したり冷蔵庫内温度が閾値を超えて調節が必要になった場合、などです。
監査ログ はセキュリティーに関連した監査に必要なデータを保存します。例えば、ユーザーがゲートウェイにログインする度に監査ログを生成します。

イベントには（命名規則に従った）特定のタイプ(type)、イベントの発生した時間(time)、そしてイベントの内容(text)が含まれます。イベントはインベントリ内の source で表されるマネージドオブジェクトを含みます。以下がイベント表現の一例になります。

{
	"type": "c8y_LocationUpdate",
	"time": "2010-11-13T18:28:36.000Z",
	"text": "Location updated",
	"source": { 
		"id": "47634", ... 
	},
	"c8y_Position": {
		"alt": 67,
		"lng": 6.15173,
		"lat": 51.211977
	}
}

イベントはマネージドオブジェクトと同様に拡張が可能です。この例ではオブジェクトの情報を通知するだけでなく、新しいオブジェクトの位置をc8y_Positionというフラグメントで追加しています。

監査ログはイベントに、下記のプロパティを追加したものです。

アクティビティを実施したユーザーのユーザー名
アクティビティを実施したアプリケーション
行われたアクティビティ
重要度

監査ログの構成例です。

{
	"type": "c8y_SecurityEvent",
	"time": "2010-11-13T18:28:36.000Z",
	"text": "Gateway login failed",
	"source": {
		"id": "47633"
	},
	"user": "skywalker",
	"application": "Resort energy management",
	"activity": "login",
	"severity": "MINOR"
}

アラームはイベントに、下記のプロパティを追加したものです。

アラームが発生中か解決済みかのステータス
アラームの最終アップデートのタイムスタンプ
重要度の表示。（クリティカル・メジャー・マイナー・警告）
監査ログにイベントへの変更履歴を保存

以下はクリアされたアラーム例になります。

{
    "count": 1,
    "creationTime": "2020-03-19T12:16:31.586Z",
    "id": "20200301",
    "severity": "MAJOR",
    "source": { 
　　	"id": "251982", 
　　	"name": "My tracking device"
    },
    "status": "CLEARED",
    "text": "No data received from the device within the required interval.",
    "time": "2020-03-19T00:00:00.000Z",
    "type": "c8y_UnavailabilityAlarm" 
}

さらに詳細な情報についてはThings Cloud OpenAPI仕様内のEvents、Alarms、Auditsをご覧ください。

メジャーメント

メジャーメントはセンサーより取得したデータや統計を表します。

メジャーメントには計測された時間、メジャーメントを特定するID、フラグメントリストが含まれます。以下はメジャーメントの一例です。

{
	"time": "2011-01-02T03:04:00.000Z",
	"source": { 
		"id": "1235"
	},
	"c8y_ThreePhaseElectricityMeasurement": {
		"A+": { "value": 435, "unit": "kWh" },
		"A-": { "value": 23, "unit": "kWh" },
		"P+": { "value": 657, "unit": "W" },
		"P-": { "value": 0, "unit": "W" },
		"A+:1": { "value": 123, "unit": "kWh" },
		"A-:1": { "value": 2, "unit": "kWh" }
	}
}

インベントリと同様に特定デバイスの特性を識別するためにフラグメントが使われています。上記の例では三相電力メーターがそれぞれの相ごとの測定値を別々に送信します。上記の例の各フラグメントは個別の測定値名（例：「A+」または「A-」）にメジャーメントの実際の数値と単位を含めてマッピングします。

測定値には、アプリケーションで必要となるとするさまざまな追加情報を保持できます。詳細については、Things Cloud OpenAPI仕様内のMeasurementsをご覧ください。

オペレーション

Things Cloudでは、デバイスの遠隔制御や管理が行えます。

例：

デバイス制御：スイッチの設定、熱量制御など。
デバイス設定：タリフ表をスマートメーターに設定するなど。
デバイス保守：ゲートウェイに新しいファームウェアのダウンロードとインストールをリクエストするなど。

これらのユースケースは オペレーション をデバイスに送信することで実施されます。以下はID「42」のスイッチの状態を「OPEN」に変更させる例(一部)です。

{
	"deviceId": "42",
	"c8y_Relay": {
		"state": "OPEN"
	}
}

他のタイプのデータと同様、オペレーションもアプリケーション開発を単純化させるためセンサー・ライブラリを通して標準化されています（下記参照）。例えば、スイッチの設定はどんなメーカーのスイッチでも同じものを使用するようにします。

オペレーションはインベントリ内ではフラグメントと同じように定義されます（上記参照）。ゆえに、同様の拡張概念が適用できます。標準オペレーションと異なるベンダー独自拡張を定義することができます。Things Cloud はこのような独自拡張は拒否せず、変更も行いません。

デバイスにオペレーションを送信する

Things Cloud は信頼性のあるキューイング機構により、どんなネットワーク内でも安全にオペレーションをデバイスへ送信できます。このキューイング機構はどんなIoTのネットワーク規制やセキュリティー条件でも機能します。

デバイスの多くは、常時利用できない、信頼性の低い、低帯域ネットワークに接続されています。例えば、あるデバイスは一日一度コマンド取得のためにネットワークへ接続されるかも知れません。よって、Things Cloud は非同期的にデバイスと通信します。
デバイスの多くはインターネット通信に適していません。NATネットワーク、ファイアウォール、プロキシを通過できなかったり、パブリックネットワークに対応したセキュリティーに欠けているものが多くあります。このような場合でも、Things Cloud はデバイスを https クライアントとして接続できるようにします。
インターネットがモバイルデバイスまで届かない場合もあります。 Things Cloud はこれらのデバイスにオペレーションを送信できる push 技術を提供します。

デバイスからオペレーションを送信するには下図のようにいくつかのステップを踏む必要があります。例えば、あるユーザーがアプリケーションから遠隔制御動作（再起動など）を発信するとします。まずアプリケーションは Things Cloud でオペレーションを作成します（ステップ１） Things Cloud はこのオペレーションを実施するためにキューイングし、すぐに制御をアプリケーションに返します。

このデバイスを管轄するエージェントは、ある時点でデバイスにこのオペレーションをリクエストします。（ステップ２）これは Things Cloud のpushメカニズムですぐに行われるかもしれませんし、定期的なスケジュールとして予約されるかもしれません。

エージェントはこのオペレーションを管理するデバイスに対して実行します。（ステップ３）　そして実行結果を Things Cloud に送信します。（ステップ４）　エージェントが管理するデバイスはエージェントの直接または間接な子(childDevices) です。

最後に、アプリケーションはオペレーション結果を問い合わせできます。（ステップ５）　監査ログはオペレーションの初期リクエスト時とオペレーション実施後に作成されます。

Device control architecture

もしオペレーションをデバイスへ送信する際、通信に問題が起きた場合、エージェントによってアラームが作動されます。

時には、オペレーションのデバイス送信時とその返答の受信時の間にある程度遅延が起こる場合があります。このシステムでは、保守機能に対しエラーが報告されない限り、送信が成功したと仮定します。

信頼性のあるオペレーションを構築

オペレーションはできる限り常に冪等性を持って構築されるべきです。冪等性とは何度オペレーションを走らせても同じ結果となること意味します。

例えば、スイッチをある特定の状態にするオペレーションは冪等性があります。スイッチをオンにするオペレーションを何度走らせても結果はオンのままだからです。しかし、スイッチを切り替える(変更する)オペレーションは冪等性がありません。何度このオペレーションを走らせてもその結果はスイッチの状態に依存するため、結果が同じにならないからです。

詳細情報はThings Cloud OpenAPI仕様内のDevice control APIをご覧ください。

センサー・ライブラリ

Things Cloud には、すべてのデバイス製品で特定のセンシングや制御スキルを定義したセンサー・ライブラリがあります。１デバイスに複数のセンサーの制御機能を持たせることができます。センサー・ライブラリを使用するとアプリケーションは次の問いに答えることができます。

エネルギーを測定するためにどのようなデバイスが設置されていますか?
エネルギーの数値は何ですか？
そのエネルギーメーターにはオフにできる電源スイッチも搭載されていますか？

センサー・ライブラリには基本的なセンサーとオペレーションが多数含まれており、Things Cloud のAPIで対応しています。これは開発を単純化させるだけでなく、便利で汎用的なIoTプラグインを作成する手助けとなります。

技術的には、センサー・ライブラリではインベントリ、メジャーメント、イベント、デバイスオペレーション用の標準フラグメントを記載している命名規則(インベントリ参照)で定義しています。下記は電力メーターに使用する2つのフラグメント例になります。

{
	"id" : "121",
	"type" : "com_kamstrup_382",
	"c8y_SinglePhaseElectricityMeasurement": {},
	"c8y_Relay" : { 
		"state": "OPEN" 
	}
}

その他の例と詳細については、「リファレンスガイド」のセンサー・ライブラリを参照してください。

まとめ

Things Cloud は次のIoTシステムの管理・制御モデルを提供します。

インベントリ内にIoTデバイス、ネットワークとアセットの一元参照。
デバイスの設定
センサー装置の読み込み
オペレーション
リアルタイムイベントの制御

このモデルは、デバイスベンダー間の相違を吸収することを意図しています。さらに、多種多様なデバイスやアプリケーションの特殊機能をカバーする拡張性を備えています。