JP4680896B2 - ネットワーク装置およびこの種の装置のスタートアップを監視するための方法 - Google Patents

Description

本発明は、ネットワーク装置およびこの種の装置のソフトウェアスタートアップを監視するための方法に関する。

ＤＳＬモデム、ブリッジまたはルータまたはその組み合わせのようなスタンドアローン形ネットワーキング装置は例えばローカルエリアネットワークをインターネットのようなアクセスネットワークと取り持つために使用される。

一般に、スタンドアローン形装置はリード・オンリーメモリ（ＲＯＭ）および／または電気的に消去可能なプログラマブルリード・オンリーメモリ（ＥＥＰＲＯＭ）のような永続メモリ、すなわちいわゆるオンボードメモリ手段を有している。このメモリはとりわけ、スタートアップを開始しかつ装置コンフィギュレーションパラメータ、立ち上げ、すなわちブートソフトウエアおよびファームウェアのような装置を実行するために必要であるデータおよびソフトウェアを含んでいる。

スタートアップを保証するために、スタンドアローン形装置には上述したアイテムのいくつかの２つのコピー、すなわち装置コンフィギュレーション、ブートソフトウェアおよびファームウェアを含んでいるものがある。しかしモデムのいくつかはこれらデータシングルコピーを格納するのがやっとである大きさの永続メモリを有してさえいればよい。

その場合、これらのデータが歪みを受けているとすれば、装置は当然機能するのをやめかつ永続メモリは新しい有効なファームウェアまたはコンフィギュレーションまたはブートプログラムをリカバーする。

この状況は例えば、モデムが適当なサーバーからアプグレードなソフトウェアをダウンロードするとき起こる可能性がある。永続メモリはソフトウェアのワンコピーしか保持することができないので、古いソフトウェアは更新されたソフトウェアが完全に記録される前に消去される。コネクションが遮断されるまたは装置がダウンロードの期間にパワーダウンすると、ソフトウェアは歪みを受ける。

従ってソフトウェアまたはハードウェア不足もしくは欠如のために装置はパワーアップフェーズまたは再立ち上げの期間に自動的に停止に至る可能性がある。

このような場合、装置は通例当然機能するのを停止しかつＬＥＤインジケータによりエンドユーザに問題状態を通知する。

例えばＵＳ６５２６０９２からモデムがホストパーソナルコンピュータに通じている電話線を介して更新されたオペレーティングコードをダウンロードしかつホストパーソナルコンピュータからシリアルポートを介してモデムのメモリをリプログラミングできるようにすることが公知である。

本発明は、ローカルネットワークに接続するためのネットワーク装置であって、ネットワークは少なくとも１つのソフトウェアサーバを有しており、この装置はソフトウエアを記憶するための１つの永続メモリを有している形式のものにおいて、
− ネットワークに接続するための通信手段を備え、
− ソフトウェア故障を検出するための装置のスタートアップを監視するための手段を備え、
− 該監視手段による故障の検出に応答してソフトウェア故障信号を生成しかつネットワーク上に故障の通報を自動的に送信するための手段を備え、ここで該通報は少なくとも１つのソフトウェアサーバによって受信されるようにネットワーク上に同報される
ことを特徴とするネットワーク装置を提供する。

従ってユーザは、サーバが必要ありと決定しない限りは、故障手直し過程に介入する必要はない。有利には、サーバは故障タイプを解析するためおよび正しい処置（アクション）を自動的にとるためのアプリケーションを有している。

殊に、本発明の有利な実施形態によれば、故障がソフトウェアスタートアップ故障であるとき、故障信号を生成するための手段は、ソフトウェアサーバからリプレースメントソフトウェアをメモリ手段に自動的にダウンロードするよう要求するのに適している。

従って、この実施形態の永続メモリは１つのソフトウェアコピーだけを保持していればよくかつソフトウェアまたはデータの２つのコピーを保持している装置と同レベルのロバスト性を有している。

有利には、ソフトウェアダウンロードはいずれの遅延もなく行われる。

