タグ: Bluetooth Low Energy

IoT MCUの無線LAN

WithHappy

IoTに適した無線LANの条件とは？（TechTarget、2020年11月27日）記事を紹介し、IoT MCU関連のプライベート網無線LAN規格を説明します。

IoT向き無線LAN条件と規格

纏まった良い記事なので、一読をお勧めします。

記事を要約すると、IoT向きの無線LANの選定には、3つの検討ポイントがあります。

  1. 省電力性：バッテリーだけで長時間無線LAN通信ができる
  2. 長距離伝送性：アクセスポイント（AP）から1km以上離れる場合がある
  3. 国より異なる利用周波数の空き状態確認

各ポイントを満たす無線LAN規格として下記3つを挙げ特徴を説明しています。

  • IEEE 802.11ah（別名Wi-Fi HaLow）：Target Wake Time（TWT）により通信タイミングを調整しAP通信競合を防ぐと同時にスケジュールタイムまでスリープし電力消費を抑える
  • IEEE 802.11ba：TWTに加えWake-Up Radio省電力機能を利用しAPからの通信要求に対応
  • IEEE 802.11af： 54MHz～698MHz利用で900MHz～1GHzの802.11ah/802.11baより長距離伝送可能
    ※11afは、テレビ用ホワイトスペースのVHF/UHFバンド（54 MHz～790 MHz）利用なので空き状態により耐ノイズ注意

IoT向き無線LANとBluetooth

無線LANには、2.4GHz利用、数m～10m程度の「近距離無線通信規格」：IEEE 802.15.1（別名Bluetooth）もあります。コイン電池で1年以上動作できるなど超省電力動作ですが、低速です。PCやスマートフォンでは、マウス/キーボード/ヘッドホンなどの周辺機器との接続に使われます。

より高速、より長距離（400m程度）、より高スループットを目指し、Bluetooth v4.2、Bluetooth 5などと規格が変化しています。

IoT MCUへの実装は、Bluetooth 5内蔵MCUやBluetooth 5モジュールとMCUを接続する方法があります。

IoT 向き無線LANとPC/スマホ向き無線LAN

2020年12月時点のPC/スマートフォン無線LAN規格が下表です（出展：NTT西日本公式ホームページ）。

規格 周波数帯 最大通信速度
IEEE 802.11b 2.4GHz 11Mbps
IEEE 802.11g 2.4GHz 54Mbps
­­­­IEEE 802.11a 5GHz 54Mbps
IEEE 802.11n 2.4GHz 600Mbps
5GHz
IEEE 802.11ac 5GHz 6.9Gbps
IEEE 802.11ad（WiGig） 60GHz 6.8Gbps
IEEE 802.11ax 2.4GHz 9.6Gbps
5GHz

IoT向き無線LANと異なるのは、周波数帯がより高周波の2.4GHz/5GHzを利用する点と、新規格11ac/11ad/11ax、従来規格11b/11g/11a/11n、ともにデータ伝送速度が速い点です。スマホのAPは、家庭や店舗に設置された無線LANルータで、高周波利用のため伝送距離は精々100m程度、60GHzの11adでは10m程度です。公衆網5G高速化に伴い新無線LAN規格：11ac/11ad/11axが普及しつつあります。

動画再生などの利用形態も多いPC/スマホ向き無線LANは、「高速大容量化」が求められます。IoTの「長距離省電力」要求とは、異なる無線LAN規格となっています。

まとめ：IoT MCUプライベート網の無線LAN規格

無線LANアクセスポイントからの伝送距離変化
無線LANアクセスポイントからの伝送距離変化

プライベート網無線LAN規格は、APからの伝送距離により、

  1. 「近距離（10m以下）超省電力」規格（周辺機器向き）：Bluetooth（IEEE 802.15.1）
  2. 「短距離（100m程度）高速大容量」規格（PC/スマホ向き）：IEEE 802.11a/11b/11g/11n/11ac/WiGig（11ad）/11ax
  3. 「長距離（1km以上）省電力」規格（IoT向き）：Wi-Fi HaLow （IEEE 802.11ah）/11.af/11.ba

の3種類があります。

IoT MCUには、最新のBluetooth 5や屋外や1km半径の広い敷地内でも使える長距離省電力規格のWi-Fi HaLowが望まれるようです。

但し、普及済みのPC/スマホ向き無線LAN規格が使えると、屋内の既存PC/スマホ無線LANルータをインターネット空間へのAPに利用でき、常時電力供給も可能なため、低コストIoT MCUを実現する方法になりうると思います。


