BLE 接続製品の開発過程で、「シリアル プロファイルはどこにあるの?」という疑問が生じるかもしれません。おそらく、Bluetooth SIG Web サイト上のプロファイルの長いリストをスクロールしているときに、シリアル プロファイルを見逃したと思ったのでしょう。あるいは、持っていません。私はそれをまったく見ていませんでしたが、より高速な方法、つまりチップセットが提供するシリアル API 実装を選択する準備をしていました。実際、これら 2 つの方法はどちらも機能しません。公式の Bluetooth 設定ファイルは機能しません。シリアル Rx/Tx をサポートします。
では、Bluetooth Low Energy シリアルは、Bluetooth の使い方を学びたくない人にとっては単なる不十分なツールなのでしょうか? あるいは、Bluetooth Low Energy シリアル戦略に正当な利点はありますか?
次回、コネクテッド製品のコミュニケーション戦略を設計するときは、次の点に留意してください。
Bluetooth Low Energy (BLE) は、Bluetooth (現在は Bluetooth Classic) の低電力代替品として設計されました。BLE を使用すると、デバイスはコイン型電池で何年にもわたって通信できます。BLE は、小さなデータの塊をできるだけ効率的に送信することに重点を置くことでこれを実現します。この効率を実現するために、Attribute Protocol (ATT) と呼ばれるクライアント/サーバー アーキテクチャを採用しています。
ATT は、サービス、特性、および記述子記述子で構成されます。これらの各オブジェクトをプロファイル構成ファイルと呼ぶことができます。記述子は機能に属し、その機能の属性を表します。キャラクタリスティックには状態があり、さまざまな状態において、クライアントは、その変更の読み取り、書き込み、またはサブスクライブによってサーバー側のキャラクタリスティックと対話します。サービスは一連の特性です。
BLE はシリアル プロトコルとはまったく思えませんね。これは、シリアル パケットに関連するすべてのオーバーヘッドが抽象化され、読み取り、書き込み、通知のための単純なインターフェイスのみが残るためです。それにもかかわらず、チップメーカーは BLE シリアル ポート プロトコルを採用し、それぞれが自社のチップセットに BLE シリアル ポート プロトコルを実装し、カスタム プロファイル (顧客プロファイル) と API を作成しました。
Microchip Technology の Transparent UART サービス、Nordic Semiconductor の Nordic UART サービス、および Texas Instruments のシリアル ポート サービスは、BLE シリアル ポート用に作成されたカスタム プロファイルのほんの一部です。Bluetooth Low Energy 製品に BLE よりもシリアルを選択することには多くの利点があるため、そうするのは理にかなっています。
注: BLE シリアル通信とは、通知/指示 (notify/indicate) のみを許可する RX 機能と、書き込みのみを許可する TX 機能を含む、単一のサービスで構成される ATT 設計を指します。
Bluetooth Low Energy シリアルを使用する理由
Bluetooth Low Energy シリアル プロトコルを使用する主な理由は、使いやすいことです。組み込みエンジニアにとって、シリアル プロトコルの設計と使用は呼吸するのと同じくらい簡単です。使い慣れたプロトコルに固執することで、開発が迅速化され、最終製品の信頼性が高まります。
BLE シリアル ポートを使用すると、使い慣れているだけでなく、BLE 経由で送信されるアプリケーション データ形式が他の有線および無線トランスポート プロトコル (UART、SPI、Wi-Fi など) と相互運用可能であることも意味します。したがって、BLE プロトコル スタックがメイン アプリケーションとは異なるプロセッサ上にある場合にも、BLE シリアル ポートには大きな利点があります。
メイン アプリケーションとは別のプロセッサ上で BLE スタックを実行するのは、組み込みアーキテクチャの一般的な戦略です。これらの BLE コプロセッサは、完全な SoC から専用の BLE スタックまで、複雑さは異なりますが、すべての作業を完了するには十分です。
ハードウェアの機能に関係なく、プロセッサがメイン アプリケーションを実行していない場合、単純に BLE チップを構成し、別の UART ラインとして対話できるのは非常に魅力的です。パケット プロトコルの変更、新しいデータ タイプの送信、パケット インフラストラクチャ (長さフィールドやパケット識別子フィールドなど) の調整はすべて、BLE コプロセッサ上で何も変更せずに実行できます。これは、コプロセッサが送信内容を気にしないためです。すべてを転送するだけです。
一般に、BLE シリアル ポートはより速く接続を確立できます。上の図に示すように、接続確立時間は、検出されたサービス、特性、記述子の数に比例して増加する傾向があります。
「検出」とは、アプリケーションがそれらが何であるかを認識し、後で参照できるように、すべてのサービス、特性、および記述子にハンドルをマッピングすることを指します。接続の開始時に、追加のサービス、特性、または記述子が検出されるたびに、接続を使用してアプリケーション データを転送できるようになるまでに、1 ～ 3 つの接続間隔が追加されます。
iOS システムの接続間隔 (接続間隔) は通常 30 ミリ秒ですが、Android システムでは 7.5 ミリ秒程度になる場合があります。BLE シリアル ポート アーキテクチャは、1 つのサービスと 2 つの特性だけを使用して、大量のさまざまなデータを送信できます。
Bluetooth Low Energy シリアル通信のデメリット
Bluetooth クラシック プロトコルも含め、ほとんどすべての形式のデジタル通信は、さまざまなレベルのカプセル化を備えたシリアル プロトコルに基づいています。
では、なぜ Bluetooth Low Energy を単純なワイヤレス UART リンクとして使用できないのでしょうか?
Serial over BLE の最も重大な欠点は、アプリケーションの遅延が長いことです。アプリケーションの遅延が増加すると、ユーザー エクスペリエンスが低下し、デバイスが低電力状態に移行することで節約できたはずの時間が無駄になったり、占有されたりすることになります。
上の図に示すように、リクエストを受信した後、実行のためにペリフェラル アプリケーション層 (ペリフェラルのアプリケーション層) に渡す必要があります。リクエストの実行後、レスポンスを適切なパケットにカプセル化する必要があります。次に、応答パケットはペリフェラルの BLE スタックに渡され、ペリフェラルからセントラルに指示が送信されます。
周辺アプリケーションがメモリから直接データを返す場合でも、中央デバイスは要求されたデータを受信するために少なくとも 2 つの接続間隔を必要とします。ほとんどの場合、アプリケーションによって BLE レイヤーに対して行われたすべてのリクエストはキューに入れられる必要があるため、中央デバイスが行ったリクエストに対する応答を受信するまでにかかる時間は、通常より長い接続間隔が必要になることを考慮します。
標準 BLE 読み取りリクエストの場合、上図に示すように、周辺アプリケーションは特性の状態を継続的に更新します。読み取られると、キャラクタリスティックには要求されたデータがすでに含まれており、すぐに応答します。リクエストとレスポンスは接続間隔内に保持されます。
BLE シリアル モードでのアプリケーションの遅延も、接続内のどちらのデバイスも関心のない種類のデータをフィルターで除外できないため、より高くなります。したがって、重要でないパケットが破棄される前に、すべてのパケットが BLE 経由で送信され、アプリケーション層に渡される必要があります。
BLE シリアル戦略で時間と電流を無駄にするもう 1 つの要因は、アプリケーション層でデータ パケットに追加されるオーバーヘッドです。パケット識別子、長さフィールド、およびチェックサムはすべて、BLE シリアル ポリシーのアプリケーション層パケットに追加されるフィールドです。同じフィールドがカプセル化された BLE パケットにも追加されます。これらの繰り返しフィールドは BLE 無線送信にビットを追加しますが、BLE プロトコルにはさまざまな問題を処理する独自のメカニズムがあるため、ほとんど価値はありません。
BLE 製品が iOS および Android を実行しているデバイスと通信する場合は、他にも留意すべき考慮事項がいくつかあります。まず、複雑なパケット プロトコルでは、開発者 (おそらく別のチーム) が参照できる詳細なドキュメントが必要です。また、BLE パケットのシリアル化では、モバイル アプリケーションには、有用な情報を解析する方法と送信先を知るために、あらゆる種類のパケット プロトコルを検査する中央パケット処理インフラストラクチャが必要です。最後に、モバイル プログラミング言語 (Android など) は 1 バイト未満のオブジェクトを処理することが難しいため、BLE シリアル データ パケットはバイト サイズのデータ ユニットのみで構成できます。
BLE シリアル パケットの最後の欠点は、カスタム パケット プロトコルを使用すると、他の BLE ソフトウェアとの相互運用性が大幅に制限されることです。BLE 無線の数が増えると、デバイスがパートナー アプリケーションや他の BLE ベースのシステムと通信できるようになる可能性を想像するのは難しくありません。これが、統合プロファイルを可能にする Bluetooth SIG プロファイルの真の力です。
コネクテッド製品では、どのテクノロジーを使用するかを選択する必要があります (コネクテッド製品で何を使用する必要がありますか)
BLE シリアル通信戦略の長所と短所を理解したところで、「製品の設計を適切に決定するにはどうすればよいですか?」と疑問に思われるかもしれません。
どの方法を使用しても、設計タスクを完了するために使用可能な製品を作成できるため、答えは主に設計者にかかっています。ただし、設計アプローチは製品開発の容易さとパフォーマンスの両方に影響します。
コミュニケーション戦略を比較する場合、最初に考慮すべきことは、製品の物理的な制約です。スループットが主な関心事である場合、特にデータの大部分が一方向に流れる場合、シリアル通信戦略を使用すると、最短時間で最も多くのデータを転送できます。BLE 無線から最大のパフォーマンスを得る方法を理解する必要があります。Bluetooth モジュールの処理能力が不十分な場合、Bluetooth モジュールとインターフェイスする最も簡単な方法は、シリアル通信戦略インターフェイスを使用することです。
上記の状況では、BLE シリアル通信が使用される傾向があります。構築している製品のハードウェア ソリューションの実際の条件による制約が問題にならない場合は、UX (ユーザー エクスペリエンス) の制限、つまり遅延に焦点を当てる必要があります。
優れたユーザー エクスペリエンスは、いつでも機能し、直感的に使用できるデバイスを作ることから何よりも大切です。もちろん、遅延が良好なユーザー エクスペリエンスに影響を与えないことを保証する必要があります。この場合、最適化したいのは、接続レイテンシとアプリケーション レイテンシです。
接続待機時間は、アプリケーション データ転送ポイントに接続するのにかかる時間です。一方、アプリケーションの遅延とは、アプリケーションが接続されたデバイスに要求を行ってから応答を受け取るまでにかかる時間です。
BLE シリアル戦略で使用されているように、より少ないサービスと特性を使用し、より高速なアドバタイズ レートを使用することで、接続遅延を改善できます。ただし、BLE シリアル プロトコルを使用すると、特にデフォルトでは接続全体で情報の流れが継続するため、アプリケーションの遅延が犠牲になります。
クライアント/サーバー設計を使用すると、このアプリケーションの遅延が回避され、超高速の応答が提供されます。長時間実行される接続を使用するデバイスの場合、接続のセットアップ時間とアプリケーションの遅延の間のトレードオフは非常に簡単です。さらに機能を追加できます。
ハイブリッド モデル: 両方の長所 (ハイブリッド モデル: 両方の長所)
BLE シリアル戦略とクライアント/サーバー アプローチは、スペクトルの両端です。多くの製品では、最適な設計はその中間にあります。
パンチスルーの場合、顧客は通常、BLE シリアル戦略を実装した後に会社に来ます。また、製品の通信プロトコルを最初から作成する機会がある場合、通常はハイブリッド戦略が考案されます。
ハイブリッド BLE アーキテクチャを設計するための経験則をいくつか示します。
-
BLE シリアル ポリシーから始めて、必要に応じて機能を抽出します。
-
セントラルから迅速にアクセスする必要がある値には、ペリフェラルが常に更新されるという読み取り可能なプロパティが必要です。
-
ログやファームウェアのアップデートなどの一括バックグラウンド転送には、ユーザー エクスペリエンスに関連する通信が妨げられないように、独自の特性が必要です。
-
急速に変化する状態情報は、単一時点のスナップショットとして表示できるようにグループ化する必要があります。これは、システムがデバイスの状態を説明するためにさまざまなセンサーからのデータを必要とする場合に役立ちます。
-
現在のクライアントにとって役に立たない情報は、別の機能を通じて送信するか、クライアントが興味に応じて情報をオンまたはオフにできるようにする必要があります。このようにして、クライアントはどのような情報を受信するかを制御できます。
-
他のシステムにとって価値のある情報は、標準の Bluetooth プロファイルを通じて公開される必要があります。(バッテリー残量、温度、その他の情報など)
参考：
1. BLE SPP の設計戦略