本発明はまた、ネットワーク装置がソフトウエアを記憶するための１つの永続メモリと、少なくとも１つのソフトウェアサーバを有しているネットワークに接続するための通信手段とを有しているという、ネットワーク装置のソフトウェアスタートアップを監視するための方法であって、この監視過程は次のステップを有している：
− ソフトウェアスタートアップ故障を検出するために装置のソフトウェアスタートアップを監視し、
− スタートアップソフトウェア故障の検出に応答してソフトウェアスタートアップ故障信号を生成し、
− 少なくとも１つのソフトウェアサーバに受信されるようにするためにソフトウェア故障信号をネットワーク上に自動的に同報する
方法を提供する。

本発明の思想は以下の詳細だが、それに制限されているわけではない本発明の実施例の説明およびを各図を参照して考察することによって容易に理解することができる。その際
図１は本発明の実施例のネットワーク装置を含んでいるシステムのブロック線図を示し、
図２は図１のシステムに使用されるのに適しておりかつ本発明の実施例の原理に従っている処理方法のフローチャートを略示し、
図３は図２に示されている方法をより詳しく説明するフローチャートを略示している。

図１には本発明の実施例のスタンドアローン形装置１が組み込まれているシステムのブロック線図が示されている。

このネットワーク装置１はデータ転送通信を処理することができるいずれかのデバイスから成っている。それは例えばＤＳＬタイプのモデムまたは別のスタンドアローン形のネットワーク装置であってよい。装置はローカルエリアネットワーク２に接続されており、ネットワークにはサーバ３および／または故障処理アプリケーション（図示なし）を備えてるデバイスに接続されている。

ネットワーク装置１は電気的に消去可能なプログラマブルリードオンリーメモリ（Electrically Erasable Programmable Read Only Memory＝ＥＥＰＲＯＭ）のような永続的オンボードメモリ手段４を備えている。この永続メモリは複数のアイテムを保持している。この実施例によれば、それはその他のデータとともに、装置のスタートアップおよび機能のために必要なソフトウェアプログラム、例えば装置コンフィギュレーションパラメータ５、立ち上げ、すなわちブートソフトウエア６およびファームウェア７を記憶している。

装置コンフィギュレーション５はとりわけ、モデムのシリアルナンバーおよびネットワークアドレスを含んでいるパラメータのセットである。

ファームウェア７はアプリケーションレベルソフトウェアによって消去可能ではないメモリに書き込まれている、すなわち所定のプロテクションを有しているいずれかのソフトウェアから成っている。この実施例において、ファームウェアは例えばモデムのオペレーティングシステムを有している。以下に示すように、ファームウェアはダウンロードによって大域的に置換されることもできるが、ファームウェアは独特なアイテムを有していてもよく、かつ本発明は大容量ダウンロードに制限されておらず、その範囲は個別のアイテムのテストおよびダウンロードも含んでいる。

実際には、スタンドアローン形装置１は、分かり易くするために示されていないが、種々のプログラムを実行するマイクロプロセッサのようなデータ処理ユニットおよび非永続メモリも有している。実行の前に、永続メモリに記憶されているソフトウェアは非永続メモリ（例えばＲＡＭ）にコピーされる。

スタンドアローン形装置はオンボードメモリ手段４と、ネットワーク２に接続されているネットワーク通信手段９との間にデータ転送モジュール８も有している。

この転送モジュール８は例えば標準化されたブートストラップ・プロトコル（ＢＯＯＴＰ）、およびローカルエリアネットワーク２を介してサーバ３と装置１との間で情報交換するためのファイルトランスファプロトコル（ＴＦＴＰ）を使用することができる。装置はこの実施例によればＤＳＬモデムであるので、相応のＰＳＴＮインタフェースおよびそのＤＳＬ機能を実行するための関連回路も有している。これらのアイテムはそれ自体よく知られているので、図１には示されていない。

モジュール８および１０は具体化実現された、つまりインプリメンテド・ハードウェアかまたは非永続メモリからマイクロプロセッサによって実行されるソフトウェアモジュールであってよい。