評価ボードから読む最新マイコン技術動向

WithHappy

最新マイコンの評価ボードから、IoT向けMCU技術動向を考察します。参考にしたのは2017年後半開発の下記2種評価ボードです。

つい最近、2ボードはWebinarで解説されており充実内容でした。興味がある方は、上記リンクから探せばOn Demandでも見られると思います。英語ですが非常に参考になります。

CY8CKIT-062-BLE
CY8CKIT-062-BLE

私は、「ベンダ製評価ボードは、ハード/ソフト両方の早期開発レファレンスとすべきだ」と何度か説明してきました。この認識に基づき最新評価ボードから今後のIoT MCU技術動向を抽出したのが下記です。

リッチ表示、タッチパッド、大容量ストレージ、IoT無線通信、FreeRTOS

IoTマイコンには、以下5項目が現状MCU技術に加わると思います。

IoT MCU技術動向（2017年11月）
追加技術 概要
リッチ表示出力 2×16文字程度のLCD表示から、128×160ドットカラーTFTディスプレイなどよりリッチ表示が可能な出力。
タッチパッド入力 従来タクトスイッチから、タッチパッドなどのより柔軟なユーザインタフェース入力。
大容量ストレージ 小容量EEPROM or RAMから、ロギングデータ等の保存も可能なSDカードなどの大容量ストレージ。
IoT無線通信 UART/SCIから、IoTプロトコルに応じた間欠動作で低電力志向の無線通信。
FreeRTOS ベアメタル開発から、複雑なリアルタイム処理実現のためのRTOS開発。

※IoT通信は様々なプロトコルが乱立状態ですが、BLE/Thread両方サポートに集約されそうな気配です。
※RTOSもCMSIS_RTOS/mbed OS 5/FreeRTOSと様々ですが、FreeRTOS利用例が多いです。

5項目全てが追加される訳ではなく、現状MCUにIoT通信処理のみを追加したコスト重視IoT MCUと、全て追加した高機能IoT MCUの2タイプに分かれそうです。

2タイプのIoTエンド端末

IoT MCUで開発するデバイスを、ここではIoTエンド端末と呼びます。端末の方がイメージし易いからです。コスト重視IoT MCUは、低価格IoTエンド端末へ、高機能IoT MCUは、IoTの申し子となる高機能IoTエンド端末へ搭載されます。

IoT端末の多くはこの低価格タイプになると思います。

ADCなど従来MCUのアナログ入力にセンサを接続し、IoT通信でクラウドへセンサデータを定期的に送信します。低電力処理重視のためリッチ表示などは不要で、数年～10年程度はバッテリー動作可能です。

IoT通信機能は現状未実装ですが、ルネサスエレクトロニクスのOktoberfestコースターなどが実例です。通信機能搭載で、店員のスマホから飲み物の有無や温度が解るなどの使い方が想定できます。

Oktoberfestコースター
Oktoberfestコースター

つまり、IoTクラウドの5感センシング（視覚、聴覚、触覚、味覚、嗅覚）が主機能で、クラウド処理結果やユーザへのアクション指示は、スマホなどの別端末が行うのがこのタイプです。

＊　　＊　　＊

高機能IoTエンド端末は、低価格端末機能に加え、リッチ表示ディスプレイでユーザに端末やクラウド解析結果なども表示可能で、ユーザが状況に応じて判断するためのタッチパッド入力なども備わっています。

端末データをローカルなSDカードなどのストレージへ蓄積し、一括してクラウド送信することや、ディスプレイ表示を状況に応じて変更するための画像データをローカル保存することもなどもできます。

IoT普及時の高機能端末がこれで、言わば簡易スマホ機能も備えた端末と言えます。最新評価ボードは、このタイプの開発レファレンスに使えるように設計されています。

実時間で複雑な並列動作が要求されるので、RTOS（FreeRTOS）が用いられます。

NXPのSwiss Army Knife Multi toolなどが実例です。

Swiss Army Knife Multi tool Block Diagram
Swiss Army Knife Multi tool Block Diagram

まとめ

最新MCU評価ボードから、現状MCUへの技術追加（強化）5項目を抽出しました。追加項目により低価格IoT MCUと高機能IoT MCUの2つに分け、IoTエンド端末イメージを示しました。

現状MCUにIoT無線通信を追加した低価格IoTエンド端末は、IoTセンサとして機能し通信プロトコルが確定すれば、現状技術でも実現性は高そうです。

