JP2013143093A - 情報処理装置、情報処理システム - Google Patents

Abstract

【課題】２つ以上のアプリケーションの一方に異常が検出されても、他方のアプリケーションを継続して実行可能な情報処理装置を提供すること。
【解決手段】複数のアプリケーションと、第一のカウント期間におけるアプリケーション毎の動作中通知の回数をカウントするアプリ監視手段６０と、アプリケーションの動作を制御するアプリ制御手段３２と、を有し、アプリ監視手段がアプリケーションの過去の動作中通知の回数に基づき、アプリケーションの異常兆候を検出した場合、前記アプリ制御手段は、最も優先度が低いアプリケーションの動作中通知の送信を停止し、異常兆候が検出されていないアプリケーションは、異常兆候が検出される前のタイミングと、異常兆候が検出されたアプリケーションが動作中通知を送信するタイミング又はその前後のタイミングで、動作中通知を送信する、ことを特徴とする。
【選択図】図１

Description

本発明は、実行しているアプリの異常を検出する情報処理装置等に関する。

車両ではマイコンにより制御される車載装置が多く搭載されており、車載装置の安全性を確保するため、車載装置と共に安全装置を搭載することが一般的である。安全装置はマイコンや車載装置の機能が仕様にしたがって動作しているか否かを監視し、故障などが検出されると機能を停止したり、外部に通知するなどのフェールセーフ機能を提供する。このような安全性の確保や得られる安全性そのものを機能安全と呼ぶ。

車両の機能安全については、ＩＥＣ６１５０８／ＩＳＯ２６２６２等に規格化されており、ＩＳＯ２６２６２では自動車の安全要求と安全対策を指定する指標としてＡＳＩＬ（Automotive Safety Integrity Level）が定められている。ＡＳＩＬはＡ〜Ｄ、ＱＭ（Ｄ＞Ｃ＞Ｂ＞Ａ＞ＱＭ）の安全性レベルが定められており、各部品がどの安全性レベルを満たすべきか、部品が関わる安全性に応じてメーカが決定することができる。このため、安全性に重大な影響がある部品のＡＳＩＬは高くなる。

例えば、マイコンではプロセッサについてＡＳＩＬを定めることができるし、マイコン上で動作するアプリケーションについてもＡＳＩＬを定めることができる。メーカとしては、高い機能安全を確保していることをアピールするために高い安全性レベルのＡＳＩＬを指定することができるが、その安全性レベルに見合った監視が必要になる。

例えば、１つのマイコン上で複数のアプリケーション１，２が動作する場合がある。この場合、メーカは、車載装置を制御するアプリケーション１の安全性レベルをＡＳＩＬ Ａ、車載装置の制御と直接的な関連性の低いアプリケーション２の安全性レベルをＱＭ、と定めることができる。

安全装置としては、ＡＳＩＬの安全性レベルに応じた監視が必要になる。例えば、高ランクのアプリケーションに異常が検出された場合、そのアプリケーションを復帰するための処理が優先される。しかし、低ランクのアプリケーションに異常が検出された場合、安全装置は高ランクのアプリケーションの挙動に影響を与えてまで、低ランクのアプリケーションの復帰処理を優先すべきではない。

ここで、従来からアプリケーションの動作を監視する仕組みとしてＷＤＴ（Ｗａｔｃｈ Ｄｏｇ Ｔｉｍｅｒ）が知られている。しかしながら、ＷＤＴは、アプリケーションが一定時間、タイマリセットしないとマイコンをリセットしてしまうため、その間、マイコンを使用できず処理が止まってしまう。

アプリケーションに何らかの異常が検出された場合に処理を継続する方法として、処理系を二重化する方法がある（例えば、特許文献１参照。）。特許文献１には、主処理部と補助処理部が互いに処理内容を監視し、データ処理をしている一方の処理部が処理の途中でダウンした場合に切替手段が、回線に接続する主処理部と補助処理部を切り替えるフォールトトレラント計算器が開示されている。

また、ＷＤＴと同様に監視対象の応答の有無を監視して異常を検出する技術が考えられている（例えば、特許文献２参照。）。特許文献２には、監視対象である通信装置にテスト信号を送信し、テスト信号の送信時から所定時間以内に応答を受信したか否かにより通信異常を判定する診断システムが開示されている。

特開２００１−２９０６６８号公報 特開２０１１−０４０８８６号公報

しかしながら、特許文献１に開示されているようにシステムを二重化する方法ではコスト増となるため高い安全性レベルでアプリケーションを監視できても、全てのアプリケーションの監視に採用することは困難である。

また、特許文献２では異常と判定された場合に異常と関係のある通信装置に通知するだけで、どのようにフェールセーフ制御するかについて記載されていない。すなわち、異常が検出された場合に処理を止めずに継続することについて考慮されていない。

本発明は、上記課題に鑑み、２つ以上のアプリケーションの一方に異常が検出されても、他方のアプリケーションを継続して実行可能な情報処理装置を提供することを目的とする。

本発明は、動作中であることを通知する動作中通知を周期的にアプリ監視手段に送信する複数のアプリケーションと、第一のカウント期間におけるアプリケーション毎の動作中通知の回数をカウントするアプリ監視手段と、アプリケーションの動作を制御するアプリ制御手段と、を有し、前記アプリ監視手段が各アプリケーションの過去の前記第一のカウント期間における動作中通知の回数に基づき、少なくとも１つのアプリケーションの異常兆候を検出した場合、前記アプリ制御手段は、優先度が最も低いアプリケーションの動作中通知の送信を停止し、異常兆候が検出されていないアプリケーションは、異常兆候が検出される前と同じタイミングと、動作中通知の送信が停止されたアプリケーションが動作中通知を送信するタイミング又はその前後のタイミングで、動作中通知を送信する、ことを特徴とする。

２つ以上のアプリケーションの一方に異常が検出されても、他方のアプリケーションを継続して実行可能な情報処理装置を提供することができる。

監視マイコンによるマイコンの異常監視の概略を説明する図の一例である。 マイコンシステム又はマイコンの概略構成図の一例を示す。 マイコンシステム又はマイコンの機能ブロック図の一例である。 応答送信部による応答信号の送信と、応答監視部による応答信号の監視を模式的に示す図の一例である。 フェールセーフ状態における応答信号の送信方法を説明する図の一例である。 マイコン又はマイコンシステムの動作手順を示すフローチャート図の一例である。 アプリが３つある場合のマイコン又はマイコンシステムの概略を説明する図の一例である。 複数のマイコンのアプリを１つの監視マイコンで監視するマイコンシステムの一例を示す図である。 マイコン又はマイコンシステムの機能ブロック図の一例である（実施例２）。 フェールセーフ状態における応答信号及び動作状態情報の送信方法を説明する図の一例である（実施例２）。 送信タイミングと送信される情報を説明する図の一例である。 マイコン又はマイコンシステムの動作手順を示すフローチャート図の一例である（実施例２）。

