似通るBluetoothと無線LAN

Bluetooth 5と無線LANの類似性が増し、互いの領域に滲出、相互補完が薄れていくという記事、両規格の生立ちと規格の方向性が良く解ります。

Bluetoothと無線LANの領域

本ブログ掲載のMCUとMPU/SCB間の無線規格のページの下図で見ると、両規格の違いは、バッテリー消費量です。

Bluetooth(BLE)とLPWAの違い
Bluetooth(BLE)と無線LANの領域

記事要旨を表にしました。Bluetooth 5の機能強化点が、無線LAN側を浸食していきつつあるのが解ります。

Bluetooth 5と無線LANの生立ちと規格の方向性
  Bluetooth 5 無線LAN
生立ち RS-232C代替無線規格、シンプルなネットワークスタックで低消費電力 IPネットワークの無線化
周波数(Hz 2.4G 2.4G/5G
通信速度/距離 複数デバイス間の低速少量データ 数100Mbps~数Gbps、100m(max)
機能強化点 速度:2Mbps
通信範囲:4倍
ブロードキャスト容量:8倍
コネクションレス通信サポート
暗号化サポート
セキュリティ規格WEP:Wired Equipment PrivacyからWPA:Wi-Fi Protected Accessへ

無線LAN側は、スリープモード利用で省電力強化の方向ですが、実用化には時間がかかるそうです。

この規格の見通しが立つまでは、無線機能搭載MCUの選定が、しづらいです。結果、CypressのPSoCアナログ特化製品のような、無線規格変更に柔軟に対応できるコプロセサ化も必要かもしれません。

※本時期内容は、MCUとMPU/SCB間無線規格ページへ追記しました。

広範囲IoT向け無線規格「LPWA」

IoT向け無線規格「LPWA」の全貌の記事2つを紹介します。LPWAとは、Low Power Wide Areaの略で、マイコン:MCUとIoT向けコンピュータ:MPU/SBC間通信ではメジャーなBluetoothなどの近距離無線に対して、より広い範囲のIoT向けの通信規格のことです。

1つ目が、IoT向け通信に価格破壊をもたらす「LPWA」、2つ目が、いよいよ日本上陸、LPWAの最有力候補「LoRaWAN」の実力は?です。通信コストとオープン仕様というキーワードが登場します。

低電力な長距離通信技術:LPWA

BluetoothとLPWAとの違いを示すのが、1つ目記事より抜粋した下図です。3GやLTE技術で問題となる通信コストや初期投資を抑える新技術がLPWAで、低速かつ一回の通信量も数10バイト程度に抑えて、バッテリー消費量を数年または10年以上も可能とするのを目標としています。

Bluetooth(BLE)とLPWAの違い
Bluetooth(BLE)とLPWAの違い(記事より抜粋)

低通信コスト

主なLPWA技術が下表です。SIGFOXは、フランスやスペインなどで、1回線あたり年間1ドルで既にサービス開始済みで、800万回線契約があるそうです。LoRaWANは、韓国SKテレコムが日本円換算月額32円で提供中です。

主なLPWA技術
主なLPWA技術(記事より抜粋)

オープン仕様

これらLPWAは、キャリアの提供サービスです。日本では、LoRaWANが最有力候補だそうです。その理由は、Wi-Fiのように誰もがその技術を利用しサービスを提供できるオープンな仕様と、免許不要帯の利用にあります。

日本国内LoRaWANフィールドテストの結果、 6㎞程度の最大伝送距離と、20~30km/h以下の低速移動体通信が確認できたようです。

オープンイノベーション

デファクトスタンダードやオープン仕様は、マイコン:MCU開発にとっても無視できません。マイコンで産み出す機能実現とその維持のために、低コストや代替デバイスの検討も無視できないからです。

マイコン開発者自身の意識も、このオープン仕様の流れに沿う必要があるのかもしれません。オープンイノベーション白書が無料でダウンロードできますので、意識改革の手始めに目を通すのも良いと思います。

ソフトバンク、ARM買収を発表

ソフトバンクは、IoT戦略の加速を目的に、英ARM株式100%取得し買収することを発表しました。

9月30日までに買収完了予定です。IoTデバイス開発の関係者にとってはサプライズニュースです。

テクノロジーのパラダイムシフト

ソフトバンク発表資料(免責事項にふれる可能性があるため非掲載)によると、現在のモバイルインターネットの次のパラダイムシフトはIoTです。また、ARMベースSoC:System on Chipの出荷台数は、148億個(2015年)で、未だに発展段階の成長を続けていることが解ります。

ARM Cortex-M0/M0+を用いる本ブログ対象の組込用途マイコン:MCUや、IoTコンピュータ:MPU/SBCなどの2020年市場予測も掲載されています。今後Cortex-M0/M0+の採用を検討されている開発者の方々にも有用な情報です。

SoftBank+ARM

組込の世界では、実質ルネサスのみであった日本プレーヤーに、株主とはいえソフトバンクが参加することは、日本人として少し嬉しい気がします。
しかし、孫社長の後継者問題、英国EU離脱のARM陣営への財務基盤強化などが、今後IoT、特にMCU分野にどう影響するかは、要注意でしょう。

SoftBank携帯で、IoT MCUソフトウエア開発を行う状況が来るかもしれません。

IoT無線規格「Z-Wave」

欧米のホームセキュリティと室内温度コントロール、ホテルなどで実績があり普及が進むIoT無線規格が「Z-Wave」です。Z-Waveの国内動向記事によると、2015年のZ-Wave認証製品の累計出荷台数は6000万デバイス超、2016年には1億デバイス出荷が確実だそうです。

日本では未知な部分が多いIoTを、実サービスへ適用した例と、その出荷台数がインパクトある内容ですので、記事要旨を示します。

BLEの課題とZ-Waveの対策

  1. Wi-Fi環境下での干渉
  2. 石造りの家庭が多い欧州では、減衰が多い
  3. 通信距離が最大7~10m程度と短い
  4. 端末の増設に弱い

スマホ等で普及しているIoT無線通信の1つBLE:Bluetooth Low Energyの上記4課題に対して、Z-Waveは、これら課題を解決する下記特徴を備えているそうです。

  1. Wi-Fiとの干渉に強い
  2. 150m四方の通信距離
  3. 最大232個の端末増設が容易
  4. 低消費電力でバッテリー駆動の完全互換センサに数多く採用中

記事より抜粋したZ-Waveと他のIoT無線規格の比較を示します。

Z-Waveと他IoT無線規格の比較
Z-Waveと他IoT無線規格の比較(記事より抜粋)

日本国内でZ-Wave普及が遅れる理由

利用できる周波数解禁が海外比10年以上遅れていること、スマホによる家電や照明操作が電気用品安全法により規制されていること、火災警報器の厳しい基準などが原因だそうです。

また、欧米スマートホームのスタイルをそのまま導入できない日本の治安の良さも一因だそうです。

メッシュ網

技術解説記事によると、端末識別のためにMACヘッダにユニークなIDを付与することで232個までノードに対してメッシュ網を構成するそうです。

Z-Wave Singlecast
Z-Wave Singlecast(記事より抜粋)
Z-Wave Multicast
Z-Wave Multicast(記事より抜粋)

Z-Waveデバイスと評価キット

Z-Waveを制御するデバイス開発元の米Sigma-Design製評価キットは、欧州、米国、日本向けに用意されています。

日本でも医療/介護の分野で普及する可能性があるので要注意のIoT無線規格だと思います。MCUとMPU/SCB間の無線規格一覧ページへZ-Waveを追加し、今後も注視します。

IoTマイコン無線規格

6月の本ブログは、ThreadやBluetooth 5など、マイコン:MCUとIoTコンピュータ:MPU/SCB間の無線通信規格に関する記載が多くなりました。モノをインターネットへ接続するIoTの要となる無線インタフェースが、今変動中であることが解ります。

私は、コスト重視のMCUは、最終的にはどれか1つの規格(Threadが良いと思います)になり、カバー範囲重視のMPU/SBCは、複数規格(Wi-Fiは必須で、BluetoothやThread…)を実装すると思います。

このMCUとMPU/SCB間の無線規格の現状を考えた面白い記事を見つけたので紹介します。

IPアドレスとの親和性

記事によると、無線規格の要件として、よく言われる低消費電力動作の必要性以外にも、既に出来上がったWi-Fi世界との親和性が重要だとしています。IEEEでもこの線に沿った「Wi-Fi Halow」と「Passive Wi-Fi」規格検討が進んでいるそうです。

かつて私も有線通信:ATMの研究開発にたずさわったので多少解りますが、IEEE(アイトリプルイー)の規格化が済むと、直ぐに商用製品が発売され、Businessに裏打ちされた規格が開発される場、それがIEEEです。そして、MCUとMPU/SCB間の無線技術を含む多くの通信課題が解決される場でもあります。

確かに、IPアドレスとの親和性が高いと、NIC: Network Interface Cardのハードやソフトが流用でき、これらを実装したMCUでのパケット化処理(UART over IP)も簡単になるかもしれません。

MCUとMPU/SCB間の無線技術

UART、つまりSCIを実装しないMCUはありません。
SCI入出力を簡単に無線化できるソフト/ハード技術、これがIoT MCU無線規格の本命になると思います。今日時点の内容は以下ですが、この技術の一覧表を固定ページに追加しました。固定ページは、適宜、内容を更新します。

IoT MCU Wireless Specifications
無線規格 特徴 備考
Bluetooth 4.2 128ビットAES対応など従来比セキュア機能拡張 スマホへ普及中
Bluetooth 5 4.2比通信速度、通信距離、ブロードキャスト容量拡大 2017年初めリリース予定
Thread メッシュ網構成
Wi-Fi Halow Wi-Fiとの親和性高く、室内外40m、屋外1㎞通信 IEEE 802.11ah
Passive Wi-Fi IEEE 802.bベース、超低消費電力(電池駆動10年)目標

 

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機器への搭載を目標にしているそうです。

Atom新規開発中止とPSoCアナログ特化製品追加

IntelがAtomプロセサの新規開発を中止すると発表しました。
Cypressは、アナログ制御に特化したPSoC 4ベース新製品投入を発表しました。
所感を記載します。

Atom新規開発中止

Surface 3やEdisonなどの既存Atomを使った製品の今後も怪しくなってきますね。Galileoは Pentiumを使ったSoC: System on Chipなのでとりあえず安心ですが…。

少品種大量生産が 半導体メーカーのビジネスモデルなので、マッチしない製品群は、開発停止というユーザにとっては避けてほしいオプションが常に付きまといます。

マイコン開発者にとって、「代替品が可能なデバイス」に魅力を感じるのは、この最悪オプションのためです。

これはIntelの話でしたが、日本メーカー競争力と継続性強化のための方策についてコチラに興味深い記事があります。

PSoCアナログ特化新製品追加

一方Cypressは、Spansion買収で得たCortex-M0+ライセンスを使ったPSoC 4に、オペアンプやコンパレータ、アナログ・マルチプレクサなどのアナログに特化したプログラマブルアナログブロックを統合したPSoC Analog Coprocessor(Cy8C4Axx)新製品を追加しました。

コプロセサ化により、センサの変更を、ホストプロセサソフトへ及ぼさずに短時間でプロトタイピング開発できるメリットがあります。

PSoC Analog Coprocessor Merit
PSoC Analog Coprocessor Merit(記事より抜粋)

モーション、照度、湿度、近接センサ、サーミスタなど搭載の評価ボードCY8CKIT-048を使うと、アナログ・フロント・エンド(AFE)がPSoC Creatorで開発できるので、一般的に40時間かかる方法と比べ4時間で開発できるそうです。「1週間のスケジュールを、半日でできる!」、夢のようです。

無線通信規格の変更容易なコプロセサ化

評価ボードにはArduinoシールドコネクタも実装済みなので、Raspberry Pi 3などのIoTコンピュータ:MPU/SBCに直接搭載も可能でしょう。

また、対ホストプロセサ通信には、UARTが使えます。ここにUART over BLEやUART over Threadの適用が予想できます。

MCUとMPU/SBC間の無線通信規格が流動的な現状では、このアナログコプロセサ機能配分も適していると思います。CY8CKIT-042搭載のBLE 4.1がBLE 4.2に簡単に変更できたように、無線規格変更に対して柔軟に対応できるからです。

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エンドポイント通信の本命になるかもしれません。

Node-REDとGenuino 101

Node-RED

トラ技2016年6月号記載のNode-REDは、強力な開発ツールです。ターゲットは、本ブログのマイコンやシングルボードコンピュータなど全てを含むことができます。但し、あくまでNode-RED動作環境の下での動作が前提です。

つまり、WindowsやLinuxなどのリッチOSアプリの1つがNode-REDで、これを使えば、Raspberry Pi 3とArduino/Genuino 101両方で動作するプログラムが開発できます。マイコンの動作オブジェクトコードは(今のVersion0.13.4版では)出力されません。

今回は、このNode-REDがデバイスに依存せずにプログラミングできる仕組みとprintfデバッグについて考察します。

デバイス非依存性

マイコン開発で苦労する部分は、センサやモータなどの個別制御プログラムです。しかし、この制御プログラムが予めライブラリで提供されていて、しかも、制御する側のデバイス、マイコンかシングルボードコンピュータかもGUIで簡単に選択できれば、苦労はかなり減ります。

残りの部分は、どの順番でどのように個別制御プログラムを動かすかというフローチャートのイメージに近い部分です。このフローチャートに近い部分を、Node-REDでは「flow」と呼び、ブラウザを使ってGUIで開発します。

Node-REDのflow例
Node-REDのflow例

ChromeやFirefoxなどのお馴染みのブラウザが使えますので、Windows であってもiOSでも、Linux:Raspbianであっても開発できます。RaspbianをインストしたRaspberry Pi 3もデフォルトブラウザはEpiphanyですが問題なく動作します。

トラ技6月号のP65の図8:GPIOライブラリnode-red-contrib-gpioとJohnny-Fiveの位置づけが、「デバイス非依存性」を端的に示しています。

図8で示されたライブラリとNode-REDのFlowは、オンラインFlowライブラリで多くのサンプルが公開されており、6月4日時点で778個です。☑nodeがライブラリです。

トラ技では、P66のArduino系ボードの中にArduino/Genuino 101は入っていませんが、Firmateプロトコルスケッチをボードへ書き込めますので記事と同様に動作します。このFirmateもCPUやマイコンボードに依存しないプロトコルなので、対象ボードがFirmateさえサポートすればNode-REDから制御できます。

Arduirno/Genuino 101でFirmateプロトコルスケッチを利用
Arduirno/Genuino 101でFirmateプロトコルスケッチを利用

このように、制御に必要なflowサンプルやnodeライブラリを部品として全てネットからダウンロードでき、この部品の加筆修正も簡単にできるNode-REDは魅力があります。ソフト開発時にハード準備が間に合わないことは良くあることですが、実ハードがなくても代替ハードで動作確認し、最後にGUIでポート番号を変更しさえすれば実ハードでも動作することが可能だからです。

printfデバッグ

Arduino IDEも同様ですが、Node-REDには、本格的なデバッガ機能が(今のところ)ありません。

プログラマがprintf(Node-REDは、デバッグ出力ノードに相当)を使って変数などを一時出力してデバッグすることはできますが、動作を一時停止しRAM内容をダンプしたり、変数を変更後に停止位置から再実行したりすることは簡単にはできません。

printfデバッグは、ダウンロードした部品が完全でバグが無いブラックボックスとして扱える場合には効果的かもしれません。例えば、ハードウエア開発で、74シリーズロジックを組み合わせて開発する場合に、ロジックにバグがあると考える開発者はいません。自ら開発したハードをデバッグする際には、プローブとオシロスコープを使って、ロジック間の信号を読み解きバグ取りをします。このプローブがprintfに相当します。

少し前は、マイコンソフト開発でもprintfデバッグが盛んでした。デバッガは高価だったからです。しかし現在は、シリアルーUSB変換機能と兼用でデバッガ機能を持たせた低価格マイコンボードが多数あります(LPC、Kinetis、Cypressマイコンボードなど弊社利用の評価ボード)。

ソフトウエアもハードウエアのように部品化が進めば、printfデバッグで完成する時代がくるかもしれません。しかし、かなり先の話だと個人的には思います。
個別マイコンボードのデバッガ機能がプラグインで追加できる開発ツールを望んでいます。EclipseベースのIDEは、この要望に最も近いのかもしれません。

Arduino/Genuino 101用マイコンテンプレート

因みに、Arduino/Genuino 101のIDEは、今のところArduino IDEです。

Intelは、デバッグ機能付きのEclipseベースIDE、Intel® System Studio for MicrocontrollersのQuark™ SE版をアナウンスしていますが、未だにリリースされていません。私は2016年版Eclipse:Neonをベースに使うと思いますので、今少し時間がかかるかもしれません。

従って、Arduino/Genuino 101用のマイコンテンプレートの発売ももう少し後になります。昔ながらのprintfデバッグには、戻りたくないというのも本音です。ご容赦ください。