(57)【要約】      （修正有）【課題】監視用サブマイコンの負荷を軽減することのできる制御装置を提供する。【解決手段】制御装置は、被制御対象を制御するための制御アプリケーションを実行するメインＣＰＵ１１を有するメインマイコン１０と、制御アプリケーションの実行状況を監視するための監視アプリケーションを実行するサブＣＰＵ２１を有してメインマイコンを監視するサブマイコン２０と、を備える。制御アプリケーションは、機能ごとにメインマイコン内で分割して格納され、メインＣＰＵは、入力される起動要因に基づいて、起動すべき被制御対象に対応する制御アプリケーションに限定して実行するものであり、監視アプリケーションは、制御アプリケーションに対応するようにサブマイコン内で分割して格納され、サブＣＰＵは、起動要因に基づいて、メインＣＰＵにより実行される制御アプリケーションに対応する監視アプリケーションを実行してメインマイコンを監視する。【選択図】図１
2017091169.tif 000002
【特許請求の範囲】
【請求項１】
被制御対象（２００）を制御するための制御アプリケーションが格納されたメインメモリ（１２）と、前記制御アプリケーションを読み込んで実行するメインＣＰＵ（１１）と、を有するメインマイコン（１０）と、
前記制御アプリケーションの実行状況を監視するための監視アプリケーションが格納されたサブメモリ（２２）と、前記監視アプリケーションを読み込んで実行するサブＣＰＵ（２１）と、を有して前記メインマイコンを監視するサブマイコン（２０）と、を備え、
前記制御アプリケーションは、機能ごとに前記メインメモリ内で分割して格納され、
前記メインＣＰＵは、入力される起動要因に基づいて、起動すべき前記被制御対象に対応する前記制御アプリケーションに限定して実行するものであり、
前記監視アプリケーションは、前記制御アプリケーションに対応するように前記サブメモリ内で分割して格納され、
前記サブＣＰＵは、前記起動要因に基づいて、前記メインＣＰＵにより実行される前記制御アプリケーションに対応する前記監視アプリケーションを実行して前記メインマイコンを監視する制御装置。
【請求項２】
前記サブメモリには、前記制御アプリケーションのうち、監視が必要な前記制御アプリケーションに対応する前記監視アプリケーションが少なくとも格納され、
前記サブＣＰＵには、少なくとも、監視が必要な前記制御アプリケーションに対応する起動要因が入力され、対応する前記監視アプリケーションが実行される請求項１に記載の制御装置。
【請求項３】
前記監視アプリケーションは、前記制御アプリケーションのうち、実行されていない前記制御アプリケーションが真に実行されていないことを監視する機能を含む請求項１または請求項２に記載の制御装置。
【請求項４】
前記サブマイコンは、前記サブマイコンの監視により異常が検出された場合、異常が検出された前記制御アプリケーションに対応する前記被制御対象に対してフェールセーフを実施するものであり、
前記メインＣＰＵにより実行されている前記制御アプリケーションに異常が検出された場合と、実行されていない前記制御アプリケーションに異常が検出された場合とで、フェールセーフの内容を分ける請求項３に記載の制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
複数のアプリケーションを実行する制御装置に関する。
【背景技術】
【０００２】
近年、ＲＯＭやＲＡＭに代表されるメモリは情報を保持しておくための容量が飛躍的に増加している。一方、中央演算処理装置（ＣＰＵ）も、その処理能力が日々向上されつつある。
【０００３】
ところで、マイコンは、メモリに格納されたアプリケーションをＣＰＵが読み出して実行することで被制御対象の制御を行っている。メモリの容量が増大すれば、格納できるアプリケーションの総量が大きくなるので、被制御対象の制御の自由度を増大することができる。
【０００４】
しかしながら、メモリの容量の増加に対してＣＰＵの処理能力が追従できない場合、ＣＰＵがメモリに格納されたアプリケーションを十分に処理できない虞が生じる。
【０００５】
これに対して、特許文献１には、複数のアプリケーションのそれぞれに優先度を設定して車両の状況に応じて優先度の高いアプリケーションを起動する技術が開示されている。
【０００６】
これにより、ＣＰＵはメモリに格納されたすべてのアプリケーションを処理する必要がない。よって、ＣＰＵの負荷を軽減することができる。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００６−１５０９９９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００８】
ところで、複数のマイコンを有する制御装置がある。そのような制御装置は、例えばアプリケーションの実行を行うメインマイコンと、メインマイコンの動作を監視するサブマイコンとを有している。
【０００９】
サブマイコンはメインマイコンを監視するという機能上、メインマイコンが実行するすべてのアプリケーションを監視している。よって、サブマイコンを構成するメモリには監視用のアプリケーションが格納されている。メインマイコンのメモリに格納されるアプリケーション数が多くなれば、これに伴ってサブマイコンが格納すべき監視用アプリケーションの数も増加する。従来では、メインマイコンに格納されたアプリケーションの実行／非実行にかかわらず、サブマイコンがメインマイコンを監視しており、アプリケーションの数の増加に伴ってサブマイコンのＣＰＵの処理能力を超えてしまう虞がある。
【００１０】
本発明は、上記問題点を鑑みてなされたものであり、複数のアプリケーションを実行する制御装置において、監視用サブマイコンの負荷を軽減することのできる制御装置を提供することを目的とする。
【課題を解決するための手段】
【００１１】
ここに開示される発明は、上記目的を達成するために以下の技術的手段を採用する。なお、特許請求の範囲およびこの項に記載した括弧内の符号は、ひとつの態様として後述する実施形態に記載の具体的手段との対応関係を示すものであって、発明の技術的範囲を限定するものではない。
【００１２】
上記目的を達成するために、本発明は、被制御対象（２００）を制御するための制御アプリケーションが格納されたメインメモリ（１２）と、制御アプリケーションを読み込んで実行するメインＣＰＵ（１１）と、を有するメインマイコン（１０）と、制御アプリケーションの実行状況を監視するための監視アプリケーションが格納されたサブメモリ（２２）と、監視アプリケーションを読み込んで実行するサブＣＰＵ（２１）と、を有してメインマイコンを監視するサブマイコン（２０）と、を備え、制御アプリケーションは、機能ごとにメインメモリ内で分割して格納され、メインＣＰＵは、入力される起動要因に基づいて、起動すべき被制御対象に対応する制御アプリケーションに限定して実行するものであり、監視アプリケーションは、制御アプリケーションに対応するようにサブメモリ内で分割して格納され、サブＣＰＵは、起動要因に基づいて、メインＣＰＵにより実行される制御アプリケーションに対応する監視アプリケーションを実行してメインマイコンを監視することを特徴としている。
【００１３】
これによれば、監視アプリケーションはサブメモリ内で機能ごとに分割されて格納されている。そして、サブマイコンは、実行中の制御アプリケーションに対応した監視アプリケーションを実行して、実行中の制御アプリケーションの監視を優先的に行う。このため、実行されていない制御アプリケーションを積極的に監視することがない。したがって、サブＣＰＵの負荷を軽減することができる。
【図面の簡単な説明】
【００１４】
【図１】第１実施形態にかかる制御装置およびアクチュエータの概略構成を示すブロック図である。
【図２】メインメモリおよびサブメモリに格納されるアプリケーションを示す図である。
【図３】アクチュエータとその起動要因の一覧を示す図である。
【図４】サブＣＰＵの動作を示すフロー図である。
【図５】変形例１にかかるサブＣＰＵの監視の状態を示す図である。
【図６】変形例２にかかるフェールセーフの具体例を示す図である。
【発明を実施するための形態】
【００１５】
以下、本発明の実施の形態を図面に基づいて説明する。なお、以下の各図相互において、互いに同一もしくは均等である部分に、同一符号を付与する。
【００１６】
（第１実施形態）
最初に、図１〜図３を参照して、本実施形態に係る制御装置の概略構成について説明する。
【００１７】
本実施形態における制御装置は、例えばハイブリッド車を制御するハイブリッドＥＣＵである。図１に示すように、制御装置１００は、メインマイコン１０とサブマイコン２０とを備えている。
【００１８】
メインマイコン１０はアクチュエータ２００を駆動するための命令を含む駆動信号をアクチュエータ２００に出力している。アクチュエータ２００は特許請求の範囲に記載の被制御対象に相当する。一方、サブマイコン２０は、メインマイコン１０の状態を監視している。そして、サブマイコン２０はメインマイコン２０の状態に異常が認められた場合に、該当するアクチュエータ２００に対してフェールセーフを実施する。
【００１９】
なお、アクチュエータ２００にはハイブリッド車が走行する、あるいは、電源として機能するためのあらゆる機構を含んでもよいが、例えば、車両制御に係る電動機、エンジンや制動ブレーキ、ランプ点灯制御に係るランプ、ボデー系照合制御に係るドアロック機構、プラグイン制御に係るバッテリや、補機充電制御に係るモータなどが含まれる。図１では、それぞれ別の機能を有する５つのアクチュエータＡ１〜Ａ５がメインマイコン１０により制御されている様子が図示されている。
【００２０】
図１に示すように、メインマイコン１０は、メインＣＰＵ１１とメインメモリ１２とを有している。
【００２１】
メインＣＰＵ１１は、アクチュエータ２００を駆動する駆動信号を出力している。具体的には、メインＣＰＵ１１は、メインメモリ１２に格納された制御用アプリケーションプログラム（以下、単に制御アプリケーションと云う）を読み込み、所定の演算を実行してアクチュエータ２００を駆動させるための駆動信号を出力している。
【００２２】
メインメモリ１２は、一般的に知られたＲＯＭあるいはＲＡＭであり、上記制御アプリケーションが格納されている。本実施形態におけるメインメモリ１２は、図２に示すように、制御アプリケーションＢ１〜Ｂ５が格納されている。制御アプリケーションＢ１〜Ｂ５はそれぞれアクチュエータＡ１〜Ａ５の駆動を制御するためのアプリケーションである。制御アプリケーションＢ１〜Ｂ５は、所定のレジスタにそれぞれ独立に格納され、メインＣＰＵ１１により個別に実行可能になっている。
【００２３】
また、サブマイコン２０は、サブＣＰＵ２１とサブメモリ２２とを有している。
【００２４】
サブＣＰＵ２１は、メインマイコン１０を監視することでアクチュエータ２００が正しく駆動しているか否かを監視している。例えば、サブＣＰＵ２１は、メインＣＰＵ１１が実行した制御アプリケーションＢ１〜Ｂ５のうち、監視すべきアクチュエータ２００に対応する制御アプリケーションの入出力を監視している。サブＣＰＵ２１は、入力に対して想定外の出力がされた場合に、対応するメインマイコン１０の機能が異常であると判断する。
【００２５】
サブＣＰＵ２１は、サブメモリ２２に格納された監視用アプリケーションプログラム（以下、単に監視アプリケーションと云う）を読み込み、所定の演算を実行して上記監視を行う。
【００２６】
サブメモリ２２は、一般的に知られたＲＯＭあるいはＲＡＭであり、上記監視アプリケーションが格納されている。本実施形態におけるサブメモリ２２は、図２に示すように、監視アプリケーションＣ１，Ｃ４，Ｃ５が格納されている。監視アプリケーションＣ１，Ｃ４，Ｃ５はそれぞれ制御Ｂ１，Ｂ４，Ｂ５の入出力を監視するためのアプリケーションであり、ひいては、アクチュエータＡ１，Ａ４，Ａ５の駆動を監視するためのアプリケーションである。監視アプリケーションＣ１，Ｃ４，Ｃ５は、所定のレジスタにそれぞれ独立に格納され、サブＣＰＵ２１により個別に実行可能になっている。
【００２７】
なお、本実施形態におけるサブメモリ２２には、制御アプリケーションＡ２，Ａ３を監視、ひいてはアクチュエータＡ２，Ａ３を監視する監視アプリケーションＣ２，Ｃ３は格納されていない。サブメモリ２２には、監視が必須である重要なアクチュエータ２００に対応した監視アプリケーションが少なくとも格納されていれば良く、すべてのアクチュエータ２００の監視は必ずしも必須ではない。
【００２８】
また、メインメモリ１２に格納された各制御アプリケーションＢ１〜Ｂ５は、どのレジスタに格納されていてもよい。サブメモリ２２に格納された各監視アプリケーションＣ１，Ｃ４，Ｃ５は、どのレジスタに格納されていてもよい。すなわち、各監視アプリケーションＣ１，Ｃ４，Ｃ５は、制御アプリケーションＢ１，Ｂ４，Ｂ５に対応した番地のレジスタに格納されている必要はない。さらに言えば、メインメモリ１２とサブメモリ２２とは同一種のメモリである必要もない。
【００２９】
ところで、メインＣＰＵ１１は、所定の起動要因が入力されると、対応した制御アプリケーションを実行してアクチュエータ２００を駆動する。図３にその一例を示す。
【００３０】
図３に示すように、アクチュエータＡ１は例えばエンジンであり、起動要因は運転者によるイグニッション操作である。この操作はＩＧ信号線を介して、起動要因としてメインＣＰＵ１１に伝達される。メインＣＰＵ１１は対応する制御アプリケーションＢ１を読み込んで実行してエンジンを起動させる。このアクチュエータＡ１は車両の走行に重要な役割を果たすため監視を必要とするものとする。監視が必要なアクチュエータＡ１に対して、アクチュエータＡ１を起動させるための起動要因はサブＣＰＵ２１にも入力されている。サブＣＰＵ２１は、起動要因の入力をトリガーにして、制御アプリケーションＢ１に対応する監視アプリケーションＣ１を読み込んで実行する。このように、イグニッション操作という起動要因の入力に基づいて、メインＣＰＵ１１は制御アプリケーションＢ１を実行してアクチュエータＡ１を起動し、サブＣＰＵ２１は監視アプリケーションＣ１を実行して制御アプリケーションＢ１の状態を監視する。
【００３１】
アクチュエータＡ２は例えばランプであり、起動要因は運転者によるアクセサリーポジション（ＡＣＣ）操作である。この操作はＡＣＣ信号線を介して、起動要因としてメインＣＰＵ１１に伝達される。メインＣＰＵ１１は対応する制御アプリケーションＢ２を読み込んで実行してランプを点灯させる。このアクチュエータＡ２は車両の走行や安全性に大きく影響しないとして監視を不要とするものとする。監視が不要なアクチュエータＡ２に対しては、起動要因はサブＣＰＵ２１に入力されない。
【００３２】
アクチュエータＡ３は例えばドアロック機構であり、起動要因はキーを保有する運転者等の接近である。この操作はＣＡＮ１通信を介して、起動要因としてメインＣＰＵ１１に伝達される。メインＣＰＵ１１は対応する制御アプリケーションＢ３を読み込んで実行してドアロックを解除させる。このアクチュエータＡ３は車両の走行や安全性に大きく影響しないとして監視を不要とするものとする。監視が不要なアクチュエータＡ３に対しては、起動要因はサブＣＰＵ２１に入力されない。なお、ＣＡＮはコントローラ・エリア・ネットワークの略称で、登録商標である。
【００３３】
アクチュエータＡ４は例えばバッテリであり、起動要因は、車両の家庭用プラグへの接続である。この操作はＣＡＮ２通信を介して、起動要因としてメインＣＰＵ１１に伝達される。メインＣＰＵ１１は対応する制御アプリケーションＢ４を読み込んで実行してバッテリへの充電を開始させる。このアクチュエータＡ４は車両の安全性に重要な役割を果たすため監視を必要とするものとする。監視が必要なアクチュエータＡ４に対して、アクチュエータＡ４を起動させるための起動要因はサブＣＰＵ２１にも入力されている。サブＣＰＵ２１は、起動要因の入力をトリガーにして、制御アプリケーションＢ４に対応する監視アプリケーションＣ４を読み込んで実行する。このように、イグニッション操作という起動要因の入力に基づいて、メインＣＰＵ１１は制御アプリケーションＢ４を実行してアクチュエータＡ４を起動し、サブＣＰＵ２１は監視アプリケーションＣ４を実行して制御アプリケーションＢ４の状態を監視する。
【００３４】
アクチュエータＡ５は例えば補機バッテリであり、起動要因は、高圧バッテリから補機バッテリへの充電指示である。この操作はＬＩＮ通信を介して、起動要因としてメインＣＰＵ１１に伝達される。メインＣＰＵ１１は対応する制御アプリケーションＢ５を読み込んで実行して補機バッテリの充電を開始させる。このアクチュエータＡ５は車両の安全性に重要な役割を果たすため監視を必要とするものとする。監視が必要なアクチュエータＡ５に対して、アクチュエータＡ５を起動させるための起動要因はサブＣＰＵ２１にも入力されている。サブＣＰＵ２１は、起動要因の入力をトリガーにして、制御アプリケーションＢ５に対応する監視アプリケーションＣ５を読み込んで実行する。このように、イグニッション操作という起動要因の入力に基づいて、メインＣＰＵ１１は制御アプリケーションＢ５を実行してアクチュエータＡ５を起動し、サブＣＰＵ２１は監視アプリケーションＣ５を実行して制御アプリケーションＢ５の状態を監視する。
【００３５】
なお、起動要因の伝達手段は有線、無線ともに上記例に限定されるものではなく、他の通信プロトコルによる通信方式にも適用可能である。
【００３６】
次に、図４を参照して、制御装置１００、とくにサブＣＰＵ２１の動作フローについて説明する。
【００３７】
図４に示すように、まずはステップＳ１が実行される。ステップＳ１はサブＣＰＵ２１が起動要因を取得するステップである。本実施形態では、図１に示すように、サブＣＰＵ２１にはアクチュエータＡ１，Ａ４，Ａ５に関する起動要因が入力可能に接続されている。具体的には、図３に示すように、サブＣＰＵ２１にはＩＧ信号線が接続され、さらにＣＡＮ２通信、ＬＩＮ通信が可能になっている。
【００３８】
次いで、ステップＳ２が実行される。ステップＳ２は、サブＣＰＵ２１が、起動要因がＩＧ信号線を介するものか否かを判定するステップである。起動要因がＩＧ信号線を介するものであればＹＥＳ判定となり、ステップＳ３に進む。ステップＳ３は、サブＣＰＵ２１が監視アプリケーションＣ１をサブメモリ２２から読み出して実行するステップである。ステップＳ３により監視アプリケーションＣ１が実行されるとメインＣＰＵ２１が制御するアクチュエータＡ１の駆動がサブマイコン２０により監視される状態になる。ステップＳ３終了後は動作フローを終了し、ステップＳ１からのフローを繰り返す。
【００３９】
一方、ステップＳ２において起動要因がＩＧ信号線を介するものでなければＮＯ判定となる。この場合はステップＳ４に進む。
【００４０】
ステップＳ４は、サブＣＰＵ２１が、起動要因がＣＡＮ２通信を介するものか否かを判定するステップである。起動要因がＣＡＮ２通信を介するものであればＹＥＳ判定となり、ステップＳ５に進む。ステップＳ５は、サブＣＰＵ２１が監視アプリケーションＣ４をサブメモリ２２から読み出して実行するステップである。ステップＳ５により監視アプリケーションＣ４が実行されるとメインＣＰＵ２１が制御するアクチュエータＡ４の駆動がサブマイコン２０により監視される状態になる。ステップＳ５終了後は動作フローを終了し、ステップＳ１からのフローを繰り返す。
【００４１】
一方、ステップＳ４において起動要因がＣＡＮ２通信を介するものでなければＮＯ判定となる。この場合はステップＳ６に進む。
【００４２】
ステップＳ６は、サブＣＰＵ２１が、起動要因がＬＩＮ通信を介するものか否かを判定するステップである。起動要因がＬＩＮ通信を介するものであればＹＥＳ判定となり、ステップＳ７に進む。ステップＳ７は、サブＣＰＵ２１が監視アプリケーションＣ５をサブメモリ２２から読み出して実行するステップである。ステップＳ７により監視アプリケーションＣ５が実行されるとメインＣＰＵ２１が制御するアクチュエータＡ５の駆動がサブマイコン２０により監視される状態になる。ステップＳ７終了後は動作フローを終了し、ステップＳ１からのフローを繰り返す。
【００４３】
一方、ステップＳ６において起動要因がＬＩＮ通信を介するものでなければＮＯ判定となる。この場合は、監視の必要なアクチュエータ２００が起動されない状態に相当するので、サブマイコン２０は監視に関わる演算を実行せず動作フローは終了し、ステップＳ１からのフローを繰り返す。
【００４４】
次に、本実施形態における制御装置１００を採用することによる作用効果について説明する。
【００４５】
この制御装置１００では、図２に示すように、監視アプリケーションＣ１，Ｃ４，Ｃ５が所定のレジスタにそれぞれ独立に格納され、サブＣＰＵ２１により個別に実行可能になっている。そして、図４に示すように、入力される起動要因に基づいて、必要とされる監視アプリケーションのみを実行して監視を行う。このため、従来のように、すべての制御アプリケーションの状態を監視する態様に較べて、サブＣＰＵ２１の演算負荷を軽減することができる。
【００４６】
さらに、本実施形態では、制御アプリケーションに対応する監視アプリケーションすべてをサブメモリ２２に格納するのではなく、監視が要求されるアクチュエータ２００に対応する監視アプリケーションＣ１，Ｃ４，Ｃ５だけがサブメモリ２２に格納されている。また、サブＣＰＵ２１に入力される起動要因も、監視が要求されるものに限定されている。具体的には、起動要因の伝達手段として、ＩＧ信号線による通信とＣＡＮ２通信とＬＩＮ通信に限定されている。このため、サブメモリ２２の容量の節約となるとともに、サブＣＰＵ２１の演算負荷を軽減することができる。
【００４７】
また、メインＣＰＵ１１、サブＣＰＵ２１ともに、演算の実行前に、実行予定のアプリケーションが破壊されていないか否かをチェックする場合があるが、本実施形態のように、実行する制御アプリケーションあるいは監視アプリケーションが限定されていることにより、当該チェックの負荷を軽減することができる。
【００４８】
（変形例１）
第１実施形態では、監視アプリケーションが、対応した制御アプリケーションのみを監視する例について説明した。例えば、図５の実線矢印に示すように、制御アプリケーションとして制御アプリケーションＢ４が実行中である場合には、制御アプリケーションＢ４に対応した監視アプリケーションＣ４がサブＣＰＵ２１により実行されて制御アプリケーションＢ４のみが監視される。
【００４９】
これに対して、本変形例におけるサブＣＰＵ２１は、図５の破線矢印に示すように、実行されていない制御アプリケーションＢ１，Ｂ５であっても、その制御アプリケーションが監視の要求されるアプリケーションであった場合には、該当する制御アプリケーションＢ１，Ｂ５が真に停止しているか否かを監視する。
【００５０】
制御アプリケーションが真に停止しているか否かの判定には、例えば、メインＣＰＵ１１の出力が利用できる。具体的には、制御アプリケーションＢ１あるいはＢ５が実行されない状態でメインＣＰＵ１１から出力されるべきノーマリー出力以外の出力が検出された場合には、サブＣＰＵ２１は、実行されていないはずの制御アプリケーションＢ１，Ｂ５に異常があると判定する。なお、制御アプリケーションが真に停止しているか否かの判定に係るアプリケーションプログラムは非常に簡素なものになることが想定され、サブＣＰＵ２１に対して高負荷になることはない。
【００５１】
なお、制御アプリケーションＢ１が実行中である場合には、監視アプリケーションＣ１が制御アプリケーションＢ１の監視を行うとともに、制御アプリケーションＢ４，Ｂ５の停止を監視する。制御アプリケーションＢ５が実行中である場合には、監視アプリケーションＣ５が制御アプリケーションＢ５の監視を行うとともに、制御アプリケーションＢ１，Ｂ４の停止を監視する。
【００５２】
本変形例にかかる制御装置１００を採用すれば、実行中の制御アプリケーションの監視のほか、監視が要求される停止中の制御アプリケーションについても、サブＣＰＵ２１に過度な負荷を要求することなく、簡易的な監視を行うことができる。
【００５３】
（変形例２）
変形例１における態様において、制御アプリケーションに異常が発見された場合に、サブマイコン２０がメインマイコン１０およびアクチュエータ２００に対してフェールセーフを実施するようにしてもよい。
【００５４】
フェールセーフの内容は、異常を発見した監視アプリケーションと、異常と判定された制御アプリケーションとの組み合わせによってそれぞれ異なる。本変形例における具体的なフェールセーフの内容は、図６に示すようになっている。すなわち、車両制御に関わる制御アプリケーションＢ１に異常が発見された場合、発見者となる監視アプリケーションがＣ１である場合には、サブマイコン２０は車両を停止させるようにフェールセーフを実施する。一方、発見者となる監視アプリケーションがＣ４あるいはＣ５の場合には、サブマイコン２０はメインマイコン１０をリセットするようにフェールセーフを実施する。
【００５５】
つまり、実行中である制御アプリケーションＢ１を主に監視するのは監視アプリケーションＣ１であり、監視アプリケーションＣ１が実行中の制御アプリケーションＢ１に異常を認めるときはアクチュエータＡ１に異常が発生している可能性が高い。よって、サブマイコン２０はアクチュエータＡ１を安全側に制御する。一方、停止中である制御アプリケーションＢ１を監視するのは監視アプリケーションＣ４あるいはＣ５であり、監視アプリケーションＣ４，Ｃ５が制御アプリケーションＢ１に異常を認めるときはメインマイコン１０自体に異常が発生している可能性が高い。よって、サブマイコン２０はメインマイコン１０をリセットしてアクチュエータ２００を全体的に安全側に制御する。
【００５６】
制御アプリケーションＢ１に異常が発見された場合と同様に、制御アプリケーションＢ４あるいはＢ５についても同様である。プラグイン制御に関わる制御アプリケーションＢ４に異常が発見された場合、発見者となる監視アプリケーションがＣ４である場合には、サブマイコン２０はプラグイン充電を禁止するようにフェールセーフを実施する。一方、発見者となる監視アプリケーションがＣ１あるいはＣ５の場合には、サブマイコン２０はメインマイコン１０をリセットするようにフェールセーフを実施する。
【００５７】
また、補機充電制御に関わる制御アプリケーションＢ５に異常が発見された場合、発見者となる監視アプリケーションがＣ５である場合には、サブマイコン２０は補機の充電を禁止するようにフェールセーフを実施する。一方、発見者となる監視アプリケーションがＣ１あるいはＣ４の場合には、サブマイコン２０はメインマイコン１０をリセットするようにフェールセーフを実施する。
【００５８】
このように、本変形例におけるサブマイコン２０は、異常が検出された制御アプリケーションに対応する被制御対象に対してフェールセーフを実施するものであり、メインＣＰＵ１１により実行されている制御アプリケーションに異常が検出された場合と、実行されていない制御アプリケーションに異常が検出された場合とで、フェールセーフの内容を分けるようになっている。
【００５９】
これによれば、実行中の制御アプリケーション、ひいては制御中のアクチュエータ２００に異常が発見された場合には、制御中のアクチュエータ２００に関連する内容に限定してフェールセーフを実施するので、過度に運転者のドライバビリティを悪化させることなく、必要なフェールセーフを実施することができる。
【００６０】
一方、停止中の制御アプリケーションに異常が発見された場合には、メインマイコン１０自体に故障を懸念してメインマイコン２０をリセットするようにフェールセーフを実施するので、車両を確実に安全側へ制御することができる。
【００６１】
（その他の実施形態）
以上、本発明の好ましい実施形態について説明したが、本発明は上記した実施形態になんら制限されることなく、本発明の主旨を逸脱しない範囲において、種々変形して実施することが可能である。
【００６２】
上記した実施形態および変形例では、制御装置１００がハイブリッド車を制御するハイブリッドＥＣＵである例について記載した。これに伴って、アクチュエータ２００も、ハイブリッド車に関するものを例示した。しかしながら、制御装置１００の適用範囲は、任意のアクチュエータを制御するマイコンすべてに適用が可能である。特に、車両を制御するＥＣＵであれば好適である。そして、アクチュエータ２００の例示もあくまで一例であって、上記例に限定されるものではない。
【００６３】
また、変形例１および変形例２では、実行されない制御アプリケーションの監視について、メインＣＰＵ１１から出力されるべきノーマリー出力以外の出力が検出された場合に異常であると判定する例を記載したが、停止中の制御アプリケーションの監視は、メインＣＰＵ１１の入出力の監視に限定されない。例えば、制御アプリケーションが実行される際にカウントアップされるカウンタの挙動を監視してもよい。通常、制御アプリケーションの実行中は、プロセス管理のためのカウンタがカウントアップする。サブＣＰＵ２１は、停止中の制御アプリケーションのカウントが意図せずカウントアップしている場合に、当該制御アプリケーションが異常であると判定しても良い。
【００６４】
また、上記した実施形態では、サブメモリ２２に、監視を必要とする制御アプリケーションに対応する監視アプリケーションのみが格納され、サブＣＰＵ２１には対応した起動要因のみが入力される例を示した。しかしながら、この例に限定されることはなく、各制御アプリケーションに対応したすべての監視アプリケーションがサブメモリ２２に格納されていてもよいし、すべての起動要因が入力されるようになっていても良い。入力される起動要因に対して、実行中の制御アプリケーションに対応する監視アプリケーションが実行されるようになっていれば良い。
【符号の説明】
【００６５】
１０…メインマイコン，１１…メインＣＰＵ，１２…メインメモリ，２０…サブマイコン，２１…サブＣＰＵ，２２…サブメモリ，１００…制御装置，２００…アクチュエータ（被制御対象）
【図１】
2017091169.tif 000003
【図２】
2017091169.tif 000004
【図３】
2017091169.tif 000005
【図４】
2017091169.tif 000006
【図５】
2017091169.tif 000007
【図６】
2017091169.tif 000008