本発明によれば、スタンドアローン形装置１は装置のソフトウェアのスタートアップを制御することができる監視手段も有している。

これら監視手段１０は、とりわけ、ファームウェア７の妥当性、存在および正しいスタートアップおよびコンフィギュレーションデータ５の妥当性をチェックする。永続メモリにおけるブートソフトウエアコピーのチェックも可能であるが、詳しい説明はしないものとする。

殊にスタートアッププロセスの期間に何らかの問題がある場合、これら監視手段１０はファームウェアスタートアップ故障信号を生成する。これは転送モジュール８および通信手段９によってデータ伝送ネットワーク２を介してソフトウェアサーバ３に伝送される。

ソフトウェアサーバ３に知らされるこの故障信号はサーバによってリプレースメントファームウェアのダウンロードのＢＯＯＴＰ要求に関連付けられる。この故障信号を送出するために使用されるＢＯＯＴＰプロトコルのフレーム部分はダウンロードされるべきソフトウェアの種類かまたは適当な故障信号を特定する。このフレーム部分は例えば、ＢＯＯＴＰプロトコルの「ベンダ専有オプショナルフィールド」であってよい。

ソフトウェアサーバ３で示されている、データ転送ネットワーク２におけるアプリケーションは、プログラムコードおよびリプレースメントソフトウェアおよび／またはコンフィギュレーションデータが記憶されているデータベースを維持しているものとする。

このＢＯＯＴＰ要求に応答して、このサーバ３はリプレースメントソフトウェアをネットワーク装置に、転送モジュール８および通信手段９のＴＦＴＰプロトコルを使用してネットワーク２を介して転送する。

実際には、ＢＯＯＴＰメッセージは、過程については以下に詳細に説明するが、装置の複数の故障状態を有している。ローカルエリアネットワーク上のその他のデバイスはこれらの状態を解釈しかつ正しい処置を決定しようとする。処置は典型的にはリプレースメントソフトウェアのダウンロードを含んでいるが、ユーザに対する故障情報の通報を含んでいてもよい。

有利には、監視手段１０はボタン１１に関連付けられるようにすることができる。ボタンはユーザによって手動で操作されて、ネットワークを介するファームウェアおよび／またはブートソフトウエアのダウンロードの要求がトリガされるようにすることができる。

有利には、ユーザにスタートアップ故障を通報するために監視手段１０に視認または音響警報１２が接続されている。

図２には、この実施例による、スタンドアローン形装置１のスタートアッププロセスお簡素化されたバージョンが示されている。図示のステップは主に、妥当性のテストに関しかつ例えばメモリ４におけるファームウェア７のようなソフトウェアを表している。

スタンドアローン形装置１のパワーオン時に（ステップ２０）、監視手段１０は装置１のスタートアップのために必要なファームウェアに関するファームウェアテストステップ２１を開始する。このテストステップの期間に問題が検出されなければ、監視手段１０はステップ２２において、ファームウェアがオンボードメモリ手段４に記憶されているかどうかをチェックする。

ファームウェアが見つからなければ、監視手段１０はスタートアップ故障信号Ｆを生成し、かつ装置１を再度立ち上げする。

ステップ２３において、テストステップ２１が成功裡に実行されないならば、監視手段１０は、伝送モジュール８および通信手段９のＢＯＯＴＰプロトコルを使用して、伝送ネットワークネット２を介してソフトウェアサーバ３からリプレースメントファームウェアのダウンロードを要求する。

ステップ２４において、ソフトウェアサーバ３は、転送モジュール８および通信手段９のＴＦＴＰプロトコルを使用して、転送ネットワークネット２を介してリプレースメントファームウェアをダウンロードする。

ステップ２５において、監視手段１０はダウンロードが正しく行われるように制御する。例えばダウンロードが中断されたとき、監視手段１０は固有のファームウェア故障信号Ｆ（故障のタイプの識別を含んでいる）を生成し、かつ装置１を再立ち上げするので、新しいダウンロードが開始されるようになる。

