JP2013001141A - 情報処理装置、ソフト起動方法 - Google Patents

Abstract

【課題】１つのＥＣＵに複数の制御アプリから共用される回路が搭載された際、制御アプリの起動条件に関係なく回路を保護可能な情報処理装置を提供すること。
【解決手段】ＩＧオンにより起動する第１のアプリケーションと、＋Ｂ電源により起動する第２のアプリケーションと、＋Ｂ電源により作動して、前記第１アプリケーションが利用する第１の周辺機器及び前記第２アプリケーションが利用する第２の周辺機器５００との共通のインタフェース４００と、を有する情報処理装置であって、＋Ｂ電源により作動する前記第１又は第２の周辺機器が、当該情報処理装置に出力する入力データを監視して前記周辺機器の故障を検出する、＋Ｂ電源により起動する監視ソフト２００、を有することを特徴とする。
【選択図】図３

Description

本発明は、複数のアプリケーションが起動可能な情報処理装置に関し、特に、アプリケーションが使用する周辺機器の故障を検出可能な情報処理装置に関する。

車載されている各種の装置は、電子制御ユニット（ＥＣＵ：electronic control unit）により制御されている。ＥＣＵは、エンジンを制御するもの、ブレーキを制御するもの、ボディ系の機器を制御するもの、ＡＶ系統の機器を制御するもの等、数多く存在する。ところが、ＥＣＵの数が増大したため開発コストや搭載するために必要な車載スペースが増大することを無視できなくなってきた。このため、いくつかのＥＣＵの機能を１つのＥＣＵに機能統合する試みが知られている。

ところで、ＥＣＵが作動するためには電源が必要だが、各ＥＣＵが作動を開始する条件は必ずしも同じではない。例えば、走行に必要なエンジンＥＣＵはＩＧオンで作動を開始し（以下、このようなＥＣＵを「ＩＧ電源で作動する」という）、電子キーシステムのＥＣＵはＩＧオンの前でもバッテリが装着されていれば作動する（以下、このようなＥＣＵを「＋Ｂ電源で作動する」という）。ＩＧ電源のＥＣＵと＋Ｂ電源のＥＣＵを統合した場合、ＩＧ電源のＥＣＵの機能（アプリケーション）を常に起動させる必要はないので、複数のＥＣＵから統合された複数のアプリケーションを、電源の状態に応じて起動させることが考えられる（例えば、特許文献１参照。）。

特許文献１には、電源状態及び起動要件に基づいて各アプリケーションの動作要件の判定を行い、動作要件を満足したアプリケーションのみを起動するＥＣＵが開示されている。

特開２００６−３２７２１７号公報

しかしながら、特許文献１では、アプリケーションが使用する回路について考慮されていないという問題がある。

図１は、アプリケーションと回路の関係を説明する図の一例である。ＥＣＵ１は制御アプリＡにてセンサ・アクチュエータαを使用し、制御アプリＢにてセンサ・アクチュエータβを使用する。ＥＣＵ１はＩＧ電源のＥＣＵであり、ＥＣＵ１はＩＧオンにより作動を開始する。また、センサ・アクチュエータαはＩＧオン電源のセンサ・アクチュエータであり、センサ・アクチュエータβは＋Ｂ電源のセンサ・アクチュエータである。

ここで、ハード的な対象であるセンサ・アクチュエータを制御する場合、ＥＣＵは特定の回路を必要とすることが多い。回路ＡはＥＣＵ１に存在するので回路ＡもＩＧオンにより作動を開始する。これに対し、ＥＣＵ２は＋Ｂ電源のＥＣＵであり、ＥＣＵ２及び回路Ｃはバッテリにより常時作動している。センサ・アクチュエータγは＋Ｂ電源のセンサ・アクチュエータである。

また、各制御アプリは故障検出ソフトとセットで実行される。故障検出ソフトは、センサからの入力値がセンサの仕様範囲内に入るかを監視したり、アクチュエータの異常有無を監視して、回路を保護するソフトである。したがって、故障検出ソフトが起動していないと回路を保護することができない。

なお、ＥＣＵ１では、回路ＡがＩＧ電源であるのに対し、センサ・アクチュエータβは＋Ｂ電源である。しかし、＋Ｂ電源でセンサ・アクチュエータβが作動しても回路ＡがＩＧオンまで作動しない。このため、故障検出ソフトが起動していない状態でセンサ・アクチュエータβが故障しても、回路Ａが損傷することはない。

次に、ＥＣＵ１とＥＣＵ２を１つのＥＣＵに機能統合したとする。図示するように、回路Ａと回路Ｃが共に１つのＥＣＵに搭載される。統合後もセンサ・アクチュエータが作動する場合は、「制御アプリ＋故障検出ソフト」と回路の作動条件は一致していなければならない。これにより、統合後も故障検出ソフトが回路を保護することができる。

