JP7345921B2 - マスタースレーブアーキテクチャのｏｔａ差分更新方法とシステム - Google Patents

Description

本発明はモノのインターネット（Internet of Things, IoT）に関し、特に、マスタースレーブアーキテクチャのOTA差分更新方法及びシステムに関する。

モノのネットワークはインターネット、無線ネットワーク、従来の電力通信網などのネットワークに基づいた情報キャリアであり、各種のIoTデバイスを通じて、知能化感知、識別、データ収集と設備管理などの知的処理過程を実現できる。IoTデバイスは、情報センサ、周波数識別技術、全地球的測位システム、赤外線センサ、レーザースキャナー、車載機器、スマートスピーカーなどを含み、IoTデバイスでリアルタイムに音声、光、電気、熱、画像、位置などの必要な情報を収集し、知能化感知、識別と管理を実現できる。IoTデバイスはアプリケーション、オペレーティングシステム、ファームウェアなどのプロセスのサポートが必要なため、時間の経過とともに、IoTデバイスのプログラムには脆弱性や互換性の問題を解決、インタラクティブや機能サポートの追加などのニーズがあり、IoTデバイスのプログラムを更新する必要がある。

従来技術では、IoTデバイスを更新する場合、マスタースレーブの構造関係を構築されることが多く、マスターノードはBluetooth（登録商標）、Wi-Fi、485、LoRa（登録商標）などの標準通信プロトコルを使用して、スレーブノードのパッケージ全体をリフレッシュする。ただし、この方法では、マスタースレーブのアーキテクチャを十分に活用できないだけでなく、フラッシュレートが低下し、更新サイクルが長くなり、更新の安定性も保証されない。

従来技術における問題を考慮して、マスタースレーブアーキテクチャのOTA差分更新方法およびシステムを提供する。

マスタースレーブアーキテクチャのOTA差分更新方法は、サーバと複数の更新待ちのノードを含み、複数の更新待ちのノードは一つのルートノードを含み、
上記のOTA差分更新方法は、
上記のルートノードは、上記のサーバからプリセットされた更新プランを取得し、その更新プランに従って各更新待ちのノードの間のマスタースレーブ接続関係及び各更新待ちのノードの更新方式を決定するステップS1と、
ルートノードは、更新プランによりサーバから差分更新ファイルをダウンロードするステップS2と、
マスタースレーブ接続関係を有する2つの更新待ちのノードごとに対して、その中のスレーブノードの更新方式によってマスターノードの処理方式を決定し、
スレーブノードの更新方式が第１のタイプの方式であれば、ステップS4に進み、
スレーブノードの更新方式が第２のタイプの方式であれば、ステップS5に進むステップS3と、
マスターノードが上記の差分更新ファイルをリフレッシュして復帰し、スレーブノードに送信して、スレーブノードに更新を完了させるステップS4と、
マスターノードは、差分更新ファイルをスレーブノードに直接送信し、更新を実行するステップS5とを含む。

好ましくは、上記の更新プランは更新シーケンス及び接続条件を含み、
上記のステップS1において、上記のルートノードは上記の更新シーケンスによって、今回の更新に関与する上記の更新待ちのノード間のマスタースレーブ接続関係を決定する；
上記ステップS4またはステップS5において、今回の更新に関与する2つのマスタースレーブ接続関係を有する上記の更新待ちのノードに対して、上記のマスターノードは、上記のスレーブノードが対応する接続関係を満たしているか否かを判断し、上記のスレーブノードが接続条件を満たした場合、上記のマスターノードと上記のスレーブノード間の接続を構築する。

好ましくは、上記のスレーブノードの現在のバージョンのデータが上記のスレーブノードのスレーブメモリ領域に事前に保存されており、
上記のステップS4において、マスタースレーブ接続関係を有する2つの上記の更新待ちのノードごとに対して、具体的に、
上記のマスターノードが上記の差分更新ファイルを取得し、更新要求を上記のスレーブノードに送信するステップS40と、
上記のスレーブノードから同意の旨を受信した後、上記のマスターノードと上記のスレーブノードを制御して、同時に更新モードに入らせるステップS41と、
上記のマスターノードは、上記のマスタースレーブ接続関係によって上記のスレーブノードに接続するステップS42と、
上記のマスターノードは、上記のスレーブノードの現在のバージョンデータを取得し、それを上記のマスターノードのマスターメモリ領域に保存するステップS43と、
上記のマスターノードは、上記の差分更新ファイルを分析し、上記のマスタースメモリ領域にある現在のバージョンのデータに変化が生じた複数のマスター差分メモリブロックに対応する差分ブロック更新データを取得するステップS44と、
上記のマスターノードは差分ブロック更新データによって、全ての上記のマスター差分メモリブロックにある現在のバージョンのデータをリフレッシュ及び復帰し、リフレッシュ及び復帰された更新バージョンのデータを取得するステップS45と、
上記のマスターノードが、上記の差分ブロック更新データを対応する上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じたスレーブ差分メモリブロックに送信し、上記のスレーブノードに更新を完了させるステップS46とを含む。

好ましくは、上記のステップS46は、
上記のマスターノードは、リフレッシュ要求を上記のスレーブノードに送信するステップS461と、
上記のスレーブノードの上記のリフレッシュ要求に対する受信要求を受けた後、全ての上記の差分ブロック更新データを対応する上記のスレーブメモリ領域にある上記のスレーブ差分メモリブロックに送信し、上記のスレーブノードに更新を完了させるステップS462とを含む。

好ましくは、上記のステップS44は、また、
上記のマスターノードは、上記のマスター差分メモリブロックにある上記の現在のバージョンのデータをバックアップ保存を実行して、バックアップのバージョンのデータを生成し、
上記のステップS46からさらにステップS47を実行し、
ステップS47において、上記のマスターノードは、上記のスレーブノードのバージョン番号を事前設定された時間までに受信しているかどうかを判断し、
YESであれば、上記のプロセスを終了し、
NOであれば、上記の差分ブロック更新データを再度上記のスレーブノードに送信して、上記のスレーブノードのバージョン番号を事前設定された時間までに受信しているかどうかを再度判断し、送信回数が事前設定された回数を超えた場合は、上記のバックアップのバージョンのデータを上記のスレーブノードの上記のスレーブ差分メモリブロックに送信する。

好ましくは、上記のスレーブノードの現在のバージョンのデータは、事前に上記のスレーブメモリ領域に保存され；
上記のステップS5において、マスタースレーブ接続関係を有する2つの上記の更新待ちのノードごとに対して、具体的に、
上記のスレーブノードは、上記のマスターノードから直接に送信された上記の差分更新ファイルを取得するステップS50と、
上記のスレーブノードは、再起動して更新モードに入るステップS51と、
上記の差分更新ファイルに従って、上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のスレーブ差分メモリブロックを得て、その全ての上記のスレーブ差分メモリブロックにある現在のバージョンのデータをリフレッシュするステップS52とを含む。

好ましくは、上記のステップS52は、また、
上記のスレーブ差分メモリブロックにある上記の現在のバージョンのデータをバックアップして、バックアップのバージョンのデータを生成することを含み、
上記のステップS52に続き、さらに、ステップS53を実行し、
ステップS53において、全ての上記のスレーブ差分メモリブロックをリフレッシュした後、それが再び再起動の可能性を判断し、
YESであれば、上記のプロセスを終了し、
NOであれば、上記のバックアップのバージョンのデータに従って上記のスレーブ差分メモリブロックをリフレッシュする。

好ましくは、上記のスレーブ差分メモリブロックにある上記の現在のバージョンのデータに対するバックアップ処理を実行するプロセスは、
上記のスレーブノードのメモリリソースは事前設定されたバックアップ閾値を満たしているかどうかを判断し、
YESであれば、上記のバックアップのバージョンのデータを上記のスレーブメモリ領域に保存し、
NOであれば、上記のバックアップのバージョンのデータを上記のマスターノードのマスターメモリ領域に保存することを含む。

好ましくは、上記のステップS43または上記のステップS52の前に検証ステップを含み、
上記の検証ステップは、
上記の差分更新ファイルのファイル検証値が上記の現在のバージョンのデータのデータ検証値と一致しているかどうかを判断し、
YESであれば、検証に合格し、次のステップに進み、
NOであれば、検証に合格せず、プロセスを終了することを含む。

好ましくは、上記のステップS1において、上記のルートノードは、今回の更新に関与する上記の更新待ちのノードが上記のルートノードだけであると分析した時、
上記のステップS2において、上記のルートノードが再起動された後、更新モードに入り、上記の差分更新ファイルに従って、上記のルートノードのルートメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のルート差分メモリブロックを得て、その全ての上記のルート差分メモリブロックにある現在のバージョンのデータをリフレッシュする。

マスタースレーブアーキテクチャを備えたOTA差分更新システムであり、サーバと複数の更新待ちのノードを含み、上記の複数の更新待ちのノードは一つのルートノードを含み、
上記のOTA差分更新システムは、上記のサーバからプリセットされ更新プランを取得し、上記の更新プランに従って、上記の各更新待ちのノード間のマスタースレーブの接続関係及び上記の各更新待ちのノードの更新方式を決定する取得モジュールと、
上記の取得モジュールに接続され、上記の更新プランに従って上記のサーバから差分更新ファイルをダウンロードするダウンロードモジュールと、
上記のダウンロードモジュールに接続され、マスタースレーブの接続関係を有する2つの上記の更新待ちのノードごとに、その中のスレーブノードの上記の更新方式に従ってマスターノードの上記の更新方式を決定する選択モジュールと、
上記の選択モジュールに接続され、上記のスレーブノードの更新方式が第１のタイプの方式か第２のタイプの方式かを判断し、対応する判断結果を生成する判断モジュールと、
上記の判断モジュールと上記のダウンロードモジュールに接続され、上記の判断結果は上記のスレーブノードの更新方式が第１のタイプの方式を示す時、上記のマスターノードをコントロールして、上記のマスターノードに上記の差分更新ファイルをリフレッシュ及び復帰させて上記のスレーブノードに送信させ、上記のスレーブノードに更新させる第１の更新モジュールと、
上記の判断モジュールと上記のダウンロードモジュールに接続され、上記の判断結果が上記のスレーブノードの更新方式が第２のタイプの方式を示す時、上記のマスターノードをコントロールして、上記のマスターノードに上記の差分更新ファイルを上記のスレーブノードに直接送信させ、更新を実行する第２の更新モジュールとを含む。

