JP7042096B2 - 車両用電子制御装置 - Google Patents

Description

本発明は、車両用電子制御装置に関し、例えばＥＣＭ（Engine Control Module）におけるリプログラミング時の故障情報の維持に関する。

ＥＣＭなどの車両用電子制御装置では、故障を検知した場合に、車両に発生した故障情報を不揮発性メモリに記憶して保持している。そして、整備や点検のときに作業者が診断用の外部ツールをＥＣＭに接続して不揮発性メモリから故障情報を読み出し、外部ツールのモニタに故障の状況を表示して確認するようになっている（例えば特許文献１及び特許文献２参照）。

特開２００９－０５９３３４号公報 特開２００９－０６７２９８号公報

ところで、車両用電子制御装置では、プログラムやデータに更新、あるいは修正が必要になると、それらの書き換え、いわゆるリプログラミングが行われる。この際、ＥＣＭが故障を検知した後でリプログラミングを行うと、不揮発性メモリに記憶されている故障情報を外部ツールで表示できない可能性がある。これは、リプログラミングの前後で情報の形態が変化すると、故障情報の引き継ぎができないからである。このため、リプログラミング時には、不揮発性メモリに記憶した故障情報を消去するのが一般的であった。
しかしながら、法規制の変更により、リプログラミング後であっても、故障情報を維持することが要求されるようになった。

本発明は上記のような事情に鑑みてなされたもので、その目的とするところは、リプログラミングを行っても、記憶情報を維持して正しい車両情報を外部ツールに出力できる車両用電子制御装置を提供することにある。

本発明の一態様に係る車両用電子制御装置は、プログラムを外部から書き換え可能に構成された電子制御装置であって、書き換え前（リプログラミング前）の複数の制御プログラム間及び書き換え後（リプログラミング後）の制御プログラム間で共通し、且つ前記書き換え前の制御プログラムと前記書き換え後の制御プログラムに依存しない管理ナンバーを、車両の動作中に生じた故障コードに対応させて記憶し、前記複数の制御プログラムの少なくとも１つを書き換えた後に、記憶した前記管理ナンバーから前記少なくとも１つの書き換えた制御プログラムに依存するインデックスを参照し、当該インデックスに基づき前記故障コードを出力して外部ツールの表示に用いる、ことを特徴とする。

本発明によれば、リプログラミング前の複数の制御プログラム間及びリプログラミング後の制御プログラム間で共通し、且つリプログラミング前の制御プログラムとリプログラミング後の制御プログラムに依存しない管理ナンバーを記憶することで、リプログラミング前の制御プログラムの書き換えを行った後でも記憶情報を維持し、リプログラミング後の制御プログラムに依存するインデックスを出力することで、複数のリプログラミング前の制御プログラムの少なくとも１つをリプログラミング後の制御プログラムに書き換えても故障コードの互換性を保つことができる。従って、リプログラミングを行っても、記憶情報を維持して正しい故障コードを外部ツールに出力できる。

本発明の実施形態に係る車両用電子制御装置の概略構成を示すブロック図である。 図１に示した車両用電子制御装置のリプログラミングを行う場合のシステム概要図である。 図２に示したリプログラミングツールの構成例を示すブロック図である。 従来と本発明の診断情報を対比して示す図である。 図１に示した車両用電子制御装置におけるリプログラミング動作を示すフローチャートである。 図１に示した車両用電子制御装置におけるリプログラミング前とリプログラミング後の状態について説明するための図である。 新旧プログラムの識別方法及び外部表示処理の詳細について説明するための図である。 新旧プログラムの識別方法及びリプログラミング方法の第１の例について説明するための図である。 新旧プログラムの識別方法及びリプログラミング方法の第２の例について説明するための図である。 新旧プログラムの識別方法及びリプログラミング方法の第３の例について説明するための図である。 新旧プログラムの識別方法及びリプログラミング方法の第４の例について説明するための図である。

以下、本発明の実施形態について図面を参照して説明する。
図１は、本発明の実施形態に係る車両用電子制御装置の概略構成を示している。車両１０に搭載されたエンジン２０（内燃機関）には、各種のセンサ３１が設けられており、これらセンサ３１で検出された信号がＥＣＭ３０に入力される。センサ３１は、例えば吸入空気量センサ、クランク角センサ、アクセル開度センサ、水温センサ、カム角センサ、空燃比センサ、及び油温センサなどである。また、ＥＣＭ３０には、エンジン２０の運転及び停止のメインスイッチであるイグニッションスイッチ（図示せず）からの信号が入力される。

