JP6502211B2 - 車両制御装置 - Google Patents

Description

本発明は、車両制御装置に関するものである。

近年の多くの車両制御システムは、電子化された車両制御機器を操作する電子制御装置（Ｅｌｅｃｔｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ：ＥＣＵ）と、複数のＥＣＵ間の通信を可能にする車載ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）から構成されている。

車両制御システムは、環境負荷の低減や安全に関する要求が増すことにともない、システムの高機能化、機能の分散化、複雑化が進んでいる。その結果、ＥＣＵのソフトウェアアーキテクチャの標準化、安全装置の電子制御化、およびその安全性確保の仕組みの重要性が増大している。

カーメーカーは、分散させた機能毎に専用のＥＣＵを用意する。そのため、１つの車両制御システム内に仕様の異なる複数のＥＣＵが混在する。標準化された車両制御装置のソフトウェアアーキテクチャを導入することにより、仕様の異なるＥＣＵを組合せて車両制御システムを構築することが容易となる。

下記非特許文献１が記載しているＡＵＴＯＳＡＲアーキテクチャにおいては、マイコンに依存する機能単位、センサやアクチュエータの制御処理のアルゴリズム単位、および設定パラメータ単位でソフトウェアがモジュール化されている。したがって、例えば車種変更などに応じてマイコンが変更されたとしても、仕様変更を要するモジュールを修正するのみで変更後の仕様に対応することができ、他のモジュールを修正する必要はない。

車両制御機器における安全装置の電子制御化にともない、機能安全の仕組みが車両制御システムに導入されてきている。機能安全とは、電気・電子システムに不具合が生じたときシステムが安全側に遷移することにより安全を確保する考えである。例えば下記非特許文献２が記載している自動車向け機能安全規格ＩＳＯ２６２６２においては、規格独自の安全度水準であるＡＳＩＬ（Ａｕｔｏｍｏｔｉｖｅ Ｓａｆｅｔｙ Ｉｎｔｅｇｒｉｔｙ Ｌｅｖｅｌ）が設けられている。最上位レベルＡＳＩＬ Ｄに準拠するためには、車両制御装置の安全に関わる機能が、主機能／安全装置／監視装置として明確に分離して構成されていることを第３者に対し証明できることが求められている。

ＩＳＯ２６２６２においては、安全要求が異なるソフトウェア間の干渉を防止することが求められている。一般的な車両制御システムはさまざまな制御アプリケーションによって構成されているので、時間保護機能やメモリ保護機能といったシステムを構成するソフトウェア間の相互作用を防止するための仕組みが近年着目されてきている。具体的には、あるソフトウェアが暴走した場合、他のソフトウェアが使用するデータが格納されているメモリ領域へその暴走したソフトウェアがアクセスしてそのデータを破壊しようすることを防ぐ機能である。一般的な車両制御装置においてＡＵＴＯＳＡＲアーキテクチャを適用すると、車両制御システムはさまざまなＡＳＩＬのソフトウェアが混在することがわかっている。したがって、既存のソフトウェアがＩＳＯ２６２６２に準拠するためには、ソフトウェア間の干渉防止する仕組みが必要となる。

下記特許文献１においては、機能毎に診断機能を持ち自身の状態を判定し、異常が検出されると自身の機能の応じたフェールセーフ処理を実施する構成について言及されている。これにより、ソフトウェアに異常が発生しても、異常を検知する仕組みとそれに対処する機能が組み込まれているため、異常が発生したソフトウェアの影響が他のソフトウェアに波及することを防ぐことができる。

特開２０１４−１１５９５０号公報

ＡＵＴＯＳＡＲ＿ＥＸＰ＿ＬａｙｅｒｅｄＳｏｆｔｗａｒｅＡｒｃｈｉｔｅｃｔｕｒｅ ＩＳＯ２６２６２

異なる安全度水準を有するソフトウェアが混在した車両制御システムにおいては、低い安全度水準のソフトウェアからの影響を防ぐための保護機能（時間保護、メモリ保護）が必要となる。例えば時間保護は、ＯＳ（Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ）が処理する単位であるタスクや割り込み処理に対して適用され、処理時間が想定を超える（デッドラインオーバー）ことを検出し、異常がシステム全体に伝搬しないようにする機能である。

特許文献１に記載されているような従来の車両制御システムにおいては、各処理が監視機能を備えており、異常が検出されるとフェールセーフ処理としてＯＳまたはシステム全体を再起動またはソフトウェアリセットする。これにより制御処理が中断し、車両制御システムの動作が少なくとも一時的に停止する可能性がある。車両の動作が（一時的であるとしても）停止すると利便性が低下するので、車両制御システム全体として動作継続性を確保することが求められる。

本発明は、上記のような課題に鑑みてなされたものであり、異常処理を実施しつつ動作継続性を確保することのできる車両制御装置を提供することを目的とする。