以下、本発明を実施するための形態について図面を参照しながら説明する。

図１は、監視マイコンによるマイコンの異常監視の概略を説明する図の一例である。本実施形態の異常監視は、大きく通常監視状態とフェールセーフ状態に分けて説明することができる。

・通常監視状態（図１（ａ））
通常監視状態とはアプリケーション（以下、単にアプリという）の動作に異常兆候が検出されていないマイコン５０の状態であり、フェールセーフ状態と対比して使用される。マイコン５０と監視マイコン６０は通信可能に接続されている。マイコン５０ではアプリ１及びアプリ２が動作しており、ほぼ定期的に応答送信部に応答信号１，２を送信するよう要求する。図の送信タイミング１がアプリ１の応答信号１の送信タイミングであり、送信タイミング２がアプリ２の応答信号２の送信タイミングである。応答送信部は従来のアプリがＷＤＴ（Ｗａｔｃｈ Ｄｏｇ Ｔｉｍｅｒ）をリセットする場合と同様に、応答信号１，２を監視マイコン６０に送信する。

監視マイコン６０の応答監視部は、応答信号１と応答信号２を別々に監視し、統計間毎に受信回数を算出する。応答監視部は受信回数を時系列に記憶しており、その変動に基づき、アプリ１，２が停止する前に、異常兆候を検出する。例えば、図示するようにアプリ１の過去の受信回数が安定しているのに対し、アプリ２の受信回数が減少傾向にある場合、応答監視部はアプリ２の異常兆候を検出する。このように、アプリが完全に停止する前にアプリが不安定であることを検出できることが本実施例の特徴の１つである。不安定であることとは、いずれ停止したり応答しなくなることが予測される状態をいい、本実施例では不安定な状態を「異常兆候」と称する
・フェールセーフ状態（図１（ｂ））
監視マイコン６０がアプリ２の異常兆候を検出した場合、マイコン５０はフェールセーフ状態になる。フェールセーフ状態では、優先度の低いアプリ２が例えば停止され、アプリ１は継続して動作する。ここで、本実施形態では、優先度の低いアプリ２の方が異常兆候が生じやすいという前提の下で説明する。優先度は例えばＡＳＩＬにより判定される。

アプリ１は、引き続き応答送信部に応答信号１の送信を要求する。アプリ２は停止しているので、応答送信部はアプリ２の応答信号２を監視マイコン６０に送信する必要がない。このため、応答信号２の送信処理が不要になる。そこで、アプリ１は、応答信号２の送信タイミング２を利用して、アプリ１の応答信号１を監視マイコン６０に送信する。すなわち、アプリ１は、送信タイミング１と送信タイミング２の両方で応答信号１を監視マイコン６０に送信する。

応答信号１の送信頻度が２倍になるので、監視マイコン６０の応答監視部は、マイコン５０の監視を強化することができる。すなわち、応答監視部は、高頻度に送信される応答信号１の受信回数を監視して、受信回数が安定しているか否かを判定するので、受信回数の傾向を高精度に把握しやすくなり、アプリ１の異常兆候を検出しやすくなる。

このように、監視マイコン６０は、マイコン５０の一部の機能が不安定になってもすぐにはリセットしないので、マイコン５０は引き続き処理を継続できる。また、一部のアプリに異常兆候が検出された後、他のアプリの監視を強化できるので、不安定なアプリ又はその停止により不安定でないアプリに異常が生じたとしても早期に検出して対応できる。

高優先度のアプリ１と低優先度のアプリ２について補足する。高優先度のアプリ１と低優先度のアプリ２は、それぞれ独立に動作するシステムであり、低優先度のアプリ２は高優先度のアプリ１よりも不安定になりやすい。仮に高優先度のアプリ１が不安定になったように見えても、低優先度のアプリ２に起因している可能性が高い。このため、本実施形態の監視マイコン６０は、不安定になったアプリに関係なく低優先度のアプリ２を停止させる。最終的に、高優先度のアプリ１が不安定になった場合、従来どおり、高優先度のアプリ１に対しフェールセーフ処理が行われる。

〔マイコンの構成例〕
図２は、本実施例のマイコンシステム１００又はマイコン５０の概略構成図の一例を示す。本実施例の異常監視方法は、図２（ａ）の監視マイコン６０がマイコン５０を監視する態様、図２（ｂ）の１つのマイコン５０が自身を監視する態様のいずれでも適用可能である。まず、図２（ａ）から説明する。

マイコン５０は、システムバス９に接続されたＣＰＵ１１、ＲＡＭ１２、フラッシュメモリ１３及びＷＤＴ１４を有し、周辺バス１０に接続されたＣＡＮコントローラ１６、ＡＤＣ（Ａ／Ｄコントローラ）１７及びＩ／Ｏチャネル１８を有し、システムバス９と周辺バス１０がブリッジ１５により接続されている。

ＣＰＵ１１は、フラッシュメモリ１３に記憶されているプログラムを、ＲＡＭ１２を作業メモリにして実行する。ＣＰＵ１１は、マルチコアでもシングルコアでもよい。フラッシュメモリ１３に記憶されたプログラムは、マイコン５０が車載装置を制御するアプリ１，２の他、異常監視に使用されるプログラム、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）、ミドルウェア、デバイスドライバ等が含まれている。

ＷＤＴ１４は、従来と同様に、ＣＰＵ１１が実行するアプリ１，２が定期的にリセットするためのタイマを有しており、タイマがリセットされないことからアプリ１又はアプリ２の暴走を検出する。本実施例ではＷＤＴ１４と同様の機能が監視マイコン６０により得られるため、ＷＤＴ１４はなくてもよい。一方、監視マイコン６０に異常が生じた場合のために、ＷＤＴ１４を搭載しておくことも有効である。この場合、ＷＤＴ１４は監視マイコン６０がアプリ１，２両方の異常を検出するよりも長い時間、アプリ１，２のいずれからも応答がない場合に異常を検出する。

ブリッジ１５は、システムバス９と周辺バス１０の間の周波数や電圧の違いを吸収し、システムバス９に接続された回路と周辺バス１０に接続された回路とを通信可能に接続する。ＣＡＮコントローラ１６は、マイコン５０と監視マイコン６０がＥＣＵ（Electronic Control Unit）に搭載された場合に、他のＥＣＵと通信するための通信回路である。ＡＤＣ１７は、マイコン５０に接続されたセンサのアナログ信号をデジタル信号に変換する。ＡＤＣ１７に加え、ＤＡＣ（Ｄ／Ａコントローラ）を有する場合もある。Ｉ／Ｏチャネル１８には、他のマイコン、アクチュエータ、センサ、スイッチ等が接続される。

