狠狠撸

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

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

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

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

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

? バイナリファイルとは
? 01の配列
? どのように読むか規定されていない
? パースが必要
? プログラミング言語のビット演算をつかう
? 論理積 (&) 論理和 (|) ビット反転 (~)
右シフト(>>) 左シフト (<<)
? ハマった箇所
? Floatが変な値になる
? →リトルエンディアンとビッグエンディアン
のとり違い！
? -z方向加速度が常に一定の値を示してしまう
? →重力加速度だった！
バイナリデータを扱う
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方向加速度
空き
パース

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

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

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

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

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

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

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

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

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

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

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

狠狠撸

滨辞罢テ?ハ?イステ?ータ収集の难しい点

More Related Content

滨辞罢テ?ハ?イステ?ータ収集の难しい点

Editor's Notes