目次


次の IoT プロジェクトに最適なハードウェアを選択する

このハードウェア・ガイドを参考に、IoT プロジェクトをプロトタイピングおよび開発する際に使用するハードウェアを判断してください

Comments

IoT の中心となるのは、インターネットに接続されたハードウェア・デバイスです。これらの IoT デバイスがモニターしてインスツルメント化する「モノ」(つまり、実際のオブジェクト) には、産業機器、家庭用電化製品、ビル、自動車、倉庫の在庫品、人 (ウェアラブル・デバイスの場合) などがあります。

新しい IoT ソリューションを開発する際は、ハードウェアおよびソフトウェアのコンポーネントを設計してプロトタイピングし、フィードバックと評価のプロセスを繰り返して改良していくことになります。このプロトタイピングと改良のプロセスを活性化するのに役立つのが、Arduino や Raspberry Pi などの電子ホビースト向けハードウェア・プラットフォームです。なぜなら、これらのハードウェア・プラットフォームはすぐに利用できること、そして設計を繰り返すごとにプリント回路基板 (PCB) をカスタマイズして製造するよりも投資にかかる費用が少ないことにあります。このプロセスの一環として、開発する IoT アプリケーションのハードウェア要件を考慮し、それらの要件に照らし合わせて作成するプロトタイプ IoT デバイスを評価し、要件に適応するように IoT デバイスを改良していくことになりますが、その都度、必要に応じて市販のコンポーネントあるいはカスタム・コンポーネントのどちらかを採用することになります。

IoT のコンテキストでは、「デバイス」は多重定義された用語であり、特定の目的で設計または使用されるハードウェアを表します。この用語は、センサーやアクチュエーターなどの個々のハードウェア・コンポーネントを参照するために使用されるだけでなく、Raspberry Pi といった市販されている既製の基板を意味することもあれば、多数のデバイスから構成されるカスタム・プロトタイプおよび製造単位を意味することもあります。この記事では、広く利用されている市販のハードウェア・コンポーネントのいくつかを取り上げて考察し、今後の IoT プロジェクトをプロトタイピングして開発する際に、特定のデバイスを他に優先して選択すべき理由を説明します。

IoT デバイスの特性

IoT ランドスケープが成熟する中、新たなデバイスとデバイス・プラットフォームが次々とリリースされています。新しく利用可能になったデバイスを他のデバイスと比較して評価するためには、大半の IoT デバイスに共通する主要な特性を理解しておかなければなりません。

IoT デバイスの特性は、以下の大まかな機能を基準に決定することができます。

  • データの収集と制御
  • データの処理と保管
  • 接続性
  • 電源管理

データの収集と制御

データ収集 (DAQ) とは、物理的現象を測定して、それらの測定値を一定の時間間隔 (データ・サンプル・レート) でデジタル値に変換するプロセスのことです。DAQ には、未加工のセンサー測定値を操作およびスケーリングするための信号調節機能、そしてセンサーのアナログ測定値をデジタル値に変換して処理および分析可能にするためのアナログ・デジタル・コンバーターも必要になります。

センサーは入力コンポーネントであり、物理的変数を測定して、それを電気信号 (電圧) に変換します。センサーは、何千種類もの市販のセンサーの中から選択できます。これらのセンサーが測定する変数は、温度、湿度、圧力、煙、ガス、光、音、振動、気流、速度、加速度、近接、GPS 位置、高度、力など多岐に及びます。ただし、センサーが測定するのはこれらの周囲条件だけではありません。デバイスの内部の状態をモニターする固有受容センサーもあります。また、ボタン、スライダー、タッチスクリーンなどのセンサーは、デバイスと直接やり取りするためのヒューマン・マシン・インターフェースになります。さらに、温度センサーをはじめ、センサーのタイプごとにさまざまな製造元による幅広いコンポーネントの選択肢があります。これらのコンポーネントは正確度と精度に関する仕様がそれぞれ少しずつ異なり、特定のアプリケーションや動作条件に合わせて設計されています (水中での使用や、極度の暑さまたは寒さに耐えられる設計など)。

センサー・コンポーネントの重要な特性は、分解能です。センサーの分解能は、センサーが確実に読み取ることが可能な最小量の変化を表しており、未加工のセンサー測定値を表すための数値の大きさに関係します。例えば、アナログ温度センサーの分解能が 10 ビットだとすると、このセンサーは温度測定値を 0 ~ 1023 の数値で表すことになります。ビットはバイナリーなので、10 ビットは 2 の 10 乗、つまり合計で最大 1024 の値を表すというわけです。ただし、実際にはセンサーが電気ノイズの影響を受けるため、実分解能はこれよりも低くなります。

