Tomofiles Note

ドローンとインターネット、そして人との関係を考えるソフトウェアエンジニアのアウトプットブログ

国内外のドローン関連ウェブサービスを調べる（3） 〜リモート識別とInterUSS〜

ドローン ウェブサービス UTM 動向調査 InterUSS

こんにちは、Tomofilesです。

最近、海外動向ばかり調べています。
日本と違って、アメリカは民間主導での取り組みがメインなので、とにかく情報がオープンで、調べるとたくさん出てきます。

いまアメリカのドローン業界で最もホットな話題（？）は、「リモート識別」という仕組み作りです。
リモート識別は、ドローン活用を社会実装する上で、最も重要な要素の一つである「セキュリティ」を確保する仕組みです。

ドローンは近い将来、物流・警備・監視・郵便・空撮と、様々な用途で利用されることが期待されています。
いまは無人地帯での活用から始めていますが、最終的には、これらの用途を市街地で実現しようと、取り組みが行われています。
これらの用途は、広域に、かつ、自動航行・遠隔制御で実現されることが想定され、必ず操縦者が付近にいるということはありません。
そうなると、そのドローンが、誰によって、何を目的に、どこに向かって、飛行しようとしているのか不明瞭になります。
そして、その穴を突いて、犯罪やテロに利用される可能性が考えられます。

リモート識別は、この問題を解決し安全なドローン活用を目指す、政府の規則と民間の実装の取り組みです。
今回は、そんなリモート識別の規則について、そして、民間主導のリモート識別の実装（InterUSS）について、調査したことを紹介します。

リモート識別とは

セキュリティを優先するアメリカ

前回、アメリカのドローン規制の取り組みについて、紹介しました。

tomofiles.hatenablog.com

その中でも紹介していないトピックとして、リモート識別というものがあります。
前述の通り、リモート識別は、ドローン活用を社会実装する上で、重要な要素の一つである「セキュリティ」を確保する仕組みです。

UAS Remote Identification

リモート識別は、2017年に登場したトランプ大統領の意向により、アメリカにおける最優先の取り組み事項となりました。
当時、ISIS（イスラム国）による民生ドローンの軍事利用が話題となっており、また、ハッキングによりドローンの制御を奪うことができるという検証結果も公開され、いつ重要施設への攻撃に利用されるかわからない、とまで言われるほど、ドローンは問題視されていたのです。
そこで、リモート識別があれば、どこで誰が何のために、どのようなルートでドローンを飛ばしているのか分かり、ルートを外れている悪意のあるドローンを見つけることもできるため、事件を未然に防いだり、発見したりすることができるようになります。

リモート識別は現在、FAAによる規則制定案の通知（NPRM）が公開され、今月始めまでパブリックコメントを受け付けていました。

www.federalregister.gov

※参考：NPRMとは
NPRMとは何？ Weblio辞書

リモート識別の実現がもたらすもの

リモート識別が、具体的に私達の生活にどう絡んでくるのか、イメージが掴めないかもしれません。
そんな人には、以下のサイトの動画がおすすめです。

www.airmap.com

目視で確認した正体不明のドローンの情報を、スマートフォンからインターネット経由で取得しています。
つまり、これからの時代、物流等でドローンが市中を飛行するようになった場合、そのドローンの身元をインターネットで確認することができるということです。

この仕組みは、おそらく官民問わず提供されるものとなるはずで、私達一般市民が不審なドローンを発見することができ、警察等も同様に公務に役立てられるものとなると思われます。
さらにリモート識別は、ドローン同士の衝突回避等への利用も視野に入れられており、H2M（Human to Machine）だけでなく、M2M（Machine to Machine）な活用も期待されているようです。

ドローンの運用への影響

リモート識別は、前回の記事で紹介したLAANC（低高度承認および通知機能）と同じように、民間のUASサービスサプライヤー（USS）によりサービスとして提供されます。
つまり、手動操縦・自動遠隔操縦に関わらず、すべてのドローンの飛行においては、リモート識別USSに対する通知が義務化されます。
FAAの規則案には、次のように記載されています。

  • 離陸するためには、インターネット経由でリモート識別USSに接続していること
  • 飛行中にリモート識別USSとの接続が切れた場合、直ちに着陸すること
  • 接続が切れた場合でも、必要な情報を機体から直接ブロードキャストしていれば、飛行継続しても良い（※）
  • リモート識別機能が無い古い機体や玩具は、リモート識別USSに対して飛行エリアを提供していれば、飛行しても良い