好ましくは、上記の更新プランは更新シーケンス及び接続条件を含み、
上記の取得モジュールは、上記の更新シーケンスに従って、今回の更新に関与する上記の更新待ちのノード間のマスタースレーブの接続関係を決定し、
上記の第１の更新モジュールまたは上記の第２の更新モジュールは、今回の更新に関与するマスタースレーブの接続関係を有する2つの上記の更新待ちのノードに対して、上記のマスターノードは、上記のスレーブノードが対応する接続関係を満たしたかどうかを判断し、上記のスレーブノードが上記の接続条件を満たす場合、上記のマスターノートと上記のスレーブノート間の接続を構築する。

好ましくは、上記のスレーブノードの現在のバージョンのデータは、事前に上記のスレーブノードのスレーブメモリ領域に保存され、
上記の第１の更新モジュールは、
マスタースレーブの接続関係を有する2つの上記の更新待ちのノードごとに、上記のマスターノードをコントロールして、上記のマスターノードに上記の差分更新ファイルを取得させて上記のスレーブノードに送信させる第１の取得ユニットと、
上記の第１の取得ユニットに接続され、上記のマスターノードをコントロールして、上記のマスターノードに上記のスレーブノードの同意の旨を受信させて、その同意に従って上記のマスターノードと上記のスレーブノードにともに更新モードに入らせることをコントロールする第１の再起動ユニットと、
上記の第１の再起動ユニットに接続され、上記のマスターノードをコントロールして、上記のマスタースレーブの接続関係に従って、上記のマスターノードに上記のスレーブノードに接続させるマスタースレーブの接続ユニットと、
上記のマスタースレーブの接続ユニットに接続され、上記のマスターノードをコントロールして、上記のマスターノードに上記のスレーブノードの現在のバージョンのデータを取得させて上記のマスターノードのマスターメモリ領域に保存させる第２の取得ユニットと、
上記の第２の取得ユニットに接続され、上記のマスターノードをコントロールして、上記の差分更新ファイルを分析させ、上記のマスターメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のマスター差分メモリブロックに対応する差分ブロック更新データを得らせる分析ユニットと、
上記の分析ユニットに接続され、上記のマスターノードをコントロールして、上記の差分ブロック更新データによって全ての上記のマスター差分メモリブロックにある上記の現在のバージョンのデータをリフレッシュ及び復帰させ、リフレッシュ及び復帰された更新のバージョンのデータを得らせる第１のリフレッシュユニットと、
第１のリフレッシュユニットに接続され、上記のマスターノードをコントロールして、上記の差分ブロック更新データを対応する上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じたスレーブ差分メモリブロックに送信させ、上記のスレーブノードに更新させる送信ユニットとを含む。

好ましくは、上記のスレーブノードの現在のバージョンのデータが事前に上記のスレーブノードのスレーブメモリ領域に保存され、
上記の第２の更新モジュールは、
上記のスレーブノードをコントロールして、上記のスレーブノードに上記のマスターノードから直接に送信された上記の差分更新ファイルを取得させる第３の取得ユニットと、
上記の第３の取得ユニットに接続され、上記のスレーブノードを再起動させて更新モードに入らせる第２の再起動ユニットと、
上記の第２の再起動ユニットに接続され、上記のスレーブノードをコントロールして、上記の差分更新ファイルに従って、上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のスレーブ差分メモリブロックを得て、全ての上記のマスター差分メモリブロックにある現在のバージョンのデータに対してリフレッシュを実行させる第２のリフレッシュユニットとを含む。

好ましくは、上記の取得モジュールは、上記のルートノードをコントロールして、この更新に関与する上記の更新待ちのノードが上記のルートノードだけであるかどうかを分析させ、対応する判断結果を生成させる判断ユニットを含み、
上記のダウンロードモジュールは、上記の判断結果はこの更新に関与する上記の更新待ちのノードが上記のルートノードだけであることを示す時、上記のルートノードを再起動させ、更新モードに入らせ、上記の差分更新ファイルに従って、上記のルートノードのルートメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のルート差分メモリブロックを得て、全ての上記のルート差分メモリブロックにある現在のバージョンのデータをリフレッシュさせる第４の更新ユニットを含む。

本発明の有益効果は、OTA差分更新方法及びシステムを提供し、マスタースレーブノードを利用して差分更新を実現し、マスタースレーブのアーキテクチャのメリットを十分に發揮し、リフラッシュレートをアップし、更新サイクルを短縮し、更新の安定性も確保することができる。

本発明の好ましい実施形態におけるOTA差分更新方法のプロセス図である。 本発明の好ましい実施形態におけるステップS4のプロセス図である。 本発明の好ましい実施形態におけるステップS46のプロセス図である。 本発明の好ましい実施形態におけるステップS47のプロセス図である。 本発明の好ましい実施形態におけるステップS5のプロセス図である。 本発明の好ましい実施形態におけるステップS53のプロセス図である。 本発明の好ましい実施形態におけるOTA差分更新方法の構造図である。 本発明の好ましい実施形態における第１の更新モジュールの構造図である。 本発明の好ましい実施形態における送信ユニットの構造図である。 本発明の好ましい実施形態における分析ユニットの構造図である。 本発明の好ましい実施形態における第２の更新モジュールの構造図である。 本発明の好ましい実施形態における第２のリフレッシュユニットの構造図である。

本発明の図面を参考して、実施形態にある技術案を明確且つ完全に説明するが、記載されている実施形態がただ本発明の一部の実施形態にすぎず、全ての実施形態ではないことが明らかである。本発明に記載されている実施形態に基づいて、当業者が創造的なものを作り出さないで得られた全ての他の実施形態は、本発明の保護範囲に属する。

本発明の実施形態と実施形態における特性は互いに組み合わせることができることに注意する必要がある。

以下は、図面と具体的な実施形態を組み合わせて、本発明をさらに説明するが、本発明の限定とするものではない。

本発明は、マスタースレーブアーキテクチャのOTA差分更新方法およびシステムを提供し、それは、サーバと複数の更新待ちのノードを含み、複数の更新待ちのノードは一つのルートノードを含み、
図１に示すように、OTA差分更新方法は、
ルートノードは、サーバからプリセットされた更新プランを取得し、その更新プランに従って上記の各更新待ちのノードの間のマスタースレーブ接続関係及び各更新待ちのノードの更新方式を決定するステップS1と、
上記のルートノードは上記の更新プランにより上記のサーバから差分更新ファイルをダウンロードするステップS2と、
マスタースレーブ接続関係を有する2つの上記の更新待ちのノードごとに対して、その中のスレーブノードの更新方式によってマスターノードの処理方式を決定し、
上記のスレーブノードの更新方式が第１のタイプの方式であれば、ステップS4に進み、
上記のスレーブノードの更新方式が第２のタイプの方式であれば、ステップS5に進むステップS3と、
上記のマスターノードが上記の差分更新ファイルをリフレッシュして復帰し、上記のスレーブノードに送信して、上記のスレーブノードに更新を実行させるステップS4と、
上記のマスターノードは、上記の差分更新ファイルを上記のスレーブノードに直接送信し、上記のスレーブノードに更新を実行するステップS5とを含む。

具体的に、メインアーキテクチャの利点を最大限に活用し、更新レートを改善し、更新時間を短縮し、更新の安定性を確保するために、本発明はOTA差分更新方法を提供し、サーバに今回の更新するための更新プランはプリセットされ、ステップS1が実行され、ルートノードは、今回の更新するための更新プランを取得するために、サーバと無線／有線で接続され、当該の更新プランに従って、今回の更新に関与する全ての更新待ちのノード、各更新待ちのノード間のマスタースレーブの接続関係及び各更新待ちのノードの更新方式を決定する。ステップS2が実行され、ルートノードは、更新プランに関与する更新待ちのノードに従って、サーバから更新待ちのノードの差分更新ファイルをダウンロードする。ステップS3が実行され、マスタースレーブの接続関係を有する2つの更新待ちのノードごとに対して、そのマスタースレーブの接続関係中のスレーブノードとする更新待ちのノードの更新方式に従って、マスターノードとする更新待ちのノードの処理方式を決定することができる。即ち、スレーブノードの更新方式が第１のタイプの方式であれば、つまり、スレーブノードがマスターノードに頼って更新を完了する場合は、ステップS4に進み、当該のマスターノードは差分更新ファイルをリフレッシュ及び復帰し、スレーブノードに保存されている現在のバージョンのデータに変化が生じるスレーブ差分メモリブロックに対応的に送信し、スレーブノードを直接に更新させ；スレーブノードの更新方式が第２のタイプの方式であれば、つまり、スレーブノードは自身の更新機能によって更新を完了することができる場合は、ステップS5に進み、当該のマスターノードは差分更新ファイルをスレーブノードに直接に送信し、スレーブノードは当該の差分更新ファイルに従って更新を完了する。

さらに、本発明のステップは、順に繰り返して実行することができ、つまり、現在の更新待ちのノードを取得して更新してから、次の更新待ちのノードを取得して更新することができ、または、複数の更新待ちのノードを並行に取得して同時に更新することもできる。

