JP2013143093A - Information processing apparatus and information processing system - Google Patents
Information processing apparatus and information processing system Download PDFInfo
- Publication number
- JP2013143093A JP2013143093A JP2012004227A JP2012004227A JP2013143093A JP 2013143093 A JP2013143093 A JP 2013143093A JP 2012004227 A JP2012004227 A JP 2012004227A JP 2012004227 A JP2012004227 A JP 2012004227A JP 2013143093 A JP2013143093 A JP 2013143093A
- Authority
- JP
- Japan
- Prior art keywords
- application
- detected
- response
- microcomputer
- abnormal sign
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Pending
Links
Images
Landscapes
- Debugging And Monitoring (AREA)
Abstract
Description
本発明は、実行しているアプリの異常を検出する情報処理装置等に関する。 The present invention relates to an information processing apparatus that detects an abnormality of a running application.
車両ではマイコンにより制御される車載装置が多く搭載されており、車載装置の安全性を確保するため、車載装置と共に安全装置を搭載することが一般的である。安全装置はマイコンや車載装置の機能が仕様にしたがって動作しているか否かを監視し、故障などが検出されると機能を停止したり、外部に通知するなどのフェールセーフ機能を提供する。このような安全性の確保や得られる安全性そのものを機能安全と呼ぶ。 Many in-vehicle devices controlled by a microcomputer are mounted on a vehicle, and it is common to mount a safety device together with the in-vehicle device in order to ensure the safety of the in-vehicle device. The safety device monitors whether the functions of the microcomputer and the in-vehicle device are operating according to the specification, and provides a fail-safe function such as stopping the function or notifying the outside when a failure or the like is detected. Such ensuring of safety and the obtained safety itself are called functional safety.
車両の機能安全については、IEC61508/ISO26262等に規格化されており、ISO26262では自動車の安全要求と安全対策を指定する指標としてASIL(Automotive Safety Integrity Level)が定められている。ASILはA〜D、QM(D>C>B>A>QM)の安全性レベルが定められており、各部品がどの安全性レベルを満たすべきか、部品が関わる安全性に応じてメーカが決定することができる。このため、安全性に重大な影響がある部品のASILは高くなる。 The functional safety of vehicles is standardized in IEC61508 / ISO26262 and the like, and ASIL (Automotive Safety Integrity Level) is defined as an index for designating safety requirements and safety measures for automobiles. ASIL has a safety level of A to D and QM (D> C> B> A> QM), and the manufacturer determines which safety level each component should meet and the safety related to the component. Can be determined. For this reason, the ASIL of parts that have a significant impact on safety is high.
例えば、マイコンではプロセッサについてASILを定めることができるし、マイコン上で動作するアプリケーションについてもASILを定めることができる。メーカとしては、高い機能安全を確保していることをアピールするために高い安全性レベルのASILを指定することができるが、その安全性レベルに見合った監視が必要になる。 For example, an ASIL can be determined for a processor in a microcomputer, and an ASIL can be determined for an application operating on the microcomputer. As a manufacturer, an ASIL having a high safety level can be designated to appeal that high functional safety is ensured, but monitoring corresponding to the safety level is required.
例えば、1つのマイコン上で複数のアプリケーション1,2が動作する場合がある。この場合、メーカは、車載装置を制御するアプリケーション1の安全性レベルをASIL A、車載装置の制御と直接的な関連性の低いアプリケーション2の安全性レベルをQM、と定めることができる。
For example, a plurality of
安全装置としては、ASILの安全性レベルに応じた監視が必要になる。例えば、高ランクのアプリケーションに異常が検出された場合、そのアプリケーションを復帰するための処理が優先される。しかし、低ランクのアプリケーションに異常が検出された場合、安全装置は高ランクのアプリケーションの挙動に影響を与えてまで、低ランクのアプリケーションの復帰処理を優先すべきではない。 As a safety device, monitoring according to the safety level of ASIL is required. For example, when an abnormality is detected in a high-rank application, priority is given to processing for returning the application. However, if an anomaly is detected in a low-rank application, the safety device should not prioritize the return process for the low-rank application until it affects the behavior of the high-rank application.
ここで、従来からアプリケーションの動作を監視する仕組みとしてWDT(Watch Dog Timer)が知られている。しかしながら、WDTは、アプリケーションが一定時間、タイマリセットしないとマイコンをリセットしてしまうため、その間、マイコンを使用できず処理が止まってしまう。 Here, WDT (Watch Dog Timer) is known as a mechanism for monitoring the operation of an application. However, since the WDT resets the microcomputer if the application does not reset the timer for a certain period of time, the microcomputer cannot be used during that time, and processing stops.
アプリケーションに何らかの異常が検出された場合に処理を継続する方法として、処理系を二重化する方法がある(例えば、特許文献1参照。)。特許文献1には、主処理部と補助処理部が互いに処理内容を監視し、データ処理をしている一方の処理部が処理の途中でダウンした場合に切替手段が、回線に接続する主処理部と補助処理部を切り替えるフォールトトレラント計算器が開示されている。
As a method of continuing processing when an abnormality is detected in an application, there is a method of duplicating a processing system (see, for example, Patent Document 1). In
また、WDTと同様に監視対象の応答の有無を監視して異常を検出する技術が考えられている(例えば、特許文献2参照。)。特許文献2には、監視対象である通信装置にテスト信号を送信し、テスト信号の送信時から所定時間以内に応答を受信したか否かにより通信異常を判定する診断システムが開示されている。
Further, a technique for detecting an abnormality by monitoring the presence / absence of a response to be monitored as in the case of WDT has been considered (for example, see Patent Document 2).
しかしながら、特許文献1に開示されているようにシステムを二重化する方法ではコスト増となるため高い安全性レベルでアプリケーションを監視できても、全てのアプリケーションの監視に採用することは困難である。
However, as disclosed in
また、特許文献2では異常と判定された場合に異常と関係のある通信装置に通知するだけで、どのようにフェールセーフ制御するかについて記載されていない。すなわち、異常が検出された場合に処理を止めずに継続することについて考慮されていない。
Further,
本発明は、上記課題に鑑み、2つ以上のアプリケーションの一方に異常が検出されても、他方のアプリケーションを継続して実行可能な情報処理装置を提供することを目的とする。 In view of the above problems, an object of the present invention is to provide an information processing apparatus that can continuously execute the other application even if an abnormality is detected in one of the two or more applications.
本発明は、動作中であることを通知する動作中通知を周期的にアプリ監視手段に送信する複数のアプリケーションと、第一のカウント期間におけるアプリケーション毎の動作中通知の回数をカウントするアプリ監視手段と、アプリケーションの動作を制御するアプリ制御手段と、を有し、前記アプリ監視手段が各アプリケーションの過去の前記第一のカウント期間における動作中通知の回数に基づき、少なくとも1つのアプリケーションの異常兆候を検出した場合、前記アプリ制御手段は、優先度が最も低いアプリケーションの動作中通知の送信を停止し、異常兆候が検出されていないアプリケーションは、異常兆候が検出される前と同じタイミングと、動作中通知の送信が停止されたアプリケーションが動作中通知を送信するタイミング又はその前後のタイミングで、動作中通知を送信する、ことを特徴とする。 The present invention provides a plurality of applications that periodically transmit an in-operation notification for notifying that it is in operation to the application monitoring unit, and an application monitoring unit that counts the number of in-operation notifications for each application in the first count period And an application control means for controlling the operation of the application, wherein the application monitoring means displays an abnormality sign of at least one application based on the number of in-operation notifications in the first count period in the past of each application. If detected, the application control means stops sending the operation notification of the application with the lowest priority, and the application in which no abnormal sign is detected is operating at the same timing as before the abnormal sign is detected. The timing at which an application whose notification transmission has been stopped transmits an operational notification or At a timing before and after, and transmits through the operation notification, characterized in that.
2つ以上のアプリケーションの一方に異常が検出されても、他方のアプリケーションを継続して実行可能な情報処理装置を提供することができる。 Even if an abnormality is detected in one of two or more applications, an information processing apparatus capable of continuously executing the other application can be provided.
以下、本発明を実施するための形態について図面を参照しながら説明する。 Hereinafter, embodiments for carrying out the present invention will be described with reference to the drawings.
図1は、監視マイコンによるマイコンの異常監視の概略を説明する図の一例である。本実施形態の異常監視は、大きく通常監視状態とフェールセーフ状態に分けて説明することができる。 FIG. 1 is an example of a diagram for explaining an outline of microcomputer abnormality monitoring by a monitoring microcomputer. The abnormality monitoring of the present embodiment can be broadly described by being divided into a normal monitoring state and a fail-safe state.
・通常監視状態(図1(a))
通常監視状態とはアプリケーション(以下、単にアプリという)の動作に異常兆候が検出されていないマイコン50の状態であり、フェールセーフ状態と対比して使用される。マイコン50と監視マイコン60は通信可能に接続されている。マイコン50ではアプリ1及びアプリ2が動作しており、ほぼ定期的に応答送信部に応答信号1,2を送信するよう要求する。図の送信タイミング1がアプリ1の応答信号1の送信タイミングであり、送信タイミング2がアプリ2の応答信号2の送信タイミングである。応答送信部は従来のアプリがWDT(Watch Dog Timer)をリセットする場合と同様に、応答信号1,2を監視マイコン60に送信する。
Normal monitoring state (Fig. 1 (a))
The normal monitoring state is a state of the
監視マイコン60の応答監視部は、応答信号1と応答信号2を別々に監視し、統計間毎に受信回数を算出する。応答監視部は受信回数を時系列に記憶しており、その変動に基づき、アプリ1,2が停止する前に、異常兆候を検出する。例えば、図示するようにアプリ1の過去の受信回数が安定しているのに対し、アプリ2の受信回数が減少傾向にある場合、応答監視部はアプリ2の異常兆候を検出する。このように、アプリが完全に停止する前にアプリが不安定であることを検出できることが本実施例の特徴の1つである。不安定であることとは、いずれ停止したり応答しなくなることが予測される状態をいい、本実施例では不安定な状態を「異常兆候」と称する
・フェールセーフ状態(図1(b))
監視マイコン60がアプリ2の異常兆候を検出した場合、マイコン50はフェールセーフ状態になる。フェールセーフ状態では、優先度の低いアプリ2が例えば停止され、アプリ1は継続して動作する。ここで、本実施形態では、優先度の低いアプリ2の方が異常兆候が生じやすいという前提の下で説明する。優先度は例えばASILにより判定される。
The response monitoring unit of the
When the
アプリ1は、引き続き応答送信部に応答信号1の送信を要求する。アプリ2は停止しているので、応答送信部はアプリ2の応答信号2を監視マイコン60に送信する必要がない。このため、応答信号2の送信処理が不要になる。そこで、アプリ1は、応答信号2の送信タイミング2を利用して、アプリ1の応答信号1を監視マイコン60に送信する。すなわち、アプリ1は、送信タイミング1と送信タイミング2の両方で応答信号1を監視マイコン60に送信する。
The
応答信号1の送信頻度が2倍になるので、監視マイコン60の応答監視部は、マイコン50の監視を強化することができる。すなわち、応答監視部は、高頻度に送信される応答信号1の受信回数を監視して、受信回数が安定しているか否かを判定するので、受信回数の傾向を高精度に把握しやすくなり、アプリ1の異常兆候を検出しやすくなる。
Since the transmission frequency of the
このように、監視マイコン60は、マイコン50の一部の機能が不安定になってもすぐにはリセットしないので、マイコン50は引き続き処理を継続できる。また、一部のアプリに異常兆候が検出された後、他のアプリの監視を強化できるので、不安定なアプリ又はその停止により不安定でないアプリに異常が生じたとしても早期に検出して対応できる。
As described above, the
高優先度のアプリ1と低優先度のアプリ2について補足する。高優先度のアプリ1と低優先度のアプリ2は、それぞれ独立に動作するシステムであり、低優先度のアプリ2は高優先度のアプリ1よりも不安定になりやすい。仮に高優先度のアプリ1が不安定になったように見えても、低優先度のアプリ2に起因している可能性が高い。このため、本実施形態の監視マイコン60は、不安定になったアプリに関係なく低優先度のアプリ2を停止させる。最終的に、高優先度のアプリ1が不安定になった場合、従来どおり、高優先度のアプリ1に対しフェールセーフ処理が行われる。
It supplements about the
〔マイコンの構成例〕
図2は、本実施例のマイコンシステム100又はマイコン50の概略構成図の一例を示す。本実施例の異常監視方法は、図2(a)の監視マイコン60がマイコン50を監視する態様、図2(b)の1つのマイコン50が自身を監視する態様のいずれでも適用可能である。まず、図2(a)から説明する。
[Microcomputer configuration example]
FIG. 2 shows an example of a schematic configuration diagram of the
マイコン50は、システムバス9に接続されたCPU11、RAM12、フラッシュメモリ13及びWDT14を有し、周辺バス10に接続されたCANコントローラ16、ADC(A/Dコントローラ)17及びI/Oチャネル18を有し、システムバス9と周辺バス10がブリッジ15により接続されている。
The
CPU11は、フラッシュメモリ13に記憶されているプログラムを、RAM12を作業メモリにして実行する。CPU11は、マルチコアでもシングルコアでもよい。フラッシュメモリ13に記憶されたプログラムは、マイコン50が車載装置を制御するアプリ1,2の他、異常監視に使用されるプログラム、OS(Operating System)、ミドルウェア、デバイスドライバ等が含まれている。
The
WDT14は、従来と同様に、CPU11が実行するアプリ1,2が定期的にリセットするためのタイマを有しており、タイマがリセットされないことからアプリ1又はアプリ2の暴走を検出する。本実施例ではWDT14と同様の機能が監視マイコン60により得られるため、WDT14はなくてもよい。一方、監視マイコン60に異常が生じた場合のために、WDT14を搭載しておくことも有効である。この場合、WDT14は監視マイコン60がアプリ1,2両方の異常を検出するよりも長い時間、アプリ1,2のいずれからも応答がない場合に異常を検出する。
The
ブリッジ15は、システムバス9と周辺バス10の間の周波数や電圧の違いを吸収し、システムバス9に接続された回路と周辺バス10に接続された回路とを通信可能に接続する。CANコントローラ16は、マイコン50と監視マイコン60がECU(Electronic Control Unit)に搭載された場合に、他のECUと通信するための通信回路である。ADC17は、マイコン50に接続されたセンサのアナログ信号をデジタル信号に変換する。ADC17に加え、DAC(D/Aコントローラ)を有する場合もある。I/Oチャネル18には、他のマイコン、アクチュエータ、センサ、スイッチ等が接続される。
The
監視マイコン60もマイコン50と同様の構成を備えているが、必ずしも同一である必要はない。監視マイコン60は、CPU21、RAM22、フラッシュメモリ23、及び、I/Oチャネル24を有しているが、この他、一般的な回路を備えている。監視マイコン60のフラッシュメモリ13に記憶されたプログラムは、マイコン50を監視するためのプログラムであるが、OSやミドルウェア、デバイスドライバを有していてもよいし、さらに監視マイコン60が制御装置を制御するためのアプリが含まれていてもよい。
Although the
マイコン50と監視マイコン60は互いのI/Oチャネル18、24を介して接続されている。I/Oチャネル18、24は、例えば、I2C(Inter-Integrated Circuit)やUSART(Universal Synchronous Asynchronous Receiver Transmitter)などのシリアル通信の規格に従い互いに通信する。
The
図2(b)のように、マイコン内に異常監視回路19が配置される場合、監視マイコン60は不要となる。異常監視回路19は後述する監視マイコン60の機能を提供する回路である。この場合、CPU11と異常監視回路19はブリッジ15を介して通信する点を除けば図2(a)と同様である。
As shown in FIG. 2B, when the
以下では、マイコン50の異常監視がマイコンシステム100又はマイコン50のいずれにより実行されるかは特に制限しない。しかし、図2(a)の態様では、アプリ1やアプリ2だけでなくマイコン全体に異常が生じた場合にも監視マイコン60がそれを検出してリセットするなどの処理が可能になり信頼性がより向上する。図2(b)の態様では、1チップ内に異常監視回路19が含まれているので、コスト的、実装スペース的に有利である。
In the following, it is not particularly limited whether the
なお、本実施例のマイコン50又はマイコンシステム100は、主に車両のECUに搭載されることを想定している。車載されるECUには、その主要な機能により、エンジンECU、ブレーキECU、ボディECU、ナビゲーションECU(AV・情報処理ECU)、ゲートウェイECU等がある。本実施例のマイコン50又はマイコンシステム100はECUの機能の違いに影響されず搭載されることが可能である。
Note that it is assumed that the
図3は、マイコンシステム100又はマイコン50の機能ブロック図の一例である。マイコン50又はマイコンシステム100は、アプリ1,アプリ2、応答送信部31、応答監視部33、及び、モード切り換え部32を有する。
FIG. 3 is an example of a functional block diagram of the
<ASILについて>
まず、ASILについて説明する。アプリ1はASIL Aの安全性レベルが指定されており、アプリ2はASIL QMの安全性レベルが指定されている。ASILは、ハザード(障害)を避けるために達成する必要のある安全性のレベルである。ASILの決定に際しては、例えば、ハザードによって生じる被害の大きさ、ハザードの生じる頻度、ハザードが生じた場合の制御難易度がハザード毎に検討される。したがって、安全性に影響し、よく使用されるアプリほどASILが高くなる傾向になる。例えば、ブレーキを制御するアプリ、パワーステアリングを制御するアプリ等はASILが高く、直接、走行制御に影響しにくいナビやAV系のアプリのASILは低くなる。このような観点から、各アプリはQM、A〜Dの安全性レベルが与えられており、安全性レベルに応じた設計がなされている。
<About ASIL>
First, ASIL will be described.
本実施例では、異常兆候が検出されるアプリ2のASILがQMであれば、アプリ2の復帰を試みることなくアプリ1のみの動作を継続しても大きな支障はないとして説明する。また、一般に、複数の、ASILが異なるアプリが実行される場合、相対的に不安定になりやすいのはASILが低いアプリである。
In the present embodiment, it is assumed that if the ASIL of the
したがって、アプリ1のASILはA〜Dのうちいずれでもよい。また、アプリ2のASILはQMでなくてもよく、アプリ1のASILよりも低ければよい。この場合、アプリ2に異常兆候が検出され停止された状態で、アプリ1さえ動作を継続すればよいか否かは、アプリ毎に定まる設計方針である。すなわち、アプリ2の異常兆候が検出され停止された状態で、アプリ1だけが動作を継続する場合も、アプリ2の異常兆候が検出された時点でアプリ2の復帰が試みられる場合もある。アプリ単位の復帰方法には、例えば、新たなコアにアプリを割り当てたり、コア単位でリセットしたり、マイコンそのものをリセットするなどの方法がある。
Therefore, the ASIL of the
不安定になりやすいのはASILが低いアプリであるが、アプリ1とアプリ2のASILが同じ場合もあり得る。この場合、アプリ2に異常兆候が検出されたままアプリ1さえ動作を継続すればよいか否かは、アプリ毎に定まる設計方針である。
An application having a low ASIL is likely to become unstable, but the ASIL of the
アプリ1のASIL>アプリ2のASILの場合であって、アプリ1に異常兆候が検出されることもゼロではないと考えられる。この場合、本実施形態では、アプリ1に異常兆候が検出されたのは、アプリ2に起因すると判断してアプリ2を停止させる。この結果、アプリ1に異常兆候が検出されたままであれば、アプリ1の異常兆候の検出により、アプリ1の復帰が試みられることが多い。
If ASIL of
また、アプリ1の異常兆候が検出された場合にアプリ2のみ動作を継続してもよい。このような状況は、例えばアプリ1のASILがそれほど高くなく、アプリ1が使用されない状況で生じる。
Further, when an abnormality sign of the
<各機能について>
CPU11はアプリ1,2を実行する。CPU11がマルチコアの場合、あるコアがアプリ1を別のコアがアプリ2をそれぞれ継続的に実行する(またはタイマ割込みを利用するなどして定期的に実行してもよい)。CPU11がシングルコアの場合、1つのコアが時分割的にアプリ1,アプリ2を実行する。いずれの場合もアプリ1,2は、アクチュエータを制御したり、センサから信号を取得したり、スイッチをオン/オフするなど固有の処理に加え、定期的に応答送信部31に応答信号1,2の送信を要求する処理を行う。
<About each function>
The
応答送信部31、応答監視部33、及び、モード切り換え部32は、例えばOSやミドルウェアが提供する機能、又は、アプリ1,2とは別のアプリが提供する機能である。
The
応答送信部32は、アプリ1から応答信号1の送信要求を取得すると、応答監視部33に応答信号1を送信し、アプリ2から応答信号2の送信要求を取得すると、応答監視部33に応答信号2を送信する。応答監視部33は、応答信号1、2の監視結果に基づき、アプリ1又はアプリ2の異常兆候を検出する。
When the
モード切り換え部32は、アプリ2から異常兆候が検出されたという通知を取得すると、通常監視状態のマイコン50をフェールセーフ状態に切り替える。この切り替えのため、モード切り換え部32は以下の処理を行う。
・アプリASIL情報36を参照して、アプリ2の優先度(ASIL)が他のアプリ1よりも低いことを確認する。すなわち、最も優先度が低いアプリであることを確認する。または、最も優先度が低くなくても、予め定められた優先度以下であることを確認する。
・アプリ1又はアプリ2のいずれの異常兆候が検出された場合でも、アプリ2を停止、又は、アプリ2を監視対象外とする(アプリ2に応答信号2の送信を停止させる、又は、アプリ2から応答信号2の送信要求を受け付けても応答信号2の送信を行わない)
・アプリ1と監視マイコン60にフェールセーフ状態になったことを通知する
本実施例では、フェールセーフ状態のアプリ1は、アプリ2の送信タイミングも利用して応答信号1を送信する。例えば、アプリ1と2が同じ周期で応答信号を送信していた場合、アプリ1の応答信号1の送信周期は、通常実行状態に比べて1/2になる。このように送信周期が短くなるので、統計期間当たりの応答信号1の数が多くなり、応答監視部33によるアプリ1の監視精度が向上する。また、応答送信部31の送信頻度は変わらないので、マイコン50又はマイコンシステム100の負荷をほぼ変化させずに済む。
When the
-Referring to the
Even if any abnormal sign of the
Informing the
〔応答監視部による異常兆候の検出〕
図4は、応答送信部31による応答信号1,2の送信と、応答監視部33による応答信号1,2の監視を模式的に示す図の一例である。図4(a)はアプリ1,2共に正常な場合を示す。アプリ1はアプリ1の周期毎に応答送信部31に応答信号1を送信するよう要求する。アプリ2はアプリ2の周期毎に応答送信部31に応答信号2を送信するよう要求する。応答信号1,2は、アプリ1とアプリ2が動作していることを示す信号であり、両者を区別できる情報を含むものであればよい。
[Detection of abnormal signs by response monitoring unit]
FIG. 4 is an example of a diagram schematically illustrating transmission of
応答送信部31は、アプリ1、2から要求されたタイミングで、応答信号1,2を応答監視部33に送信する。アプリ1、2はそれぞれ決まった周期(例えば、100ミリ秒)で送信要求するので、タイミングが衝突することはないが、仮に衝突した場合は応答送信部31がASILの高いアプリ1を優先することで調整する。
The
応答監視部33は、応答信号1,2を識別して、それぞれを個別にカウントする。例えば、統計期間として1秒間に応答信号1を受信した回数、応答信号2を受信した回数をそれぞれカウントし記録する。こうすることで、1秒間に受信した回数を時系列に監視できる。周期が100ミリ秒だとすると、1秒間に10回、応答信号1,2が受信される。このため、図4(a)ではアプリ1,2の受信回数がほぼ10回になっている。
The
これに対し、図4(b)はアプリ2に異常兆候が見られる場合を示す。アプリ2が不安定になると、アプリ2は応答信号2の送信要求を周期的に出力しない場合がある(図の点線で囲まれた応答信号2は送信されない応答信号2を示す)。応答監視部33は、1秒間の応答信号1,2の受信回数をカウントするので、応答信号2の受信回数は徐々に小さくなったり、大きく変動したりする。応答監視部33は、過去の例えば数個のカウント値の傾きを算出し、傾きが閾値を超えた場合にアプリ2の異常兆候が検出されたと判定する。この閾値は、例えば、数秒以内に受信回数がゼロになる傾きとすることができる。
On the other hand, FIG. 4B shows a case where an abnormal sign is seen in the
また、応答監視部33は、過去の数個のカウント値の分散を算出して、閾値と比較することでアプリ2が不安定であるか否かを判定する。受信回数に一定の傾向がないが、増減が激しい場合には分散が大きくなるので、これによりアプリ2の異常兆候が検出されたと判定する。
In addition, the
また、応答監視部33は、例えば理想的な受信回数からの乖離量に基づき、アプリ2が不安定であることを検出してもよい。理想的な受信回数はアプリ毎に決まっているので(例えば、1秒間に10回)、過去の数個の受信回数の平均などが極端に少なければ(例えば、5回以下)、アプリ2の異常兆候を検出できる。
Further, the
〔フェールセーフ状態のマイコンの動作〕
図5は、フェールセーフ状態における応答信号1の送信方法を説明する図の一例である。
[Operation of fail-safe microcomputer]
FIG. 5 is an example of a diagram illustrating a method of transmitting the
モード切り換え部32により、アプリ2は、以下のように動作する。
・アプリ2が停止された場合、又は、アプリ2に応答信号2の送信を停止させた場合
CPU11がアプリ2を実行することがないので、アプリ2が応答送信2を送信要求することもない。
・アプリ2から応答信号2の送信要求を受け付けても応答信号2の送信を行わない場合
応答送信部31はアプリ2による応答送信2の送信要求を無視する。
The
-When the
When the transmission request for the
いずれの場合も、フェールセーフ状態では応答送信部31が応答信号2を応答監視部33に送信することはない。
In any case, the
アプリ1は、フェールセーフ状態になると、それまでのアプリ1の送信タイミング1に加え、アプリ2の送信タイミング2も使用して応答信号1の送信を応答送信部31に要求する。アプリ1には、このフェールセーフ状態の送信タイミングが予め設定されており、フェールセーフ状態になったという通知を取得するだけで送信周期を切り替えることができる。応答信号2が応答信号1に切り替わるだけなので、応答送信部31や応答監視部33の負荷にはほぼ変更がない。
When the
なお、応答信号2から応答信号1に置き換わった送信タイミング2は、通常実行状態の送信タイミング2と同一である必要はなく、通常実行状態の応答信号2の送信頻度と、応答信号2から置き換わった応答信号1の送信頻度が同じであればよい。すなわち、応答送信部31の送信頻度に通常実行状態とフェールセーフ状態とでほぼ変更がなければよい。
The
応答監視部33は、通常実行状態と同様に、応答信号1をカウントする。応答信号1と応答信号2の送信頻度が同じであった場合、フェールセーフ状態では応答信号1の送信頻度が倍になる。このため、通常実行状態の応答信号1の送信頻度が1秒間に10回であったなら、フェールセーフ状態の応答信号1の送信頻度は1秒間に20回となる。図5では2つの受信回数が図示されているが、左側の応答信号1の受信回数がほぼ20回になっている。
The
また、フェールセーフ状態では、応答監視部33の統計期間を1秒間のままとするのでなく、通常実行状態よりも統計期間を短くすることが好ましい。例えば、送信頻度が倍になったのであれば、統計期間が1/2になっても同じ数の受信回数が得られる。より短い時間間隔で同程度の受信回数を取得できるので、微小な変動を検出しやすくなる。アプリ1は、アプリ2が不安定になったことの影響を受けやすいと考えられるが、このように監視を強化することでアプリ1の異常兆候を精度よく検出できる。
In the fail-safe state, it is preferable that the statistical period of the
フェールセーフ状態の応答監視部33は、高頻度に送信される応答信号1の監視結果に基づき、アプリ1の異常兆候を検出すると、モード切り換え部32に通知する。したがって、アプリ1においても動作が停止する前に異常兆候が検出されるので、モード切り換え部32はアプリ1が停止する前にアプリ1を復帰させること(例えば、新たにアプリ1を起動し、不安定なアプリ1を停止させる)などの適切な対応が可能になる。すなわち、アプリ1のASILの安全性レベルに対し適切な対応が可能になる。
The
〔動作手順〕
図6は、マイコン50又はマイコンシステム100の動作手順を示すフローチャート図の一例である。この手順は、マイコン50又はマイコンシステム100が起動中、繰り返し実行される。
[Operation procedure]
FIG. 6 is an example of a flowchart illustrating an operation procedure of the
アプリ1は決められた周期で応答信号1の送信を応答送信部31に要求し、アプリ2は決められた周期で応答信号2の送信を応答送信部31に要求する(S1、S2)。
The
応答送信部31は、アプリ1の送信要求に対し応答信号1を応答監視部33に送信し、アプリ2の送信要求に対し応答信号2を応答監視部33に送信する(S3、S4)。
The
応答監視部33は応答信号1、応答信号2の統計期間当たりの受信回数をそれぞれ別々にカウントする(S5、S6)。
The
応答監視部33は、応答信号1の受信回数及び応答信号2の受信回数に基づき異常兆候が検出されるか否かを判定する(S7)。どちらの受信回数にも異常兆候が検出されない場合(S7のNo)、応答監視部33は何もせず、処理はステップS1に戻る(図の“A”)。
The
どちらかの受信回数に異常兆候が検出された場合(S7のYes)、応答監視部33は応答信号の識別情報と共に異常兆候が検出されたことをモード切り換え部32に通知する(S8)。
When an abnormal sign is detected in either reception count (Yes in S7), the
モード切り換え部32は、アプリ1又はプリ2に異常兆候が検出された場合、通常実行状態からフェールセーフ状態に切り替える(S9)。アプリ2の優先度(ASIL)が監視対象のアプリの中で最も低いこと又は所定の優先度以下であることを確認する。アプリ2の優先度(ASIL)を確認することで、優先度の高いアプリを停止することを防止できる。なお、アプリ1の異常兆候が検出された場合、モード切り換え部32はアプリ1の異常兆候に対し、アプリ1のASILに応じて予め定められた処理を行う。
The
また、モード切り換え部32は最も優先度の低い又は優先度が所定値以下のアプリ2を停止させる(S9−1)。このように、異常兆候が検出されるアプリと停止されるアプリには直接の関係はない。また、アプリ1と応答監視部33にフェールセーフ状態への切り換えを通知する(S9−2,S9−3)。
Further, the
アプリ1は、フェールセーフ状態への切り換えにより、それまでのアプリ1の送信タイミング1に加えアプリ2の送信タイミング2で応答信号1の送信を応答送信部31に要求する(S10,S11)。
By switching to the fail-safe state, the
応答送信部31は、アプリ1の送信要求に対し応答信号1を応答監視部33に送信する(S12、S13)。
The
応答監視部33は、応答信号1の統計期間当たりの受信回数をカウントする(S14、15)。フェールセーフ状態への切り換えにより、S14、S15の統計期間はS5,6よりも短くなっている。
The
応答監視部33は、応答信号1の受信回数から異常兆候が検出されるか否かを判定する(S16)。通常実行状態よりも送信頻度が多くなり、統計期間も短くなっているので、高精度に異常兆候の有無を判定できる。
The
応答信号1の受信回数に異常兆候が検出されない場合(S16のNo)、応答監視部33は何もせず、処理はステップS10に戻る(図の“B”)。
If no abnormality sign is detected in the number of receptions of the response signal 1 (No in S16), the
応答信号1の受信回数に異常兆候が検出された場合(S16のYes)、応答監視部33は応答信号の識別情報と共に異常兆候が検出されたことをモード切り換え部32に通知する(S17)。モード切り換え部32はアプリ1の異常兆候に対し、アプリ1の復帰を試みるなどのASILに応じて予め定められた処理を行う(S18)。
When an abnormal sign is detected in the number of receptions of the response signal 1 (Yes in S16), the
以上説明したように、本実施例のマイコン50又はマイコンシステム100は、複数のアプリのうち一つ以上のアプリが停止する前に異常兆候を検出することで、マイコン50をリセットすることなく、残りのアプリを動作させることができる。一方、1つでもアプリが不安定になるとマイコン全体が不安定になる可能性が高いので、フェールセーフ状態では監視を強化することで、残りのアプリの異常兆候を高精度に検出する。いずれの場合もアプリは完全に停止していないので、アプリが不安定ながらも動作している間に適切な対応が可能になる。また、フェールセーフ状態で監視を強化しても、マイコン50やマイコンシステム全体の送信頻度はほぼ変わらないので、マイコン50やマイコンシステム全体の負荷が大きくなることを抑制できる。
As described above, the
〔変形例〕
図7は、アプリが3つある場合のマイコン50又はマイコンシステム100の概略を説明する図の一例である。
[Modification]
FIG. 7 is an example of a diagram for explaining the outline of the
図7(a)は通常実行状態の応答信号1〜3を模式的に示す。3つのアプリ1〜3はそれぞれの周期で応答信号1〜3を監視マイコン60に送信している。例えば、最も優先度(ASIL)の低いアプリ3に異常兆候が検出された場合、マイコン50はフェールセーフ状態になり、アプリ3を停止するか又は監視対象外にする。アプリ1,2に異常兆候が検出された場合も、最も優先度の低いアプリ3を停止するか又は監視対象外にする。アプリ3が応答信号3を送信しないので、アプリ1,2がアプリ3の送信タイミング3を使用して応答信号1,2を送信する。
FIG. 7A schematically shows the response signals 1 to 3 in the normal execution state. The three
アプリ1,2がアプリ3の送信タイミング3や周期を知っていても、アプリ3の1つの送信タイミング3では応答信号1又は2のいずれかしか送信できない。この場合、アプリ1,2が通信して送信タイミングを決定するなどの複雑な処理が必要になり好ましくない。そこで、アプリ3の送信タイミング3をそのまま使用するのでなく、アプリ1,2はフェールセーフ状態用の送信タイミングで送信する。
Even if the
図7(b)はフェールセーフ状態の応答信号1〜3を模式的に示す。図7(b)の矢印の上側では、アプリ1とアプリ2の送信タイミングが通常実行状態とフェールセーフ状態で変わっている。しかし、アプリ1,2がフェールセーフ状態用の送信タイミングで送信することで、アプリ1とアプリ2は交互に応答信号1,2を送信することができる。なお、アプリ1とアプリ2の送信頻度が同じである必要はなく、例えば、ASILが高いアプリの送信頻度を大きくすることができる。
FIG. 7B schematically shows the response signals 1 to 3 in the fail-safe state. On the upper side of the arrow in FIG. 7B, the transmission timings of the
または、アプリ1はアプリ1とアプリ3の送信タイミングで応答信号1の送信を応答送信部31に要求して、アプリ2はアプリ2とアプリ3の送信タイミングで応答信号2の送信を応答送信部31に要求してもよい。応答送信部31は、アプリ1とアプリ2の送信要求を取得して、通常実行状態よりも送信頻度が多くならないように一部の送信要求を破棄する。図7(b)の矢印の下側に示すように、この場合、アプリ1とアプリ2の送信タイミングが通常実行状態とフェールセーフ状態でほぼ同じまま、アプリ3の送信タイミングで応答信号1または応答信号2を送信できる。応答信号1,2が交互になるとは限らないが、応答信号1,2の送信頻度は同程度である。
Alternatively, the
なお、フェールセーフ状態の応答信号1,2の合計の送信頻度は、通常実行状態の応答信号1〜3の合計の送信頻度と同じである。これにより、フェールセーフ機能と通常実行状態とで応答送信部31の負荷が変わることを抑制できる。
The total transmission frequency of the response signals 1 and 2 in the fail-safe state is the same as the total transmission frequency of the response signals 1 to 3 in the normal execution state. Thereby, it can suppress that the load of the
このように本実施例の異常監視方法は、アプリが3つ以上動作するマイコン50又はマイコンシステム100に対しても同様に適用することができる。
As described above, the abnormality monitoring method of the present embodiment can be similarly applied to the
図8(a)は、複数のマイコン50のアプリを1つの監視マイコン60で監視するマイコンシステム100の一例を示す図である。これまでの説明では1つのマイコン50で複数のアプリが動作しているが、マイコン50が複数存在して、それぞれのマイコン50がアプリ1,2を実行しても、本実施例の異常監視方法は好適に適用できる。図示する形態では、アプリ1,2がそれぞれ監視マイコン60に応答信号1,2を送信すればよく、アプリ1,2が1つのマイコン内で動作する場合とほぼ同様になる。
FIG. 8A is a diagram illustrating an example of a
また、この場合、1つのマイコン1又はマイコン2が複数のアプリを実行してもよい。したがって、アプリの数は3つ以上になるが、図7にて説明したようにアプリの数が3つ以上でも異常監視方法は同様になる。
In this case, one
図8(b)は、複数のECU1,2が実行するアプリ1,2を1つの監視マイコン60で監視するマイコンシステム100の一例を示す図である。ECU1〜3はCAN等の車載ネットワークを介して接続されている。
FIG. 8B is a diagram illustrating an example of a
図示するように、ECU1,2が複数存在して、それぞれのマイコン1,2がアプリ1,2を実行しても、本実施例の異常監視方法は好適に適用できる。図示する形態では、アプリ1,2が、それぞれ監視マイコン60が搭載されたECUに応答信号1,2を車載ネットワーク経由で送信すればよく、アプリ1,2が1つのマイコン内で動作する場合とほぼ同様になる。また、この場合、ECU1,2のマイコンが複数のアプリを実行してもよい。
As shown in the drawing, even when there are a plurality of
図8(a)(b)に示すように、本実施例の異常監視方法では、1つの監視マイコン60が複数のアプリを監視する態様において、複数のアプリが1つのマイコン内にあるか、複数のマイコン内(1つのECU内)にあるか、複数のECUにあるかを問わない。
As shown in FIGS. 8A and 8B, in the abnormality monitoring method according to the present embodiment, in a mode in which one
実施例1では、フェールセーフ状態において、アプリ1が応答信号1の送信頻度を増大させることで監視を強化した。本実施例では、アプリ1の応答信号1に加え動作状態を送信することで監視を強化するマイコン50又はマイコンシステム100について説明する。
In the first embodiment, monitoring is strengthened by increasing the transmission frequency of the
図9は、マイコン50又はマイコンシステム100の機能ブロック図の一例を示す。図9において図3と同一部には同一の符号を付しその説明は省略する。本実施例のマイコン50又はマイコンシステム100は、動作状態送信部34と高度監視部35を新たに有する。なお、フェールセーフ状態になるまでの処理は実施例1と同様である。
FIG. 9 shows an example of a functional block diagram of the
これに対し、本実施例のモード切り換え部32は、異常兆候の検出通知を取得すると、以下のような処理を行う。
・アプリASIL情報36を参照して、アプリ2の優先度(ASIL)が他のアプリ1よりも低いことを確認する。すなわち、最も優先度が低いアプリであることを確認する。または、最も優先度が低くなくても、予め定められた優先度以下であることを確認する。
・アプリ2を停止、又は、アプリ2を監視対象外とする(アプリ2に応答信号2の送信を停止させる、又は、アプリ2から応答信号2の送信要求を受け付けても応答信号2の送信を行わない)
・アプリ1と監視マイコン60にフェールセーフ状態になったことを通知する
・動作状態送信部34を起動させる
・高度監視部35を起動させる
動作状態送信部34は動作状態情報を、応答送信部31を経由して高度監視部35に送信するものであり、高度監視部35は動作状態情報に基づきフェールセーフ状態で動作するアプリ1を監視するものである。
On the other hand, when the
-Referring to the
-Stop the
Notifying the
動作状態情報は、例えば、CPU負荷、API利用頻度、特定API利用回数などである。CPU負荷は、NOPなどの空命令を繰り返し実行するアイドル状態の時間とアプリ1の実行時間の合計に対する、アプリ1の実行時間の割合である。
The operating state information is, for example, CPU load, API usage frequency, specific API usage count, and the like. The CPU load is the ratio of the execution time of the
また、API利用頻度は、アプリ1がOSなどのAPIを呼び出す頻度を数値化した値である。アプリ1は、APIを通してOSなどの機能を利用する。アプリ1に異常がなければ、APIの利用頻度は大きな変動がなく推移し、アプリ1に異常が生じ始めるとそれまで利用していたAPIの利用頻度が減少したり、それまであまり利用していなかったAPIの利用頻度が増大する。このため、APIの利用頻度はアプリ1の安定性と相関性がある。
The API usage frequency is a value obtained by quantifying the frequency at which the
特定API利用回数は、所定時間内に、特定のAPIを利用してOSの機能を呼び出した回数である。アプリ1は、CPU負荷が高い場合や、予め定められた状況が生じた場合、その時のステータス情報を記録したり、ログを記録したりする。このようなAPIは異常に関係が深いことが知られている。よって、予め異常に結びつきやすいAPIをいくつか特定しておけば、このAPIの利用回数である特定API利用回数は、アプリ1の安定性を監視する指標となる。
The specific API use count is the number of times that a function of the OS is called using a specific API within a predetermined time. When the CPU load is high or a predetermined situation occurs, the
動作状態送信部34は、CPU負荷、アプリ1のAPI利用頻度、及び、特定API利用回数を応答送信部31に送信する。応答送信部31は、アプリ1からの応答信号1と動作状態情報を応答監視部33に送信する。応答送信部31は、通常実行状態と同じ送信タイミング1で応答信号1を送信し、送信タイミング2で動作状態情報を送信する。
The operation
高度監視部35は、動作状態情報を監視してアプリ1に異常兆候が検出されるか否かを判定する。高度監視部35が、アプリ1が不安定であると判定すると、モード切り換え部32に通知する。これにより、モード切り換え部32はアプリ1の復帰を試みるなど、アプリ1のASILに応じた処理を行うことが可能になる。このように、動作状態送信部34が、アプリ1の動作状態を検出して高度監視部35に送信することで、高度監視部35は応答信号1の受信回数以外からアプリ1の状態を把握・分析することができる。
The
〔動作状態情報の送信〕
図10は、本実施例のフェールセーフ状態における応答信号及び動作状態情報の送信を説明する図の一例である。
・実施例1と同様に、フェールセーフ状態ではアプリ2は停止されるか、応答監視部33の監視対象外となるので、応答送信部31が応答信号2を応答監視部33に送信することはない。
・アプリ1は、フェールセーフ状態になっても、通常実行状態と同じ周期で応答信号1の送信を応答送信部31に要求する。
・動作状態送信部34は、例えば、動作状態情報に変化が見られると、動作状態情報を送信するよう応答送信部31に要求する。
・応答送信部31は、アプリ2の送信タイミングを使用して動作状態情報を応答監視部33に送信する。図10の“d”の四角が動作状態情報を示している。応答信号1と動作状態情報の合計の送信頻度は、通常実行状態における応答信号1、2の送信頻度と同じなので、マイコン50やマイコンシステム100の負荷はほぼ変更されない。
[Transmission of operation status information]
FIG. 10 is an example of a diagram illustrating transmission of a response signal and operation state information in the fail-safe state according to the present embodiment.
As in the first embodiment, in the fail-safe state, the
The
For example, when a change is found in the operation state information, the operation
The
高度監視部35は、CPU負荷、API利用頻度、及び、特定API利用回数を時系列に監視して、それぞれ異常兆候が検出されるか否かを判定する。例えば、CPU負荷の場合、CPU負荷の傾きを算出して、傾きが閾値以上であれば異常傾向があると判定する。CPU負荷の絶対値に着目してもよい。
The
また、高度監視部35は、過去の数個のAPI利用頻度の分散を算出して、閾値と比較することでアプリ1が不安定であるか否かを判定する。また、高度監視部35は、特定API利用回数の傾きを算出して、傾きが閾値以上向であれば異常傾向があると判定する。特定API利用回数の絶対値に着目してもよい。
In addition, the
ところで、図5では動作状態情報が3つとしたが、このように種類が多いと、1回の送信タイミング2で全ての動作状態情報を送信することができない(間に合わない)おそれがある。このような場合は、動作状態情報を1回の送信タイミング2で送信するのでなく、複数の送信タイミング2に分散させることが有効である。
By the way, although there are three pieces of operation state information in FIG. 5, if there are many types as described above, there is a possibility that not all operation state information can be transmitted (in time) at one
図11(a)は、送信タイミングと送信される動作状態情報を説明する図の一例である。図10と同様に、通常実行状態とフェールセーフ状態とで応答信号1の送信タイミングは同じである。これに対し、動作状態情報が送信される送信タイミング2では、CPU負荷、アプリ利用頻度、特定API利用回数が順番に送信されている。CPU負荷、アプリ利用頻度、特定API利用回数は、短時間に急激に変動するものではないので、すべての送信タイミング2で送信しなくても、異常兆候の監視に大きな不都合はない。
Fig.11 (a) is an example of the figure explaining the transmission timing and the operation state information transmitted. Similar to FIG. 10, the transmission timing of the
したがって、通常実行状態に対しフェールセーフ状態の送信頻度を増大させないことで、マイコン50またはマイコンシステム100の負荷をほぼ同じに保つことがない。
Therefore, the load of the
また、一種類の動作状態情報が1つの送信タイミング2で送信可能なデータ量を超える場合もありうる。図11(b)は、送信タイミングと送信される動作状態情報を説明する図の別の一例である。図11(b)では、1つのAPI利用頻度が2つ(API利用頻度1とAPI利用頻度2)に分けて送信されている。このように、一種類の動作状態情報のデータ量が大きくても、複数の送信タイミング2で送信できるので、マイコン50またはマイコンシステム100の負荷を大きく変えることなく、動作状態情報を送信できる。
In addition, there may be a case where one type of operation state information exceeds the amount of data that can be transmitted at one
〔動作手順〕
図12は、本実施例のマイコン50又はマイコンシステム100の動作手順を示すフローチャート図の一例である。図12において、マイコン50又はマイコンシステム100がフェールセーフ状態になるステップS9までの手順は図6と同様である。
[Operation procedure]
FIG. 12 is an example of a flowchart showing an operation procedure of the
モード切り換え部32は、アプリ1又はアプリ2に異常兆候が検出された場合、通常実行状態からフェールセーフ状態に切り替える(S9)。アプリ2の優先度(ASIL)が監視対象のアプリの中で最も低いこと又は所定の優先度以下であることを確認する。また、モード切り換え部32は最も優先度が低いか又は所定の優先度以下のアプリ2を停止させる(S9−1)。また、アプリ1と応答監視部33にフェールセーフ状態への切り換えを通知する(S9−2,S9−3)。また、モード切り換え部32は動作状態送信部34を起動する(S9−4)。なお、モード切り換え部32は高度監視部35も起動させるが図示を省略している。
The
起動された動作状態送信部34はアプリ1の監視を開始する(S20)。監視対象は、アプリ1を実行するCPU11のCPU負荷、API利用頻度、特定API利用回数などである。
The activated operation
アプリ1は、フェールセーフ状態へ切り換えられても通常実行状態と同様の送信タイミング1で応答信号1の送信を応答送信部31に要求する(S10)。
Even if the
応答送信部31は、アプリ1の送信要求に対し応答信号1を応答監視部33に送信する(S12)。
The
応答監視部33は、応答信号1の統計期間当たりの受信回数をカウントする(S14)。フェールセーフ状態へ切り換えてもS14の統計期間とS5の統計期間は同じである。
The
動作状態送信部34は、アプリ1の動作状態に変化があったか否かを判定する(S21)。この判定により、アプリ1の動作状態に変化がある場合にのみ、動作状態情報を送信することができる(S22)。なお、ステップS21の判定をすることなく動作状態情報を送信してもよい。
The operation
応答監視部33は、応答信号1の受信回数に異常兆候が検出されるか否かを判定する(S16)。
The
応答信号1の受信回数に異常兆候が検出されない場合(S16のNo)、高度監視部35は動作状態情報から異常傾向が検出されるか否かを判定する(S23)。
If no abnormality sign is detected in the number of times the
動作状態情報から異常傾向が検出されない場合(S23のNo)、高度監視部35は何もせず、処理はステップS10に戻る。
If no abnormal tendency is detected from the operating state information (No in S23), the
応答信号1の受信回数に異常兆候が検出された場合(S16のYes)、又は、動作状態情報から異常傾向が検出された場合(S23のYes)、応答監視部33又は高度監視部35は応答信号の識別情報と共に異常兆候検出をモード切り換え部32に通知する(S17)。モード切り換え部32はアプリ1の異常兆候に対し、アプリ1の復帰を試みるなどのASILに応じて予め定められた処理を行う(S18)。
When an abnormal sign is detected in the number of times the
本実施例では、フェールセーフ状態の応答信号1の送信頻度は実施例1よりも少ないが、高度監視部35はアプリ1の動作状態情報に基づき異常兆候を検出するので、より多様な情報に基づきアプリ1の異常兆候を検出できる。
In the present embodiment, the transmission frequency of the
19 異常監視回路
31 応答送信部
32 モード切り換え部
33 応答監視部
34 動作状態送信部
35 高度監視部
50 マイコン
60 監視マイコン
100 マイコンシステム
DESCRIPTION OF
Claims (9)
第一のカウント期間におけるアプリケーション毎の動作中通知の回数をカウントするアプリ監視手段と、
アプリケーションの動作を制御するアプリ制御手段と、を有し、
前記アプリ監視手段が各アプリケーションの過去の前記第一のカウント期間における動作中通知の回数に基づき、少なくとも1つのアプリケーションの異常兆候を検出した場合、
前記アプリ制御手段は、優先度が最も低いアプリケーションの動作中通知の送信を停止し、
異常兆候が検出されていないアプリケーションは、異常兆候が検出される前と同じタイミングと、動作中通知の送信が停止されたアプリケーションが動作中通知を送信するタイミング又はその前後のタイミングで、動作中通知を送信する、
ことを特徴とする情報処理装置。 A plurality of applications that periodically send an in-operation notification to the app monitoring means to notify that it is in operation;
Application monitoring means for counting the number of notifications during operation for each application in the first count period;
Application control means for controlling the operation of the application,
When the application monitoring means detects an abnormal sign of at least one application based on the number of notifications during operation in the past first count period of each application,
The application control means stops sending an operational notification of the application with the lowest priority,
An application for which no abnormal sign is detected is in-service notification at the same timing as before the abnormal sign is detected, and at the timing at which the application for which the operation notification is stopped is transmitted or before or after the operation notification is transmitted. Send,
An information processing apparatus characterized by that.
異常兆候が検出されていないアプリケーションは、異常兆候が検出される前と同じタイミングでのみ動作中通知を送信し、
前記動作状態検出手段は、異常兆候が検出されたアプリケーションが動作中通知を送信するタイミング又はその前後のタイミングで、動作状態情報を前記アプリ監視手段に送信する、
ことを特徴とする請求項1記載の情報処理装置。 When the application monitoring means detects an abnormal sign of the application, the application monitoring means has an operating state detecting means for detecting an operating state of the application in which no abnormal sign is detected,
Applications that have not detected any abnormal signs will only send an operational notification at the same time as before the abnormal signs were detected,
The operation state detection unit transmits operation state information to the application monitoring unit at a timing at which an application in which an abnormal sign is detected is transmitted during operation or at a timing before and after the operation notification.
The information processing apparatus according to claim 1.
ことを特徴とする請求項1記載の情報処理装置。 The application monitoring means indicates that the application has an abnormal sign when the number of notifications during operation of the application in the first count period is decreasing or when the fluctuation amount of the number of notifications during operation is equal to or greater than a threshold value. Detect
The information processing apparatus according to claim 1.
前記第二のカウント期間における動作中通知の回数に基づき、異常兆候が検出されていないアプリケーションの異常兆候を検出する、
ことを特徴とする請求項1又は3項記載の情報処理装置。 When the application monitoring unit detects an abnormal sign of the application, the application monitoring unit counts the number of notifications during operation of the application in which no abnormal sign is detected in the second count period shorter than the first count period,
Detecting an abnormal sign of an application in which no abnormal sign is detected based on the number of operating notifications in the second count period;
The information processing apparatus according to claim 1 or 3,
ことを特徴とする請求項5記載の情報処理装置。 The application monitoring means detects abnormal signs of each application based on the past CPU load, API usage frequency, or specific API usage frequency.
The information processing apparatus according to claim 5.
ことを特徴とする請求項5又は6記載の情報処理装置。 The operation state detection means transmits any one of the past CPU load, API usage frequency, or specific API usage count to the application monitoring means at two or more transmission timings.
The information processing apparatus according to claim 5 or 6.
第一のカウント期間におけるアプリケーション毎の動作中通知の回数をカウントするアプリ監視手段と、
アプリケーションの動作を制御するアプリ制御手段と、を有し、
前記アプリ監視手段が各アプリケーションの過去の前記第一のカウント期間における動作中通知の回数に基づき、少なくとも1つのアプリケーションの異常兆候を検出した場合、
前記アプリ制御手段は、異常兆候が検出されたアプリケーションの優先度が異常兆候が検出されていないアプリケーションよりも低いことを確認した後、異常兆候が検出されたアプリケーションの動作中通知の送信を停止し、
異常兆候が検出されていないアプリケーションは、異常兆候が検出される前と同じタイミングと、異常兆候が検出されたアプリケーションが動作中通知を送信するタイミング又はその前後のタイミングで、動作中通知を送信する、
ことを特徴とする情報処理装置。 A plurality of applications that periodically send an in-operation notification to the app monitoring means to notify that it is in operation;
Application monitoring means for counting the number of notifications during operation for each application in the first count period;
Application control means for controlling the operation of the application,
When the application monitoring means detects an abnormal sign of at least one application based on the number of notifications during operation in the past first count period of each application,
The application control means confirms that the priority of the application in which the abnormal sign is detected is lower than that of the application in which the abnormal sign is not detected, and then stops sending the operational notification of the application in which the abnormal sign is detected. ,
An application in which no abnormal sign is detected transmits an operational notification at the same timing as before the abnormal sign is detected, and at the timing at which the application in which the abnormal sign is detected transmits an operational notification ,
An information processing apparatus characterized by that.
アプリケーションの動作を制御するアプリ制御手段と、を有する第一の情報処理装置と、
第一のカウント期間におけるアプリケーション毎の動作中通知の回数をカウントするアプリ監視手段、を有する第二の情報処理装置と、を有する情報処理システムであって、
前記アプリ監視手段が各アプリケーションの過去の前記第一のカウント期間における動作中通知の回数に基づき、少なくとも1つのアプリケーションの異常兆候を検出した場合、
前記アプリ制御手段は、最も優先度が低いアプリケーションの動作中通知の送信を停止し、
異常兆候が検出されていないアプリケーションは、異常兆候が検出される前と同じタイミングと、動作中通知の送信が停止されたアプリケーションが動作中通知を送信するタイミング又はその前後のタイミングで、動作中通知を送信する、
ことを特徴とする情報処理システム。 A plurality of applications that periodically send an in-operation notification to the app monitoring means to notify that it is in operation;
A first information processing apparatus having application control means for controlling the operation of the application;
An information processing system comprising: an application monitoring unit that counts the number of notifications during operation for each application in the first count period;
When the application monitoring means detects an abnormal sign of at least one application based on the number of notifications during operation in the past first count period of each application,
The application control unit stops sending an operation notification of the application with the lowest priority,
An application for which no abnormal sign is detected is in-service notification at the same timing as before the abnormal sign is detected, and at the timing at which the application for which the operation notification is stopped is transmitted or before or after the operation notification is transmitted. Send,
An information processing system characterized by this.
Priority Applications (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012004227A JP2013143093A (en) | 2012-01-12 | 2012-01-12 | Information processing apparatus and information processing system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2012004227A JP2013143093A (en) | 2012-01-12 | 2012-01-12 | Information processing apparatus and information processing system |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2013143093A true JP2013143093A (en) | 2013-07-22 |
Family
ID=49039615
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2012004227A Pending JP2013143093A (en) | 2012-01-12 | 2012-01-12 | Information processing apparatus and information processing system |
Country Status (1)
Country | Link |
---|---|
JP (1) | JP2013143093A (en) |
Cited By (6)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102017204625A1 (en) | 2016-03-24 | 2017-09-28 | Toyota Jidosha Kabushiki Kaisha | SOFTWARE COMPONENT ASSIGNMENT SYSTEM FOR A VEHICLE |
JP2020190986A (en) * | 2019-05-23 | 2020-11-26 | 株式会社デンソー | Device for vehicle |
DE112020005251T5 (en) | 2019-12-05 | 2022-08-11 | Hitachi Astemo, Ltd. | VEHICLE MOUNTED ELECTRONIC CONTROL DEVICE |
WO2023048274A1 (en) * | 2021-09-27 | 2023-03-30 | 矢崎総業株式会社 | Vehicle system |
JP7507536B1 (en) | 2023-04-25 | 2024-06-28 | パナソニックオートモーティブシステムズ株式会社 | Monitoring system and control method |
JP7522547B2 (en) | 2019-09-20 | 2024-07-25 | キヤノン株式会社 | Information processing device and reset control method |
-
2012
- 2012-01-12 JP JP2012004227A patent/JP2013143093A/en active Pending
Cited By (7)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
DE102017204625A1 (en) | 2016-03-24 | 2017-09-28 | Toyota Jidosha Kabushiki Kaisha | SOFTWARE COMPONENT ASSIGNMENT SYSTEM FOR A VEHICLE |
US10509674B2 (en) | 2016-03-24 | 2019-12-17 | Toyota Jidosha Kabushiki Kaisha | Software component assigning system for vehicle |
JP2020190986A (en) * | 2019-05-23 | 2020-11-26 | 株式会社デンソー | Device for vehicle |
JP7522547B2 (en) | 2019-09-20 | 2024-07-25 | キヤノン株式会社 | Information processing device and reset control method |
DE112020005251T5 (en) | 2019-12-05 | 2022-08-11 | Hitachi Astemo, Ltd. | VEHICLE MOUNTED ELECTRONIC CONTROL DEVICE |
WO2023048274A1 (en) * | 2021-09-27 | 2023-03-30 | 矢崎総業株式会社 | Vehicle system |
JP7507536B1 (en) | 2023-04-25 | 2024-06-28 | パナソニックオートモーティブシステムズ株式会社 | Monitoring system and control method |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US8090982B2 (en) | Multiprocessor system enabling controlling with specific processor under abnormal operation and control method thereof | |
JP2013143093A (en) | Information processing apparatus and information processing system | |
US8321065B2 (en) | Method for controlling/regulating at least one task | |
JP4060322B2 (en) | Application management apparatus and storage medium storing software thereof | |
US10217299B2 (en) | Vehicular information communication system and vehicular information communication method | |
US10007570B2 (en) | Monitoring unit, control system, and computer readable medium | |
EP2642399A1 (en) | Access method, and multi-core processor system | |
JP2011022934A (en) | Electronic control unit and method for detecting failure | |
JPWO2009060530A1 (en) | Network processing control device, program, and method | |
US20220055637A1 (en) | Electronic control unit and computer readable medium | |
JP2019095893A (en) | Semiconductor device | |
JP5652198B2 (en) | Electronic control device, start control method | |
JP6007677B2 (en) | Safety control system and processor of safety control system | |
JP5928358B2 (en) | Information processing device, monitoring device, control device | |
JP6049961B1 (en) | CPU monitoring device | |
JP5533777B2 (en) | Program group | |
CN116494893A (en) | Vehicle control method and device based on functional safety mechanism and central computing architecture | |
JP6081239B2 (en) | Control device abnormality monitoring apparatus and abnormality monitoring method | |
JP2017043166A (en) | Vehicle control device | |
JP6762281B2 (en) | Stack overflow detector and vehicle control system | |
JP4820679B2 (en) | Electronic control device for vehicle | |
JP2017173947A (en) | On-vehicle controller and rom for on-vehicle controller | |
JP7278205B2 (en) | Computing device and method for monitoring computing device | |
JP2013084218A (en) | Core monitoring device and information processor | |
US20240078128A1 (en) | Control device, control system, and control method |