ところで、図１のように機能を統合するのであれば、回路Ａ,Ｃも統合した方がチップ数が少なくなりコスト低減しやすい。そこで、図２に示すように回路Ａ,Ｃを回路Ｚに統合することが期待される。回路Ｚの作動条件をＩＧオンとすると、制御アプリＢが＋Ｂ電源で起動してしても回路Ｚを使用できないので、必然的に回路Ｚの作動条件は＋Ｂ電源となる。

しかし、回路Ｚの作動条件を＋Ｂとしてしまうと、「制御アプリＢ＋故障検出ソフト」が作動していない状態で、センサ・アクチュエータβ及び回路Ｚが作動することになる。このため、センサ・アクチュエータβが故障した際に、制御アプリＢと一体の故障検出ソフトが回路Ｚを保護できないという問題が生じる。特に、機能統合しているので、回路Ｚの故障により制御アプリＡ、Ｃもセンサ・アクチュエータαやγを使用できなくなる可能性が生じてしまう。

本発明は上記課題に鑑み、１つのＥＣＵに複数の制御アプリから共用される回路が搭載された際、制御アプリの起動条件に関係なく回路を保護可能な情報処理装置を提供することを目的とする。

上記課題に鑑み、本発明は、ＩＧオンにより起動する第１のアプリケーションと、＋Ｂ電源により起動する第２のアプリケーションと、＋Ｂ電源により作動して、前記第１アプリケーションが利用する第１の周辺機器及び前記第２アプリケーションが利用する第２の周辺機器との共通のインタフェースと、を有する情報処理装置であって、＋Ｂ電源により作動する前記第１又は第２の周辺機器が、当該情報処理装置に出力する入力データを監視して前記周辺機器の故障を検出する、＋Ｂ電源により起動する監視ソフト、を有する。

１つのＥＣＵに複数の制御アプリから共用される回路が搭載された際、制御アプリの起動条件に関係なく回路を保護可能な情報処理装置を提供することを目的とする。

アプリケーションと回路の関係を説明する図の一例である。 回路Ａ,Ｃの統合例を説明する図の一例である。 統合ＥＣＵの概略を説明する図の一例である。 統合ＥＣＵが搭載された車載ネットワークの概略構成図の一例である。 統合ＥＣＵの概略構成図の一例である。 統合ＥＣＵの機能ブロック図の一例である。 統合ＥＣＵが動作する手順を示すシーケンス図の一例である。 故障検出ソフトの動作手順を示すフローチャート図の一例である。 統合ＥＣＵが動作する手順を示すシーケンス図の一例である。 統合ＥＣＵの機能ブロック図の一例である。 統合ＥＣＵの概略の構成例を説明する図の一例である。

以下、本発明を実施するための形態について図面を参照しながら説明する。
図３（ａ）は、本実施形態の統合ＥＣＵ（electronic control unit）１００の概略を説明する図の一例である。各制御アプリ３００（以下、区別する場合、制御アプリＡ〜Ｃという）はセンサ・アクチュエータ５００（以下、区別する場合、センサ・アクチュエータα、β、γという）を利用して制御を行う。各制御アプリ３００の起動条件は以下のようになっている。まず、制御アプリＡとセンサ・アクチュエータαはＩＧオンにより作動を開始し、制御アプリＣとセンサ・アクチュエータγは＋Ｂ電源により作動を開始する。

これに対し、制御アプリＢはＩＧオンにより起動し、センサ・アクチュエータβは＋Ｂ電源により起動する。このため、制御アプリＢが起動していない状態で、回路４００及びセンサ・アクチュエータβが作動する状況が生じうる。

そこで、本実施形態の統合ＥＣＵ１００は、回路４００の作動時に、制御アプリＡ〜Ｃに共通の故障検出ソフト２００を起動させることを特徴の１つとする。すなわち、故障検出ソフト２００は、回路４００の作動中、常に作動している。こうすることで、センサ・アクチュエータβが仮に故障し、制御アプリＢが起動していなくても故障検出ソフト２００が起動しているので、回路４００をセンサ・アクチュエータβから保護することができる。

なお、図３（ａ）は図２を踏襲した図であり、必ずしも制御アプリＡとセンサ・アクチュエータαは必要ない点に注意されたい。図３（ｂ）は統合ＥＣＵ１００における制御アプリの別の態様を説明する図の一例である。制御アプリＢ，Ｃ、回路４００、及び、センサ・アクチュエータ５００の動作条件は図３（ａ）と同様である。図３（ｂ）では制御アプリＢが起動していない状態で、センサ・アクチュエータβとγ、回路４００及び故障検出ソフト２００が＋Ｂ電源で作動する。したがって、制御アプリＡとセンサ・アクチュエータαの有無に関係なく、故障検出ソフト２００が、センサ・アクチュエータβの故障から回路４００を保護できるという点は変わりがない。