さらに、ステップS3のスレーブノードの更新方式は、更新プランにプリセットされうる。すなわち、更新プランに今回の更新に関与する全ての更新待ちノードの更新方式を含み、ルートノードにより、更新プランを分析し、今回の更新に関与する全てのノードの更新方式を取得することができる、事前に各ノードにマークを付けて、マークによりノードの更新方式を判断してもいい、または、マスターノードによりリアルタイムにスレーブノードの現在の負荷を監視して、負荷状態に応じて自身の更新に耐えられるかどうかを判断し、そして対応的な更新方式を選択してもいい。即ち、マスタースレーブの接続関係を有する2つの更新待ちのノードに対して、マスターノードは、事前に、スレーブノードから受信されたデフォルト情報に従って、スレーブノードの更新方式を選択してもいい、または、ビジネスロジックセッションを介してインタラクティブにスレーブノードの更新方式を選択してもいい。

ここで、ビジネスロジックセッションのプロセスは、マスターノードが更新パッケージのダウンロードが完了した後にスレーブノードに更新要求を送信して通知し、スレーブノードが自身の条件に従ってどの更新方式で応答するかと見なすことができる。応答パラメータが0の場合は、第１のタイプの更新方式とし、応答パラメータが1の場合は、第２のタイプの更新方式とする。マスターノードは、受信した応答パラメータに従って更新方法を決定する。さらに、応答パラメータはこれらの2つの値に限定されず、例えば、パラメータが2の場合、サードパーティの機能を利用して更新することを表す場合がある。

注意すべきなのは、更新待ちのノードに対して、マスターノードであるかスレーブノードであるかが常に固定されてなくて、異なるマスタースレーブの接続関係の中でのマスタースレーブの役割が異なる。本発明は、終始、現在のマスタースレーブの関係におけるスレーブノードとしている方の更新方式に従って、マスターノードの処理方法を決定する。例えば、更新待ちのノードにはA20、A30、A31を含み、A1はA20に直接接続され、A20はA30とA31に接続され、更新待ちのノードA20の更新方式については、更新待ちのノードA20はA1とA20間のマスタースレーブの接続関係においてスレーブノードとし、一方、A20とA30間、またはA20とA31間のマスタースレーブの接続関係においてマスターノードとし、更新待ちのノードA20に対して更新を行う場合、更新待ちのノードA20がスレーブノードとする時の更新方式に従って、対応するマスターノードA1の処理方式を決定する。つまり、更新待ちのノードA20の更新方式が第１のタイプの方式である時、マスターノードA1が差分ファイルをリフレッシュ及び復帰して、スレーブノードA20に送信し、一方、更新待ちのノードA20の更新方式が第２のタイプの方式である時、マスターノードA1が直接に差分ファイルをマスターノードA20に送信し、スレーブノードA20が自身機能に依存して更新を完了する。

さらに、本出願は、ただマスタースレーブの接続関係を有する2つの更新待ちのノードごとに対して選択的に処理し、このマスタースレーブの接続関係中の更新待ちのノードが他のマスタースレーブの接続関係を有することを考慮しない。例えば、上記の更新待ちのノードには、A1、A20、A30とA31を含み、A1はA20に直接接続され、A20はA30とA31に接続され、更新待ちのノードA30については、A20とA31間のマスタースレーブ接続関係しか考慮せず、スレーブノードA30とする更新方式に従って、マスターノードA20の処理方式を決定し、A30またはA20が他のマスタースレーブノード接続関係を有することを考慮する必要せず、例えば、A1とA20間のマスタースレーブ接続関係、A20とA31間のマスタースレーブ接続関係。言い換えれば、本発明による更新待ちのノードは複数のレベルに分割することができ、例えば、1級マスターノード、1級スレーブノード、2級スレーブノード、3級スレーブノードなど、対応的に、マスターノードはA1になり、1級スレーブノードはA20になり、2級ノードはA30とA31になり、A20の1級スレーブノードに対して更新する時、マスタースレーブ接続関係に関与する2つの更新待ちのノードは1級スレーブノードA1と1級スレーブノードA20であり、このときの1級マスターノードA1は当該のマスタースレーブの接続関係中のマスターノードになり、1級スレーブノードA20は当該のマスタースレーブの接続関係中のスレーブノードになる。2級スレーブノードA30に対して更新する時、マスタースレーブ接続関係に関与する2つの更新待ちのノードは1級スレーブノードA20と2級スレーブノードA30であり、この時の1級スレーブノードA20は当該のマスタースレーブの接続関係中のマスターノードになり、2級スレーブノードA30は当該のマスタースレーブの接続関係中のスレーブノードになる。

ここで、更新待ちのノードは、一つのデバイスに設置された複数のコントローラーと複数のプロセッサーであってもいい、一つのデバイスであってもいい、ルートノードは、LANモジュール、IPネットワークモジュールなどの外部と情報を交換する機能を持つマルチモードデバイス内の複数のノードにすることができる。

本発明の好ましい実施形態において、更新プランは更新シーケンスと接続条件を含み、
ステップS1において、ルートノードは更新シーケンスによって、今回の更新に関与する更新待ちのノード間のマスタースレーブ接続関係を決定する；
ステップS4またはステップS5において、今回の更新に関与する2つのマスタースレーブ接続関係を有する更新待ちのノードに対して、マスターノードは、スレーブノードが対応する接続関係を満たしているか否かを判断し、スレーブノードが接続条件を満たした場合、マスターノードとスレーブノード間の接続を構築する。

具体的に、更新プランに更新シーケンス、即ち、更新待ちのノードの前後更新順次を含む。本発明は、更新順次に従ってマスタースレーブ接続関係を順序に構築し、更新待ちのノードの更新を完了することができる。注意すべきなのは、更新順次は更新待ちのノードのマスタースレーブ接続構造と関係がない。例えば、上記の更新待ちのノードにはA1、A20、A30とA31を含み、A1はA20に直接接続され、A20はA30とA31に接続され、A30はA20とA30のマスタースレーブの接続関係においてスレーブノードとし、A2はマスターノードとするが、A30の更新順序はA2の後にしてもいい、またはA2の前にしてもいい。

更新プランには更新順序に関連する接続条件も含む。更新順序に従って、現在関与しているスレーブノードが決定され、現在のスレーブノードが更新条件を満たしているかどうかが判断される。更新条件が満たされている場合、マスターノードとスレーブノード間の接続が構築される。ここで、更新条件はスレーブノードの現在のリソース使用率、アイドル状態、及びスレーブノードに対応するデバイスの残りの電力などを含み得、さらに、現在の周囲温度、現在の時間などを含むことができる。

本発明の好ましい実施形態において、スレーブノードの現在のバージョンのデータがスレーブノードのスレーブメモリ領域に事前に保存され、
図２に示すように、ステップS4において、マスタースレーブ接続関係を有する2つの更新待ちのノードごとに対して、具体的に、
マスターノードが差分更新ファイルを取得し、更新要求をスレーブノードに送信するステップS40と、
スレーブノードから同意の旨を受信した後、マスターノードとスレーブノードを制御して、同時に更新モードに入らせるステップS41と、
マスターノードは、マスタースレーブ接続関係によってスレーブノードに接続するステップS42と、
マスターノードは、スレーブノードの現在のバージョンのデータを取得し、それをマスターノードのマスターメモリ領域に保存するステップS43と、
マスターノードは、差分更新ファイルを分析し、マスタースメモリ領域にある現在のバージョンのデータに変化が生じた複数のマスター差分メモリブロックに対応する差分ブロック更新データを取得するステップS44と、
マスターノードは差分ブロック更新データによって、全てのマスター差分メモリブロックにある現在のバージョンのデータをリフレッシュ及び復帰し、リフレッシュ及び復帰された更新バージョンのデータを取得するステップS45と、
マスターノードが、差分ブロック更新データを対応するスレーブメモリ領域にある現在のバージョンのデータに変化が生じたスレーブ差分メモリブロックに送信し、スレーブノードに更新を完了させるステップS46とを含む。

具体的に、スレーブノードの更新方式が第１のタイプの更新方式、即ち、スレーブノードがマスターノードに依存して更新を完了するという更新方式である時、マスターノードが差分ファイルをリフレッシュ及び復帰してからスレーブノードに送信し、スレーブノードに更新を完了させる。まず、ステップS40を実行し、マスターノードがサーバからダウンロードされた差分更新ファイルを取得し、当該の差分更新ファイルに従って更新要求を生成してスレーブノードに送信し、スレーブノードが当該の更新要求を受信した後、現在の状況に応じて同意要求または拒否要求を生成し、マスターノードにフィードバックすることができる。ステップS41を実行し、実際の動作では、Bootloaderを使用して起動プログラムをガイドでき、つまり、マスターノードがスレーブノードからフィードバックされた同意要求を受信すると、マスターノードとスレーブノードに対応的に更新モードに入らせ更新を実行させる。ステップS42を実行し、マスターノードとスレーブノード間のマスタースレーブ接続を構築する。さらに、ここで、スレーブノードが更新プランにある接続条件を満たしているかどうかを判断することができ、スレーブノードが接続条件を満たした後、マスターノードをスレーブノードに接続する。次にステップS43を実行し、マスターノードがスレーブノードの現在のバージョンのデータを取得してマスターノードのマスターメモリ領域に保存し、ここで、スレーブノードの現在のバージョンのデータがスレーブノードの完全なバージョンのデータであることに注意が必要である。そしてステップS44－ステップS45を実行し、マスターノードが、スレーブノードの現在のバージョンのデータ及び今回の更新に関与するスレーブノードの差分更新ファイルを分析し、マスターメモリ領域にある現在のバージョンのデータに変化が生じたマスター差分メモリブロックを決定し、マスター差分メモリブロックに対応する差分ブロック更新データを取得し、マスターノードはまた差分ブロック更新データに従って、全てのマスター差分メモリブロックにある現在のバージョンのデータをリフレッシュ及び復帰し、リフレッシュ及び復帰された更新バージョンのデータを取得し、つまり、マスターメモリ領域にスレーブノードの現在のバージョンのデータを保存する複数のマスターメモリブロックを含み、全てのマスターメモリブロックにあるバージョンのデータに変化が生じたマスターメモリブロックをマスター差分メモリブロックとし、差分更新ファイルを分析し、マスター差分メモリブロックに対応する差分ブロック更新データを取得し、その差分ブロック更新データに従ってマスター差分メモリブロックにあるバージョンデータを対応にリフレッシュし、リフレッシュ及び復帰されたバージョンデータがスレーブノードの更新されたバージョン番号である。最後に、ステップS46を実行し、マスター差分メモリブロックに対応する差分ブロック更新データを今回の更新に関与するスレーブノードのバージョンデータに変化が生じたスレーブ差分メモリブロックに送信し、マスター差分メモリブロックに保存されているのはスレーブノードの現在のバージョンのデータであり、差分ブロック更新データはマスター差分メモリブロックに対応するだけでなく、スレーブノードのスレーブ差分メモリブロックにも対応する。以上によって、マスターノードは、差分ブロック更新データを対応するスレーブノードのスレーブ差分メモリブロックに送信し、スレーブノードが当該の差分ブロック更新データの受信を完了した後に、それをスレーブノードが更新を完了したことと同等になられ、つまり、第１のタイプの方式により、マスターノードを介してスレーブノードが直接更新でき、スレーブノードで更新リフレッシュを実行する必要がない。