つまり、リモート識別USSに対しては、

  • 飛行直前にインターネット経由で飛行予定エリアを提供
  • 飛行中もインターネット経由でテレメトリーを提供
  • 趣味のパイロットも、飛行前にインターネット経由で飛行予定エリアを提供

ということが、必要になります。

インターネット経由は、機体自体からでもいいですが、GCSやタブレット端末からでも問題ありません。
つまり、DJIなどの専用フライトアプリが、リモート識別USSへの通知機能を提供することになるでしょう。

（※）のブロードキャストについてですが、上記のリモート識別USSへの通知とは別に、機体から直接周囲に電波を発して、身元情報やテレメトリーを提供する必要があります。
FAAの規則案では電波の詳細は記載されていないですが、追加装備が不要であることが望ましいとのことなので、おそらくWi-FiやBluetoothのような広く普及している仕様が想定されています。

話が逸れますが、先程のスマートフォンからドローンの身元情報を取得するシナリオは、このブロードキャストされた電波をBluetooth等で拾って確認するものと、リモート識別USSから付近の飛行情報を要求する方法があるそうです。
以下のWingの実証実験の報告によると、人がスマートフォンからリモート識別アプリを起動する前に、確認したいドローンが高速飛行して目の前から消えてしまったときに、リモート識別アプリに対して付近を飛行情報を問い合わせ、対象のドローンを特定するシナリオも、確認しているそうです。

wing.com

なんとなく、全体的にインターネットに接続できることが前提となっているようですが、以下のようにリモート識別USSへの通知が不要となるケースも想定されているようです。

  • インターネットが接続できない環境では、ブロードキャスト機能が有効であれば、飛行しても良い
  • プロポから400フィート以内の目視内飛行であれば、インターネットに接続できなくても、飛行して良い

この辺は、民間から提出されたパブリックコメントで、何か改善要望があるかもしれないですね。

リモート識別を実現する技術

ここから、テクノロジー寄りの話に入っていきます。

リモート識別は、前述の通り、UASサービスサプライヤー（USS）により提供されることになります。
リモート識別USSは、LAANC USSと同じように、いくつもの企業がインターネット上でサービスを提供することになると思われます。
複数のUSSはそれぞれ、自社管理分のドローンのリモート識別情報のみ保有することになりますが、それだけでは、問い合わせるUSSによって、違う結果が返ってくることになり、リモート識別が本当に達成したいことが実現できていません。

目指す姿は、すべてのUSSがすべてのリモート識別の情報を共有し、どこのUSSを利用しても、同じサービスが受けられるようにする、ということです。
最終型のUTMは国家レベルのインフラシステムであり、それを民間主導で作るということは、民間で国全体のシステムを統合する必要があるということです。
日本なら真っ先に大手SIer数社が牛耳って、○○万人月とかいう莫大な規模で取り掛かる案件となりそうですが、それを民間企業が自分たちでやろうとしてるのだから、すごいバイタリティですよね。
（すでに日本のUTMの研究開発は、NEC、日立、NTTデータ、楽天、などの大企業が囲んでるけど…）

USS統合に向けた課題

USS同士がリモート識別情報をやり取りして、すべてのUSSが同じリモート識別サービスを提供するためには、課題がいくつかあります。

  1. どんなUSSが存在するか（誰、どこ：WHO、WHERE）
  2. リモート識別情報がいつ更新されたか（いつ：WHEN）
  3. リモート識別情報をどうやって提供するか（どのように：HOW）

１つめの課題は、「誰がいるのか」です。
リモート識別を実現するには、別のリモート識別USSから情報を提供してもらわないといけないですが、誰がその情報を持っているのか探す方法は、簡単ではありません。
USS各自が、あらかじめすべてのUSSを知っていてもいいですが、USSが増えるたびにアクセス先を管理しないといけない上に、情報を持っていないかもしれないUSSにも問い合わせをしないといけないので、無駄が多すぎます。

f:id:Tomofiles:20200315004338p:plain

2つめの課題は、「情報の更新をどのように伝えるか」です。
リモート識別は、飛行中のドローンの情報をやり取りして、実現することになります。
つまり、リモート識別情報は、リアルタイムに生成・更新・削除が発生します。
これらの契機は、他のUSSに通知して、リモート識別情報を各USSで同期しないといけないですが、誰がその情報を欲しているのかわかりません。

f:id:Tomofiles:20200315004356p:plain

3つめの課題は、「情報をどうやって相手に渡すか」です。
リモート識別に必要な情報を、どのように別のUSSに渡すのでしょうか。
この問い自体は、IT業界にたくさんのノウハウがあるので一から考える必要はないですが、何を採用するか決めるのは簡単ではありません。

