第100回 SORACOM公式ブログ

ソラコム公式ブログ

SORACOM で完結！デバイスのファームウェア管理

• 
• シェア
• ツイートする
  一覧
• 

こんにちは。ソリューションアーキテクトの渡邊（dai）です。

IoT機器のファームウェア管理、どのようにされていますか？
既に出荷済みのIoT機器の機能向上や不具合対応には、ファームウェアの更新で対応するケースもあります。IoT機器の特性上、広域で大量に使われる可能性があるため、あらかじめオンラインでのファームウェア管理の仕組みを検討しておく必要があります。

大型の機器や大規模なサービスを展開する場合には、ファームウェア管理の仕組みが不可欠であり、要件を満たすために自社で構築されることが多いのではないでしょうか。一方で、バッテリー駆動の小型の機器であったり、特定の業務に絞ったサービスにおいては、ファームウェア管理のためだけに新たにシステムを構築するのは大変です。

• ファームウェアを配布するために配置するストレージの準備
• 更新の有無を判定できる仕組みの検討
• ダウンロードの条件や設定(URLなど)の制御

IoTの「つなぐ」を簡単にするサービスを提供している SORACOM では、IoT機器のファームウェア管理をより簡単にするためにお使いいただけるサービスも提供しています。

そこで本ブログでは、SORACOM を使ってIoT機器のファームウェア管理を実現する方法についてご紹介したいと思います。なお、ここで紹介するのはあくまで一例ですので、実際のシステムでは非機能要件と照らし合わせた上で、適宜ご参考にして頂ければ幸いです。

はじめに

はじめに、ファームウェアの管理には、クラウドとデバイスが協調して動作する、いわゆる双方向通信が求められます。そこで、ここでは双方向通信のパターンをおさらいしておきます。

SORACOM ではIoT機器の双方向通信について３つのデザインパターンをまとめています。そのうち「IPアクセスパターン」「アプリケーションパターン」は、待ち受けのポートをIoT機器側で保持する必要があります。今回のユースケースではバッテリー駆動の機器を想定していますので、３つ目の「デバイスリードパターン」が最も適しています。それは、アップデートのトリガをデバイス側に持つことによって、不要な待機電力の消費を防ぎ、デバイスの状態不整合などでアップデートが失敗するリスクを減らすことができるからです。

なお、サービスによってはサーバ側から強制的にファームウェアアップデートを指示したい場合もあると思います。そういったケースでは「IPアクセスパターン」で直接指示を送ったり、「アプリケーションパターン」でSMS等のプッシュ通知を用いて起動する(キックするとも言う)構成を検討いただけると良いかと思います。

ユースケース１： デバイス全てに同じファームウェアを配布する

それでは最初のユースケースです。このケースではシンプルにデバイス側からファームウェアの更新チェックとダウンロードを行うケースを見てみたいと思います。

IoTデータ収集・蓄積サービスの中でファイルを扱える「SORACOM Harvest Files」では ETag に対応しているので、これは簡単に実現できます。あらかじめこちらを参考に SORACOM Harvest を有効にし、ユーザーコンソールより以下の画面からSORACOM Harvest Files上のファームウェアファイルを更新します。

デバイス側では、特定のタイミングでファームウェアファイルの更新を確認し、更新されている場合にはダウンロード＆アップデートを行う必要があります。

ここでは curl コマンドを使って新しいファイルがあるかを確認し、ファイルが更新されていた場合のみファームウェアをダウンロードしてみます。以下の例では、curl の --etag-save オプションを使って現在の ETag を current.etg へ保存し  --etag-compare オプションを使ってcurrent.etgの内容とサーバ側の ETag の比較を行い更新の有無を確認しています。

$ curl --etag-save current.etg --etag-compare current.etg -O http://harvest-files.soracom.io/firmware/firmware-1.0.1.tgz

このコマンドを実行した結果、新しいファームウェアがあればダウンロードが始まり、ファームウェアが保存されます。保存されたファイルが壊れていないか md5sum を使って current.etg と比較した上で、デバイスのアップデートを実施しましょう。

なお、新しいファームウェアがなければファイルは保存されず、上記コマンドはすぐに終了します。

注意事項：

• Harvest Filesが扱える1ファイル当たりの最大データファイルは5GBです。また、ファイルの有効期限は 731 日間です。（参考）
• ETag の比較に使った--etag-compare は cURL 7.68.0 からの比較的新しい機能です。ご利用中の環境でこのオプションが無い場合は、代わりにIf-None-Match ヘッダーなどを活用ください。

ユースケース２：デバイス毎に異なるファームウェアを配布する

実際の運用では、例えば、特定の環境下で適用されるデバイスのみファームウェアを更新したい、不具合のワークアラウンドとして特定のデバイスでのみファームウェアを更新したい、といった個別のケースはよくあるのではないでしょうか。この場合はユースケース１とは異なる手法で実現できます。

ここではメタデータサービスを使ってこれを実現してみたいと思います。

メタデータサービスではSIMごとに任意の値を設定することが可能です。ここでは例えばデバイスのロットナンバーをあらかじめタグへ設定しておき、特定のロットナンバーのデバイスのみファームウェアアップデートを行う方法を考えてみたいと思います。

ファームウェアのアップデートを始める前に、あらかじめユーザーコンソールより各SIMのタグへロットナンバーを付与しておきます。

そして新しいファームウェアを配信する際は、アップデートの確認に必要なパラメータをユーザーデータを使って配信します。必要なパラメータとしては、ダウンロードを指定するURLになります。また、例えば先祖返りを防止するためにバージョン番号（version）を指定したり、誤ったダウンロードを防ぐためにロット番号（lotNumber）を指定したりして、ダウンロード時に検証するのも有効です。

ここではユーザーデータへ以下のようなJSONを設定します。新しいバージョンを 1.0.1、対象のロットナンバーを SORACOM101 として、ユーザーデータへ設定する例を記載しています。

{   "firmware": {     "version": "1.0.1",     "lotNumber": "SORACOM101",     "url": "http://harvest-files.soracom.io/firmware/firmware-1.0.1.tgz"   } }

そしてデバイス側では、ファームウェアの更新をする際に以下のような処理を行います。ここでは第一引数で与えられた version と 第二引数で与えられた lotNumber を、メタデータ情報 http://metadata.soracom.io/v1/userdata から取得した値と比較して判定を行っています。バージョンの比較には、sort -rV を使っています。チェックする際は、