図３に示すように、本発明の好ましい実施形態において、ステップS46は、
マスターノードは、リフレッシュ要求をスレーブノードに送信するステップS461と、
スレーブノードのリフレッシュ要求に対する受信要求を受けた後、全ての差分ブロック更新データを対応するスレーブメモリ領域にあるスレーブ差分メモリブロックに送信し、スレーブノードに更新を完了させるステップS462とを含む。

具体的に、マスターノードは、全てのマスター差分メモリブロックのリフレッシュ及び復帰を完了した後、リフレッシュ要求を生成してスレーブノードに送信し、スレーブノードは、当該のリフレッシュ要求を受信して、現在の動作状況に応じて同意要求または拒否要求を生成してマスターノードに送信し、マスターノードは当該の同意要求を受信した後、マスターノードとスレーブノード間の接続によって、全ての差分ブロック更新データをスレーブノードのスレーブ差分メモリブロックに送信し、スレーブノードに直接に更新を完了させる。

図４に示すように、本発明の好ましい実施形態において、ステップS44は、また、
マスターノードは、マスター差分メモリブロックにある現在のバージョンのデータをバックアップ保存を実行して、バックアップのバージョンのデータを生成し、
ステップS46からさらにステップS47を実行し、
ステップS47において、マスターノードは、スレーブノードのバージョン番号を事前設定された時間までに受信しているかどうかを判断し、
YESであれば、プロセスを終了し、
NOであれば、上記の差分ブロック更新データを再度スレーブノードに送信して、スレーブノードのバージョン番号を事前設定された時間までに受信しているかどうかを再度判断し、送信回数が事前設定された回数を超えた場合は、バックアップのバージョンのデータをスレーブノードのスレーブ差分メモリブロックに送信する。

具体的に、マスターノードは、差分更新ファイルを分析し、マスター差分メモリブロック及びマスター差分メモリブロックにある現在のバージョンのデータを決定する時、マスター差分メモリブロックにある現在のバージョンのデータに対してバックアップ処理をし、バックアップバージョンのデータを得ることができる。スレーブノードがマスターノードから送信された差分ブロック更新データを受信して差分メモリブロックをリフレッシュしてから、ステップS47において、マスターノードは、スレーブノードのバージョン番号を事前設定された時間までに受信しているかどうかを判断し、受信していれば、プロセスを終了し、受信してなければ、再試行メカニズムを実行し、つまり、差分ブロックのデータをスレーブノードに再送信し、スレーブノードのバージョン番号を事前設定された時間までに受信しているかどうかを再判断し、事前設定された回数に達して成功しない場合、つまり、差分ブロック更新データを何度もスレーブノードに送信し、毎回スレーブノードのバージョン番号が受信されない場合、ロールバックプロセスを開始、マスターノードは、バックアップのバージョンのデータ、つまり、スレーブノードのソースデータをスレーブノードに送信し、即ち、マスターノードは直接各ブロックのバージョンデータを対応するメモリ位置に送信する。

さらに、ロールバックプロセスは、マスターノードは、バックアップのバージョンのデータに従って、スレーブノードの全てのスレーブ差分メモリブロックにある最初のスレーブ差分メモリブロックから最後のスレーブ差分メモリブロックまで直接リフレッシュすることができ、また、マスターノードはスレーブノードの再起動に失敗した理由、つまり、スレーブ差分メモリブロックのリフレッシュからリフレッシュできない全てのスレーブ差分メモリブロックを特定し、特定されたブロックを再度リフレッシュすることもできる。

本発明の好ましい実施形態において、スレーブノードの現在のバージョンのデータが事前にスレーブノードのスレーブメモリ領域に保存され、
図５に示すように、ステップS5において、マスタースレーブ接続関係を有する2つの上記の更新待ちのノードごとに対して、具体的に、
スレーブノードは、マスターノードから直接に送信された差分更新ファイルを取得するステップS50と、
スレーブノードは、再起動して更新モードに入るステップS51と、
差分更新ファイルに従って、スレーブメモリ領域にある現在のバージョンのデータに変化が生じた複数のスレーブ差分メモリブロックを得て、その全てのスレーブ差分メモリブロックにある現在のバージョンのデータをリフレッシュするステップS52とを含む。

具体的に、スレーブノードの更新方式が第２のタイプの方式、つまり、スレーブノードが自身の更新機能で更新を完了する更新方式である場合、マスターノードが直接に差分更新ファイルをスレーブノードに送信し、スレーブノードが差分更新ファイルに従って更新を完了する。まず、マスターノードが差分更新ファイルをスレーブノードに送信し、全てが送信された後、スレーブノードに通知し、スレーブノードが再起動して更新モードに入り、更新モードの状態で更新を行い、スレーブノードが差分更新ファイルに従ってスレーブメモリ領域にある現在のバージョンのデータに変化が生じたスレーブ差分メモリブロックを得て、且つ差分更新ファイルに従って全てのスレーブ差分メモリブロックに対してリフレッシュを実行することにより、スレーブノードの自身で更新することを実現する。

なお、第１のタイプの更新方式では、マスターノードによる送信されたのは差分ブロック更新データであり、第２のタイプの更新方式では、マスターノードによる送信されたのは差分更新ファイルであり、差分更新ファイルは差分ブロック更新データ及び各差分ブロック更新データに対応する差分ブロック識別子を含んでもいい。つまり、第１のタイプの更新方式において、マスターノードが差分更新ファイルを分析してから各差分メモリブロックに対応する差分ブロック更新データを得てターゲットを絞ったリフレッシュしてから、差分更新ファイルにある差分ブロック更新データを直接にスレーブノードにある更新が必要のためデータが変化したスレーブ差分メモリブロックに送信し、スレーブノードに直接に更新を完了させる。一方、第２のタイプの更新方式において、マスターノードが差分更新ファイルをスレーブノードに送信し、スレーブノードが差分更新ファイルを分析して、差分ブロック識別子及び差分ブロック更新データを取得し、差分ブロック識別子及び差分更新データに従ってスレーブノードのスレーブ差分メモリブロックを更新する。

さらに説明が必要なのは、バックアップバージョンデータはサーバから配信され、例えば、通常の状況では、サーバは、更新前のバージョンと更新後のバージョン間の違いである差分更新パッケージを配信し、更新されたバージョンから更新前のバージョンへの逆方向差分パッケージ、即ちバックアップのバージョンのデータも同時に配信することができる。

さらに、ステップS50を実行する前に、マスターノードがスレーブノードと接続を構築し、スレーブノードに送信要求を送信し、スレーブノードが同意要求をマスターノードにフィードバックした後、マスターノードはスレーブノードに再度直接に差分更新ファイルを送信する。

図６に示すように、本発明の好ましい実施携帯において、ステップS52は、また、
スレーブ差分メモリブロックにある現在のバージョンのデータをバックアップして、バックアップのバージョンのデータを生成することを含み、
上記のステップS52に続き、さらに、ステップS53を実行し、
ステップS53において、全てのスレーブ差分メモリブロックをリフレッシュした後、それが再び再起動の可能性を判断し、
YESであれば、プロセスを終了し、
NOであれば、バックアップのバージョンのデータに従ってスレーブ差分メモリブロックをリフレッシュする。

本発明の好ましい実施形態において、スレーブ差分メモリブロックにある現在のバージョンのデータに対してバックアップ処理する過程は、
スレーブノードのメモリリソースがプリセットされたバックアップ閾値を満たしているかどうかを判断し、
YESであれば、バックアップのバージョンのデータをスレーブメモリ領域に保存し、
NOであれば、バックアップのバージョンのデータをマスターノードのマスターメモリ領域に保存する。

具体的に、スレーブノードが自身で更新を完了する更新方式に対して、スレーブノードが再起動に失敗した時にリフレッシュすることができるために、2つ異なるバックアップロールバックメカニズムを設置することができ、即ち、差分更新ファイルに従ってスレーブノードのスレーブ差分メモリブロックをリフレッシュする前に、スレーブノードのメモリリソースがプリセットされたバックアップ閾値を満たしかどうかを判断し、YESであれば、バックアップのバージョンのデータはスレーブメモリ領域に保存され、スレーブノードが再起動に失敗した後、スレーブメモリ領域のスレーブ差分メモリブロックがスレーブメモリ領域にあるバックアップのバージョンのデータからリフレッシュされ、NOであれば、バックアップバージョンのデータはマスターノードのマスターメモリ領域に保存され、スレーブメモリ領域のスレーブ差分メモリブロックはマスターメモリ領域にあるバックアップバージョンのデータからリフレッシュされる。

本発明の好ましい実施形態において、ステップS43またはステップS52の前にともに検証ステップを含み、
検証ステップは、
差分更新ファイルのファイル検証値が現在のバージョンのデータのデータ検証値と一致しているかどうかを判断し、
YESであれば、検証に合格し、次のステップに進み、
NOであれば、検証に合格せず、プロセスを終了することを含む。

