Things Cloudのドメインモデル

次のセクションでは、デバイスやアセットに関するいくつかのコンセプトについて説明します。

概要

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

model

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

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

以下では上記概念をひとつひとつ詳細に、例を上げて説明していきたいと思います。 例題では Things Cloud の REST API フォーマットが使われています。他のプログラミング言語への適用性については、リファレンスガイド内の該当セクションをご覧ください。

インベントリ

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

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

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

{
	"id": "47635",
	"type": "ge_45609",
	"c8y_Relay" : 
	{
		"relayState" : "OPEN"
	},
	...
}

インベントリに保存されたアセットの他の例としてスイッチが備え付けられている部屋を考えてみましょう。(“マネージドオブジェクト"の参照しているプロパティとスイッチの"id"プロパティを比較してみましょう)

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

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

フラグメント

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

{
	"id": "47635",
	"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”)を追加すれば地図上に表示できますし、スイッチを挿入すればそのデバイスの制御コマンド(下記参照)を使って電源のオン・オフが可能になります。

フラグメントの命名規則

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

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

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

オブジェクトの識別

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

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

Identity service

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

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

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

詳細は参照ガイドの 識別情報 をご覧ください。

オブジェクト階層

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

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

Example communication hierarchy

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

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

Example asset hierarchy

階層の子のオブジェクト

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

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

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

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

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

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

インベントリの使い方

リファレンスガイド内の インベントリのリファレンス で他のインベントリ使用例をご覧ください。

Event(イベント)

イベントは 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",
	"user": "vvirtanen",
	"application": "Resort energy management",
	"activity": "login",
	"severity": "MINOR",
	"source": { "id": "47633", ... },
	...
}

アラームはイベントに加え、下記のプロパティを持っています:

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

{
	"type": "c8y_UnavailabilityAlarm",
	"time": "2010-11-13T19:28:36.000Z",
	"text": "No communication with device since 2013-11-05T15:23:55.284+09:00",
	"status": "CLEARED",
	"severity": "MINOR",
	"source": { "id": "47633", ... },
	"history": {
		"auditRecords": [ {
			"activity": "Alarm updated",
			"application": "devicemanagement",
			"user": "vvirtanen",
			"time": "2013-11-05T16:37:48.494+09:00",
			"changes": [ {
				"attribute": "status",
				"newValue": "CLEARED",
				"previousValue": "ACTIVE",
				"type": "com.cumulocity.model.event.CumulocityAlarmStatuses"
			} ],
			...
		} ]
		...
	} 
	...
}

他の例については参照ガイド内の イベント, アラーム 監査 をご覧ください。

メジャーメント

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

メジャーメントには計測された時間、メジャーメントを特定する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" },
		"P+:1": { "value": 56, "unit": "W" },
		"P-:1": { "value": 0, "unit": "W" },
		"A+:2": { "value": 231, "unit": "kWh" },
		"A-:2": { "value": 23, "unit": "kWh" },
		"P+:2": { "value": 516, "unit": "W" },
		"P-:2": { "value": 2, "unit": "W" },  
		...
	},
	...
}

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

読み取り値には、アプリケーションが必要とするかもしれない任意の追加情報を保持できます。詳細については、リファレンスガイド内の メジャーメント をご覧ください。

デバイスの遠隔制御

オペレーション

デバイスは遠隔制御および管理できます。

例:

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

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

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

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

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

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

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

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

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

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

Device control architecture

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

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

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

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

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

詳細情報はリファレンスガイド デバイス制御 をご覧ください。

センサーライブラリ

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

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

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

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

Java 開発者なら、デバイス"mo"内のスイッチの状態をチェックする場合、次のようになります:

ManagedObject mo = ...;
Relay relay = mo.get(Relay.class);
RelayState state = relay.getRelayState();

JavaScript 開発者なら、上記と同じチェックする場合、次のようになります:

var state = mo.c8y_Relay.relayState

詳細はリファレンスガイド内の センサーライブラリ をご覧ください。

Things Cloud ではセンサー・ライブラリへのご意見をお待ちしております。 Things Cloud へ自社デバイス、制御、センサー装置や他のオブジェクトを統合する際に独自で作成したフラグメントモデルが実際の使用目的を超えて一般的に適用可能だと思った場合は是非 Things Cloud のライブラリへ追加させて頂きたいと思います。その場合は Things Cloud のサポートセンターへお問い合わせください。

まとめ

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

このモデルはどんなベンダーのデバイスにも同様に構築され、多種多様なデバイスやアプリケーションの特殊性や特徴をカバーできる拡張性もあります。