Azure IoT C SDK を使用した制約のあるデバイス向けの開発

Azure IoT Hub C SDK は ANSI C (C99) で記述されており、ディスクおよびメモリのフットプリントが小さいさまざまなプラットフォームを操作するのに最適です。 推奨されるメモリは 64 KB 以上ですが、正確なメモリ フットプリントは、使用するプロトコル、開かれる接続数、および対象とするプラットフォームに依存します。

注意

  • Azure IoT C SDK では、開発に役立つリソース消費量情報が定期的に発行されます。 Microsoft の GitHub リポジトリにアクセスし、最新のベンチマークを確認してください。

C SDK は apt-get、NuGet、および MBED からパッケージ形式で入手できます。 制約のあるデバイスを対象とするには、ターゲット プラットフォームに対して SDK をローカルにビルドすることをお勧めします。 このドキュメントでは、cmake を使用することにより、特定の機能を削除して C SDK のフットプリントを縮小する方法を示します。 さらに、このドキュメントでは、制約のあるデバイスを操作するための最適なプログラミング モデルについても説明します。

制約のあるデバイス向けの C SDK のビルド

制約のあるデバイス向けの C SDK をビルドします。

注意

Embedded C SDK は、制約のあるデバイスの代替手段であり、BYON (bring your own network) アプローチをサポートします。 IoT 開発者はデバイス ソリューションを作成するために、任意の MQTT クライアント、TLS、ソケットを自由に使用できます。 埋め込み C SDK の詳細については、こちらを参照してください

[前提条件]

こちらの C SDK セットアップ ガイドに従って、C SDK をビルドするための開発環境を準備します。 cmake を使用したビルドの手順に進む前に、cmake フラグを呼び出して未使用の機能を削除することができます。

余分なプロトコル ライブラリを削除する

今日、C SDK では、MQTT、MQTT over WebSocket、AMQP、AMQP over WebSocket、HTTPS という 5 つのプロトコルがサポートされています。 ほとんどのシナリオでは、クライアント上で実行されているプロトコルのうちの 1 つ、2 つを必要とします。したがって、使用しないプロトコル ライブラリは SDK から削除することができます。 シナリオに適した通信プロトコルの選択方法の詳細については、IoT Hub の通信プロトコルの選択に関する記事を参照してください。 たとえば、MQTT は、制約のあるデバイスに適する場合が多い軽量なプロトコルです。

AMQP ライブラリと HTTP ライブラリは、次の cmake コマンドを使用して削除できます。

cmake -Duse_amqp=OFF -Duse_http=OFF <Path_to_cmake>

SDK のログ機能を削除する

C SDK では、デバッグに役立つように、全体にわたって詳細なログを提供します。 運用環境のデバイス用のログ機能は、次の cmake コマンドを使用して削除することができます。

cmake -Dno_logging=OFF <Path_to_cmake>

BLOB へのアップロード機能を削除する

SDK の組み込み機能を使用することにより、大きなファイルを Azure Storage にアップロードすることができます。 Azure IoT Hub は、関連付けられた Azure Storage アカウントへのディスパッチャーとして機能します。 この機能を使用することで、メディア ファイル、大きなテレメトリ バッチ、およびログを送信することができます。 詳細情報については、「IoT Hub を使用したファイルのアップロード」を参照してください。 この機能は、アプリケーションで必要ない場合、次の cmake コマンドを使用して削除することができます。

cmake -Ddont_use_uploadtoblob=ON <Path_to_cmake>

Linux 環境でのストリップの実行

バイナリが Linux システム上で実行されている場合は、strip コマンドを利用して、コンパイル後の最終的なアプリケーションのサイズを縮小することができます。

strip -s <Path_to_executable>

制約のあるデバイス用のプログラミング モデル

次に、制約のあるデバイス用のプログラミング モデルを調べます。

シリアライザーの使用を回避する

C SDK にはオプションとして C SDK シリアライザーがあります。このオプションでは、宣言型マッピング テーブルを使用して、メソッドとデバイス ツイン プロパティを定義することができます。 シリアライザーは開発の簡略化を目的として設計されていますが、オーバーヘッドが追加されるため、制約のあるデバイスに最適ではありません。 この場合は、プリミティブ クライアント API の使用を検討し、さらに parson などの軽量のパーサーを使用して JSON を解析します。

下位のレイヤーを使用する (LL)

C SDK では 2 つのプログラミング モデルがサポートされています。 一方のセットには、下位レイヤーを意味する挿入辞 LL を伴った API が含まれています。 この API セットは軽量であり、ワーカー スレッドを起動しません。このことは、ユーザーがスケジュール設定を手動で制御する必要があることを意味します。 たとえば、デバイス クライアント用の LL API はこちらのヘッダー ファイルで確認することができます。

LL インデックスを伴っていない、もう一方の API セットはコンビニエンス レイヤーと呼ばれています。この場合、ワーカー スレッドは自動的に起動します。 たとえば、デバイス クライアント用の便利なレイヤーの API はこちらのIoT Device Client ヘッダー ファイルで確認できます。 余分な各スレッドによってシステム リソースの大部分が占有される可能性がある制約付きのデバイスの場合は、LL API の使用を検討してください。

次の手順

Azure IoT C SDK アーキテクチャの詳細について説明します。