具体的に、差分更新ファイルの紛失や誤送信による更新失敗を防ぐために、リフレッシュする前に検証ステップを実行することができる。つまり、差分更新ファイルのファイル検証値が現在のバージョンデータのデータと一致しているかどうかを判断し、YESであれば、検証に合格し、差分更新ファイルが完全で正しいものと表示され、差分更新ファイルに従って更新を実行でき、NOであれば、検証に合格せず、差分更新ファイルは未送信または誤送信と表示され、今回の更新プロセスを終了する。

本発明の好ましい実施形態において、ステップS1に、ルートノードは、今回の更新に関与する更新待ちのノードがルートノードだけであると分析した時、
ステップS2において、ルートノードが再起動された後、更新モードに入り、差分更新ファイルに従って、ルートノードのルートメモリ領域にある現在のバージョンのデータに変化が生じた複数のルート差分メモリブロックを得て、その全てのルート差分メモリブロックにある現在のバージョンのデータをリフレッシュする。

具体的に、ルートノードが更新する時、サーバからダウンロードされた差分更新ファイルに従って直接フラッシュ及び復帰して、更新を完了することができる。具体的なリフレッシュプロセスは、差分更新ファイルに従って、ルートノードのルートメモリ領域にある現在のバージョンのデータに変化が生じた複数のルート差分メモリブロックを分析及び取得し、差分更新ファイルに従って全てのルート差分メモリブロックにある現在のバージョンのデータをリフレッシュする。

マスタースレーブアーキテクチャを備えたOTA差分更新システムであり、サーバと複数の更新待ちのノードを含み、複数の更新待ちのノードは一つのルートノードを含み、
図７に示すように、OTA差分更新システムは、
サーバからプリセットされ更新プランを取得し、更新プランに従って、上記の各更新待ちのノード間のマスタースレーブの接続関係及び各更新待ちのノードの更新方式を決定する取得モジュール1と、
取得モジュール1に接続され、更新プランに従ってサーバから差分更新ファイルをダウンロードするダウンロードモジュール2と、
ダウンロードモジュール2に接続され、マスタースレーブの接続関係を有する2つの上記の更新待ちのノードごとに対して、その中のスレーブノードの更新方式に従ってマスターノードの更新方式を決定する選択モジュール3と、
選択モジュール3に接続され、スレーブノードの更新方式が第１のタイプの方式か第２のタイプの方式かを判断し、対応する判断結果を生成する判断モジュール4と、
判断モジュール4とダウンロードモジュール2に接続され、判断結果はスレーブノードの更新方式が第１のタイプの方式を示す時、マスターノードをコントロールして、上記のマスターノードに上記の差分更新ファイルをリフレッシュ及び復帰させて上記のスレーブノードに送信させ、上記のスレーブノードを更新させる第１の更新モジュールと、
判断モジュール4とダウンロードモジュール2に接続され、判断結果が上記のスレーブノードの更新方式が第２のタイプの方式を示す時、マスターノードをコントロールして、差分更新ファイルをスレーブノードに直接送信させ、更新を実行する第２の更新モジュールとを含む。

具体的に、本発明はマスタースレーブアーキテクチャを備えたOTA差動更新システムを提供する。取得モジュール1、ダウンロードモジュール2、選択モジュール3、判断モジュール4、第１の更新モジュール5及び第２の更新モジュール6を介して、サーバから差分更新ファイルをダウンロードし、マスターノードに依存するか、自身の更新機能により、更新を完了する。具体的な更新プロセスは上記で説明されているため、ここでは贅言しないとする。

本発明の好ましい実施形態において、更新プランは更新シーケンス及び接続条件を含み、
取得モジュール1は、更新シーケンスに従って、今回の更新に関与する更新待ちのノード間のマスタースレーブの接続関係を決定し、
第１の更新モジュール5または第２の更新モジュール6は、今回の更新に関与するマスタースレーブの接続関係を有する2つの上記の更新待ちのノードに対して、マスターノードは、スレーブノードが対応する接続関係を満たしたかどうかを判断し、スレーブノードが接続条件を満たした場合、マスターノートとスレーブノート間の接続を構築する。

本発明の好ましい実施形態において、スレーブノードの現在のバージョンのデータは、事前にスレーブノードのスレーブメモリ領域に保存され、
図８に示すように、第１の更新モジュール5は、
マスタースレーブの接続関係を有する2つの更新待ちのノードごとに対して、マスターノードをコントロールして、差分更新ファイルを取得させてスレーブノードに送信させる第１の取得ユニット51と、
第１の取得ユニット51に接続され、マスターノードをコントロールして、マスターノードにスレーブノードの同意の旨を受信させて、その同意に従ってマスターノードと上記のスレーブノードにともに更新モードに入らせることをコントロールする第１の再起動ユニット52と、
第１の再起動ユニット52に接続され、マスターノードをコントロールして、マスターノードにマスタースレーブの接続関係に従って、スレーブノードに接続させるマスタースレーブの接続ユニット53と、
マスタースレーブの接続ユニット53に接続され、マスターノードをコントロールして、マスターノードにスレーブノードの現在のバージョンのデータを取得させてマスターノードのマスターメモリ領域に保存させる第２の取得ユニット54と、
第２の取得ユニット54に接続され、マスターノードをコントロールして、マスターノードに差分更新ファイルを分析させ、マスターメモリ領域にある現在のバージョンのデータに変化が生じた複数のマスター差分メモリブロックに対応する差分ブロック更新データを得らせる分析ユニット55と、
分析ユニット55に接続され、マスターノードをコントロールして、マスターノードに差分ブロック更新データに従って全てのマスター差分メモリブロックにある現在のバージョンのデータをリフレッシュ及び復帰させ、リフレッシュ及び復帰された更新のバージョンのデータを得らせる第１のリフレッシュユニット56と、
第１のリフレッシュユニット56に接続され、マスターノードをコントロールして、マスターノードに、差分ブロック更新データを対応するスレーブメモリ領域にある現在のバージョンのデータに変化が生じたスレーブ差分メモリブロックに送信させ、スレーブノードに更新させる送信ユニット57とを含む。

具体的に、第１の取得ユニット51、第１の再起動ユニット52、マスタースレーブの接続ユニット53、第２の取得ユニット54、分析ユニット55、第１のリフレッシュユニット56、及び送信ユニット57を介して、スレーブノードの更新方式が第１のタイプの方式である時、即ち、スレーブノードがマスターノードに依存して更新を完了する更新方式である時、マスターノードは差分ファイルをリフレッシュ及び復帰した後、対応する差分ブロック更新データをスレーブノードのスレーブ差分メモリブロックに送信し、スレーブノードに直接に更新を完了させる。

図９に示すように、本発明の好ましい実施形態において、送信ユニット57は、
マスターノードをコントロールして、マスターノードにリフレッシュ要求を生成させてスレーブノードに送信する生成部品571と、
マスターノードをコントロールして、マスターノードにスレーブノードからのリフレッシュ要求に対応する受信要求を取得させ、全ての差分更新データを対応するスレーブメモリ領域のスレーブ差分メモリブロックに送信させ、スレーブノードに更新を完了させる受信部品572と含む。

図１０に示すように、本発明の好ましい実施形態において、分析ユニット55はさらに、
マスターノードをコントロールして、マスターノードにマスター差分メモリブロックにある現在のバージョンのデータをバックアップ及び保存させ、バックアップのバージョンのデータを生成させる第１のバックアップ部品551を含み、
第１の更新モジュール5はさらに第１の判断ユニット58を含み、
第１の判断ユニット58において、マスターノードをコントロールして、マスターノードに、プリセットされた時間までにスレーブノードのバージョン番号を受信しているかどうかを判断させ、プリセットされた時間までにスレーブノードのバージョン番号が受信されてない時、差分ブロック更新データを再びスレーブノードに送信させ、再度プリセットされた時間までにスレーブノードのバージョンの番号が受信されているかどうかを判断させ、それに、送信回数がプリセットされた回数を超えた時、バックアップのバージョンのデータをスレーブノードのスレーブ差分メモリブロックに送信させる。

本発明の好ましい実施形態おいて、スレーブノードの現在のバージョンのデータがスレーブノードのスレーブメモリ領域に事前に保存され、
図１１に示すように、第２の更新モジュール6は、
スレーブノードをコントロールして、スレーブノードに、マスターノードから直接に送信された差分更新ファイルを取得させる第３の取得ユニット61と、
第３の取得ユニット61に接続され、スレーブノードをコントロールして、スレーブノードを再起動させて更新モードに入らせる第２の再起動ユニットと、
第２の再起動ユニット62に接続され、スレーブノードをコントロールして、スレーブノードに、差分更新ファイルに従ってスレーブメモリ領域にある現在のバージョンのデータに変化が生じた複数のスレーブ差分メモリブロックを得て、全てのマスター差分メモリブロックにある現在のバージョンのデータに対してリフレッシュを実行させる第２のリフレッシュユニット63とを含む。

具体的に、第３の取得ユニット61、第２の再起動ユニット62と第２のリフレッシュユニット63により、スレーブノードの更新方式が第２のタイプの更新方式である時、即ち、スレーブノードが自身の更新機能で更新を完了する更新方式である時、マスターノードが差分ファイルをスレーブノードに直接送信し、スレーブノードが差分更新ファイルに従って更新を完了する。

図１２に示すように、本発明の好ましい実施形態において、第２のリフレッシュユニット63は第２のバックアップ部品631を含み、
第２のバックアップ部品631は、第３の取得ユニット61に接続され、差分メモリブロックにある現在のバージョンのデータをバックアップ処理し、バックアップのバージョンのデータを生成する。

第２の更新モジュール6はさらに第２の判断ユニット64を含み、
第２の判断ユニット64は、第２のバックアップユニットと第２のリフレッシュユニット63に接続され、スレーブノードが再起動できるかどうかを判断し、対応する判断結果がスレーブノードが再起動できないことを表示する場合、バックアップのバージョンのデータに従って差分メモリブロックをリフレッシュする。

