これは、岐阜人材育成講座でおこなった、CoreBluetoothフレームワークの解説の要約です。 白板は、以下の画像です:

Bluetooth Low Enerygとは

Bluetooth Low Energy(以下、BLEと省略)は、Bluetooth4で追加された超低消費電力の通信仕様です。例えば直径20mm 厚み3.2mmのコイン型1次リチウムイオン電池 CR2032 (3V 220mAh)で1〜2年間、接続してデータを送信し続ける状態での連続動作時間が得られます。

超低消費電力のRF通信規格には、BLEの他にANT, ANT+, ZigBeeなどがあります。BLEはBluetoothのブランド力、およびいち早くiPhoneおよびMacに採用されていることから、超低消費電力の通信規格として強い普及力があります。iPhoneに採用されたこと、またBluetoothに含まれることから、スマートフォンとの接続ではBLEが標準です。

Bluetooth4はBluetooth3にLow Energyの技術を追加したものです。Low Energyの技術は、それまでのBluetooth3とは全く別の技術です。そのため、Bluetooth3までの技術をクラシックBluetoothと呼び、Bluetooth Low Energyと区別することがあります。ここでもBluetooth3までの技術をクラシックBluetoothと呼びます。

クラシックBluetoothとBLEの使い分けは、必要な通信速度、製品製造コスト、電池の充電および交換が製品の利用場面に適しているか、などを考慮して決めます。

BLE、規格の狙い

BLEは

• 超低消費電力
• ペリフェラルが安価に作れる
• BLEの認証のものとで、多種多様なペリフェラル開発が可能

を主眼に規格が作られています。

超低消費電力

超低消費電力は、BLEの最も大きな狙いです。クラシックBTはリチウムイオン電池でも2週間程度で電池容量を使い果たすため、都度電池の交換もしくは充電が必要でした。この電池の交換および充電を実現するハードウェアは開発と製造にコストがかかります。またユーザに電池交換/充電を求めることが、クラシックBTが使える利用場面を狭めることがあります。

コイン型1次リチウムイオン電池 CR2032 (3V 220mAh)で1〜2年間、接続してデータを送信し続けるられるほどの超低消費電力であれば、電池が切れる=製品寿命とすることができますから、(ゴミの分別はおいておいて、いわゆる)使い捨てすら可能です。

BLEの超低消費電力は、クラシックBTと全く同じ機能を超低消費電力とするものではありません。物理的に電波を出して1ビットのデータを送受信するために必要な電力は、クラシックBTでもBLEでも、そうは違いはありません。

BLEは、例えば1秒に20バイト程度のデータを送受信するような、データのやり取り頻度は低いけれども、無線接続自体は長期間維持できる応用分野を想定した規格です。データ通信速度も物理層で1Mbpsです。クラシックBTは、ヘッドセットやパーソナル・エリア・ネットワーク(PAN)のような、特定の端末と接続すること(ペアリング)、常時データ通信があること、また高いデータ・レート(~3Mbps)が必要とされる、場面を想定した規格です。

このため、クラシックBTとBLEは、利用場面が全く違います。BLEは、Keyfobのように、常時スマートフォンと無線接続をし続けなければならないもの、またフィットネスの心拍センサーやセンサーネットワークのように、データ量は多くないが一定時間ごとにデータを収集し続ける応用分野に、非常に適しています。

ペリフェラルが安価、また多種多様な開発が可能

BLEには、セントラルとペリフェラルという概念があります。通常、iPhoneがセントラル、心拍センサーなどの周辺装置がペリフェラルになります。無線通信をするためには、接続状態の管理や、パケットの送受信のタイミング制御などが必要になります。これには、CPUを使いますし、また電波の送信受信の電力も必要です。BLEは、ペリフェラルが安価に製造できるように、演算や電池を消費する機能をセントラルに寄せて、ペリフェラルが極めて簡単な構造ですむようにしています。

BLEのネットワークは、1つのセントラルに多数のペリフェラルが接続するピコネット、です。

クラシックBTとBLEでは、プロファイルの考え方が違います。クラシックBTは、通信の振る舞いとハードウェアの振る舞いをあわせてプロファイルとして定義していました。一方で、BLEはハードウェアの振る舞いは何も定義しません。

