(57)【要約】【課題】記憶可能な情報量を増やし、ひいては車両制御の状態を適正に管理すること。【解決手段】ＣＡＮ通信ライン１００には、エンジンＥＣＵ１０，ＡＢＳ＿ＥＣＵ２０，メータＥＣＵ３０が相互に通信可能に接続されている。エンジンＥＣＵ１０は、他ＥＣＵが有するメモリの共有可能な領域を管理テーブル上で管理する。そして、同エンジンＥＣＵ１０は、時系列的に発生する各種情報を、管理テーブルに基づき何れかのＥＣＵに順次振り分けて格納する。【選択図】　　　図１
2004038388.tif 000002
【特許請求の範囲】
【請求項１】
通信ラインを介して相互に通信可能に接続された複数の電子制御ユニットを備え、車両制御に関する各種情報を記憶保持するようにした車両制御システムにおいて、
各電子制御ユニットが有するメモリの共有可能な領域を少なくとも１つの電子制御ユニットが管理テーブル上で管理し、管理主体となる電子制御ユニットは時系列的に発生する各種情報を、前記管理テーブルに基づき何れかの電子制御ユニットに順次振り分けて格納することを特徴とする車両制御システム。
【請求項２】
各電子制御ユニットが有するメモリの共有可能な領域はユニット毎に優先順位が予め決められており、前記管理テーブルには各ユニットの優先順位に従いメモリの記憶順序が定められている請求項１記載の車両制御システム。
【請求項３】
各電子制御ユニットはその起動時に、共有可能なメモリ容量を前記管理主体の電子制御ユニットに送信し、前記管理主体の電子制御ユニットは、他ユニットから受信した共有可能なメモリ容量に基づき前記管理テーブルを作成する請求項１又は２記載の車両制御システム。
【請求項４】
前記電子制御ユニットは各自に車載機器等の故障診断を実施し、故障情報及びその際の車両情報を、前記管理テーブルに基づきその都度記憶対象となる電子制御ユニットのメモリに記憶する請求項１乃至３の何れかに記載の車両制御システム。
【請求項５】
前記メモリは、常時電源バックアップされたスタンバイＲＡＭ或いは電気的に書き込み及び消去可能な不揮発性メモリである請求項１乃至４の何れかに記載の車両制御システム。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、複数の電子制御ユニット（ＥＣＵ）が通信ラインを介して接続されてなる車両制御システムに関するものである。
【０００２】
【従来の技術】
従来より、車両部品等が故障した際の故障解析を容易にするために、車両用のドライブレコーダ技術が提案されている。すなわち、車載ＥＣＵのメモリの一部にドライブレコーダを設け、或いは車載ＥＣＵにドライブレコーダを接続し、このドライブレコーダに故障発生時のエンジン回転数や水温など各種の車両情報を記憶するようにしている（例えば特開平７−１７２２５１号公報）。
【０００３】
【発明が解決しようとする課題】
しかしながら上記従来技術では、ドライブレコーダのメモリサイズにより記憶容量が限定されるという問題がある。つまり、車載ＥＣＵのメモリサイズによって記憶できる項目が決まってしまうため、欲しい情報が制限され、故障解析が困難になったり、極端な場合はドライブレコーダ機能そのものを廃止しなければならなくなる。また、車載ＥＣＵとは別にドライブレコーダを設ける場合であっても、コスト上メモリサイズには制約があり、やはり記憶できる項目が制限されるという問題が生じる。
【０００４】
近年の車両制御システムでは、ＣＡＮ通信ライン等を介して多数のＥＣＵが相互に通信可能に接続されており、故障診断の対象項目が増え、更にそれに付される車両情報が益々増える傾向にある。それ故、増加傾向にある多くの情報を支障なく記憶保持することが可能な構成が望まれている。
【０００５】
本発明は上記問題に着目してなされたものであって、その目的とするところは、記憶可能な情報量を増やし、ひいては車両制御の状態を適正に管理することができる車両制御システムを提供することである。
【０００６】
【課題を解決するための手段】
請求項１に記載の車両制御システムでは、通信ラインを介して相互に通信可能に接続された複数の電子制御ユニットを備える。そして特に、各電子制御ユニットが有するメモリの共有可能な領域を少なくとも１つの電子制御ユニットが管理テーブル上で管理し、管理主体となる電子制御ユニットは時系列的に発生する各種情報を、前記管理テーブルに基づき何れかの電子制御ユニットに順次振り分けて格納する。
【０００７】
本発明によれば、通信ライン上にある各電子制御ユニットのメモリを随時用いることが可能となり、記憶可能な情報量を大幅に増やすことができる。また、１つの電子制御ユニットが管理主体となり、各メモリの共有可能な領域を管理テーブル上で管理し、更に時系列情報を順次振り分けて格納するため、車両制御の状態を適正に管理することができる。
【０００８】
請求項２に記載の発明では、各電子制御ユニットが有するメモリの共有可能な領域はユニット毎に優先順位が予め決められており、前記管理テーブルには各ユニットの優先順位に従いメモリの記憶順序が定められている。これにより、数多くの電子制御ユニットが存在する場合にも、各種情報の振り分け先を適正に管理できる。
【０００９】
請求項３に記載の発明では、各電子制御ユニットはその起動時に、共有可能なメモリ容量を前記管理主体の電子制御ユニットに送信し、前記管理主体の電子制御ユニットは、他ユニットから受信した共有可能なメモリ容量に基づき前記管理テーブルを作成する。この場合、その都度の各電子制御ユニットの状態に則して適正な管理テーブルが作成できる。
【００１０】
車載機器等の故障時には、故障情報と共にその際の車両情報を記憶保持する必要がある。そこで、請求項４に記載したように、前記電子制御ユニットは各自に車載機器等の故障診断を実施し、故障情報及びその際の車両情報を、前記管理テーブルに基づきその都度記憶対象となる電子制御ユニットのメモリに記憶すると良い。この場合、上記の如く記憶可能な情報量（ここでは特に車両故障に関する情報量）を大幅に増やすことができるため、以後の故障解析がしやすくなるという利点が得られる。
【００１１】
前記メモリは、請求項５に記載したように、常時電源バックアップされたスタンバイＲＡＭ或いは電気的に書き込み及び消去可能な不揮発性メモリであると良い。
【００１２】
【発明の実施の形態】
以下、本発明を具体化した一実施の形態を図面に従って説明する。本実施の形態は、ＣＡＮ通信を採用した車両制御システムに具体化するものであり、図１は、本実施の形態における車両制御システムの概要を示す構成図である。
【００１３】
図１に示すように、ＣＡＮ通信ライン１００には、エンジンＥＣＵ１０，ＡＢＳ＿ＥＣＵ２０，メータＥＣＵ３０が接続されており、これら各ＥＣＵ１０〜３０は、ＣＡＮ通信ライン１００を介して相互に通信可能となっている。ＣＡＮ通信ライン１００上には、他にもトランスミッションＥＣＵ、ドアＥＣＵ、イモビＥＣＵなど、多くの電子制御ユニットが接続されるが、便宜上ここでは上記３つのＥＣＵ１０〜３０を例示し説明する。各ＥＣＵ１０〜３０には故障診断情報等を格納するためのメモリ１１，２１，３１が搭載されている。メモリ１１〜３１は、常時電源バックアップされたスタンバイＲＡＭ或いは電気的に書き込み及び消去可能なＥＥＰＲＯＭ等の不揮発性メモリにて構成され、その記憶内容は、各ＥＣＵ１０〜３０への電源遮断後も記憶保持されるようになっている。
【００１４】
各ＥＣＵ１０〜３０では、それぞれに故障診断処理が実施される。この場合、故障有りと診断された時には、その時の車両情報（エンジン回転数、水温、アクセル開度等）が検出される。そして、故障情報と車両情報とが車両故障情報として何れかのメモリ１１〜３１に記憶保持されるようになっている。ここで、各ＥＣＵのメモリ１１〜３１には共有可能な領域がそれぞれ設定されており、その共有可能な領域を用い各ＥＣＵで得られた車両故障情報が記憶保持されることとなる。なお以下の説明では便宜上、各メモリでの共有可能な領域を「空き領域」として記載する。
【００１５】
次に、各ＥＣＵ１０〜３０での車両故障情報を何れかのＥＣＵのメモリ１１〜３１に格納するための手順を説明する。特に本実施の形態では、エンジンＥＣＵ１０をマスタＥＣＵ（管理主体の電子制御ユニット）としており、基本的にはこのエンジンＥＣＵ１０に全ＥＣＵの車両故障情報が記憶される。また、エンジンＥＣＵ１０においてメモリ１１の空き領域が無くなると、次にエンジンＥＣＵ１０以外のＥＣＵ（ＡＢＳ＿ＥＣＵ２０，メータＥＣＵ３０等）のメモリに車両故障情報が記憶されるようになっている。この際、エンジンＥＣＵ１０は、他ＥＣＵの空き領域（共有可能なメモリ領域）を管理テーブル上で管理し、その管理テーブルに基づきその都度の車両故障情報を各ＥＣＵのメモリに割り振って記憶させるようにしている。
【００１６】
車両のイグニッションスイッチのＯＮ操作に伴う各ＥＣＵ１０〜３０への電源投入時において、エンジンＥＣＵ１０以外の各ＥＣＵ（図１ではＡＢＳ＿ＥＣＵ２０，メータＥＣＵ３０）は図２の処理を実行し、エンジンＥＣＵ１０は図３の処理を実行する。すなわち、図２は、エンジンＥＣＵ１０以外の各ＥＣＵによるメモリ空き領域の送信処理を示すフローチャートであり、図３は、エンジンＥＣＵ１０による管理テーブルの作成処理を示すフローチャートである。
【００１７】
図２において、先ずステップ１０１では、自身のメモリに空き領域（共有可能な領域）が有るか否かを判別する。空き領域有りの場合、ステップ１０２に進み、その空き容量を空き領域情報として一時記憶する。また、空き領域無しの場合、ステップ１０３に進み、空き無しのデータを空き領域情報として一時記憶する。
【００１８】
その後、ステップ１０４では、自ＥＣＵ固有のＩＤコードと空き領域情報とを送信データとし、続くステップ１０５では、当該送信データをＣＡＮ通信ライン１００を介してエンジンＥＣＵ１０に送信する。
【００１９】
また、図３において、エンジンＥＣＵ１０は、ステップ２０１で他ＥＣＵ（ＡＢＳ＿ＥＣＵ２０，メータＥＣＵ３０等）からのメモリの空き領域情報を受信したか否かを判別し、受信したことを条件に、ステップ２０２で管理テーブルを作成する。
【００２０】
管理テーブルは一例として図６の形式にて構成され、この管理テーブルによれば、各ＥＣＵ毎の空き容量に応じて設けられた車両故障情報の格納エリアが一覧で管理される。図６には、ＩＤコード「０１００」であるＡＢＳ＿ＥＣＵ２０とＩＤコード「０２００」であるメータＥＣＵ３０について記憶Ｎｏ．１〜５の格納エリアが設定されていることを示す。このとき、管理テーブル内の記憶Ｎｏ．はデータ格納の優先順位を示し、これは各ＥＣＵのＩＤコードが小さいものから順に決められている。なお図６中、記憶Ｎｏ．１，２については該当する記憶情報が既に格納されていることを示す（図の丸印）。
【００２１】
また、エンジンＥＣＵ１０は、故障発生の都度又は所定の時間周期で図４に示す車両故障情報の格納処理を実施する。図４において、先ずステップ３０１では、故障検出したか否かを判別する。当該エンジンＥＣＵ１０で故障有りと検出された時にステップ３０１がＹＥＳになり、後続のステップ３０２に進む。またその他に、他ＥＣＵで故障検出され、その際の車両故障情報をエンジンＥＣＵ１０が受信した時もステップ３０１がＹＥＳになる。
【００２２】
ステップ３０２では、その故障発生時において該当する故障フラグを通常ＲＡＭに記憶する他、エンジン回転数、水温、アクセル開度等の車両情報を通常ＲＡＭに記憶する。
【００２３】
その後、ステップ３０３では、自ＥＣＵ（エンジンＥＣＵ１０）のメモリ１１に空き領域が有るか否かを判別する。空き領域が有れば、ステップ３０４に進みメモリ１１に車両故障情報（故障フラグ＋車両情報）を記憶する。
【００２４】
また、メモリ１１に空き領域が無ければ、ステップ３０５に進む。ステップ３０５では、図６の管理テーブルを検索して記憶対象となるＥＣＵ（対象ＥＣＵ）を選択する。続くステップ３０６では、対象ＥＣＵのＩＤコードと車両故障状態（故障フラグ＋車両情報）とを送信データとし、その送信データを送信する。
【００２５】
更に、エンジンＥＣＵ１０以外の各ＥＣＵは、故障情報受信の都度又は所定の時間周期で図５に示す車両故障情報の格納処理を実施する。図５において、ステップ４０１では、エンジンＥＣＵ１０から車両故障情報を受信したか否かを判別する。このとき、受信データ中のＩＤコード（前記図４で送信データとして付されたＥＣＵ毎のＩＤ）が参照される。車両故障情報を受信した場合、ステップ４０２で自身の空き領域の有無を判別し、空き領域有りの場合、当該車両故障情報を自身のメモリに記憶する。
【００２６】
図４及び図５の処理によれば、エンジンＥＣＵ１０でメモリ領域が不足する場合において、その不足を補うべく管理テーブルの優先順位に則して他ＥＣＵのメモリに車両故障情報が順次格納される。このとき、エンジンＥＣＵ１０では、管理テーブルにおいて記憶済みである旨のチェックがなされる（図６中の丸印）。つまり、時系列的に発生する車両故障情報は各ＥＣＵのメモリに随時振り分けて格納され、該格納された場合その経歴のみがエンジンＥＣＵ１０の管理テーブルで管理されることとなる。
【００２７】
車両故障情報が格納された以後、故障診断ツールから車両故障情報の読み出し要求があると、エンジンＥＣＵ１０により管理テーブルが参照されて必要なデータがデータ格納場所（各ＥＣＵのメモリ）から適宜読み出される。そして、エンジンＥＣＵ１０を通じて故障診断ツールへ情報が送信される。
【００２８】
因みに、各ＥＣＵのメモリに格納された記憶情報を、故障診断ツールから削除できる構成としても良く、不要なデータを削除することによりメモリの記憶領域を拡大することが可能となる。
【００２９】
以上詳述した本実施の形態によれば、以下に示す効果が得られる。
ＣＡＮ通信ライン１００上にある各ＥＣＵのメモリ１１〜３１を随時用いることが可能となり、記憶可能な情報量を大幅に増やすことができる。また、エンジンＥＣＵ１０が管理主体となり、各メモリの共有可能な領域を管理テーブル上で管理し、更に時系列情報を順次振り分けて格納するため、車両制御の状態を適正に管理することができる。特に本実施の形態では、車両故障に関する情報量を大幅に増やすことができるため、以後の故障解析がしやすくなるという利点が得られる。これにより、故障解析の精度向上を図ることも可能となる。
【００３０】
管理テーブルには各ＥＣＵの優先順位に従いメモリの記憶順序が定められているため、数多くのＥＣＵが存在する場合にも、車両故障情報の振り分け先を適正に管理できる。
【００３１】
各ＥＣＵはその起動時において、空き容量をエンジンＥＣＵ１０に送信し、エンジンＥＣＵ１０は他ＥＣＵの空き容量に基づき管理テーブルを作成するため、その都度の各ＥＣＵの状態に則して適正な管理テーブルが作成できる。仮に、何らかの原因により各ＥＣＵ空き容量が変化したとしても、その変化に対処しつつ管理テーブルの作成が可能となる。
【００３２】
なお本発明は、上記以外に次の形態にて具体化できる。
上記実施の形態では、ＥＣＵ起動時に管理テーブルを作成することとしたが、これを変更しても良い。管理テーブルを一度作成したら、特に指示がない限り再度作成しないようにしても良い。また、車両の出荷前等において、予め特定のＥＣＵ（管理主体のＥＣＵ）に管理テーブルを作成しておくようにしても良い。
【００３３】
前記図６に示す管理テーブルに関して、「記憶内容」のデータを簡略化するか若しくは削除し、当該管理テーブルとしてのデータ縮小化を図るようにしても良い。例えば、「記憶内容」のデータとして故障フラグのみを記憶する。管理テーブルとして、少なくとも記憶対象のＥＣＵ、記憶Ｎｏ．、記憶済みの確認データを有するものであれば良い。また、信頼性を向上させるべく、この管理テーブルを２つのＥＣＵで記憶しておくことも可能である。
【００３４】
上記実施の形態では、車両の故障情報を記憶するために各ＥＣＵの共有可能な領域を使用したが、故障情報以外の情報を記憶するために各ＥＣＵの共有可能な領域を使用することも可能である。
【図面の簡単な説明】
【図１】発明の実施の形態における車両制御システムの概要を示す構成図。
【図２】メモリ空き領域の送信処理を示すフローチャート。
【図３】管理テーブルの作成処理を示すフローチャート。
【図４】車両故障情報の格納処理を示すフローチャート。
【図５】車両故障情報の格納処理を示すフローチャート。
【図６】管理テーブルを示す図。
【符号の説明】
１０…エンジンＥＣＵ、２０…ＡＢＳ＿ＥＣＵ、３０…メータＥＣＵ、１１〜３１…メモリ、１００…ＣＡＮ通信ライン。
【図１】
2004038388.tif 000003
【図２】
2004038388.tif 000004
【図３】
2004038388.tif 000005
【図４】
2004038388.tif 000006
【図５】
2004038388.tif 000007
【図６】
2004038388.tif 000008