また、制御アプリＢはセンサ・アクチュエータβを使用して制御を行うが、制御アプリＢが起動していなくても、センサ・アクチュエータβが作動している必要があるのは、例えば次のような場合である。
・センサ・アクチュエータβの起動が遅く、制御アプリＢが起動してからセンサ・アクチュエータβを起動したのでは制御アプリＢの起動が遅れてしまう場合
・制御アプリＣがセンサ・アクチュエータβを使用する場合（制御アプリＢとＣがセンサ・アクチュエータβを共有する場合）
〔構成例〕
図４は、統合ＥＣＵ１００が搭載された車載ネットワークの概略構成図の一例を示す。この車載ネットワークには、ＣＡＮ（Controller Area Network）などの車載ＬＡＮを介して接続された電源ＥＣＵ１１、統合ＥＣＵ１００、及び、スマートＥＣＵ１２等が接続されている。電源ＥＣＵ１１にはエンジンスイッチ１６、ブレーキＳＷ１７、シフトポジションセンサ１８、ＡＣＣリレー、ＩＧ１リレー及びＩＧ２リレーが、スマートＥＣＵ１２には室内アンテナ１９が、それぞれ接続されている。なお、この図は、統合ＥＣＵ１００への電源供給を図示するための図であり、これらのＥＣＵ以外のＥＣＵがさらに接続されていることが一般的である。

エンジンスイッチ１６は、押しボタン式のモーメンタリスイッチであり、内部から初期位置方向に弾性体による付勢力が与えられている。すなわち、乗員（以下、単に運転者という）がエンジンスイッチ１６を押し下げるとエンジンスイッチ１６はオン状態になり、運転者が指を離すと内蔵された弾性体の付勢力により初期位置に戻りオフとなる。

また、ブレーキＳＷ１７は、ブレーキペダルが初期位置よりも踏み込まれるとオンになり、運転者が踏力を減少させ初期位置まで戻されるとオフになるスイッチである。したがって、運転者がブレーキペダルを踏み込んでいる間だけ、ブレーキＳＷ１７から電源ＥＣＵ１１にオン信号が出力される。シフトポジションセンサ１８は、シフトレバーの位置（Ｐ、Ｎ、Ｄ、１，２、Ｒ等）を検出するセンサである。

ＡＣＣリレーは、アクセサリー機器と呼ばれる機器（オーディオ類、ナビ、室内灯等）とバッテリ５０との給電線をオン又はオフするリレーである。ＩＧ２リレー１７は、エンジン始動に関係のない機器（メーター系、ワイパー、エアコンなど）とバッテリ５０との給電線をオン又はオフするリレーである。ＩＧ１リレー１６は、エンジン始動に必要な機器（イグニッションコイル、インジェクタなど）とバッテリ５０との給電線をオン又はオフするリレーである。

スマートＥＣＵ１２は、室内アンテナ１９から定期的にリクエスト電波を発信し、電子キー２０が応答して送信したレスポンスキー電波に含まれるＩＤが予め登録されたＩＤと一致するか否かにより、電子キー２０の認証が成立するか否かを判定する。認証が成立すると電源ＥＣＵ１１に通知するので、不図示のエンジンＥＣＵはエンジン始動が許可される。

電源ＥＣＵ１１、統合ＥＣＵ１００及びスマートＥＣＵ１２はバッテリ５０と接続されている。図示した３つのＥＣＵはいずれも＋Ｂ電源である。このため、エンジンスイッチ１６のオン・オフに関係なく、バッテリ５０が装着されていれば、電源ＥＣＵ１１、統合ＥＣＵ１００及びスマートＥＣＵ１２に電源が供給される。

また、シフトポジションをＰ（又はＮでもよい）にセットした状態で、運転者がブレーキペダルを踏み込み、エンジンスイッチ１６を１回押下することで、電源ＥＣＵ１１は、ＩＧ１リレーと不図示のＳＴリレーをオンにしてスタータモータを作動させる。これによりエンジンが始動するとエンジンＥＣＵが電源ＥＣＵ１１に完爆信号を出力するので、電源ＥＣＵ１１はＡＣＣリレー、ＩＧ１リレー及びＩＧ２リレーをオンに維持する。

また、電気モータを動力の一部とする車両（ＨＶ車）、又は、電気モータを動力とする車両（ＥＶ車）の場合、電源ＥＣＵ１１は上記の運転者の操作を検出して、ＡＣＣリレー、ＩＧ１リレー及びＩＧ２リレーをオンにすると共に、ＨＶ-ＥＣＵに起動信号を出力する。ＨＶ-ＥＣＵは、プログラムを読み出して初期処理や自己診断を実行し、起動可能な状態であると、Ready‐ON信号を電源ＥＣＵ１１に出力する。電源ＥＣＵ１１は、Ready‐ON信号を受信してReady‐ONモードになる。Ready‐ONモードになることは、ＩＧオンと同様にＡＣＣリレー、ＩＧ１リレー及びＩＧ２リレーがオンであることを意味する。統合ＥＣＵ１００は少なくともＩＧ１リレー及びＩＧ２リレーの少なくともいずれかのオンを検出することができる。以下、ＩＧオンとReady‐ONを区別せずにＩＧオンとして説明する。