BLEはサービスという概念で、値の読み出しと書き出しの基本的な振る舞いのみを定義します。例えば電池残量のサービスは、電池残量の値読み出し方法と、その値の意味(ビット割り当てなど)の定義が与えられています。この電池残量のサービスは、様々なBLEデバイスが利用します。例えば、keyfobならば内蔵電池の残量通知に使います。これがもしも、電気自動車ならば、それは電気自動車の主電池残量を意味するでしょう。サービスという概念で、ハードウェアと切り離して定義されているので、抽象化され、サービスを多くの機器で横断して利用することができます。Custom Profile Development

BLEでは、128-bitのGUIDを割り当てたサービスを、開発者が独自に定義して実装することができます。従って、BLEは認証のもとで“任意のハードウェア”が開発できます。BLEでは、一般には定義されていない多種多様なハードウェアでも、独自に定義をすることで開発ができます。

BLEは、サービスを識別するIDに、16−bitのIDと128−bitのIDのいずれかを割り当てできます。16-bitは、BluetoothのSIGが定義したサービスに割り当てられます。このIDは勝手に定義して使うことは許されません。

クラシックBTでは、ハードウェアの振る舞いまで含めてプロファイルが定義されています。このため、プロファイルに定義されていないハードウェアの開発では、シリアルポートプロファイル(SPP)という、シリアル通信のプロファイルを使います。

クラシックBluetoothとBLE

クラシックBluetoothとBLEは、2.4GHzという同じ周波数帯を使っていますが、物理層の変調方式からして方式が違います。ですが、電波を送受信する回路(以下、RF回路)は、クラシックBluetoothとBLEで共用できます。したがって、BT3にBLEを追加したBT4の半導体は、コストの高いRF回路を別に設ける必要がなく、開発コストの利点があります。

Bluetooth SMART READYとSMART

BLE対応デバイスには、Bluetooth SMART READYとSMARTという2種類のロゴがあります。

BLEは、BT3にBLEを追加したものです。iPhoneのように、従来のクラシックBTとBLE両方に接続できる、いわゆる通常のBT4デバイスが、Bluetooth SMART READYになります。一方で、BLEしか実装していないデバイス、心拍計やkeyfobのようなペリフェラルも、BT4対応デバイスです。これはBLEでしか通信ができないので、Bluetooth SMARTと呼びます。

Bluetooth SMARTの製品は、Bluetooth SMART READYの製品と接続できます。ですがBluetooth(BT3以前のクラシックBT)とは接続ができません。Bluetooth SMART READYの製品は、すべてのBluetooth対応機器と接続ができます。ややこしいのですが、BLEだけ、を搭載したペリフェラル相当の機器にもBluetoothロゴをつけるための、区別です。

Bluetooth SMART READY/SMART対応機器のリストは、http://www.bluetooth.com/Pages/Bluetooth-Smart-Devices-List.aspx にあります。

シングルモードとデュアルモード

BLEでペリフェラルに対応する機器は、シングルモードとデュアルモードの2種類があります。シングルモードは、BLEのみを搭載したものをいいます。デュアルモードは、BLEに加えてクラシックBTにも接続できるものをいいます。デュアルモードは、通常、クラシックBTのシリアルポートプロファイル(SPP)でも接続できるように設計します。半導体メーカから、シングルモード、デュアルモード、それぞれのICが開発、提供されています。

シングルモードとデュアルモードのいずれにするかは、 接続する対応機器の範囲で決まります。もしもクラシックBTしか対応していない機器にも接続したい場合は、デュアルモードを選択するほか、手段はありません。また、連続してデータを送り続ける場合にも、デュアルモードを採用するかもしれません。BLEの通信速度は、物理層で1Mbps、実際の通信速度は~50kbps程度です。一方でクラシックBTは物理層で3Mbps(WiFiの物理層を使わないものであれば)で、~500kbps程度です。そもそも、そのような連続かつ高速のデータ送受信をし続ける応用例には、BLEを選択すること自体が、BLEの規格の狙い目からはずれていますから、クラシックBTのみで設計すればよいでしょう。