テストが正しく実行されるならば、監視手段１０はステップ２６において、ファームウェアをロードしかつスタートアップ故障フラグおよびタイマーをセットしてスタートアップタイムリミットが決定されるようにする。このフラグは、ファームウェアがスタートアップを正しく実行した場合にファームウェアによってリセットされる。スタートアップタイムリミットが過ぎたのにソフトウェアスタートアップが完了していない場合、フラグは依然セットされたままで、かつ監視手段１０はソフトウェアスタートアップ故障信号Ｆ（これも故障のタイプの識別を含んでいるが、上に述べた第１の故障タイプとは別のものである）を生成し、かつ装置１を再立ち上げする。その他の場合、ステップ２７において、ソフトウェアスタートアップが正しく実行されたとき、それはソフトウェアスタートアップフラグをリセットしかつ故障信号は生成されない。

有利にも、この実施例によれば、ネットワークネット装置１はファームウェアスタートアップ故障またはファームウェア不在の場合にリプレースメントファームウェアの自動的なリクエストおよび自動的なダウンロードを行う。従って、例えばスタートアップ故障は自動的に修復されかつユーザは故障の存在に気付きもしない。

殊に、図３のブロック線図には本発明の実施例によるスタンドアローン形装置のスタートアップ過程の詳細が示されている。

過程は、ネットワーク装置に対するパワーオン状態が起動されたときステップ３０においてに始まる。それから図３の過程は、よく知られているＢＯＯＴＰおよびＴＦＴＰプロトコルを使用して、監視手段１０によって実行される。

ステップ３１において、初期テストが実行される。典型的には、監視手段１０は永続メモリ４のアベイラビリティおよび非永続メモリの適正な動作をチェックする。

ステップ３２において、有利にはおよびこの実施例によれば、装置コンフィギュレーション故障があるかどうかまたはエンドユーザが操作ボタン１１を押圧してソフトウェアダウンロードを要求しているかどうかの検出が行われる。

これらの状況の１つが生じると、監視手段１０はステップ３３にジャンプし、オンボードメモリ手段４に記憶されているコンフィギュレーションデータの妥当性を制御する。

装置コンフィギュレーション５はしばしば、サインまたはチェックサムによってセキュリティが施されている。このサインまたはチェックサムは装置１のオンボードメモリ手段４に登録されている。装置コンフィギュレーションの妥当性を制御するための従来の簡単な手法は、そのチェックサムを再計算しかつそれを登録されているものと比較することである。整合しなければ、装置コンフィギュレーション５はもはや妥当ではない。この場合、監視手段１０は相応の故障フラグ３４をセットアップする。

有利には、このフラグ３４は生じている故障のタイプについての情報を伝えるように符号化されている。この場合、故障フラグ３４は装置コンフィギュレーション故障の存在を指示する情報状態を有している。

コンフィギュレーションデータのタイプに依存して、コンフィギュレーションデータ故障はダウンロードにより手直し可能のこともあるし手直し可能でないこともある。後者の場合、装置によって発生されるＢＯＯＴＰメッセージは、当該装置がもはや使用され得ずかつデッドとして考察されるべきであることを指示するものとして、他のネットワークによって解釈される。

コンフィギュレーションがステップ３３において妥当であるならば、このことはエンドユーザがボタン１１を押圧してファームウェアのダウンロードをトリガしたことを意味している。従って、監視手段１０はソフトウェアスタートアップ故障フラグ３５をセットもする。この故障フラグ３５はユーザがファームウェアのダウンロードを要求したことを特定する。

ダウンロードが要求されずかつ装置コンフィギュレーション問題が生じない場合、監視手段１０はステップ３２の後、ステップ３６の期間に、オンボードメモリ手段４に登録されているファームウェアプログラム７の妥当性をチェックする。

それを行う最も簡単な手法は、その検証パターン（フラッシュ検証パターンの場合はＦＶＰ＝Flash Verification Pattern）の存在および妥当性を制御することである。検証パターンはソフトウェアまたはデータの完全性をチェックするための従来よりのツールである。ファームウェアが永続メモリ４に首尾よく記録されているとき、検証パターンが計算されかつメモリ４に書き込まれもする。装置阿ファームウェアの記憶期間にパワー故障または別の問題を蒙っているならば、このファームウェアに相応する検証パターンは記憶されていないかまたは誤っている。