本発明に係る車両制御装置は、異常の累積回数または頻度に応じてシステムの異常レベルを判定し、その異常レベルに応じて異なるフェールセーフ処理を実行する。

本発明に係る車両制御装置によれば、動作継続性を確保しながら異常処理を実行することができる。

ＥＣＵ１の構成図である。 時間管理テーブル５１０の構成とデータ例を示す図である。 処理管理テーブル５２０の構成とデータ例を示す図である。 動作状況管理テーブル５３０の例を示す図である。 機能異常管理テーブル５４０の構成とデータ例を示す図である。 システム異常管理テーブル５５０の構成とデータ例を示す図である。 判定結果管理テーブル５６０の例を示す図である。 ソフトウェア制御部４０１の動作を説明するフローチャートである。 異常管理テーブル初期化部４０２の動作を説明するフローチャートである。 処理実行部４０３の動作を説明するフローチャートである。 １０ｍｓ処理実行部４０４の動作を説明するフローチャートである。 ５ｍｓ処理実行部４０５の動作を説明するフローチャートである。 異常検出部４０６の動作を説明するフローチャートである。 機能診断部４０７の動作を説明するフローチャートである。 システム診断部４０８の動作を説明するフローチャートである。 異常レベル判定部４０９の動作を説明するフローチャートである。 ＦＳ実行部４１０の動作を説明するフローチャートである。 時間管理部４１１の動作を説明するフローチャートである。

図１は、本発明の実施形態に係るＥＣＵ１の構成図である。ＥＣＵ１は、車両が備える電気機器（例えば図１に示すスロットルセンサ７、アクチュエータ８）を電子的に制御する装置であり、演算装置（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ：ＣＰＵ）２、メモリ３、入出力回路６を備える。

ＣＰＵ２は、メモリ３が格納しているプログラムを実行するプロセッサである。以下では記載の便宜上、各プログラムを動作主体として説明する場合があるが、実際にこれらプログラムを実行するのはＣＰＵ２である。

メモリ３は、プログラム記憶領域４とデータ記憶領域５を有する。プログラム記憶領域４は、ＣＰＵ２が実行するプログラムを格納する記憶領域であり、ソフトウェア制御部４０１、異常管理テーブル初期化部４０２、処理実行部４０３、１０ｍｓ処理実行部４０４、５ｍｓ処理実行部４０５、異常検出部４０６、機能診断部４０７、システム診断部４０８、異常レベル判定部４０９、ＦＳ実行部４１０、時間管理部４１１を格納する。これら機能部の詳細については後述する。データ記憶領域５は、後述の図２〜図７で説明する各データテーブルを格納する。

入出力回路６は、スロットルセンサ７やアクチュエータ８などの外部機器に対して信号を送信し、または外部機器からの信号を受信するための信号インターフェースである。

図２は、時間管理テーブル５１０の構成とデータ例を示す図である。時間管理テーブル５１０は、ＥＣＵ１が管理する時間に関する値を記述するデータテーブルである。時間管理テーブル５１０は、名称フィールド５１１、閾値フィールド５１２、現在値フィールド５１３を有する。

名称フィールド５１１は、時間管理テーブル５１０が管理するデータ項目の名称を保持する。閾値フィールド５１２は、各データ項目に関する閾値を保持する。閾値を有さないデータ項目については本フィールドは空である。現在値フィールド５１３は、各データ項目の現在値を保持する。

時間管理テーブル５１０が管理するデータ項目の具体例としては、例えば後述するタイマカウンタの現在値および初期化閾値、後述のフローチャートで説明する各処理の実行周期の現在値、などが挙げられる。

図３は、処理管理テーブル５２０の構成とデータ例を示す図である。処理管理テーブル５２０は、ＯＳが管理する制御処理（機能）に関するパラメータを管理するデータテーブルである。処理管理テーブル５２０は、ｉｎｄｅｘフィールド５２１、処理名フィールド５２２、実行周期フィールド５２３、安全度水準フィールド５２４、実行時間フィールド５２５、実行回数フィールド５２６を有する。

ｉｎｄｅｘフィールド５２１は、処理の実行順番を示す。処理名フィールド５２２は、当該処理を特定するための名称を保持する。実行周期フィールド５２３は、当該処理が実行される周期を示す。安全度水準フィールド５２４は、当該処理に割り付けられたソフトウェアの安全度水準の値を保持する。“１”の場合はＡＳＩＬソフトウェア（要求される安全度水準が高いソフトウェア）であることを示し、“０”の場合はＱＭソフトウェア（要求される安全度水準が低い）であることを示す。実行時間フィールド５２５は、当該処理を実行するためにかかると想定される時間を保持する。実行回数フィールド５２６は、単位時間あたりに当該処理が実行されると想定される回数を保持する。