デュアルモードにすると決めると、自動的に、クラシックBTが要求する電池容量、また充電可能にするなどの、ハードウェアの設計要件が決まります。

もしも開発するハードウェアが、常時センサーを働かせるために電池の消費量が大きいならば、デュアルモードで設計しても、電池まわりはさほど違ったものにはならないでしょう。ですが、間欠的にセンサーを動作させるもので、電池交換や充電が不要で長期間動作することが、ユーザからみた装置の使い勝手や印象に影響するものであれば、デュアルモードにすることは、簡単ではないでしょう。

iOSのBLEデバイス開発

書くのがめんどくさくなったので、箇条書きで:

• 2011年以降発売されたApple製品はBluetooth4対応。BLEデバイスと接続できる。
• BLEデバイスの販売にMFiプログラムは必須ではない。ただしロゴを掲載したいなら参加が必要。
• BLEデバイスと接続するアプリのストア承認にMFiは不要。ただし、アプリの動作を確認するために、BLEデバイスの提出が求められる、かもしれない。

BLEデバイスと接続するアプリケーションは:

• 一般開発者ライセンスで提供されているCoreBluetoothフレームワークで開発する
• アプリはバックグラウンドで動作させられる
• iOS5までは、iPhoneはセントラルのみで動作する。
• iOS6からは、iPhoneはセントラルおよびペリフェラルになれる。

つまり、テレビにもしもBLEリモコンがあったとすれば、iPhoneは任意のBLEリモコンを模倣できる。

応用例

コネクションレス型とコネクション型。BLEは基本コネクションして使うもの。

アドバタイズメント・パケットを利用して、近接検出のコネクションレスな利用ができる。同じデバイスからのアドバタイズメント・パケットを都度受信処理するためには、DuplicatesKeyをYESに設定する:

NSDictionary *options = [NSDictionary dictionaryWithObject:[NSNumber numberWithBool:YES] forKey:CBCentralManagerScanOptionAllowDuplicatesKey];
[centralManager_ scanForPeripheralsWithServices:nil options:options];

はまりどころ

通常のコネクションする使い方ならば、ハマるところはない。 強いて言えば:

• CBPeripheralは自分でretainしないといけない
  • scanForPeripheralsWithServicesで取得したCBPeripheralはアプリ側でretainしないといけない
• デバイスから強制定期にBluetoothの接続切断をすると、iOS6では、CoreBluetoothが例外を飛ばしてくる
  • try~catchして処理

このほか:

• iPhoneが接続したことがないBLEデバイスのUUIDは、アドバタイズメント・パケット受信時はnull
  • iPhoneが、任意のアプリで一度でも接続したことがあれば、UUIDが取得できる。iPhoneの電源On/Offをしてもクリアされない。どっかにキャッシュをもっているのだろう。
• iOS6では、iPhoneからBLE接続を切断しても、iPhoneは30秒〜1分程、BLE接続をもっている。このためBLEデバイスからアドバタイズメント・パケットが送出されない
  • アドバタイズメント・パケットを利用する場合は、デバイス側から強制的にBLE接続を切断する。

このように、細かい所で、iOS5とiOS6で振る舞いが違うところ、タイミングのパラメータ値が違うような些細だけど、使い方によっては致命的になる、ところがある。しらないと、はまるので、事前の確認をしっかりすること。

開発方法のおすすめ

BLEのハードウェア開発は、次章で述べるように、組み込み開発が必要になるために、どうしてもiOS単体で閉じた開発に比べて、時間がかかる。

iOS6では、たぶん、ペリフェラル側もiPhoneでプロトタイピングするのが、よいのではと思っている。BLEデバイスの開発には、ハードウェアそれ自体が特別なセンサーを利用しているか、またBLEの開発の中心は、ハードウェアなのかそれともデータ処理のアルゴリズムなのか、で区別してみる。

まずBLEが特殊なハードウェアを使うものであれば、iPhoneにそのハードウェアの機能がないので、プロトタイピングにはならない。しかしダミーデータを流す程度には使える。

