BLEは超便利！？My NP1アプリBLE通信で苦労した話
パイオニア株式会社 SaaS Technology Center モバイル開発部プロダクトマネージャー＆Androidエンジニアの山本です！
今回は、NP1（エヌピーワン：エッジデバイス）とMy NP1アプリ（スマホアプリ）を接続・通信するBluetooth Low Energy（以下、BLE）について苦労話を語っていこうと思います。
BLEとは、近距離無線通信技術Bluetoothの拡張仕様の一つ
https://e-words.jp/w/BLE.html
(参照 2022-05-09)
NP1とは？
NP1は今年の3月に発売されたパイオニアの新商品で、音声だけで案内するスマート音声ナビやクラウドドライブレコーダー、定額使い放題Wi-Fiを搭載したパイオニアの全く新しい車用デバイスです。
NP1は画面を搭載しておらず、NP1を操作するには音声やMy NP1アプリを接続して操作します。
その接続や通信でNP1とMy NP1はBLEを採用しています。
NP1の設定など、NP1をより便利にご利用いただくためのサポートをします。
My NP1アプリについてはこちら
なぜBLEを採用しているのか？
ひとことで〜
超低消費電力！
一般的にはBluetoothの手別は大きく分けて2種類あって、Bluetooth ClassicとBLEがあります。
スマホアプリでBluetooth Classicを使用すると、スマホのバッテリー残量がすぐなくなってしまうことありますよね。
例えば、Audio機器やヘッドセット、PCとのデータ通信などでずっと繋ぎっぱなしにしておくと、すぐバッテリーがなくなってしまいます。
My NP1はNP1（エッジデバイス）と常時接続することを前提としていますので、すぐバッテリーが切れてしまうとアプリが使えなくなってしまいます。
My NP1ではユーザーのペインを取り除くためにも、BLEを採用することにしました。
BLEってどんな技術？
BLEって実際どういう技術なのでしょうか？
技術的解説を見てみましょう。
Bluetooth Low Energy (BLE) 無線機は、超低消費電力動作のために設計されています。2.4GHz アンライセンス ISM 周波数帯の 40 チャンネルでデータを送信するBluetooth LE 無線は、開発者に市場独自の接続要件を満たす製品を構築するための非常に大きな柔軟性を提供します。Bluetooth LE は複数の通信トポロジーをサポートし、ポイントツーポイントからブロードキャスト、さらに最近では、ブロードキャストまで拡張しています。
https://www.bluetooth.com/ja-jp/learn-about-bluetooth/tech-overview/
(参照 2022-04-26)
特徴は、BTClassicに比べて1/30の超低消費電力で動作できるということです。
その代わり、通信帯域が狭かったり、送信パケットサイズが小さいなどのデメリットも存在します。
また、ペリフェラルとセントラルが分かれていることで、アプリレイヤーでハンドリングしやすいメリットがあります。
BLE通信ではセントラル(Central)とペリフェラル(Peripheral)の2種類の役割が存在し、この２者の間でやり取りがなされます。セントラルはマスタとも呼ばれ、通信の制御を行う役割を持ちます。BLEではセントラルがペリフェラルに対して要求を出すことでデータ通信が行われ、一般的にはPCやスマートフォンがこの役割です。
https://houwa-js.co.jp/2018/06/20180629/
(参照 2022-05-09)
このような特徴をうまく使えば、超低消費電力の恩恵を受けながら、データ通信が可能ということになります。
My NP1ではどうやって使っている？
My NP1はNP1（エッジデバイス）と通信をするためにBLEを採用していますが、具体的には下記の機能で使用されています。
My NP1はNP1の設定を行う
NP1が取得した情報をMy NP1へ通知してもらい、画面を変化させる
NP1が取得した情報をMy NP1へ通知してもらい、同期を取る
この３点で使用されています。
例えば「My NP1はNP1の設定を行う」は下記のような画面で使われています。
NP1へBLEを使用して設定コマンドを送付します。
これは実際にアプリ内でどう処理されてNP1と通信をしているのでしょうか？
My NP1ではModelの中に複数クラスを抱えており、BLEコマンドハブ機能部とBLEコマンド作成部と通信管理部に分けて機能分担処理しています。
Androidにおいて通信管理部はバックグラウンドでの動作をできるように、独立した形（Service）で作成したり、MVVMを少しカスタマイズしました。
MVVMとは、利用者に対する表示・操作の機能（ユーザーインターフェース）が存在するソフトウェアの構造を階層的に整理したモデルの一つで、全体を「Model」（モデル）-「View」（ビュー）-「ViewModel」（ビューモデル）の3層に分割にしたもの。
Modelはデータの管理や保存、外部との入出力、内部的な処理を担い、Viewは利用者に対する画面表示や入力・操作の受け付けを担当する。両者の間を仲介して互いの状態変更を通知、反映させる役割をViewModelが担う。
https://e-words.jp/w/MVVM.html#:~:text=MVVM%E3%81%A8%E3%81%AF%E3%80%81%E5%88%A9%E7%94%A8%E8%80%85,%E3%81%AB%E5%88%86%E5%89%B2%E3%81%AB%E3%81%97%E3%81%9F%E3%82%82%E3%81%AE%E3%80%82
(参照 2022-05-09)
My NP1でのBLEの特別な使い方はある？
My NP1で考慮しなければいけないのは、実装難易度を下げながら、セキュアな通信を実現した上で、NP1の状態を把握して接続と通信を行わないといけないということです。
My NP1では設計段階で上記を考慮し、5つの特徴を実装しました。
１：プロトコルバッファでエンコード/デコードしたバイナリを通信をする
通常はBLEで通信する場合は、バイナリデータ（コンピュータが理解しやすいデータ配列のこと）のフォーマットを定義して、その定義に沿ってスマホアプリ側と車載器で個々に実装する必要があります。
しかし、個々で実装した場合、データフォーマットの解釈誤りなど、送受信データをチェックしないといけないため、考慮するものが増え、試験する上でも手間です。
なので、My NP1とNP1（エッジデバイス）では独自の通信仕様をプロトコルバッファで構築し、送受信で使用するコマンド体系を定義することで、データバイナリ上で通信実現しました。
プロトコルバッファを使用することで、データフォーマットの解釈誤り/実装誤りを回避できるようになりました。
プロトコルバッファは、有線で送信したりファイルに保存したりできるデータをシリアル化する方法です。JSONやXMLなどの他の形式も、データのシリアル化に使用されます。これらのプラットフォームは非常に柔軟で効果的であることが証明されていますが、完全に最適化されていない1つの場所は、プラットフォームに依存しない方法で複数のマイクロサービス間でデータを送信するシナリオです。
https://ichi.pro/purotokoru-baffuxa-o-rikaisuru-74516557270343
(参照 2022-04-26)
２：スキャン時にUUIDフィルタをかける
一般的なデバイススキャンの場合、アプリが接続したいデバイス以外のデバイスまで表示してしまうことになり、ユーザーとしては、たくさんのスキャン結果の中から目的のデバイスを探さなければなりません。
スキャンする際にUUIDフィルタ（Universally Unique IDentifierフィルタ：デバイスを一意に定義するIDをフィルタするもの）を使用して、NP1（エッジデバイス）のみスキャンすることで、ユーザーがNP1を見つけやすくしました。
３：スキャンしたNP1デバイスへの複数のGATT通信を同時に行う
NP1は販売店で取付されることも考慮しなければいけません。販売店の環境は、多数のNP1がペアリング状態である可能性もあります。
2で書いたように目的のNP1を探すために複数のGATT通信を同時に行なっています。
※GATT通信とは：GATT (Generic Attribute Profile)というBLE機器が持つデータ構造とその操作方法を定義したもので通信すること。
詳しい解説はこちら
４：機器登録する前と後で暗号化の仕組みを変える
NP1（エッジデバイス）は機器登録前と機器登録後で暗号化の仕組みが違います。
機器登録後のBLE通信はセキュアである必要があります。
それは、ユーザーを紐づける内容のデータ通信をやりとりするためです。
しかし、機器登録前はユーザーを紐づける内容のデータ通信は行っておらず、BLE通信はセキュアである必要はありません。
そのため、機器登録前と機器登録後で暗号化の仕組みを変えています。
具体的には、NP1の取り付けを行う時は暗号化しておらず、機器登録後、ルート情報などを通信する際などは暗号化された状態となっています。
５：クロージャーベースのI/F思想を導入
MVVMでいうViewからModelへBLEで通信した情報のやり取りを行う際、送受信で使用するコマンド体系（read/write等）を意識して画面操作を行なっていると、画面操作側でリクエスト管理をしなければならなくなり、かなり非効率です。
Viewに近くなればなるほど、送受信で使用するコマンド体系を意識せずデータを簡単にコールバックで受け取れるように、クロージャーベースのコマンド体系I/F思想を取り入れました。
このI/F思想によって、BLEのコマンド体系と画面操作がくっきりと分けられることができるため、ユニットテストの効率化やコーディングの作業分担などが容易に行えるようになりました。
※コールバック：プログラム中で、ある関数などを呼び出す際に別の関数などを途中で実行するよう指定する手法のこと
※クロージャ：組み合わされた（囲まれた）関数と、その周囲の状態の参照の組み合わせのこと
苦労話
いろいろなことを考慮しなければいけない中で、やっぱり苦労したところもありました。
１：車載器との接続確立シーケンスが複雑
先にも書いた通り、機器登録する前と後で暗号化の仕組みを変える以上、NP1（エッジデバイス）の起動モード（機器登録する前と後）が異なるということになります。
それによって、接続のシーケンスを１本では事足りず、２本用意しなければならなくなりました。
起動モードもNP1の側面ボタンで変化してしまうので、My NP1はボタン押下に追従できるようにエラー分岐を複数用意しなければなりませんでした。
２：アクセストークンを利用したBLEコマンドのハンドリング
BLE通信コマンドにアクセストークンを用いたことで、NP1のモードにより使うトークンを変えなければならなくなりました。
機器登録前のトークンは保持する必要ないのですが、機器登録後のトークンは保持しなければならず、アプリ終了後も保持しなければなりません。
この辺の考慮は当たり前なのですが、アプリ終了のハンドリングもしなければならず苦労しました。
他にも、NP1の処理能力を考慮してタイミングのチューニングをおこなったり、機能制限に対するエラー分岐などを考慮しております。
３：デバッグ時の送受信データ解析が難解
BLEの恩恵をうけたことで、検証でも大変なこともありました。
プロトコルバッファを使っているため、アプリ層でのデータハンドリングは便利ですが、通信管理部での解析時の送受信データ解析は逆に難解になります。
通信コマンドをビルドする上では、定義ファイルに従ってプロトコルバッファに任せればいいのですが、バイナリダンプ（バイナリデータの出力）が正しいデータかどうか確認する上では逆にパース（解析）しないといけなくなります。
プロトコルバッファ定義は複数あるので、どの定義ファイルに従っているダンプなのか調査が大変で、バイナリレベルで可読もできないので解析に時間がかかりました。
４：端末による制動の違い
各社スマホ端末でBLEの振る舞いが異なったり、Androidバージョンでも異なり、機種やバージョンに依存しないロジックを検討しなければならず、整合性を合わせるのが大変でした。
１機種のためにロジックを見直さなければならないなど、工数/予算と普及率のトレードオフ関係にも悩まされましたね（笑）
最後に
いかがでしたでしょうか？
BLEを使うってメリットもあるけど大変なこともありますよね。
他にもMy NP1では、レガシーの技術を現代のスマホでも実現できるようにしたり（RTSPを使用した動画ストリーミング再生）、トレンドのアーキテクチャ（navigation・viewbinding・LiveDataなど）を採用したりしています。
この記事が面白いと思っていただけたら、スキやコメントお待ちしております。
モバイル開発部では、パイオニアのスマホアプリのグロースアップに協力してくれる仲間を募集しています。
＜パイオニア採用情報＞
＜カジュアル面談 Meety＞
＜新入社員とベテラン社員の対談 - モバイル開発のリアル -＞