それ故に、ステップ３６において、監視手段１０はファームウェア検証パターンを用いてファームウェアの妥当性をチェックする。パターンが妥当でなければ、故障フラグ３７がセットされる。別のテストステップの場合のように、この特別な故障フラグは故障の性質つまりその内容を指示している。

ステップ３８において、監視手段１０は故障フラグ３４、３５、３７のセッティング状態をチェックする。少なくとも１つのフラグがセットされているならば、監視手段１０は自動的に、転送モジュール８および通信手段９のＢＯＯＴＰプロトコルを使用して転送ネットワーク２を介して故障信号をサーバ３に送信する。このメッセージは故障フラグ状態を含んでいる。

ソフトウェアサーバ３のアプリケーションのような、ネットワークデバイスにまとめられているアプリケーションはこれらの信号に注意しかつ故障状態情報を解釈する。この情報の解釈の後、これらのアプリケーションは、有利にはいずれのエンドユーザの介入もなしに、ネットワーク装置１に対するファームウェアダウンロードの少なくとも１つのスタートを有しているおよび／またはユーザへ問題を通報する処置を行う決定をする。通報は、例えば重大なコンフィギュレーション故障の発生の場合、故障の是正が可能ではなくなった後にユーザに通報される。この目的のために試行のカウンタがインプリメントされかつ例えばファームウェアダウンロードを要求するそれぞれのＢＯＯＴＰメッセージの後に漸次的にインクリメントされるようにするとよい。

殊に、伝送モジュール８は問題状態を監視手段１０によってネットワークに送信された適当なＢＯＯＴＰプロトコルメッセージの「ベンダオプショナル専用フィールド」において指示する。このフィールドはアプリケーション確定制限または付加的なクライアント情報を通信するために標準的に使用されるものである。

換言すれば、メッセージは有利には予め定めたサーバに限ってではなく、ネットワーク上に同報される。ネットワーク上のデバイスのいずれか１つは、それがそのメッセージに注意し、解析しかつ応答するための正当なアプリケーションを有しているならば、サーバとして動作するようであってもよい。

そのダウンロードの後、リプレースメントファームウェアは永続性のオンボードメモリ手段４に記憶される。このステップは参照番号３９を有している。

ステップ４０において、監視手段１０はリプレースメントソフトウェアがいずれの中断もなくダウンロードされかつそれが正しく記録されるように制御する。

ダウンロードされるソフトウェアがファームウェアであるとき、データ処理ユニットはリプレースメントファームウェアをチェックしかつそのフラッシュな検証パターン（flash verification pattern）を計算しかつそれをステップ４１でメモリ４に記録する。

リプレースメントソフトウェアがダメージを受けているまたは正しくダウンロードされないまたは正しく記録されなかったならば、監視手段１０は相応の故障フラグ４２をセットする。それから、スタンドアローン形装置１は再度立ち上げられる。勿論、フラグは再立ち上げ過程によって影響されないような仕方で記憶される。ステップ３１において、デバイスはフラグ４２がセットされているかどうかをテストしかつ相応のＢＯＯＴＰメッセージを送信してファームウェアがダウンロードされるようにする。

ステップ４３において、ステップ３８において故障フラグが検出されなかった場合、監視手段１０はオンボードメモリ手段４におけるファームウェアの存在を制御する。この存在をチェックするために使用可能な種々の方法がある。例えば、ファームウェアの存在はファームウェアコードの固定のロケーションにおける特定の識別コードの検出によりチェックすることができる。本発明によればその他の方法も使用することができる。

ソフトウェアが登録されていなければ、監視手段１０は故障フラグ４４をセットしかつモデムはステップ３０において再度立ち上げられて、上述のセットされたフラグに基づいて故障が処理されるようにする。

ステップ４１またはステップ４３が何の問題もなく実行されたならば、監視手段１０はスタートアップフラグをセットしかつ、ステップ４６においてファームウェアをロードしかつスタートする前に、スタートタイマーをトリガする。