図４は、動作状況管理テーブル５３０の例を示す図である。動作状況管理テーブル５３０は、ＯＳが管理する処理の動作状況を管理するデータテーブルである。動作状況管理テーブル５３０は、ｉｎｄｅｘフィールド５３１、処理名フィールド５３２、起動許可フラグフィールド５３３、開始時刻フィールド５３４、終了時刻フィールド５３５、実行時間フィールド５３６、実行回数フィールド５３７を有する。

ｉｎｄｅｘフィールド５３１は、処理の実行順番を示す。処理名フィールド５３２は、当該処理を特定するための名称を保持する。起動許可フラグフィールド５３３は、当該処理が現周期において起動を許可されているか否かを示すフラグを保持する。“０”は起動不可であることを示し、“１”は起動許可であることを示す。開始時刻フィールド５３４と終了時刻フィールド５３５は、当該処理が開始した時刻および終了した時刻をそれぞれ保持する。実行時間フィールド５３６は、当該処理を実行するのに実際にかかった時間を保持する。実行回数フィールド５３７は、単位時間あたりに当該処理が実際に実行された回数を保持する。

図５は、機能異常管理テーブル５４０の構成とデータ例を示す図である。機能異常管理テーブル５４０は、ＯＳが管理する処理の異常状態を管理するデータテーブルである。機能異常管理テーブル５４０は、処理名フィールド５４１、閾値フィールド５４２、異常カウンタフィールド５４３を有する。

処理名フィールド５４１は、処理を特定するための名称を保持する。異常カウンタフィールド５４３は、当該処理が異常と判定された回数を保持する。閾値フィールド５４２は、後述の図１４において異常カウンタフィールド５４３の値が異常であるか否かを判定するための閾値を保持する。

図６は、システム異常管理テーブル５５０の構成とデータ例を示す図である。システム異常管理テーブル５５０は、システムレベルの異常状態（ＥＣＵ１全体にわたる異常）を管理するデータテーブルである。システム異常管理テーブル５５０は、名称フィールド５５１、閾値フィールド５５２、値フィールド５５３を有する。

名称フィールド５５１は、システム異常管理テーブル５５０が管理する異常パラメータの名称を保持する。値フィールド５５３は、当該異常パラメータの現在値を保持する。閾値フィールド５５２は、当該異常パラメータを用いてシステム異常レベルを判定するための閾値を保持する。

図７は、判定結果管理テーブル５６０の例を示す図である。判定結果管理テーブル５６０は、機能診断部４０７、システム診断部４０８、異常レベル判定部４０９による異常判定結果を管理するデータテーブルである。判定結果管理テーブル５６０は、名称フィールド５６１、値フィールド５６２を有する。名称フィールド５６１は、判定結果管理テーブル５６０が管理する判定結果の名称を保持する。値フィールド５６２は、当該判定結果の値を保持する。

図８は、ソフトウェア制御部４０１の動作を説明するフローチャートである。以下、図８の各ステップについて説明する。

（図８：ステップＳ４０１０００）
ソフトウェア制御部４０１は、異常管理テーブル初期化部４０２を呼び出す。本ステップは、現在値を管理する各テーブルを初期化するためのものである。本ステップの詳細については後述の図９で説明する。

（図８：ステップＳ４０１００１）
ソフトウェア制御部４０１は、処理実行部４０３を呼びだす。本ステップは、ＥＣＵ１が実行する各制御処理を実施するためのものである。本ステップの詳細については後述の図１０で説明する。

（図８：ステップＳ４０１０２）
ソフトウェア制御部４０１は、異常検出部４０６を呼び出す。本ステップは、各制御処理の異常およびシステムレベルの異常（ＥＣＵ１全体としての異常）を診断するためのものである。本ステップの詳細については後述の図１３で説明する。

（図８：ステップＳ４０１００３）
ソフトウェア制御部４０１は、ＦＳ実行部４１０を呼び出す。本ステップは、ＥＣＵ１を安全状態へ移行させるフェールセーフ処理を実行するためのものである。本ステップの詳細については後述の図１７で説明する。

（図８：ステップＳ４０１００４）
ソフトウェア制御部４０１は、時間管理部４１１を呼び出す。本ステップの詳細については後述の図１８で説明する。

（図８：ステップＳ４０１００５）
ソフトウェア制御部４０１は、例えばＥＣＵ１をシャットダウンする命令が与えられているか否かなどに基づき、動作を終了するか否かを判定する。動作を終了する場合は本フローチャートを終了し、継続する場合はステップＳ４０１０００に戻る。

図９は、異常管理テーブル初期化部４０２の動作を説明するフローチャートである。以下、図９の各ステップについて説明する。

（図９：ステップＳ４０２０００）
異常管理テーブル初期化部４０２は、時間管理テーブル５１０からタイマカウンタの現在値（図２の１行目のレコード）を取得するとともに、テーブル初期化周期（図２の２行目のレコード）を取得する。取得したタイマカウンタを取得した周期（本例においては１００）で割った余りが０であればステップＳ４０２００１に進み、それ以外であれば本フローチャートを終了する。