これらの技術的な課題に対して、日本のJISに相当するASTMによる標準化の取り組みを通して、USS間のコミュニケーションを促進するプラットフォームの開発がオープンソースで行われています。
それが、前回も紹介したInterUSSです。

InterUSS

※参考：ASTM標準とは
ASTMとは何？ Weblio辞書

InterUSSのコンセプト

InterUSSの主要な機能は、上記公式サイトに記載されていますが、以下の2点です。

  1. 発見
  2. 同期検証

1つめの「発見」は、USSが情報を取得する必要がある他のUSSを発見できる機能です。
この機能により、他のUSSを全部知る必要がなくなるので、各USSの負担が減ります。

2つめの「同期検証」は、必要なときに他のUSSの完全かつ最新の情報を確実に取得する機能です。
この機能により、情報を欲しているUSSに確実に情報を提供でき、最新状態を同期できます。

これらの機能を実現するのが、InterUSSプロジェクトの中のDiscovery and Synchronization Service（DSS）というプラットフォームです。

github.com

DSSについて、もう少し細かい機能概要（コンセプト）が紹介されたmdが、以下にあります。

dss/concepts.md at master · interuss/dss · GitHub

この内容を図を用いて、少しわかりやすく説明してみると、以下のとおりです。

1. サブスクリプション
各USSは、自身の関心のあるエリアをあらかじめDSSに宣言しておきます。
この宣言しておくエリア情報を、「サブスクリプション」と呼びます。
サブスクリプションを認識したDSSは、そのエリアでの変更が発生したときに、USSがその変更を検出できるようになります。

f:id:Tomofiles:20200315112024p:plain

エリア情報というのは、地図上で表現すると以下のような、緯度・経度の座標で表現されたエリアを意味しています。

f:id:Tomofiles:20200315113122p:plain

2. 識別サービスエリア
ドローンパイロットは、ドローンの飛行前にUSSに飛行エリアを宣言することになりますが、このエリアのことを「識別サービスエリア」と呼びます。
識別サービスエリアは、ドローンの離陸とともにUSS経由でDSSに作成し、飛行終了とともにDSSから削除する必要があります。
識別サービスエリアをDSSに通知すると、その応答として、当該エリアに関心を持っているUSS（サブスクリプション）を教えてくれます。

f:id:Tomofiles:20200315114916p:plain

識別サービスエリアも、サブスクリプションと同様に地理情報を持っているので、重なったエリアを検出することができるのです。

f:id:Tomofiles:20200315115034p:plain

3. 同期
サブスクリプションにより、関心のある他のUSSを発見できたUSSは、自身の状態変更を直接相手のUSSに通知しないといけません。
DSSは発見と状態の同期は行ってくれますが、具体的な情報のやり取りまでは行ってくれません。
これは、上記GithubのDSSコンセプトでも説明がありますが、「あくまでファシリテーターに徹する」という精神に則っているためです。

f:id:Tomofiles:20200315120400p:plain

この通知により、相手のUSSは自分のUSSに対して、当該ドローンの飛行情報の要求を行います。
これはポーリング（定期的に要求を繰り返し、情報を取得し続ける）により実現され、相手のUSSに飛行情報を提供します。

f:id:Tomofiles:20200315121429p:plain

このUSS間の直接的な情報のやり取りは、API（Application Programming Interface）により実現され、情報の構造や手順などが決められています。
これはDSSが実装するものではなくUSSが実装するものなので、このAPI規約に則った正しいAPIを、各USSが用意する責任があります。

1.サブスクリプションと2.識別サービスエリアは、順序が逆になっても、状態の同期が行われるようになっています。
先に識別サービスエリアが存在するエリアに、後からサブスクリプションを作成要求をDSSに行うと、その応答に、現在そのエリアに存在する識別サービスエリアを通知してくれます。

かなり大雑把な説明とはなりましたが、DSSを用いたUSS間の全体的な仕組みは、こんな感じです。

InterUSSを実際に触ってみる

さて、InterUSSのコンセプトがわかったところで、実際にInterUSSのDSSを実行して、動きを確認してみたいと思います。
DSSをローカル環境で起動して、各種APIを叩いてみましょう。
なお、動作環境はこれまでの記事と同じく、Linux（Ubuntu Desktop）で行います。

DSSをローカルで起動

以下のように、Githubからリポジトリを取得します。

$ git clone git@github.com:interuss/dss.git

DSSはdocker-composeで起動するので、以下のようにコマンドを実行します。

# docker-composeのyamlファイルがある場所まで移動
$ cd dss/build/dev