成功したスタートアップの後、ファームウェアによってスタートアップフラグがリセットされ、それが正しくスタートしたことを確認する。しかしスタート時間が経過終了する前にスタートアップが実行されなかったならば、監視手段１０は問題フラグ４８をセットしかつステップ３０において装置を再度立ち上げて相応の故障が処理されるようにする。

要約すると、図３の過程は５つの問題状態を定義している：
− ソフトウェア（ファームウェア）スタートアップエラー：ファームウェアはスタートアップか再立ち上げの期間に正しくスタートアップすることなくて停止する；
− 不当なコンフィギュレーション；
− 失敗したソフトウェア（ファームウェア）ダウンロード（例えばダウンロード過程の中断）；
− ソフトウェアの不在；
− ダウンロードされたソフトウェアの、永続メモリに対する書き込み失敗（検証パターン不正）。

その他の状態はソフトウェアのダウンロードをトリガすることができる：
− デバイスの機械的なボタンがユーザにより押圧されてファームウェアのダウンロードが要求される；
− ファームウェアはネットワークを介してファームウェア更新を実行するようにという要求を受信する。

フラグは立ち上げ過程の開始時、またはその実行期間に監視手段によってチェックされる。ダウンロードは明示的に要求することができるまたはダウンロードに関する決定がデバイスメッセージに注意するアプリケーションに任されるようになっている。

本発明はここまで説明してきた有利な実施例に限定されておらず、いずれの種類のソフトウェアまたはデータをダウンロードすることができる。そしてこの過程はＴＦＴＰおよびＢＯＯＴＰプロトコルとは異なっているプロトコルによって実行することもできる。

本発明の実施例のネットワーク装置を含んでいるシステムのブロック線図 図１のシステムに使用されるのに適しておりかつ本発明の実施例の原理に従っている処理方法のフローチャート 図２に示されている方法をより詳しく説明するフローチャート

Claims (18)

1. ローカルネットワークに接続するためのネットワーク装置であって、
   前記ローカルネットワークは少なくとも１つのソフトウェアサーバを有しており、
   前記ネットワーク装置はソフトウエアを記憶するための１つの永続メモリを有している形式のものにおいて、
   前記ローカルネットワークに接続するための通信手段を備え、
   ソフトウェアスタートアップ故障を検出するため、前記ネットワーク装置のスタートアップを監視するための手段を備え、
   該監視手段によるスタートアップ故障の検出に応答してソフトウェアスタートアップ故障信号を生成しかつローカルネットワーク上に前記ソフトウェアスタートアップ故障の通報を自動的に送信するための手段を備え、
   ここで該通報は前記少なくとも１つのソフトウェアサーバによって受信されるように前記ローカルネットワーク上に同報される
   ことを特徴とするネットワーク装置。
2. 前記故障信号は、
   故障の性質もしくはその内容、
   ダウンロードされるべきリプレースメントソフトウェアの識別、
   永続メモリに現在記憶されているソフトウェアのバージョンの識別
   の少なくとも１つを特定するための情報を有している請求項１記載の装置。
3. ソフトウェアは、
   ブートプログラム、
   コンフィギュレーションデータ、
   ファームウェア
   の少なくとも１つを有している請求項１または２記載の装置。
4. ソフトウェアはファームウェアを有しており、
   スタートアップを監視するための手段は
   現在のファームウェア検証パターンの妥当性をチェックするための手段を備え、および
   前記検証パターンが妥当ではないときに特定のソフトウェアスタートアップ故障信号を生成するための手段を備えている
   請求項３記載の装置。
5. スタートアップを監視するための手段は
   現在のソフトウェアのチェックサムを計算するための手段を備え、
   前記計算されたチェックサムを予め記憶されているチェックサムと比較するための手段を備え、
   前記計算されたチェックサムが記憶されているものと一致しないときにスタートアップ故障信号を生成するための手段を備えている
   請求項１記載の装置。