（図９：ステップＳ４０２０００：補足）
本ステップは、時間管理テーブル５１０が定義する周期毎に異常カウント（各機能やシステム全体が異常と判断された回数）を初期化するためのものである。異常カウントを初期化せず累積回数を用いて異常判定することも考えられる。この場合は累積回数がある程度に到達した時点でシステムレベルの異常とみなすことになる。これは比較的軽微な異常を無視してシステム全体レベルの重篤な異常に至った時点でフェールセーフなどを実施することに相当する。しかし実際の運用においては、ＥＣＵが備える各機能要素において軽微なエラーが頻繁に生じているケースがしばしばある。例えばメモリのビットエラーがしばしば生じているがエラー訂正機能によって制御処理は正常に進行し、異常とはみなされないことがこれに当たる。小規模異常であってもその頻度や発生箇所の個数によっては、ＥＣＵ１全体の動作に対して重篤な影響を与えるかまたはこれに近づいている可能性がある。そこで本実施形態においては、システムレベルの異常に至らないまでも現実には発生している小規模な瞬時エラーをも検出するため、異常カウントを周期的にリセットすることとした。異常カウントを一切リセットしないか、またはリセット周期を極端に長くセットすると、累積回数をカウントしていることと変わらないので、リセット周期は瞬時エラーを検出できる程度の適切な値にあらかじめセットしておく。

（図９：ステップＳ４０２００１〜Ｓ４０２００３）
異常管理テーブル初期化部４０２は、機能異常管理テーブル５４０の異常カウンタフィールド５４３（Ｓ４０２００１）、システム異常管理テーブル５５０の値フィールド５５３（Ｓ４０２００２）、動作状況管理テーブル５３０の開始時刻フィールド５３４〜実行回数フィールド５３７（Ｓ４０２００３）を、それぞれ初期化する。

図１０は、処理実行部４０３の動作を説明するフローチャートである。以下、図１０の各ステップについて説明する。

（図１０：ステップＳ４０３０００）
処理実行部４０３は、時間管理テーブル５１０からタイマカウンタの現在値（図２の１行目のレコード）を取得する。取得したタイマカウンタを１０で割った余りが０であればステップＳ４０３００１に進み、それ以外であればステップＳ４０３００２へスキップする。

（図１０：ステップＳ４０３００１）
処理実行部４０３は、１０ｍｓ処理実行部４０４を呼び出す。１０ｍｓ処理実行部４０４は、１０ｍｓ周期で実施すべき制御処理を実行する。１０ｍｓ処理実行部４０４の動作については後述の図１１で説明する。処理実行部４０３は、本ステップにおいて１０ｍｓ処理実行部４０４の処理完了を待機する必要はなく、１０ｍｓ処理実行部を呼び出してすぐにステップＳ４０３００２へ進むとともに、１０ｍｓ周期処理を並列実行することができる。

（図１０：ステップＳ４０３００２）
処理実行部４０３は、時間管理テーブル５１０からタイマカウンタの現在値を取得する。取得したタイマカウンタを５で割った余りが０であればステップＳ４０３００３に進み、それ以外であれば本フローチャートを終了する。

（図１０：ステップＳ４０３００３）
処理実行部４０３は、５ｍｓ処理実行部４０５を呼び出す。５ｍｓ処理実行部４０５は、５ｍｓ周期で実施すべき制御処理を実行する。５ｍｓ処理実行部４０５の動作については後述の図１２で説明する。

（図１０：ステップＳ４０３００とＳ４０３００２の補足）
これらステップにおいてそれぞれタイマカウンタを１０と５で除算しているのは、処理管理テーブル５２０において実行周期フィールド５２３がそれぞれ１０と５である機能が登録されているからである。これら実行周期はあらかじめ取得しておいてもよいし、本フローチャートの適当な時点（例えばＳ４０３０００の前）において取得してもよい。

図１１は、１０ｍｓ処理実行部４０４の動作を説明するフローチャートである。以下、図１１の各ステップについて説明する。

（図１１：ステップＳ４０４０００）
１０ｍｓ処理実行部４０４は、処理管理テーブル５２０が管理しているｉ番目の処理の実行周期フィールド５２３が１０（ｍｓ）であれば、さらに動作状況管理テーブル５３０から当該処理の起動許可フラグフィールド５３３を取得する。実行周期フィールド５２３が１０かつ起動許可フラグフィールド５３３値が１であればステップＳ４０４００１に進み、それ以外であればｉをインクリメントした上で本ステップを改めて実施する。

（図１１：ステップＳ４０４００１）
１０ｍｓ処理実行部４０４は、時間管理テーブル５１０からタイマカウンタの現在値を取得し、動作状況管理テーブル５３０のｉ番目レコードの開始時刻フィールド５３４にその値を記録する。

