BLEとThreadソフト開発者必見動画

IoT通信規格のBLE 4.2とThread(802.15.4)両方をサポートするNXP)Kinetis KW41Z搭載の評価ボードを使ったBEL4.2とThreadメッシュ接続の開発Video(タイトルが以下Lesson 1~10)を紹介します。

Kinetis KW41Z Video Lesson Contents
Kinetis KW41Z Video Lesson Contents

BLEやThreadソフト開発者必見のLessons

内容、質ともに優れたVideoでMCUXpressoとSDKの使い方も良く解ります。特に興味深い内容とその出所が以下です。

  1. Bluetooth ClassicとBluetooth Low Energyの本質的な違い(Lesson 3、3分ごろ)
  2. Bluetooth ClassicとBLE間を接続するBluetooth Smart Ready(Lesson 3、6分ごろ)
  3. BLE接続の具体例(Lesson 3、19分ごろ)
  4. BLE/Thread接続に必要な知識(Lesson 3, 6)
  5. Threadが生まれた背景(Lesson 6、2分ごろ)
  6. Cortex-M0+/48MHz、512MB ROM、128KB RAM、FreeRTOSで実現するBLE/Thread IoT端末(Lesson  5, 9, 10)

BLEやThreadに関する情報は多くありますが、ソフト開発者の立場からは、本Lessonsが最も要領よくポイントをまとめています。

Kinetis KW41Z

KINETIS KW MCU FAMILY BLOCK DIAGRAM
KINETIS KW MCU FAMILY BLOCK DIAGRAM

Kinetis KW41Zの評価ボードは、以下の2種(Digi-Key価格)です。

低価格で有名なFRDM評価ボードですが、さすがに両プロトコル対応のKW41Z搭載ボードとなると$100以上します。Videoで使っているR41Z-EVALは、約$60と安く入手できます。但し、Lesson 10のBLEとThreadメッシュ切り替え接続の動作確認を行うには、同時に3台の評価ボードが必要です。

ThreadのみサポートのKW21、BLEのみのKW31もありますが、無線規格が乱立していて、どれが本命かを見極めるのが困難な現状では、両プロトコルサポートのKW41が安全でしょう。

API for IoT

MCUXpressoとSDKを使って、BLEまたはThread通信機能を持つIoT端末を開発する際に、プロトコルのどの部分の変更/修正が必要で、それがソース上のどこにあるか、全体の開発手順などはVideoを観ると良く解ります。

BLE Protocol Stack
BLE Protocol Stack

また、LEDなどのGPIO制御を行うSDKデモソフトとIoT通信の並列処理は、FreeRTOSを使って実現していることも解ります。簡単なIoT端末なら、このデモソフトに、外部センサ値をAD変換し、その変換データをクラウドのサーバーへIoT経由で送信する機能を追加しさえすれば、直ぐに開発できそうです。
※簡単なIoT端末は後述

BLEやThreadは、IoT通信の有力な候補です。しかし、IoTの通信プロトコルが何になるにせよ、IoT通信向けのAPIが決まれば、あまり気にする必要がない、というのが全Lessonを通しての私の感想です。

その理由は、デモソフト実装済みのGPIO制御はそのまま使えますし、FreeRTOSを使っていますので、外部センサ入力を定期的にADCする処理(ADCスレッド)と、ADC変換データをIoT通信APIへ出力する処理(IoT出力スレッド)の2処理を追加開発すれば良いからです。

ADCスレッドは、IoT通信規格には無関係です。一方、IoT出力スレッドは、Uart出力と同様のIoT APIが使える(用意される)と思います。NXP)LPC8xxマイコンのUart APIの例で示すと、Chip_UART_SendBlocking()が、Chip_IoT_SendBlocking()に代わるイメージです。IoT API利用条件が初期設定で満たされれば、ユーザは、通信速度や、通信プロトコルを意識せずにIoT通信を使えるようになると思います。

*  *  *

IoT通信規格が不確定な状況で、少しでも早くIoTやRTOSに慣れるには、R41Z-EVALは良い評価ボードです。また、FreeRTOSを使えば、48MHz動作のCortex-M0+、512MB ROM、128KB RAMで簡単なIoT端末が開発できそうな見通しもこれらLessonは、与えてくれました。是非、ご自分でご覧になってください。

簡単なIoT端末のイメージ

データ入力とGPIO出力を行うMCU端末で、IoT無線通信機能を備える。通信セキュリティを確保できるAES-128などの機能も備え、対象機器から取得したデータを安全にクラウド内のサーバーへ送信する。
サーバーは、対象機器データを人工知能を使って予測分析し、結果を端末へ送信する。
端末は、受信結果を基にLEDなどのGPIO出力を行い、オペレータまたはロボットが対象機器メンテナンス作業の手助けをする。