簡易スマホ機能も備えた高機能IoTエンド端末は、新技術（IoT無線通信、FreeRTOS）や、従来MCUであまり使われなかったリッチ表示出力、パッチパッド入力、大容量ストレージ技術が強化されそうです。

リッチ表示出力や大容量ストレージには、高速大容量向きのSerial Peripheral Interface：SPIバス接続が有力です。センサ接続には、従来同様低速なInter Integrated Circuit：I2Cバスを使い続けるでしょう。

タッチパッド入力は、ベンダ提供の独自ライブラリを利用する形態になります。ベンダ毎にセンス能力やウエット耐性などに性能差が生じる可能性があります。

IoT通信処理とRTOSは、様々な仕様が混在中ですが、BLEとThread両用、FreeRTOSに収束しそうな気配があります。

ESP-WROOM-32と評価ボードESP32-DevKitC

WithHappy

トランジスタ技術2017年11月号特集のWi-FiとBLE4.2両方搭載のIoTマイコン：ESP-WROOM-32（秋月電子550円）とその評価ボード：ESP32-DevKitC（秋月電子1480円）の記事をまとめます。

ESP32-DevKitC and ESPWROOM-32
ESP32-DevKitC and ESPWROOM-32

無線通信Wi-FiとBluetooth 4.2搭載で単価550円のマイコン

Wi-Fiは、802.11b/g/nの2.4GHzのみ、通信中の消費電流実測値は、起動時800mA、定常時200mAなのでマイコン電源にある程度の余裕が必要です。評価ボードは、1A出力のNCP1117（ONセミコンダクタ）を使っていますが、50％デューティで考えると、もう少し余裕が必要かもしれません。Bluetoothは、BLE4.2です。アンテナも内蔵です。

Tensilica製80MHz～240MHz動作32ビットディアル（！）コア、ROM: 448KB、RAM: 520KB、NXP）LPC8xxシリーズのスイッチマトリクス相当のGPIO_matrixを実装しており、デジタル周辺回路入出力を34本あるGPIOへ割り付け可能です。AD/DAなどのアナログ周辺回路は、ピン固定です。

製造は中国Espressif Systems社、従業員数約120人のファブレスメーカで、2016年米ガードナーが「IoT産業における最もクールな企業」に選出しました。Cortex-M系コアでありませんが、確かに機能/価格：コスパは凄いです。マイコン単体、評価ボードどちらも秋月電子からの入手性が良いので、人気が出るかもしれません。

プログラミングはArduino IDEとCLIのESP-IDFの2種

評価ボードESP32-DevKitCのプログラミングは、Arduino IDEのスケッチベースと、コマンド ライン インターフェース：CLIを使うEspressif Systems社提供ESP-IDF（IoT Development Framework）の2通りがあります。イーサネット、BLE4.2やI2Sを使う場合は、ESP-IDFでの開発が必要です。

評価ボードは、前述の1A電源とUSBシリアル変換デバイスのみ実装ですので、LEDやSWなどをブレッドボードなどで追加し、開発プログラムの動作確認をします。記事4章では、I2C接続で2種類の加速度センサー、1000円台で購入できるMMA8451Q（NXP）、または、20ビット高分解能のADXL355（アナデバ）を使い、簡易IoT地震計を開発しています。I2C経由の加速度データ取得方法は、他のマイコン制御時にも参考になります。

ディアルコア超高性能マイコンですので、評価ボードに1.8インチのSPIカラー液晶モジュール：M-Z18SPI-2PB（aitendo、950円）を接続し、動画を再生しているのが5章です。7章は、AD/DAを使って、今はやりのスマートスピーカーを開発しています。

11月号は、10ドルコンピュータのラズベリーパイZero Wを使った記事も記載されていますが、本ブログはマイコンが対象ですので割愛します。

マイコン開発のポイントは、ライブラリ活用/流用

コマンドラインインターフェース：CLIを使ったソフト開発は、慣れが必要です。しかし、これは慣れの問題です。例えArduino IDEでも、初めての人には戸惑う部分もあるでしょう。Arduino IDEが隠して（見えなくして）いる部分が他に比べて多いので、比較的簡単に慣れるようになるだけの話です。

慣れた後はどちらの開発環境も、豊富なライブラリや、サンプル・プログラム、サンプルソフトを使ってソフト開発をします。個人が１からソフトを全部開発するのではなく、既にあるソフト資産を活用/流用する、これが全てのマイコン共通の現代的なマイコンソフト開発方法です。