センサーは温度などの物理的変数を電気信号に変換しますが、出力デバイスはこれとは逆に電気信号を物理的な動きに変換します。出力デバイスには、LED、スピーカーとスクリーン、そしてモーターやソレノイドのように物理的な世界でモノを動かしたり制御したりするアクチュエーターなどがあります。アクチュエーターは一般に産業向け IoT アプリケーションの内部にデプロイされます。例えば、製造業では、アセンブリー・プロセスで製品を移動したり、つかんだりするのに空気圧式リニア・アクチュエーターが広く使用されています。

データの処理と保管

IoT デバイスが収集したデータの基本的な処理、変換、分析を行うためには、データの処理機能と保管機能を備えていなければなりません。IoT デバイスはデータを直接処理する場合もあれば、処理したデータを集約して分析するために他のデバイスやゲートウェイ・デバイス、またはクラウド・サービスやアプリに送信する場合もあります。

エッジ・アナリティクスでは、中央の 1 箇所でデータ分析を行うのではなく、ネットワークのエッジでデータ分析を行います。デバイスが上流にあるクラウド・サーバーやデータ・センターに大量のデータを送信して詳細な分析を行うのではなく、データをデバイス上で分析するか、あるいはIoT デバイスが直接接続されている近くのゲートウェイ・デバイス (ルーターなど) 上で分析することで、ほぼリアルタイムでのデータ分析が可能になります。エッジでデータを処理すれば、データの収集と並行してデータを集約し、フィルター処理によって顕著なデータだけを選択して上流に送信することが可能になります。突き詰めるところ、エッジ・アナリティクスによって、上流での処理およびストレージ要件が減ると同時に、ネットワーク上の負荷が軽減されるのです。

IoT アプリケーションで使用する処理能力とストレージは、データを取り込むサービスやアプリでどれだけの処理が行われるのかではなく、デバイス自体で発生する処理量に左右されます。デバイスで対応可能なデータの処理速度は、利用可能なメモリー容量、そしてクロック速度とコア数を含むプロセッサーの仕様によって決まります。また、デバイス上に保管できるデータの量は、上流に送信可能な状態になるまでデータを存続させるために使用する非揮発性フラッシュ・メモリーの容量によって決まります。エッジ・アナリティクスを実行するデバイスには、基本的なデータ処理しか実行しないデバイスよりも遥かに多くの処理機能が必要です。具体的には、妥当性検査、正規化、スケーリング、測定値の変換 (例えば、未加工の温度測定値を摂氏に変換) などの機能が必要になってきます。

接続性

ネットワーク接続性は、あらゆる IoT デバイスを決定付ける特性のうちの 1 つです。デバイスは他のデバイスとローカルで通信し、クラウド内のサービスやアプリにデータをパブリッシュします。デバイスの中にはワイヤレスで通信するものがあります。その場合には、802.11 (Wi-Fi)、Bluetooth、RFID、セルラー・ネットワークや、あるいは LoRa、SigFox、NB-IoT などの LPWAN (Low Power Wide Area Network) テクノロジーが使用されます。一方、スマート・ビルディング、ホーム・オートメーション、産業用制御アプリケーションにインストールされる固定式デバイスには、有線通信が適しています。これらのデバイスは、Ethernet を使用して接続するか、Ethernet over Power を使用して改良することができます。シリアル通信もデバイス間をつなげる有線接続の 1 つの形態です。シリアル通信では、UART (Universal Asynchronous Receiver Transmitter) のような標準プロトコルや、自動車産業を起源とする CAN (Controller Area Network) プロトコルを使用します。

電源管理