Bluetooth 5仕様

6月18日記載のBluetooth 5の仕様が記事になり、内容を一覧表にしてみました。

Bluetooth 5 Specification
項目 Bluetooth 5仕様 備考
通信モード 2Mbps 最大100m(100mW出力) 従来バージョンと後方互換、2Mbpsを追加
1Mbps
125Kbps 最大400m(100mW出力) 従来比4倍の通信距離
通信範囲 メッシュ機能リリース予定 従来Bluetooth 4.2などもメッシュ利用可
消費電力 従来と同等 2Mbpsなら従来比短時間通信のため低消費電力
ブロードキャスト機能 最大255文字 URL送信可能(従来31文字)

 

Threadと同様、一軒の家の範囲をくまなくカバーする「メッシュ網」と、2020年に450億台と予想されるIoT機器のうち、3分の1の140億台のIoT機器への搭載を目標にしているそうです。

Bluetooth 5 2017年初頭リリース予定

住宅全体、ビル全体、屋外での利用も可能なBluetooth 5が2016年末~2017年初頭にリリースされる予定だそうです。

前回のThread記事で書いたように、現行版Bluetoothがスマホとウエラブルデバイス間に適しているのを、通信到達距離を4倍、通信速度を2倍にし、しかも現行版と同じ低消費電力で実現するのがBluetooth 5です。

メッシュのThreadと、スターのBluetoothの違いがありますが、どちらも狙いはIoTエンドポイントのマイコンへの普及です。

より軽く「UART over Bluetooth」または「UART over Thread」を実装できる方が望まれると思います。マイコン:MCUにとって、デバッグの容易さから、UARTは消えゆくレガシー周辺回路ではなく必須回路と考えるからです。

一方、現在のIoTコンピュータ:MPU/SBC側の対MCU通信インタフェースはBluetoothです。こちらにその理由と、ネットワーク構成を示します。
ThreadとBluetooth 5の普及状況に応じてMPU/SBCでは、両サポートになりえます。

IoT無線規格「Thread」

Threadは、Wi-FiやBluetoothなどの既存無線通信と異なりメッシュメットワーク構成の2015年7月発表の新しいIoT無線規格です。詳しい記事はコチラ、またThread詳細はWebを参照して頂くとして、ここでは記事要旨を示します。

Threadの特徴

Thread System Messaging Model
Thread System Messaging Model(2016_05_10_ThreadPresentation.pdfより抜粋)

メッシュ網構成: Wi-FiやBluetoothの1対1(多)のスター網構成に対し、通信堅牢性と通信範囲の確保を目的にメッシュ網で通信。

ネイティブIP通信:OSIのネットワーク層とトランスポート層の仕様策定が目的で、超低消費電力で短距離通信のIP通信を行うオープン仕様。上下層は、既存レイヤー仕様をそのまま使用。

ネットワーク管理機能と高セキュリティを両立:ノードトラブルや網障害に対し、自己修復し通信継続。

長期電池駆動が可能:長期電池駆動が可能なデータ送受方法を採用。

などホームネットワーク要件を全て満たす。

主要参加メンバー

Thread Group Sponsor BoD Members
Thread Group Sponsor BoD Members(2016_05_10_ThreadPresentation.pdfより抜粋)

ホームコントロール大手Somfy、ホームセキュリティ大手Tyco、Qualcomm Technologies、照明大手OSRAMなどの企業と、マイコン大手NXP、ARMなどが主要メンバーとして参加。

以上が記事要旨にWebから得られる情報を追加したものです。以下の理由で私はThreadに期待しています。

BLEは重い

BLE: Bluetooth Low Energyは、少量データの送信には理想的ですが、アプリケーション規格などが厳格で、「スマホとウエラブルデバイス間通信」に適しています。

しかし、これをマイコンで「単に土管として無線を使いたい」場合には少し重たい気がします。例えば、マイコンUART入出力をIoTコンピュータ:MPU/SBCへ無線で接続する時などです(BLEとROM量はコチラに記載)。

※土管として無線を使うとは、例えば、UART over BLEなどです。

莫大な販売量が見込まれるとしてもIoTエンドポイントマイコンは、ROM/RAMが少なく低価格デバイスが向いていると思います。BLE機能を実装するとROM量は64KB超が予想されます。

Threadが、BLEより軽くマイコンへ実装できれば、IoTエンドポイント通信の本命になるかもしれません。