Upgrade to Pro — share decks privately, control downloads, hide ads and more …

横浜スタジアム技術実証・COCOA インストール率のリアルタイム可視化 IoT システム【De...

横浜スタジアム技術実証・COCOA インストール率のリアルタイム可視化 IoT システム【DeNA TechCon 2021】/techcon2021-2

2020 年の日本プロ野球は、新型コロナウイルス感染症の影響で、例年より 3 ヶ月遅い 6 月に無観客での開幕となりました。7 月から観客の動員も可能になりましたが、シーズン末でも球場の収容人数の 50 % を上限とした試合開催となりました。

そうした中、大規模イベントを安全に開催する方法を探るため、横浜スタジアム技術実証* が実施されました。

本セッションでは、横浜スタジアム技術実証の一環として、新たに開発・実証*を行った「新型コロナウイルス接触確認アプリ(COCOA)* インストール率のリアルタイム可視化 IoT システム」の紹介を行います。

まず最初に、横浜スタジアム技術実証全体の概要と COCOA のインストール率を測定する背景について説明いたします。

次に、COCOA インストール率測定に関して説明いたします。COCOA がインストールされているデバイス数の測定方法(接触符号 RPI、入場ゲートでの 2 点測定)を説明したのち、実際に行った横浜スタジアムでの測定結果を紹介いたします。

最後に、COCOA インストール数をリアルタイムで集計・可視化する IoT システムのアーキテクチャを紹介します。データ取得(Raspberry Pi, fluentd)、データ集約(Google BigQuery)、データ可視化(Google データポータル)の 3 パートから構成されるシステムを、実証における要件や、技術選定の理由などにも触れながら紹介いたします。

本セッションを通して、安全なリアルイベント開催や、IoT デバイスで収集したセンサーデータのリアルタイム分析・可視化システムを構築する際の参考としていただければ幸いです。

*横浜スタジアム技術実証について https://www.pref.kanagawa.jp/docs/bu4/jissyo.html
*弊社の取り組みについての紹介記事 https://dena.com/jp/article/003672
*新型コロナウイルス接触確認アプリ(COCOA) https://www.mhlw.go.jp/stf/seisakunitsuite/bunya/cocoa_00138.html

DeNA_Tech

March 03, 2021
Tweet

More Decks by DeNA_Tech

Other Decks in Technology