（図１１：ステップＳ４０４００２〜Ｓ４０４００３）
１０ｍｓ処理実行部４０４は、ｉ番目の処理を実行する（Ｓ４０４００２）。１０ｍｓ処理実行部４０４は、動作状況管理テーブル５３０のｉ番目レコードの実行回数フィールド５３７を１増やす。

（図１１：ステップＳ４０４００４）
１０ｍｓ処理実行部４０４は、時間管理テーブル５１０からタイマカウンタの現在値を取得し、動作状況管理テーブル５３０のｉ番目レコードの終了時刻フィールド５３５にその値を記録する。

（図１１：ステップＳ４０４００５）
１０ｍｓ処理実行部４０４は、１０ｍｓ周期で実行する全処理を実行完了したか否かを確認する。全処理を完了した場合は本フローチャートを終了し、それ以外であればｉをインクリメントしてステップＳ４０４０００に戻る。

（図１１：補足）
１０ｍｓ処理実行部４０４は、各処理が完了するのを待機してから次の処理を起動する必要はなく、各処理を並列実行することもできる。その場合は各処理についてステップＳ４０４００１〜Ｓ４０４００４を並行して実行することになる。

図１２は、５ｍｓ処理実行部４０５の動作を説明するフローチャートである。５ｍｓ処理実行部４０５の動作は１０ｍｓ処理実行部４０４と概ね同様であるが、実行周期フィールド５２３の値が５である処理が対象となる点が異なる。

図１３は、異常検出部４０６の動作を説明するフローチャートである。以下、図１３の各ステップについて説明する。

（図１３：ステップＳ４０６０００）
異常検出部４０６は、時間管理テーブル５１０からタイマカウンタの現在値を取得するとともに、診断周期（図２の３行目のレコード）を取得する。取得したタイマカウンタを取得した周期（本例においては２０）で割った余りが０であればステップＳ４０６００１に進み、それ以外であれば本フローチャートを終了する。

（図１３：ステップＳ４０６００１）
異常検出部４０６は、機能診断部４０７を呼び出す。本ステップは、各機能異常を検出するためのものである。本ステップの詳細については後述の図１４で説明する。

（図１３：ステップＳ４０６００２）
異常検出部４０６は、システム診断部４０８を呼び出す。本ステップは、システムレベル（ＥＣＵ１全体レベル）の異常を検出するためのものである。本ステップの詳細については後述の図１５で説明する。

（図１３：ステップＳ４０６００３）
異常検出部４０６は、異常レベル判定部４０９を呼び出す。本ステップは、ＥＣＵ１の異常レベルを判定するためのものである。本ステップの詳細については後述の図１６で説明する。

図１４は、機能診断部４０７の動作を説明するフローチャートである。以下、図１４の各ステップについて説明する。

（図１４：ステップＳ４０７０００）
機能診断部４０７は、動作状況管理テーブル５３０から処理ｉの開始時刻フィールド５３４と終了時刻フィールド５３５の値をそれぞれ取得し、その差分に基づき処理ｉの実行時間を算出して実行時間フィールド５３６に格納する。

（図１４：ステップＳ４０７００１）
機能診断部４０７は、ステップＳ４０７０００において算出した実行時間と、処理管理テーブル５２０が格納している当該処理ｉの実行時間フィールド５２５とを比較する。算出した実行時間の方が大きければステップＳ４０７００３へスキップし、小さければステップＳ４０７００２へ進む。

（図１４：ステップＳ４０７００２）
機能診断部４０７は、動作状況管理テーブル５３０から処理ｉの実行回数フィールド５３７を取得し、処理管理テーブル５２０が格納している当該処理ｉの実行回数フィールド５２６と比較する。実行回数フィールド５３７の方が大きければステップＳ４０７００３へ進み、小さければステップＳ４０７００４へスキップする。

（図１４：ステップＳ４０７００３）
機能診断部４０７は、機能異常管理テーブル５４０のｉ番目レコードの異常カウンタフィールド５４３を１増やす。当該処理ｉの安全度水準フィールド５２４が“１”である場合はさらに、判定結果管理テーブル５６０が格納する高優先度処理異常フラグの値フィールド５６２に“１”を格納する。

（図１４：ステップＳ４０７００３：補足）
本実施形態においては、後述の図１６で説明するように、ＥＣＵ１全体としての異常レベルに応じてそれぞれ異なるフェールセーフ処理を実行する。したがって、発生している故障の程度に応じてシステム異常レベルを判定する必要がある。要求される安全度水準が高い機能が故障している場合、故障の程度は高いと考えられるので、かかる機能については異常状態を管理するフラグを格別に設けて管理することとした。

（図１４：ステップＳ４０７００４）
機能診断部４０７は、全処理について診断完了したか否かを判定する。診断完了した場合はステップＳ４０７００５へ進み、それ以外であればｉの値をインクリメントしてステップＳ４０７０００へ戻る。