本発明の好ましい実施形態において、第２のバックアップ部品631はメモリ判断部品を含み、
メモリ判断部品は、スレーブノードのメモリリソースがバックアップの閾値を満たしているかどうかを判断し、対応する判断結果がバックアップの閾値を満たしていることを表示する場合、バックアップのバージョンのデータをスレーブメモリ領域に保存し、及び、対応する判断結果がバックアップの閾値を満たしてないことを表示する場合、バックアップのバージョンのデータをマスターメモリ領域に保存する。

本発明の好ましい実施形態において、取得モジュール1は、ルートノードをコントロールして、今回の更新に関与する更新待ちノードがルートノードであるかどうかを判断し、対応する判断結果を生成する判断ユニットを含み、
ダウンロード2は、判断結果が今回の更新に関与する更新待ちノードがルートノードであることを表示する場合、ルートノードをコントロールして、ルートノードに、再起動させて、更新モードに入らせ、差分更新ファイルに従って、ルートノードのルートメモリ領域にある現在のバージョンのデータに変化が生じた複数のルート差分メモリブロックを得て、全てのルート差分メモリブロックにある現在のバージョンのデータをリフレッシュさせる第４の更新ユニットを含む。

本発明の有益効果が、OTA差分更新方法及びシステムを提供し、マスタースレーブノードを利用して差分更新を実現し、マスタースレーブのアーキテクチャのメリットを十分に發揮し、リフラッシュレートをアップし、更新サイクルを短縮し、更新の安定性も確保することができる。

上記は、本発明の好ましい実施形態にすぎず、本発明の実施形態及び保護範囲を限定することを意図するものではない。当業者は、本発明の明細書及び図面に示された内容により作り出された均等の置換や明らかな変更によって得られた解決策は全て本発明の保護範囲内に含まれることを意識すべきである。
以下に、本願の当初の特許請求の範囲に記載された発明を付記する。
［１］
マスタースレーブアーキテクチャのOTA差分更新方法であり、サーバと複数の更新待ちのノードを含み、複数の更新待ちノードに一つのルートノードを含み、
上記のOTA差分更新方法は、
上記のルートノードは、上記のサーバからプリセットされた更新プランを取得し、上記の更新プランに従って各上記の更新待ちのノード間のマスタースレーブ接続関係及び各上記の更新待ちのノードの更新方式を決定するステップS1と、
上記のルートノードは、上記の更新プランに従ってサーバから差分更新ファイルをダウンロードするステップS2と、
マスタースレーブ接続関係を有する2つの更新待ちのノードごとに対して、その中のスレーブノードの更新方式によってマスターノードの処理方式を決定し、
上記のスレーブノードの更新方式が第１のタイプの方式であれば、ステップS4に進み、
上記のスレーブノードの更新方式が第２のタイプの方式であれば、ステップS5に進むステップS3と、
上記のマスターノードが上記の差分更新ファイルをリフレッシュして復帰し、上記のスレーブノードに送信して、上記のスレーブノードに更新を完了させるステップS4と、
上記のマスターノードは、上記の差分更新ファイルを上記のスレーブノードに直接送信し、更新を実行するステップS5とを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
［２］
［１］に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記の更新プランは更新シーケンス及び接続条件を含み、
上記のステップS1において、上記のルートノードは上記の更新シーケンスに従って、今回の更新に関与する上記の更新待ちのノード間のマスタースレーブ接続関係を決定する；
上記ステップS4またはステップS5において、今回の更新に関与するマスタースレーブ接続関係を有する2つの上記の更新待ちのノードに対して、上記のマスターノードは、上記のスレーブノードが対応する接続関係を満たしているか否かを判断し、上記のスレーブノードが接続条件を満たした場合、上記のマスターノードと上記のスレーブノード間の接続を構築することを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
［３］
［１］に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のスレーブノードの現在のバージョンのデータが上記のスレーブノードのスレーブメモリ領域に事前に保存されており、
上記のステップS4において、マスタースレーブ接続関係を有する2つの上記の更新待ちのノードごとに対して、具体的に、
上記のマスターノードが上記の差分更新ファイルを取得し、更新要求を上記のスレーブノードに送信するステップS40と、
上記のスレーブノードから同意の旨を受信した後、上記のマスターノードと上記のスレーブノードを制御して、同時に更新モードに入らせるステップS41と、
上記のマスターノードは、上記のマスタースレーブ接続関係によって上記のスレーブノードに接続するステップS42と、
上記のマスターノードは、上記のスレーブノードの現在のバージョンデータを取得し、それを上記のマスターノードのマスターメモリ領域に保存するステップS43と、
上記のマスターノードは、上記の差分更新ファイルを分析し、上記のマスタースメモリ領域にある現在のバージョンのデータに変化が生じた複数のマスター差分メモリブロックに対応する差分ブロック更新データを取得するステップS44と、
上記のマスターノードは差分ブロック更新データによって、全ての上記のマスター差分メモリブロックにある現在のバージョンのデータをリフレッシュ及び復帰し、リフレッシュ及び復帰された更新バージョンのデータを取得するステップS45と、
上記のマスターノードが、全ての上記の差分ブロック更新データを対応する上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じたスレーブ差分メモリブロックに送信し、上記のスレーブノードに更新を完了させるステップS46とを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
［４］
［３］に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のステップS46は、
上記のマスターノードは、リフレッシュ要求を上記のスレーブノードに送信するステップS461と、
上記のスレーブノードの上記のリフレッシュ要求に対する受信要求を受けた後、全ての上記の差分ブロック更新データを対応する上記のスレーブメモリ領域にある上記のスレーブ差分メモリブロックに送信し、上記のスレーブノードに更新を完了させるステップS462とを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
［５］
［３］に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のステップS44は、また、
上記のマスターノードは、上記のマスター差分メモリブロックにある上記の現在のバージョンのデータをバックアップと保存し、バックアップのバージョンのデータを生成し、
上記のステップS46からさらにステップS47を実行し、
ステップS47において、上記のマスターノードは、上記のスレーブノードのバージョン番号を事前設定された時間までに受信してるかどうかを判断し、
YESであれば、上記のプロセスを終了し、
NOであれば、上記の差分ブロック更新データを再度上記のスレーブノードに送信して、上記のスレーブノードのバージョン番号を事前設定された時間までに受信しているかどうかを再度判断し、送信回数が事前設定された回数を超えた場合は、上記のバックアップのバージョンのデータを上記のスレーブノードの上記のスレーブ差分メモリブロックに送信することを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
［６］
［１］に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のスレーブノードの現在のバージョンのデータは、事前に上記のスレーブメモリ領域に保存され；
上記のステップS5において、マスタースレーブ接続関係を有する2つの上記の更新待ちのノードごとに対して、具体的に、
上記のスレーブノードは、上記のマスターノードから直接に送信された上記の差分更新ファイルを取得するステップS50と、
上記のスレーブノードは、再起動して更新モードに入るステップS51と、
上記の差分更新ファイルに従って、上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のスレーブ差分メモリブロックを得て、その全ての上記のスレーブ差分メモリブロックにある現在のバージョンのデータをリフレッシュするステップS52とを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
［７］
［６］に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のステップS52は、また、
上記のスレーブ差分メモリブロックにある上記の現在のバージョンのデータをバックアップして、バックアップのバージョンのデータを生成することを含み、
上記のステップS52に続き、さらに、ステップS53を実行し、
ステップS53において、全ての上記のスレーブ差分メモリブロックをリフレッシュした後、それが再び再起動の可能性を判断し、
YESであれば、上記のプロセスを終了し、
NOであれば、上記のバックアップのバージョンのデータに従って上記のスレーブ差分メモリブロックをリフレッシュすることを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
［８］
［７］に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のスレーブ差分メモリブロックにある上記の現在のバージョンのデータに対するバックアップ処理を実行するプロセスは、
上記のスレーブノードのメモリリソースは事前設定されたバックアップ閾値を満たしているかどうかを判断し、
YESであれば、上記のバックアップのバージョンのデータを上記のスレーブメモリ領域に保存し、
NOであれば、上記のバックアップのバージョンのデータを上記のマスターノードのマスターメモリ領域に保存することを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
［９］
［３］または［６］に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のステップS43または上記のステップS52の前に検証ステップを含み、
上記の検証ステップは、
上記の差分更新ファイルのファイル検証値が上記の現在のバージョンのデータのデータ検証値と一致しているかどうかを判断し、
YESであれば、検証に合格し、次のステップに進み、
NOであれば、検証に合格せず、プロセスを終了することを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
［１０］
［１］に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のステップS1において、上記のルートノードは、今回の更新に関与する上記の更新待ちのノードが上記のルートノードだけであると分析した時、
上記のステップS2において、上記のルートノードが再起動された後、更新モードに入り、上記の差分更新ファイルに従って、上記のルートノードのルートメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のルート差分メモリブロックを得て、その全ての上記のルート差分メモリブロックにある現在のバージョンのデータをリフレッシュすることを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
［１１］
マスタースレーブアーキテクチャを備えたOTA差分更新システムであり、サーバと複数の更新待ちのノードを含み、上記の複数の更新待ちのノードは一つのルートノードを含み、
上記のOTA差分更新システムは、
上記のサーバからプリセットされ更新プランを取得し、上記の更新プランに従って、上記の各更新待ちのノード間のマスタースレーブの接続関係及び上記の各更新待ちのノードの更新方式を決定する取得モジュールと、
上記の取得モジュールに接続され、上記の更新プランに従って上記のサーバから差分更新ファイルをダウンロードするダウンロードモジュールと、
上記のダウンロードモジュールに接続され、マスタースレーブの接続関係を有する2つの上記の更新待ちのノードごとに、その中のスレーブノードの上記の更新方式に従ってマスターノードの上記の更新方式を決定する選択モジュールと、
上記の選択モジュールに接続され、上記のスレーブノードの更新方式が第１のタイプの方式か第２のタイプの方式かを判断し、対応する判断結果を生成する判断モジュールと、
上記の判断モジュールと上記のダウンロードモジュールに接続され、上記の判断結果は上記のスレーブノードの更新方式が第１のタイプの方式を示す時、上記のマスターノードをコントロールして、上記のマスターノードに上記の差分更新ファイルをリフレッシュ及び復帰させて上記のスレーブノードに送信させ、上記のスレーブノードに更新させる第１の更新モジュールと、
上記の判断モジュールと上記のダウンロードモジュールに接続され、上記の判断結果が上記のスレーブノードの更新方式が第２のタイプの方式を示す時、上記のマスターノードをコントロールして、上記のマスターノードに上記の差分更新ファイルを上記のスレーブノードに直接送信させ、更新を実行する第２の更新モジュールとを含むことを特徴とするマスタースレーブアーキテクチャを備えたOTA差分更新システム。
［１２］
［１１］に記載のマスタースレーブアーキテクチャを備えたOTA差分更新システムにおいて、上記の更新プランは更新シーケンス及び接続条件を含み、
上記の取得モジュールは、上記の更新シーケンスに従って、今回の更新に関与する上記の更新待ちのノード間のマスタースレーブの接続関係を決定し、
上記の第１の更新モジュールまたは上記の第２の更新モジュールは、今回の更新に関与するマスタースレーブの接続関係を有する2つの上記の更新待ちのノードに対して、上記のマスターノードは、上記のスレーブノードが対応する接続関係を満たしたかどうかを判断し、上記のスレーブノードが上記の接続条件を満たす場合、上記のマスターノートと上記のスレーブノート間の接続を構築することを特徴とするマスタースレーブアーキテクチャを備えたOTA差分更新システム。
［１３］
［１１］に記載のマスタースレーブアーキテクチャを備えたOTA差分更新システムにおいて、上記のスレーブノードの現在のバージョンのデータは、事前に上記のスレーブノードのスレーブメモリ領域に保存され、
上記の第１の更新モジュールは、
マスタースレーブの接続関係を有する2つの上記の更新待ちのノードごとに対して、上記のマスターノードをコントロールして、上記のマスターノードに上記の差分更新ファイルを取得させて上記のスレーブノードに送信させる第１の取得ユニットと、
上記の第１の取得ユニットに接続され、上記のマスターノードをコントロールして、上記のマスターノードに上記のスレーブノードの同意の旨を受信させて、その同意に従って上記のマスターノードと上記のスレーブノードにともに更新モードに入らせることをコントロールする第１の再起動ユニットと、
上記の第１の再起動ユニットに接続され、上記のマスターノードをコントロールして、上記のマスタースレーブの接続関係に従って、上記のマスターノードに上記のスレーブノードに接続させるマスタースレーブの接続ユニットと、
上記のマスタースレーブの接続ユニットに接続され、上記のマスターノードをコントロールして、上記のマスターノードに上記のスレーブノードの現在のバージョンのデータを取得させて上記のマスターノードのマスターメモリ領域に保存させる第２の取得ユニットと、
上記の第２の取得ユニットに接続され、上記のマスターノードをコントロールして、上記の差分更新ファイルを分析させ、上記のマスターメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のマスター差分メモリブロックに対応する差分ブロック更新データを得らせる分析ユニットと、
上記の分析ユニットに接続され、上記のマスターノードをコントロールして、上記の差分ブロック更新データによって全ての上記のマスター差分メモリブロックにある上記の現在のバージョンのデータをリフレッシュ及び復帰させ、リフレッシュ及び復帰された更新のバージョンのデータを得らせる第１のリフレッシュユニットと、
第１のリフレッシュユニットに接続され、上記のマスターノードをコントロールして、全ての上記の差分ブロック更新データを対応する上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じたスレーブ差分メモリブロックに送信させ、上記のスレーブノードに更新させる送信ユニットとを含むことを特徴とするマスタースレーブアーキテクチャを備えたOTA差分更新システム。
［１４］
［１１］に記載のマスタースレーブアーキテクチャを備えたOTA差分更新システムにおいて、上記のスレーブノードの現在のバージョンのデータが事前に上記のスレーブノードのスレーブメモリ領域に保存され、
上記の第２の更新モジュールは、
上記のスレーブノードをコントロールして、上記のスレーブノードに上記のマスターノードから直接に送信された上記の差分更新ファイルを取得させる第３の取得ユニットと、
上記の第３の取得ユニットに接続され、上記のスレーブノードを再起動させて更新モードに入らせる第２の再起動ユニットと、
上記の第２の再起動ユニットに接続され、上記のスレーブノードをコントロールして、上記の差分更新ファイルに従って、上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のスレーブ差分メモリブロックを得て、全ての上記のマスター差分メモリブロックにある現在のバージョンのデータに対してリフレッシュを実行させる第２のリフレッシュユニットとを含むことを特徴とするマスタースレーブアーキテクチャを備えたOTA差分更新システム。
［１５］
［１１］に記載のマスタースレーブアーキテクチャを備えたOTA差分更新システムにおいて、上記の取得モジュールは、上記のルートノードをコントロールして、この更新に関与する上記の更新待ちのノードが上記のルートノードだけであるかどうかを分析させ、対応する判断結果を生成させる判断ユニットを含み、
上記のダウンロードモジュールは、上記の判断結果はこの更新に関与する上記の更新待ちのノードが上記のルートノードだけであることを示す時、上記のルートノードを再起動させ、更新モードに入らせ、上記の差分更新ファイルに従って、上記のルートノードのルートメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のルート差分メモリブロックを得て、全ての上記のルート差分メモリブロックにある現在のバージョンのデータをリフレッシュさせる第４の更新ユニットを含むことを特徴とするマスタースレーブアーキテクチャを備えたOTA差分更新システム。