これはソフトウエアに限ったことではありません。ハードウエア開発でも、評価ボードやArduinoソケットは、1種のライブラリとも言えます。ソフト、ハードともに使える資産は活用し、これで得た（得をした）開発時間は、独自性を活かす部分に使います。

ライブラリ活用/流用には、ライブラリを使う側の骨格：スケルトンを理解していることが前提条件です。記事P48のArduinoスケッチの書き方で言えば、図Aのsetup（）やloop（）関数のようにマクロ的にソフト構造を捉えた後に、ミクロな問題へと詳細化することです。

骨格：スケルトンを理解していれば、後は必要な機能をライブラリの中から選び、必要に応じてライブラリを修正し、骨格に付け加えれば、動くモノが完成します（完成度で言えば65～79％：良判定）。

マイコン開発はこの動くものから、完成・出荷段階（完成度80％以上：優判定）にするのに結構な手間と時間が掛かります。

従って、ライブラリを上手く使ってなるべく早い段階で良段階へ到達し、ここからは腰を落ち着けて80％以上の完成度になるように開発時間の配分をしましょう。
また、骨格理解や習得にも十分な時間を割きましょう。

弊社マイコンテンプレートは、様々なサンプルソフトを流用/活用した早期ソフト完成、いわゆるプロトタイピング開発に役立ちます。是非ご活用ください。

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

WithHappy

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出力を行い、オペレータまたはロボットが対象機器メンテナンス作業の手助けをする。

PSoC 6続報

WithHappy

MONOist組み込み開発ニュースに、PSoC 6と他社製品との性能、消費電力の比較が掲載されています（出典：「業界最小」の消費電力でセキュリティも、サイプレスがIoT向け「PSoC」を投入）。

PSoC 6の目標

「ある程度のシステム制御ができる性能＋低消費電力＋セキュリティ、これらの同時実現」というPSoC 6の目標のために採用された40nmプロセス技術とデュアルARMコアにより、PSoC 6の他社比、優れた性能が解ります。

PSoC 6 Comparison Table1
PSoC 6 Comparison Table1（記事より）
PSoC 6 Comparison Table 2
PSoC 6 Comparison Table 2（記事より）

青字が性能同等、または、より優れた項目を示しています。PSoC 4でも採用中の高性能CapSenseやアナログコンポーネント、多くのGPIO数、そして100MHz動作のCortex-M0+、ピーク時257DMIPSなど、弊社ブログ対象の従来MCUの性能枠を大きく超えるものです。

１MB ROM、288KB RAM、８KB キャッシュの意味

ディアルコアで、１MB ROM、288KB RAM、8KB キャッシュものリソースを持つPSoC 6制御には、RTOSが必要になると思います。MCU開発も、よいよOS必須時代になるのでしょうか？

PSoC Creator News and InformationにNew FreeRTOS on PSoC 4 port が掲載されています（PSoC Creator 4.0のStart Pageからもアクセス可能）。弊社マイコンテンプレートで使ったCY8CKIT-042 評価ボードへも適用できそうです。ARMコアなので、mbed OS 5も気にはなりますが、FreeRTOSですので、RTOSへの備え記事が、理解に有効に活用できるでしょう。

弊社自作FreeRTOSサンプルソフト状況

RTOSへの備え記事は、LPCXpresso 824-MAXを使ってFreeRTOSサンプルソフトを自作しています（Lチカ、Q-通信、セマフォ同期、ミューティックス排他制御の4種）。

この自作サンプルを横展開してLPCXpresso 812/812-MAX、LPCXpresso 1114/5へ適用する予定でした。しかし、LPCXpresso 824-MAXで動作するサンプル（勿論GPIOとLPCOpenライブラリのみ変更）が、Lチカを除いて他の評価ボードでは動作確認ができないのが現状です。

原因が（僅か数十行の）自作サンプルにあるのか、それとも、それ以外かの見極めも、結構大変です。FreeRTOSもv9では、スタティックなセマフォ、ミューティックス割付ができるなど改良が進んでいるのでデバッグには良さそうですが、現状のv8は未だ非対応です。

LPCXpresso 824-MAX版だけでもFreeRTOSサンプルソフトを無償リリースするか、それとも、当初の予定どおり全評価ボード対応として問題解決後リリースするか3月末を目途に検討中です。

Bluetooth 5.0対応のIoT向けマイコンPSoC 6発表

WithHappy