監視マイコン６０もマイコン５０と同様の構成を備えているが、必ずしも同一である必要はない。監視マイコン６０は、ＣＰＵ２１、ＲＡＭ２２、フラッシュメモリ２３、及び、Ｉ／Ｏチャネル２４を有しているが、この他、一般的な回路を備えている。監視マイコン６０のフラッシュメモリ１３に記憶されたプログラムは、マイコン５０を監視するためのプログラムであるが、ＯＳやミドルウェア、デバイスドライバを有していてもよいし、さらに監視マイコン６０が制御装置を制御するためのアプリが含まれていてもよい。

マイコン５０と監視マイコン６０は互いのＩ／Ｏチャネル１８、２４を介して接続されている。Ｉ／Ｏチャネル１８、２４は、例えば、Ｉ２Ｃ（Inter-Integrated Circuit）やＵＳＡＲＴ（Universal Synchronous Asynchronous Receiver Transmitter）などのシリアル通信の規格に従い互いに通信する。

図２（ｂ）のように、マイコン内に異常監視回路１９が配置される場合、監視マイコン６０は不要となる。異常監視回路１９は後述する監視マイコン６０の機能を提供する回路である。この場合、ＣＰＵ１１と異常監視回路１９はブリッジ１５を介して通信する点を除けば図２（ａ）と同様である。

以下では、マイコン５０の異常監視がマイコンシステム１００又はマイコン５０のいずれにより実行されるかは特に制限しない。しかし、図２（ａ）の態様では、アプリ１やアプリ２だけでなくマイコン全体に異常が生じた場合にも監視マイコン６０がそれを検出してリセットするなどの処理が可能になり信頼性がより向上する。図２（ｂ）の態様では、１チップ内に異常監視回路１９が含まれているので、コスト的、実装スペース的に有利である。

なお、本実施例のマイコン５０又はマイコンシステム１００は、主に車両のＥＣＵに搭載されることを想定している。車載されるＥＣＵには、その主要な機能により、エンジンＥＣＵ、ブレーキＥＣＵ、ボディＥＣＵ、ナビゲーションＥＣＵ（ＡＶ・情報処理ＥＣＵ）、ゲートウェイＥＣＵ等がある。本実施例のマイコン５０又はマイコンシステム１００はＥＣＵの機能の違いに影響されず搭載されることが可能である。

図３は、マイコンシステム１００又はマイコン５０の機能ブロック図の一例である。マイコン５０又はマイコンシステム１００は、アプリ１，アプリ２、応答送信部３１、応答監視部３３、及び、モード切り換え部３２を有する。

＜ＡＳＩＬについて＞
まず、ＡＳＩＬについて説明する。アプリ１はＡＳＩＬ Ａの安全性レベルが指定されており、アプリ２はＡＳＩＬ ＱＭの安全性レベルが指定されている。ＡＳＩＬは、ハザード（障害）を避けるために達成する必要のある安全性のレベルである。ＡＳＩＬの決定に際しては、例えば、ハザードによって生じる被害の大きさ、ハザードの生じる頻度、ハザードが生じた場合の制御難易度がハザード毎に検討される。したがって、安全性に影響し、よく使用されるアプリほどＡＳＩＬが高くなる傾向になる。例えば、ブレーキを制御するアプリ、パワーステアリングを制御するアプリ等はＡＳＩＬが高く、直接、走行制御に影響しにくいナビやＡＶ系のアプリのＡＳＩＬは低くなる。このような観点から、各アプリはＱＭ、Ａ〜Ｄの安全性レベルが与えられており、安全性レベルに応じた設計がなされている。

本実施例では、異常兆候が検出されるアプリ２のＡＳＩＬがＱＭであれば、アプリ２の復帰を試みることなくアプリ１のみの動作を継続しても大きな支障はないとして説明する。また、一般に、複数の、ＡＳＩＬが異なるアプリが実行される場合、相対的に不安定になりやすいのはＡＳＩＬが低いアプリである。

したがって、アプリ１のＡＳＩＬはＡ〜Ｄのうちいずれでもよい。また、アプリ２のＡＳＩＬはＱＭでなくてもよく、アプリ１のＡＳＩＬよりも低ければよい。この場合、アプリ２に異常兆候が検出され停止された状態で、アプリ１さえ動作を継続すればよいか否かは、アプリ毎に定まる設計方針である。すなわち、アプリ２の異常兆候が検出され停止された状態で、アプリ１だけが動作を継続する場合も、アプリ２の異常兆候が検出された時点でアプリ２の復帰が試みられる場合もある。アプリ単位の復帰方法には、例えば、新たなコアにアプリを割り当てたり、コア単位でリセットしたり、マイコンそのものをリセットするなどの方法がある。

不安定になりやすいのはＡＳＩＬが低いアプリであるが、アプリ１とアプリ２のＡＳＩＬが同じ場合もあり得る。この場合、アプリ２に異常兆候が検出されたままアプリ１さえ動作を継続すればよいか否かは、アプリ毎に定まる設計方針である。

アプリ１のＡＳＩＬ＞アプリ２のＡＳＩＬの場合であって、アプリ１に異常兆候が検出されることもゼロではないと考えられる。この場合、本実施形態では、アプリ１に異常兆候が検出されたのは、アプリ２に起因すると判断してアプリ２を停止させる。この結果、アプリ１に異常兆候が検出されたままであれば、アプリ１の異常兆候の検出により、アプリ１の復帰が試みられることが多い。

また、アプリ１の異常兆候が検出された場合にアプリ２のみ動作を継続してもよい。このような状況は、例えばアプリ１のＡＳＩＬがそれほど高くなく、アプリ１が使用されない状況で生じる。

＜各機能について＞
ＣＰＵ１１はアプリ１，２を実行する。ＣＰＵ１１がマルチコアの場合、あるコアがアプリ１を別のコアがアプリ２をそれぞれ継続的に実行する（またはタイマ割込みを利用するなどして定期的に実行してもよい）。ＣＰＵ１１がシングルコアの場合、１つのコアが時分割的にアプリ１，アプリ２を実行する。いずれの場合もアプリ１，２は、アクチュエータを制御したり、センサから信号を取得したり、スイッチをオン／オフするなど固有の処理に加え、定期的に応答送信部３１に応答信号１，２の送信を要求する処理を行う。

応答送信部３１、応答監視部３３、及び、モード切り換え部３２は、例えばＯＳやミドルウェアが提供する機能、又は、アプリ１，２とは別のアプリが提供する機能である。

