Things Cloud のドメインモデル

このセクションではThings Cloudのデバイスやアセットに関連する複数のコンセプトを説明します。

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

ドメインモデル

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

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

これにより、Things Cloud では基盤センサーネットワークで使用されるデバイスの固有仕様や通信方式から独立してIoTアプリケーションが作成できます。さらに、ある特定メーカーの専用デバイスモデル用のウェブ設定フォームのような特殊事例に対応するアプリケーションの作成も可能なのです。

以下では上記概念をひとつひとつ詳細に、例を上げて説明していきたいと思います。例題では Things Cloud の REST API フォーマットで使われているJavaScript object notation (JSON)を使用しています。Java, JavaScriptや他の環境フォーマットは開発ガイドとして記述する予定です。参照ガイドにも詳細が記載されているのでそれぞれご参照ください。

インベントリ

インベントリでは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
  • オブジェクトのタイプを特定する文字列
  • オブジェクトの最終更新時間
  • 追加フラグメント

フラグメント

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

{
    "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_Relay")も追加されています。

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

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

フラグメントの命名規則

フラグメント名の競合を避けるため、 Java や他のコンピューター言語と同様な命名規則があります。

上記の例"c8y_Position" は"c8y"(Things Cloud で予約している文字列)とアンダースコアと"Position"の組み合わせです。 センサー・ライブラリデバイスマネジメントライブラリにプラットフォームで定義された標準フラグメントのリストが掲載されています。

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

オブジェクトの識別

インベントリにある各マネージドオブジェクトはそれぞれ Things Cloud によって作成された"グローバルな" IDを持っています。この ID を使えばどんなオブジェクトもネットワーク再構築やハードウェア変更に影響を受けずに識別できます。

ほとんどの企業ITシステムやデバイスでは独自のデバイス識別基準を持っています。とくに、技術的なデバイス識別用のコードを持っているゲートウェイやデバイスがあります。例えば、スマート・メーターはゲートウェイがアクセス可能なようメーター番号によって識別されるとします。顧客関係管理システム(CRM)ではこのメーターを購入した顧客に顧客IDを付けるでしょう。そして企業資産管理システムはこのメーターをデバイスに貼られた資産タグで追跡し、さらに企業資産管理システムはメーター番号と顧客IDで追跡するでしょう。

コード変換サービス

これらの多様な識別方式をアプリケーションとできるよう、 Things Cloud ではコード変換サービスも提供しています。 Things Cloud では Things Cloud 外で使用される資産識別コードが登録でき、アプリケーションで使用しているグローバル ID とのマッピングサービス(機能)を提供しています。このサービスは(外部識別コードを登録する)エージェントと(外部識別コードからグローバル ID へマッピングする)デバイスの管理・変更を行う業務プロセスが使用します。

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

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

オブジェクト階層

インベントリ・モデルは以下の二つのデフォルト階層に対応しています:通信階層("childDevices") と資産階層("childAssets")。通信階層はデバイスが通信上どのようにプラットフォームに接続されているか追跡することができます。下図は典型的な通信階層を示します。エージェントはセンサーネットワークを Things Cloud に繋げます。センサーネットワークとはゲートウェイ装置やモデムを通して通信します。ゲートウェイは次にセンサーネットワークにあるセンサーや制御装置などのデバイスと接続します。通信階層は基盤で使用され、デバイスと通信したり通信の問題を解消します。

通信構成例

資産階層はM2Mデバイスにより遠隔監視や操作をされている資産を構成します。よって、M2Mアプリケーションにとって最も関連性があります。例えば、建築管理の資産階層には部屋の含まれたビルがあるとします。ビルは Things Cloud と接続しているビルと関連付けされ、部屋はセンサーや制御装置と関連付けられます。この階層例は下記の図を参照ください。

Example asset hierarchy

階層の子のオブジェクト

上記の二つの階層はinventory interfaceと顧客ライブラリに対応しています。顧客ライブラリは階層の子を追加したり削除する方式を提供します。階層自身は顧客アプリケーションで規定されます。通信階層はエージェントによって構築され、アセット階層はアプリケーションにより追加されます。

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

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

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

接続を切断してアンインストールしたデバイスは必ずしも捨てられ、システムから削除するとは限りません。デバイスが倉庫に返品され後日別の場所で再利用されるかもしれません。デバイスのデータやデバイス情報を維持されるか否かは業務プロセスや事例によって決まります。物理的にデバイスをインベントリから削除するということは関連データを全て失うことになります。これは古いデータのクリーンアップの場合でのみ必要でしょう。切断したデバイスのデータを維持したい場合はデバイスの識別マッピングを識別サービスから削除します。新デバイスが古いデバイスと入れ替わる場合、新しい"global"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+01:00",
    "status": "CLEARED",
    "severity": "MINOR",
    "source": { "id": "47633", ... },
    "history": {
        "auditRecords": [ {
            "activity": "Alarm updated",
            "application": "devicemanagement",
            "user": "vvirtanen",
            "time": "2013-11-05T16:37:48.494+01: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のネットワーク規制やセキュリティー条件でも機能します:

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

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

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

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

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

Device control architecture

なお、オペレーション結果の通信(ステップ4と5)はデバイス制御インターフェースとは別のチャンネルで起こることがあります。例えば、スイッチの状態が変更した場合エージェントはインベントリの更新が必要になり、アプリケーションはそれに沿ってユーザー・インターフェースを更新することになるかもしれません。他の例として、もしオペレーションをデバイスへ送信する時、通信に問題が起きたとすると、エージェントによってアラームを作動させる場合があるかもしれません。

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

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

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

詳細情報は参照ガイドデバイスコントロールを参照ください。

センサー・ライブラリ

Things Cloud には上記の通り、デバイスによらずに定義される、特定のセンシングやオペレーション特性を定義したセンサー・ライブラリ があります。1デバイスに複数のセンサーとオペレーション機能を持たせることができます。たとえば、センサー・ライブラリを使用して以下の問いにアプリケーションが答えるようにできます:

  • エネルギー測定できるデバイスが導入されていますか?
  • エネルギーの数値は何ですか?
  • そのエネルギーメーターにはオフ電源スイッチも搭載されていますか?

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

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

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

参照ガイドの"センサー・ライブラリ"で詳細情報を記述しています。

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

まとめ

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

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

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