図５は、統合ＥＣＵ１００の概略構成図の一例を示す。統合ＥＣＵ１００はマイコン６０とその他の回路とを有し、その他の回路は、例えば、ＡＤＣ４１，ＤＡＣ４２、ＣＡＮコントローラ４４、モータドライバ４３、及び、電源回路４５である。

マイコン６０は、メインバス３９に接続されたＣＰＵ３１、ＲＡＭ３２、ＲＯＭ３３、ＩＮＴＣ３４、ＤＭＡＣ３５、及び、バスコントローラ３６を有する。また、マイコン６０は、周辺バス４０に接続されたＴｉｍｅｒ（以下、区別する場合Timer1、Timer0という）３７、複数のＩ／Ｏ３８を有する。これらのＩ／Ｏ３８に上記の回路が接続されている。

ＣＰＵ３１は、シングルコア又はマルチコアのＣＰＵである。または、ハードウェアマルチスレッド（ＨＭＴ）型のＣＰＵでもよい。ＣＰＵ３１はＲＡＭ３２を作業メモリにしてプログラムを実行する。ＲＯＭ３３はフラッシュメモリなどの不揮発メモリであり、ＣＰＵ３１が実行するプログラムや静的なデータを記憶している。本実施形態ではプログラムに制御アプリＡ〜Ｃ、及び、故障検出ソフト２００が含まれている。また、デバイスドライバやＯＳなどのプラットフォームも記憶されている。

ＤＭＡＣ３５は、ＣＰＵ３１からの指示によりＲＡＭ３２やＲＯＭ３３のデータをＴｉｍｅｒ３７やＩ／Ｏ３８に送信する。また、Ｔｉｍｅｒ３７やＩ／Ｏ３８がＩＮＴＣ３４を介してＣＰＵ３１に割り込みした際にＣＰＵ３１から指示を受けて、Ｔｉｍｅｒ３７やＩ／Ｏ３８からデータを受け取り、ＲＡＭ３２に書き込む。

ＩＮＴＣ３４はＩＲＱやその他の割り込み端子を介してＴｉｍｅｒ３７やＩ／Ｏ３８から入力された割り込み要求を、周辺機器の優先順位に基づき調停してＣＰＵ３１に通知する。これによりＣＰＵ３１は割り込みした周辺機器に応じて決まった処理を実行する。

バスコントローラ３６は、メインバス３９と周辺バス４０との間のバス本数や周波数の違いを吸収して相互にデータを受け渡す。

周辺バス４０には、実行速度の比較的おそい周辺回路が接続されており、Ｔｉｍｅｒ３７は、例えばＣＰＵ３１が設定した値をカウントし終わるとＩＮＴＣ３４を介してＣＰＵ３１に割り込みすることでＣＰＵ３１に通知する。通知によりＣＰＵ３１は例えば定期的に所定のプログラムを実行することができる。

そして、ＡＤＣ４１、ＤＡＣ４２、ＣＡＮコントローラ４４、及び、モータドライバ４３は、それぞれが上述した回路４００となりうる回路である。すなわち、ＡＤＣ４１には制御アプリＡが使用するセンサＡ、制御アプリＢが使用するセンサＢ、制御アプリＣが使用するセンサＣ、が接続されている。ＤＡＣ４２には制御アプリＡが使用するアクチュエータＡ、制御アプリＢが使用するアクチュエータＢ、制御アプリＣが使用するアクチュエータＣ、が接続されている。モータドライバ４３には制御アプリＡが使用するモータＡ、制御アプリＢが使用するモータＢ、制御アプリＣが使用するモータＣ、が接続されている。なお、ＣＡＮコントローラ４４にはＣＡＮバスが接続されるが、ＣＡＮバスは制御アプリＡ〜Ｃに共通である。

ＡＤＣ４１は、センサＡ〜Ｃが検出したアナログ信号をデジタル信号に変換してＩ／Ｏ３８に出力する。ＤＡＣ４２は、制御アプリＡ〜ＣがＩ／Ｏ３８を介して出力したデジタル信号をアナログ信号に変換してアクチュエータＡ〜Ｃに出力する。モータドライバ４３は、制御アプリＡ〜ＣがＩ／Ｏ３８を介して出力したデジタル信号をモータ制御信号に変換してモータＡ〜Ｃに出力する。複数のセンサ、アクチュエータ又はモータが接続されている回路４００は、例えばマルチプレクサにより選択的に信号を入出力できるようになっている。または、センサ、アクチュエータ又はモータ毎にチャネルを有していてよい。

ＣＡＮコントローラはＣＡＮＩＤに基づく優先順位で時分割にＣＡＮフレームを送受信する通信装置である。＋Ｂ電源の統合ＥＣＵでは、ＩＧオフの間も通信のためＣＡＮコントローラに常に電源が供給される。

