IoTデバイス向け堅牢なクラウドベース・ソフトウェア・アップデート

リソース制約のあるエッジ・デバイスと強力なコントローラー/ゲートウェイの両方を最新に保つことは、事実上すべてのIoT展開で不可欠です。

ソフトウェア・アップデート機能は、インターネットに接続した瞬間に出現する進化する脅威ランドスケープからコネクテッド・デバイスを守る最前線の防衛線です。セキュリティ・パッチを決して受け取らないLinuxベースのWeb接続デバイスは、そのオペレーターにとって事実上の自殺ミッションです。

セキュリティを超えて、アップデートはアジャイルなハードウェア開発を可能にします。機能を段階的にロールアウトし、最小実行可能製品を継続的に進化するプラットフォームに変えます。顧客は時間とともに新機能を受け取れるデバイスを評価し、メーカーはハードウェアの再設計や再出荷なしで、アプリなどの機能拡張を収益化することで新たな収益源を開放できます。

デバイス接続の選択肢

アップデート戦略を計画する際、最初の決定はデバイスがアップデート・サービスに直接接続するか、デバイス接続レイヤー（Bosch IoT Hub、AWS IoT、IBM Watson IoT、Azure IoT Hubなど）を通じて間接的に接続するかです。Bosch IoT Rolloutsは両アプローチをサポートし、その柔軟性が重要な理由は以下の通りです。

直接接続は、アップデート・チャネルを他のデータ・ストリームから分離し、それぞれを独立して進化させます。この分離により、ビジネス・チャネルが急速に変化する場合でも（初期段階のIoTソリューションでは一般的で、デバイスが製造後数か月または数年間オフラインのままであることも）、アップデートAPIを安定させます。

また、デバイス上でビジネス・ロジックをアップデート・プロセスから分離します。OSGiランタイムを実行するIoTゲートウェイなどの複雑なスタックでは、ミッション・クリティカルなバンドルと同じランタイムを共有するアップデート・クライアントが、ランタイムが不安定になると失敗する可能性があります。アップデート・プロセスを分離することで、このリスクを軽減します。

もちろん、2つのチャネルはデバイス上での追加実装作業を意味し、トラフィックやバッテリー消費を増やす可能性があります。それでも、多くのエンジニアは保守性のメリットが追加の複雑さを上回ると考えています。

間接接続は、クラウド接続レイヤーが管理する単一チャネルにすべてのトラフィックを統合します。これによりデバイス・ファームウェアが簡素化され、成熟したデバイス管理プロトコル（LWM2M、OMA-DM、TR-069）が利用可能になります。これらには既にアップデート・サブプロトコルが含まれています。メーカー定義の独自プロトコルにも対応できます。

実践では、エンジニアはプロジェクトの後半までアップデート統合を延期し、間接パスをデフォルトで選び、展開後に結果に対処しがちです。Bosch IoT Rolloutsでは、プロジェクトの成熟度と複雑さに最も適したアプローチを選択できます。

直接と間接の選択では、関心の分離かアーキテクチャのシンプルさか、優先事項を自問してください。Bosch IoT Rolloutsは両方をサポートし、単一パターンにロックインせずにソリューションを進化させられます。

もう一つの重要な決定はトランスポート・プロトコルです。多くのソリューションがカスタム・オーバーレイ付きMQTTを採用し、他は接続レイヤーが提供する独自プロトコルを活用します。OMA-DM v2やLWM2Mのような標準は堅牢なフレームワークを提供しますが、初期段階の複雑さをもたらす可能性があります。適切に選ばれた標準なら、カスタム・コードを書かずにデバイスとアップデート・サービスをアウト・オブ・ザ・ボックスで動作させられます。

デバイス認証は両パスで重要です。可能な限り、アップデート・チャネルとプライマリIoTチャネルの両方で同じ非対称メカニズム（X.509証明書など）を使用。Bosch IoT RolloutsのDirect Device Integration APIがこれをサポートします。非対称認証情報が制約デバイスで実現困難な場合、中央対称キーストアでギャップを埋められます。

最終的に、単一のアーキテクチャがすべてのIoTシナリオに適合することはありません。朗報は、実証済みの多様なオプションが存在し、それぞれがセキュリティ、アジリティ、運用要件に合わせて調整可能だということです。