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

2022-11-02
AWS コミュニティ通信

松下 享平 (AWS IoT HERO)

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

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

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


デジタルツインとは

デジタルツインとは「現実世界の状態をサイバー空間上に再現して、デジタルでこの 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 で “モノ” を作るとシャドウの格納領域が準備されます。

クリックすると拡大します

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

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 におけるシャドウの扱い方を説明しておくと、大きく 2 つあります。

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

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

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

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

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

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

今回は 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 上にあることを覚えておいていただけると嬉しく思います。


builders.flash メールメンバーへ登録することで
AWS のベストプラクティスを毎月無料でお試しいただけます

筆者プロフィール

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

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

AWS を無料でお試しいただけます

AWS 無料利用枠の詳細はこちら ≫
5 ステップでアカウント作成できます
無料サインアップ ≫
ご不明な点がおありですか?
日本担当チームへ相談する