多センサーBLEゲートウェイの容量と再接続を試験する

「1台のゲートウェイで何台のBLEセンサーを扱えるか」という問いには、負荷条件を添える必要があります。1分に1回報告する10台と、20ミリ秒ごとにバースト送信する10台では、課題が異なります。根拠のある容量仕様は、無線とソフトウェアの制限を明確にし、必要な負荷でデータ鮮度を実証し、複数のセンサーが同時に消失した際の復旧を測定します。

接続型収集かアドバタイズ収集かを選ぶ

接続型GATTゲートウェイはリンクを維持し、キャラクタリスティックを購読し、設定指令を送る場合もあります。アドバタイズ収集器は、接続を伴わない報告を受信します。Bluetooth Meshは、これらとは別の通信・プロビジョニングモデルです。各方式では探索、配送、安全性の性質が異なり、ノード数をそのまま比較することはできません。

まず機器一覧を作成します。プロトコルとファームウェアの版、報告形式、サンプリング周波数、バースト長、接続可否、ペアリング要件、許容データ年齢を記録します。欠けた過去サンプルの回収が必要か、最新の測定値だけでよいかを決めます。アドバタイズ収集でも、導入先の要件に応じて、真正性、重複排除、リプレイ対策をアプリケーション側で定義する必要があります。

Obeitaの納入済みESP32 Wi-Fi・Bluetoothゲートウェイ事例は、Wi-FiとSIG Meshという異なる方向性を説明しています。アーキテクチャを検討する参考になりますが、接続型GATTセンサーの容量実測値は掲載していません。GATTゲートウェイには、対象端末と負荷に対する独自の検証が必要です。

接続数の上限と実用上の容量を区別する

正確なチップ型番、コントローラーファームウェア、ホストスタック、SDKバージョン、ビルド設定を確認します。ホスト接続オブジェクト、コントローラーのリンク数、ACLバッファー、ボンディング情報の保存領域、アプリケーションキューには、それぞれ別の上限があります。一つの設定を増やしても、ほかの制限はなくなりません。

バージョンを限定した具体例として、EspressifのESP-IDF v6.0.3向けESP32マルチ接続ガイドは、ESP-NimBLEとESP-Bluedroidについて各9本の同時接続を示し、対応するホスト設定と一致するコントローラー設定を要求しています。これは実装上限であり、あらゆる負荷やESP32系列の全チップに対するセンサー台数の保証ではありません。ZephyrにもCONFIG_BT_MAX_CONNがあります。実製品が使うリリースの文書を確認してください。出典：Espressifマルチ接続ガイド、Zephyr GAP Shell文書。

Linuxゲートウェイでは、RAMを増やしたりCPUを高速化したりしても、無線コントローラーの接続上限が上がる根拠にはなりません。USB/UARTコントローラーの型番、ファームウェア、カーネル、BlueZの版を記録します。通知コールバックは短く保ち、検証してキューへ入れた後、データベース書き込みや上り通信をBluetoothコールバック経路の外で実行します。

実測の余裕を含めた通信量予算を立てる

最初にアプリケーションのバイト数を計算します。例えば、8台のセンサーが各16バイトの記録を5 Hzで生成すると、プロトコルのオーバーヘッドを除いて毎秒640バイトになります。これは無線スループットの予測ではありません。パケット交換、空の接続イベント、確認応答、再送、スキャン、スケジューリングにも時間が必要です。

一次評価では、各リンクの接続イベントが占有すると予想される空中時間をその接続間隔で割り、合計する方法が有用です。スキャン、再接続、上り通信との共存のために余裕を残します。この推定はBluetoothのスケジューリング保証ではなく、実測の代わりでもありません。イベント重複、コントローラー方針、バースト到着により、平均予算に余裕があっても失敗することがあります。

交渉済みの接続間隔、Peripheral Latency、監視タイムアウト、PHY、ATT MTU、リンク層データ長を測定します。ATT MTUが大きくても、リンク層パケットが長くなるとは限らず、毎イベントの交換パケット数が増える保証もありません。接続間隔を広げると調整しやすくなる一方、遅延やバーストのバッファー要求が悪化する場合があります。一般的な「最大スループット」設定ではなく、鮮度目標に対してパラメーターを変更します。

再接続を上限のある状態機械として実装する

センサーごとに、探索、接続、安全性の確立、サービス解決、購読、ストリーミングを独立して追跡します。「接続済み」は準備完了ではありません。購読後に、正しく識別された最初の有効なアプリケーションサンプルを受信することが、有用な準備完了基準です。