電源回路４５は、ＩＧオフの状態でもバッテリ５０から電源供給を受けてマイコン駆動用の電圧・電流を生成する。例えば、バッテリ電圧が１２Ｖなら例えば３．３〜５Ｖの電圧を生成する。電源回路４５にはＩＧオンを検出して、ＩＧオン又はＩＧオフに応じて電源を供給する回路を制御する。例えば、＋Ｂ電源の回路に対しては、ＩＧオンを検出するか否かに関係なく電源を供給する。ＩＧオン電源の回路に対しては、ＩＧオンを検出した場合にのみ電源を供給する。本実施形態では、一例としてＡＤＣ４１がＩＧオン電源であるとして説明する。

なお、電源回路４５は、ＩＧオン時は、ＥＣＵ内の全ての回路を通常モードで動作させるために必要な大容量の電圧・電流を生成し、ＩＧオフ時は、＋Ｂ電源の回路４００やマイコン６０を省電力モードに保持するために必要な最小限の電圧・電流を生成する。

センサＡ〜Ｃ、アクチュエータＡ〜Ｃ及びモータＡ〜Ｃには、バッテリ５０から常時、又は、ＩＧ１リレーとＩＧ２リレーがオンになるとバッテリ５０から電源が供給される。例えば、センサＡにはＩＧオンにより電源が供給され、センサＢ，Ｃにはバッテリ５０から常時、電源が供給されている。ＣＡＮバスにはバッテリ５０から常時、電源が供給される。

〔統合ＥＣＵの機能〕
図６は、統合ＥＣＵ１００の機能ブロック図の一例を示す。制御アプリＡは制御手段Ａを有し、制御アプリＢは制御手段Ｂを有し、制御アプリＣは制御手段Ｃを有する。また、統合ＥＣＵ１００は、制御アプリＡ〜Ｃに共通の故障検出ソフト２００を有する。制御アプリＡ〜Ｃ、及び、故障検出ソフト２００は独立したソフトウェアなので、リソースを使用するソフトウェアを管理する仕組みが存在することが好ましい。例えば、タスクスケジューラやディスパッチャなどと呼ばれる機能である。本実施形態では、この機能がプラットフォーム５１により提供されるものとする。

各制御手段Ａ〜Ｃ、及び、故障検出ソフト２００は、予め決められたイベントが検出されたり、タイマの定期的な割り込み毎に、それぞれがいくつかのタスクとして起動する。例えば、制御手段Ａ,ＢはＩＧオンにより生成される。監視部５３は、ＡＤＣ４１の割り込みより生成されるが、バッテリ５０の装着により生成されてもよい。制御手段Ｃはバッテリ５０の装着により生成されるが、ＡＤＣ４１の割り込みより生成されてもよい。

各タスクは、自身の状態（入出力などによるデータを待っている実行待機状態、ＣＰＵ３１への割り当てを待っている実行可能状態、実行中の状態）や優先度を、プラットフォーム５１を介してＴＣＢ（タスクコントロールブロック）に登録する。プラットフォーム５１は、各タスクの優先度に応じて、実行可能状態のタスクからＣＰＵ３１に割り当てるタスクを決定する。

例えば、監視部５３は、ＡＤＣ４１がＩ／Ｏ３８経由でＣＰＵ３１に割り込みし、プラットフォーム５１が監視部５３の状態を高優先度の実行可能状態にすることで、ＣＰＵ３１により実行される。監視部５３は、ＡＤＣ４１に対し後述するような処理を行う。監視部５３は、ＡＤＣ４１の入力データに異常がないと判断すると、プラットフォーム５１が提供するプロセス間通信、又は、共有メモリなどを介して、制御手段Ｃに入力データを出力する。制御手段Ａ〜Ｃのうちどの制御手段にＡＤＣ４１の入力データを出力するかは（センサＡ〜Ｃのうちどのセンサのデータか）、ＡＤＣ４１が割り込み時にＣＰＵ３１に通知している。

同様に、監視部５３は、ＡＤＣ４１の入力データに異常があると判断すると、フェールセーフ部５４のタスクを生成する。フェールセーフ部５４は、後述するようなフェールセーフ処理を行う。

制御手段Ａ〜Ｃは、本実施例の特徴部を説明するための付加的な機能なのでどのような機能を有していてもよい。しかし、制御手段Ａは、センサＡが検出しＡＤＣ４１が変換したデジタル信号を制御に使用し、制御手段Ｂは、センサＢが検出しＡＤＣ４１が変換したデジタル信号を制御に使用し、制御手段Ｃは、センサＣが検出しＡＤＣ４１が変換したデジタル信号を制御に使用する。