（図１４：ステップＳ４０７００５）
機能診断部４０７は、機能異常管理テーブル５４０の各レコードの異常カウンタフィールド５４３と閾値フィールド５４２を比較する。異常カウンタフィールド５４３の方が大きければ当該機能は異常であると判定する。機能診断部４０７は、異常であると判定した機能の個数を、判定結果管理テーブル５６０の機能異常数の値フィールド５６２に格納する。

図１５は、システム診断部４０８の動作を説明するフローチャートである。以下、図１５の各ステップについて説明する。

（図１５：ステップＳ４０８０００）
システム診断部４０８は、機能異常管理テーブル５４０から全処理についての異常カウンタフィールド５４３の値を取得する。システム診断部４０８は、取得した異常カウンタの合計値を処理の総個数（例えば機能異常管理テーブル５４０のレコード数）で除算することにより、機能異常回数の平均値を算出する。システム診断部４０８は、算出した平均値をシステム異常管理テーブル５５０の平均機能異常回数を記録するレコードの値フィールド５５３に格納する。

（図１５：ステップＳ４０８０００：補足）
本フローチャートにおいては、処理の簡易の観点から異常カウントの平均値をシステム異常レベルの判断指標として用いることとしたが、その他値を用いてもよい。例えば重要度に応じて各処理を重み付けし、各処理の異常カウントにその重みを乗算した上で合計値を求め、その結果を値フィールド５５３に格納してシステム異常レベルの判断指標として用いることもできる。

（図１５：ステップＳ４０８００１）
システム診断部４０８は、ステップＳ４０８０００で算出した平均値と、システム異常管理テーブル５５０が格納している平均機能異常回数の閾値フィールド５５２とを比較する。算出した平均値の方が大きければステップＳ４０８００２へ進み、小さければステップＳ４０８００３へスキップする。

（図１５：ステップＳ４０８００２）
システム診断部４０８は、システム異常管理テーブル５５０のシステム異常カウンタを記録するレコードの値フィールド５５３を１増やす。

（図１５：ステップＳ４０８００３）
システム診断部４０８は、システム異常カウンタの値フィールド５５３と、システム異常管理テーブル５５０が格納しているシステム異常カウンタの閾値フィールド５５２とを比較する。値フィールド５５３の方が大きければステップＳ４０８００４へ進み、小さければ本フローチャートを終了する。

（図１５：ステップＳ４０８００４）
システム診断部４０８は、判定結果管理テーブル５６０のシステム異常フラグを記録するレコードの値フィールド５６２に“１”を格納する。

図１６は、異常レベル判定部４０９の動作を説明するフローチャートである。以下、図１６の各ステップについて説明する。

（図１６：ステップＳ４０９０００）
異常レベル判定部４０９は、判定結果管理テーブル５６０からシステム異常フラグの値フィールド５６２を取得する。システム異常フラグの値が“１”であればステップＳ４０９００１へ進み、“０”であればステップＳ４０９００２へスキップする。

（図１６：ステップＳ４０９００１）
異常レベル判定部４０９は、判定結果管理テーブル５６０の異常レベルを記録するレコードの値フィールド５６２に“３”を格納する。

（図１６：ステップＳ４０９００２）
異常レベル判定部４０９は、判定結果管理テーブル５６０から高優先度処理異常フラグの値フィールド５６２を取得する。高優先度処理異常フラグの値が“１”であればステップＳ４０９００１へ進み、“０”であればステップＳ４０９００３へ進む。

（図１６：ステップＳ４０９００１〜Ｓ４０９００２：補足）
システム異常フラグは、ステップＳ４０８００３においてシステム異常カウンタが閾値以上である場合にセットされるフラグである。システム異常カウンタは機能異常回数の平均値が閾値以上である場合にカウントアップされるものである。すなわちシステム異常フラグは、多数の機能が異常であることを示しているので、これがセットされているときはシステム異常レベルが高いと考えられる。したがってこの場合の異常レベルは、本フローチャートにおける最高の“３”とすることにした。また高優先度処理異常フラグは安全要求度が高い処理が異常であることを示しているので、システム異常フラグと同様に取り扱うこととした。

（図１６：ステップＳ４０９００３〜Ｓ４０９００４）
異常レベル判定部４０９は、判定結果管理テーブル５６０から機能異常数の値フィールド５６２を取得する。機能異常数が２より大きければ、ステップＳ４０９００４において判定結果管理テーブル５６０の異常レベルを記録するレコードの値フィールド５６２に“２”を格納する。機能異常数が２以下であればステップＳ４０９００５へ進む。

（図１６：ステップＳ４０９００５〜Ｓ４０９００６）
異常レベル判定部４０９は、機能異常数が１より大きければ、ステップＳ４０９００６において判定結果管理テーブル５６０の異常レベルを記録するレコードの値フィールド５６２に“１”を格納する。機能異常数が１以下であれば本フローチャートを終了する。