DISCOVER -> CONNECT -> SECURE -> RESOLVE -> SUBSCRIBE -> STREAM
failure  -> RELEASE_RESOURCES -> BACKOFF -> DISCOVER

# Illustrative full-jitter backoff, seconds:
delay = random_uniform(0, min(60, 2 ** min(attempt, 6)))
# Reset attempt after a defined healthy-stream interval.
# Limit simultaneous connection/setup attempts globally.

上記の時間値は設計例であり、BLEの必須設定ではありません。各状態にタイムアウト、キャンセル経路、理由コードを設けます。非互換のプロトコルや繰り返す認証失敗など、対処が必要な故障は再試行回数などに上限を設けます。高速で無期限に再試行せず、対応可能な障害情報を表示します。

切断後は、古いハンドルとコールバック登録を適切に解放し、不要になった処理を中止した後、必要なセキュリティと購読を再確立します。対応するボンディング／プライバシー機構か、認証済みのアプリケーション識別子で恒久的な同一性を維持します。変化するプライベートアドレスを常に別の新規センサーと見なしてはいけません。BlueZでは、サポートされる通知インターフェースを使い、文書化されたエラーを処理します。BlueZ GATT APIを参照してください。

起動識別子とサンプルシーケンスで、再起動、欠落、重複を区別します。製品の復旧仕様に必要な状態だけを永続化します。蓄積データの送信中にゲートウェイが再起動しても、古いサンプルを暗黙にリアルタイム値へ分類し直してはいけません。

全リンクが稼働中に競合と故障を試験する

無線部を共有する設計では、BLE収集とWi-Fi通信が無線資源を競合します。Espressifは、優先度に基づく共存と、Wi-Fi状態によるスケジューリング変化を説明しています。安定した上り通信と、Wi-Fiスキャン／再接続の双方を試験します。静かな評価台上の接続では、これらの条件を網羅できません。ESP32共存ガイドを参照し、その後、採用するSDKとチップに対応する文書を確認します。

量産用筐体、アンテナ位置、電源を使います。対応センサー台数と報告頻度を変化させ、意図する動作境界で、制御された減衰または代表的な配置を使って繰り返します。RSSIだけでは合否を決められません。強信号の対照グループを維持し、キューやCPUの故障を無線問題から切り分けられるようにします。

利用可能なデータを基準に受入条件を定める

試験前に合格しきい値を決めます。仕様例としては、サンプル年齢の99パーセンタイルを2秒未満とし、所定の重複を除いたサンプル配送率を満たし、合意した復旧時間内に到達可能な全センサーを復旧させる、といった条件があります。これは要件例であり、報告済みの実測結果ではありません。1分に1回測定する低速センサーには、別の鮮度目標が必要です。

分母を定義します。測定期間中に生成されるはずのサンプル、センサーが保持したサンプル、送信可能だったサンプルは、異なる数量です。重複は、ユニークな配送済みサンプルとは別に数えます。既知のオフライン期間が目標にどう影響するかを記録します。初回試行成功率と最悪ノードの振る舞いも含め、全体平均が特定センサーへの資源供給不足を隠さないようにします。

センサーの取得時刻からサンプル年齢を測定するのは、時刻同期が取れているか、時刻差とドリフトに上限がある場合だけです。そうでなければ、ゲートウェイ受信から上り送信までの遅延を別に報告し、エンドツーエンドの年齢は不明と明記します。ローカル状態の継続時間には単調時計を使い、故障、検出、接続、購読、最初の有効サンプルまでの全時系列を記録します。

実際に故障した層を切り分ける

• リンクは接続したがデータが来ない：サービス解決、購読状態、権限、センサーのデータ生成状態を確認します。
• 台数を増やした場合だけ失敗する：コントローラー上限、バッファー不足、イベント調整、全体の初期化並列数を調べます。
• 上り通信の後に故障する：Wi-Fi共存の記録、コールバック時間、キュー増加を比較します。
• 不調な1台がほかの全機器を遅らせる：共有ロック、直列化された無制限再試行、キューの公平性を調べます。
• 再起動しないと再接続できない：接続オブジェクトのリーク、古いコールバック、タイムアウトで抜けられない状態を確認します。

有用なプロジェクト資料には、センサー実機、ファームウェア版、通信量プロファイル、トポロジー、上り通信の動作、数値による受入目標を含めます。Obeitaのゲートウェイ統合サービスで作業範囲を相談できます。成果物は、選択した構成のバージョン付き容量範囲と復旧レポートとし、ログで結果を裏付けるべきです。 関連する納入済みESP32 Wi-Fi・Bluetoothゲートウェイ事例も、構成検討の参考になります。本文の数値例と試験計画は、この事例の実測結果ではありません。