故障検出ソフト２００は、制御アプリＡ〜Ｃに共通のソフトであり、ＡＤＣ４１をセンサＡ〜Ｃの故障から保護する。例えば、監視部５３は、以下のような監視を行う。
・ＡＤＣ４１がデジタル信号を変換した際、センサＡ〜Ｃの仕様範囲に収まっているか否かを検査する。センサＡ〜Ｃ毎に出力する仕様上の電圧範囲が異なる場合、センサＡ〜Ｃ毎に仕様範囲に収まっているか否かを検査する。
・ＡＤＣ４１が変換したデジタル信号を経時的に監視して安定しているか否かを検査する（過去の数個の値の差の合計が所定範囲を超えて変動しないこと）。
・ＡＤＣ４１にセンサＡ〜Ｃの診断を要求し、異常があるか否かを検査する
また、フェールセーフ部５４はセンサＡ〜Ｃの異常が検出された場合、以下のようなフェールセーフ処理を行う。
・センサＡ〜Ｃをリセットする
・センサＡ〜ＣとＡＤＣ４１の接続を個別にオフにする。
・センサＡ〜ＣとＡＤＣ４１を１つずつ接続し、ＡＤ変換するなどしてセンサＡ〜Ｃの仕様範囲にデジタル信号が含まれるか否かを等を判定する診断を行う。これにより、センサＡ〜Ｃのうち故障したセンサを特定する。

なお、回路４００が異なった場合、故障検出ソフト２００が提供する機能も異なるので、マイコン６０は回路に応じて異なる故障検出ソフト２００を実行することが好ましい。すなわち、故障検出ソフトは回路の数だけ起動することができる。

〔動作手順〕
図７は、統合ＥＣＵ１００が動作する手順を示すシーケンス図の一例である。図７の手順は車両にバッテリ５０が装着されることでスタートする。

バッテリ５０が装着されると、まず＋Ｂ電源のセンサＢ、Ｃに電源が供給され作動する（Ｓ１０）。また、バッテリ５０が装着されると、電源回路４５に＋Ｂ電源が供給される（Ｓ２０）。

電源回路４５は＋Ｂ電源により作動して、予め定められている回路であるＡＤＣ４１に電源を供給する（Ｓ３０）。

ＡＤＣ４１に電源が供給されると、ＡＤＣ４１がリセットされ、ＡＤＣ４１が作動して自己診断などを行い、異常がなければＣＰＵ３１に割り込みする（Ｓ４０）。具体的には、ＡＤＣ４１が接続されたＩ／Ｏ３８がＩＮＴＣ３４に割り込み要求して、ＩＮＴＣ３４がＣＰＵ３１に割り込む。

ＣＰＵ３１はＡＤＣ４１が接続されたＩ／Ｏ３８からの割り込みにより予め決まった割り込みハンドラを実行し、この割り込みハンドラが検査検出ソフトを起動させる（Ｓ５０）。これにより、ＡＤＣ４１は故障検出ソフト２００により保護される。

また、ＣＰＵ３１はＡＤＣ４１からの割り込みにより又はバッテリ５０の装着により制御アプリＣを起動させる（Ｓ６０）。なお、ＡＤＣ４１の作動後に故障検出ソフト２００を起動させるのでなく、故障検出ソフト２００をＡＤＣ４１よりも先に起動させてもよい。このような処理は、故障検出ソフト２００の起動後にＡＤＣ４１を作動させることで実現できる。

このように、ＡＤＣ４１が起動している間は、必ず故障検出ソフト２００が起動することで、故障検出ソフト２００がＡＤＣ４１を保護することができる。

次に、運転者がＩＧオンすると、電源回路４５はＩＧオンを検出する（Ｓ７０）。また、ＩＧ電源のセンサＡに電源が供給され起動する（Ｓ８０）。

電源回路４５はＩＧオンを検出すると、ＣＰＵ３１に割り込みする（Ｓ９０）。具体的には、電源回路４５がＩＮＴＣ３４に割り込み要求して、ＩＮＴＣ３４がＣＰＵ３１に割り込む。

ＣＰＵ３１はＩＧオンにより予め決まった割り込みハンドラを実行し、この割り込みハンドラが制御アプリＡ、Ｂを起動する（Ｓ１００）。制御アプリＡ〜Ｃは、優先度やタイムスケジュールなどにより時分割に実行されるが、その間、共通に故障検出ソフト２００を利用して、ＡＤＣ４１を保護する。

図８は、故障検出ソフト２００の動作手順を示すフローチャート図の一例である。図８の手順は、ＡＤＣ４１により故障検出ソフト２００の監視部５３が生成されるとスタートする。監視部５３は、ＡＤＣ４１が入力データをＩ／Ｏ３８に出力すると実行状態となる。

まず、監視部５３はセンサＡ〜Ｃのいずれが入力データを出力したかを判別する（Ｓ２１０）。ＡＤＣ４１は入力データをＩ／Ｏ３８に出力する際にセンサＡ〜Ｃの識別信号をＣＰＵ３１に入力するので、監視部５３はこれによりセンサＡ〜Ｃを判別する。