Claims (15)

1. マスタースレーブアーキテクチャのOTA差分更新方法であり、サーバと複数の更新待ちのノードを含み、複数の更新待ちノードに一つのルートノードを含み、
   上記のOTA差分更新方法は、
   上記のルートノードは、上記のサーバからプリセットされた更新プランを取得し、上記の更新プランに従って各上記の更新待ちのノード間のマスタースレーブ接続関係及び各上記の更新待ちのノードの更新方式を決定するステップS1と、
   上記のルートノードは、上記の更新プランに従ってサーバから差分更新ファイルをダウンロードするステップS2と、
   マスタースレーブ接続関係を有する2つの更新待ちのノードごとに対して、その中のスレーブノードの更新方式によってマスターノードの処理方式を決定し、
   上記のスレーブノードの更新方式が第１のタイプの方式であれば、ステップS4に進み、
   上記のスレーブノードの更新方式が第２のタイプの方式であれば、ステップS5に進むステップS3と、
   上記のマスターノードが上記の差分更新ファイルをリフレッシュして復帰し、上記のスレーブノードに送信して、上記のスレーブノードに更新を完了させるステップS4と、
   上記のマスターノードは、上記の差分更新ファイルを上記のスレーブノードに直接送信し、更新を実行するステップS5とを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
2. 請求項１に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記の更新プランは更新シーケンス及び接続条件を含み、
   上記のステップS1において、上記のルートノードは上記の更新シーケンスに従って、今回の更新に関与する上記の更新待ちのノード間のマスタースレーブ接続関係を決定する；
   上記ステップS4またはステップS5において、今回の更新に関与するマスタースレーブ接続関係を有する2つの上記の更新待ちのノードに対して、上記のマスターノードは、上記のスレーブノードが対応する接続関係を満たしているか否かを判断し、上記のスレーブノードが接続条件を満たした場合、上記のマスターノードと上記のスレーブノード間の接続を構築することを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
3. 請求項１に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のスレーブノードの現在のバージョンのデータが上記のスレーブノードのスレーブメモリ領域に事前に保存されており、
   上記のステップS4において、マスタースレーブ接続関係を有する2つの上記の更新待ちのノードごとに対して、具体的に、
   上記のマスターノードが上記の差分更新ファイルを取得し、更新要求を上記のスレーブノードに送信するステップS40と、
   上記のスレーブノードから同意の旨を受信した後、上記のマスターノードと上記のスレーブノードを制御して、同時に更新モードに入らせるステップS41と、
   上記のマスターノードは、上記のマスタースレーブ接続関係によって上記のスレーブノードに接続するステップS42と、
   上記のマスターノードは、上記のスレーブノードの現在のバージョンデータを取得し、それを上記のマスターノードのマスターメモリ領域に保存するステップS43と、
   上記のマスターノードは、上記の差分更新ファイルを分析し、上記のマスターメモリ領域にある現在のバージョンのデータに変化が生じた複数のマスター差分メモリブロックに対応する差分ブロック更新データを取得するステップS44と、
   上記のマスターノードは差分ブロック更新データによって、全ての上記のマスター差分メモリブロックにある現在のバージョンのデータをリフレッシュ及び復帰し、リフレッシュ及び復帰された更新バージョンのデータを取得するステップS45と、
   上記のマスターノードが、全ての上記の差分ブロック更新データを対応する上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じたスレーブ差分メモリブロックに送信し、上記のスレーブノードに更新を完了させるステップS46とを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
4. 請求項３に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のステップS46は、
   上記のマスターノードは、リフレッシュ要求を上記のスレーブノードに送信するステップS461と、
   上記のスレーブノードの上記のリフレッシュ要求に対する受信要求を受けた後、全ての上記の差分ブロック更新データを対応する上記のスレーブメモリ領域にある上記のスレーブ差分メモリブロックに送信し、上記のスレーブノードに更新を完了させるステップS462とを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
5. 請求項３に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のステップS44は、また、
   上記のマスターノードは、上記のマスター差分メモリブロックにある上記の現在のバージョンのデータをバックアップと保存し、バックアップのバージョンのデータを生成し、
   上記のステップS46からさらにステップS47を実行し、
   ステップS47において、上記のマスターノードは、上記のスレーブノードのバージョン番号を事前設定された時間までに受信してるかどうかを判断し、
   YESであれば、メソッドを終了し、
   NOであれば、上記の差分ブロック更新データを再度上記のスレーブノードに送信して、上記のスレーブノードのバージョン番号を事前設定された時間までに受信しているかどうかを再度判断し、送信回数が事前設定された回数を超えた場合は、上記のバックアップのバージョンのデータを上記のスレーブノードの上記のスレーブ差分メモリブロックに送信することを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
