トップページ

コスト、信頼性、性能を満たす選択肢は?IoTデバイス開発に欠かせないOTA機能の実装アプローチ、3つの手法を徹底検証

近年、デバイスメーカーは製品寿命の長期化やコネクティビティに対する要求の高まりを受け、OTAアップデートによる継続的な価値提供が求められている。本稿では、フラッシュストレージにおけるOTA機能の実装アプローチの基礎を解説するとともに、従来手法の課題解決に役立つ“最適解”について提案する。

産業用および車載分野における製品寿命の長期化、そして製品のコネクティビティに対する要求が高まるにつれ、IoT(Internet of Things)デバイスメーカーは信頼性やセキュリティ問題に取り組むと同時に、システムファームウェアのOTA(Over-The-Air)アップデートにより機能強化を実装せざるを得ない状況になっています。

OTAによるアップデートは、製品に対するユーザー満足度を向上させるだけでなく、オンサイトでのアップデート作業コストの削減に役立ちます。また、車載分野においては重大なリコール発生の防止にも効果を発揮します。

OTAアップデートは、想定内外にかかわらずダウンタイムを必要最小限に抑えながら、確実に行わなければなりません。つまり、OTAアップデートにより最新ファームウェアをダウンロードし、インストールするまでのプロセス全体において、“予見可能なリスクを極力排除すること”が求められます。

一方、コスト削減や製品化までの時間短縮を実現するには、OTA機能を簡潔かつ迅速に実装しなければなりません。このため、既存の設計をほとんど変更することなくアップグレードする機能が求められます。また、OTAは無線あるいは有線(インターネットプロトコル)方式のいずれかを介して行われる“ファームウェアアップデート”の総称となっていることも忘れてはなりません。

フラッシュストレージにおけるOTA機能の実装方法は、コストや設計の複雑さ、パフォーマンスに影響します。実際、その実装方法にはさまざまなアプローチが存在しますが、それぞれ長所/短所があります。本稿ではそれらの設計手法を解説し、既存のハードウェア設計にOTA機能を実装する際、ウィンボンドのSpiStack Flashを使用することでどのような優れたメリットが得られるのか、その具体的な効果を紹介します。

 

産業用および車載システムに最も適したOTAアップデートの実装方法は?

IoT向けの一般的な組み込みシステムは、DRAMとコード格納用の外付けフラッシュメモリでサポートされているチップセットで構成されています。起動後、フラッシュメモリ内のコードは「コードシャドーイング」のプロセスを通じて解凍され、チップセットの実行のためDRAMにアップロードされます。このハードウェア構成を変更せずに、OTA機能を追加できるケースがあります。

このシステムアーキテクチャの場合、通常の操作を一時停止し、新たなバージョンのファームウェアをDRAMにダウンロードおよび認証して、一連のイレーズ/プログラム操作を通じ、一度に1セクタまたは1ブロックずつフラッシュメモリに転送することで、OTAアップデートを実行します。図1は、OTA方式により深夜に行われたセットボックスのシステム更新の例です。この間、一時的に視聴サービスは利用できず、「電源を切らないように」との警告が表示されます。

図1 セットボックスへのDRAMベースのファームウェアアップデートでは、「電源を切らないように」と、ユーザーに警告する必要があります(出典:Hyderabaduserクリエイティブ・コモンズライセンスに基づく)

 

しかし、こうした方法は産業用および車載分野向けアプリケーション、または誤動作が許されない機器向けには“不適切”です。その理由は大きく2つあります。

第一に、定期保守のために操作を中断することは、費用面や不便さで受け入れられないことが多いからです。そして第二に、この方法では絶対に許容できない故障リスクが伴います。

例えば、アップデートプロセス中に予期せぬ停電が発生した場合、DRAMに保存されている新しいファームウェアイメージは一瞬で失われてしまいます。過去のファームウェアはフラッシュから部分的に消去されているかもしれませんが、新しいファームウェアは一部しか書き込まれていない可能性があります。これは、システムに不完全なファームウェアが書き込まれる、あるいはフラッシュに保存されている2つの異なるファームウェアの一部が残ってしまうことを意味します。このような状態に陥ると、次回起動時、ほとんどの場合システムは正常に動作しないでしょう。それどころか、起動すらせずにデバイスが使用できなくなる可能性もあります。

ただ、こうしたアプローチは、OTA機能専用の追加ストレージ容量が不要なため、コスト優位性があります。そういった観点から、ローエンドのコンシューマーデバイスであれば小さなリスクとして許容されるかもしれません。