電源管理は、バッテリーやその他の非有線電源 (太陽光など) に依存する携帯 IoT デバイスおよびウェアラブル IoT デバイスにとって特に重大な懸案事項です。データの収集および制御機能、ストレージ機能、処理機能、ネットワーク接続機能を提供するため取り付けられるセンサー、アクチュエーター、または集積回路 (IC) の使用パターンと電力要件によっては、節電のため、あるいはバッテリー寿命を延ばすために、デバイスを定期的にスリープ・モードや低電力モードにする必要が生じることもあります。例えば、Raspberry Pi 3 のようなシングル・ボード・コンピューターを標準的な使用条件で動作させるには、約 700 ~ 1000mA の電流が必要です。Wi-Fi ネットワークを介して継続的にデータを送信したり、デバイス上で大量のデータを処理するためにデバイスが高負荷状態になったりすると、電力使用量はこの範囲の上限に達し、デバイスがアイドル状態になると低下することになります。カメラ・モジュールを接続するとしたら、カメラの使用中は常に所要電流が約 250mA 増加します。センサーには常時、動作するための電力が必要です。Raspberry Pi 上の GPIO ピンが供給する電力は 3.3V または 5V であり、すべてのピンを合わせると最大 50mA の電力を供給します。したがって、ピンに接続するコンポーネントの数を増やすと、デバイス全体の電力消費量も増えることになります。

IoT プロジェクトのプロトタイピングに使用できる市販のハードウェアのタイプ

IoT アプリケーションの開発がこれまで以上に身近なものになっています。それは、低価格で購入できる市販のハードウェア開発ボード、プラットフォーム、プロトタイピング・キットの種類が増えているおかげです。したがって、モジュール式のハードウェア設計にはかなりの柔軟性があり、例えば、代替コンポーネントと交換して、わずかに異なる仕様でセンサーを試してみたり、進化する要件に対処するために、デバイスのネットワーキング・モジュール、データ処理モジュール、ストレージ・モジュールを個別にアップグレードしたりすることができます。

マイクロコントローラーやシングル・ボード・コンピューターをはじめ、市販のハードウェア・デバイスの多くは、システム・オン・チップ (SoC) IC を中心に設計されています。SoC は、データ処理、ストレージ、ネットワーキングなどの数々の機能を単一のチップに集積することから、この構成は便宜のためにある程度の柔軟性を犠牲にすることを意味します。けれども幸いなことに、構成がさまざまに異なる、かなりの数のコモディティー・デバイスが出回っています。例として、表 1 では IoT プロジェクトのプロトタイピングに使用できる代表的なマイクロコントローラーの技術仕様を、表 2 では、よく使われている 3 つのシングル・ボード・コンピューター (SBC) の技術仕様を比較しています。

マイクロコントローラー開発ボード

マイクロコントローラーとは、データ処理機能とストレージ機能を提供する SoC のことです。マイクロコントローラーには 1 つ以上のプロセッサー・コア、メモリー (RAM)、そしてマイクロコントローラー上で動作するカスタム・プログラムを保管するための消去可能プログラマブル読み取り専用メモリー (EPROM) が搭載されています。マイクロコントローラー開発ボードとは、マイクロコントローラーをプロトタイピングに使用する際にチップをプログラミングできるよう、回路が追加された PCB のことです。

センサーとアクチュエーターは、デジタルまたはアナログ式汎用入出力 (GPIO) ピンまたはハードウェア・バスを介してマイクロコントローラーに接続します。ハードウェア・バスを介して接続されたコンポーネントとのデバイス内通信には、I2CSPI のような標準通信プロトコルが使用されます。標準を採用することによって、バスを使用して接続するコンポーネントを容易に追加、交換できるようになります。

