(57)【特許請求の範囲】
【請求項１】
複数のアプリケーションが、システムソフトウェアのデバイスドライバを介してハードウェアを構成する複数の物理デバイスを利用すると共に、前記アプリケーションおよびハードウェアに対するＲＡＳ機能を実装する、ＲＡＳ機能を備える組み込み機器において、
前記システムソフトウェアと前記ハードウェア間に介在させたハイパーバイザ層内に、前記複数のアプリケーションおよびハードウェアのＲＡＳ機能を統合して一元管理する、論理ＲＡＳ機能部を実装し、
前記論理ＲＡＳ機能部は、前記複数の物理デバイスを所定個数に分類した論理デバイスに対する論理デバイス異常検出ロジックを備え、
前記論理デバイス異常検出ロジックは、
前記システムソフトウェアのブートローダからの前記物理デバイスの初期化時および前記システムソフトウェアのＯＳのデバイスドライバからのアクセス時に起動され、前記論理デバイスに対する異常検出診断を実行することを特徴とするＲＡＳ機能を備える組み込み機器。
【請求項２】
前記論理デバイス異常検出ロジックからの異常検出情報を取得し、前記ハードウェアの物理デバイスの異常を検出する異常検出処理手段と、
前記論理デバイス異常検出ロジックからの異常検出情報と、前記アプリケーションの異常検出情報とを統合化して異常処理を実行する、統合化異常対応処理ロジックと、
前記統合化異常対応処理ロジックからの異常対応情報に基づいて前記ハードウェアの物理デバイスの異常対応処理を実行する異常対応処理手段と、
を備えることを特徴とする請求項１に記載のＲＡＳ機能を備える組み込み機器。
【請求項３】
前記論理ＲＡＳ機能部は、前記複数のアプリケーションに対応した論理ウォッチドッグタイマ群およびソフトウェア処理異常検出ロジックを備え、
前記論理ウォッチドッグタイマ群は、前記複数のアプリケーションに実装された定周期リセット要求手段からのリセット要求によりリセットされることにより前記複数のアプリケーションを監視し、
タイムアップした論理ウォッチドッグタイマ情報を前記ソフトウェア処理異常検出ロジックに出力し、
前記ソフトウェア処理異常検出ロジックは、前記統合化異常対応処理ロジックに対して異常対応処理を依頼することを特徴とする請求項２に記載のＲＡＳ機能を備える組み込み機器。
【請求項４】
前記統合化異常対応処理ロジックは、前記ソフトウェア処理異常検出ロジックからの異常情報を取得したときに、前記システムソフトウェアのアプリケーション管理手段に通知して対応処理を依頼することを特徴とする請求項３に記載のＲＡＳ機能を備える組み込み機器。
【請求項５】
前記統合化異常対応処理ロジックは、夫々複数種類が定義された異常個所に対する異常レベルと異常対応処理に基づき、異常発生箇所に対し異常レベルと異常対応処理の対応付けを設定すると共に、デバイス・ソフトウェアの依存関係および複合的な異常対応処理を設定することを特徴とする請求項２乃至４のいずれかに記載のＲＡＳ機能を備える組み込み機器。
【請求項６】
前記論理ＲＡＳ機能部は、前記論理デバイス異常検出ロジックに対するデバイス定周期診断用タイマおよび前記ハードウェアに設けたウォッチドッグタイマに対する物理ウォッチドッグタイマリセット手段を備えることを特徴とする請求項１乃至５のいずれかに記載のＲＡＳ機能を備える組み込み機器。
【請求項７】
前記論理デバイス異常検出ロジックおよび前記論理ウォッチドッグ用タイマに対して論理ＲＡＳ機能設定情報を与える第１データベースと、
前記論理デバイス異常検出ロジックおよび前記ソフトウェア処理異常検出ロジックに対して過去の異常履歴情報を与える第２データベースと、
を備える請求項３または４に記載のＲＡＳ機能を備える組み込み機器。
【請求項８】
前記統合化異常対応処理ロジックの異常処理内容は、前記第２データベースの異常履歴に記録されることを特徴とする請求項７に記載のＲＡＳ機能を備える組み込み機器。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、複数のアプリケーションが、システムソフトウェアのデバイスドライバを介してハードウェアを構成する複数の物理デバイスを利用すると共に、前記アプリケーションおよびハードウェアに対するＲＡＳ機能を実装する、ＲＡＳ機能を備える組み込み機器に関するものである。
【背景技術】
【０００２】
ＲＡＳ（ Reliability Availability Serviceability）は、システムの信頼性、可用性、および保守性、の独立した意味を持つ３つの機能を合わせた概念であり、組み込み機器への実装は周知の技術である。特許文献１には、コンピュータシステムにバス接続されたＲＡＳ機能付きインターフェースによって、コンピュータに接続されるデバイスの異常を監視する技術が開示されている。
【０００３】
ＲＡＳ機能は、コンピュータシステムが障害で停止することを極力防止することを目的に、システムの監視、異常の早期発見、故障状態の判断、および短時間での修理回復を提供する機能を指す。ＲＡＳ機能は、以下のような機能を提供する。
【０００４】
（１）システムの異常監視
（ａ）アプリケーションを動作させるために必要なハードウェアの動作監視。
（ｉ）アプリケーションが直接使用するハードウェアの監視。例えば、ＣＰＵ、Ｓ            ＤＲＡＭ、ＣＦカード、シリアル通信の動作監視など。
（ｉｉ）ハードウェアの動作に悪影響を及ぼす環境の監視。例えば、電源バッテリ            の電圧、電流、周囲温度、塵埃、腐食度の監視など。
（ｂ）ウォッチドッグタイマ(Watch Dog Timer、以下ＷＤＴ)による、ソフトウェアの動作監視。
（２）異常時の、システムの動作状態の記録。
（３）システム異常時の対応処理。例えば、Ｉ／Ｏデバイスの再起動、システムの停止な      ど。
【０００５】
図１０は、従来のＲＡＳ機能を備える組み込み機器の構成例を示す機能ブロック図であり、ハードウェア１００、システムソフトウェア２００、アプリケーションソフトウェア３００を基本構成要素として備える。
【０００６】
ハードウェア１００は、ＣＰＵを含む複数の物理デバイス群１０１を含む。システムソフトウェア２００は、ブートローダ２１０とＯＳ２２０を含む。アプリケーションソフトウェア３００は、物理デバイスを使用するアプリケーション３０１〜３０Ｎを含む。
【０００７】
初期化時診断プログラム２１３は、ブートローダ２１０が持つデバイスドライバＡ２１１に実装され、デバイス初期化手段２１２で起動されるハードウェアの初期化を行う際に物理デバイスの診断処理を実行する。
【０００８】
初期化時診断プログラム２１３は、初期化時診断が必要な物理デバイスごとに固有の診断処理を行う。異常検出時は、異常対応処理プログラムＡ２１４により、初期化時診断に対応する異常対応処理を実行する。
【０００９】
ＯＳ２２０が持つデバイスドライバＢ２２１に実装された使用時異常検出プログラム２２３は、物理デバイスを使用するアプリケーション３０１〜３０Ｎからの要求を受ける物理デバイス使用時にアクセス手段２２２により起動され、アプリケーションが物理デバイスを使用するタイミングでの異常検出処理を実行する。異常検出時は、異常対応処理プログラムＢ２２４により、デバイス使用時診断に対応する異常対応処理を実行する。
【００１０】
ＯＳ２２０が持つデバイスドライバＢ２２１に実装される定周期診断プログラム２３１は、ＯＳ２２０に実装されているタイマ２３０により定周期で起動され、アプリケーションが直接使用しない、もしくは使用頻度の低い物理デバイスに対して定周期診断が必要な物理デバイスごとに固有の診断処理を実行する。異常検出時は、異常対応処理プログラムＣ２３２により、異常対応処理を実行する。
【００１１】
デバイスドライバＢ２２１は、ハードウェア１００に実装されているＷＤＴ１０２にアクセスするためのＷＤＴドライバ２４０を備えている。
【００１２】
ハードウェア１００に実装されている物理ＷＤＴ１０２は、ＷＤＴドライバ２４０を介して監視対象アプリケーション３１０の監視機能を実現するために実装されている。物理ＷＤＴ１０２は、監視対象となるアプリケーション３１０自身に実装されるＷＤＴリセット手段３１０Ａにより、ＷＤＴドライバ２４０を介して定周期でリセットされる。
【００１３】
次に、動作の概要を説明する。ＲＡＳ機能は、組み込み機器を構成するハードウェア、およびアプリケーションについて動作状態を診断、監視することで、システムに対して信頼性、確実性を向上させる機能を提供する。
【００１４】
診断、監視により異常が検出された場合、異常が発生した物理デバイス、アプリケーションとその異常の程度に応じて、個別に実装された対応処理を行う。ＲＡＳ機能は、以下に示す４つのタイミング（１）〜（４）で動作する。
【００１５】
（１）システム立ち上げ時の物理デバイス初期化時におけるハードウェアの診断は、時間のかかる診断や、システムがオンライン状態であるときに行うとシステムに悪影響を及ぼす診断(例えば、メモリの全領域ゼロクリアなど)を実行する。
【００１６】
初期化時診断処理は、ブートローダ２１０のデバイスドライバに実装される初期化診断プログラム２１３で実行される。ブートローダ２１０は、立ち上げ時に診断が必要なデバイスに対して、各物理デバイス個別に実装された初期化時診断処理を行う。異常が検出された際は、検出された異常の箇所と程度に応じて、異常処理対応プログラムＡ２１４で個別に異常対応処理を行う。
【００１７】
（２）アプリケーションが物理デバイスを使用する時に実行されるハードウェアの診断は、システムがオンライン状態であるため、システムに悪影響を及ぼさない診断に限られる。
【００１８】
使用時異常検出処理は、ＯＳ２２０に組み込まれるデバイスドライバＢ２２１に実装される使用時異常検出プログラム２２３により実行される。アプリケーションから物理デバイスへのアクセスがあると、デバイスドライバＡ２２１はアプリケーションがアクセスする各物理デバイスに対して個別に使用時異常検出処理を行う。異常が検出された際は、検出された異常の箇所と程度に応じて、異常処理対応プログラムＢ２２４で個別に異常対応処理を行う。
【００１９】
（３）定周期によるハードウェアの動作環境の診断は、アプリケーションからの使用頻度が低いデバイスや、システムに対して悪影響を及ぼす周囲環境について一定周期で診断を行う。
【００２０】
定周期診断処理は、ＯＳ２２０が持つタイマ２３０により、一定周期でデバイスドライバ２２１に実装された定周期診断処理プログラム２３１を呼び出し、各物理デバイスや環境センサ(温度センサなど)を診断する。異常が検出された際は、検出された異常の箇所と程度に応じて、異常処理対応プログラムＣ２３２で個別に異常対応処理を行う。
【００２１】
（４）ソフトウェアの動作監視は、アプリケーションが正常に動作しているかどうかを、ハードウェア１００に実装された物理ＷＤＴ１０２を用いて監視処理を行う。ＯＳは、ＷＤＴドライバ２４０より提供される。ＷＤＴを用いた監視処理の実現手段となるＷＤＴリセット手段３１０Ａは、監視対象となるアプリケーション３１０自身に実装される。
【００２２】
アプリケーション３１０は、ＷＤＴドライバ２４０を介して、一定周期で物理ＷＤＴ１０２のカウンタをリセットする。アプリケーション３１０に異常が発生し物理ＷＤＴ１０２のリセットが行われなくなると、物理ＷＤＴ１０２はタイムアップし、ハードウェアの強制的リセットなどハードウェアによる対応処理が行われる。
【先行技術文献】
【特許文献】
【００２３】
【特許文献１】特開２００９−０１５４７２号公報
【発明の概要】
【発明が解決しようとする課題】
【００２４】
従来構成のＲＡＳ機能を備える組み込み機器では、次のような問題がある。
（１）ＲＡＳ機能は、システムに散在して実装される。ＲＡＳ機能は、同じ物理デバイスに対する診断であっても、必要とされる診断のタイミングや診断の内容によって処理が異なる。
【００２５】
そのため、ＲＡＳ機能を呼び出すブートローダやＯＳなどのシステムソフトウェアの各種モジュールは、各々固有のＲＡＳ機能を実装する必要がある。これにより、ＲＡＳ機能はモジュール間で一部機能が重複する場合も個別に開発され、各々のモジュールに散在して実装される。
【００２６】
（２）ＲＡＳ機能は、搭載される組み込み機器専用の機能として、機器ごとに実装される。
ＲＡＳ機能に対する要求は、各々の機器の使用目的や運用方針によって異なる。具体的には、機器に搭載される物理デバイスが異なれば、監視対象とする物理デバイスや異常検出および対応の処理が異なる。
【００２７】
また、異常検出された場合の対応処理は、異常部分を分離してシステムの動作を実行する(稼働率を重視する運用)、小さな異常でも検出されれば即時停止する(安全性を重視する運用)、など運用方針によっても異なる。
【００２８】
ＲＡＳ機能の実装は、機種(物理デバイスのハードウェア仕様)に依存する。異常検出や異常対応処理の処理手順が同じであっても、物理デバイス毎にアクセス手続きが異なるため、実装される処理は異なるものになる。
【００２９】
（３）ＷＤＴを用いたアプリケーションの監視では、監視対象、および対応処理が制限される。ハードウェアが提供する１つのＷＤＴを用いたアプリケーション監視の対象は、１つのアプリケーション処理に限られる。ＷＤＴにより監視対象のアプリケーションの異常が検出された場合、対応処理はＣＰＵのリセットなど、ハードウェアによる対応処理に限られる。
【００３０】
（４）異常が検出された際の対応処理が、その検出箇所だけに限られたものとなる。異常検出処理は、各物理デバイスで個別に実装されるため、複合的に発生した異常を検知することができない。
【００３１】
異常対応処理は各物理デバイスの異常検出処理に対応し、ハードウェアの仕様に依存して個別に実装されるため、複数のハードウェアおよびソフトウェアに対する統合的な異常対応処理を行うことができない。
【００３２】
本発明の目的の第１は、課題（１）の問題を解決し、ブートローダ、ＯＳ、およびアプリケーションがＲＡＳ機能にできる限り依存しない構成を実現する。このとき、ＲＡＳ機能を一箇所にまとめて実装することにより、ＲＡＳ機能の信頼性、確実性の向上を図ることにある。
【００３３】
本発明の目的の第２は、課題（２）の問題を解決し、ＲＡＳ機能を搭載する組み込み機器の機種に依存しない共通の枠組みを用いてＲＡＳ機能に対する要求を満たすことにある。
【００３４】
本発明の目的の第３は、課題（３）の問題を解決し、複数のアプリケーションについての監視を可能にすると共に、各々のアプリケーションについて異常検出時の対応処理を個別に規定することを可能にすることにある。
【００３５】
本発明の目的の第４は、課題（４）の問題を解決し、複合的に発生した異常への対応処理を行う、統合的な異常対応処理機能を実現することにある。
【課題を解決するための手段】
【００３６】
このような課題を達成するために、本発明は次の通りの構成になっている。
複数のアプリケーションが、システムソフトウェアのデバイスドライバを介してハードウェアを構成する複数の物理デバイスを利用すると共に、前記アプリケーションおよびハードウェアに対するＲＡＳ機能を実装する、ＲＡＳ機能を備える組み込み機器において、
前記システムソフトウェアと前記ハードウェア間に介在させたハイパーバイザ層内に、前記複数のアプリケーションおよびハードウェアのＲＡＳ機能を統合して一元管理する、論理ＲＡＳ機能部を実装し、
前記論理ＲＡＳ機能部は、前記複数の物理デバイスを所定個数に分類した論理デバイスに対する論理デバイス異常検出ロジックを備え、
前記論理デバイス異常検出ロジックは、
前記システムソフトウェアのブートローダからの前記物理デバイスの初期化時および前記システムソフトウェアのＯＳのデバイスドライバからのアクセス時に起動され、前記論理デバイスに対する異常検出診断を実行することを特徴とするＲＡＳ機能を備える組み込み機器。
【００３８】
（２）前記論理デバイス異常検出ロジックからの異常検出情報を取得し、前記ハードウェアの物理デバイスの異常を検出する異常検出処理手段と、
前記論理デバイス異常検出ロジックからの異常検出情報と、前記アプリケーションの異常検出情報とを統合化して異常処理を実行する、統合化異常対応処理ロジックと、
前記統合化異常対応処理ロジックからの異常対応情報に基づいて前記ハードウェアの物理デバイスの異常対応処理を実行する異常対応処理手段と、
を備えることを特徴とする（１）に記載のＲＡＳ機能を備える組み込み機器。
【００３９】
（３）前記論理ＲＡＳ機能部は、前記複数のアプリケーションに対応した論理ウォッチドッグタイマ群およびソフトウェア処理異常検出ロジックを備え、
前記論理ウォッチドッグタイマ群は、前記複数のアプリケーションに実装された定周期リセット要求手段からのリセット要求によりリセットされることにより前記複数のアプリケーションを監視し、
タイムアップした論理ウォッチドッグタイマ情報を前記ソフトウェア処理異常検出ロジックに出力し、
前記ソフトウェア処理異常検出ロジックは、前記統合化異常対応処理ロジックに対して異常対応処理を依頼することを特徴とする（２）に記載のＲＡＳ機能を備える組み込み機器。
【００４０】
（４）前記統合化異常対応処理ロジックは、前記ソフトウェア処理異常検出ロジックからの異常情報を取得したときに、前記システムソフトウェアのアプリケーション管理手段に通知して対応処理を依頼することを特徴とする（３）に記載のＲＡＳ機能を備える組み込み機器。
【００４１】
（５）前記統合化異常対応処理ロジックは、夫々複数種類が定義された異常個所に対する異常レベルと異常対応処理に基づき、異常発生箇所に対し異常レベルと異常対応処理の対応付けを設定すると共に、デバイス・ソフトウェアの依存関係および複合的な異常対応処理を設定することを特徴とする（２）乃至（４）のいずれかに記載のＲＡＳ機能を備える組み込み機器。
【００４２】
（６）
前記論理ＲＡＳ機能部は、前記論理デバイス異常検出ロジックに対するデバイス定周期診断用タイマおよび前記ハードウェアに設けたウォッチドッグタイマに対する物理ウォッチドッグタイマリセット手段を備えることを特徴とする（１）乃至（５）のいずれかに記載のＲＡＳ機能を備える組み込み機器。
【００４３】
（７）前記論理デバイス異常検出ロジックおよび前記論理ウォッチドッグ用タイマに対して論理ＲＡＳ機能設定情報を与える第１データベースと、
前記論理デバイス異常検出ロジックおよび前記ソフトウェア処理異常検出ロジックに対して過去の異常履歴情報を与える第２データベースと、
を備える（３）または（４）に記載のＲＡＳ機能を備える組み込み機器。
【００４４】
（８）前記統合化異常対応処理ロジックの異常処理内容は、前記第２データベースの異常履歴に記録されることを特徴とする（７）に記載のＲＡＳ機能を備える組み込み機器。
【発明の効果】
【００４５】
本発明によれば、次のような効果を期待することができる。
（１）ＲＡＳ機能を論理ＲＡＳ機能部で統合的に提供することにより、ＲＡＳ機能の一元管理を実現できる。従来、個々のアプリケーションに散在していた処理を、ハイパーバイザ層の論理ＲＡＳ機能部へ一元化することで、物理デバイスを使用する上位層のアプリケーションに対する修正を減らし、ＲＡＳ機能の実装を容易にできる環境を実現することができる。
【００４６】
（２）物理デバイスを機能的に分類された論理デバイスに抽象化することで、機種ごとの差分を吸収できる。ＲＡＳ機能の実装が必要な物理デバイスを、図２のテーブル１に示す５種類の論理デバイスに抽象化し、物理デバイスの差に依存しない論理デバイスの論理機能に対するＲＡＳ機能を提供することで、ＲＡＳ機能を個々の機種専用に実装する必要がなくなる。
【００４７】
各物理デバイスに対するＲＡＳ機能を、論理デバイスの論理ロジックと物理デバイス固有の処理に切り分けることで、診断ロジックの共通化と物理デバイス固有処理の一元化を図ることができる。
【００４８】
抽象化した５種類の論理デバイスに対するＲＡＳ機能へ単純化させたことにより、ＯＳやＲＯＭモニタなどの仕組みを必要とすることなく、ＲＡＳ機能をハイパーバイザ層で実現することが可能となる。
【００４９】
（３）論理ＷＤＴ群により、複数のアプリケーション処理の監視を実現することができる。論理ＲＡＳ機能部により複数の論理ＷＤＴ群を提供することにより、複数のアプリケーション処理について監視を行うことができる。
【００５０】
統合化異常対応処理ロジックとの組み合わせにより、ハードウェアのリセット以外にもきめ細かな異常対応処理を行うことができる。また、論理ＷＤＴ群をハイパーバイザ層で実現することにより、ソフトウェアタイマの信頼性に影響するソフトウェアを僅かな部分に限定することができる。
【００５１】
（４）統合化異常対応処理ロジックにより、複合的な異常対応処理を実現することができる。異常発生箇所に対する異常のレベルとして、図２のテーブル３に示す３種類の異常レベルを定義し、これに対応付ける異常対応処理項目を図２のテーブル４に示す４種類に統一することで、異常対応処理ロジックの共通化と物理デバイス固有処理の一元化を行うことができる。
【００５２】
異常個所に対する異常レベルと異常対応処理項目の組み合わせにより、きめ細かな異常対応処理が行える。また、異常レベルと異常対応処理の種類を限定して処理を単純化することにより、ＲＡＳ機能をハイパーバイザ層で実現することが可能となる。更に、異常対応処理を統合化することにより、依存関係をもつ複数のデバイスおよびアプリケーションに対して複合的な異常対応処理を行うことができる。
【図面の簡単な説明】
【００５３】
【図１】本発明を適用したＲＡＳ機能を備えた組み込み機器の一実施例を示す機能ブロック図である。
【図２】論理ＲＡＳ設定情報を示すテーブル１乃至テーブル４である。
【図３】論理ＲＡＳ設定情報を示すテーブル５乃至テーブル８および過去の異常履歴例を示すテーブル９、異常時のシステム状態例を示すテーブル１０である。
【図４】物理デバイス初期化処理における異常検出ロジックへの遷移を示すフローチャートである。
【図５】物理デバイスへのアクセスから異常検出ロジックへの遷移を示すフローチャートである。
【図６】論理デバイスに対する異常検出ロジックの動作を示すフローチャートである。
【図７】ソフトウェア処理監視と異常検出ロジックの動作を示すフローチャートである。
【図８】統合された異常対応ロジックの動作を示すフローチャートである。
【図９】異常対応処理項目検索の動作を示すフローチャートである。
【図１０】従来のＲＡＳ機能を備えた組み込み機器の構成例を示す機能ブロック図である。
【発明を実施するための形態】
【００５４】
以下本発明を、図面を用いて詳細に説明する。図１は、本発明を適用したＲＡＳ機能を備えた組み込み機器の一実施例を示す機能ブロック図である。図１０で説明した従来構成と同一要素には同一符号を付して説明を省略する。
【００５５】
図１において、アプリケーションソフトウェア４００のアプリケーション４０１、４０２、４０３、４０４は、システムソフトウェア５００のデバイスドライバを介してハードウェア１００の物理デバイス群１０１を利用する。
【００５６】
本発明の構成上の特徴は、システムソフトウェア５００のブートローダ５１０及びＯＳ５２０とハードウェア１００との間にハイパーバイザ層６００を介在させ、このハイパーバイザ層に実装した論理ＲＡＳ機能部６２０により、アプリケーションソフトウェアおよびハードウェアのＲＡＳ機能を一元管理する仕組みを提供した点にある。
【００５７】
以下、本発明の論理ＲＡＳ機能に関連する要素の構成と動作を説明する。ハイパーバイザ層６００内の物理デバイス中継インタフェース６１０は、システムソフトウェア５００を経由した物理デバイス群１０１へのアクセスを監視し、必要なタイミングに応じて論理ＲＡＳ機能を実行させるための機能ブロックであり、以下に述べる２種類のインタフェース（１）及び（２）を、物理デバイスを使用する上位層のソフトウェアへ提供する。
【００５８】
（１）物理デバイス初期化インタフェース６１１：
物理デバイスを初期化する際に使用するインタフェースであり、物理デバイスの初期化において異常が発生した場合、論理ＲＡＳ機能の実行へ遷移する。図４は、物理デバイス初期化処理における異常検出ロジックへの遷移を示すフローチャートである。
【００５９】
ステップＳ１の処理開始で、システムソフトウェア５００のブートローダ５１０における各種デバイスドライバ５１１内のデバイス初期化ドライバ５１２からの信号ｃを物理デバイス初期化インタフェース６１１が取得して、ステップＳ２でハードウェア１００の物理デバイス群１０１に初期化信号ｋを出力する。
【００６０】
ステップＳ３のチェックで初期化時に異常が発生した場合は、信号ｊを後述する論理デバイス異常検出ロジック６２１に送りステップＳ４で異常検出ロジックを実行させ、ステップＳ５で物理デバイス初期化処理を終了する。ステップＳ３のチェックで初期化時に異常が発生ない場合は、ステップＳ５にスキップして物理デバイス初期化処理を終了する。
【００６１】
（２）物理デバイスアクセスインタフェース６１２：
アプリケーションが物理デバイスへアクセスする際に使用するインタフェースである。アプリケーション４０１、４０２、４０３からの物理デバイス使用要求ａが、ソフトウェア５００内のＯＳ５２０が備える各種デバイスドライバ５１１で受け付けられると、デバイスアクセス手段５２１より使用要求信号ｅが物理デバイスアクセスインタフェース６１２に送信され、デバイスごとに決められたタイミングで論理ＲＡＳ機能部６２０の実行へ遷移する。
【００６２】
図５は、物理デバイスへのアクセスから異常検出ロジックへの遷移を示すフローチャートである。ステップＳ１で要求信号ｅが物理デバイスアクセスインタフェース６１２に送信され、ステップＳ２で物理デバイスへのアクセスが開始されるが、事前のチェックステップＳ３でアクセスを行う前に異常検出が必要な場合には、信号ｈを論理デバイス異常検出ロジック６２１に出力して異常検出を実行させた後、信号ｌを物理デバイス群１０１に出力し、ステップＳ５で物理デバイスに対して要求された処理を実行する。
【００６３】
チェックステップＳ３で、異常検出が必要ない場合には、ステップＳ４をスキップして信号ｌを物理デバイス群１０１に出力し、ステップＳ５で物理デバイスに対して要求された処理を実行する。
【００６４】
更に、チェックステップＳ６でアクセスを行った後に異常検出が必要な場合には、信号ｈを論理デバイス異常検出ロジック６２１に出力して異常検出を実行させた後、信号ｌを物理デバイス群１０１に出力し、ステップＳ７で物理デバイスに対して要求された処理を実行し、ステップＳ８で処理を終了する。チェックステップＳ６で、異常検出が必要ない場合には、ステップＳ７をスキップしてステップＳ８で処理を終了する。
【００６５】
次に、本発明の主要部を成す論理ＲＡＳ機能部６２０につき説明する。論理ＲＡＳ機能部６２０は、ハイパーバイザ層６００において、論理的なＲＡＳ機能を提供する機能ブロックである。
【００６６】
論理ＲＡＳ機能部６２０は、物理デバイス群１０１を、論理的な複数種類のデバイスに分類した論理デバイスに対する異常検出ロジック６２１、タイマ管理手段６２２、ソフトウェア処理異常検出ロジック６２６、および統合化異常対応処理ロジック６２７を備えている。
【００６７】
論理デバイス異常検出ロジック６２１は、論理ＲＡＳ機能の実行を要求する物理デバイスを、図２のテーブル１に示すように、論理ＣＰＵ，論理メモリ、論理ファイル、論理Ｉ／Ｏ、論理センサの５種類に分類し、各論理デバイスに対して定義された診断や検査を実行する。
【００６８】
論理デバイスは、図２のテーブル２に示す論理機能を有するデバイスとして抽象化されたデバイスであり、それぞれの論理機能に対し、正常性を検証するための診断・検査項目が定義される。異常が検出された際は、異常の状態と過去の異常履歴から図２のテーブル３に示す３種類の異常レベル、レベル１、レベル２、レベル３を判定し、統合化異常対応処理ロジック６２７へ信号ｐ１で異常検出情報を伝達する。
【００６９】
タイマ管理手段６２２は、論理ＷＤＴ群６２３、定周期診断を行うデバイス定周期診断タイマ６２４、および物理ＷＤＴリセットタイマ６２５を実装する。論理ＷＤＴ群６２３は、ハイパーバイザ層６００で論理的なＷＤＴ機能を複数のソフトウェアタイマで実現し、ソフトウェア処理の監視機能として提供する。異常が検出された際は、ソフトウェア処理異常検出ロジック６２６へ、ソフトウェアの異常情報信号ｎで伝達する。
【００７０】
デバイス定周期診断タイマ６２４は、ハードウェアの定周期診断を行うトリガとなるタイマであり、論理デバイス異常検出ロジック６２１へ一定周期で物理デバイスの診断を要求する信号ｍを送信する。
【００７１】
タイマ管理手段６２２は、ソフトウェア監視の中核を担う機能ブロックであるため、タイマ管理手段自身で物理ＷＤＴ１０２を用いた異常の監視を行う。これは、物理ＷＤＴリセットタイマ６２５により、一定周期で物理ＷＤＴ１０２のリセットを要求する信号ｑを出力することで実現する。信号ｑは、後述する物理デバイス固有処理手段６３０内の物理ＷＤＴリセット手段６３３に渡され、この物理ＷＤＴリセット処理手段６３３からの信号ｕにより、ハードウェア１００の物理ＷＤＴ１０２をリセットする。
【００７２】
ソフトウェア処理異常検出ロジック６２６は、論理ＷＤＴ群６２３により異常検出されたソフトウェアの異常情報信号ｎと、第２データベース６２９を検索した過去の異常履歴データｄ５から、図２のテーブル３に示すレベル１、レベル２、レベル３の３種類の異常レベルを判定し、その異常検出情報を信号ｐ２で統合化異常対応処理ロジック６２７へ伝達する。
【００７３】
統合化異常対応処理ロジック６２７は、論理デバイス異常検出ロジック６２１およびソフトウェア処理異常検出ロジック６２６から、異常検出箇所と異常レベルの情報を信号ｐ１およびｐ２で受信し、異常対応処理を実行する機能を備える。
【００７４】
統合化異常対応処理ロジック６２７は、受信した複数の異常検出情報ｐ１，ｐ２と第１データベース６２８にアクセスして得られる論理ＲＡＳ機能設定データｄ３から、異常発生箇所、異常発生箇所と依存関係にあるデバイス、ソフトウェア、および異常の同時性を判断し、複合的に異常対応処理ロジックを実行する。異常対応処理は、図２のテーブル４に示す、４種類の異常対応処理１乃至４を提供する。
【００７５】
第１データベース６２８は、論理ＲＡＳ機能を実現するための設定情報が格納された記憶領域である。図２のテーブル１に示す物理デバイスと論理デバイスの対応付け、図２のテーブル２に示す各論理デバイスと物理デバイス固有処理の対応付け、図３のテーブル５に示すデバイス・ソフトウェアの依存関係、図３のテーブル６に示す異常発生箇所の異常レベルと異常対応処理項目の対応付け、図３のテーブル７に示す複合的な異常対応処理項目の対応付け、および図３のテーブル８に示す論理ＷＤＴ用タイマ６２３のタイムアップ時間についての設定情報を保持する。
【００７６】
第２データベース６２９は、図３のテーブル９に示す過去に異常が検出された時の異常検出履歴、および、図３のーブル１０に示す異常時のシステムの状態を記録する記憶領域である。異常検出履歴は異常検出時に異常レベルを判定するための情報として使用される。異常時のシステムの状態は、メンテナンス作業者などが異常の発生するシステムの状態を参照するために使用される。
【００７７】
物理デバイス固有処理部６３０は、各物理デバイスに対する異常検出処理手段６３１、および異常対応処理手段６３２を実装する機能ブロックである。異常検出処理手段６３１は、論理デバイス異常検出ロジック６２１からの信号ｏに対応した物理デバイス固有処理を実行する。異常対応処理手段６３２は、統合化異常対応処理ロジック６２７からの信号ｒにより伝達された異常対応情報に対応した物理デバイス固有処理を実行する。
【００７８】
次に本発明組み込み機器の動作を、以下の（１）項乃至（４）項で説明する。
（１）ソフトウェアに対する論理ＲＡＳ機能実行のインタフェース：
論理ＲＡＳ機能の実行は、アプリケーションソフトウェア４００の処理からハイパーバイザ層６００の物理デバイス中継インタフェース６１０へアクセスすることによって行われる。
【００７９】
物理デバイス中継インタフェース６１０は、物理デバイス初期化インタフェース６１１および物理デバイスアクセスインタフェース６１２の２種類のインタフェースを持ち、夫々、既に説明した図４、図５に示す動作フローにより論理ＲＡＳ機能が実行される。
【００８０】
（２）論理デバイスに対する異常検出ロジック：
図６は、論理デバイスに対する異常検出ロジックの動作を示すフローチャートである。ステップＳ１で処理が開始されると、ステップＳ２で信号ｈ，ｊ，ｍを論理デバイス異常検出ロジック６２１が受け取る。
【００８１】
論理デバイス異常検出ロジック６２１は、ステップＳ３で、第１データベース６２８にアクセスして取得したデータｄ１を参照し、論理ＲＡＳ機能の実行を要求する物理デバイスについて、論理ＲＡＳ機能設定情報に記録された対応付けにより、５種類の論理デバイスに分類する。
【００８２】
次に、ステップＳ４でデータｄ１を参照し、各論理デバイスの論理機能に対応した診断、検査項目を参照し、実行する必要のある診断、検査項目を選出する。これは、論理ＲＡＳ機能実行の要求元、すなわち物理デバイス中継インタフェース６１０で提供される２種類のインタフェースによって、実行する異常検出ロジックが異なるためである。
【００８３】
この対応付けは、図２のテーブル２の例に示すような情報として論理ＲＡＳ機能設定情報に記録されている。実行する必要のある診断、検査項目については、信号ｏを出力し、ステップＳ５で夫々対応する物理デバイス固有の異常検出処理手段６３１を呼び出し、信号ｓにより物理デバイス群１０１の異常検出処理を実行する。
【００８４】
ステップＳ６のチェックで異常が検出された場合は、ステップＳ７で異常の程度と第２データベース６２９にアクセスして取得したデータｄ４を参照し、過去の異常検出履歴から異常レベルを判定し、ステップＳ８でデータｄ４で異常履歴を更新したうえで、ステップＳ９で異常検出箇所と異常レベルの情報を、信号ｐ１で統合化異常対応処理ロジック６２７に伝達し、ステップＳ１０で論理デバイス異常検出ロジックの処理を終了する。ステップＳ６のチェックで異常が検出されない場合は、ステップＳ１０にスキップして処理を終了する。
【００８５】
具体例として、デバイス・ソフトウェアＡＩＯ（Analog Input Output）アクセス時の異常検出ロジックの動作を記述する。ＡＩＯの物理デバイスアクセスインタフェース６１２にアクセスがあると、論理ＲＡＳ機能部６２０に実行の要求が伝達される。論理デバイス異常検出ロジック６２１は、図２のテーブル１からＡＩＯを論理Ｉ／Ｏであると分類し、図２のテーブル２に従ってＡＩＯの診断、検査項目を選定し、ＡＩＯ固有処理を呼び出して診断を行う。
【００８６】
ここで致命的な異常が検出された場合、図３のテーブル９にアクセスして記録された過去の異常検出履歴を参照し、過去に異常検出がないことから、異常レベルをレベル２(致命的、再現性無し)と判定して、異常検査履歴を更新のうえ信号ｐ１を統合化異常対応処理ロジック６２７へ伝達する。
【００８７】
（３）ソフトウェア処理監視と異常検出ロジック：
図７は、ソフトウェア処理監視と異常検出ロジックの動作を示すフローチャートである。論理ＲＡＳ機能部６２０のタイマ管理手段６２２は、複数のソフトウェアタイマで構成された論理ＷＤＴ群６２３を実装して上位のソフトウェア処理に提供し、これにより複数のソフトウェア処理の監視を実現する。
【００８８】
論理ＷＤＴ群６２３のスタートとリセット機能は、監視対象となるアプリケーション４０２、４０３、４０４自身が定周期ＷＤＴリセット要求手段４０２Ａ、４０３Ａ、４０４Ａを実装し、タイマ管理手段６２２はこれら定周期ＷＤＴリセット要求手段を呼び出す。
【００８９】
ステップＳ１でソフトウェア処理の監視が開始されると、ＯＳ５２０内のＷＤＴリセット手段５２２からの信号ｆ１、またはブートローダ５１０内のＷＤＴリセット手段５１３からの信号ｆ２により、ステップＳ２で論理ＷＤＴ群６２３がスタートする。
【００９０】
論理ＷＤＴ群６２３は、ステップＳ３で第１データベース６２８へアクセスしたデータｄ２から、設定されたタイムアップ時間を論理ＲＡＳ機能設定情報より取得し、ステップＳ４で論理ＷＤＴ群のタイマのカウントを開始する。
【００９１】
アプリケーション４０２、４０３、４０４は、正常に動作している場合には、定周期ＷＤＴリセット要求手段４０２Ａ、４０３Ａ、４０４Ａにより、カウンタがタイムアップしない周期でカウンタをクリアする。
【００９２】
ステップＳ５のチェックでソフトウェアの異常により論理ＷＤＴ群６２３のいずれかがタイムアップした場合は、ステップＳ６でソフトウェアの異常情報が信号ｎでソフトウェア処理異常検出ロジック６２６に伝達される。ステップＳ１からＳ６までの処理が論理ＷＤＴ群６２３の処理範囲（Ａ）である。
【００９３】
ソフトウェア処理異常検出ロジック６２６は、ステップＳ７で第２データベース６２９にアクセスしたデータｄ５により、過去の異常検出履歴を参照することにより異常レベルを判定する。
【００９４】
更に、ステップＳ８で、データｄ５で第２データベース６２９の異常検出履歴を更新したうえで、ステップＳ９で異常検出箇所と異常レベルの情報を、信号ｐ２で統合化異常対応処理ロジック６２７に伝達し、ステップＳ１０でソフトウェア処理の監視を終了する。ステップＳ７からＳ９までの処理がソフトウェア処理異常検出ロジック６２６の処理範囲（Ｂ）である。
【００９５】
具体例として、アプリケーションとしてインストールされている(図示されていない)デバイス・ソフトウェである、図３のテーブル５に定義されているＨＴＴＰサーバの監視処理について記述する。
【００９６】
ＨＴＴＰサーバ自身には、論理ＷＤＴ群６２３のスタートとリセット処理が実装される。ＨＴＴＰサーバが論理ＷＤＴ群６２３をスタートさせると、論理ＷＤＴ群６２３は、図３テーブル８の例のようなタイムアップ時間の設定からタイムアップ時間６０秒を取得し、カウントを開始する。
【００９７】
ＨＴＴＰサーバは、正常時には６０秒を超えない周期で論理ＷＤＴ群６２３をリセットする。ＨＴＴＰサーバに異常があった場合、論理ＷＤＴ群６２３はタイムアップし、ソフトウェアの異常情報を信号ｎでソフトウェア処理異常検出ロジック６２６に伝達する。
【００９８】
ソフトウェア処理異常検出ロジック６２６では、データｄ５により、第２データベース６２９へのアクセスでテーブル９の異常検出履歴を参照し、過去にも異常が発生していることから、異常レベルをレベル３(致命的、再現性あり)と判定し、異常検出履歴を更新のうえ情報を信号ｐ２により統合化異常対応処理ロジック６２７へ伝達する。
【００９９】
（４）統合化異常対応処理ロジック６２７：
図８は、統合された異常対応ロジックの動作を示すフローチャートである。ステップＳ１で異常対応処理ロジックが開始されると、ステップＳ２で統合化異常対応ロジック６２７は、論理デバイス異常検出ロジック６２１からの異常情報信号ｐ１またはソフトウェア異常検出ロジック６２６からの異常情報信号ｐ２により、異常検出箇所と異常レベルの情報を受信する。
【０１００】
ステップＳ３で異常検出箇所と異常レベルに対応した異常対応処理を検索する。まず、検索では、異常発生箇所に対し異常レベルに従った対応処理を、データｄ３で第１データベース２６８にアクセスし、論理ＲＡＳ機能設定情報から検索（異常対応処理項目検索の動作フローは、図９で説明する）し、項目を選出する。
【０１０１】
ステップＳ４のチェックで物理デバイスに対する異常処理がある場合には、信号ｒを出力して、ステップＳ５で物理デバイス固有処理部６３０内の異常対応処理手段６３２を起動し、信号ｔで物理デバイス群１０１により該当する物理デバイス固有の異常対応処理を実行する。
【０１０２】
次に、ステップＳ６のチェックでソフトウェア処理に異常がある場合には、ＯＳ５２０内のアプリケーション管理手段５２３に信号ｇを通知し、ステップＳ７でソフトウェの管理機能へ異常対応処理を要求する。
【０１０３】
ステップＳ８でデータｄ６を第２データベース６２９に送信し、テーブル９およびテーブル１０に過去の異常履歴に異常時のシステムの状態を記録し、ステップＳ９で異常対応処理ロジックを終了する。
【０１０４】
図９は、統合化異常対応処理ロジック６２７による異常対応処理項目検索の動作を示すフローチャートである。ステップＳ１で異常対応処理検索が開始されると、ステップＳ２では統合化異常対応処理ロジック６２７は、データｄ３で第１データベース６２８にアクセスし、テーブル６を参照して異常個所の異常レベルに従った異常対応処理項目を検索する。
【０１０５】
ステップＳ３では、第１データベース６２８にアクセスしたデータｄ３で、テーブル５を参照し、異常発生箇所と依存関係にあるデバイス・ソフトウェアを検索する。ステップＳ４のチェックで依存するデバイス・ソフトウェアがある場合には、ステップＳ５のチェックに進み、依存する部分で異常が検出されていなければ、ステップＳ６でデータｄ３により第１データベース６２８にアクセスし、依存する部分への統合的な異常対応処理を検索する。
【０１０６】
次に、ステップＳ７のチェックで統合的な異常処理の必要性がある場合には、ステップＳ８で依存する部分の異常対応を処理項目に追加し、ステップＳ９で異常対応処理検索を
終了する。
【０１０７】
ステップＳ５のチェックで、依存する部分で異常検出されている場合には、ステップＳ８にスキップして、依存する部分の異常対応を処理項目に追加する。ステップＳ４のチェックで、依存するデバイス・ソフトウェアがない場合には、ステップＳ９にスキップして異常対応処理検索を終了する。
【０１０８】
図８、図９の処理フローで明らかなように、統合化異常対応処理ロジック６２７は、異常発生箇所と依存関係にあるデバイス・ソフトウェアを論理ＲＡＳ機能設定情報から検索する。依存する部分については、その部分において異常検出されている場合、もしくは複合的な異常対応処理が論理ＲＡＳ機能設定情報に定義されている場合に、対応処理を項目として追加する。
【０１０９】
検索された異常対応処理ロジックの処理項目のうち、物理デバイスに対する処理は、対応する固有の異常対応処理手段６３２を呼び出して処理を実行する。ソフトウェアに対する処理は、ＯＳが持つソフトウェアの管理機能であるアプリケーション管理手段５２３に対して異常対応処理の要求を行う。そして最後に、異常が発生した時のシステムの状態を過去の異常履歴に記録する。
【０１１０】
具体例として、ＡＩＯの異常(異常レベル２)が単独で検出された際の異常対応処理を記述する。統合化異常対応処理ロジック６２７は、異常情報信号ｐ１を受信すると、テーブル６の例に示す異常対応処理の対応付けの情報を参照し、ＡＩＯに対する異常レベル２の異常対応処理１(ＡＩＯの再起動)を処理項目として選出する。
【０１１１】
次に、テーブル５の例に示す依存関係の情報より、制御アプリケーションが依存関係にあることを把握する。ここで、制御アプリケーションでも異常が検出されていれば、その異常対応処理を処理項目に加える。
【０１１２】
この例では、ＡＩＯ単独の異常としているため、テーブル７の例に示す複合的な異常対応処理の検索に移る。ここでは、依存する制御アプリケーションの異常対応処理、および条件が設定されているため、異常対応処理１(制御アプリケーションの再起動)を処理項目に加える。
【０１１３】
以上により異常対応処理の処理項目が列挙されるため、処理項目に従ってＡＩＯ固有の異常対応処理、および制御アプリケーション再起動の要求を行う。そして最後に、テーブル１０に示す例のように、異常が発生した時のシステムの状態を記録する。
【０１１４】
以上説明した本発明のＲＡＳ機能は、次のような拡張応用が可能である。
（１）組み込み機器に着脱可能なフォールトトレラント機能装置への応用：
信頼性を向上させることを目的として、論理ＲＡＳ機能に対して、ＲＡＳ機能に加えて論理的なフォールトトレラント機能を実装する。
【０１１５】
ブートローダやＯＳなどの上位のソフトウェアは、ハードウェアの冗長化構成やシングル構成を意識する必要がない。従って、ハイパーバイザ層で実現する冗長化制御機能は、論理化された多重化ＣＰＵボードの制御を行い、物理ＣＰＵへアクセスする際にハードウェアに依存する機能へマッピングする。
【０１１６】
（２）抽象化、単純化を行った論理ＲＡＳ機能をＦＰＧＡへ実装することが可能である。プログラマブルなＩＣにＲＡＳ機能を実装することにより、より信頼性の高いＲＡＳ機能を着脱可能な形態で組み込み機器に提供することができる。
【０１１７】
（３）ＣＰＵとしてマルチコアＣＰＵを採用する場合には、ハイパーバイザー層６００に実装された論理ＲＡＳ機能部６２０、物理デバイス中継インターフェース６１０、物理デバイス固有処理部６３０を、専用のコアＣＰＵに割り当てることによりＲＡＳ機能に係る信号処理の高速化を実現することができる。
【符号の説明】
【０１１８】
１００  ハードウェア
１０１  物理デバイス群
１０２  物理ウォッチドッグタイマ（ＷＤＴ）
４００  アプリケーションソフトウェア
４０１〜４０４  アプリケーション
４０２Ａ〜４０４Ａ  定周期ＷＤＴリセット要求手段
５００  システムソフトウェア
５１０  ブートローダ
５１１  デバイスドライバ
５１２  デバイス初期化ドライバ
５１３  ＷＤＴリセット手段
５２０  ＯＳ
５２１  デバイスアクセス手段
５２２  ＷＤＴリセット手段
５２３  アプリケーション管理手段
６００  ハイパーバイザ層
６１０  物理デバイス中継インタフェース
６１１  物理デバイス初期化インタフェース
６１２  物理デバイスアクセスインタフェース
６２０  論理ＲＡＳ機能部
６２１  論理デバイス異常検出ロジック
６２２  タイマ管理手段
６２３  論理ＷＤＴ群
６２４  デバイス定周期診断タイマ
６２５  物理ＷＤＴリセットタイマ
６２６  ソフトウェア処理異常検出ロジック
６２７  統合化異常対応処理ロジック
６２８  第１データベース
６２９  第２データベース
６３０  物理デバイス固有処理部
６３１  異常検出処理手段
６３２  異常対応処理手段
６３３  物理ＷＤＴリセット手段
【図１】
0005733515.tif 000002
【図３】
0005733515.tif 000003
【図４】
0005733515.tif 000004
【図５】
0005733515.tif 000005
【図６】
0005733515.tif 000006
【図７】
0005733515.tif 000007
【図８】
0005733515.tif 000008
【図９】
0005733515.tif 000009
【図１０】
0005733515.tif 000010
【図２】
0005733515.tif 000011