（図１６：ステップＳ４０９００３〜Ｓ４０９００６：補足）
本フローチャートにおいては、機能異常数を基準として異常レベルをセットしているが、その基準とする個数は本フローチャートに示すものに限られず、例えば全機能数に基づき適宜定めることができる。

図１７は、ＦＳ実行部４１０の動作を説明するフローチャートである。以下、図１７の各ステップについて説明する。

（図１７：ステップＳ４１００００〜Ｓ４１０００１）
ＦＳ実行部４１０は、判定結果管理テーブル５６０から異常レベルを記録するレコードの値フィールド５６２を取得する。異常レベルが“３”であれば、ステップＳ４１０００１においてＥＣＵ１をソフトウェアリセットする。それ以外であればステップＳ４１０００２へ進む。

（図１７：ステップＳ４１０００２〜Ｓ４１０００３）
ＦＳ実行部４１０は、異常レベルが“２”であれば、ステップＳ４１０００３において安全度水準フィールド５２４が“０”である（すなわち要求される安全度水準が低い）全ての機能の起動許可フラグフィールド５３３を“０”にする（すなわち起動不可にする）。それ以外であればステップＳ４１０００４へ進む。

（図１７：ステップＳ４１０００４）
ＦＳ実行部４１０は、異常レベルが“１”であれば、ステップＳ４１０００５において異常カウンタフィールド５４３が閾値フィールド５４２を超えている機能の起動許可フラグフィールド５３３を“０”にする（すなわち起動不可にする）。それ以外であれば本フローチャートを終了する。

図１８は、時間管理部４１１の動作を説明するフローチャートである。以下、図１８の各ステップについて説明する。

（図１８：ステップＳ４１１０００〜Ｓ４１１００１）
時間管理部４１１は、時間管理テーブル５１０が格納しているタイマカウンタの現在値をインクリメントする。

（図１８：ステップ）
時間管理部４１１は、時間管理テーブル５１０が格納しているタイマカウンタの閾値フィールド５１２を取得する。タイマカウンタの現在値が閾値フィールド５１２を超えた場合は、ステップＳ４１１００２においてタイマカウンタの現在値を０にセットする。それ以外であれば本フローチャートを終了する。

＜本発明のまとめ＞
本実施形態に係るＥＣＵ１は、単位時間当たりの機能異常数に基づきシステム異常レベルを判定し、そのシステム異常レベルに応じたフェールセーフ処理を実行する。したがって、例えばシステム異常レベルが低いときはできる限り多くの機能を維持したままでフェールセーフ動作を実行することにより、ＥＣＵ１の動作継続性を高めることができる。

本実施形態に係るＥＣＵ１は、個々の機能の動作状況を管理し、その動作状況に基づきシステム全体の異常レベルを判定する。これにより、ＥＣＵ１全体の動作にとって障害となる重篤な異常状態に至る前に、適切なフェールセーフ処理を実行して対処することができる。

本実施形態に係るＥＣＵ１は、要求される安全度水準が高い機能が異常である場合は、その他機能が異常である場合よりもシステム異常レベルが高いとみなす。これにより、例えばＡＵＴＯＳＡＲのように安全度水準について厳格に定める規格に準拠した制御を実現することができる。

＜本発明の変形例について＞
本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施例の構成の一部を他の実施例の構成に置き換える事が可能であり、また、ある実施例の構成に他の実施例の構成を加えることも可能である。また、各実施例の構成の一部について他の構成の追加・削除・置換をすることができる。

以上の実施形態においては、ＥＣＵ１はＩＳＯ２６２６２に準拠したアーキテクチャを備えているが、本発明の対象はこれに限られずその他機能部を備えていてもよい。例えばデータを保存するための不揮発性メモリ（バックアップＲＡＭ）や水温センサなどを備えてもよい。また本発明は、車両が備える電気機器を制御する制御装置一般に対して適用することができる。

以上の実施形態においては、各閾値は１つのみであるが、例えば上限値や下限値などを用いて閾値の範囲を表現することもできる。すなわち異常判定を実施することができれば任意形式の閾値を用いることができる。

以上の実施形態においては、説明の簡易のため５ｍｓ周期処理と１０ｍｓ周期処理を取り扱っているが、その他周期の処理についても本発明を適用することができる。周期処理以外の機能についても同様である。

以上の実施形態においては、安全度水準フィールド５２４の値としてＡＳＩＬ（１）とＱＭ（０）の２種類を例示しているが、３種類以上の安全度水準を設けてもよい。以上の実施形態においては、異常レベル１〜３を例示しているが、より多くの異常レベルを設けることもできる。

以上の実施形態においては、異常レベルの個数に応じて図１７で説明した３つのフェールセーフ処理を例示したが、その他のフェールセーフ処理を実施することもできるし、異常レベルの個数に応じてより多くのフェールセーフ処理を設けることもできる。いずれの場合であっても、異常レベルが高ければより安全側に倒したフェールセーフ処理を実施することが望ましい。

上記各構成、機能、処理部、処理手段等は、それらの一部や全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記録装置、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。