応答送信部３２は、アプリ１から応答信号１の送信要求を取得すると、応答監視部３３に応答信号１を送信し、アプリ２から応答信号２の送信要求を取得すると、応答監視部３３に応答信号２を送信する。応答監視部３３は、応答信号１、２の監視結果に基づき、アプリ１又はアプリ２の異常兆候を検出する。

モード切り換え部３２は、アプリ２から異常兆候が検出されたという通知を取得すると、通常監視状態のマイコン５０をフェールセーフ状態に切り替える。この切り替えのため、モード切り換え部３２は以下の処理を行う。
・アプリＡＳＩＬ情報３６を参照して、アプリ２の優先度（ＡＳＩＬ）が他のアプリ１よりも低いことを確認する。すなわち、最も優先度が低いアプリであることを確認する。または、最も優先度が低くなくても、予め定められた優先度以下であることを確認する。
・アプリ１又はアプリ２のいずれの異常兆候が検出された場合でも、アプリ２を停止、又は、アプリ２を監視対象外とする（アプリ２に応答信号２の送信を停止させる、又は、アプリ２から応答信号２の送信要求を受け付けても応答信号２の送信を行わない）
・アプリ１と監視マイコン６０にフェールセーフ状態になったことを通知する
本実施例では、フェールセーフ状態のアプリ１は、アプリ２の送信タイミングも利用して応答信号１を送信する。例えば、アプリ１と２が同じ周期で応答信号を送信していた場合、アプリ１の応答信号１の送信周期は、通常実行状態に比べて１／２になる。このように送信周期が短くなるので、統計期間当たりの応答信号１の数が多くなり、応答監視部３３によるアプリ１の監視精度が向上する。また、応答送信部３１の送信頻度は変わらないので、マイコン５０又はマイコンシステム１００の負荷をほぼ変化させずに済む。

〔応答監視部による異常兆候の検出〕
図４は、応答送信部３１による応答信号１，２の送信と、応答監視部３３による応答信号１，２の監視を模式的に示す図の一例である。図４（ａ）はアプリ１，２共に正常な場合を示す。アプリ１はアプリ１の周期毎に応答送信部３１に応答信号１を送信するよう要求する。アプリ２はアプリ２の周期毎に応答送信部３１に応答信号２を送信するよう要求する。応答信号１，２は、アプリ１とアプリ２が動作していることを示す信号であり、両者を区別できる情報を含むものであればよい。

応答送信部３１は、アプリ１、２から要求されたタイミングで、応答信号１，２を応答監視部３３に送信する。アプリ１、２はそれぞれ決まった周期（例えば、１００ミリ秒）で送信要求するので、タイミングが衝突することはないが、仮に衝突した場合は応答送信部３１がＡＳＩＬの高いアプリ１を優先することで調整する。

応答監視部３３は、応答信号１，２を識別して、それぞれを個別にカウントする。例えば、統計期間として１秒間に応答信号１を受信した回数、応答信号２を受信した回数をそれぞれカウントし記録する。こうすることで、１秒間に受信した回数を時系列に監視できる。周期が１００ミリ秒だとすると、１秒間に１０回、応答信号１，２が受信される。このため、図４（ａ）ではアプリ１，２の受信回数がほぼ１０回になっている。

これに対し、図４（ｂ）はアプリ２に異常兆候が見られる場合を示す。アプリ２が不安定になると、アプリ２は応答信号２の送信要求を周期的に出力しない場合がある（図の点線で囲まれた応答信号２は送信されない応答信号２を示す）。応答監視部３３は、１秒間の応答信号１，２の受信回数をカウントするので、応答信号２の受信回数は徐々に小さくなったり、大きく変動したりする。応答監視部３３は、過去の例えば数個のカウント値の傾きを算出し、傾きが閾値を超えた場合にアプリ２の異常兆候が検出されたと判定する。この閾値は、例えば、数秒以内に受信回数がゼロになる傾きとすることができる。

また、応答監視部３３は、過去の数個のカウント値の分散を算出して、閾値と比較することでアプリ２が不安定であるか否かを判定する。受信回数に一定の傾向がないが、増減が激しい場合には分散が大きくなるので、これによりアプリ２の異常兆候が検出されたと判定する。

また、応答監視部３３は、例えば理想的な受信回数からの乖離量に基づき、アプリ２が不安定であることを検出してもよい。理想的な受信回数はアプリ毎に決まっているので（例えば、１秒間に１０回）、過去の数個の受信回数の平均などが極端に少なければ（例えば、５回以下）、アプリ２の異常兆候を検出できる。

〔フェールセーフ状態のマイコンの動作〕
図５は、フェールセーフ状態における応答信号１の送信方法を説明する図の一例である。

モード切り換え部３２により、アプリ２は、以下のように動作する。
・アプリ２が停止された場合、又は、アプリ２に応答信号２の送信を停止させた場合
ＣＰＵ１１がアプリ２を実行することがないので、アプリ２が応答送信２を送信要求することもない。
・アプリ２から応答信号２の送信要求を受け付けても応答信号２の送信を行わない場合
応答送信部３１はアプリ２による応答送信２の送信要求を無視する。

いずれの場合も、フェールセーフ状態では応答送信部３１が応答信号２を応答監視部３３に送信することはない。

アプリ１は、フェールセーフ状態になると、それまでのアプリ１の送信タイミング１に加え、アプリ２の送信タイミング２も使用して応答信号１の送信を応答送信部３１に要求する。アプリ１には、このフェールセーフ状態の送信タイミングが予め設定されており、フェールセーフ状態になったという通知を取得するだけで送信周期を切り替えることができる。応答信号２が応答信号１に切り替わるだけなので、応答送信部３１や応答監視部３３の負荷にはほぼ変更がない。

なお、応答信号２から応答信号１に置き換わった送信タイミング２は、通常実行状態の送信タイミング２と同一である必要はなく、通常実行状態の応答信号２の送信頻度と、応答信号２から置き換わった応答信号１の送信頻度が同じであればよい。すなわち、応答送信部３１の送信頻度に通常実行状態とフェールセーフ状態とでほぼ変更がなければよい。

応答監視部３３は、通常実行状態と同様に、応答信号１をカウントする。応答信号１と応答信号２の送信頻度が同じであった場合、フェールセーフ状態では応答信号１の送信頻度が倍になる。このため、通常実行状態の応答信号１の送信頻度が１秒間に１０回であったなら、フェールセーフ状態の応答信号１の送信頻度は１秒間に２０回となる。図５では２つの受信回数が図示されているが、左側の応答信号１の受信回数がほぼ２０回になっている。

