IoTデバイスデータ収集の難しい点

Mobility Technologies Co., Ltd.
Data Engineering Study #4
IoTデバイスデータ収集の難しい点
株式会社 Mobility Technologies
渡部徹太郎
2020/11/04

View Slide

⾃⼰紹介
2
ID ：fetaro
名前：渡部徹太郎
学生：東京工業大学でデータベースと情報検索の研究
(@日本データベース学会)
職歴：
* 野村総合研究所(NRI)
- オンライントレードシステム基盤
- オープンソース技術部隊
* リクルートテクノロジーズ
- ビッグデータ分析基盤
* Mobility Technologies
- データエンジニア
エディタ：emacs派→ InteliJ派
趣味：麻雀、自宅サーバ
⽇本AWSユーザ会(JAWS)
ビッグデータ⽀部⻑
やってました
著書

View Slide

Mobility Technologiesの紹介
3
配⾞関連事業
広告決済事業乗務員向けソリューション事業
DRIVE CHART・ドラレコ事業次世代向けR&D事業

View Slide

ドライブレコーダ
n システム概要
ドライブレコーダのデータを収集している
4
アップロード
プログラム
インター
ネット
Wifi
LB
収集処理
アクセス
ポイント
ルータ
ドラ
レコ
ドラ
レコ
ドラ
レコ
速度
センサ
GPS
センサ
カメラ
分散キュー
Wifi
タクシー
JapanTaxiドライブレコーダv4の写真

View Slide

n IoTデバイスからのデータ収集はWebのデータ収集とは違う！
1. バイナリデータを扱う
2. CPUアーキテクチャはx86/x64とは限らない
3. プログラムのサイズに容量制限がある
4. ネットワークは切れることがある
5. ネットワーク帯域は無限ではない
6. 電源は落ちることがある
7. 電⼒は有限である
8. ログは⾒ることができない
9. アップデートは⼀⼤イベント
10. 時間は正しいとは限らない
「エンジニアの総合格闘技」と呼ばれるほど、多種多様な知識が必要となる
IoTデバイスからのデータ収集は⼀味違う
5

View Slide

n バイナリファイルとは
n 01の配列
n どのように読むか規定されていない
n パースが必要
n プログラミング⾔語のビット演算をつかう
n 論理積 (&) 論理和 (|) ビット反転 (~)
右シフト(>>) 左シフト (<<)
n ハマった箇所
n Floatが変な値になる
n →リトルエンディアンとビッグエンディアン
のとり違い！
n -z⽅向加速度が常に⼀定の値を⽰してしまう
n →重⼒加速度だった！
バイナリデータを扱う
6
1 1 0 1 0 0 1 1 0 1 0 0 1 0 0 0
0 1 1 0 1 1 1 1 0 0 0 0 0 0 0 0
0 0 0 1 0 1 1 0 0 0 0 1 1 1 0 0
1 0 1 0 0 0 1 1 0 1 0 0 1 0 1 1
Webの場合 IoTデバイスの場合
データ形式 JSON, CSV, DBのテーブルバイナリファイル
タイムスタンプ
GPS緯度
GPS経度
各種フラグ
X⽅向加速度 -X⽅向加速度 y⽅向加速度 -y⽅向加速度
空き
パース

View Slide

CPUのアーキテクチャはx86/x64とは限らない
7
CPU
アーキテクチャ
x86/x64 ARM
（が多い）
n CPUアーキテクチャとは主に２種類ある
n x86/x64 : サーバ、パソコン
n ARM : IoTデバイス、スマートフォン
n 難しい箇所
n MacOSやクラウドの仮想マシンでコンパイルしたバイナリは動かない
n →クロスコンパイルが必要
n どうやってクロスコンパイルするか
n Go⾔語やRustが開発しやすい
n →JapanTaxiドライブレコーダではメモリ管理に厳格なRust⾔語を採⽤

View Slide

プログラムのサイズに制限がある
8
プログラムの
サイズ
気にしたこと無い。
磁気ディスクやSSDの容量は
100 Gbyte以上ある。
フラッシュディスクは16Gbyte〜
64Gbyte程度
n 難しい箇所
n プログラムのコンパイル後のサイズを気にする必要がある
n ライブラリは潤沢には使えない
n →他のモジュールと同じライブラリを使う
n 開発⾔語は複数使えない
n →Rust⾔語のみ

View Slide