6. 請求項３に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のスレーブノードの現在のバージョンのデータが上記のスレーブノードのスレーブメモリ領域に事前に保存されており；
   上記のステップS5において、マスタースレーブ接続関係を有する2つの上記の更新待ちのノードごとに対して、具体的に、
   上記のスレーブノードは、上記のマスターノードから直接に送信された上記の差分更新ファイルを取得するステップS50と、
   上記のスレーブノードは、再起動して更新モードに入るステップS51と、
   上記の差分更新ファイルに従って、上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のスレーブ差分メモリブロックを得て、その全ての上記のスレーブ差分メモリブロックにある現在のバージョンのデータをリフレッシュするステップS52とを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
7. 請求項６に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のステップS52は、また、
   上記のスレーブ差分メモリブロックにある上記の現在のバージョンのデータをバックアップして、バックアップのバージョンのデータを生成することを含み、
   上記のステップS52に続き、さらに、ステップS53を実行し、
   ステップS53において、全ての上記のスレーブ差分メモリブロックをリフレッシュした後、それが再び再起動の可能性を判断し、
   YESであれば、メソッドを終了し、
   NOであれば、上記のバックアップのバージョンのデータに従って上記のスレーブ差分メモリブロックをリフレッシュすることを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
8. 請求項７に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のスレーブ差分メモリブロックにある上記の現在のバージョンのデータに対するバックアップ処理を実行するプロセスは、
   上記のスレーブノードのメモリリソースは事前設定されたバックアップ閾値を満たしているかどうかを判断し、
   YESであれば、上記のバックアップのバージョンのデータを上記のスレーブメモリ領域に保存し、
   NOであれば、上記のバックアップのバージョンのデータを上記のマスターノードのマスターメモリ領域に保存することを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
9. 請求項６に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のステップS43または上記のステップS52の前に検証ステップを含み、
   上記の検証ステップは、
   上記の差分更新ファイルのファイル検証値が上記の現在のバージョンのデータのデータ
   検証値と一致しているかどうかを判断し、
   YESであれば、検証に合格し、次のステップに進み、
   NOであれば、検証に合格せず、プロセスを終了することを含むことを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
10. 請求項１に記載のマスタースレーブアーキテクチャのOTA差分更新方法において、上記のステップS1において、上記のルートノードは、今回の更新に関与する上記の更新待ちのノードが上記のルートノードだけであると分析した時、
    上記のステップS2において、上記のルートノードが再起動された後、更新モードに入り、上記の差分更新ファイルに従って、上記のルートノードのルートメモリ領域にある現在のバージョンのデータに変化が生じた複数のルート差分メモリブロックを得て、その全ての上記のルート差分メモリブロックにある現在のバージョンのデータをリフレッシュすることを特徴とするマスタースレーブアーキテクチャのOTA差分更新方法。
11. マスタースレーブアーキテクチャを備えたOTA差分更新システムであり、サーバと複数の更新待ちのノードを含み、上記の複数の更新待ちのノードは一つのルートノードを含み、
    上記のOTA差分更新システムは、
    上記のサーバからプリセットされ更新プランを取得し、上記の更新プランに従って、上記の各更新待ちのノード間のマスタースレーブの接続関係及び上記の各更新待ちのノードの更新方式を決定する取得モジュールと、
    上記の取得モジュールに接続され、上記の更新プランに従って上記のサーバから差分更新ファイルをダウンロードするダウンロードモジュールと、
    上記のダウンロードモジュールに接続され、マスタースレーブの接続関係を有する2つの上記の更新待ちのノードごとに、その中のスレーブノードの上記の更新方式に従ってマスターノードの上記の更新方式を決定する選択モジュールと、
    上記の選択モジュールに接続され、上記のスレーブノードの更新方式が第１のタイプの方式か第２のタイプの方式かを判断し、対応する判断結果を生成する判断モジュールと、
    上記の判断モジュールと上記のダウンロードモジュールに接続され、上記の判断結果は上記のスレーブノードの更新方式が第１のタイプの方式を示す時、上記のマスターノードをコントロールして、上記のマスターノードに上記の差分更新ファイルをリフレッシュ及び復帰させて上記のスレーブノードに送信させ、上記のスレーブノードに更新させる第１の更新モジュールと、
    上記の判断モジュールと上記のダウンロードモジュールに接続され、上記の判断結果が上記のスレーブノードの更新方式が第２のタイプの方式を示す時、上記のマスターノードをコントロールして、上記のマスターノードに上記の差分更新ファイルを上記のスレーブノードに直接送信させ、更新を実行する第２の更新モジュールとを含むことを特徴とするマスタースレーブアーキテクチャを備えたOTA差分更新システム。
12. 請求項１１に記載のマスタースレーブアーキテクチャを備えたOTA差分更新システムにおいて、上記の更新プランは更新シーケンス及び接続条件を含み、
    上記の取得モジュールは、上記の更新シーケンスに従って、今回の更新に関与する上記の更新待ちのノード間のマスタースレーブの接続関係を決定し、
    上記の第１の更新モジュールまたは上記の第２の更新モジュールは、今回の更新に関与するマスタースレーブの接続関係を有する2つの上記の更新待ちのノードに対して、上記のマスターノードは、上記のスレーブノードが対応する接続関係を満たしたかどうかを判断し、上記のスレーブノードが上記の接続条件を満たす場合、上記のマスターノードと上記のスレーブノード間の接続を構築することを特徴とするマスタースレーブアーキテクチャを備えたOTA差分更新システム。
13. 請求項１１に記載のマスタースレーブアーキテクチャを備えたOTA差分更新システムにおいて、上記のスレーブノードの現在のバージョンのデータは、事前に上記のスレーブノードのスレーブメモリ領域に保存され、
    上記の第１の更新モジュールは、
    マスタースレーブの接続関係を有する2つの上記の更新待ちのノードごとに対して、上記のマスターノードをコントロールして、上記のマスターノードに上記の差分更新ファイルを取得させて上記のスレーブノードに送信させる第１の取得ユニットと、
    上記の第１の取得ユニットに接続され、上記のマスターノードをコントロールして、上記のマスターノードに上記のスレーブノードの同意の旨を受信させて、その同意に従って上記のマスターノードと上記のスレーブノードにともに更新モードに入らせることをコントロールする第１の再起動ユニットと、
    上記の第１の再起動ユニットに接続され、上記のマスターノードをコントロールして、上記のマスタースレーブの接続関係に従って、上記のマスターノードに上記のスレーブノードに接続させるマスタースレーブの接続ユニットと、
    上記のマスタースレーブの接続ユニットに接続され、上記のマスターノードをコントロールして、上記のマスターノードに上記のスレーブノードの現在のバージョンのデータを取得させて上記のマスターノードのマスターメモリ領域に保存させる第２の取得ユニットと、
    上記の第２の取得ユニットに接続され、上記のマスターノードをコントロールして、上記の差分更新ファイルを分析させ、上記のマスターメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のマスター差分メモリブロックに対応する差分ブロック更新データを得らせる分析ユニットと、
    上記の分析ユニットに接続され、上記のマスターノードをコントロールして、上記の差分ブロック更新データによって全ての上記のマスター差分メモリブロックにある上記の現在のバージョンのデータをリフレッシュ及び復帰させ、リフレッシュ及び復帰された更新のバージョンのデータを得らせる第１のリフレッシュユニットと、
    第１のリフレッシュユニットに接続され、上記のマスターノードをコントロールして、全ての上記の差分ブロック更新データを対応する上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じたスレーブ差分メモリブロックに送信させ、上記のスレーブノードに更新させる送信ユニットとを含むことを特徴とするマスタースレーブアーキテクチャを備えたOTA差分更新システム。
14. 請求項１１に記載のマスタースレーブアーキテクチャを備えたOTA差分更新システムにおいて、上記のスレーブノードの現在のバージョンのデータが事前に上記のスレーブノードのスレーブメモリ領域に保存され、
    上記の第２の更新モジュールは、
    上記のスレーブノードをコントロールして、上記のスレーブノードに上記のマスターノードから直接に送信された上記の差分更新ファイルを取得させる第３の取得ユニットと、
    上記の第３の取得ユニットに接続され、上記のスレーブノードを再起動させて更新モードに入らせる第２の再起動ユニットと、
    上記の第２の再起動ユニットに接続され、上記のスレーブノードをコントロールして、上記の差分更新ファイルに従って、上記のスレーブメモリ領域にある上記の現在のバージョンのデータに変化が生じた複数のスレーブ差分メモリブロックを得て、全ての上記のスレーブ差分メモリブロックにある現在のバージョンのデータに対してリフレッシュを実行させる第２のリフレッシュユニットとを含むことを特徴とするマスタースレーブアーキテクチャを備えたOTA差分更新システム。
15. 請求項１１に記載のマスタースレーブアーキテクチャを備えたOTA差分更新システムにおいて、上記の取得モジュールは、上記のルートノードをコントロールして、この更新に関与する上記の更新待ちのノードが上記のルートノードだけであるかどうかを分析させ、対応する判断結果を生成させる判断ユニットを含み、
    上記のダウンロードモジュールは、上記の判断結果はこの更新に関与する上記の更新待ちのノードが上記のルートノードだけであることを示す時、上記のルートノードを再起動させ、更新モードに入らせ、上記の差分更新ファイルに従って、上記のルートノードのルートメモリ領域にある現在のバージョンのデータに変化が生じた複数のルート差分メモリブロックを得て、全ての上記のルート差分メモリブロックにある現在のバージョンのデータをリフレッシュさせる第４の更新ユニットを含むことを特徴とするマスタースレーブアーキテクチャを備えたOTA差分更新システム。

Images