また、フェールセーフ状態では、応答監視部３３の統計期間を１秒間のままとするのでなく、通常実行状態よりも統計期間を短くすることが好ましい。例えば、送信頻度が倍になったのであれば、統計期間が１／２になっても同じ数の受信回数が得られる。より短い時間間隔で同程度の受信回数を取得できるので、微小な変動を検出しやすくなる。アプリ１は、アプリ２が不安定になったことの影響を受けやすいと考えられるが、このように監視を強化することでアプリ１の異常兆候を精度よく検出できる。

フェールセーフ状態の応答監視部３３は、高頻度に送信される応答信号１の監視結果に基づき、アプリ１の異常兆候を検出すると、モード切り換え部３２に通知する。したがって、アプリ１においても動作が停止する前に異常兆候が検出されるので、モード切り換え部３２はアプリ１が停止する前にアプリ１を復帰させること（例えば、新たにアプリ１を起動し、不安定なアプリ１を停止させる）などの適切な対応が可能になる。すなわち、アプリ１のＡＳＩＬの安全性レベルに対し適切な対応が可能になる。

〔動作手順〕
図６は、マイコン５０又はマイコンシステム１００の動作手順を示すフローチャート図の一例である。この手順は、マイコン５０又はマイコンシステム１００が起動中、繰り返し実行される。

アプリ１は決められた周期で応答信号１の送信を応答送信部３１に要求し、アプリ２は決められた周期で応答信号２の送信を応答送信部３１に要求する（Ｓ１、Ｓ２）。

応答送信部３１は、アプリ１の送信要求に対し応答信号１を応答監視部３３に送信し、アプリ２の送信要求に対し応答信号２を応答監視部３３に送信する（Ｓ３、Ｓ４）。

応答監視部３３は応答信号１、応答信号２の統計期間当たりの受信回数をそれぞれ別々にカウントする（Ｓ５、Ｓ６）。

応答監視部３３は、応答信号１の受信回数及び応答信号２の受信回数に基づき異常兆候が検出されるか否かを判定する（Ｓ７）。どちらの受信回数にも異常兆候が検出されない場合（Ｓ７のＮｏ）、応答監視部３３は何もせず、処理はステップＳ１に戻る（図の“Ａ”）。

どちらかの受信回数に異常兆候が検出された場合（Ｓ７のＹｅｓ）、応答監視部３３は応答信号の識別情報と共に異常兆候が検出されたことをモード切り換え部３２に通知する（Ｓ８）。

モード切り換え部３２は、アプリ１又はプリ２に異常兆候が検出された場合、通常実行状態からフェールセーフ状態に切り替える（Ｓ９）。アプリ２の優先度（ＡＳＩＬ）が監視対象のアプリの中で最も低いこと又は所定の優先度以下であることを確認する。アプリ２の優先度（ＡＳＩＬ）を確認することで、優先度の高いアプリを停止することを防止できる。なお、アプリ１の異常兆候が検出された場合、モード切り換え部３２はアプリ１の異常兆候に対し、アプリ１のＡＳＩＬに応じて予め定められた処理を行う。

また、モード切り換え部３２は最も優先度の低い又は優先度が所定値以下のアプリ２を停止させる（Ｓ９−１）。このように、異常兆候が検出されるアプリと停止されるアプリには直接の関係はない。また、アプリ１と応答監視部３３にフェールセーフ状態への切り換えを通知する（Ｓ９−２，Ｓ９−３）。

アプリ１は、フェールセーフ状態への切り換えにより、それまでのアプリ１の送信タイミング１に加えアプリ２の送信タイミング２で応答信号１の送信を応答送信部３１に要求する（Ｓ１０，Ｓ１１）。

応答送信部３１は、アプリ１の送信要求に対し応答信号１を応答監視部３３に送信する（Ｓ１２、Ｓ１３）。

応答監視部３３は、応答信号１の統計期間当たりの受信回数をカウントする（Ｓ１４、１５）。フェールセーフ状態への切り換えにより、Ｓ１４、Ｓ１５の統計期間はＳ５，６よりも短くなっている。

応答監視部３３は、応答信号１の受信回数から異常兆候が検出されるか否かを判定する（Ｓ１６）。通常実行状態よりも送信頻度が多くなり、統計期間も短くなっているので、高精度に異常兆候の有無を判定できる。

応答信号１の受信回数に異常兆候が検出されない場合（Ｓ１６のＮｏ）、応答監視部３３は何もせず、処理はステップＳ１０に戻る（図の“Ｂ”）。

応答信号１の受信回数に異常兆候が検出された場合（Ｓ１６のＹｅｓ）、応答監視部３３は応答信号の識別情報と共に異常兆候が検出されたことをモード切り換え部３２に通知する（Ｓ１７）。モード切り換え部３２はアプリ１の異常兆候に対し、アプリ１の復帰を試みるなどのＡＳＩＬに応じて予め定められた処理を行う（Ｓ１８）。

以上説明したように、本実施例のマイコン５０又はマイコンシステム１００は、複数のアプリのうち一つ以上のアプリが停止する前に異常兆候を検出することで、マイコン５０をリセットすることなく、残りのアプリを動作させることができる。一方、１つでもアプリが不安定になるとマイコン全体が不安定になる可能性が高いので、フェールセーフ状態では監視を強化することで、残りのアプリの異常兆候を高精度に検出する。いずれの場合もアプリは完全に停止していないので、アプリが不安定ながらも動作している間に適切な対応が可能になる。また、フェールセーフ状態で監視を強化しても、マイコン５０やマイコンシステム全体の送信頻度はほぼ変わらないので、マイコン５０やマイコンシステム全体の負荷が大きくなることを抑制できる。

〔変形例〕
図７は、アプリが３つある場合のマイコン５０又はマイコンシステム１００の概略を説明する図の一例である。

図７（ａ）は通常実行状態の応答信号１〜３を模式的に示す。３つのアプリ１〜３はそれぞれの周期で応答信号１〜３を監視マイコン６０に送信している。例えば、最も優先度（ＡＳＩＬ）の低いアプリ３に異常兆候が検出された場合、マイコン５０はフェールセーフ状態になり、アプリ３を停止するか又は監視対象外にする。アプリ１，２に異常兆候が検出された場合も、最も優先度の低いアプリ３を停止するか又は監視対象外にする。アプリ３が応答信号３を送信しないので、アプリ１，２がアプリ３の送信タイミング３を使用して応答信号１，２を送信する。

アプリ１，２がアプリ３の送信タイミング３や周期を知っていても、アプリ３の１つの送信タイミング３では応答信号１又は２のいずれかしか送信できない。この場合、アプリ１，２が通信して送信タイミングを決定するなどの複雑な処理が必要になり好ましくない。そこで、アプリ３の送信タイミング３をそのまま使用するのでなく、アプリ１，２はフェールセーフ状態用の送信タイミングで送信する。