6. 前記メモリはファームウェアを有しており、
   スタートアップを監視するための手段は
   前記メモリにおけるファームウェアの存在をチェックするための手段を備え、
   前記メモリにファームウェアが記憶されていないときにスタンドアローン形装置を再度立ち上げるための手段を備え、
   前記メモリにファームウェアが記憶されていないときにソフトウェアスタートアップ故障信号を生成するための手段を備えている
   請求項３記載の装置。
7. スタートアップを監視するための手段は
   リプレースメントソフトウェアの、前記メモリへのダウンロードをチェックするための手段を備え、
   前記ダウンロードの期間に問題が検出されたとき、当該装置を再度立ち上げるための手段およびソフトウェアスタートアップ故障信号を生成するための手段を備えている
   請求項１から６までのいずれか１項記載の装置。
8. ソフトウェアはファームウェアを有しており、かつ
   当該装置は
   リプレースメントファームウェアが前記メモリに適正に記録されたとき、ダウンロードされたリプレースメントファームウェアに相応してリプレースメント検証パターンを前記メモリに書き込むための手段を備えている
   請求項３、４または７のいずれか１項記載の装置。
9. スタートアップを監視するための手段は
   ソフトウェアをロードする過程を監視するための手段を備え、
   前記ロードする過程に問題が生じたときに、スタンドアローン形装置を再度立ち上げるための手段およびソフトウェアスタートアップ故障信号を生成するための手段を備えている
   請求項１から８までのいずれか１項記載の装置。
10. ソフトウェアスタートアップを監視するための手段は
    スタートアップタイムリミットを検出するためのタイマーを備え、
    ソフトウェアスタートアップを開始させるための手段を備え、該ソフトウェアはスタートアップの完了後の、前記監視手段に対するスタートアップ終了指示に適合しており、
    タイムリミットの終了前にスタートアップが完了しなかった場合に、ソフトウェアスタートアップ故障信号を生成するための手段を備えている
    請求項１から９までのいずれか１項記載の装置。
11. 当該装置は更に監視手段に接続されている、ユーザがリプレースメントソフトウェアのダウンロードを手動で要求できるようにするためのユーザ処置可能な手段を有している
    請求項１から１０までのいずれか１項記載の装置。
12. 当該装置は更に監視手段に接続されている、スタートアップ故障をユーザに通報するためのアラームを有している
    請求項１から１１までのいずれか１項記載の装置。
13. ソフトウェアスタートアップ故障信号を生成するための手段は
    故障フラグのセットを監視するための手段を備え、
    セットされた故障フラグの検出に応答してソフトウェア故障信号を生成しかつ該ソフトウェア故障信号をローカルネットワーク上に伝送するための手段を備えている
    請求項１から１２までのいずれか１項記載の装置。
14. 故障の性質もしくは内容の指示は一連の状態フラグを有している
    請求項１から１３までのいずれか１項記載の装置。
15. 前記通報は更に永続メモリに現在記憶されているソフトウェアのバージョンの識別を有している
    請求項１４記載の装置。
16. ネットワーク装置がソフトウエアを記憶するための１つの永続メモリと少なくとも１つのソフトウェアサーバを有しているローカルネットワークに接続するための通信手段とを有しているという、ネットワーク装置のソフトウェアスタートアップを監視するための方法であって、
    該方法は、
    ソフトウェアスタートアップ故障を検出するために前記ネットワーク装置のソフトウェアスタートアップを監視し、
    ソフトウェアスタートアップ故障の検出に応答してソフトウェアスタートアップ故障信号を生成し、
    前記少なくとも１つのソフトウェアサーバに受信されるようにするためにソフトウェアスタートアップ故障信号を前記ローカルネットワーク上に自動的に同報する
    ステップを有している方法。
17. ソフトウェアスタートアップ故障信号はリプレースメントソフトウェアを前記メモリにダウンロードするようにする、少なくとも１つのソフトウェアサーバに対する要求を有している
    請求項１６記載の方法。
18. ソフトウェアスタートアップ故障信号は前記少なくとも１つのソフトウェアサーバによって解析されるための、故障の識別を有している
    請求項１６記載の方法。

Images