ＥＣＭ３０は、これら各種のセンサ３１及びイグニッションスイッチからの信号に基づいて、予め記憶された制御プログラムに従って演算処理を行い、例えば燃料噴射弁、ＶＴＣ機構及び点火モジュールなどの各種装置の操作量あるいは制御量を算出し、これらの装置や装置を駆動するアクチュエータ３２などに制御信号を出力して制御する。

このＥＣＭ３０は、ＣＰＵ（Central Processing Unit）などのプロセッサ３３と、揮発性メモリの一例としてのＲＡＭ（Random Access Memory）３４と、制御プログラム及び各種データを記憶する不揮発性メモリの一例としてのＲＯＭ（Read Only Memory）３５と、車両情報（故障や異常の情報）及び学習値などを記憶する不揮発性メモリの一例としてのＥＥＰＲＯＭ（Electrically Erasable and Programmable Read Only Memory）３６と、入力と出力のインターフェースを行うための入出力インターフェース（入出力Ｉ／Ｆ）３７と、外部装置と通信を行うための外部通信インターフェース（外部通信Ｉ／Ｆ）３８と、バス３９とを備えている。

プロセッサ３３、ＲＡＭ３４、ＲＯＭ３５、ＥＥＰＲＯＭ３６、入出力Ｉ／Ｆ３７及び外部通信Ｉ／Ｆ３８は、バス３９によって相互に接続されている。また、外部通信Ｉ／Ｆ３８は、ネットワークケーブル４０を着脱可能に接続するコネクタ３８ａを有する。このコネクタ３８ａには、外部からプログラムを書き換えるためのリプログラミングツール５０、あるいは故障発生時に整備や点検を行うための外部ツール６０がＣＡＮ（Controller Area Network）、シリアル通信、ＦｌｅｘＲａｙ（登録商標）及びＥｔｈｅｒｎｅｔ（登録商標）などのネットワークケーブル４０を介して接続される。

図２は、車両用電子制御装置のリプログラミングを行う場合のシステム構成を示している。リプログラミングの対象となるＥＣＭ３０は、ネットワークケーブル４０を介して、リプログラミングツール５０に着脱自在に接続される。この状態で、作業者がリプログラミングツール５０を操作して、ＥＣＭ３０のリプログラミング作業を行う。
なお、ＥＣＭ３０とリプログラミングツール５０とは、ネットワークケーブル４０とコネクタ３８ａ，５２ａを使用した有線接続に限らず、無線送受信機を使用した無線通信によって相互に接続されるように構成しても良い。

リプログラミングツール５０は、作業者がＥＣＭ３０のデータの書き換え作業を行う電子機器であって、例えば、パーソナルコンピュータなどから構成される。具体的には、リプログラミングツール５０は、図３に示すように、ＣＰＵなどのプロセッサ５１と、ネットワークに接続するための通信装置５２と、ハードディスク装置やＳＳＤ（Solid State Drive）などのストレージ５３と、作業者へのインターフェースとなる入出力装置５４と、バス５５とを備えている。プロセッサ５１、通信装置５２、ストレージ５３及び入出力装置５４は、バス５５によって相互に接続されている。ここで、通信装置５２は、ネットワークケーブル４０を着脱可能に接続するコネクタ５２ａを有する。また、入出力装置５４は、ＬＣＤ（Liquid Crystal Display）などのディスプレイと、キーボードと、マウスなどのポインティングデバイスと、を含む。

なお、ストレージ５３は、例えば、図示しないネットワークに接続されたＮＡＳ（Network Attached Storage）やサーバのストレージなどであってもよい。
このストレージ５３には、ＥＣＭ３０のＥＥＰＲＯＭ３６を書き換えるためのデータが格納されている。このデータは、例えば、エンジン２０に搭載あるいは設置された各種機器を制御する制御プログラム、その制御プログラムで使用される定数やマップなどの制御パラメータなどを含む。

リプログラミング処理（データ書き換え処理）は、作業者がネットワークケーブル４０を介してＥＣＭ３０とリプログラミングツール５０とを接続した後、リプログラミングツール５０において、所定の操作を行ったときに実行される。ここでは、ＥＣＭ３０は、ネットワークケーブル４０を介してリプログラミングツール５０と接続されたときに、電力が供給されて起動することを前提とするが、別の電源ケーブルの接続により起動する形態もあり得る。

一方、外部ツール６０は、ＥＣＭ３０から出力される故障コードを受信し、故障コードに対応する故障状態をモニタに表示するもので、専用の診断ツールであっても良いし、リプログラミングツール５０と同様に、例えばパーソナルコンピュータなどから構成されても良い。また、外部ツール６０とＥＣＭ３０は、ネットワークケーブル４０を使用した有線接続に限らず、無線送受信機を使用した無線通信によって相互に接続されるような構成でも良い。ここでは、外部ツール６０には、周知の診断ツールを用いるものとして詳細な説明は省略する。