図７（ｂ）はフェールセーフ状態の応答信号１〜３を模式的に示す。図７（ｂ）の矢印の上側では、アプリ１とアプリ２の送信タイミングが通常実行状態とフェールセーフ状態で変わっている。しかし、アプリ１，２がフェールセーフ状態用の送信タイミングで送信することで、アプリ１とアプリ２は交互に応答信号１，２を送信することができる。なお、アプリ１とアプリ２の送信頻度が同じである必要はなく、例えば、ＡＳＩＬが高いアプリの送信頻度を大きくすることができる。

または、アプリ１はアプリ１とアプリ３の送信タイミングで応答信号１の送信を応答送信部３１に要求して、アプリ２はアプリ２とアプリ３の送信タイミングで応答信号２の送信を応答送信部３１に要求してもよい。応答送信部３１は、アプリ１とアプリ２の送信要求を取得して、通常実行状態よりも送信頻度が多くならないように一部の送信要求を破棄する。図７（ｂ）の矢印の下側に示すように、この場合、アプリ１とアプリ２の送信タイミングが通常実行状態とフェールセーフ状態でほぼ同じまま、アプリ３の送信タイミングで応答信号１または応答信号２を送信できる。応答信号１，２が交互になるとは限らないが、応答信号１，２の送信頻度は同程度である。

なお、フェールセーフ状態の応答信号１，２の合計の送信頻度は、通常実行状態の応答信号１〜３の合計の送信頻度と同じである。これにより、フェールセーフ機能と通常実行状態とで応答送信部３１の負荷が変わることを抑制できる。

このように本実施例の異常監視方法は、アプリが３つ以上動作するマイコン５０又はマイコンシステム１００に対しても同様に適用することができる。

図８（ａ）は、複数のマイコン５０のアプリを１つの監視マイコン６０で監視するマイコンシステム１００の一例を示す図である。これまでの説明では１つのマイコン５０で複数のアプリが動作しているが、マイコン５０が複数存在して、それぞれのマイコン５０がアプリ１，２を実行しても、本実施例の異常監視方法は好適に適用できる。図示する形態では、アプリ１，２がそれぞれ監視マイコン６０に応答信号１，２を送信すればよく、アプリ１，２が１つのマイコン内で動作する場合とほぼ同様になる。

また、この場合、１つのマイコン１又はマイコン２が複数のアプリを実行してもよい。したがって、アプリの数は３つ以上になるが、図７にて説明したようにアプリの数が３つ以上でも異常監視方法は同様になる。

図８（ｂ）は、複数のＥＣＵ１，２が実行するアプリ１，２を１つの監視マイコン６０で監視するマイコンシステム１００の一例を示す図である。ＥＣＵ１〜３はＣＡＮ等の車載ネットワークを介して接続されている。

図示するように、ＥＣＵ１，２が複数存在して、それぞれのマイコン１，２がアプリ１，２を実行しても、本実施例の異常監視方法は好適に適用できる。図示する形態では、アプリ１，２が、それぞれ監視マイコン６０が搭載されたＥＣＵに応答信号１，２を車載ネットワーク経由で送信すればよく、アプリ１，２が１つのマイコン内で動作する場合とほぼ同様になる。また、この場合、ＥＣＵ１，２のマイコンが複数のアプリを実行してもよい。

図８（ａ）（ｂ）に示すように、本実施例の異常監視方法では、１つの監視マイコン６０が複数のアプリを監視する態様において、複数のアプリが１つのマイコン内にあるか、複数のマイコン内（１つのＥＣＵ内）にあるか、複数のＥＣＵにあるかを問わない。

実施例１では、フェールセーフ状態において、アプリ１が応答信号１の送信頻度を増大させることで監視を強化した。本実施例では、アプリ１の応答信号１に加え動作状態を送信することで監視を強化するマイコン５０又はマイコンシステム１００について説明する。

図９は、マイコン５０又はマイコンシステム１００の機能ブロック図の一例を示す。図９において図３と同一部には同一の符号を付しその説明は省略する。本実施例のマイコン５０又はマイコンシステム１００は、動作状態送信部３４と高度監視部３５を新たに有する。なお、フェールセーフ状態になるまでの処理は実施例１と同様である。

これに対し、本実施例のモード切り換え部３２は、異常兆候の検出通知を取得すると、以下のような処理を行う。
・アプリＡＳＩＬ情報３６を参照して、アプリ２の優先度（ＡＳＩＬ）が他のアプリ１よりも低いことを確認する。すなわち、最も優先度が低いアプリであることを確認する。または、最も優先度が低くなくても、予め定められた優先度以下であることを確認する。
・アプリ２を停止、又は、アプリ２を監視対象外とする（アプリ２に応答信号２の送信を停止させる、又は、アプリ２から応答信号２の送信要求を受け付けても応答信号２の送信を行わない）
・アプリ１と監視マイコン６０にフェールセーフ状態になったことを通知する
・動作状態送信部３４を起動させる
・高度監視部３５を起動させる
動作状態送信部３４は動作状態情報を、応答送信部３１を経由して高度監視部３５に送信するものであり、高度監視部３５は動作状態情報に基づきフェールセーフ状態で動作するアプリ１を監視するものである。

動作状態情報は、例えば、ＣＰＵ負荷、ＡＰＩ利用頻度、特定ＡＰＩ利用回数などである。ＣＰＵ負荷は、ＮＯＰなどの空命令を繰り返し実行するアイドル状態の時間とアプリ１の実行時間の合計に対する、アプリ１の実行時間の割合である。

また、ＡＰＩ利用頻度は、アプリ１がＯＳなどのＡＰＩを呼び出す頻度を数値化した値である。アプリ１は、ＡＰＩを通してＯＳなどの機能を利用する。アプリ１に異常がなければ、ＡＰＩの利用頻度は大きな変動がなく推移し、アプリ１に異常が生じ始めるとそれまで利用していたＡＰＩの利用頻度が減少したり、それまであまり利用していなかったＡＰＩの利用頻度が増大する。このため、ＡＰＩの利用頻度はアプリ１の安定性と相関性がある。

特定ＡＰＩ利用回数は、所定時間内に、特定のＡＰＩを利用してＯＳの機能を呼び出した回数である。アプリ１は、ＣＰＵ負荷が高い場合や、予め定められた状況が生じた場合、その時のステータス情報を記録したり、ログを記録したりする。このようなＡＰＩは異常に関係が深いことが知られている。よって、予め異常に結びつきやすいＡＰＩをいくつか特定しておけば、このＡＰＩの利用回数である特定ＡＰＩ利用回数は、アプリ１の安定性を監視する指標となる。

