Weitere ähnliche Inhalte
Ähnlich wie IoTデバイスデータ収集の難しい点 (20)
Mehr von Tetsutaro Watanabe (20)
Kürzlich hochgeladen (12)
IoTデバイスデータ収集の難しい点
- 2. Mobility Technologies Co., Ltd.
自己紹介
2
ID :fetaro
名前:渡部 徹太郎
学生:東京工業大学でデータベースと情報検索の研究
(@日本データベース学会)
職歴:
* 野村総合研究所(NRI)
- オンライントレードシステム基盤
- オープンソース技術部隊
* リクルートテクノロジーズ
- ビッグデータ分析基盤
* MobilityTechnologies
- データエンジニア
エディタ:emacs派→ InteliJ派
趣味:麻雀、自宅サーバ
日本AWSユーザ会(JAWS)
ビッグデータ支部長
やってました
著書
- 4. Mobility Technologies Co., Ltd.
ドライブレコーダ
システム概要
ドライブレコーダのデータを収集している
4
アップロード
プログラム
インター
ネット
Wifi
LB
収集 処理
アクセス
ポイント
ルータドラ
レコ
ドラ
レコ
ドラ
レコ
速度
センサ
GPS
センサ
カメラ
分散キュー
Wifi
タクシー
JapanTaxiドライブレコーダv4の写真
- 5. Mobility Technologies Co., Ltd.
IoTデバイスからのデータ収集はWebのデータ収集とは違う!
1. バイナリデータを扱う
2. CPUアーキテクチャはx86/x64とは限らない
3. プログラムのサイズに容量制限がある
4. ネットワークは切れることがある
5. ネットワーク帯域は無限ではない
6. 電源は落ちることがある
7. 電力は有限である
8. ログは見ることができない
9. アップデートは一大イベント
10. 時間は正しいとは限らない
「エンジニアの総合格闘技」と呼ばれるほど、多種多様な知識が必要となる
IoTデバイスからのデータ収集は一味違う
5
- 6. Mobility Technologies Co., Ltd.
バイナリファイルとは
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方向加速度
空き
パース
- 7. Mobility Technologies Co., Ltd.
CPUのアーキテクチャはx86/x64とは限らない
7
Webの場合 IoTデバイスの場合
CPU
アーキテクチャ
x86/x64 ARM
(が多い)
CPUアーキテクチャとは主に2種類ある
x86/x64 : サーバ、パソコン
ARM : IoTデバイス、スマートフォン
難しい箇所
MacOSやクラウドの仮想マシンでコンパイルしたバイナリは動かない
→クロスコンパイルが必要
どうやってクロスコンパイルするか
Go言語やRustが開発しやすい
→JapanTaxiドライブレコーダではメモリ管理に厳格なRust言語を採用
- 8. Mobility Technologies Co., Ltd.
プログラムのサイズに制限がある
8
Webの場合 IoTデバイスの場合
プログラムの
サイズ
気にしたこと無い。
磁気ディスクやSSDの容量は
100 Gbyte以上ある。
フラッシュディスクは16Gbyte〜
64Gbyte程度
難しい箇所
プログラムのコンパイル後のサイズを気にする必要がある
ライブラリは潤沢には使えない
→他のモジュールと同じライブラリを使う
開発言語は複数使えない
→Rust言語のみ
- 9. Mobility Technologies Co., Ltd.
難しい箇所
ネットワークは常に切れる想定で開発する必要がある
リトライを仕込む
サーバ側でどこまで処理したかを管理し、再接続時にレジュームできるようにする
ハマった箇所
無線通信が干渉する
Wifiの2.4GHz帯の電波は、他のwifi機器やbluetooth機器と干渉する
→デバイス間のチャンネル調整が必要
無線電波が弱い
→天井がないと電波が反射が少ない
ネットワークは切れることがある
9
Webの場合 IoTデバイスの場合
通信品質 安定
たまにパケットが落ちるぐらい
不安定
場所によって切れる
- 10. Mobility Technologies Co., Ltd.
難しい箇所
通信帯域的&コスト的に、
全てのドライブレコーダの動画をアップロードすることはできない
→業務要件を加味して必要最小限な動画だけアップロードするようにする
→全てのデータが取れない前提でアプリケーションを組む
同時に全台のデバイスのデータを全力でアップロードできない
→アップロードタイミングを制御することは難しいため、タイムアウト指数的に増やしていきで
きるだけ救うようにする
ネットワーク帯域は有限である
10
Webの場合 IoTデバイスの場合
通信帯域 1Gbps〜10Gbps Wifi: 50Mbps〜500Mbps
(SIM: 10Mbps〜100Mpbs)
料金 固定料金
(従量課金だとしても安い)
従量課金でしかも高い
- 11. Mobility Technologies Co., Ltd.
電源は落ちることがある
11
難しい箇所
電源が落ちたときを想定して開発する
電源が供給されなくなると、完全停止する前にデバイス側からシグナルを受信するので、
それをTRAPして適切な終了処理を書く(ファイルを閉じる等)
Webの場合 IoTデバイスの場合
電源の有無 ほとんど気にしない。
インフラ側で吸収してくれる
常に電源が落ちることを想定す
る
- 12. Mobility Technologies Co., Ltd.
電力は有限である
12
難しい箇所
消費電力を抑える
エンジンがオンの場合はよいが、オフの場合はバッテリーの電力を用いた動作になる
長時間の起動はバッテリーあがりを引き起こす可能性がある
車との調整が必要
最大起動時間を決めて、それ以内に処理を終わらせるようにする
Webの場合 IoTデバイスの場合
消費電力 え?なんですかそれ? 省電力を心がける。
起動時間を気にする。
- 13. Mobility Technologies Co., Ltd.
難しい箇所
エラー内容をサーバに返す前に死なれると何が起きていたかわからない
ログにしかエラー内容は出力されない
デバイスに接続してログを確認するしかない
SSHサーバは入っていないため、SSH接続はできない
タクシー車両に行きコンソールケーブルを接続して参照する必要あり
ログは見ることができない
13
Webの場合 IoTデバイスの場合
ログの参照 Cloud watch ポチー
ssh ポチー
現地にいってデバイスに物理接
続
- 14. Mobility Technologies Co., Ltd.
難しい箇所
OTA(Over The Air)による自己アップデートシステムの整備が必須
デバイス側がオンラインになったときに、アップロードプログラムを確認し、あれば自
身を更新する仕組み
すべてのモジュール更新がOTAでできるわけではない
インストールメディアをいれたSDカードを持ってタクシー車両に行き、SDカードをド
ライブレコーダに指してインストール作業が必要
数百台の作業になることもあり、人海戦術となる
アップデートは一大イベント
14
Webの場合 IoTデバイスの場合
デプロイの方法 git pull ポチー OTA (Over The Air)
or
人海戦術
- 15. Mobility Technologies Co., Ltd.
ハマった箇所
2000年のログが送られてくる
IoTデバイスのマザーボードには時計が内蔵されていないため、起動直後は2000年1月1
日になる
GPS等を介して時刻を取得すると、正しい時刻になる
時間が正しいとは限らない
15
Webの場合 IoTデバイスの場合
時刻同期 マザーボードに時計がある。
NTPで常に同期。
デバイスに時計があるとは限ら
ない
- 16. Mobility Technologies Co., Ltd.
Webのデータ収集とIoTデバイスのデータ収集は必要なスキルセットが違う!
バイナリデータの扱い
クロスコンパイル・組み込みプログラミング
ハードウェアの知識
ネットワークの知識
電源への配慮
ログ参照やアップデートへの考慮
時計への配慮
まとめ
16
Hinweis der Redaktion
- 1:00
- ~3:00 60sec