# docker-composeコマンドを実行
$ docker-compose -f docker-compose_golang.yaml -p dss_sandbox up

これだけです。
このyamlファイルは、動作検証用（サンドボックス環境）のものらしく、本番ビルドをする場合は推奨されていません。
今回はお試しなので、これでOKです。

以降、各種APIを実行していきますが、以下にAPI仕様が公開されています。

redocly.github.io

OAuth認証

DSSは本番運用ではクラスター構成となるそうで、DSSにアクセスするための認証は、OAuth認証を用いるようです。
OAuthトークンを発行すると、どのDSSへのアクセスでも、同一のアクセストークンが使用できます。

サンドボックス環境では、ダミーOAuth認証サーバが実行されます。
ダミー認証なので、実質的にアクセストークンを発行するだけで、セキュリティ的には何もしていないものです。

とりあえず動きを確認するだけであれば、以下の認証APIをリクエストするだけで大丈夫です。

GET http://localhost:8085/token?issuer=tomofiles&intended_audience=localhost&scope=dss.write.identification_service_areas

# Response Body
{
  "access_token": "※アクセストークンが発行される"
}

Getパラメーターはそれぞれ、発行されるアクセストークンの中に格納される値を指定しています。
渡したものをそのままアクセストークンの中に格納してくれるので、ダミー認証なのです。

  • issuer：任意の文字列
  • intended_audience：ローカル起動なのでlocalhost固定
  • scope：権限みたいなもので、dss.write.identification_service_areasかdss.read.identification_service_areas（今回はすべてwrite）
サブスクリプション

DSSにサブスクリプションを登録してみましょう。

API動作確認のサンプルとして、以下のエリアを例にAPIを実行していきたいと思います。（先程の例を再掲）

f:id:Tomofiles:20200315115034p:plain

■サブスクリプション1

USS 2のサブスクリプション（赤いエリア）をDSSに登録します。

PUT http://localhost:8082/v1/dss/subscriptions/0023e0fe-834b-4bee-913d-80a6df37d7ad
Authorization Bearer ※アクセストークン
# Request Body
{
  "extents": {
    "spatial_volume": {
      "footprint": {
        "vertices": [
          {
            "lng": 139.715395,
            "lat": 35.708947
          },
          {
            "lng": 139.715483,
            "lat": 35.686921
          },
          {
            "lng": 139.765663,
            "lat": 35.686419
          },
          {
            "lng": 139.766635,
            "lat": 35.706508
          }
        ]
      },
      "altitude_lo": 0.0,
      "altitude_hi": 100.0
    },
    "time_start": "2020-03-16T00:00:00Z",
    "time_end": "2020-03-17T00:00:00Z"
  },
  "callbacks": {
    "identification_service_area_url": "https://example.com/uss/identification_service_areas/0023e0fe-834b-4bee-913d-80a6df37d7ad"
  }
}

# Response Body
{
  "service_areas": [
  ],
  "subscription": {
    "callbacks": {
      "identification_service_area_url": "https://example.com/uss/identification_service_areas/0023e0fe-834b-4bee-913d-80a6df37d7ad"
    },
    "id": "0023e0fe-834b-4bee-913d-80a6df37d7ad",
    "notification_index": 0,
    "owner": "fake-user",
    "time_end": "2020-03-17T00:00:00Z",
    "time_start": "2020-03-16T00:00:00Z",
    "version": "1bv395vvvbnso"
  }
}

■サブスクリプション2

USS 3のサブスクリプション（青いエリア）をDSSに登録します。

PUT http://localhost:8082/v1/dss/subscriptions/37464136-207f-4548-af6c-0ef027bf7096
Authorization Bearer ※アクセストークン
# Request Body
{
  "extents": {
    "spatial_volume": {
      "footprint": {
        "vertices": [
          {
            "lng": 139.756299,
            "lat": 35.692590
          },
          {
            "lng": 139.754443,
            "lat": 35.665176
          },
          {
            "lng": 139.803210,
            "lat": 35.665607
          },
          {
            "lng": 139.804447,
            "lat": 35.693092
          }
        ]
      },
      "altitude_lo": 0.0,
      "altitude_hi": 100.0
    },
    "time_start": "2020-03-16T00:00:00Z",
    "time_end": "2020-03-17T00:00:00Z"
  },
  "callbacks": {
    "identification_service_area_url": "https://example.com/uss/identification_service_areas/37464136-207f-4548-af6c-0ef027bf7096"
  }
}