動作状態送信部３４は、ＣＰＵ負荷、アプリ１のＡＰＩ利用頻度、及び、特定ＡＰＩ利用回数を応答送信部３１に送信する。応答送信部３１は、アプリ１からの応答信号１と動作状態情報を応答監視部３３に送信する。応答送信部３１は、通常実行状態と同じ送信タイミング１で応答信号１を送信し、送信タイミング２で動作状態情報を送信する。

高度監視部３５は、動作状態情報を監視してアプリ１に異常兆候が検出されるか否かを判定する。高度監視部３５が、アプリ１が不安定であると判定すると、モード切り換え部３２に通知する。これにより、モード切り換え部３２はアプリ１の復帰を試みるなど、アプリ１のＡＳＩＬに応じた処理を行うことが可能になる。このように、動作状態送信部３４が、アプリ１の動作状態を検出して高度監視部３５に送信することで、高度監視部３５は応答信号１の受信回数以外からアプリ１の状態を把握・分析することができる。

〔動作状態情報の送信〕
図１０は、本実施例のフェールセーフ状態における応答信号及び動作状態情報の送信を説明する図の一例である。
・実施例１と同様に、フェールセーフ状態ではアプリ２は停止されるか、応答監視部３３の監視対象外となるので、応答送信部３１が応答信号２を応答監視部３３に送信することはない。
・アプリ１は、フェールセーフ状態になっても、通常実行状態と同じ周期で応答信号１の送信を応答送信部３１に要求する。
・動作状態送信部３４は、例えば、動作状態情報に変化が見られると、動作状態情報を送信するよう応答送信部３１に要求する。
・応答送信部３１は、アプリ２の送信タイミングを使用して動作状態情報を応答監視部３３に送信する。図１０の“ｄ”の四角が動作状態情報を示している。応答信号１と動作状態情報の合計の送信頻度は、通常実行状態における応答信号１、２の送信頻度と同じなので、マイコン５０やマイコンシステム１００の負荷はほぼ変更されない。

高度監視部３５は、ＣＰＵ負荷、ＡＰＩ利用頻度、及び、特定ＡＰＩ利用回数を時系列に監視して、それぞれ異常兆候が検出されるか否かを判定する。例えば、ＣＰＵ負荷の場合、ＣＰＵ負荷の傾きを算出して、傾きが閾値以上であれば異常傾向があると判定する。ＣＰＵ負荷の絶対値に着目してもよい。

また、高度監視部３５は、過去の数個のＡＰＩ利用頻度の分散を算出して、閾値と比較することでアプリ１が不安定であるか否かを判定する。また、高度監視部３５は、特定ＡＰＩ利用回数の傾きを算出して、傾きが閾値以上向であれば異常傾向があると判定する。特定ＡＰＩ利用回数の絶対値に着目してもよい。

ところで、図５では動作状態情報が３つとしたが、このように種類が多いと、１回の送信タイミング２で全ての動作状態情報を送信することができない（間に合わない）おそれがある。このような場合は、動作状態情報を１回の送信タイミング２で送信するのでなく、複数の送信タイミング２に分散させることが有効である。

図１１（ａ）は、送信タイミングと送信される動作状態情報を説明する図の一例である。図１０と同様に、通常実行状態とフェールセーフ状態とで応答信号１の送信タイミングは同じである。これに対し、動作状態情報が送信される送信タイミング２では、ＣＰＵ負荷、アプリ利用頻度、特定ＡＰＩ利用回数が順番に送信されている。ＣＰＵ負荷、アプリ利用頻度、特定ＡＰＩ利用回数は、短時間に急激に変動するものではないので、すべての送信タイミング２で送信しなくても、異常兆候の監視に大きな不都合はない。

したがって、通常実行状態に対しフェールセーフ状態の送信頻度を増大させないことで、マイコン５０またはマイコンシステム１００の負荷をほぼ同じに保つことがない。

また、一種類の動作状態情報が１つの送信タイミング２で送信可能なデータ量を超える場合もありうる。図１１（ｂ）は、送信タイミングと送信される動作状態情報を説明する図の別の一例である。図１１（ｂ）では、１つのＡＰＩ利用頻度が２つ（ＡＰＩ利用頻度１とＡＰＩ利用頻度２）に分けて送信されている。このように、一種類の動作状態情報のデータ量が大きくても、複数の送信タイミング２で送信できるので、マイコン５０またはマイコンシステム１００の負荷を大きく変えることなく、動作状態情報を送信できる。

〔動作手順〕
図１２は、本実施例のマイコン５０又はマイコンシステム１００の動作手順を示すフローチャート図の一例である。図１２において、マイコン５０又はマイコンシステム１００がフェールセーフ状態になるステップＳ９までの手順は図６と同様である。

モード切り換え部３２は、アプリ１又はアプリ２に異常兆候が検出された場合、通常実行状態からフェールセーフ状態に切り替える（Ｓ９）。アプリ２の優先度（ＡＳＩＬ）が監視対象のアプリの中で最も低いこと又は所定の優先度以下であることを確認する。また、モード切り換え部３２は最も優先度が低いか又は所定の優先度以下のアプリ２を停止させる（Ｓ９−１）。また、アプリ１と応答監視部３３にフェールセーフ状態への切り換えを通知する（Ｓ９−２，Ｓ９−３）。また、モード切り換え部３２は動作状態送信部３４を起動する（Ｓ９−４）。なお、モード切り換え部３２は高度監視部３５も起動させるが図示を省略している。

起動された動作状態送信部３４はアプリ１の監視を開始する（Ｓ２０）。監視対象は、アプリ１を実行するＣＰＵ１１のＣＰＵ負荷、ＡＰＩ利用頻度、特定ＡＰＩ利用回数などである。

アプリ１は、フェールセーフ状態へ切り換えられても通常実行状態と同様の送信タイミング１で応答信号１の送信を応答送信部３１に要求する（Ｓ１０）。

応答送信部３１は、アプリ１の送信要求に対し応答信号１を応答監視部３３に送信する（Ｓ１２）。

応答監視部３３は、応答信号１の統計期間当たりの受信回数をカウントする（Ｓ１４）。フェールセーフ状態へ切り換えてもＳ１４の統計期間とＳ５の統計期間は同じである。

動作状態送信部３４は、アプリ１の動作状態に変化があったか否かを判定する（Ｓ２１）。この判定により、アプリ１の動作状態に変化がある場合にのみ、動作状態情報を送信することができる（Ｓ２２）。なお、ステップＳ２１の判定をすることなく動作状態情報を送信してもよい。