次に、監視部５３は入力データが仕様範囲に入っているか否かを判定する（Ｓ２２０）。仕様範囲は、センサＡ〜Ｃにより決まっているので、監視部５３はセンサＡ〜Ｃ毎に仕様範囲に入っているか否かを判定する。

入力データが仕様範囲に入っている場合（Ｓ２２０のＹｅｓ）、入力データを出力したセンサがセンサＡ〜Ｃのいずれであるかに応じて、入力データを制御手段Ａ〜Ｃに送出する（Ｓ２３０）。

入力データが仕様範囲に入っていない場合（Ｓ２２０のＮｏ）、センサＡ〜Ｃが故障している可能性があるので、監視部５３はフェールセーフ部５４を起動する（Ｓ２４０）。フェールセーフ部５４は、仕様範囲に入らない入力データを出したセンサに再度のＡＤ変換を要求し、仕様範囲に入るか否かを確認する。そして、故障している可能性が高いと判定すれば、該センサとＡＤＣ４１を遮断する。こうすることで、ＡＤＣ４１を故障したセンサから保護することができる。また、故障していないセンサとＡＤＣ４１は接続されたままなので、制御アプリはそれらのセンサの検出する信号を使用することができる。

＜起動手順の変形例＞
図７の手順では、ＡＤＣ４１が作動した後に故障検出ソフトが起動を開始したが、故障検出ソフトが起動するまでの間にセンサＢが故障すると、故障検出ソフトがＡＤＣ４１を保護できないおそれがある。そこで、図９のような手順も有効である。

図９では、バッテリ５０が装着され電源回路４５に＋Ｂ電源が供給されるまでは（Ｓ２０）図７と同様である。

しかし、電源回路４５は＋Ｂ電源により起動しても、ＡＤＣ４１ではなくＣＰＵ３１に故障検出ソフトの起動開始を要求するための割り込みを行う（Ｓ３２）。

ＣＰＵ３１は電源回路４５からの割り込みにより予め決まった割り込みハンドラを実行し、検査検出ソフトを起動する（Ｓ５０）。また、故障検出ソフトは故障検出ソフトの起動が完了したことを電源回路４５に通知する（Ｓ５２）。

電源回路４５はこの通知によりＡＤＣ４１に電源を供給する（Ｓ３０）。このような手順とすることで、故障検出ソフトをＡＤＣの起動よりも必ず後にできるので、故障検出ソフトはセンサＢ、Ｃの故障からＡＤＣを確実に保護することができる。

〔アクチュエータやモータの場合〕
センサでなく、アクチュエータやモータの場合も処理手順は同様である。
図１０は、統合ＥＣＵ１００の機能ブロック図の一例を示す。図１０において図６と同一部の説明は省略する。統合ＥＣＵ１００は、制御アプリＡ〜Ｃに共通の故障検出ソフト２００を有する。回路毎に故障の検出方法は異なることが一般的なので、故障検出ソフト２００は、回路毎に用意されている。制御手段Ａ〜Ｃは図６と同じものでもよいし、異なっていてもよい。

監視部５３は、モータドライバ４３の割り込み又はバッテリ５０の装着により生成される。制御手段Ｃはバッテリ５０の装着により生成されるが、モータドライバ４３の割り込みより生成されてもよい。

監視部５３は、モータドライバ４３がＩ／Ｏ３８経由でＣＰＵ３１に割り込みし、ＣＰＵ３１が監視部５３の状態を高優先度の実行可能状態にすることで、ＣＰＵ３１により実行される。監視部５３は、例えば、以下のような監視を行う。
・モータドライバ４３により検出されるモータ側の電圧や電流が仕様範囲に収まっているか否かを検査する。モータＡ〜Ｃ毎に検査することができる。
・モータドライバ４３により検出されるモータ温度が所定値以下に収まっているか否かを検査する。モータＡ〜Ｃ毎に検査することができる。
・指示された回転数と実際の回転数がほぼ一定か否かを検査する
また、フェールセーフ部５４はモータの異常が検出された場合、以下のようなフェールセーフ処理を行う。
・モータドライバ４３とモータの接続を個別にオフにする。
・モータドライバ４３に出力される回転数を一定値以下に制限する。

監視部５３はモータドライバ４３が起動している状態で起動するので、故障検出ソフト２００は、回路がＡＤＣ４１の場合と同様に、モータドライバ４３をモータの故障から保護することができる。

また、ＣＡＮコントローラ４４を回路４００とみなしても、本実施形態の回路の保護方法は有効である。ＣＡＮバスがショートなどして高電圧が印加されたような場合に、ＣＡＮコントローラを保護すべき状況となる。ＣＡＮバスとＣＡＮコントローラは、＋Ｂ電源なので、ＩＧオフでもバッテリにより作動している。一般には、ＣＡＮコントローラは送信エラー回数と受信エラー回数をカウントし、所定値を超えるとバスオフすることができる。本実施例ではＣＡＮコントローラに対応した故障検出ソフトが、ＣＡＮコントローラの通信状態を検出することでＣＡＮコントローラと同等以上にＣＡＮコントローラを保護することができる。

