IoTにおけるクラウドベースのソフトウェアアップデートのコンポーネント

制約のあるエッジデバイスや、より強力なコントローラーやゲートウェイのソフトウェア（コンポーネント）を更新することは、ほとんどのIoTシナリオで一般的な要件です。

ソフトウェアアップデート機能を使用すると、安全なIoTが保証されます IoTプロジェクトにパンドラの箱との戦いのチャンスを与えることで、デバイスが接続された瞬間にオープンしました。 。その瞬間から、デバイスはITセキュリティの脅威の最前線にあり、歴史的に、多くの組み込みソフトウェア開発者が直面する必要はありませんでした。最近では、たとえば、Linuxを搭載した、ウェブに接続されたデバイスを、その存続期間中にセキュリティ更新プログラムが適用されていない状態で出荷することは、自殺に似ています。

ソフトウェアアップデートのより魅力的な議論は、ハードウェアおよびハードウェア関連コンポーネントのアジャイル開発を可能にするということです。製造時にすべての機能を準備する必要はないため、最小実行可能製品などの概念をデバイスに適用できます。 IoTソリューションのクラウド側での変更は、実行時にデバイスにも適用できます。

デバイスが更新可能であれば、デバイスは顧客にとってはるかに魅力的であるため、ソフトウェアの更新はそれ自体がビジネスモデルである場合があります。言い換えれば、消費者は、固定された一連の機能を利用できるだけでなく、将来の製品アップデートの恩恵も期待できることを知っています。さらに、機能拡張機能（アプリなど）の潜在的な収益化から、新しい収益源が生まれる可能性があります。 ）新しいデバイスを設計、製造、出荷する必要はありません（改訂版）。

デバイス接続

デバイスをクラウドサービスに接続するには、さまざまなオプションがあります。アーキテクチャの観点から、デバイスを直接接続するかどうかを決定する必要があります ソフトウェアアップデートサービスに、または間接的に デバイス接続レイヤー（Bosch IoT Hub、AWS IoT、IBM Watson IoT、Azure IoT Hubなど）を介して、それ自体がIoTソリューションサービスになることもあります。私は直接的なアプローチを大いに信じており、私の製品であるBosch IoTRolloutsは実際には両方をサポートしています。その理由を以下に説明します。

始めましょう：直接接続により、IoTソリューションがデバイスのイベントストリームとコマンドに使用する独自のチャネルに加えて、ソフトウェア更新用の個別のチャネルを持つことで、IoTソリューションの関心の分離が可能になります。

これは2つの理由から興味深いアプローチです。まず、他のチャネルのすべてのビジネス要件に煩わされる必要がない場合、ソフトウェア更新チャネルのAPIを安定させるのがはるかに簡単になります 。 IoTには、接続されたデバイスがバックエンドと接触せずに長期間使用される可能性があるシナリオがあることを忘れてはなりません。場合によっては、特に製造から最初の接続までに数年かかることがあります。トランスポート層をその時間安定させるのは簡単ですが、ビジネス層の場合は確かにそうではありません。これは、多くのクラウドソリューションがまだ成熟の初期段階にあるIoTに特に当てはまります。

第2に、別のチャネルを使用すると、ビジネスを分離して、デバイス自体の機能を更新することもできます 。特に複雑なスタック（IoTゲートウェイなど）では、問題を修正するためにスタックが壊れている可能性があるため、スタック自体を更新しなければならないリスクを本当に冒したいですか？そして、それが常にそれを行うことができることを保証することができますか？ゲートウェイにOSGiランタイムがあり、1つのバンドルでメモリ不足の例外が発生し、ソフトウェア更新クライアントが同じランタイムで実行されているシナリオを想像してみてください。結果を予測するのは非常に難しいかもしれません。

ただし、分離には代償が伴います。通常、2つのチャネルはデバイス側での実装作業が増えることを意味し、シナリオによっては、トラフィックバジェットやバッテリー寿命の浪費も増える可能性があります。

2番目のオプションは、ユースケースを単一のチャネルに結合することです。これを間接と呼びます クラウド接続レイヤーは実際にデバイスに接続されており、ソリューションをクラウド内の更新トラフィックから分割する必要があるため、ソフトウェア更新サービスとの統合。

これには、単純化された接続アーキテクチャという大きな利点があります。また、汎用デバイス管理プロトコル標準（LWM2M、OMA-DM、TR-069など）を活用することもできます。これには通常、標準のサブセクションとしてのみソフトウェアアップデートが含まれます。さらに、デバイス（メーカー）自体によって定義された独自のプロトコルを使用できます。

結局のところ、IoTソリューションエンジニアは、関心の分離と単純さのどちらを選択するかを選択できます。 Bosch IoTロールアウトでは、両方のオプションをサポートすることを決定し、両方を使用しているお客様がいます。直接接続はIoTソリューションの保守がはるかに簡単であることが判明しましたが、間接接続はアーキテクチャ全体に多くの複雑さを追加します。

ただし、ほとんどのIoTエンジニアは、プロジェクトの非常に遅い段階でソフトウェア更新の問題を設計プロセスに含めます。これは、ほとんどの場合、ソフトウェア更新はコアビジネス機能の一部ではなく、それ以上の変更を加えたくないためです。彼らのアーキテクチャに。その結果、ほとんどのソリューションは間接的なアプローチを採用しており、運用開始後の結果に苦しむ可能性があります。

IoTでのクラウドベースのソフトウェアアップデートに関する2番目の決定は、プロトコルに関連しています。標準のデバイス管理プロトコルを使用する必要がありますか、それともカスタムプロトコルを設計する必要がありますか？最近の多くのIoTソリューションは、カスタムプロトコルを上にしたMQTTを支持しています。さらに、市場に出回っているIoT接続レイヤーの多くは、HTTP、MQTT、またはAMQPに加えて独自のプロトコルも提供しています。

私は個人的に、いくつかの基準には価値があり、少なくとも検討する必要があると信じています。 OMA-DM v2は有望に見え、LWM2Mについてもある程度の経験があります。いつものように、標準は優れたフレームワークを提供しますが、通常、一連の制約があります。特にIoTプロジェクトの初期段階では、これにより多くの複雑さが増す可能性があります。ただし、ソフトウェアの更新をカバーする優れた標準により、デバイスとソフトウェアの更新サービスの両方が既成のものをサポートしている場合、IoTソリューションは1行のコードを記述しなくても機能としてソフトウェアの更新を行うことができます。

最後になりましたが、デバイス認証の問題があります。もちろん、これはすべてのIoTソリューションの一般的な質問です。ただし、特に直接統合パスの場合、ソフトウェアの更新とIoTソリューションチャネルに同じ認証メカニズムを使用できるかどうかを選択する必要があります。私は通常、同じメカニズムを使用することを主張します。これは、実際には非対称認証（X.509証明書など）を使用して簡単に実装できます。 Bosch IoT Rolloutsは、Direct Device Integration APIと、IoTで通常使用されるほとんどの接続レイヤーでこれをサポートしています。非対称がオプションではない場合（制約のある組み込みデバイスの場合によくあることです）、さまざまなチャネルで使用できる中央（対称）キーストアを選択することをお勧めします。

上で指摘したように、行わなければならない選択と答えられるべき質問があります。残念ながら、IoTは、少なくとも大部分のシナリオに適合する1つのアーキテクチャを見つけた状態にはまだありません。ただし、良いニュースは、オプションがあり、それらが機能することです。