C SDK と埋め込み C SDK の使用シナリオ
Microsoft では、埋め込みデバイスと制約のあるデバイスのシナリオ向け Azure IoT device SDK とミドルウェアを提供しています。 この記事は、デバイス開発者がアプリケーションに使用するデバイスを決定するのに役立ちます。
次の図は、お客様が C ベース (C99) の SDK を使用してデバイスを Azure IoT に接続する 4 つの一般的なシナリオを示しています。 この記事の残りの部分では、各シナリオについて詳しく説明します。
シナリオ 1 - Azure IoT C SDK (Linux および Windows 用)
Azure IoT C SDK は、2015 年から、デバイスを IoT サービスに接続するために作成されている最初の Azure SDK です。 これは、デバイスを Azure IoT に接続するための次の機能を提供することを目的として構築された安定したプラットフォームです。
- IoT Hub サービス
- デバイス プロビジョニング サービス クライアント
- Microsoft によって作成され、保守される通信トランスポートの 3 つの選択肢 (MQTT、AMQP、HTTP)
- 一般的な TLS スタックの複数の選択肢 (ターゲット プラットフォームに応じた OpenSSL、Schannel、Bed TLS)
- TCP ソケット (Win32、Berkeley または Mbed)
通信トランスポート、TLS、ソケットの抽象化を提供すると、パフォーマンス コストが発生します。 多くのパスでは、さまざまな抽象化レイヤー間で malloc と memcpy の呼び出しが必要です。 このパフォーマンス コストは、デスクトップや Raspberry Pi デバイスに比べてわずかです。 しかし、真に制約のあるデバイスでは、メモリが断片化される可能性があるため、このコストがかなりのオーバーヘッドになります。 通信トランスポート レイヤーでは、少なくとも 100 ミリ秒ごとに doWork 関数を呼び出す必要もあります。 このような頻繁な呼び出しにより、バッテリ電源で動作するデバイス向けに SDK を最適化するのは困難になります。 また、複数の抽象化レイヤーが存在すると、お客様が特定のライブラリを使用または変更することが困難になります。
シナリオ 1 は、通常はメモリ使用量や電力消費の影響を受けにくい Windows または Linux デバイスの場合に推奨されます。 ただし、Windows および Linux ベースのデバイスでは、シナリオ 2 に示すように、Embedded C SDK を使用することもできます。 Windows および Linux ベースのデバイス向けのその他のオプションとしては、他の Azure IoT デバイス SDK (Java SDK、.NET SDK、Node SDK、Python SDK) があります。
シナリオ 2 - Embedded C SDK (ベアメタル シナリオおよびマイクロコントローラー用)
2020 年、Microsoft は、Azure SDK for Embedded C (Embedded C SDK とも呼ばれます) をリリースしました。 この SDK は、お客様からのフィードバックを基に、制約のある マイクロコントローラー デバイスをサポートする必要性の高まりに対応して構築されました。 通常、制約のあるマイクロコントローラーによって、メモリと処理能力は低下していました。
Embedded C SDK には、次の主要な特性があります。
- 動的メモリ割り当てなし。 お客様は、目的の場所 (グローバル メモリ、ヒープ、スタックなど) にデータ構造を割り当てる必要があります。 その後、初期化してさまざまな操作を実行するには、割り当てた構造のアドレスを SDK 関数に渡す必要があります。
- MQTT のみ。 MQTT は効率的で軽量のネットワーク プロトコルであるため、MQTT のみの使用は、制約のあるデバイスに最適です。 現在、MQTT v3.1.1 のみがサポートされています。
- 独自のネットワーク スタックを使用。 Embedded C SDK では、I/O 操作は実行されません。 このアプローチを使用すると、お客様は、MQTT、TLS、Socket クライアントの中から、ターゲット プラットフォームに最適なものを選択できます。
- C SDK と同様の機能セット。 Embedded C SDK では、Azure IoT C SDK と同様の機能が提供されます。ただし、次の機能は、Embedded C SDK では提供されません。
- BLOB へのアップロード
- IoT Edge モジュールとして実行する機能
- AMQP ベースの機能 (コンテンツ メッセージのバッチ処理、デバイスの多重化など)
- 全体的なメモリ占有領域が小さい。 IoT Hub に接続する方法を示すサンプルで示すように、Embedded C SDK では、74 KB の ROM と 8.26 の RAM しか使用されません。
Embedded C SDK は、オペレーティング システムのないマイクロコントローラー、リアルタイムのオペレーティング システム (Eclipse ThreadX など)、Linux、Windows を使用するマイクロコントローラーをサポートします。 お客様はカスタムのプラットフォーム レイヤーを実装して、この SDK をカスタム デバイスで使用できます。 この SDK では、Arduino、Swift などの一部のプラットフォーム レイヤーも提供されます。 Microsoft は、すぐに使用できるサポート対象プラットフォームを増やすために、他のプラットフォーム レイヤーを提出するようにコミュニティに奨励しています。 Wind River VxWorks は、コミュニティから提出されたプラットフォーム レイヤーの一例です。
Embedded C SDK は、Azure IoT C SDK と比較して柔軟性があるため、プログラミング上の利点がいくつか増えます。 特に、制約のあるデバイスを使用するアプリケーションでは、リソースを大幅に節約でき、プログラムによる制御を向上することもできます。 これに対して、Eclipse ThreadX または FreeRTOS を使用する場合は、これらと同じ利点に加えて、RTOS 実装による他の機能を得ることができます。
シナリオ 3 – Azure IoT ミドルウェアがある Eclipse ThreadX (Eclipse ThreadX ベースのプロジェクト用)
シナリオ 3 では、Eclipse ThreadX と Azure IoT ミドルウェアを使用します。 Eclipse ThreadX は、Embedded C SDK 上に構築されていて、MQTT と TLS のサポートを追加します。 Eclipse ThreadX のミドルウェアは、ネイティブの Eclipse ThreadX API と類似した API をアプリケーションに対して公開します。 このアプローチを使用すると、開発者が API を使用して、Eclipse ThreadX ベースのデバイスを Azure IoT に接続するのが簡単になります。 Eclipse ThreadX は、ソリューションに必要なすべてのネットワーク機能と IoT 機能を提供する、完全に統合された効率的でリアルタイムの埋め込みプラットフォームです。
ST、NXP、Renesas、Microchip 製のいくつかの一般的な開発者キットのサンプルを入手できます。 これらのサンプルは、Azure IoT Hub または Azure IoT Central で動作し、GitHub の IAR Workbench または semiconductor IDE プロジェクトとして入手できます。
Eclipse ThreadX 用の Azure IoT ミドルウェアは、Embedded C SDK をベースにしているため、メモリは割り当てられません。 お客様は、グローバル メモリ、ヒープ、またはスタックに SDK データ構造を割り当てる必要があります。 お客様は、データ構造を割り当てた後、初期化してさまざまな操作を実行するために、構造のアドレスを SDK 関数に渡す必要があります。
シナリオ 4 - FreeRTOS と FreeRTOS ミドルウェア (FreeRTOS ベースのプロジェクト用)
シナリオ 4 では、埋め込み C ミドルウェアを FreeRTOS に組み込みます。 埋め込み C ミドルウェアは、Embedded C SDK 上に構築され、オープンソースの coreMQTT ライブラリを介して MQTT サポートを追加します。 この FreeRTOS 用のミドルウェアは、MQTT レベルで動作します。 これは、MQTT 接続の確立、トピックのサブスクライブとサブスクライブ解除、メッセージの送受信を行います。 切断は、お客様がミドルウェア API を介して処理します。
お客様は、TLS/TCP の構成とエンドポイントへの接続を制御します。 このアプローチを使用すると、いずれかのスタックのソフトウェアまたはハードウェア実装の間で柔軟性が得られます。 FreeRTOS 用の Azure IoT ミドルウェアによってバックグラウンド タスクは作成されません。 メッセージは同期的に送受信されます。
コア実装は、こちらの GitHub リポジトリ で提供されています。 NXP1060、STM32、ESP32 など、いくつかの一般的な開発者キットのサンプルを入手できます。 これらのサンプルは、Azure IoT Hub、Azure IoT Central、Azure Device Provisioning Service で動作し、こちらの GitHub リポジトリで入手できます。
FreeRTOS 用の Azure IoT ミドルウェアは Embedded C SDK をベースとしているため、これにもメモリは割り当てられません。 お客様は、グローバル メモリ、ヒープ、またはスタックに SDK データ構造を割り当てる必要があります。 お客様は、データ構造を割り当てた後、初期化してさまざまな操作を実行するために、割り当てた構造のアドレスを SDK 関数に渡す必要があります。
C ベースの SDK の技術的な使用シナリオ
次の図は、この記事で説明した各 SDK 使用シナリオの技術的なオプションをまとめたものです。
メモリとプロトコルによる C ベースの SDK の比較
次の表では、使用されるメモリとプロトコルに基づいて 4 つのデバイス SDK 開発シナリオを比較しています。
| メモリ 割り当て |
メモリ 使用量 |
プロトコル サポートされている |
推奨対象 | |
|---|---|---|---|---|
| Azure IoT C SDK | ほとんどの場合、動的 | Unrestricted。 RAM では、1 MB 以上に スパン可能。 |
AMQP HTTP MQTT v3.1.1 |
マイクロプロセッサベースのシステム Microsoft Windows Linux Apple OS X |
| Azure SDK for Embedded C | 静的のみ | アプリケーションが割り当てる データ量によって制限されます。 |
MQTT v3.1.1 | マイクロコントローラー ベアメタル実装 RTOS ベースの実装 |
| Eclipse ThreadX 用の Azure IoT ミドルウェア | 静的のみ | 制限あり | MQTT v3.1.1 | マイクロコントローラー RTOS ベースの実装 |
| FreeRTOS 用の Azure IoT ミドルウェア | 静的のみ | 制限あり | MQTT v3.1.1 | マイクロコントローラー RTOS ベースの実装 |
各 SDK でサポートされる Azure IoT 機能
次の表では、Azure IoT 機能のサポートに基づいて 4 つのデバイス SDK 開発シナリオを比較しています。
| Azure IoT C SDK | Azure SDK for Embedded C |
Azure IoT ミドルウェア Eclipse ThreadX |
Azure IoT ミドルウェア FreeRTOS 用の |
|
|---|---|---|---|---|
| SAS クライアント認証 | はい | イエス | イエス | はい |
| x509 クライアント認証 | はい | イエス | イエス | はい |
| デバイスのプロビジョニング | はい | イエス | イエス | はい |
| テレメトリ | はい | イエス | イエス | はい |
| Cloud-to-Device メッセージ | はい | イエス | イエス | はい |
| ダイレクト メソッド | はい | イエス | イエス | はい |
| デバイス ツイン | はい | イエス | イエス | はい |
| IoT プラグ アンド プレイ | はい | イエス | イエス | はい |
| テレメトリのバッチ処理 (AMQP、HTTP) |
はい | いいえ | 番号 | いいえ |
| Azure BLOB へのアップロード | はい | いいえ | 番号 | いいえ |
| Azure IoT Edge でホストされている コンテナーでの自動統合 |
はい | いいえ | 番号 | いいえ |
次のステップ
デバイス開発と使用可能な SDK for Azure IoT の詳細については、次の表を参照してください。