Arduino (http://arduino.cc/en/Main/) はオープンソースのデバイス・プラットフォームであり、活発なコミュニティーによって互換性のある開発ボードとツールの作成が進められています。デバイスの機能は公式 Arduino モデル (https://www.arduino.cc/en/Products/Compare) の間でも、サード・パーティー製の Arduino 対応ボードの間でもさまざまに異なります。表 1 には、Arduino 対応のマイクロコントローラーとして、広く普及している Arduino Uno、セルラー・モデムが統合された Particle の Electron、Wi-Fi が統合された低価格の低消費電力マイクロコントローラーである Espressif Systems の ESP8266-01 (https://espressif.com/en/products/hardware/esp8266ex/overview) の技術仕様を記載しています。

図 1. Arduino マイクロコントローラー開発ボード

Arduino と同様に、ESP8266 にも活発な利用者のコミュニティーがあります。ESP8266 をベースに作成されている開発ボードとして有名なものとしては、NodeMCU (http://nodemcu.com/index_en.html)、WeMos D1 (https://www.wemos.cc/)、および AdaFruit no Feather Huzzah (https://learn.adafruit.com/adafruit-feather-huzzah-esp8266/overview) が挙げられます。オープンソースおよびメーカーのコミュニティーは OTA (Over The Air) アップデートをサポートすることを目的に、ESP8266 ベースのボード用にすでに数多くの代替ファームウェアを開発していて、IoT 開発者は Lua、Python、JavaScript を使ってこれらのボード用のプログラムを作成できるようになっています。

表 1. Uno、Electron、および ESP82566-01 マイクロコントローラーの技術仕様
特性特長Arduino UnoParticle ElectronEspressif Systems の ESP8266-01
データの収集と制御
GPIO ピンアナログ入力 6 本
デジタル入出力 14 本 (うち、PWM 6 本)
アナログ入力 12 本
アナログ出力 2 本
デジタル入出力 30 本 (うち、PWM 15 本)
デジタル入出力 2 本
アナログ入出力 1 本
ロジック・レベル電圧5V3.3V3.3V
データの処理と保管
プロセッサーATMega328PU32 ビット STM32F20532 ビット Tensilica L106
プロセッサー速度16 KHz120 MHz80 MHz
メモリー32 kB のフラッシュ・メモリー
1 kB の EEPROM
1 Mb のフラッシュ・メモリー
128 kB の RAM
1 Mb
接続性
ネットワーク・インターフェースデフォルトでは、なし。シールドを使用して追加可能。統合セルラー・モデム (2G / 3G)統合 W-Fi
電源
推奨電源9 ~ 12V DC 0.5 ~ 2A (バレル)、5V 500mA (USB)、または 9 ~ 12 V (VIN ピン)5V (マイクロ USB) または 3.9V ~ 12VDC (VIN ピン)3.3V 300mA 調整電源 (VCC ピン)
その他
寸法2.7 x 2.1 (インチ)2.0 x 0.8 (インチ)1.4 x 1 (インチ)
標準価格$25$39 ~ $59$10

Arduino 対応マイクロコントローラー上で実行するソフトウェアを開発する際には、通常の手法として、C または C++ と Arduino IDE が使用されていますが、コミュニティーが開発した言語バインディングとビジュアル・プログラミング・ツールもあります。共通のピン配置を共有する Arduino 対応ボートは、例えば Ethernet ポートまたは Bluetooth を Arduino Uno に追加するために、必要に応じてサード・パーティー・シールドを使用して拡張することができます。Arduino は最も広く採用されている電子ホビースト向けマイクロコントローラー開発環境ですが、Tessel (https://tessel.io/) や Particle.io (http://particle.io) など、JavaScript をネイティブにサポートするマイクロコントローラー開発環境もあります。一方、Python は、MicroPython の PyBoard (http://micropython.org) のようなボード向けや、WeIO (http://we-io.net/hardware/) によってサポートされています。

Arduino 対応のマイクロコントローラーを選択すると、クロスプラットフォームの Arduino ライブラリーと Arduino IDE を使用して開発されたプログラムを、他の Arduino 対応デバイスに簡単に移植できますが、それでも対処しなければならないボード間の違いは残っています。例えば、Arduino Uno はデジタル入出力ピン上で 5V ロジックを使用する一方 (ここで、0 ボルトは LOW または OFF と同等で、5V は HIGH または ON と同等です)、ESP8266 および Particle ボードは 3.3V ロジック (HIGH が 3.3V です) を使用します。この違いは、センサー・コンポーネントまたはアクチュエーター・コンポーネントの選択を左右する場合があります。これらのコンポーネントは、いずれかのロジック・レベルでのみ動作するためです。5V ロジック用に設計されたセンサーを 3.3V ロジック用に設計されたセンサーに交換すると、予測できない結果となり、おそらく高い電圧には耐えられないピンが損傷することになります。そのため、ロジック・レベルの異なるセンサーに交換するには、ロジック・レベル・コンバーターを追加しなければなりません。ディープ・スリープ・モードを有効にしたり、特定のプロトコルを使用して接続先センサーからデータを読み取ったりするなどの詳細レベルのハードウェア機能を実装する段階になると、デバイスまたはコンポーネントの固有のライブラリーに依存しなければならないことになるはずです。そうなると、コードの移植性がさらに制限されます。

シングル・ボード・コンピューター

シングル・ボード・コンピューター (SBC) は、マイクロコントローラーの 1 レベル上に位置するものです。なぜなら、SBC にはキーボード、マイク、ディスプレイなどの周辺装置を接続できるだけでなく、SBC のほうがより多くのメモリー容量も処理能力も使用できるためです (表 1 の 8 ビット、16 KHz のマイクロコントローラーに対し、表 2 の ARM マイクロプロセッサーは 32 ビット、1.2 GHz となっています)。表 2 に、代表的な 3 つの SBC として、Raspberry Pi 3 Model B (https://www.raspberrypi.org/)、BeagleBone Black (http://beagleboard.org/black)、DragonBoard 410c (https://developer.qualcomm.com/hardware/dragonboard-410c) の技術仕様を記載します。

図 2. Raspberry Pi シングル・ボード・コンピューター

マイクロコントローラーとシングル・ボード・コンピューターとの区別は、若干、個人の判断に任されるところがあります。デバイスの中には、Onion Omega 2 (https://docs.onion.io/omega2-docs/omega2.html#omega2) のように、搭載メモリーおよび処理能力がほとんどローエンドの SBC と同等であることからマイクロコントローラーとシングル・ボード・コンピューターの中間に位置するものもあります。また、ハイブリッド・デバイスもいくつかあります。その一例は、ARM ベースの Linux システムに Arduino 対応マイクロコントローラーを統合した UDOO Quad (http://www.udoo.org/docs/Introduction/Introduction.html) です。

表 2. Raspberry Pi 3、BeagleBone Black、DragonBoard の SBC 技術仕様
特性特長Raspberry Pi 3 Model BBeagleBone BlackQualcomm DragonBoard 410c
データの収集と制御
GPIO ピン入出力ピン 40 本 (うち、デジタル入出力 29 本)デジタル入出力 65 本 (うち、PWM 8 本)
アナログ入力 7 本
デジタル入出力 12 本
ロジック・レベル電圧3.3V5V1.8V
データの処理と保管
プロセッサーARM Cortex A53AM335X ARM Cortex A8ARM Cortex A53
プロセッサー速度1.2GHz1 GHz1.2 GHz
メモリー1 Gb4 Gb1Gb、8Gb のフラッシュ・メモリー
接続性
ネットワーク・インターフェースWi-Fi、Ethernet、BluetoothEthernet、
USB ポート (外部 Wi-Fi/Bluetooth アダプター用)
Wi-Fi、Bluetooth、GPS
電源
推奨電源5V 2.5A (マイクロ USB ポート)5V 1.2A ~ 2A (バレル)6.5 ~ 18V 2A (バレル)
その他
寸法3.4 x 2.2 (インチ)3.4 x 2.1 (インチ)3.3 x 2.1 (インチ)
標準価格$35$55$75

マイクロコントローラーの場合と同じく、SBC デバイスの機能を拡張するには、スタッカブル拡張ボード (Raspberry Pi では HAT、BeagleBone Black では Cape と呼ばれます) を追加します。また、モーター・コントローラーやアナログ・デジタル・コンバーターなどの外部モジュールを追加して、組み込みデバイスの機能の制約を緩和することもできます。

多くの SBC デバイスは小型 PC と似ていて、通常は簡素化された Linux ディストリビューションなどの組み込みオペレーティング・システムを実行します。このため、これらのデバイスに接続されたセンサーおよびアクチュエーターと連動する組み込みアプリケーションを開発する際は、選択可能な開発ツールと言語の数がマイクロコントローラー・ボード上での場合よりも大幅に増えます。ただし、マイクロコントローラー・ボードよりも SBC のほうがセットアップするのが複雑で、サイズが大きく、消費する電力も増えます。さらに、アプリケーションが保管される SD カードやフラッシュ・メモリーが破損するなどの問題も発生しやすいという欠点があります。

マイクロプロセッサー開発ボードとシングル・ボード・コンピューターのどちらを使用するかの選択

市販のマイクロプロセッサー開発ボードおよびシングル・ボード・コンピューターでは、おそらく IoT ソリューションを完全に実現するという目標を途中までしか達成できないでしょうが、この 2 つは IoT ソリューション開発を迅速に開始するには大いに役立ちます。

IoT ソリューション開発を開始する 1 つの方法は、アプリケーションの要件に照らし合わせて IoT デバイスの重要な特性を把握した上で、以下の設計上の意思決定に取り組むことです。

  • 周辺機器として必要となるセンサーと出力コンポーネントのタイプおよび数を決定します。また、必要に応じて、これらのコンポーネントの回路設計も決定します。
  • 周辺コンポーネントからの読み取りを調整して、それらのコンポーネントを制御するために使用するマイクロコントローラーまたはシングル・ボード・デバイスを選択します。
  • デバイス内通信に使用する必要があるデータ通信プロトコルを決定します (例えば、マイクロコントローラーと接続センサーとの間の通信には I2C を使用します)。
  • クラウド・サービスやアプリとの通信に使用する必要があるネットワーキング・ハードウェアおよびプロトコルを選択します。

例えば、私が限られた予算内でホーム・オートメーション・システムをセットアップするとしたら、Raspberry Pi Zero W を選びます。この SBC デバイスは小型で、価格もかなりお手頃 (約 10 ドル) です。しかも、デバイス上でデータ処理とアナリティクスを実行するのに十分な処理能力とメモリー (1GHz の ARM6 プロセッサーと 512 MB の RAM) が搭載されています。また、プログラムとデータを保管する microSD カード・フラッシュ・メモリーを最大 64GB まで拡張できるだけでなく、Raspberry Pi 3 と同じように完全な 40 ピン GPIO ヘッダーを備えているため、複数のセンサーを接続して SPI プロトコルと I2C プロトコルの両方をサポートすることも可能です。ホーム・ネットワークに接続するには、Raspberry Pi Zero W に搭載されている Wi-Fi を使用できます。また、マイクロ USB を使用してポータブル・パワー・パックから電源供給することも、コンセントから電源供給することもできます。

IoT デバイスと組み込みソフトウェア、そして上流のサービスとアプリのプロトタイピングを進めていく間、定期的にパフォーマンス、信頼性、セキュリティーを含む機能要件および非機能要件と照らし合わせてプロトタイプを評価すれば、選択した内容を必要に応じて再考することができます。

IoT プロジェクトをデプロイする IoT ハードウェアの要件

IoT デバイスは極めて特化されていて、非常に限られたコンテキストと環境内で動作するように設計されているため、IoT プロジェクトのハードウェア要件はプロジェクトごとに大きく異なります。汎用の市販のハードウェアを使用してプロトタイピングを開始するとしても、この反復型の設計と要件検証プロセスを繰り返していくと、最終的には、本番 IoT ソリューションをデプロイするために要件に応じてカスタマイズした PCB およびコンポーネントを設計・開発する方向に向かっていくはずです。このプロセスの一環として、以下のハードウェア要件に注意する必要があります。

  • セキュリティー要件
  • 開発の容易性
  • データ収集、処理、および保管の要件
  • 接続性要件
  • 電力要件
  • 物理的なデバイス設計要件
  • 費用要件

セキュリティー要件

セキュリティーは IoT 内で不可欠の要素であるため、設計と開発のあらゆる段階で考慮する必要があります。デバイスによって収集されるデータの完全性とセキュリティーは、プロトタイピングの段階でも損なわれることがあってはなりません。セキュリティー要件は、IoT デバイス自体のセキュリティー、ネットワークの堅牢さ、そして関連するクラウド・サービスとモバイルおよび Web アプリケーションのセキュリティーに関係します。

関連するセキュリティー要件は以下のとおりです。

  • データとメッセージをその送信および受信と同時に暗号化および暗号化解除できるだけの十分な処理能力とメモリーが各デバイスに備わっていることを確認します。
  • 組み込みソフトウェア開発ライブラリーが、上流のサービスおよびアプリでの認証に使用される許可およびアクセス制御メカニズムをサポートすることを確認します。
  • ネットワークに新しく追加されるデバイスを安全に登録してスプーフィングを回避するためのデバイス管理プロトコルを実装する市販のデバイスを採用するかどうか、そしてセキュリティー・パッチのセキュアな OTA アップデートをサポートするファームウェア機能が組み込まれた市販のデバイスを採用するかどうかを選択します。

開発の容易性

プロトタイピング中は、IoT デバイスを稼働中の状態にして、データを収集し、他のデバイスやクラウドと通信するまでのプロセスを迅速かつ簡単に繰り返せるようでなければならないため、開発の容易性も優先順位の高い要件となります。

ハードウェア製造元または開発コミュニティーが提供している API マニュアル、開発ツール、およびサポートのアクセス可能性、可用性、品質を考慮する必要があります。IoT ソリューション開発中のフラストレーションを軽減し、時間を節約するためには、迅速かつ簡単にプログラミングおよび再フラッシングできると同時に、デバイスごとに必要となる構成がゼロまたは最小限で済む、デプロイするのに人手のかからないデバイスを選択するようにしてください。

データ収集、処理、およびストレージ要件

接続するセンサーの数、収集するデータの分解能、データのサンプリング・レートのすべてが組み合わさって処理するデータの量が決まり、それによってデータ処理およびストレージ要件が左右されます。

デバイス上に保持する必要があるデータ量は、デバイスがデータを上流に送信するために接続する頻度によって決まります。スマート・ビルディングに設置された常に有線接続されているデバイスが、少量のロー・データを可用性の高いサーバーにストリーム配信で直接送るのであれば、大量のデータを一気に処理しなければならないデバイスと比べて、必要なデータ処理能力とストレージは少なくなります。電力を節約するために数時間間隔でしか接続しないデバイスには、次の接続までローカルでデータをログに記録しなければならないため、より多くのストレージが必要になります。

接続性要件

ワイヤレス・ネットワークの接続性要件には、動作範囲 (信号が届かなければならない距離) と、データの想定送信量および送信レートが含まれます。また、デバイスの耐障害性と、接続切断後に再接続してデータの送信を再試行する能力も考慮に入れる必要があります。

ハードウェアに Bluetooth や Wi-Fi などのネットワーク接続機能が統合されている場合もありますが、この機能が統合されておらず、拡張ボードやモジュールを使用してこの機能を追加しなければならない場合もあります。アップグレード可能な外部モジュールを使用する場合、異なるモジュールを試してそれぞれの信号送信範囲と消費電力を評価してから選べるので、柔軟性が高くなります。

電力要件

電力要件は、必要なセンサーの数やネットワーク送信レートを含め、デバイスに関する他の多くの要件によって左右されます。デバイスを有線で接続するかどうか、デバイスにバッテリーやスーパー・キャパシターなどのポータブル電源が必要かどうかを検討してください。バッテリーが必要な場合は、そのサイズ、重量、容量の要件だけでなく、バッテリーが充電可能または交換可能であるか、あるいはバッテリーが切れたらデバイスを破棄しなければならないかどうかも把握しなければなりません。また、充電式のデバイスについては、充電が必要になる頻度、充電する手段についても把握する必要があります。

物理的なデバイス設計要件

物理的なデバイス設計要件には、デバイスの外観とサイズが含まれます。

また、デバイスを設置する環境条件も考慮して、例えば防水加工または高耐久化されたエンクロージャーでなければならないかどうかを判断します。車両モニタリング・アプリケーションの一部としてデバイスをトラックの下側に取り付けるとしたら、デバイスが過酷な条件下でも動作し続けるように保護されている必要があります。つまり、防水対策が施され、土埃、衝撃、振動に耐えられる設計でなければなりません。

費用要件

ハードウェアの費用には、ハードウェアと関連コンポーネント (センサーなど) の当初の支出額に加え、継続的な運用費用 (動力費や、摩耗した部品または欠陥のあるコンポーネントの交換という形での保守費用) が含まれます。さらに、コンポーネントやデバイス・ドライバーによっては、継続的にライセンス料金を支払う必要がある場合もあります。開発の初期段階では、限られた数のカスタム・ボードを作成するよりも、市販されている既製の開発ボードや SBC を必要な数だけ購入したほうが手頃な費用で済むでしょう。ただし、数十台あるいは数百台のデバイスにスケールアップする段階にきたら、専用のハードウェア・デバイスのほうがより価値のある提案となるはずです。

まとめ

IoT プロジェクトのハードウェアを選択する際、すべての場合に当てはまる 1 つの手法というものはありません。開発の初期段階では、マイクロプロセッサーまたはシングル・ボード・コンピューターのような標準ベースのコモディティー・ハードウェアを採用すると、柔軟性を犠牲にすることなく、時間と費用を節約することができます。IoT ソリューションをデプロイする段階では、極めて重要なハードウェア設計意思決定に、プロトタイピンングの段階で得た知識を生かすことができます。


ダウンロード可能なリソース


コメント

コメントを登録するにはサインインあるいは登録してください。

static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=60
Zone=Cloud computing, Internet of Things
ArticleID=1048824
ArticleTitle=次の IoT プロジェクトに最適なハードウェアを選択する
publish-date=03272018