これに対し、産業用機器や車載システムなど、品質と信頼性に対する期待がはるかに高いアプリケーション向けでは絶対に許容されません。これらのアプリケーションは、新しいファームウェアが正常にダウンロードされて保存が完了するまで、既存ファームウェアのバージョンが維持される仕組みが必要となります。

 

【手法1】利用可能なフラッシュメモリを増強してのOTA実装

現在のイメージを消去せず、新しいファームウェアバージョンを保存するための簡単な方法は、利用可能なフラッシュストレージの容量を増やすことです。これは既存バージョンと新バージョンの両方を同じデバイスに、同時に保存できるようフラッシュの容量を2倍にすることを意味し、2つのバージョンのうち1つだけが“アクティブ”と見なされます。

その際、アドレスオフセットメカニズムが実行のための“アクティブコード”を決定します。これは、ホストチップセットあるいはソフトウェアでサポートされます。目的は、実行のために2バージョンあるファームウェアのうちの1つを指すよう、プログラムカウンタを変更することです。消去およびプログラム操作を含む新しいファームウェアが正常に更新されると、アドレスオフセットは、後続のコード実行が新しいファームウェアに向けられるよう調整されます。フラッシュ容量のうち古いイメージが占めていた部分は、その後の更新に使用できます。

これであれば、コード更新操作が停電などによって中断されても、システム起動に失敗したり、誤動作したりする危険性がなくなります。ただ、使用されるフラッシュメモリは1つのみであり、コード更新中のフラッシュは読み取り操作に使用できないため、その間、システムは継続的な操作を維持することが不可能です。

このアプローチを総合的に考えると、一般的な256Mb(32MB)NORフラッシュデバイスでは、64KBのブロックの消去に最大2秒かかる可能性があり、そのようなブロックは512個も存在します。そのため、システム設計者は更新処理に数百秒を割り当てなければならず、このダウンタイムは多くのアプリケーションにとって長過ぎます。DRAMから実行するアプリケーションでも定期的にフラッシュメモリにアクセスする必要があり、そのような長期間のフラッシュメモリのダウンタイムは許容できません。

 

【手法2Read While WriteフラッシュによるOTA実装

フラッシュメモリの読み取り操作が可能な状態でアップデートするためには、新しいファームウェアバージョン用に、既存のファームウェアと並行して別のフラッシュメモリを用意する必要があります。

これを成し遂げるための方法は、コードストレージに使用されるメインフラッシュを複製することです。冗長フラッシュメモリはメインフラッシュメモリの横に配置され、OTA更新イベント中に新しいファームウェアを保存するために呼び出された場合を除き、“非アクティブ”のままです。そして、新しいファームウェアが正常に保存された後、この冗長フラッシュメモリがメインフラッシュメモリとして指定されます。その後、前のメインフラッシュメモリは非アクティブとなります。

この方法は安全で信頼性が高く、システム障害の危険性がありません。そのため、高信頼性と可用性を必要とするシステムで人気があります。しかし、このようなアプローチは部品コストが高く、より多くの基板スペース、新しいレイアウト設計、そして冗長フラッシュデバイスを制御するためのチップセットからの追加信号を必要とします。

前述の通り、OTA機能を必要とする組み込みシステムは従来、コード格納のための外付けフラッシュメモリを含みます。この問題に対する解決策の一つは、フラッシュメモリ内にパーティションを作成し、プログラム/イレーズ動作をサポートするためのメモリブロックバンクと、読み出し動作をサポートするための別バンクを同じダイ上に作成することです。

これは「Read While Writeフラッシュメモリ」と呼ばれる種類のデバイスアーキテクチャで、基本的に2つのデバイスが1つのダイに融合されて1つのパッケージに入れられたものです。残念なことに、フラッシュメモリ技術の基本的な特性は、この組み合わせに対抗します。プログラム/イレーズ動作は高電圧および高電流で動作し、非常に多くのノイズが発生します。データを破壊することなく同時に読み出し動作を実行するために、チップは入念な内部分離を必要としますが、実際には、ノイズは常に性能や動作周波数を低下させます。そのようなアーキテクチャはまた、同時動作を可能にするために内部データ経路およびラッチの複製を必要とします。これらの追加回路はダイ面積を占有し、製品のコストを押し上げます。