BLE開発が、データ処理に価値がある場合がある。例えばフィットネス関連のBLEデバイスは、ほとんどが、加速度を使う。加速度から消費カロリーや歩数、高度の変化などを算出するのは、データ処理になる。このような、iPhoneにもあるハードウェアを利用し、その開発の工数の多くがデータ処理の場合には、iPhoneでのプロトタイピングは絶大であろう。

iPhoneでプロトタイピングしたソースコードをマイコンに移植すればよい。そのソースコードは、当然ながら、マイコンの性能に合わせて書きなおさなければならないかもしれないが。

BLEのデバイス自体は、とても簡単な回路ととても単純なデータ処理をする設計が多い。電力消費量とデバイスの大きさを考えれば、そのほとんどの処理はiPhone側に持たせたほうが、合理的で利点があるから。

BLEのハードウェア開発

BLEのデバイス開発は、組み込み装置の開発そのものです。ARM Cortex-M0のようなマイコンに、BLEのプロトコルスタックとユーザのアプリケーションを入れて、周辺のスイッチやLED、そしてセンサーを動かすハードウェアを開発していきます。

マイコンを利用する開発の難易度は、何を作りたいか、どう作るかの構想により、大きく違います。構想をたてる時点から、組み込み会社と協業していくことを、おすすめします。マイコン用の開発環境(IDE)があり、C言語で開発していきます。

ここでは、BLEのデバイス開発について、見ていきます。試作では、むき出しの基板に組み上げた回路でもよいでしょうが、実際には、筐体や商品パッケージ、取扱説明書など付随するものも必要です。ここでは、それらは考えません。

フルカスタム開発

半導体チップを購入して、ゼロから設計と開発をすることを、フルカスタム開発と呼びます。フルカスタム開発の設計の流れは:

1. 半導体チップメーカからBLEの半導体を購入
2. 半導体チップメーカの推奨設計例をもとにして、基板回路などを設計
3. 電波法の認証 (試作では1台単位、製造では製造設備単位で認証が必要)

となります。製造まで考慮すると、製造時試験の手順決定と技術文書の作成など、多くの項目がありますが、ここでは省略しています。

BLEの半導体には、BLEの通信機能だけがあるものと、BLEの通信機能に加えてマイコンまで内蔵した、いわゆるSoC(システム・オン・チップ)の2種類があります。いずれを採用する場合でも、通信の制御にマイコンは必須です。

BLEの通信機能だけがあるものを使う場合は、その半導体とマイコンの間は、ホストコントロールインタフェースというBluetoothの規格に従ったプロトコルでやりとりをします。既存の製品にBLEを追加する場合で、すでに製品の中にあるマイコンで通信制御まで実現する場合には、この形を取ります。

SoCは、BLEのプロトコルスタックとユーザのアプリケーションが、BLEの半導体に内蔵された1つのマイコンで実行されます。回路面積を小さく、かつ消費電力を最小にできる利点があります。BLEデバイスをゼロから企画する場合で、大きさや電池の持ちに注目するときには、こちらを採用します。

CC2540を使ったファームウェア開発で、TI社のファーム焼きソフトを使っている場合、”データフラッシュの消去”をすると、CC2540のユーザ書き込みMACが0に初期化される。ドキュメントには、ユーザ指定のMACが0なら、メーカ書き込みのMACを使うとあるが、実際には、使っていない。ユーザのMACが0もしくは0xffいずれの場合も、その値を使ってしまう。すべてのデバイスのUUIDがおなじになり、個別識別ができない。ロット単位のエラッタなのかどうかは知らない。なので、フラッシュをクリアしてしまったときは、メーカ指定のMACをコピペで書き込んでおく。

モジュール

BLEの通信部分を入出力端子が外部に出ている小さな基板に収めたモジュールという部品があります。いろいろな会社からモジュールが出ています。

モジュールを採用する利点は、Bluetoothや電波法の認証を自社で取得する必要がないことです。一方で、モジュールの基板(大変小さくて、1cm角ですが)の形と大きさに製品が制約される場合があります。小型あるいは細長いようなBLEデバイスを開発するときには、モジュールの外形確認が必要になります。

