(57)【要約】      （修正有）【課題】複数の動作モードを有する車両制御装置において、演算リソースを効率的に使用する。【解決手段】車両の動作を制御する装置であって、制御動作のモード毎に実行すべき制御モジュールを定義した定義情報と制御モジュールが定義している演算内容を実行する演算部とを備え、演算部は動作モードに対応して定義情報が定義している制御モジュールを実行する。定義情報は車両が電気自動車として走行する電気自動車モードにおいて実行すべき制御モジュールとその実行順序、車両がエンジン走行車として走行するエンジンモードにおいて実行すべき制御モジュールとその実行順序、および、車両がモーターとエンジンを併用して走行するフル走行モードにおいて実行すべき制御モジュールとその実行順序、を定義しており、演算部はその動作モードに対応して定義情報が定義している制御モジュールを定義されている実行順序にしたがって実行する。【選択図】図２
2014004858.tif 000002
【特許請求の範囲】
【請求項１】
車両の動作を制御する装置であって、
制御動作の種類毎にその制御動作の演算内容を定義した複数の制御モジュールと、
前記車両の動作モード毎に実行すべき前記制御モジュールを定義した定義情報と、
前記制御モジュールが定義している演算内容を実行する演算部と、
を備え、
前記演算部は、
前記車両の動作モードを取得し、その動作モードに対応して前記定義情報が定義している前記制御モジュールを実行する
ことを特徴とする車両制御装置。
【請求項２】
前記定義情報は、
前記車両が電気自動車として走行する電気自動車モードにおいて実行すべき前記制御モジュールとその実行順序、
前記車両がエンジン走行車として走行するエンジンモードにおいて実行すべき前記制御モジュールとその実行順序、および
前記車両がモータとエンジンを併用して走行するフル走行モードにおいて実行すべき前記制御モジュールとその実行順序
を定義しており、
前記演算部は、
前記車両が前記電気自動車モード、前記エンジンモード、および前記フル走行モードのうちいずれの動作モードで動作しているかを取得し、
その動作モードに対応して前記定義情報が定義している前記制御モジュールを定義されている実行順序にしたがって実行する
ことを特徴とする請求項１記載の車両制御装置。
【請求項３】
前記車両制御装置は、前記車両の動作モードに対応する前記制御モジュールを実行する複数の前記演算部を備えており、
前記演算部は、前記車両がいずれの動作モードで動作しているかを示す車両動作モードフラグを前記定義情報として書き込み、
前記定義情報内に書き込まれた前記車両の動作モードに対応する前記制御モジュールを実行していない前記演算部のうち少なくとも一部は、前記車両の動作モードに対応する前記制御モジュール以外の前記制御モジュールが定義している演算内容のうち前記車両の動作モードと競合しないものの少なくとも一部を、前記車両の動作モードに対応する前記制御モジュールを実行している前記演算部の演算処理と並行して実行する
ことを特徴とする請求項１記載の車両制御装置。
【請求項４】
前記制御モジュールは、１以上のプログラム関数を用いて実装されたソフトウェアとして構成されており、
前記定義情報は、前記制御モジュールの動作状態に応じて実行すべき前記プログラム関数を指定する関数指定フラグを前記制御モジュール毎に定義しており、
前記演算部は、前記制御モジュールの動作状態を取得し、その動作状態に対応して前記関数指定フラグが指定している前記プログラム関数を実行する
ことを特徴とする請求項１記載の車両制御装置。
【請求項５】
前記制御モジュールは、
前記制御モジュールの動作状態毎に実行すべき処理を記述したプログラム関数と、
前記関数指定フラグに応じて処理を分岐して前記関数指定フラグに対応するプログラム関数を呼び出す分岐命令と、
を用いて実装されており、
前記演算部は、前記制御モジュールの動作状態を取得し、その動作状態に対応する前記関数指定フラグが指定する前記分岐命令の分岐先において呼び出すよう指定されている前記プログラム関数を実行する
ことを特徴とする請求項４記載の車両制御装置。
【請求項６】
前記関数指定フラグは、前記車両の動作モードに応じて実行すべき前記プログラム関数を前記制御モジュール毎に指定しており、
前記演算部は、前記車両の動作モードを取得し、その動作モードに対応して前記関数指定フラグが指定する前記プログラム関数を実行する
ことを特徴とする請求項５記載の車両制御装置。
【請求項７】
前記関数指定フラグは、前記車両の燃費モードに応じて実行すべき前記プログラム関数を前記制御モジュール毎に指定しており、
前記演算部は、前記車両の燃費モードを取得し、その燃費モードに対応して前記関数指定フラグが指定する前記プログラム関数を実行する
ことを特徴とする請求項５記載の車両制御装置。
【請求項８】
前記関数指定フラグは、前記制御モジュールが実行すべき自己診断処理を実装した前記プログラム関数を前記制御モジュール毎に指定しており、
前記演算部は、前記関数指定フラグが指定する自己診断処理を実装した前記プログラム関数を実行する
ことを特徴とする請求項５記載の車両制御装置。
【請求項９】
前記関数指定フラグは、前記演算部の演算負荷レベルに応じて実行すべき前記プログラム関数を前記制御モジュール毎に指定しており、
前記演算部は、自己の演算負荷レベルに対応して前記関数指定フラグが指定する前記プログラム関数を実行する
ことを特徴とする請求項５記載の車両制御装置。
【請求項１０】
前記関数指定フラグは、前記車両の動作フェーズに応じて実行すべき前記プログラム関数を前記制御モジュール毎に指定しており、
前記演算部は、前記車両の動作フェーズを取得し、その動作フェーズに対応して前記関数指定フラグが指定する前記プログラム関数を実行する
ことを特徴とする請求項５記載の車両制御装置。
【請求項１１】
前記関数指定フラグは、前記制御モジュールに要求される安全性レベルに応じて実行すべき前記プログラム関数を前記制御モジュール毎に指定しており、
前記演算部は、前記御モジュールに要求される安全性レベルを取得し、その安全性レベルに対応して前記関数指定フラグが指定する前記プログラム関数を実行する
ことを特徴とする請求項５記載の車両制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両の動作を制御する装置に関するものである。
【背景技術】
【０００２】
車両の動作を電子的に制御する車両制御装置（Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ：ＥＣＵ）は、ＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）が制御プログラムを実行することにより、車両の各種動作を制御する。この制御プログラムは一般に、実行単位となる複数の制御モジュールに細分化して記述されている。
【０００３】
制御モジュールの実行状態は、ＥＣＵのＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）により管理され、あらかじめ定められた実行優先順位（タスクレベル）に基づいて実行される。例えばエンジンを制御するＥＣＵは、クランクパルス信号等のパルス割り込み、ＡＤ変換割り込み、インターバルの異なる複数のタイマ割り込み等のイベント発生に応じて、様々な制御タスクを実行する。
【０００４】
一方で近年は、車両の動力源としてエンジン（ＥＮＧ）とともにモータを搭載したハイブリッド車が開発されている。ハイブリッド車は、ＥＮＧのみで走行するＥＮＧ走行モード、モータのみで走行するＥＶ（Ｅｌｅｃｔｒｉｃ  Ｖｅｈｉｃｌｅ）走行モード、ＥＮＧとモータを同時に稼動させて走行するハイブリッド走行モードなど、複数の走行モードで走行することができ、走行モードに応じて対応するＥＣＵがそれぞれ制御を実行する。
【０００５】
ＥＣＵのような組込制御機器は、従来の制御プログラムを再利用して新たな制御プログラムを開発することが多いため、従来実装されていたエンジン制御をベースにして、ハイブリッド車の制御プログラムを開発する場合がある。そうすると、各ＥＣＵ内において、ＥＶ走行モード時には実行する必要がないＥＮＧ走行モード用の制御モジュールを実行したり、その反対にＥＮＧ走行モード時には実行する必要がないＥＶ走行モード用の制御モジュールを実行したりする実装が生じる可能性がある。したがって、運転シーンによっては不要な制御演算を常に実施していることになり、演算負荷が過剰になってしまう場合があった。
【０００６】
下記特許文献１には、上記のような課題に対して、制御装置のＣＰＵ演算負荷がある一定値以上の高負荷になった場合には、通常の制御モードから、通常より制御を抑制させた抑制モードに処理を切り替え、演算負荷の平均化を図る技術が開示されている。
【０００７】
下記特許文献２には、複数のＥＣＵ間で負荷を分散して処理を実行することにより、各ＥＣＵの余剰能力を有効活用しようとする技術が提案されている。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２００１−２５６０６３号公報
【特許文献２】特開２００４−０３８７６６号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
上記特許文献１に記載されている技術では、ＣＰＵ演算負荷に基づき制御を抑制している。しかし、想定していた要因とは異なる要因によりＣＰＵ演算負荷が高くなっている場合、ＣＰＵ演算負荷を抑制したとしてもその要因が除去されるとは限らない。そのため、ＣＰＵ演算負荷のみを根拠として演算負荷を抑制したとしても、車両制御において求められる安全性、燃費、エミッション性能などを必ずしも確保することができない可能性が考えられる。
【００１０】
上記特許文献２に記載されているように、ＣＰＵ数を増やして負荷分散を図る手法は、車両制御装置のコスト増加を招くため、常に採用することができるものではない。演算性能の高いＣＰＵを用いる手法も同様である。また仮に、ＣＰＵの数や性能などの演算リソースを潤沢に利用できる環境を整えられたとしても、プログラム開発者が想定していない高負荷状態が発生し得ることには変わりなく、単にその可能性を低減することができるに過ぎない。したがって、車両制御装置のような高い信頼性を要する組込制御装置は、ＣＰＵの数や演算性能によらず、高負荷時の対策を講じておく必要がある。
【００１１】
上記のような課題は、制御プログラムを再利用することと密接な関係があると考えられる。すなわち、車両の品種に対応した制御プログラムを個別に開発するのであれば、その車両品種に最適化した制御を実装すればよいので、車両の走行モードに応じて予想外の高負荷が生じる可能性は少ないといえる。
【００１２】
本発明は、上記のような課題に鑑みてなされたものであり、複数の動作モードを有する車両制御装置において、演算リソースを効率的に使用することのできる技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明に係る車両制御装置は、車両の動作モード毎に実行すべき制御モジュールを定義した定義情報を備え、動作モードに対応して定義情報が定義している制御モジュールを実行する。
【発明の効果】
【００１４】
本発明に係る車両制御装置によれば、複数の車両動作モードに対応した制御モジュールを再利用している場合においても、動作モードを実行するために必要な制御モジュールのみを選択的に実行することができる。これにより、不要な制御演算を実行する必要がなくなるので、演算処理の増大を抑制し、処理能力を効率良く使用しつつ動作モードに適した制御演算を適切に実行して安全性などを確保することができる。
【００１５】
上記した以外の課題、構成、および効果は、以下の実施形態の説明により明らかになるであろう。
【図面の簡単な説明】
【００１６】
【図１】実施形態１に係る車両制御装置１００の構成図である。
【図２】タスクリスト１２２の構成例を示す図である。
【図３】ＣＰＵ１１０が制御タスクを実行する処理のタイムチャートを説明する図である。
【図４】ＣＰＵ１１０が制御タスクを実行する処理を説明するフローチャートである。
【図５】実施形態２に係る車両制御装置１００のＣＰＵ構成を示す概念図である。
【図６】制御モジュール１２１の内部で使用する、制御モジュール１２１の動作状態を示す情報を例示する図である。
【図７】制御モジュール１２１が図６に示す走行モード情報を用いて、実行する関数を切り分ける処理を説明するフローチャートである。
【発明を実施するための形態】
【００１７】
＜実施の形態１＞
図１は、本発明の実施形態１に係る車両制御装置１００の構成図である。車両制御装置１００は、車両の動作を電子的に制御する装置であり、ＣＰＵ１１０、ＲＯＭ（Ｒｅａｄ  Ｏｎｌｙ  Ｍｅｍｏｒｙ）１２０、ＲＡＭ（Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）１３０を備える。ＣＰＵ１１０は、ＲＯＭ１２０が格納している各プログラムを実行する。ＲＯＭ１２０は、制御モジュール１２１、タスクリスト１２２を格納している。ＲＡＭ１３０は、ＣＰＵ１１０が動作する際に一時的に使用するデータなどを格納する。
【００１８】
制御モジュール１２１は、車両の制御処理を記述したソフトウェアである。ここでは６つの制御モジュール１２１を例示したが、個数はこれに限られるものではない。各制御モジュール１２１の違いについては後述の図２で説明する。各制御モジュール１２１は、必ずしも単一のソフトウェアとして実装する必要はなく、複数のソフトウェアプログラムを組み合わせて１つの制御モジュール１２１とすることもできる。
【００１９】
以下では記載の便宜上、制御モジュール１２１などのソフトウェアプログラムを動作主体として説明する場合があるが、実際にこれらソフトウェアプログラムを実行するのはＣＰＵ１１０などの演算部であることを付言しておく。
【００２０】
図２は、タスクリスト１２２の構成例を示す図である。制御モジュール１２１は、車両がＥＶ走行モードのときに実行すべき処理を記述したものと、車両がＥＮＧ走行モードのときに実行すべき処理を記述したものとに分けられる。従来はこれらを区別することなく再利用していたため、本来は実行する必要がない制御モジュール１２１が実行される場合があった。そこで本実施形態１では、走行モード毎に実行すべき制御モジュール１２１とその実行順序を記述したタスクリスト１２２を設けることにした。本実施形態１における「定義情報」は、タスクリスト１２２がこれに相当する。
【００２１】
タスクリスト１２２は、制御モジュール１２１を車両の走行モード毎にあらかじめ分類し、その実行順序を定義するデータである。最も基本的には、車両の走行モード毎に１つのタスクリストを設けるが、同じ走行モードであっても複数種類のタスクが存在する場合には、タスクの種類毎にタスクリストを設けてもよい。これらタスクリストを総合したものを、タスクリスト１２２としてあらかじめＲＯＭ１２０内に格納しておく。
【００２２】
図２では、４つのタスクリストを例示した。タスクリスト１は、車両がＥＶ走行モードのときにＣＰＵ１１０が実行すべき制御モジュール１２１とその実行順序を定義したものである。タスクリスト２と３は、車両がＥＮＧ走行モードのときにＣＰＵ１１０が実行すべき制御モジュール１２１とその実行順序を定義したものである。例えば１ｍｓ周期で実行すべきタスクと１０ｍｓ周期で実行すべきタスクが存在するような場合には、同じ走行モードについて複数のタスクリストを設けることができる。タスクリスト４は、車両がフル走行モードのときにＣＰＵ１１０が実行すべき制御モジュール１２１とその実行順序を定義したものである。フル走行モードとは、例えば坂道など大きな走行動力を必要とするときに、一時的にエンジンとモータを併用して走行する動作モードである。
【００２３】
図３は、ＣＰＵ１１０が制御タスクを実行する処理のタイムチャートを説明する図である。ＣＰＵ１１０は、制御演算を開始するに際して、車両の動作モードを取得する。ＣＰＵ１１０は、その動作モードに対応する制御モジュール１２１とその実行順序をタスクリスト１２２から読み出し、これにしたがって各制御モジュール１２１を実行する。
【００２４】
これに対し従来の車両制御装置は、個々の命令レベルにおいては車両の走行モードに応じて処理を分岐させたり不要な処理をスキップさせたりする場合もあったが、制御モジュール１２１単位で実行要否や実行順序を定義していなかった。そのため、車両の走行モードによらずタスクリスト４と同様に全ての制御モジュール１２１を実行するか、あるいは各制御モジュール１２１のなかでいくつかの命令をスキップする程度の使い分けをしていた程度であった。本実施形態１により、走行モードに応じて必要な制御モジュールのみを実行し、演算負荷を抑制することができる。
【００２５】
図４は、ＣＰＵ１１０が制御タスクを実行する処理を説明するフローチャートである。以下、図４の各ステップについて説明する。
ＣＰＵ１１０は、車両の走行モードを取得する（Ｓ４０１）。走行モードがＥＶ走行であればステップＳ４０４へ進み（Ｓ４０２）、ＥＮＧ走行モードである場合はステップＳ４０５へ進み（Ｓ４０３）、それ以外であればフル走行モードであると判定してステップＳ４０６へ進む。ステップＳ４０４〜Ｓ４０６では、走行モードに対応したタスクリストを読み出す。同じ走行モードについて複数のタスクリストがある場合は、それらを区別するためのパラメータ（例えば動作周期）をさらに取得して対応するタスクリストを読み出す。ＣＰＵ１１０は、読み出したタスクリストの記述にしたがって、各制御モジュール１２１を実行する。
【００２６】
＜実施の形態１：まとめ＞
以上のように、本実施形態１に係る車両制御装置１００は、車両の走行モードに応じてＣＰＵ１１０が実行すべき制御モジュール１２１およびその実行順序を定義したタスクリスト１２２を備え、その定義にしたがって車両走行モードに応じた制御モジュール１２１を実行する。これにより、必要十分な制御モジュール１２１のみを実行し、演算負荷の不要な増大を抑制しつつ適切な制御演算を実行して安全性などを確保することができる。
【００２７】
＜実施の形態２＞
車両制御装置によっては、複数のＣＰＵを備え、車両の動作モード毎にＣＰＵを切り替えるように構成されたものがある。本発明の実施形態２では、このような車両制御装置において、実施形態１で説明したタスクリスト１２２を利用する構成例を説明する。複数のＣＰＵが車両の走行モードに応じて切り替わる構成以外は実施形態１と概ね同様であるため、以下では差異点を中心に説明する。
【００２８】
図５は、本実施形態２に係る車両制御装置１００のＣＰＵ構成を示す概念図である。本実施形態２に係る車両制御装置１００は、２つのＣＰＵ１１１と１１２を備える。ＣＰＵ１１１はＥＮＧ走行モードにおける制御を実行するＣＰＵであり、エンジン御モジュール（ＥＣＭ）と呼ぶことにする。ＣＰＵ１１２はＥＶ走行モードにおける制御を実行するＣＰＵであり、ハイブリッド制御モジュール（ＨＣＭ）と呼ぶことにする。
【００２９】
車両がＥＮＧ走行モードで動作しているときは、ＣＰＵ１１１は実施形態１で説明したタスクリスト１にしたがって制御モジュール１２１を実行し、高負荷状態となる。このときＣＰＵ１１２はＣＰＵ１１１に比して低負荷な状態となり、ＣＰＵ１１１が主体となって車両を制御する。車両がＥＶ走行モードに切り替わると、ＣＰＵ１１１はＣＰＵ１１２へ制御を譲る。ＣＰＵ１１２は、実施形態１で説明したタスクリスト２にしたがって制御モジュール１２１を実行する。演算負荷の状態は反転する。以下同様に制御動作が切り替わる。
【００３０】
本実施形態２では、いずれかのＣＰＵが低負荷状態である場合には、そのＣＰＵは演算リソースの観点から余裕があることに着目し、先行して実行することができる演算処理をあらかじめ実行しておくこととする。すなわち、ＣＰＵ１１１が動作している間はＣＰＵ１１２は低負荷状態であるため、ＣＰＵ１１２はＥＶ走行モードにおいて実行する制御演算の一部を先行して実行する。同様にＣＰＵ１１２が動作している間はＣＰＵ１１１は低負荷状態であるため、ＣＰＵ１１１はＥＮＧ走行モードにおいて実行する制御演算の一部を先行して実行する。
【００３１】
このように制御演算の一部を低負荷状態の間に先行して実行しておくことにより、車両の走行モードが切り替わった時点で既に一部の制御演算を完了させておくことができるので、車両制御装置１００全体として処理を平滑化し、演算リソースを有効に活用することができる。
【００３２】
低負荷状態にあるＣＰＵが一部の制御演算を先行して開始する具体的な実装手法としては、例えば以下のようなものが考えられる。
（ａ）各制御モジュール１２１は、高負荷状態において実行すべきものと低負荷状態において先行して実行すべきものに分けてあらかじめ構成しておく。
（ｂ）高負荷状態にあるＣＰＵは、その旨を示す車両動作モードフラグをＲＡＭ１３０などの記憶領域に書き込む。
（ｃ）タスクリスト１２２をＣＰＵ毎に設け、各ＣＰＵは車両の現在の走行モードを車両動作モードフラグに基づき取得し、その走行モードに対応するタスクリストの記述にしたがって制御モジュール１２１を実行する。
【００３３】
上記のようにタスクリスト１２２と車両動作モードフラグを構成することにより、各ＣＰＵは現在の車両動作モードと各ＣＰＵの負荷状態を知ることができる。すなわち、タスクリスト１２２と車両動作モードフラグの組み合わせ（本実施形態２における「定義情報」）は、各ＣＰＵが車両の走行モードに応じて実行すべき制御モジュール１２１を定義する情報として用いることができる。
【００３４】
＜実施の形態２：まとめ＞
以上のように、本実施形態２に係る車両制御装置１００は、車両の走行モードに対応する複数のＣＰＵを備え、車両の走行モードに対応する制御を実行していないＣＰＵは、一部の制御演算を先行して実行する。これにより、車両制御装置１００全体として演算負荷を平準化して演算リソースを効率的に活用することができる。
【００３５】
＜実施の形態３＞
実施形態１〜２では、車両の走行モードに対応する制御モジュール１２１を実行することを説明した。制御モジュール１２１は、１以上の制御プログラムによって構成されているため、走行モードに応じて実行すべき処理を制御プログラム単位で切り替えることができる。しかし実際の制御プログラムに記述されている個々のプログラム命令は、車両の走行モードによっては必要ないものが含まれている可能性がある。特に制御プログラムを再利用する場合には、個々のプログラム命令については重複記述となっている可能性も考えられる。
【００３６】
そこで本発明の実施形態３では、制御モジュール１２１内のプログラム関数単位で、車両の走行モードに応じて実行すべきものと実行しないものを切り分ける手法を説明する。その他の構成は実施形態１〜２と同様であるため、以下では差異点を中心に説明する。
【００３７】
図６は、制御モジュール１２１の内部で使用する、制御モジュール１２１の動作状態を示す情報を例示する図である。制御モジュール１２１内のプログラム関数単位で実行可否を切り分けるためには、各プログラム関数が車両または制御モジュール１２１の動作状態を取得できるようにする必要がある。そこで本実施形態３では、制御モジュール１２１の内部変数として、図６に例示するような情報を各制御モジュール１２１に保持させることとした。
【００３８】
図６に示す情報は、車両や制御モジュール１２１の動作状態によって変化しない固定的なものであれば、例えば制御モジュール１２１内部に固定的に記述してもよいし、ＲＯＭ１２０内の特定領域にあらかじめ格納しておいてもよい。車両や制御モジュール１２１の動作状態によって変化する動的なものであれば、これら動作状態を取得した制御モジュール１２１がＲＡＭ１３０内の適当な記憶領域にその動作状態を書き込み、各制御モジュール１２１がその動作状態を参照して自己の内部変数として取り込むようにすればよい。以下では、図６に例示した各情報について説明する。
【００３９】
（図６：走行モード情報）
走行モード情報は、車両の走行モード（ＥＮＧ走行モード、ＥＶ走行モード、フル走行モード）を示すフラグである。車両の走行モードは動的に変化するため、いずれかの制御モジュール１２１が車両の走行モードを取得してＲＡＭ１３０などにこれを書き込み、各制御モジュール１２１はこれを読み出して自己の内部変数として本情報を取り込むようにすればよい。本情報を取り込んだ各制御モジュール１２１は、自己の動作状態を本情報に応じて設定することができる。詳細は後述の図７で説明する。以下に説明する各情報についても同様である。
【００４０】
（図６：燃費モード情報）
運転者は、省燃費走行をしたいとき、車両へその旨を指示するボタンなどを押下し、車両制御装置１００がこれに応じて燃費性能を重視した制御を実行する。これを省燃費モードなどと呼ぶ。燃費モード情報は、車両が省燃費モードで走行しているか否かを示すフラグである。車両が省燃費モードで走行しているか否かは動的に変化するため、走行モード情報と同様に処理すればよい。
【００４１】
（図６：自己診断レベル情報）
自己診断レベル情報は、制御モジュール１２１が実装している自己診断機能の種類を示すフラグである。例えばセンサが正常動作しているか否かを診断する処理（センサ系診断処理）はいつ実行してもよいので、ＣＰＵ１１０が低負荷のときに実行すれば効率がよい。一方で診断対象となるセンサが稼働中（制御中）でないと正しく実行できないような診断（機能診断）は、センサの稼動状況により処理を実行するか否かを決定する必要がある。そこで制御モジュール１２１内に各自己診断機能の種類を示す本情報を保持しておき、各制御モジュール１２１は本情報にしたがって自己診断機能を実行するタイミングを決定する。自己診断機能は制御モジュール１２１内の関数として実装されているので、自己診断機能の種類は固定されている。したがって本情報は、固定的に保持しておけばよい。
【００４２】
（図６：演算負荷レベル情報）
演算負荷レベル情報は、ＣＰＵ１１０の演算負荷を示す情報である。ＣＰＵ１１０の演算負荷は動的に変化するので、走行モード情報と同様に処理すればよい。本情報は、実施形態２において各ＣＰＵの演算負荷状態を把握するために用いることもできる。あるいは制御モジュール１２１内で演算負荷に応じて処理を変更する場合に用いることもできる。例えば制御モジュール１２１内部で同じ処理を異なる関数によって実行して互いの演算結果を照合している場合、演算負荷が高まっている間はかかる処理を一時中断して単一の関数のみを用いるように処理を変更することが考えられる。
【００４３】
（図６：制御実行レベル情報）
制御実行レベル情報は、車両の動作フェーズ（運転状況）を示すフラグである。ここでは、始動時、アイドルストップ時、低速走行時、高速走行時の４フェーズを例示した。制御モジュール１２１は、本情報に基づき、車両の動作フェーズに応じて処理を変更することができる。車両の動作フェーズは動的に変化するため、走行モード情報と同様に処理すればよい。
【００４４】
（図６：ＩＳＯ２６２６２（機能安全）情報）
ＩＳＯ２６２６２（機能安全）情報は、各制御モジュール１２１に求められる機能安全レベルをＩＳＯ２６２６２規格にしたがって定義した情報であり、ＡＳＩＬ（Ａｕｔｏｍｏｔｉｖｅ  Ｓａｆｅｔｙ  Ｉｎｔｅｇｒｉｔｙ  Ｌｅｖｅｌ）レベルによって記述することができる。制御モジュール１２１は、本情報に基づき、求められている機能安全レベルに応じて処理を変更することができる。各制御モジュール１２１に求められる機能安全レベルは制御モジュール１２１を実装する時点で定まっているので、本情報は、固定的に保持しておけばよい。
【００４５】
図７は、制御モジュール１２１が図６に示す走行モード情報を用いて、実行する関数を切り分ける処理を説明するフローチャートである。図６に示すその他の情報についても図７と同様に処理することができる。以下、図７の各ステップについて説明する。
【００４６】
制御モジュール１２１は、例えばプログラムの先頭部分において、走行モード情報を読み出す（Ｓ７０１）。制御モジュール１２１は、走行モード情報に基づき車両の走行モードを判定し（Ｓ７０２）、その走行モードに対応する関数を実行する（Ｓ７０３〜Ｓ７０５）。
【００４７】
図７に示すフローチャートは、実施形態１で説明した、制御モジュール１２１単位で実行要否を切り分ける処理と併用することができる。すなわち、制御プログラムを再利用している場合には、ＥＶ走行モードの制御処理を実装した制御モジュール１２１内に、ＥＮＧ走行モードにおいて実行すべき関数が存在する可能性があるからである。したがって図７のフローチャートは、制御モジュール１２１が実施形態１で説明した各タスクリストのいずれに属するかによらず、実行することが望ましい。
【００４８】
図７では、車両の走行モードに応じて実行する関数を変更する例を示したが、同様に実行する必要がない関数をスキップすることもできる。実行する関数を変更する場合は、例えばｓｗｉｔｃｈ分岐命令をプログラム内で用いればよい。関数をスキップする場合は、例えばｉｆ分岐命令をプログラム内で用いればよい。
【００４９】
制御モジュール１２１は、図６に示す情報を複数利用することもできる。この場合は、図７と同様の処理を図６の各情報について実行すればよい。このとき、各情報にしたがって実行すべき関数を判断した結果が競合する可能性があるので、図６に示す各情報に優先順位を付けて高順位の情報に基づく判断結果を優先適用するようにしてもよい。
【００５０】
図６に示す各情報を制御モジュール１２１が取り込むことにより、各制御モジュール１２１は自己の動作状態とこれに対応して実行すべき関数を知ることができる。すなわち、図６に示す各情報（本実施形態３における「定義情報」）は、ＣＰＵ１１０が制御モジュール１２１の動作状態に応じて実行すべき関数を指定する関数指定フラグとして用いることができる。
【００５１】
＜実施の形態３：まとめ＞
以上のように、本実施形態３に係る車両制御装置１００は、制御モジュール１２１の動作状態を定義する情報をＲＡＭ１３０内や制御モジュール１２１内に保持し、これに基づき制御モジュール１２１が実行すべき関数を切り替える。これにより、必要十分な関数のみを実行し、演算リソースの利用効率をさらに向上させることができる。
【００５２】
本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。上記実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることもできる。また、ある実施形態の構成に他の実施形態の構成を加えることもできる。また、各実施形態の構成の一部について、他の構成を追加・削除・置換することもできる。
【００５３】
上記各構成、機能、処理部、処理手段等は、それらの一部や全部を、例えば集積回路で設計する等によりハードウェアで実現してもよい。また、上記の各構成、機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現してもよい。各機能を実現するプログラム、テーブル、ファイル等の情報は、メモリ、ハードディスク、ＳＳＤ（Ｓｏｌｉｄ  Ｓｔａｔｅ  Ｄｒｉｖｅ）等の記録装置、ＩＣカード、ＳＤカード、ＤＶＤ等の記録媒体に格納することができる。
【符号の説明】
【００５４】
１００：車両制御装置、１１０〜１１２：ＣＰＵ、１２０：ＲＯＭ、１２１：制御モジュール、１２２：タスクリスト、１３０：ＲＡＭ。
【図１】
2014004858.tif 000003
【図２】
2014004858.tif 000004
【図３】
2014004858.tif 000005
【図４】
2014004858.tif 000006
【図５】
2014004858.tif 000007
【図６】
2014004858.tif 000008
【図７】
2014004858.tif 000009