実際のところRead While Writeフラッシュメモリは、基板のレイアウト変更を必要とすることから、一般的ではないバスインタフェースが使用され、好まれなくなりました。さらに、そのような特別なバスインタフェースをサポートしているチップセットは非常に少なく、システム設計者の選択肢は限られています。Read While Writeフラッシュメモリの使用は2つのファームウェアの保存をサポートし、もう一方のイメージをアップデートしながら1つのイメージからの読み取りアクセスを提供しますが、コストが高く、設計変更を余儀なくされ、限られたチップセットしか使えないことを考えると、そのような利点はあまり意味を持ちません。

 

【手法3SpiStack製品を用いたOTA実装

前述の手法1、2の課題を受け、ウィンボンドは単一のチップイネーブル信号を使用して、1つのパッケージに2つの同一フラッシュダイをスタックするSpiStack製品を発表しました。ハードウェア抽象化レベルでは、単一フラッシュデバイスのように見え、システムソフトウェアによって2つのダイのうち1つが選択されます。

このアーキテクチャでは、一方のダイがプログラム/イレーズを実行し、他方のダイが同時に読み出し動作を実行します。メモリ容量が2つ別々のダイで提供されるので、ノイズの問題もクリアになり、ハイスピードでの同時操作が可能です。

ダイをスタックすることの利点は、シングルダイ製品と同じパッケージでより大容量を提供できることです。例えば、8×6mmのWSONパッケージに収容されたコードストレージ用NORフラッシュの256Mbシングルダイを使用している組み込みシステムは、同一パッケージの512Mb SpiStack Flashに置き換えることが可能です。SpiStack Flashは、OTAアップデートの際、読み取り操作を中断することなく、また予期せぬ停電が発生した場合も既存のファームウェアが失われることなく、Read While Write操作をサポートします。

これは、産業用および車載向けシステムの重要な要件を満たしています。しかし、2つのダイは、ホストチップセットによってどのように制御されるのでしょうか。チップセットからのチップセレクト(/CS)信号が各ダイに必要な場合、フラッシュにもう1つピンがあるはずです。そのため、チップセットへの追加ピン接続をサポートするため、8ピンパッケージがさらにピン数の多いパッケージへと置き換えられます。

8ピンフラッシュメモリを、よりピン数の多いフラッシュに置き換えるためには、基板の再設計が必要です。また、システムによっては、チップセットに2番目のダイを駆動するのに使用できるスペアピンがありません。つまり、追加の/CSピンが必要な場合、通常のスタックダイのシステム設計に統合するのは大変不便で、最悪の場合、不可能ですらあります。

図2 C2hチップセットコマンドは、SpiStack Flash内の各ダイをダイIDに使用して切り替えます(出典:ウィンボンド)

 

この問題を回避するため、ウィンボンドは特別なC2hコマンドを通じてソフトウェアチップセレクト技術を開発し、SpiStack Flashに実装しました。このソフトウェアコマンドは、8ビットのダイIDに基づいてチップセレクト動作を行います(2)。両ダイは同じピン接続を介してホストチップセットに接続します。つまり、追加のピンが不要なので、OTAアップデートのサポートのために基板を再設計する必要がなく、追加の/CSピンを占有することもありません(3)。代わりに、オペレーティングシステムはグローバル変数とフラッシュ内の領域を使用して、どのダイがアクティブかを追跡します。

図3 ソフトウェアでチップセレクト機能を実装するのに必要なチップセレクト(/CS)ピンは1本のみです(出典:ウィンボンド)

 

SpiStack Flashは、「W25M512JV」および「W25M512JW」シリーズ製品で利用できます。また、NORおよびNANDフラッシュメモリの組み合わせも利用可能です。WSON8やBGA24など、業界標準パッケージおよびピン配置にて提供します。

 

まとめ:産業用および車載システムのOTAアップデートに最適な選択肢

産業用や車載システムにおけるOTAアップデートの実装は、アップデート中も継続操作をサポートし、以前のファームウェアを保持しつつ、更新されたファームウェアを不揮発性メモリに格納するメモリアーキテクチャが必要です。

基板の再設計が不要で、高速なシステム動作を維持しながら、この機能を実装する理想的な方法は、チップセレクト(/CS)ピンのソフトウェア制御による冗長ダイスタッキングアプローチの使用であり、それはウィンボンドのSpiStack Flashによって実現できます。

W25M512JV」および「W25M512JW」製品のデータシートは、https://bit.ly/2TlVhbJから入手可能です。

テクニカル記事

お問い合わせ

Copyright © Winbond All Rights Reserved.

This website uses cookies to ensure you get the best experience on our website. Learn more
OK