n 難しい箇所
n ネットワークは常に切れる想定で開発する必要がある
n リトライを仕込む
n サーバ側でどこまで処理したかを管理し、再接続時にレジュームできるようにする
n 無線通信が⼲渉する
n Wifiの2.4GHz帯の電波は、他のwifi機器やbluetooth機器と⼲渉する
n →デバイス間のチャンネル調整が必要
n 無線電波が弱い
n →天井がないと電波が反射が少ない
ネットワークは切れることがある
9
通信品質安定
たまにパケットが落ちるぐらい
不安定
場所によって切れる

View Slide

n 難しい箇所
n 通信帯域的＆コスト的に、
全てのドライブレコーダの動画をアップロードすることはできない
n →業務要件を加味して必要最⼩限な動画だけアップロードするようにする
n →全てのデータが取れない前提でアプリケーションを組む
n 同時に全台のデバイスのデータを全⼒でアップロードできない
n →アップロードタイミングを制御することは難しいため、タイムアウト指数的に増やしていきで
きるだけ救うようにする
ネットワーク帯域は有限である
10
通信帯域 1Gbps〜10Gbps Wifi: 50Mbps〜500Mbps
(SIM: 10Mbps〜100Mpbs)
料⾦固定料⾦
（従量課⾦だとしても安い）
従量課⾦でしかも⾼い

View Slide

電源は落ちることがある
11
n 難しい箇所
n 電源が落ちたときを想定して開発する
n 電源が供給されなくなると、完全停⽌する前にデバイス側からシグナルを受信するので、
それをTRAPして適切な終了処理を書く（ファイルを閉じる等）
電源の有無ほとんど気にしない。
インフラ側で吸収してくれる
常に電源が落ちることを想定す
る

View Slide

電⼒は有限である
12
n 難しい箇所
n 消費電⼒を抑える
n エンジンがオンの場合はよいが、オフの場合はバッテリーの電⼒を⽤いた動作になる
n ⻑時間の起動はバッテリーあがりを引き起こす可能性がある
n ⾞との調整が必要
n 最⼤起動時間を決めて、それ以内に処理を終わらせるようにする
消費電⼒え？なんですかそれ？省電⼒を⼼がける。
起動時間を気にする。

View Slide

n 難しい箇所
n エラー内容をサーバに返す前に死なれると何が起きていたかわからない
n ログにしかエラー内容は出⼒されない
n デバイスに接続してログを確認するしかない
n SSHサーバは⼊っていないため、SSH接続はできない
n タクシー⾞両に⾏きコンソールケーブルを接続して参照する必要あり
ログは⾒ることができない
13
ログの参照 Cloud watch ポチー
ssh ポチー
現地にいってデバイスに物理接
続

View Slide

n 難しい箇所
n OTA(Over The Air)による⾃⼰アップデートシステムの整備が必須
n デバイス側がオンラインになったときに、アップロードプログラムを確認し、あれば⾃
⾝を更新する仕組み
n すべてのモジュール更新がOTAでできるわけではない
n インストールメディアをいれたSDカードを持ってタクシー⾞両に⾏き、SDカードをド
ライブレコーダに指してインストール作業が必要
n 数百台の作業になることもあり、⼈海戦術となる
アップデートは⼀⼤イベント
14
デプロイの⽅法 git pull ポチー OTA (Over The Air)
or
⼈海戦術

View Slide

n 2000年のログが送られてくる
n IoTデバイスのマザーボードには時計が内蔵されていないため、起動直後は2000年1⽉1
⽇になる
n GPS等を介して時刻を取得すると、正しい時刻になる
時間が正しいとは限らない
15
時刻同期マザーボードに時計がある。
NTPで常に同期。
デバイスに時計があるとは限ら
ない

View Slide

n Webのデータ収集とIoTデバイスのデータ収集は必要なスキルセットが違う！
n バイナリデータの扱い
n クロスコンパイル・組み込みプログラミング
n ハードウェアの知識
n ネットワークの知識
n 電源への配慮
n ログ参照やアップデートへの考慮
n 時計への配慮
まとめ
16

View Slide

⽂章·画像等の内容の無断転載及び複製等の⾏為はご遠慮ください。
17
仲間募集中！

View Slide

IoTデバイスデータ収集の難しい点

IoTデバイスデータ収集の難しい点

fetaro

More Decks by fetaro

Other Decks in Technology

Featured

Transcript