BLEデバイスと接続してそのデータを基にグラフィカル表示するlinuxベースのアプリケーション装置において、以下の観点からアプリケーションソフトウエアを再構築する。
①bluetoothデバイスと24時間通信継続する装置における通信の安定性を得ること。
②通信切断後の再接続のアプリ側と通信デーモン側の間の状態不一致を回避すること。
FlutterBluePlus方式
Flutter
├─ UI
├─ Graphics
└─ Bluetooth ─ BlueZ
Pythonサービス方式
systemd
├── ble_manager.service
| ├─ Bluetooth ─ BlueZ
├── Flutter.service
├─ UI
└─ Graphics
FlutterBluePlus方式にて、グラフィックス表示とbluetooth通信管理を一括で設計しているが、各種の検証試験において、BlueZデーモン側とアプリケーション側の両者間でbluetooth通信状態の不一致が発生するケースが発生している。通信シーケンスの改善を実施し、かつ状態遷移の各ポイントにおいて補償処理を追加することで、状態不一致はほぼ回避できている。
Pythonサービス方式では、BLE制御をBlueZのD-BusAPI経由で独立したサービスとして動かせるため、Bluetooth機能をUIから分離する。Flutterは画面表示だけとし、BLE Managerは通信だけとし、役割を分離することで設計を明確にする。Pythonで ble_manager.service を作り、FlutterとはSocket通信で連携する構成である。Bluetooth通信の安定性が製品品質に直結するため、BLEをUIから独立したサービスに分離するアーキテクチャが最も堅牢で、将来の保守や機能追加にも対応しやすいと考える。
両方の方式が完成したので、各アプリケーション毎にその適正を考慮して方式選択する予定である。