図４は、従来と本発明の診断情報を対比して示している。すなわち、従来は、図４（ａ）に示すように、故障コード（ＤＴＣ：Diagnostic Trouble Code）とインデックス（Index）を用いており、ＥＣＭ３０が故障を検知すると、その故障コードに対応するインデックスをＥＥＰＲＯＭ３６に記憶していた。そして、整備や点検のために、外部ツール６０がＥＣＭ３０のコネクタ３８ａに接続されて、故障コードの出力要求があると、ＥＥＰＲＯＭ３６に記憶したインデックスを元に故障コードを決定し、外部ツール６０に車両情報として故障コードを送信していた。外部ツール６０は、受信した故障コードに対応する故障状態をモニタに表示する。

例えば、検知した故障の故障コードが「２０００」であるとすると、ＥＥＰＲＯＭ３６には故障コード「２０００」に対応するインデックス「３」が記憶される。そして、外部ツール６０が接続されて故障コードの出力要求があると、ＥＥＰＲＯＭ３６に記憶されているインデックス「３」から、このインデックス「３」に対応する故障コード「２０００」を参照し、車両情報として故障コード「２０００」を外部ツール６０に送信する。外部ツール６０は、この故障コード「２０００」に対応する故障の状態をモニタに表示する。
ここで、故障コードがどのような故障に該当するかの定義は変わらないが、インデックスは制御プログラムの数に依存し、診断数に対応して振り分けられているため、プログラムの書き換えで診断数が増減すると、インデックスの番号が変化してしまう。

これに対し、本発明では、図４（ｂ）に示すように、故障コードとインデックスに加えて、管理ナンバー（管理Ｎｏ．）を用いる。管理ナンバーは、制御プログラムの数に依存せず（診断数にも依存しない）、書き換え前の複数の制御プログラム（第１制御プログラム）及び書き換え後の制御プログラム（第２制御プログラム）間で共通に使用されるものである。従って、インデックスは、故障コード「１０００」、「１００１」、「１００２」、「２０００」、「２００１」に順次「１」、「２」、「３」、「４」、「５」と割り振られるのに対し、管理ナンバーは、各故障コードに対応して「００」、「０１」、「０２」、「０５」、「０６」と診断に応じて割り振られている。そして、故障を検知すると、その故障コードに対応するインデックスをＥＥＰＲＯＭ３６に記憶するのではなく、管理ナンバーをＥＥＰＲＯＭ３６に記憶する。

すなわち、図５のフローチャートに示すように、例えばＥＣＭ３０が故障コード「２０００」の故障を検知すると（ステップＳ１）、故障コード「２０００」からインデックス「３」を参照し、インデックス「３」から管理ナンバー「０５」を参照する。そして、故障コード「２０００」に対応する管理ナンバー「０５」をＥＥＰＲＯＭ３６に記憶する（ステップＳ２）。この状態を図６（ａ）に模式的に示す。

その後、制御プログラムの書き換え（リプログラミング）が行われ（ステップＳ３）、図６（ｂ）に示すように、故障コード「１００２」と「２０００」との間に故障コード「１００３」が追加されたと仮定すると、インデックスは診断数に依存するため、故障コード「１００３」はインデックス「３」、故障コード「２０００」はインデックス「４」、故障コード「２００１」はインデックス「５」となる。この際、故障コード「１０００」、「１００１」、「１００２」に対応するインデックス「０」、「１」、「２」は変化しない。
また、管理ナンバーは、故障コードに対応し、複数の制御プログラム間で共通に使用されるので、新たな管理ナンバー「０３」が追加されるものの、他の管理ナンバーはリプログラミング前の状態を維持する。

次に、外部ツール６０を接続して（ステップＳ４）、故障コードの出力要求を行うと（ステップＳ５）、図６（ｃ）に示すように、ＥＥＰＲＯＭ３６に記憶した管理ナンバー「０５」が参照される（ステップＳ６）。続いて、管理ナンバー「０５」からインデックス「４」を参照し（ステップＳ７）、インデックス「４」から故障コード「２０００」を参照し（ステップＳ８）、外部ツール６０に車両情報としてインデックス「４」に対応する故障コード「２０００」を送信する。外部ツール６０は、この車両情報を受けて故障コード「２０００」に対応する故障の状態をモニタに表示する。

