メインコンテンツに移動
AWS コミュニティ通信

デジタルツインとは ? その概念と実装を、AWS IoT Core の「デバイスシャドウ」で追う

2022-11-02 | Author : 松下 享平 (AWS IoT HERO)

はじめに

こんにちは、AWS IoT Hero の松下 (ニックネーム : Max) です。

デジタルツインという言葉をご存じでしょうか ? これからのデジタル社会において、多くのエンジニアの方が向き合うこととなる考え方です。アマゾン ウェブ サービス (AWS) でも「AWS のデジタルツイン:ビジネスの価値と成果を解き放つ」として紹介されています。

本稿ではデジタルツインの考え方や、デジタルツインの実装として AWS IoT Core の「デバイスシャドウ」の動作を紹介します。デジタルツインの考え方だけでも役立つと思いますので、最後までお読みいただけると嬉しく思います。


X ポスト » | Facebook シェア » | はてブ »

builders.flash メールメンバー登録

builders.flash メールメンバー登録で、毎月の最新アップデート情報とともに、AWS を無料でお試しいただけるクレジットコードを受け取ることができます。 
今すぐ登録 »

デジタルツインとは

デジタルツインとは「現実世界の状態をサイバー空間上に再現して、デジタルでこの 2 つを結びつけること」です。サイバー空間は、クラウドとも言い換えられます。

少し難しい表現となりましたが、身近な例が GPS による位置情報のマッピングです。カーナビやスマートフォンの地図アプリでの利用、そしてバスやタクシーのロケーション(位置情報把握)があります。位置という現実世界の情報を、サイバー空間である地図アプリに再現しています。

先の例は「現実世界の状態をデジタル化して、サイバー空間に再現する」様子であり、実はデジタルツインとしては半分の説明です。もう半分は「サイバー空間上の状態変化を、現実世界に適用する」というものです。データをクラウドに集めるだけでなく、クラウド側から現実世界に介入できるという考え方になります。この 2 つがあるからこそ、冒頭で紹介した “結びつける” という表現になります。タクシーの例に加えるとしたら、配⾞指⽰が「現実世界への介入」となります。

実装面におけるデジタルツイン

実装に目を向けると「現実世界の状態」をセンサー等で、「サイバー空間上に再現」をクラウドで、そして「デジタルで結びつける」をネットワークで実現します。いわゆる IoT (モノのインターネット) の構成と同じであるため、デジタルツインは IoT の文脈で多く語られるわけです。

センサーやクラウドはなんとなくわかりそうですが、ネットワークでは見慣れたHTTPとは異なるプロトコル「MQTT」が使われることが多いです。MQTT はステートフルでオーバーヘッドが少なく、Pub/Sub 型でのメッセージ配信ができます。要するに、双方向通信が可能です。デジタルツインにおける「現実世界への介入」はクラウド側が起点となる通信であり、双方向通信機能が求められるため MQTT が利用されます。

※ AWS 上での取り扱いでは MQTTS (MQTT+TLS) ですが、機能面の解説を優先して MQTT としています。

デジタルツインと AWS IoT Core の「デバイスシャドウ」

AWS 上で IoT データを処理するサービスの筆頭格が AWS IoT Core です。IoT デバイスに対する MQTT ベースの Amazon API Gateway と言えば、位置づけがわかりやすいかもしれません。IoT Core は、ルールに基づいたデータ加工や AWS サービスへの配信 ができるため、データ収集だけでも活躍します。

デジタルツインの観点で有用なのが「デバイスシャドウ」です。デバイスシャドウ (以下、シャドウ) は、平たく言えば「JSON ストレージ」です。以下は IoT Core 上のシャドウです。IoT Core で “モノ” を作るとシャドウの格納領域が準備されます。

Screenshot showing a Device Shadow state JSON example in Japanese, with the reported location set to 秋葉原 (Akihabara).

シャドウの使い方

シャドウの使い方自体はシンプルで、IoT Core に対して JSON を送信します。AWS CLI なら以下の通りです。

bash
aws iot-data update-thing-shadow --thing-name TAXI-01 --payload '{"state":{"reported":{"location":"秋葉原"}}}' /dev/null

例 : タクシーの場合

さて、こういった JSON の保存先であれば Amazon S3 や Amazon DynamoDB といった選択肢もありますが、その中でデバイスシャドウを利用する理由は「状態の差分算出」機能があるためです。タクシーの例をもとに考えてみましょう。タクシーと IoT Core 間では現在位置の報告と、配車システム経由の配車指示をやり取りすることにします。
タクシー、IoT Core、配車システム間の連携を示す日本語のシーケンス図。タクシーが現在位置をIoT Coreに送信し、IoT Coreが配車システムと連携して配車指示を受信・配信する流れを表現。