3月14日のEE Times Japanに“Cypress、低消費でより強固なセキュリティ実現”という記事が掲載されました。この記事から、2017/4Q（10月～12月）量産予定のCypressの新しいIoT MCU、PSoC 6の特徴をまとめました。

PSoC 6の特徴

  • Cortex-M4＋Cortex-M0+ のデュアルARMコア
  • プロセス技術にウルトラローパワー40nm SONOS採用（従来は130nm）した結果、Cortex-M0+：15uA/MHz、Cortex-M4：22uA/MHz、ローパワーモード動作電圧：1.1V、ウルトラローパワーモード動作電圧：0.9Vを実現。消費電流は、下表参照。
PSoC 6 Current consumption
PSoC 6 Current consumption（記事より）
  • ハードウエアでのセキュア データストレージ機能を備えたTEE : Trust Execution Environment実装
  • 暗号化アルゴリズム：楕円曲線暗号（ECC）、AES（Advanced Encryption Standard）、ハッシュ（SHA-1/2/3）ハードウエア実装
  • Bluetooth Low Energy 5.0対応
  • 評価ボード：PRoC 6 BLE Pioneer Kit（CY8CKIT-062-BLE）は75米ドル。
    ※弊社マイコンテンプレート使用中のPRoC 4 BLE Pioneer Kit (CY8CKIT-042-BLE）は49米ドルです、ディアルコアを考慮するとお買い得？

ハードによるセキュリティ機能はIoT MCUに必須

IoTマイコンにARMコアを使う場合、新しいCortex-M23/33コアによるアプローチと、従来コアにTEEなどのセキュリティ機能を付加したアプローチの2つがありそうです。CypressのPSoC 6は、後者です。

いずれも、ハッキングやウイルス対策に、ハードによるセキュリティ対策は必須です。私個人の感触では、どの程度の処理を MCUで行うかにもよりますが、たとえ専用セキュリティハードを追加したとしても、Cortex-M0/M0+/M23クラスの処理能力では、IoT通信制御だけでも重すぎるのではないかと思います。

そこで、より能力の高いCortex-M33やCortex-M3、M4を使うか、M0クラスとのディアルコア化も解として有力かもしれません（コア性能差は、コチラを参照、Cortex-Mxの特徴はコチラを参照）。

PSoC 6はBluetooth 5.0とデュアルコアでしたが、IoT通信規格の決定だけでなく、MCUアーキテクチャ、これら両方の観察がIoT MCU選択に必要になりそうです。

似通るBluetoothと無線LAN

WithHappy

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間無線規格ページへ追記しました。

mbed OS 5リリース

WithHappy

2016年8月5日、ARM mbed OS 5がリリースされました。mbed OS 5対応評価ボードは、現在39種類あります。本プロブ対象のARM Cortex-M0/M0+クラス評価ボードは、このうち6種ありました。

上記ページのHardwareタグでBoardsを選択し、Filterでmbed OS 5をチェックすると対応ボードが一覧表示されます。

Cortex-M0/M0+クラスのRTOS必要性

コスト重視のARM Cortex-M0/M0+マイコン：MCUに、リアルタイムOS：RTOSが必要か否かは、意見が分かれるところです。RTOSを使うためのROM/RAMのオーバーヘッドと、無線通信ドライバ/ライブラリの必要性がポイントだと思います。

FreeRTOSの場合は、ライブラリを除くと約5KB ROMが必要であることを以前示しました。mbed 5 OSは、BLEなどの各種無線通信をサポートしますが、コア部分は、（おそらく）同程度だと思います。
※MCUとMPU/SBC間の無線通信規格はコチラにまとめています。

IoT向けMCU実現には、無線通信機能は必須です。ここを１からMCUに実装するのは結構大変です。RTOSライブラリで提供されれば、Cortex-M0/M0+クラスMCUへの適用も現実的になるかもしれません。

一方、CypressのPSoC 4 BLEやPRoCは、RTOSを使わずにBLE通信を実現済みです。

Cortex-M0/M0+クラスへのRTOS適用は、まだ不透明だと思います。しかし仮にRTOSが誰にでも安心して使えるようになると、残念ながら弊社販売中のマイコンテンプレートは不要になるかもしれません。

マイコンテンプレート対抗馬は、本記事のmbed OS 5、FreeRTOSです。

IoT無線規格「Z-Wave」

WithHappy

欧米のホームセキュリティと室内温度コントロール、ホテルなどで実績があり普及が進む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マイコン無線規格

WithHappy

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年）目標