１：ＥＣＵ、２：ＣＰＵ、３：メモリ、４０１：ソフトウェア制御部、４０２：異常管理テーブル初期化部、４０３：処理実行部、４０４：１０ｍｓ処理実行部、４０５：５ｍｓ処理実行部、４０６：異常検出部、４０７：機能診断部、４０８：システム診断部、４０９：異常レベル判定部、４１０：ＦＳ実行部、４１１：時間管理部、５１０：時間管理テーブル、５２０：処理管理テーブル、５３０：動作状況管理テーブル、５４０：機能異常管理テーブル、５５０：システム異常管理テーブル、５６０：判定結果管理テーブル。

Claims (7)

1. 車両の動作を制御する車両制御装置であって、
   複数の個別機能を有するシステム部の異常を検出する異常検出部、
   前記システム部の異常レベルを判定する異常レベル判定部、
   を備え、
   前記システム部は、前記個別機能を実行する処理実行部を備え、
   前記異常検出部は、各前記個別機能についてそれぞれ個別に前記異常を検出し、
   前記異常レベル判定部は、前記複数の個別機能それぞれについての前記異常検出部による異常検出結果に基づき、前記システム部の異常レベルを判定し、
   前記異常レベル判定部は、各前記個別機能それぞれについて前記異常検出部が検出した前記異常の累積回数に基づき算出した異常回数値、または各前記個別機能それぞれについて前記異常検出部が検出した前記異常の所定時間当たりの頻度に基づき算出した異常回数値が、所定の回数閾値を超えている場合は、前記システム部の異常を示すシステム異常カウンタをカウントアップし、
   前記異常レベル判定部は、前記システム異常カウンタが所定のシステム異常閾値を超えた場合は、前記異常レベルが最も高いと判定し、
   前記異常検出部は、前記処理実行部が前記個別機能を実行するのにかかった所要時間が所定の実行時間閾値を超えている場合、または前記処理実行部が所定時間内において前記個別機能を実行した回数が所定の実行回数閾値を超えている場合は、その個別機能についての前記累積回数または前記頻度をカウントアップし、
   前記異常検出部は、前記累積回数または前記頻度が所定の閾値を超えている前記個別機能が異常であると判定し、
   前記異常レベル判定部は、前記異常検出部が異常であると判定した前記個別機能の個数に応じて前記異常レベルを判定する
   ことを特徴とする車両制御装置。
2. 前記車両制御装置は、前記異常検出部が検出した前記異常の累積回数に応じ、前記システム部の異常時処理を段階的に実行する、フェールセーフ実行部を備え、
   前記フェールセーフ実行部は、前記異常レベル判定部が判定した前記異常レベルに対応する前記異常時処理を実行する
   ことを特徴とする請求項１記載の車両制御装置。
3. 前記車両制御装置は、前記個別機能が要求する安全レベルを定義する値を記述した処理管理テーブルを備え、
   前記異常検出部は、各前記個別機能についてそれぞれ個別に前記異常を検出し、
   前記異常レベル判定部は、前記処理管理テーブルが定義している前記安全レベルが所定レベル以上である前記個別機能について前記異常検出部が前記異常を検出した場合は、前記安全レベルが前記所定レベル未満である前記個別機能について前記異常検出部が前記異常を検出した場合よりも、前記異常レベルが高いと判定する
   ことを特徴とする請求項１記載の車両制御装置。
4. 前記処理実行部は、前記個別機能を開始してから完了するまでの所要時間、または所定時間内における前記個別機能の実行回数を計測し、
   前記異常検出部は、前記所要時間が所定の実行時間閾値を超えている場合、または前記実行回数が所定の実行回数閾値を超えている場合は、前記累積回数または前記頻度をカウントアップする
   ことを特徴とする請求項１記載の車両制御装置。
5. 前記フェールセーフ実行部は、前記異常レベル判定部が判定した前記異常レベルが所定の高異常レベル以上である場合は、前記異常時処理として、ソフトウェアリセットにより前記システム部を初期化する
   ことを特徴とする請求項２記載の車両制御装置。
6. 前記フェールセーフ実行部は、前記異常レベル判定部が判定した前記異常レベルが所定の低異常レベル以下である場合は、前記異常時処理として、前記異常検出部が前記異常を検出した前記個別機能を起動することを禁止する
   ことを特徴とする請求項２記載の車両制御装置。
7. 前記車両制御装置は、前記個別機能が要求する安全レベルを定義する値を記述した処理管理テーブルを備え、
   前記フェールセーフ実行部は、前記異常レベル判定部が判定した前記異常レベルが所定の高異常レベル未満かつ所定の低異常レベルを超えている場合は、前記異常時処理として、前記処理管理テーブルが定義している前記安全レベルが所定レベル以下である前記個別機能全てを起動することを禁止する
   ことを特徴とする請求項２記載の車両制御装置。

Images