このように、故障コード（車両情報）からインデックス（第２識別情報）を参照し、インデックスから管理ナンバー（第１識別情報）を参照してＥＥＰＲＯＭ３６に記憶する。このＥＥＰＲＯＭ３６に記憶した管理ナンバーからインデックスを参照し、故障コードを外部ツール６０に送信する。このように、管理ナンバーをＥＥＰＲＯＭ３６に記憶することで、制御プログラムの書き換えによってインデックスが変化しても、記憶情報（故障情報）を維持でき、管理ナンバーからインデックスを参照して故障コードを出力することで、プログラムの書き換え前の故障コードとの互換性を失うことがないので、外部ツール６０に正しい故障コードを出力できる。

図７は、新旧プログラムの識別方法及び外部表示処理の詳細を示している。本例では、管理ナンバーに「ＤＧＮＳＷｂｙｔｅ」と「ＤＧＮＳＷｂｉｔ」の情報を組み合わせて使用している。すなわち、従来と同じビット数で診断数を表現すると、診断数の最大値（Ｍａｘ）は、「２５６×８＝２０４８」である。１６進数では、「０７ＦＦ」で表され、最上位ビット（ＭＳＢ１５）は「０」であるので、「ＭＳＢ１５＝０」を旧プログラムと定義し、最上位ビットに「１」を書き込み、「ＭＳＢ１５＝１」を新プログラムと定義する。これによって、最上位ビットが「１」か「０」かにより新旧のプログラムを識別できる。
このような新旧のプログラムの識別を可能にするために、ＥＥＰＲＯＭ３６には「ｂｙｔｅ／ｂｉｔ」の順で記憶するのではなく、「ｂｉｔ／ｂｙｔｅ」の順に記憶すると良い。

図８は、新旧プログラムの識別方法及びリプログラミング方法の第１の例を示している。本例は、新旧プログラムの書き込み時の故障コードの扱いに関するものである。ＥＣＭ３０に書き込まれているプログラムが旧プログラムで、書き換えるプログラムも旧プログラムの場合には、故障コードは消去（従来通り）する。ＥＣＭ３０に書き込まれているプログラムが旧プログラムで、書き換えるプログラムが新プログラムの場合には、故障コードは消去する。ＥＣＭ３０に書き込まれているプログラムが新プログラムで、書き換えるプログラムが旧プログラムの場合にも、故障コードは消去する。そして、ＥＣＭ３０に書き込まれているプログラムが新プログラムで、書き換えるプログラムが新プログラムの場合には、故障コードを保持する。
このように、本発明は、ＥＣＭ３０に書き込まれている新プログラムを新プログラムに書き換える場合が対象となる。

図９は、新旧プログラムの識別方法及びリプログラミング方法の第２の例を示している。本例は、書き換え前の制御プログラムが管理ナンバーを持っているか否かを確認し、持っていない場合にはＥＥＰＲＯＭ３６に記憶されているデータを消去するものである。管理ナンバーを持っていない場合には、書き換え前には図９（ａ）に示すように、ＥＥＰＲＯＭ３６にインデックス（ここでは「３」）が記憶されている。すなわち、ＥＥＰＲＯＭ３６に記憶されているデータが、インデックスであるので旧プログラムである。よって、データを消去して初期化する。

この結果、書き換え後のプログラムは、図９（ｂ）に示すように故障コード「１００３」が増加し、インデックス「３」が故障コード「１００３」に対応し、インデックス「４」が故障コード「２０００」に対応し、インデックス「５」が故障コード「２００１」に対応するように変化する。また、故障コード「１０００」、「１００１」、「１００２」、「１００３」、「２０００」、「２００１」にそれぞれ対応して、管理ナンバー「００」、「０１」、「０２」、「０３」、「０５」、「０６」が追加される。
一方、ＥＥＰＲＯＭ３６に管理ナンバーが記憶されている場合には、新プログラムであるのでデータの消去は行わない。
このように、ＥＥＰＲＯＭ３６に記憶されているのがインデックスか管理ナンバーかを判別することで、旧プログラムか新プログラムかを判定できる。

図１０は、新旧プログラムの識別方法及びリプログラミング方法の第３の例を示している。書き換え前の制御プログラムが図１０（ａ）の状態で、ＥＥＰＲＯＭ３６に管理ナンバー「０５」が記憶されているものとする。この状態で、リプログラミングより故障コード「２０００」が削除されたとすると、図１０（ｂ）に示す状態となる。すなわち、インデックス「０」が故障コード「１０００」に対応し、インデックス「１」が故障コード「１００１」に対応し、インデックス「２」が故障コード「１００２」に対応し、インデックス「３」が故障コード「１００３」に対応し、インデックス「４」が故障コード「２００１」に対応するように変化する。このとき、故障コード「１０００」、「１００１」、「１００２」、「１００３」、「２００１」にはそれぞれ、管理ナンバー「００」、「０１」、「０２」、「０３」、「０６」が対応する。
この場合には、外部ツール６０に故障コードは出力されないが、現状と同じであるので問題はない。