応答監視部３３は、応答信号１の受信回数に異常兆候が検出されるか否かを判定する（Ｓ１６）。

応答信号１の受信回数に異常兆候が検出されない場合（Ｓ１６のＮｏ）、高度監視部３５は動作状態情報から異常傾向が検出されるか否かを判定する（Ｓ２３）。

動作状態情報から異常傾向が検出されない場合（Ｓ２３のＮｏ）、高度監視部３５は何もせず、処理はステップＳ１０に戻る。

応答信号１の受信回数に異常兆候が検出された場合（Ｓ１６のＹｅｓ）、又は、動作状態情報から異常傾向が検出された場合（Ｓ２３のＹｅｓ）、応答監視部３３又は高度監視部３５は応答信号の識別情報と共に異常兆候検出をモード切り換え部３２に通知する（Ｓ１７）。モード切り換え部３２はアプリ１の異常兆候に対し、アプリ１の復帰を試みるなどのＡＳＩＬに応じて予め定められた処理を行う（Ｓ１８）。

本実施例では、フェールセーフ状態の応答信号１の送信頻度は実施例１よりも少ないが、高度監視部３５はアプリ１の動作状態情報に基づき異常兆候を検出するので、より多様な情報に基づきアプリ１の異常兆候を検出できる。

１９ 異常監視回路
３１ 応答送信部
３２ モード切り換え部
３３ 応答監視部
３４ 動作状態送信部
３５ 高度監視部
５０ マイコン
６０ 監視マイコン
１００ マイコンシステム

Claims (9)

1. 動作中であることを通知する動作中通知を周期的にアプリ監視手段に送信する複数のアプリケーションと、
   第一のカウント期間におけるアプリケーション毎の動作中通知の回数をカウントするアプリ監視手段と、
   アプリケーションの動作を制御するアプリ制御手段と、を有し、
   前記アプリ監視手段が各アプリケーションの過去の前記第一のカウント期間における動作中通知の回数に基づき、少なくとも１つのアプリケーションの異常兆候を検出した場合、
   前記アプリ制御手段は、優先度が最も低いアプリケーションの動作中通知の送信を停止し、
   異常兆候が検出されていないアプリケーションは、異常兆候が検出される前と同じタイミングと、動作中通知の送信が停止されたアプリケーションが動作中通知を送信するタイミング又はその前後のタイミングで、動作中通知を送信する、
   ことを特徴とする情報処理装置。
2. 前記アプリ監視手段がアプリケーションの異常兆候を検出した場合、異常兆候が検出されていないアプリケーションの動作状態を検出する動作状態検出手段を有し、
   異常兆候が検出されていないアプリケーションは、異常兆候が検出される前と同じタイミングでのみ動作中通知を送信し、
   前記動作状態検出手段は、異常兆候が検出されたアプリケーションが動作中通知を送信するタイミング又はその前後のタイミングで、動作状態情報を前記アプリ監視手段に送信する、
   ことを特徴とする請求項１記載の情報処理装置。
3. 前記アプリ監視手段は、前記第一のカウント期間におけるアプリケーションの動作中通知の回数が減少傾向にある場合、又は、動作中通知の回数の変動量が閾値以上の場合、アプリケーションに異常兆候があることを検出する、
   ことを特徴とする請求項１記載の情報処理装置。
4. 前記アプリ監視手段は、アプリケーションの異常兆候を検出した場合、前記第一のカウント期間より短い第二のカウント期間で、異常兆候が検出されていないアプリケーションの動作中通知の回数をカウントし、
   前記第二のカウント期間における動作中通知の回数に基づき、異常兆候が検出されていないアプリケーションの異常兆候を検出する、
   ことを特徴とする請求項１又は３項記載の情報処理装置。
5. 前記動作状態情報は、アプリケーションを実行するＣＰＵのＣＰＵ負荷、アプリケーションが呼び出すＯＳ又はミドルウェアのＡＰＩの利用頻度、又は、異常時に呼び出されるＡＰＩとして予め定められた特定ＡＰＩの利用回数の１つ以上である、ことを特徴とする請求項１〜３いずれか２項記載の情報処理装置。
6. 前記アプリ監視手段は、過去のＣＰＵ負荷、ＡＰＩの利用頻度、又は、特定ＡＰＩの利用回数に基づき、各アプリケーションの異常兆候を検出する、
   ことを特徴とする請求項５記載の情報処理装置。
7. 前記動作状態検出手段は、過去のＣＰＵ負荷、ＡＰＩの利用頻度、又は、特定ＡＰＩの利用回数のいずれか１つを、２回以上の送信タイミングに分けてアプリ監視手段に送信する、
   ことを特徴とする請求項５又は６記載の情報処理装置。
8. 動作中であることを通知する動作中通知を周期的にアプリ監視手段に送信する複数のアプリケーションと、
   第一のカウント期間におけるアプリケーション毎の動作中通知の回数をカウントするアプリ監視手段と、
   アプリケーションの動作を制御するアプリ制御手段と、を有し、
   前記アプリ監視手段が各アプリケーションの過去の前記第一のカウント期間における動作中通知の回数に基づき、少なくとも１つのアプリケーションの異常兆候を検出した場合、
   前記アプリ制御手段は、異常兆候が検出されたアプリケーションの優先度が異常兆候が検出されていないアプリケーションよりも低いことを確認した後、異常兆候が検出されたアプリケーションの動作中通知の送信を停止し、
   異常兆候が検出されていないアプリケーションは、異常兆候が検出される前と同じタイミングと、異常兆候が検出されたアプリケーションが動作中通知を送信するタイミング又はその前後のタイミングで、動作中通知を送信する、
   ことを特徴とする情報処理装置。
9. 動作中であることを通知する動作中通知を周期的にアプリ監視手段に送信する複数のアプリケーションと、
   アプリケーションの動作を制御するアプリ制御手段と、を有する第一の情報処理装置と、
   第一のカウント期間におけるアプリケーション毎の動作中通知の回数をカウントするアプリ監視手段、を有する第二の情報処理装置と、を有する情報処理システムであって、
   前記アプリ監視手段が各アプリケーションの過去の前記第一のカウント期間における動作中通知の回数に基づき、少なくとも１つのアプリケーションの異常兆候を検出した場合、
   前記アプリ制御手段は、最も優先度が低いアプリケーションの動作中通知の送信を停止し、
   異常兆候が検出されていないアプリケーションは、異常兆候が検出される前と同じタイミングと、動作中通知の送信が停止されたアプリケーションが動作中通知を送信するタイミング又はその前後のタイミングで、動作中通知を送信する、
   ことを特徴とする情報処理システム。

Images