# Response Body
{
  "service_areas": [
  ],
  "subscription": {
    "callbacks": {
      "identification_service_area_url": "https://example.com/uss/identification_service_areas/37464136-207f-4548-af6c-0ef027bf7096"
    },
    "id": "37464136-207f-4548-af6c-0ef027bf7096",
    "notification_index": 0,
    "owner": "fake-user",
    "time_end": "2020-03-17T00:00:00Z",
    "time_start": "2020-03-16T00:00:00Z",
    "version": "1bv39anlv83o8"
  }
}

これで、赤いエリアと青いエリアのサブスクリプションが登録できました。
サブスクリプションのタイミングで、すでに当該エリアに識別サービスエリアが存在する場合は、レスポンスのservice_areasの配列に要素が設定されています。
今回はまだ識別サービスエリアを登録していないので、何も返ってきません。

識別サービスエリア

次に、DSSに識別サービスエリアを登録します。

識別サービスエリアは、USSが管理しているドローンが離陸する際に、飛行エリアを宣言するものです。
前掲の地図における緑のエリアを識別サービスエリアとして、登録してみましょう。

PUT http://localhost:8082/v1/dss/identification_service_areas/9ba8c7c1-8025-4861-8c4b-c92923130c90
Authorization Bearer ※アクセストークン
# Request Body
{
  "extents": {
    "spatial_volume": {
      "footprint": {
        "vertices": [
          {
            "lng": 139.756740,
            "lat": 35.712462
          },
          {
            "lng": 139.756740,
            "lat": 35.703997
          },
          {
            "lng": 139.779534,
            "lat": 35.704069
          },
          {
            "lng": 139.778915,
            "lat": 35.710167
          }
        ]
      },
      "altitude_lo": 19.5,
      "altitude_hi": 19.5
    },
    "time_start": "2020-03-16T00:00:00Z",
    "time_end": "2020-03-17T00:00:00Z"
  },
  "flights_url": "https://example.com/uss/flights/9ba8c7c1-8025-4861-8c4b-c92923130c90/details"
}

# Response Body
{
  "service_area": {
    "flights_url": "https://example.com/uss/flights/9ba8c7c1-8025-4861-8c4b-c92923130c90/details",
    "id": "9ba8c7c1-8025-4861-8c4b-c92923130c90",
    "owner": "fake-user",
    "time_end": "2020-03-17T00:00:00Z",
    "time_start": "2020-03-16T00:00:00Z",
    "version": "1bv39jnr38bp8"
  },
  "subscribers": [
    {
      "subscriptions": [
        {
          "notification_index": 1,
          "subscription_id": "0023e0fe-834b-4bee-913d-80a6df37d7ad"
        }
      ],
      "url": "https://example.com/uss/identification_service_areas/0023e0fe-834b-4bee-913d-80a6df37d7ad"
    }
  ]
}

レスポンスを確認すると、subscriptionsに1件要素が設定されています。
UUIDを確認すると、USS 2のサブスクリプションと同じIDなので、識別サービスエリアとして宣言した当該エリアに、USS 2が関心を持っていることが検出できました。
あとは、urlに設定されているUSS宛の通知用APIで、USSに識別サービスエリアの通知を行い、相手のUSSに監視対象としてもらいます。
USS 3はエリア的に離れているので、今回の識別サービスエリアの作成による、通知対象として検出されませんでした。

まとめ

アメリカのリモート識別の実現は、すぐそこまで来ています。
今回細かく見てきた、ASTM標準のInterUSSプラットフォームを用いたリモート識別の有効性は、アメリカおよびスイスの実証実験で確認されています。

wing.com
※再掲

こうやって、実際に動かせるDSSのソフトウェアが公開されているのは、新規プレイヤーの参入を促し、業界を盛り上げる良い取り組みだと思います。
リモート識別という国家レベルのインフラシステムですら、私のように国境を超えてその価値が確認できるのです。

日本でもこういう取り組みができるといいですね。

先日、東京都が新型コロナウィルス対策サイトをオープンソース化したことで話題になりました。
一般市民がサイトの改善に貢献でき、また、その価値を再利用して、別の自治体が同じようなサイトを作成する支援もすることができ、ものすごい勢いで進化を遂げています。

www.itmedia.co.jp

ドローン活用の仕組み作りも、このような形がきっと日本でも理想的です。

私もアメリカやヨーロッパのように、民間でドローン活用の仕組みを作っていきたいです。
何か良い方法は無いでしょうか？

そんなことを考えるようになった、今日この頃でした。
今回も長くなってしまってすみません。

◆Previous Part
tomofiles.hatenablog.com

◆Next Part
tomofiles.hatenablog.com