〔＋Ｂ電源とＩＧオン電源以外の電源について〕
上記では、ＩＧオン電源で起動する制御アプリにより使用されるが、＋Ｂ電源で作動する回路４００を、＋Ｂ電源で作動するセンサ・アクチュエータ５００の故障から保護する統合ＥＣＵ１００について説明した。しかし、＋Ｂ電源とＩＧ電源以外にも、同様の関係が生じる場合がある。

図１１は、統合ＥＣＵの概略の構成例を説明する図の一例である。制御アプリＡとセンサ・アクチュエータαはＩＧオンにより作動を開始し、制御アプリＣとセンサ・アクチュエータγはＡＣＣ電源により作動を開始する。制御アプリＢはＩＧオンにより起動し、センサ・アクチュエータβはＡＣＣ電源により作動を開始する。このため、制御アプリＢが起動していない状態で、回路４００及びセンサ・アクチュエータβが作動する状況が生じうる。

このような状況において、故障検出ソフト２００はＡＣＣ電源で起動することで、回路４００をセンサ・アクチュエータβの故障から保護することができる。図１１においてＩＧをＡＣＣにＡＣＣを＋Ｂに置き換えた場合も同様に説明できる。

すなわち、本実施形態の情報処理装置は、回路４００及びセンサ・アクチュエータ５００が作動を開始する電源よりも、制御アプリが起動する電源の方が遅くオンにされる場合に有効である。

以上説明したように、本実施形態の統合ＥＣＵ１００は、機能統合に伴い統合された回路の作動時に、故障検出ソフト２００を起動させることで、センサ・アクチュエータが仮に故障しても、回路をセンサ・アクチュエータから保護することができる。

５０ バッテリ
６０ マイコン
１００ 統合ＥＣＵ
２００ 故障検出ソフト
３００ 制御アプリ
４００ 回路
５００ センサ・アクチュエータ

Claims (8)

1. ＩＧオンにより起動する第１のアプリケーションと、
   ＋Ｂ電源により起動する第２のアプリケーションと、
   ＋Ｂ電源により作動して、前記第１アプリケーションが利用する第１の周辺機器及び前記第２アプリケーションが利用する第２の周辺機器との共通のインタフェースと、を有する情報処理装置であって、
   ＋Ｂ電源により作動する前記第１又は第２の周辺機器が、当該情報処理装置に出力する入力データを監視して前記周辺機器の故障を検出する、＋Ｂ電源により起動する監視ソフト、
   を有する情報処理装置。
2. 前記監視ソフトは、＋Ｂ電源で作動する前記第１又は第２の周辺機器が、ＩＧオンで起動する前記第１のアプリケーションへの入力データを監視する、
   ことを特徴とする請求項１記載の情報処理装置。
3. ＩＧオンにより起動する第３のアプリケーションを有し、
   前記第３のアプリケーションが利用する、ＩＧオンにより作動する第３の周辺機器が前記インタフェースに接続されている、
   ことを特徴とする請求項１又は２記載の情報処理装置。
4. 前記故障検出ソフトは、前記インタフェースの作動開始により起動する、
   ことを特徴とする請求項１〜３いずれか１項記載の情報処理装置。
5. 前記故障検出ソフトは、前記インタフェースの作動開始よりも先に起動する、
   ことを特徴とする請求項１〜３いずれか１項記載の情報処理装置。
6. 前記故障検出ソフトは、前記インタフェースの数だけ起動する、ことを特徴とする請求項１〜５いずれか１項記載の情報処理装置。
7. 第１のアプリケーションが利用する第１の周辺機器及び第２のアプリケーションが利用する第２の周辺機器の共通のインタフェースと接続するためのポートと、
   ＩＧオンにより起動する前記第１のアプリケーションと、
   ＋Ｂ電源により起動する前記第２のアプリケーションと、を有する情報処理装置であって、
   ＋Ｂ電源により作動する、前記第１又は第２の周辺機器が当該情報処理装置に出力する入力データを監視して前記周辺機器の故障を検出する、＋Ｂ電源により起動する監視ソフト、
   を有する情報処理装置。
8. ＩＧオンにより起動する第１のアプリケーションと、
   ＋Ｂ電源により起動する第２のアプリケーションと、
   ＋Ｂ電源により作動して、前記第１アプリケーションが利用する第１の周辺機器及び前記第２アプリケーションが利用する第２の周辺機器との共通のインタフェースと、を有する情報処理装置であって、
   ＋Ｂ電源により作動する前記第１又は第２の周辺機器が、当該情報処理装置に出力する入力データを監視して、前記周辺機器の故障を検出する監視ソフトを起動させる、
   ことを特徴とするソフト作動開始方法。

Images