Transcript

  1. 所属 • スポーツ事業本部システム部 事業開発グループ • スマートシティ統括部 エネルギー事業推進室 仕事 • ソフトウェアエンジニア

    • ベイスターズの ID 基盤や周辺サービスの開発・運用 • 衛星データ活用・IoT 関連技術の調査 • クライアントからサーバまで開発全般 Twitter: 今日の発表:#COCOA #IoT #fluentd #BigQuery #GoogleDataPortal 4 武藤 悠輔 / Yusuke Muto
  2. 7 イベント会場 後日 イベント来場者の中に 新型コロナへの感染が発覚 した場合 濃厚接触者は COCOA の通知を 通して自身の感染リスクが高まっ

    ていることがわかる 特に、イベントを継続的に実施する場合に COCOA の活用がより重要になる COCOA の課題:普及率が低く、リスク管理が適切に行えない状況である → 検査や次のイベント参加の自粛など 行動変容につながる 1. 実証 1.2 なぜ COCOA か
  3. 8 横浜スタジアム技術実証において行ったこと 1. COCOA インストールの啓発  来場者の COCOA インストール率を向上させる目的で、COCOA をインストー ルしている方に対して、球場内で利用可能な

    500 円券などのインセンティブ付 与を行った。 2. COCOA インストール率の測定 (本発表)  信頼のおける測定方法の確立を目的として実証を行い、COCOA インストール の啓発効果の定量的な測定につなげる。  1. 実証 1.3 COCOA の課題解決に向けて COCOA が正しく機能し、 イベントが継続的に、 安全に開催できる状況を実現する
  4. *COCOA デバイス数 = COCOA がインストールされ、有効になっているデバイス数 11 2. 測定 2-1. 定義 入場ゲート

    を通過する タイミングで測定 COCOA をインストール ・会場側でカウントすることを想定 ・横浜スタジアムの場合は手動でカウントさ れている ・入場者のもつ COCOA デバイスのユニー クな数を測定する → 実証を行った箇所 来場者は一定の割合で COCOA をインストールしている
  5. 12 2. 測定 2-2. COCOA デバイスの検出 ref) https://covid19-static.cdn-apple.com/applications/covid19/current/static/contact-tracing/pdf/ExposureNotification-BluetoothSpecificationv1.2.pdf?1 ① COCOA の信号であること:

    で判断可能 ② 同一デバイスからきた信号であること: で判断可能 → 結構クセの強いデータ BLE 信号の仕様は Apple/Google が公開している
  6. 13 2. 測定 2-2. COCOA デバイスの検出 1. 接触符号 RPI は 10~20

    分に一度変化する BLE 受信機 1~2 分以内 10 ~ 20 分以上経過 RPI - A RPI - A RPI - B  最初の数分は、RPI を見ることで同 デバイス 1 からの信号であることがわ かる 一定時間経過すると、RPI が変化して しまい、受信機からは、別のデバイス に見えるようになる → 同じデバイスが、BLE 受信機の近くに 20 分以上あると RPI が変化してしまう
  7. 14 2. 測定 2-2. COCOA デバイスの検出 2. BLE の信号は、数十メートル以上届く BLE 受信機

    入場ゲートから数十メートル離れた デバイスの信号も受信してしまう 入場ゲートを通っているデバイ スからの信号だけを取りたい → 入場ゲートを通るデバイスだけを測定したくても、ノイズが多くのってしまう
  8. 15 2. 測定 2-2. COCOA デバイスの検出 3. スマートフォンの機種によって、電波強度が異なる → 電波強度から距離を判断できない *

    COCOA においても、濃厚接触を判定する際に、電波強度の端末依存性を解消するために、送信電波強度**を補正するための情報も BLE 信号の中に入っているが、API 外から利用はできない。 **送信電波強度は、Bluetooth® Specification に記載の Transmit Power Level の情報で共有されている。 ・iOS・Android などの違いだけでなく、Android の機種ごとにも異なる
  9. 16 2. 測定 2-2. COCOA デバイスの検出 入場ゲート BLE 受信機1 BLE 受信機2

    COCOA インストール率 = / 入場者数  入場ゲートに 2 個の BLE 受信機を設置し、入場する順番で両デバイスで検知 された COCOA デバイスのみカウントする 1. RPI が 10~20 分で変化 2. BLE の信号が数十メートル以上届く 3. 機種によって電波強度が異なる
  10. 17 2. 測定 2-3. 横浜スタジアムでの測定 ref) https://www.yokohama-stadium.co.jp/sta-map/ :左図の赤丸  → 左下のスターサイドゲートで説明を行う ゲートの場所

    ・関内駅から徒歩 2 分 ・来場者数が 3 万人程度の試合で 1 万人以上が 利用する主要な入場口 ・入場口が長めな (~40m) スロープになっている ・ゲートは試合のたびに設営・撤去される ・通過時間: 2 ~ 3 分程度
  11. 19 2. 測定 2-3. 横浜スタジアムでの測定 → およそ 程度(複数の試合に対してほぼ同一の結果)  (参考)実証時点での日本における COCOAインストール率:15.4 %

    → そもそも感染対策への意識が高い。 → 平均は 程度  付与したインセンティブの内容により多少の差はあった が、基本的には継続的な COCOA 普及施策により、COCOA インストール率の底上げが期待される結果を得た。 ref) https://www.pref.kanagawa.jp/documents/67872/kensyoukeltuka_sokuhou.pdf (システムについては次セクションで説明します) 左のダッシュボードの COCOA デバイス数を、別途記録 されている入場者数で割った値
  12. ・実証に足る最小限の構成に留めた ・ゲート設営時に、デバイスの設置・回収を依頼できるようにする(右上の写真) ・設置がうまくいったことを確認するためのダッシュボードも開発する必要性 ・Wifi がない場所には、泥臭く結構長い有線 LAN を配線(右下の写真) ・Wifi があっても不安定な場所もあるため、デバイスのローカルにもデータを蓄積 ・バッテリーでの利用も可能にする必要性

    ・3 試合でインセンティブの内容が全て異なったため、失敗できなかった。 ・一箇所の不具合が別の場所に波及しないために、ゲートウェイ構成などではなく、 デバイスごとに fluentd で直接 BQ へアップロードさせる構成をとった 23 3. システム構成 3-1. 開発要件
  13. 24 3. システム構成 3-2. システム全体像  BLE 受信機を用いて、センサ データを取得し、BigQuery に直 接ストリーミングする。

     Google Cloud Platform の BigQuery にセンサーデータを 集約する。 ・BigQuery コンソールでの分析 ・Google データポータル による可 視化 fluentd BigQuery Query
  14. ・Raspberry Pi4 Model B 4GB ・金属ケース(放熱用) ・microSD 32 GB ・プラスチックケース

    ・RTC モジュール(本体時刻合わせ) ・AC アダプター(5V 3A) ・バッテリー(~ 10,000 mAh程度) 25 3. システム構成 3-3. 実装
  15. 26 hcidump コマンド(https://github.com/bluez/bluez)でダンプした BLE データから、COCOA のデータを取り出す。 ① Exposure Notification API

    の判定 コード抜粋 ② 接触符号 RPI の取得 ④ RPI を sha256 で一方向ハッシュ化  RPI はそもそも個人情報ではないが、BigQuery のデータが 漏洩するリスクなどにも万全を期すために実施  (参考)実測値ベースで、エッジデバイスで秒間 45 万回以 上実行可能な処理ため、測定に影響はない ③ BigQuery に書き出すデータ  hostname: 設置場所に対応する  timestamp: データの取得時間  rpi: 接触符号 RPI  rssi: 電波強度 3. システム構成 3-3. 実装
  16. 27 ① fluentd-plugin-bigquery  直接 BigQuery へ書き込むためのプラグイン ref) https://github.com/fluent-plugins-nursery/fluent-plugin-bigquery ② GCP

    BigQuery への書き込みの設定  ・GCP ProjectID  ・GCP BigQuery Dataset  ・GCP BigQuery Table  ・GCP ServiceAccount のクレデンシャルファイル コード抜粋 コード抜粋 3. システム構成 3-3. 実装
  17. 28 hostname: 設置場所に対応する rpi: 接触符号 RPI を一方向ハッシュ化したもの timestamp: データの取得時間 rssi:

    電波強度 → ネットワークの状況次第だが、エッジデバイスで検知されてから 1 分以内程度で BigQuery 上に蓄積される 3. システム構成 3-3. 実装
  18. 32 センサーデータ BigQuery  COCOA センサ  Raspberry Pi 入場者の COCOA 有効デバイス数

    リアルタイムダッシュボード Data Studio COCOA デバイス数 時系列データダッシュボード Data Studio …  COCOA センサ  Raspberry Pi  COCOA センサ  Raspberry Pi  COCOA センサ  Raspberry Pi 3. システム構成 3-3. 実装
  19. 35