AWS IoT Core におけるシャドウの扱い方

少し IoT Core におけるシャドウの扱い方を説明しておくと、大きく 2 つあります。

IoT デバイスから IoT Core への状態報告は state.reported.*** キーで送ります。先の例では、現在位置を state.reported.location に入れて送った状態を IoT Core 上で見ていたわけです。配車システムから IoT デバイスへの指示は、IoT Core へ対し state.desired.*** というキーを送ります。例えば、目黒へ向かう配車指示は state.desired.location = 目黒 です。

A sequence diagram in Japanese showing the interaction between a taxi, IoT Core, and a dispatch system, illustrating how location states are reported and updated in a digital twin scenario.

delta キーとは

ここで 1 つ、これまでの説明に無かったキーが出てきました。それが delta です。deltareporteddesired における location の差分です。現在位置 (reported) が秋葉原、配車指示 (desired) が目黒であるため、差分は「目黒に向かえ」という差分 (delta) が算出されたのです。

秋葉原から目黒までは、様々な地域を経由します。その間にもタクシーからは定期的に state.reported.location を送信しますが、desired とは異なるため都度 delta が算出されます。そして、無事目黒に到着し、state.reported.location = 目黒と IoT Core へ送信すると、reporteddesired が一致するため、差分が解消されて delta が無くなります。

位置による Delta キーの変化

赤坂通過時 (delta が算出されている)

A screenshot showing a device shadow state example in JSON format with Japanese labels, illustrating 'desired', 'reported', and 'delta' states for location.

六本木通過時 (delta が算出されている)

Screenshot showing a sample Device Shadow state in JSON format with Japanese labels for desired, reported, and delta states.

目黒到着時 (delta が無くなっている)

A screenshot showing a Device Shadow state JSON example with Japanese text, illustrating the desired and reported state for location as '目黒'.

デバイスシャドウの利点

今回は IoT Core 上で動きを確認しました。実際には IoT デバイスから MQTT Subscribe することで、ここで紹介した JSON が得られます。具体的な MQTT トピックや JSON ドキュメントの意味については AWS IoT Device Shadow サービスDevice Shadow MQTT トピック が参考になるでしょう。

デバイスシャドウの利点として「状態の差分算出」を解説しました。他のストレージサービスの利用時には AWS Lambda 等を使うことが求められますが、デバイスシャドウであれば IoT Core がやってくれるわけです。

デバイスシャドウに適しているユースケース

デバイスシャドウは、クラウド側から状態変化を起こしたい場合に適しています。それ以外のケース、例えば位置データを集めるだけならば他のサービスへの蓄積でも良いでしょう。Amazon S3 や Amazon DynamoDB はもちろん、AWS IoT SiteWise のアセットのプロパティも使えます。(AWS IoT SiteWise と AWS IoT TwinMaker をつかった視覚的なデジタルツインの実践例もありますね)。

また、デバイスシャドウと他の AWS サービスを併用するのも有効です。一例としては検索があります。デバイスシャドウ内は フリートインデックス を作ることで可能です。しかし、例えば高トラフィックな Web システムからの参照には Amazon DynamoDB 等を使ったほうが有利であるため、デバイスシャドウと併用するといったアーキテクチャも考えられます。これも IoT Core のルールを利用すれば構築可能です。

まとめ

デジタルツインは「現実世界の状態をクラウド上に再現して、デジタルでこの 2 つを結びつける」こと、そしてクラウド側の実装として AWS IoT Core のデバイスシャドウを紹介しました。

これからのデジタル社会において、デジタルツインを実装する機会がより増えてくると考えられます。現実世界のモノには常に状態が存在している事、その状態を管理する仕組みが AWS 上にあることを覚えておいていただけると嬉しく思います。

筆者プロフィール

松下 享平
株式会社ソラコム テクノロジー・エバンジェリスト / AWS IoT Hero

IoT の活用事例やライブデモを通じて、IoTの 普及と SORACOM の利用を促進をする講演や執筆活動を担当。登壇回数は延べ 500 以上、1978 年生まれの静岡人、座右の銘は「論よりコード」

A person with short dark hair and glasses is standing with arms crossed, wearing a black collared shirt, against a plain light background.