モジュールは、Bluetoothの相互接続認証と電波法が求める工事認証を取得しているため、これを採用すればフルカスタム開発のファームウェア開発を除く手順が省けます。

2012年8月までは、モジュールの工事認証の条件に、モジュールが用意に着脱できること、という条件がありました。これを満たすため、モジュールには“コネクタ”がありました。しかし、2012年8月に、この条件が撤廃されたことで、直接ハンダ付けで固定する表面実装タイプの工事認証が通るようになっています。

BluetoothとMFiのロゴを掲載するには

Bluetooth対応のロゴ、およびMade for iPhoneのロゴを商品に掲載するには、それぞれBluetoothの相互接続認証の取得とMFiプログラムの参加が必要です。

Bluetoothは、認証費用自体は実費で5万円程度ですが、Bluetoothのメンバーに登録するための年会費が1万ドル必要です。自社で設計開発する場合は、自社でBluetoothの相互接続認証を取る必要があります。たいがいのモジュールは、Bluetoothの相互接続認証を取得しています。この場合は、そのモジュールを利用した派生製品であるとBluetooth対応製品のリストに無償で登録ができます。

Bluetoothのロゴを掲載しなくても、正体不明のRF装置として販売はできますが、iPhoneのようなBluetooth SMART READYな装置に接続することを表示するためには、Bluetoothのロゴは必要です。

iPhoneはBluetooth SMART READYなので、BLEデバイスはiPhoneに接続できます。このBLEデバイスの販売およびアプリのストア認証にMFiプログラムは必須ではありません。しかし、MFiのロゴを製品に掲載したいならば、MFiプログラムへの参加が必要です。

半導体チップについて

Bluetooth4対応デバイスは、従来の3までのBluetoothとLow Enery両方と接続できるデュアルモードと、 Low Energyだけに対応するシングルモードの2つにわけられる。iPhoneとBLEで接続するデバイスは、BLEのみに対応する、シングルモードデバイスになる。 シングルモードデバイスは、無線および制御回路を1つにした集積回路として、テキサス・インスツルメンツ、CSR、およびノルディック社の3社から販売されている。 TI社はCC2540およびCC2541の2つのシングルモード集積回路を販売している。価格は2ドル。8051マイコンを内臓しており、BTLEプロトコルスタックをIAR Embedded Workbench IDEのライブラリとして提供している。GPIOおよびADCなどの豊富なIOもあり、BLE接続センサーがワンチップで実現ができる。 CC2541は、BLEに加えてTI社およびノルディック社の独自2.4GHzデータ通信方式も対応している。この独自の無線通信は、例えばマウスやキーボードで独自の2.4GHzの通信仕様を利用している製品をBLEに移行するときに、従来の独自通信技術に対応させつつ、かつBLE対応が求められる場合に使われる。チップサイズは6mm角。

CC2540/2541の開発は、IAR Embedded Workbench 8051を使う。モバイルライセンス、フルセットで 35万円ほど、機能限定版で 25万ほど。また、保守(更新)は、最初3ヶ月は無料、年間更新料として購入価格の20%がかかる。 CSR社は、ウェブサイトで概略しか情報を公開していない。TI社のCC2540同じようなマイコンを内臓したものを販売している。BLEの開発部門はサムスンの出資をうけている。このため、純粋な半導体メーカとして続くのかは、不安に感じるところがある。 ノルディック社は、nRF8001およびnRF8002を販売している。nRF8001は、TI社のものと違い、BLEの プロトコルスタックまでを提供しており、制御はACIインタフェースをとおして別のマイコンで実現する。 nRF8002はnRF8001に、キーレスエントリーのようなキーホルダーに使われる近接等のプロファイルを実 装したもので、BLEで最もよく使われるキーホルダー的な機能が実現できる。チップの価格は3ドル程度 (Mouserで274円、80円/ドルより)。チップサイズは5mm角。 またCortex-M0+を搭載したSoC、nRF51シリーズを発表している。ノルディック社が提供してきた独自規格の2.4GHz通信とBLEに対応したものが出荷されている。この開発環境はKeil MDK-ARMを使います。このライセンス料金は、30万円程度です。このSoCのファームウェア開発方法は、ARM Cortex-M0+の手順そのままです。

