設計要件に対して最適なIoTプロトコルの選択

Created: May 17, 2017
Updated: December 7, 2020

 

IoT製品設計は、新しいノートパソコンの購入と似ている部分があります。速度、コスト、機能、相互運用性など多くの要素を検討する必要があります。最終的には、これらの要素のうち1つまたは2つを特に重視し、他の要素を可能な限り最適化することになります。私の場合、何年にもわたってLinuxコンピューターだけを使用してきましたが、Microsoftファイルの共有が必要になったとき、相互運用性の制約は厳しいものでした。最終的に私は妥協し、コンピューターをWindowsとのデュアルブートに設定しました。

 

オープンソースでも独自のものでも、ほとんどのシステムにおいて相互運用性は重要です

 

 

IoT製品の相互運用性についての質問は、使用する通信プロトコルに依存します。これは、ほとんどの製品は別のプロトコルを使用してシステムと通信できないためです。選択するプロトコルは、ハードウェアにも影響を及ぼします。例えば、伝送距離によってシステムで利用可能なIoTモジュール、電力要件、ネットワーク構成が決まります。

 

プロトコルの選択方針

選択可能なプロトコルは膨大な数にのぼります。新しいバージョンが毎年誕生し、グループは既存のオプションの統合を試みています。自分の製品に最適なプロトコルは、どのように決定すればいいのでしょうか?

 

国際的な標準を策定しようとすることは、それ自体が混乱を、絵文字についてさえも引き起こします。

 

検討の必要があるすべてのオプションにストレスを与える前に、いくつかの助言を行いたいと思います。これは正直なところ、私自身が最初のIoT設計を行う前に読んでいればよかったと思うものです。「結局のところ、それを使わないこと自体が間違いであると言えるほど浸透している、または重要である標準は存在しません」(テキストの強調は私が加えたものです)。

1.     優先度の特定

IoT Centralが開発者の動向について行った2017年の調査によれば、IoTについて最も重要な懸念はセキュリティと相互運用性です。セキュリティは、物理的なPCBからユーザーデータの保存まで、製品設計のあらゆるレベルで対処が必要です。相互運用性はもう少しだけ簡単です。適切なプロトコルを選択することで、自分の製品が属するIoTエコシステムを最大化することが可能です。

2. 専門用語の理解

IoTの分野に関与している企業の数は非常に多いため、用語も混乱しています。データプロトコルと通信プロトコルの意味の対比さえ業界により異なり、時には会社ごとに異なることさえあります。ここに優れた概略がありますが、何かを決定する前に用語をダブルクリックしてみてください。

 

最も一般的に使用されるプロトコル

IoTの世界で「Windows」や「Mac」に相当するような主要なプロトコルは、IoTの実際の普及が始まる前には一般的に存在していました。例えば、Bluetooth、Wi-Fi、携帯電話、NFC(近距離通信)などです。これらのプロトコルはIoTアプリケーションに最適化されていない代わりに、広く使われているため相互運用性の点では有利です。

 
Bluetooth

周波数: 2.4GHz、周波数ホッピング

距離: 中距離(100m以下)

クラウドへのアクセス: 簡単(Bluetooth 4.2ではIPv6ルーティングが追加されたため、直接インターネットにアクセスできます)

Bluetoothは一般に「個人用領域のネットワーク」として使用されます。過去3年間に採用数が増大しており、いくつかの新しいバージョンやメッセージ形式も含まれています。

Bluetooth Low Energy(BLE)はIoTに特化して最適化されたもので、メッセージの形式、サイズ、伝送時間を調整し、伝送距離が短くなり(50mまで低下)、電力の要件が緩和されています。CSR Meshの追加により、ネットワーキングも改善されています。

 
携帯電話

周波数: GPRS、2G、3G、4G領域および通信事業者によって異なる

距離: 長距離(15~35km)

クラウドへのアクセス: 簡単

携帯電話通信は長距離の伝送が可能で、クラウドへ直接アクセスできますが、電力要件が高いという欠点があります。また、私自身がハードウェアとネットワークへの貧弱なサポートで問題を経験したため、プロバイダーを十分に調べることを強くお勧めします。

 
近距離通信(NFC)

周波数: 13.56MHz

距離: 非常に短い距離(数cmから数m)

クラウドへのアクセス: 中程度 - タグやモジュールからインターネットへのブリッジが必要

NFCは実際には、別の通信規格のセットです。アクティブ、受動、バッテリー補助受動形式が存在します。通信距離が最も長いのはアクティブデバイスで、受動システムで最も短くなります。

このプロトコルは、ペアリングを必要としない場合の、消費電力の小さいBluetooth代替品と考えられています。一部のNFC規格はRFIDと互換性があるため、在庫管理製品では一般的な選択肢です。

 
Wi-Fi

周波数: 2.4GHz

距離: 中距離(環境と規格に応じて40~90m)

クラウドへのアクセス: 簡単、インターネットプロトコルを基盤とする規格であるためインターネットへ通信できます

Wi-Fiは、IEEEの802.11規格を使用する最も一般的なプロトコルです。使いやすく、他の製品との互換性に優れ、高い帯域幅を使用できます。Wi-FIには多くの電力が必要ですが、最新の規格であるIEEE 802.11 AHは電力の要件を減らし、伝送距離を延ばすことを意図しています。これはIoTアプリケーションに最適です。

WeMoなど、独自のプロトコルではなく、既存のWi-Fiネットワークに乗って実現されるオプションもあります。

 

プロトコル競争のリーダーの出現

一部の新しいプロトコルは、既存のプロトコルを追い越し始めています。これらのプロトコルはIoTアプリケーション専用に設計されているため、性能上の利点があり、今後数年間に使用が増大するでしょう。

Thread

周波数: 2.4GHz

