(57)【要約】【課題】演算機能を持たないドライバ回路と演算装置とが通信する車両制御装置において、両者が正常に通信できていることを簡易な手法によって効率的に診断することができる技術を提供する。【解決手段】本発明に係る車両制御装置は、演算部からドライバ回路に対する制御命令として診断データを送信し、ドライバ回路は診断データをビット反転した反転診断データを演算部に返信する。演算部は、診断データと反転診断データを用いて、演算部とドライバ回路との間の通信が正常に実施できているか否かを診断する。【選択図】図１
2014162404.tif 000002
【特許請求の範囲】
【請求項１】
車両が備える機能部を制御するための制御命令を出力する演算部と、
前記制御命令にしたがって前記機能部を駆動するドライバ回路と、
を備え、
前記ドライバ回路は、回路上にあらかじめ静的に実装された機能を実行するように構成されており、
前記演算部は、前記ドライバ回路が正常動作しているか否かを診断するための診断データを、前記制御命令として前記ドライバ回路に対して送信し、
前記ドライバ回路は、前記演算部から受信した前記診断データの少なくとも一部をビット反転した反転診断データを前記演算部に対して送信し、
前記演算部は、前記ドライバ回路へ出力した前記診断データと前記ドライバ回路から受信した前記反転診断データを用いて、前記演算部と前記ドライバ回路が正常に通信できているか否かを診断する
ことを特徴とする車両制御装置。
【請求項２】
前記演算部は、前記ドライバ回路に対して前記診断データを送信する毎に、前記診断データをビット反転させる
ことを特徴とする請求項１記載の車両制御装置。
【請求項３】
前記車両制御装置は、
前記演算部から前記ドライバ回路に対して送信する信号を伝搬する送信配線と、
前記ドライバ回路から前記演算部に対して送信する信号を伝搬する受信配線と、
を備え、
前記ドライバ回路は、
前記送信配線を介して前記演算部と通信する動作と、前記受信配線を介して前記演算部と通信する動作とを非同期に実行し、
前記機能部の動作結果を示す動作データおよび前記反転診断データを、前記演算部に対して前記受信配線を介して送信する
ことを特徴とする請求項２記載の車両制御装置。
【請求項４】
前記演算部は、前記ドライバ回路に対して前記制御命令を出力するいずれかの実行周期において、前記診断データを前記ドライバ回路に対して送信し、
前記ドライバ回路は、前記動作データを前記演算部に対して送信する前の実行周期において前記演算部から前記診断データを受信した場合は、その受信した診断データをビット反転することにより前記反転診断データを生成する
ことを特徴とする請求項３記載の車両制御装置。
【請求項５】
前記ドライバ回路は、
前記送信配線を介して前記演算部から受信したデータを格納する受信レジスタと、
前記受信配線を介して前記演算部に対して送信するデータを格納する送信レジスタと、
を備え、
前記受信レジスタと前記送信レジスタは、互いにビット干渉を起こさないように分離して構成されている
ことを特徴とする請求項３記載の車両制御装置。
【請求項６】
前記演算部は、ビット値０とビット値１を交互に配置したデータを前記診断データとして前記ドライバ回路へ送信する
ことを特徴とする請求項２記載の車両制御装置。
【請求項７】
前記演算部は、複数の前記機能部に対して同時に発行する前記制御命令を１つのシリアルデータ内に記述して前記ドライバ回路に対して送信し、
前記ドライバ回路は、
前記演算部から受信した前記シリアルデータ内に記述されているビットデータと前記機能部に対する制御命令との間の対応関係を定義する受信コマンドマップを備え、
前記受信コマンドマップを用いて、前記シリアルデータ内に記述されているビットデータを、複数の前記機能部に対する前記制御命令に変換することにより、前記シリアルデータを複数の前記機能部に対して同時に発行する前記制御命令に変換する
ことを特徴とする請求項１記載の車両制御装置。
【請求項８】
前記ドライバ回路は、複数の前記機能部の動作結果を示す前記動作データを１つのシリアルデータ内に記述して前記演算部に対して送信する
ことを特徴とする請求項３記載の車両制御装置。
【請求項９】
前記演算部と前記ドライバ回路は、マイクロセカンドバス規格に準拠して互いに通信する
ことを特徴とする請求項７記載の車両制御装置。
【請求項１０】
前記車両制御装置は、
前記演算部から前記ドライバ回路に対してクロック信号を送信する１対のクロック配線と、
１対の前記送信配線と、
１本の前記受信配線と、
前記送信配線および前記受信配線を介した通信を有効化する旨を指示する有効化信号を前記演算部から前記ドライバ回路に対して送信する１本の有効化信号配線と、
を備えることを特徴とする請求項３記載の車両制御装置。
【請求項１１】
前記演算部は、
前記診断データと前記反転診断データを用いて、前記診断データまたは前記反転データのうちビット異常が生じている箇所を特定することにより、前記受信レジスタまたは前記送信レジスタにおいて異常が生じている箇所を診断し、その結果を示す信号を出力する
ことを特徴とする請求項５記載の車両制御装置。
【請求項１２】
前記演算部は、前記診断データまたは前記反転データのうちビット異常が生じている箇所が存在する場合は、前記ドライバ回路を停止させるよう指示する前記制御命令を前記ドライバ回路に対して出力し、
前記ドライバ回路は、前記演算部から受信した前記制御命令にしたがって、前記機能部を駆動する動作を停止する
ことを特徴とする請求項１１記載の車両制御装置。
【請求項１３】
前記ドライバ回路は、前記機能部として、前記車両が備えるソレノイド回路、前記車両が備えるリレー回路、前記車両が備えるインジェクタ回路、前記車両が備えるイグニッション回路、前記車両が備えるヒータ回路のうち少なくともいずれかを駆動する
ことを特徴とする請求項１記載の車両制御装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、車両の動作を制御する装置に関する。
【背景技術】
【０００２】
従来、車両の動作を制御する電子制御装置（ＥＣＵ：Ｅｌｅｃｔｒｏｎｉｃ  Ｃｏｎｔｒｏｌ  Ｕｎｉｔ）は、車両負荷を駆動するドライバＩＣ（Ｉｎｔｅｇｒａｔｅｄ  Ｃｉｒｃｕｉｔ）と、ドライバＩＣを制御するマイコンとを備え、マイコンからドライバＩＣに対してパラレル信号を送信することにより、車両負荷を駆動制御している。
【０００３】
一方、近年ではＥＣＵに求められる機能が高機能化するとともに、低コスト化に対する要求も増している。そこで、マイコンのｐｏｒｔ数を削減してコストを低減するため、マイコンとドライバＩＣとの間で送受信するパラレル信号をシリアル信号に置き換える試みがなされている。例えばマイクロシリアルバス規格に準拠した通信が、これに該当する。
【０００４】
マイコンとドライバＩＣがシリアル信号によって通信する場合、複数の制御命令が直列的に記述されたシリアルデータを送受信することになる。この場合、マイコンとドライバＩＣとの間のシリアル通信において異常が発生すると、ドライバＩＣが駆動する全ての車両負荷に対する制御命令が異常となる。したがって、マイコンとドライバＩＣとの間のシリアル通信における異常が発生した場合はこれを即座に検出して車両をフェールセーフモードに移行させることが必要になると考えられる。
【０００５】
下記特許文献１には、電子制御装置の異常検出に関し、制御データをエコーバック（受信側が受信したデータと同じデータを送信側へ返信する）することによって異常を検出する技術が記載されている。
【０００６】
下記特許文献２には、電子制御装置の異常検出に関し、比較器２３からトランシーバ１２に対して検査信号を送信し、さらに比較器２３はトランシーバ１２から比較用信号を受信し、両者を比較した結果をＣＰＵ２１へ報告する手法が記載されている。同文献においては、上記手法により、マイコン１１とトランシーバ１２の間の信号線に断線した箇所があるか否かなどを検査している。
【０００７】
下記特許文献３には、ＥＣＵ１が備えるメインコンピュータ１ａとサブコンピュータ１ｂの間の通信において、サブコンピュータ１ｂはリードモード実行時に読み出しデータとその全ビットを反転したデータをメインコンピュータ１ａに対して送信し、メインコンピュータ１ａはこれらデータを比較することが記載されている。メインコンピュータ１ａは上記処理により、サブコンピュータ１ｂから受信した読み出しデータが正常であるか否かを確認している。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】特開２０００−３１２１５１号公報
【特許文献２】特開２０１１−２２９０７９号公報
【特許文献３】特開平４−１７０８２９号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特許文献１に記載されている技術においては、通信データそのものをエコーバックするため、通信データ自体が異常である場合にこれを検出できない可能性がある。例えばエコーバックするデータがビット値０またはビット値１いずれかに偏っていると、いずれかのビット位置において異常が発生していてもこれを正常なデータであると誤認識してしまう可能性がある。
【００１０】
特許文献２に記載されている技術においては、比較器２３を設けるための追加コストが必要になる。また、マイコン１１とトランシーバ１２が通信していない間に検査信号を発信する必要があるため、検査を実施するタイミングが制約される。
【００１１】
特許文献３に記載されている技術においては、メインコンピュータ１ａとサブコンピュータ１ｂともに演算機能を備えている必要があるため、コストが高くなる傾向がある。また、サブコンピュータ１ｂが読み出したデータとこれをビット反転したデータをともにメインコンピュータ１ａに対して送信するので、診断実施のために通信するデータ量が大きくなる傾向があると考えられる。
【００１２】
本発明は、以上のような課題に鑑みてなされたものであり、演算機能を持たないドライバ回路と演算装置とが通信する車両制御装置において、両者が正常に通信できていることを簡易な手法によって効率的に診断することができる技術を提供することを目的とする。
【課題を解決するための手段】
【００１３】
本発明に係る車両制御装置は、演算部からドライバ回路に対する制御命令として診断データを送信し、ドライバ回路は診断データをビット反転した反転診断データを演算部に返信する。演算部は、診断データと反転診断データを用いて、演算部とドライバ回路との間の通信が正常に実施できているか否かを診断する。
【発明の効果】
【００１４】
本発明に係る車両制御装置によれば、送信側である演算部から送信した診断データを受信側であるドライバ回路が反転して返信するので、診断を確実に実施することができる。また、演算部からドライバ回路に対する制御命令として診断データを送信するので、演算部にとって任意のタイミングで診断を実施することができる。さらには、ドライバ回路が演算機能を持たない場合であっても診断を容易に実施できるので、診断機能を実装するコストを抑えることができる。
【図面の簡単な説明】
【００１５】
【図１】実施形態１に係る車両制御装置１０００の構成図である。
【図２】制御フレームのビット配列を示す図である。
【図３】データフレームのビット配列を示す図である。
【図４】コマンドマップ２２０の構成例を示す図である。
【図５】アップストリーム通信におけるデータフレームのビット配列を示す図である。
【図６】アップストリーム通信におけるデータフレームの構成例を示す図である。
【図７】マイコン１００が診断データを送信するタイミングとドライバ回路２００が反転診断データを返信するタイミングの例を示す図である。
【図８】ダウンストリーム通信とアップストリーム通信のタイムチャート例である。
【発明を実施するための形態】
【００１６】
＜実施の形態１＞
図１は、本発明の実施形態１に係る車両制御装置１０００の構成図である。車両制御装置１０００は、車両が備える機能部の動作を制御するＥＣＵであり、マイコン（演算部）１００とドライバ回路２００を備える。ドライバ回路２００が駆動する車両負荷については記載を省略した。
【００１７】
マイコン１００は、ソフトウェア１１０とＭＳＢインターフェース（Ｉ／Ｆ）１２０を備える。ソフトウェア１１０は、車両動作を制御する処理を実装したアプリケーションやＢＩＯＳなどのソフトウェア群である。ＭＳＢインターフェース１２０は、ドライバ回路２００との間でシリアル通信を実施する通信インターフェースである。本実施形態１においてはマイクロセカンドバス規格に準拠したシリアル通信を実施するものとするが、通信方式はこれに限られるものではない。
【００１８】
ＭＳＢインターフェース１２０は、タイマ１２１、クロック生成器１２２、送信レジスタ１２３、受信レジスタ１２４を備える。クロック生成器１２２は、マイコン１００とドライバ回路２００の間で動作を同期させるためのクロック信号を生成し、１対のクロック配線３２０を介してドライバ回路２００へ出力する。送信レジスタ１２３は、ＭＳＢインターフェース１２０からドライバ回路２００に対して送信するデータを一時的に格納するレジスタであり、１対の送信配線３３０を介してドライバ回路２００に接続されている。受信レジスタ１２４は、ＭＳＢインターフェース１２０がドライバ回路２００から受信したデータを一時的に格納するレジスタであり、１本の受信配線３４０を介してドライバ回路２００に接続されている。
【００１９】
ＭＳＢインターフェース１２０とドライバ回路２００の間はさらに、イネーブル信号配線３１０を介して接続されている。ＭＳＢインターフェース１２０は、ドライバ回路２００に対して制御命令を発行するときは、送信配線３３０を介して制御命令を送信すると同時に、イネーブル信号配線３１０を介してイネーブル信号を送信する。
【００２０】
ドライバ回路２００は、車両負荷を駆動するドライバＩＣであり、あらかじめ回路上に静的に実装された機能を実行するように構成されている。したがってドライバ回路２００は、例えばプログラムを実行することはできない。ドライバ回路２００は、受信レジスタ２１０、コマンドマップ２２０、出力レジスタ２３０、ドライバ２４０、実行結果レジスタ２５０、送信レジスタ２６０を備える。
【００２１】
受信レジスタ２１０は、送信配線３３０を介してＭＳＢインターフェース１２０から受信したデータを一時的に格納するレジスタである。コマンドマップ２２０は、シリアルデータとして受信した制御命令を各ドライバ２４０に対するパラレルな制御命令に変換するための変換テーブルであり、詳細は後述する。出力レジスタ２３０は、コマンドマップ２２０を用いて変換した各ドライバ２４０に対する制御命令を一時的に格納するレジスタである。ドライバ２４０は、各車両負荷を駆動する回路であり、ドライバ回路２００が駆動する車両負荷の種類や個数に応じて必要な数だけ設けられている。実行結果レジスタ２５０は、各ドライバ２４０が車両負荷を駆動した結果として得られる実行結果を記述した動作データを各ドライバ２４０から受け取って一時的に格納するレジスタである。送信レジスタ２６０は、ＭＳＢインターフェース１２０に対して送信するデータを一時的に格納するレジスタである。
【００２２】
送信レジスタ１２３と受信レジスタ１２４は、互いにビット干渉を起こさないように、電気的または論理的に分離して構成することが望ましい。受信レジスタ２１０と送信レジスタ２６０についても同様である。
【００２３】
コマンドマップ２２０は、その機能を実現する回路デバイスを用いて構成することができる。同等の機能を実装したソフトウェアとこれを実行するプロセッサを用いてコマンドマップ２２０を構成することも技術的には可能であるが、ドライバ回路２００の実装コストを抑制する観点からは、上述のようにドライバ回路は回路デバイスのみを用いて構成することが望ましい。
【００２４】
＜実施の形態１：マイコン１００からドライバ回路２００に対する通信＞
マイコン１００は、送信配線３３０を介して、ドライバ回路２００に対して制御命令を送信する。マイコン１００からドライバ回路２００に対する通信を、ダウンストリームと呼ぶ場合もある。制御命令を記述したフレームは、制御フレームとデータフレームの２種類がある。以下これらデータフレームの例について説明する。
【００２５】
図２は、制御フレームのビット配列を示す図である。制御フレームは、狭義の制御命令を記述したフレームである。制御フレームは、フレームの種類を示す１ビットの選択ビット、制御命令の種類を記述した５ビットの命令ビット（Ｃ０〜Ｃ４）、制御命令の内容を記述した１１ビットのデータビット（Ｄ０〜Ｄ１０）、２ビットの無効ビットを有する。ＭＳＢインターフェース１２０は、制御フレームをドライバ回路２００に対して送信するとき、同時にイネーブル信号をアクティブにする。
【００２６】
図３は、データフレームのビット配列を示す図である。データフレームは、制御命令に含まれる数値データなどの実データを送信するためのフレームである。データフレームは、フレームの種類を示す１ビットの選択ビット、データの内容を記述した１６ビットのデータビット（Ｄ０〜Ｄ１５）、２ビットの無効ビットを有する。ＭＳＢインターフェース１２０は、データフレームをドライバ回路２００に対して送信するとき、同時にイネーブル信号をアクティブにする。
【００２７】
図４は、コマンドマップ２２０の構成例を示す図である。ＭＳＢインターフェース１２０が送信する制御命令はシリアルデータであるため、複数のドライバ２４０に対する制御命令が直列的に記述されている。そこでドライバ回路２００は、コマンドマップ２２０を用いてシリアルデータ内に記述されている各ドライバ２４０に対する制御命令を抽出し、それぞれ出力レジスタ２３０に格納する。出力レジスタ２３０は、各ドライバ２４０に対する制御命令を並列的に格納する。すなわちドライバ回路２００は、コマンドマップ２２０を用いることにより、マイコン１００が送信したシリアルデータ内に記述されている制御命令を、複数のドライバ２４０に対するパラレルな制御命令に変換する。
【００２８】
ドライバ回路２００は、マイコン１００から受信した制御フレーム内に記述されているデータが図４に示すいずれかのビットパターンと合致した場合、そのビット列は当該ビットパターンに対応する制御命令であると解釈する。
【００２９】
図４に示すデータ例においては、１６種類の制御命令を例示したが、これに限られるものではない。なお、１番目の例として記述している制御命令は、後述する診断データである。すなわち後述する診断データは、形式的には制御命令の１種として定義されている。
【００３０】
＜実施の形態１：ドライバ回路２００からマイコン１００に対する通信＞
ドライバ回路２００は、各ドライバ２４０における断線や短絡などの回路異常によって生じる異常電圧などの異常状態が発生したか否かを自己診断する機能を備えており、その診断結果を動作データとして実行結果レジスタ２５０に格納する。例えば１番目のドライバ２４０において異常電圧が発生した場合は、実行結果レジスタ２５０の１番目のビット値を１にする、などの機能を備える。
【００３１】
ただしドライバ回路２００は演算機能を持たないため、実行結果レジスタ２５０に格納されている各ビット値の意味を解釈することはできない。そこでドライバ回路２００は、実行結果レジスタ２５０に格納されている動作データをシリアルデータに変換し、送信レジスタ２６０および受信配線３４０を介してマイコン１００へ送信する。マイコン１００は、ソフトウェア１１０が実装している機能によってドライバ回路２００から受信した動作データを診断する。
【００３２】
ドライバ回路２００からマイコン１００に対する通信を、アップストリームと呼ぶ場合もある。ドライバ回路２００は、ダウンストリーム通信とアップストリーム通信を非同期で実施する。すなわちドライバ回路２００は、マイコン１００から制御命令を受信したか否かによらず、例えば一定の動作周期で実行結果レジスタ２５０内の動作データをマイコン１００へ送信する。
【００３３】
図５は、アップストリーム通信におけるデータフレームのビット配列を示す図である。アップストリーム通信におけるデータフレームは、１ビットの開始ビット、４ビットのコマンドフィールド（Ｃ０〜Ｃ３）、２ビットのアドレスフィールド（Ａ０〜Ａ１）、６ビットのデータフィールド（Ｄ０〜Ｄ５）、１ビットのパリティビット、２ビットの停止ビットを有する。複数のデータフレームを連続して送信する場合は、データフレーム間に１ビットのフレーム間ビットを設ける。アップストリーム通信はダウンストリーム通信とは非同期に実施されるため、アップストリーム通信においてはイネーブル信号は必要ない。
【００３４】
図６は、アップストリーム通信におけるデータフレームの構成例を示す図である。ドライバ回路２００は、各ドライバ２４０についての診断結果を、図６に示すような変換規則にしたがってシリアルデータに変換し、送信レジスタ２６０に格納する。送信レジスタ２６０に格納されたシリアルデータは、例えば一定の動作周期でマイコン１００へ送信される。図６に示す変換規則は、ダウンストリーム通信においてシリアルデータをパラレルデータに変換する処理と逆向きの変換であるため、コマンドマップ２２０上に実装することができる。
【００３５】
＜実施の形態１：診断データ＞
ドライバ回路２００は、各ドライバ２４０における異常発生の有無を示す動作データをマイコン１００へ送信する。この動作データによる異常診断は、車両負荷の異常を診断するという側面が強く、ドライバ回路２００自身に発生した異常については診断することが困難である。
【００３６】
他方、ドライバ回路２００が備える受信レジスタ２１０において、例えばビット固着（特定箇所のビットが固定される）などの異常が発生すると、ドライバ２４０に対する制御命令が正しく伝達されず、車両動作が危険な状態になる可能性がある。同様に送信レジスタ２６０において異常が発生すると、マイコン１００はドライバ２４０の動作を正しく診断することができない。同様の不具合は、送信配線３３０や受信配線３４０において異常が発生している場合にも生じ得る。
【００３７】
上記のようなドライバ回路２００の異常は、ドライバ回路２００が演算機能を備え、各レジスタ上のデータや各配線上のデータを例えばパリティチェックなどによってチェックすることにより、ドライバ回路２００自身が自己診断できる可能性がある。しかしドライバ回路２００内に演算機能を設けると、ドライバ回路２００の実装コストが増大する。またドライバ２４０をドライバ回路２００内に実装する場合、ドライバ２４０は発熱し易い傾向があり、さらに演算機能を追加すると発熱原因を追加することになるので、熱対策の観点から好ましくない。
【００３８】
そこで本実施形態１において、マイコン１００はドライバ回路２００との間の通信が正常に実施できているか否かを診断するための診断データをドライバ回路２００へ送信し、ドライバ回路２００は診断データをビット反転した反転ビットデータをマイコン１００へ返信することとした。マイコン１００は、診断データと反転診断データの論理和を求め、その結果すべてのビットが１になれば、ドライバ回路２００との間の通信が正常に実施できていることを確認できる。
【００３９】
診断データのビット配列は任意である。例えば診断データとして「１１００」を送信した場合、ドライバ回路２００はこれを反転した反転診断データ「００１１」をマイコン１００へ返信する。マイコン１００は、「１１００」と「００１１」の論理和を求め、その結果すべてのビットが１であれば（１１００＋００１１＝１１１１）、ドライバ回路２００との間の通信が正常に実施できていることが分かる。すなわち、受信レジスタ２１０、送信レジスタ２６０、送信配線３３０、受信配線３４０のいずれにおいても異常が発生していないことを確認することができる。
【００４０】
図７は、マイコン１００が診断データを送信するタイミングとドライバ回路２００が反転診断データを返信するタイミングの例を示す図である。マイコン１００が診断データをドライバ回路２００に対して送信するタイミングとしては様々なものが考えられる。本実施形態１においては、マイコン１００からドライバ回路２００に対する制御命令の１種として診断データを定義し、マイコン１００は制御命令をドライバ回路２００に対して送信するタイミングであればいつでも、診断データを送信することができるものとした。
【００４１】
図７に示す例において、マイコン１００は任意の実行周期内でドライバ回路２００に対して診断データを送信する。診断データは、図４の１番目に例示した制御命令「ＲＤ＿ＤＡＴＡ」として定義されている。ドライバ回路２００は、コマンドマップ２２０を用いて診断データが到着したか否かを判定することができる。ドライバ回路２００は、制御命令ＲＤ＿ＤＡＴＡが到着した場合は、ＲＤ＿ＤＡＴＡの全ビットをビット反転した反転診断データを、実行結果レジスタ２５０に格納する。
【００４２】
ドライバ回路２００は、アップストリーム通信を実施する実行周期において、図６に例示した変換規則にしたがって動作データをシリアルデータに変換する。さらに、直前の実行周期において反転診断データが実行結果レジスタ２５０内に格納されている場合は、これをシリアルデータ内の適当な位置（例えば末尾）に追加する。
【００４３】
マイコン１００は、診断データをドライバ回路２００に対して送信した場合、次にアップストリーム通信を受信するとき、動作データと併せて反転診断データを受信することになる。マイコン１００は、上述の診断規則にしたがって診断を実施する。
【００４４】
図８は、ダウンストリーム通信とアップストリーム通信のタイムチャート例である。以下、図８のタイムチャート例について説明する。
【００４５】
マイコン１００とドライバ回路２００はシリアル通信するため、要求される最も短い通信周期に合わせてダウンストリーム通信の制御周期を設定する必要がある。すなわち、各車両負荷が要求する制御周期のうち最短のものを満足する必要がある。さらには、制御命令の確からしさを確認するため２連照合（同じデータを２回連続して送信し、２回とも同じデータであれば正常データとみなす）を用いた場合、最短周期の１／２周期で制御命令を送信する必要がある。
【００４６】
図８に示す例においては、リレー負荷、インジェクタ負荷、イグニッション負荷の３種類が存在し、イグニッション負荷が要求する制御周期が最も短く３．２μｓであるものと仮定した。そのためマイコン１００は、１．６μｓ周期でドライバ回路２００に対して制御命令を送信する必要がある。具体的な通信周期は負荷仕様や要求精度などに応じて適宜定めればよい。その他の負荷としては、例えばソレノイド回路、ヒータ回路などが考えられる。
【００４７】
またマイコン１００は、任意の通信周期において、上述の診断データ（ＲＤ＿ＤＡＴＡ）をドライバ回路２００に対して送信する。診断データは制御命令の１つとして定義されているため、制御命令の順番などの制約がない限り、任意のタイミングにおいて診断データを送信することができる。
【００４８】
ドライバ回路２００は、ダウンストリーム通信とは非同期にアップストリーム通信を実施し、各ドライバ２４０の動作データをマイコン１００へ送信する。直前のアップストリーム通信周期において診断データを受信した場合、ドライバ回路はこれをビット反転した反転診断データ（ＩＮＶ＿ＲＤ＿ＤＡＴＡ）をアップストリーム通信内の適当な箇所（図８に示す例では末尾）に付加する。
【００４９】
マイコン１００は、次回以降のダウンストリーム通信周期において診断データを送信する場合、前回の診断データをビット反転したデータ（ＩＮＶ＿ＲＤ＿ＤＡＴＡと等しくなる）を、新たな診断データとしてドライバ回路２００に対して送信する。以後同様に、診断データを送信する毎にビットを反転する。これは全てのビット位置を均一に診断するためである。詳細は実施形態２において説明する。
【００５０】
アップストリーム通信の通信周期は任意でよい（例えば１０ｍｓ周期）が、通信回数が増えると演算負荷が増加するため、必要最小限に抑えることが望ましい。例えばマイコン１００側でＯＢＤ２（Ｏｎ  Ｂｏａｒｄ  Ｄｉａｇｎｏｓｉｓ  ２）などの車両診断を実施する際に必要な通信速度とすればよい。
【００５１】
図８に例示するような診断処理を実施するタイミングとしては、車両が起動する前が望ましい。具体的には、車両制御装置１０００のリセットが解除されてからエンジンが始動する前までに実施することが望ましい。
【００５２】
＜実施の形態１：まとめ＞
以上のように、本実施形態１に係る車両制御装置１０００において、マイコン１００は制御命令の１つとして診断データをドライバ回路２００に対して送信し、ドライバ回路２００は診断データをビット反転した反転診断データをマイコン１００に返信する。これにより、マイコン１００は制御命令を送信する任意のタイミングで、ドライバ回路２００との間の通信が正常に実施できているか否かを診断することができる。
【００５３】
また、本実施形態１に係る車両制御装置１０００において、マイコン１００は診断データと反転診断データの論理和が全ビット１であるか否かにより、上記診断を実施する。この診断規則は診断データのビット配列によらず同一であるため、マイコン１００側の診断処理を簡易化することができる（各ビットを逐一比較する必要がない）。またドライバ回路２００はビットを反転するのみでよいので、例えばビット値を表す電圧値を増減する回路（ＮＯＴ回路）などにより、演算機能を用いずに上記処理を実装することができる。
【００５４】
また、本実施形態１に係る車両制御装置１０００において、ドライバ回路２００は、ダウンストリーム通信とは非同期にアップストリーム通信を実施する。これにより、マイコン１００は診断データを送信した結果を待機する必要がなくなるので、診断データを送信するタイミングをさらに自由に設定することができる。
【００５５】
また、本実施形態１に係る車両制御装置１０００において、ドライバ回路２００は、各ドライバ２４０の自己診断結果を記述した動作データと併せて、反転診断データをシリアル化してマイコン１００に送信する。これにより、反転診断データを送信するための通信周期を別途設ける必要がなくなるので、通信負荷を軽減することができる。
【００５６】
また、本実施形態１に係る車両制御装置１０００において、マイコン１００とドライバ回路２００は、１本のイネーブル配線３１０、１対のクロック配線３２０、１対の送信配線３３０、１本の受信配線３４０の、合計６配線によって接続され、互いにＭＳＢ規格に準拠したシリアル通信を実施する。これにより、マイコン１００とドライバ回路２００それぞれの端子数および配線数を少なく抑えることができる。
【００５７】
＜実施の形態２＞
実施形態１においては、マイコン１００が送信する診断データは任意でよいことを説明した。ただし、より効率的に診断を実施するためには、診断データのビット配列について工夫する余地があると考えられる。そこで本発明の実施形態２においては、より効率的に診断を実施することができる診断データのビット配列について検討する。車両制御装置１０００の構成は実施形態１と同様である。
【００５８】
各レジスタや配線に異常が発生すると、特定位置のビット値が同一の値に固定される（ビット固着）可能性がある。ビット固着をできる限り短い通信周期で検出するためには、マイコン１００が診断データを送信する毎に全ビットを反転させ、２通信周期以内で全ビットがビット値０とビット値１の双方を持つようにすることが望ましい。これは送信レジスタ１２３と受信レジスタ１２４の双方について同様であり、またドライバ回路２００内の受信レジスタ２１０と送信レジスタ２６０の双方について同様である。
【００５９】
また、各レジスタは隣接するビットが異物などの要因によって短絡し、必ず同じ値となる（ビット短絡）異常が発生する可能性がある。ビット短絡を回避するためには、診断データはビット値０とビット値１を交互に有することが望ましい。
【００６０】
以上に鑑みると、マイコン１００が送信する診断データとしては、ビット値０とビット値１を交互に有し、かつ診断データを送信する毎にビット値を反転することが望ましいと考えられる。図４の１行目に示すＲＤ＿ＤＡＴＡの例においては、この検討を踏まえ、ビット値０から開始するビット配列とビット値１から開始するビット配列ともに、ＲＤ＿ＤＡＴＡとして定義した。
【００６１】
＜実施の形態２：まとめ＞
以上のように、本実施形態２に係る車両制御装置１０００は、ビット値０とビット値１を交互に有するビット配列を、診断データとして用いる。これにより、２通信周期以内でビット固着を検出し、かつビット短絡による誤診断を回避することができる。
【００６２】
＜実施の形態３＞
以上の実施形態１〜２において、マイコン１００は、診断データのいずれかの位置において異常なビットを検出した場合、そのビット位置に対応するレジスタアドレスが異常であることを検出することができる。ただしこの異常は、診断データを発行することによって検出した異常であり、ドライバ２４０から取得する動作データには依拠していない。すなわちこの異常は、車両負荷やドライバ２４０の異常を表すものではない。このときマイコン１００が実施する動作としては、例えば以下のようなものが考えられる。
【００６３】
（異常検出時の動作例１）
マイコン１００は、異常を検出したビット位置に対応する車両負荷またはドライバ２４０を停止させる旨の制御命令を発行する。ただし、レジスタが故障していると制御命令がドライバ２４０に対して正常に伝達されない可能性があるため、例えば別の通信配線などを経由してドライバ２４０に対して制御命令を伝達する必要がある。
【００６４】
（異常検出時の動作例２）
マイコン１００は、診断データのいずれかのビット位置において異常が検出された場合は、車両動作を安全側に倒し、ドライバ回路２００の動作を停止する。具体的には、イネーブル信号を非アクティブにしてもよいし、制御命令として動作停止命令を発行してもよい。
【００６５】
（異常検出時の動作例３）
マイコン１００は、異常を検出したビット位置またはこれと同等の内容を示す信号を、例えば上位の制御装置に対して出力する。
【００６６】
＜実施の形態４＞
本発明は上記した実施形態に限定されるものではなく、様々な変形例が含まれる。上記実施形態は本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。また、ある実施形態の構成の一部を他の実施形態の構成に置き換えることもできる。また、ある実施形態の構成に他の実施形態の構成を加えることもできる。また、各実施形態の構成の一部について、他の構成を追加・削除・置換することもできる。
【００６７】
実施形態１〜３において、ドライバ回路２００は、装置コストなどの制約条件が許容する限りにおいては、回路構成を動的に変更することによりプログラム可能な回路デバイス（ＦＰＧＡなど）を用いて構成することもできるし、実施形態１で説明したようにあらかじめ回路基板上に実装された機能のみを実施し、その回路構成を動的に変更することができない回路デバイスを用いて構成することもできる。あるいは、ドライバ回路２００が担う機能を実現するには不十分な最小限度の演算機能をドライバ回路２００に付与してもよい。
【００６８】
実施形態１〜３において、ドライバ回路２００は診断データをビット反転して送信することを説明したが、必ずしも診断データの全ビットを反転して一括送信する必要はなく、一部のビットのみを反転して送信することを繰り返すようにしてもよい。マイコン１００はドライバ回路２００から受け取ったビット反転データを用いて逐次診断を実施することを繰り返すことにより、診断データ全体を診断する。
【００６９】
診断データの一部ビットを反転させる場合、例えばマイコン１００からドライバ回路２００に対してダウンストリーム通信によりコマンドマップ２２０の切り替えを指示し、順次診断を実施することにより、全ビットを診断するようにしてもよい。この場合、コマンドマップ２２０上において、ビットシフトなどの手法により診断データをビット反転させるコマンドを記述しておき、ドライバ回路２００はこれを用いてビット反転を実施するようにしてもよい。ただし、ドライバ回路２００の実装コストや診断処理負荷が増大するため、全ビットを一度に反転するのが望ましい。
【符号の説明】
【００７０】
１００：マイコン、１１０：ソフトウェア、１２０：ＭＳＢインターフェース、１２１：タイマ、１２２：クロック生成器、１２３：送信レジスタ、１２４：受信レジスタ、２００：ドライバ回路、２１０：受信レジスタ、２２０：コマンドマップ、２３０：出力レジスタ、２４０：ドライバ、２５０：実行結果レジスタ、２６０：送信レジスタ、３１０：イネーブル信号配線、３２０：クロック配線、３３０：送信配線、３４０：受信配線、１０００：車両制御装置。
【図１】
2014162404.tif 000003
【図２】
2014162404.tif 000004
【図３】
2014162404.tif 000005
【図４】
2014162404.tif 000006
【図５】
2014162404.tif 000007
【図６】
2014162404.tif 000008
【図７】
2014162404.tif 000009
【図８】
2014162404.tif 000010