モジュール

この他に、BlueGiga社はTI社のCC2540を採用したモジュールを販売しています。このモジュールは、IAR WorkbenchのようなC言語開発環境の代わりに、BASICのようなスクリプト開発環境を独自に提供している特徴があります。また、FCCとCEを取得しており、Bluetoothの相互接続認証を取得しています。ですからBluetooth対応の製品リストに無償で登録ができるので、Bluetoothのロゴを表示して販売ができます。

許認可の取得

Bluetooth4 Low Energy機器を販売するためには、販売国での認証取得が必須です。この認証は、電波を 放出する機器が他の機器の動作を阻害しないことを承認することで、無線局免許がなくても電波を発する無 線装置を運用してよいという制度が求めるものです。この認証なく電波を発した場合は、日本では使用者が 電波法違反を問われます。 Bluetoothのロゴを掲載するには、Bluetoothの団体に加入して、機器相互接続試験をクリアしなければな りません。ロゴを掲載せずBluetooth機器だといわないならば、これを取得していなくても、販売は可能で す。プロファイルによりますが、150~250万円程度がかかります。 この認証は、米国ではFCC、日本ではTELEC、欧州ではCE、と呼ばれます。FCCおよびCEは、一般的な 電気機器にもとめられるEMC(電磁両立性、電気機器などが備える、電磁的な不干渉性および耐性)も必要になります。

EMC試験および無線機器の認証取得代理を提供している会社がいくつかあります。試験および書類申請までを一貫してサービスとして提供しています。回路や電波の技術と法律の両面の知識が必要で専門職でなければ対応は難しいので、設計段階から、相談をしておくことが大切です。

電波を出す製品を米国、日本、欧米で販売するための許認可は、それぞれFCC、工事認証、CEになります。設計したものが基準を満たせず再試験になった場合には、その追加費用など、付随する費用発生がありますが、最低限必要な費用なの目安は:

• FCC 165万円くらい
  • EMC(9kHzを超える) 40~50万円
  • 無線に関わるもの(Part15 sub C、電磁障害なきこと) 80万円
  • 米国への書類提出など 25万円
• 日本 48万円くらい(書類作成、申請代行費用は含まず)
  • 工事認証(工場生産単位での認証) 48万円
• CE 合計220万円くらい
  • EMC 100万円
  • 無線関連(障害なきこと) 80~90万円
  • 電気機器の安全性確認 30万円
    • 認証に提出するデータは、量産と同じもので計測されたものを提出します。

製造設備および体制に対して、 求められるものは:

• FCC
  • 特に無い
• 日本
  • 製造されたものの特性が同一であること、そのために品質が管理されていることを書類で明らかにする。
  • 具体的にはISOを取得している、出荷時検査の装置や測定手順が決められていてデータが保存されているなどの、体制の整備が審査対象になる。
• CE
  • 特に無い
  • しかし、各国で抜き取り調査をしている。もしも違反している場合は、製品の全数回収の義務が生じる。また罰金が課せられる。

ここでは書いていないこと

ぶっちゃけです。

AndroidとWindows Phone8でのBLE対応アプリ開発

BLEのAndoridのプロトコルスタックは、Googleから公式に提供はされていない。ADK2.0でBLEをつけているのにと思っても、ぶっちゃけあれはデュアルモードなので。モトローラなど、半導体もやっているところや、BLE開発を先行して進めている会社がそれぞれ自社の名前空間でBLE対応のプロトコルスタックを出している。BT4対応のハードか否かも、機種依存で、プロトコルスタックもカオス。近づいたら火傷しそうな落とし穴を、考えつく限り散りばめた、カオスすぎる状況。

Windows Phone8は、ハードウェア要件にBT4必須がない。Windows8のハードウェア要件にはBT4必須があるので、Phoneでは違うんだ、に気をつけておかないと、混同しやすくて危ない。スタックは、Windowsと同じなので、使いやすいかも。特定プロファイルの実装はあったけど、128-bitな独自のサービスにも対応できるかは調べがついていない。