図１１は、新旧プログラムの識別方法及びリプログラミング方法の第４の例を示している。書き換え前の制御プログラムが図１１（ａ）の状態で、リプログラミングより故障コード「２０００」、「２００１」が変更された制御プログラム（故障コード「４０００」、「４００１」）に書き換えられた場合、図１１（ｂ）の状態となる。このように、故障コードが変更されても、故障コード「２０００」と「４０００」の故障内容が変わることはないので問題はない。
但し、外部ツール６０における故障コードと車両の故障状態との対応関係も修正する必要がある。

上述したように、本発明においては、書き換え前の複数の制御プログラム（第１制御プログラム）間及び書き換え後の制御プログラム（第２制御プログラム）で共通し、且つ制御プログラムに依存しない管理ナンバー（第１識別情報）を、車両の動作中に生じた故障コード（車両情報）に対応させて不揮発性メモリ（ＥＥＰＲＯＭ）に記憶しておくことで、制御プログラム（第２制御プログラム）の書き換えを行った後でも記憶情報を維持できる。また、複数の制御プログラムの少なくとも１つを書き換えた後に、記憶した管理ナンバーから制御プログラムに依存するインデックス（第２識別情報）を参照し、このインデックスに基づき故障コードを出力して外部ツールの表示に用いることで、制御プログラムの書き換え前と故障コードの互換性を保つことができる。
従って、本発明によれば、リプログラミングを行っても、不揮発性メモリに記憶した故障情報を維持することができ、正しい故障コードを外部ツールに出力できる。

なお、上述した実施形態では、ＥＣＭを例に取って説明したが、プログラムやデータがリプログラミングされる電子制御装置一般に適用できるのは勿論である。
また、記憶情報が故障コード（故障情報）の場合を例に取って説明したが、学習値を保持する場合も同様にして適用できる。

更に、「複数の制御プログラムの少なくとも１つを書き換える」と表現したが、これには特定の制御プログラムの一部分や、この制御プログラム内で用いられる設定値や初期値などのデータを書き換える場合も含まれるものとする。ここで、複数の制御プログラムとは、制御対象が同系列の制御プログラム、換言すれば、制御対象が同じ又は互いに関連性を有する制御プログラムである。
更にまた、ＥＣＭが燃料噴射弁、ＶＴＣ機構及び点火モジュールなどを制御する例について説明したが、車両に搭載された各種の機器、例えば変速機、電動ブレーキシステム、ＡＢＳ（Antilock Brake System）、及びブラシレスモータなどを制御する電子制御装置にも同様に適用できる。

１０…車両、２０…エンジン、３０…ＥＣＭ（車両用電子制御装置）、３１…センサ、３２…アクチュエータ、３３…プロセッサ、３４…ＲＡＭ、３５…ＲＯＭ、３６…ＥＥＰＲＯＭ（不揮発性メモリ）、３７…入出力インターフェース、３８…外部通信インターフェース、３９…バス、４０…ネットワークケーブル、５０…リプログラミングツール、６０…外部ツール

Claims (3)

1. プログラムを外部から書き換え可能に構成された電子制御装置であって、
   書き換え前の複数の制御プログラム間及び書き換え後の制御プログラム間で共通し、且つ前記書き換え前の制御プログラムと前記書き換え後の制御プログラムに依存しない管理ナンバーを、車両の動作中に生じた故障コードに対応させて記憶し、
   前記複数の制御プログラムの少なくとも１つを書き換えた後に、記憶した前記管理ナンバーから前記少なくとも１つの書き換えた制御プログラムに依存するインデックスを参照し、当該インデックスに基づき前記故障コードを出力して外部ツールの表示に用いる、ことを特徴とする車両用電子制御装置。
2. 記憶される前記管理ナンバーは、車両の動作中に生じた前記故障コードから前記インデックスを参照し、前記インデックスから前記管理ナンバーを参照して記憶するものである、ことを特徴とする請求項１に記載の車両用電子制御装置。
3. 前記書き換え前の複数の制御プログラムは、制御対象が同じ又は互いに関連性を有する、ことを特徴とする請求項１又は２に記載の車両用電子制御装置。

Images