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": "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) があれば、そのデバイスの制御コマンド(下記参照)を使って電源のオン・オフが可能になります。

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

フラグメントの命名規則

フラグメントは、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仕様内のEventsAlarmsAuditsをご覧ください。

メジャーメント

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

メジャーメントには計測された時間、メジャーメントを特定する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 でオペレーションを作成します(ステップ1) Things Cloud はこのオペレーションを実施するためにキューイングし、すぐに制御をアプリケーションに返します。

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

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

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

Device control architecture

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

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

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

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

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

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

センサー・ライブラリ

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

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

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

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

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

まとめ

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

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