距離: 短距離(10~30m)

クラウドへのアクセス: 中程度 - ブリッジは依然として必要ですが、6LoWPANによりIPv6インターネットプロトコルを簡単に使用できます。

ThreadはGoogleから生まれ、Nestで発展したものです。数年前に予測されたほど急速に使用は増加しませんでしたが、Threadはほとんどの場合にスマートホームの有力な候補とみなされています。また、ThreadをZigbee無線上で使用し、IPv6サポートによりクラウドへアクセスすることもできます。

Zigbee

周波数: 915MHz、2.4GHz

距離: 短距離(10~20m)

クラウドへのアクセス: 中程度 - ブリッジが必要

Zigbeeは低消費電力のIoT中心のプロトコルで、128ビットのAES暗号化を使用できます。

Zigbeeは、主に複数のサプライヤーが存在することから、多くの製造業者によって使用されます。また、Zigbeeはメッシュネットワーキングでも十分に確立されています。ただし、適切に設計されていないメッシュや製品統合失敗例など、残念な話もいくつか語られています。Zigbeeのプロファイルがすべて一致し、メッシュが堅牢に設計していることを確認してください。

Z-Wave

周波数: 908/916MHz(米国)。Z-WaveはISM帯域を要するため、国によって周波数が異なります

距離: 中距離(100m)

クラウドへのアクセス: 中程度 - ブリッジが必要

Z-WaveとZigbeeはほぼ対等です。Z-WaveはISM帯域を使用し、この帯域は2.4GHz帯域ほど混雑しておらず、干渉を受けにくいことから、多く選択されます。欠点は、Z-Waveの伝送速度が低いことと、自己の「ホーム」である領域の外ではデバイスを使用できないことです。Z-Waveにも128ビットAES暗号化のオプションが存在します。

無線は単一ソースで、結果として一般に価格がより高くなります。

新しい、興味深いプロトコル

市場での地位の確立を目指している新しいプロトコルは数多く存在します。相互運用性の観点から見ると、これらのほとんどは検討に値するほど成熟しておらず、広まってもいません。しかし、これらのうちいくつかは多少の発展を見せ始めています。

AllJoyn

周波数: 各種 - AllJoynはWi-Fi、イーサネット、シリアルを使用して伝送を行います

距離: 各種 - AllJoynは広範なプラットフォームで動作するため、距離はハードウェアにより異なります

クラウドへのアクセス: 中程度 - ブリッジが必要ですが、スタンドアロンのネットワークとして機能できます

AllJoynはQualcommにより開始されたものですが、現在ではオープンソースで、Windows、iOS、OSx、Ubuntu、Androidプラットフォームで動作します。広く採用されてはいませんが、私の見たところでは最も興味深い手法の1つです。

EnOcean

周波数: 902MHz(米国およびカナダ)、2.4GHz

距離: 中距離(屋内で30m、屋外で最大300m)

クラウドへのアクセス: 中程度 - ブリッジが必要

EnOceanは環境発電プロトコルで、ワイヤレスインターフェイスの自己給電が可能です。周波数が低く帯域幅が狭いですが、独自の使用事例を提供し、ZigbeeやBLEとも互換性があります。

ANT

周波数: 2.4GHz

距離: 短距離(100m)

クラウドへのアクセス: ブリッジが必要

ANTはBLEとよく比較されるもので、センサネットワークに特化しており、各ノードがメッセージの送信と受信を行えます。

 

IoTシステムのすべてのコンポーネント間で相互運用性を実現するには、要件を注意深く管理する必要があります。

 

IoT通信プロトコルには非常に多くの選択肢が存在するため、まず製品の要件を特定することが重要です。IoTエコシステム内で、自分のシステムと他のシステムとの相互運用性を検討することを強くお勧めします。IoTの展望は急激に変化しており、多くのIoTアプリケーションを実現するために相互運用性は重要な要素であるため、これは特に難しい部分です。新しいノートパソコンをどのような目的に使用するかと同様に、IoTシステムの要求を理解することで、現在直面している設計上の質問への回答が容易になります。

 

要件管理を一貫した単純なものに保つため最良の方法は、Altium VaultのDesign Data Managementなどの優れたツールを使用することです。Vaultは変更の追跡を行い、要件に照らし合わせてコンポーネントをチェックすることで、システムおよび製品エコシステム内での相互運用性の保証をサポートします。今すぐAltiumの販売代理店にお問い合わせください。

 

 

 

most recent articles

テンプレートを活用してより多くの時間を設計に充てるには 今日、設計者は一般にEDAソフトウェアのデフォルトを開始点として使用し、寸法線、単位、グリッド設定、色、他の環境的な要素を必要に応じて変更します。プロジェクトを開始するたびに初めから作業を行うのが普通で、既知の適切な設定、レイヤー構成、回路図シートのタイトルブロックなどがほとんど再利用されません。 このように設計データをその場その場で作成すると、プロジェクトの不整合や危険を招きます。Altium Designer®とAltium 365®のテンプレートは、個々の設計者や設計チームが一貫した設計データを使用して信頼できる開始点からプロジェクトを始められるようにすることで、これらの危険を排除するのに役立ちます。 このビデオでは、設計プロセスを通してAltium Designerでテンプレートがどのように使用されているか紹介します。 以下は、セッションで紹介されたトピックとなります。 設計プロセスの各側面をテンプレート化する Altium 365を使用してチームに展開するための設計テンプレートを活用する 均一なコンポーネントをすばやく作成する 設計チーム全体で一貫性を実現する 準備や研修時間を短縮する 今すぐAltium Designerの無償評価版をリクエストして、世界最高のPCB設計ソリューションをお試しください!ご不明な点などございましたら、お問合せフォームにご入力ください。 ビデオを見る
Back to Home