【０００１】
【発明の属する技術分野】
本発明は、複数の電子制御ユニット（ＥＣＵ）が通信ラインを介して接続されてなる車両制御システムに関するものである。
【０００２】
【従来の技術】
従来より、車両部品等が故障した際の故障解析を容易にするために、車両用のドライブレコーダ技術が提案されている。すなわち、車載ＥＣＵのメモリの一部にドライブレコーダを設け、或いは車載ＥＣＵにドライブレコーダを接続し、このドライブレコーダに故障発生時のエンジン回転数や水温など各種の車両情報を記憶するようにしている（例えば特開平７−１７２２５１号公報）。
【０００３】
【発明が解決しようとする課題】
しかしながら上記従来技術では、ドライブレコーダのメモリサイズにより記憶容量が限定されるという問題がある。つまり、車載ＥＣＵのメモリサイズによって記憶できる項目が決まってしまうため、欲しい情報が制限され、故障解析が困難になったり、極端な場合はドライブレコーダ機能そのものを廃止しなければならなくなる。また、車載ＥＣＵとは別にドライブレコーダを設ける場合であっても、コスト上メモリサイズには制約があり、やはり記憶できる項目が制限されるという問題が生じる。
【０００４】
近年の車両制御システムでは、ＣＡＮ通信ライン等を介して多数のＥＣＵが相互に通信可能に接続されており、故障診断の対象項目が増え、更にそれに付される車両情報が益々増える傾向にある。それ故、増加傾向にある多くの情報を支障なく記憶保持することが可能な構成が望まれている。
【０００５】
本発明は上記問題に着目してなされたものであって、その目的とするところは、記憶可能な情報量を増やし、ひいては車両制御の状態を適正に管理することができる車両制御システムを提供することである。
【０００６】
【課題を解決するための手段】
請求項１に記載の車両制御システムでは、通信ラインを介して相互に通信可能に接続された複数の電子制御ユニットを備える。そして特に、各電子制御ユニットが有するメモリの共有可能な領域を少なくとも１つの電子制御ユニットが管理テーブル上で管理し、管理主体となる電子制御ユニットは時系列的に発生する各種情報を、前記管理テーブルに基づき何れかの電子制御ユニットに順次振り分けて格納する。
【０００７】
本発明によれば、通信ライン上にある各電子制御ユニットのメモリを随時用いることが可能となり、記憶可能な情報量を大幅に増やすことができる。また、１つの電子制御ユニットが管理主体となり、各メモリの共有可能な領域を管理テーブル上で管理し、更に時系列情報を順次振り分けて格納するため、車両制御の状態を適正に管理することができる。
【０００８】
請求項２に記載の発明では、各電子制御ユニットが有するメモリの共有可能な領域はユニット毎に優先順位が予め決められており、前記管理テーブルには各ユニットの優先順位に従いメモリの記憶順序が定められている。これにより、数多くの電子制御ユニットが存在する場合にも、各種情報の振り分け先を適正に管理できる。
【０００９】
請求項３に記載の発明では、各電子制御ユニットはその起動時に、共有可能なメモリ容量を前記管理主体の電子制御ユニットに送信し、前記管理主体の電子制御ユニットは、他ユニットから受信した共有可能なメモリ容量に基づき前記管理テーブルを作成する。この場合、その都度の各電子制御ユニットの状態に則して適正な管理テーブルが作成できる。
【００１０】
車載機器等の故障時には、故障情報と共にその際の車両情報を記憶保持する必要がある。そこで、請求項４に記載したように、前記電子制御ユニットは各自に車載機器等の故障診断を実施し、故障情報及びその際の車両情報を、前記管理テーブルに基づきその都度記憶対象となる電子制御ユニットのメモリに記憶すると良い。この場合、上記の如く記憶可能な情報量（ここでは特に車両故障に関する情報量）を大幅に増やすことができるため、以後の故障解析がしやすくなるという利点が得られる。
【００１１】
前記メモリは、請求項５に記載したように、常時電源バックアップされたスタンバイＲＡＭ或いは電気的に書き込み及び消去可能な不揮発性メモリであると良い。
【００１２】
【発明の実施の形態】
以下、本発明を具体化した一実施の形態を図面に従って説明する。本実施の形態は、ＣＡＮ通信を採用した車両制御システムに具体化するものであり、図１は、本実施の形態における車両制御システムの概要を示す構成図である。
【００１３】
図１に示すように、ＣＡＮ通信ライン１００には、エンジンＥＣＵ１０，ＡＢＳ＿ＥＣＵ２０，メータＥＣＵ３０が接続されており、これら各ＥＣＵ１０〜３０は、ＣＡＮ通信ライン１００を介して相互に通信可能となっている。ＣＡＮ通信ライン１００上には、他にもトランスミッションＥＣＵ、ドアＥＣＵ、イモビＥＣＵなど、多くの電子制御ユニットが接続されるが、便宜上ここでは上記３つのＥＣＵ１０〜３０を例示し説明する。各ＥＣＵ１０〜３０には故障診断情報等を格納するためのメモリ１１，２１，３１が搭載されている。メモリ１１〜３１は、常時電源バックアップされたスタンバイＲＡＭ或いは電気的に書き込み及び消去可能なＥＥＰＲＯＭ等の不揮発性メモリにて構成され、その記憶内容は、各ＥＣＵ１０〜３０への電源遮断後も記憶保持されるようになっている。
【００１４】
各ＥＣＵ１０〜３０では、それぞれに故障診断処理が実施される。この場合、故障有りと診断された時には、その時の車両情報（エンジン回転数、水温、アクセル開度等）が検出される。そして、故障情報と車両情報とが車両故障情報として何れかのメモリ１１〜３１に記憶保持されるようになっている。ここで、各ＥＣＵのメモリ１１〜３１には共有可能な領域がそれぞれ設定されており、その共有可能な領域を用い各ＥＣＵで得られた車両故障情報が記憶保持されることとなる。なお以下の説明では便宜上、各メモリでの共有可能な領域を「空き領域」として記載する。
【００１５】
次に、各ＥＣＵ１０〜３０での車両故障情報を何れかのＥＣＵのメモリ１１〜３１に格納するための手順を説明する。特に本実施の形態では、エンジンＥＣＵ１０をマスタＥＣＵ（管理主体の電子制御ユニット）としており、基本的にはこのエンジンＥＣＵ１０に全ＥＣＵの車両故障情報が記憶される。また、エンジンＥＣＵ１０においてメモリ１１の空き領域が無くなると、次にエンジンＥＣＵ１０以外のＥＣＵ（ＡＢＳ＿ＥＣＵ２０，メータＥＣＵ３０等）のメモリに車両故障情報が記憶されるようになっている。この際、エンジンＥＣＵ１０は、他ＥＣＵの空き領域（共有可能なメモリ領域）を管理テーブル上で管理し、その管理テーブルに基づきその都度の車両故障情報を各ＥＣＵのメモリに割り振って記憶させるようにしている。
【００１６】
車両のイグニッションスイッチのＯＮ操作に伴う各ＥＣＵ１０〜３０への電源投入時において、エンジンＥＣＵ１０以外の各ＥＣＵ（図１ではＡＢＳ＿ＥＣＵ２０，メータＥＣＵ３０）は図２の処理を実行し、エンジンＥＣＵ１０は図３の処理を実行する。すなわち、図２は、エンジンＥＣＵ１０以外の各ＥＣＵによるメモリ空き領域の送信処理を示すフローチャートであり、図３は、エンジンＥＣＵ１０による管理テーブルの作成処理を示すフローチャートである。
【００１７】
図２において、先ずステップ１０１では、自身のメモリに空き領域（共有可能な領域）が有るか否かを判別する。空き領域有りの場合、ステップ１０２に進み、その空き容量を空き領域情報として一時記憶する。また、空き領域無しの場合、ステップ１０３に進み、空き無しのデータを空き領域情報として一時記憶する。
【００１８】
その後、ステップ１０４では、自ＥＣＵ固有のＩＤコードと空き領域情報とを送信データとし、続くステップ１０５では、当該送信データをＣＡＮ通信ライン１００を介してエンジンＥＣＵ１０に送信する。
【００１９】
また、図３において、エンジンＥＣＵ１０は、ステップ２０１で他ＥＣＵ（ＡＢＳ＿ＥＣＵ２０，メータＥＣＵ３０等）からのメモリの空き領域情報を受信したか否かを判別し、受信したことを条件に、ステップ２０２で管理テーブルを作成する。
【００２０】
管理テーブルは一例として図６の形式にて構成され、この管理テーブルによれば、各ＥＣＵ毎の空き容量に応じて設けられた車両故障情報の格納エリアが一覧で管理される。図６には、ＩＤコード「０１００」であるＡＢＳ＿ＥＣＵ２０とＩＤコード「０２００」であるメータＥＣＵ３０について記憶Ｎｏ．１〜５の格納エリアが設定されていることを示す。このとき、管理テーブル内の記憶Ｎｏ．はデータ格納の優先順位を示し、これは各ＥＣＵのＩＤコードが小さいものから順に決められている。なお図６中、記憶Ｎｏ．１，２については該当する記憶情報が既に格納されていることを示す（図の丸印）。
【００２１】
また、エンジンＥＣＵ１０は、故障発生の都度又は所定の時間周期で図４に示す車両故障情報の格納処理を実施する。図４において、先ずステップ３０１では、故障検出したか否かを判別する。当該エンジンＥＣＵ１０で故障有りと検出された時にステップ３０１がＹＥＳになり、後続のステップ３０２に進む。またその他に、他ＥＣＵで故障検出され、その際の車両故障情報をエンジンＥＣＵ１０が受信した時もステップ３０１がＹＥＳになる。
【００２２】
ステップ３０２では、その故障発生時において該当する故障フラグを通常ＲＡＭに記憶する他、エンジン回転数、水温、アクセル開度等の車両情報を通常ＲＡＭに記憶する。
【００２３】
その後、ステップ３０３では、自ＥＣＵ（エンジンＥＣＵ１０）のメモリ１１に空き領域が有るか否かを判別する。空き領域が有れば、ステップ３０４に進みメモリ１１に車両故障情報（故障フラグ＋車両情報）を記憶する。
【００２４】
また、メモリ１１に空き領域が無ければ、ステップ３０５に進む。ステップ３０５では、図６の管理テーブルを検索して記憶対象となるＥＣＵ（対象ＥＣＵ）を選択する。続くステップ３０６では、対象ＥＣＵのＩＤコードと車両故障状態（故障フラグ＋車両情報）とを送信データとし、その送信データを送信する。
【００２５】
更に、エンジンＥＣＵ１０以外の各ＥＣＵは、故障情報受信の都度又は所定の時間周期で図５に示す車両故障情報の格納処理を実施する。図５において、ステップ４０１では、エンジンＥＣＵ１０から車両故障情報を受信したか否かを判別する。このとき、受信データ中のＩＤコード（前記図４で送信データとして付されたＥＣＵ毎のＩＤ）が参照される。車両故障情報を受信した場合、ステップ４０２で自身の空き領域の有無を判別し、空き領域有りの場合、当該車両故障情報を自身のメモリに記憶する。
【００２６】
図４及び図５の処理によれば、エンジンＥＣＵ１０でメモリ領域が不足する場合において、その不足を補うべく管理テーブルの優先順位に則して他ＥＣＵのメモリに車両故障情報が順次格納される。このとき、エンジンＥＣＵ１０では、管理テーブルにおいて記憶済みである旨のチェックがなされる（図６中の丸印）。つまり、時系列的に発生する車両故障情報は各ＥＣＵのメモリに随時振り分けて格納され、該格納された場合その経歴のみがエンジンＥＣＵ１０の管理テーブルで管理されることとなる。
【００２７】
車両故障情報が格納された以後、故障診断ツールから車両故障情報の読み出し要求があると、エンジンＥＣＵ１０により管理テーブルが参照されて必要なデータがデータ格納場所（各ＥＣＵのメモリ）から適宜読み出される。そして、エンジンＥＣＵ１０を通じて故障診断ツールへ情報が送信される。
【００２８】
因みに、各ＥＣＵのメモリに格納された記憶情報を、故障診断ツールから削除できる構成としても良く、不要なデータを削除することによりメモリの記憶領域を拡大することが可能となる。
【００２９】
以上詳述した本実施の形態によれば、以下に示す効果が得られる。
ＣＡＮ通信ライン１００上にある各ＥＣＵのメモリ１１〜３１を随時用いることが可能となり、記憶可能な情報量を大幅に増やすことができる。また、エンジンＥＣＵ１０が管理主体となり、各メモリの共有可能な領域を管理テーブル上で管理し、更に時系列情報を順次振り分けて格納するため、車両制御の状態を適正に管理することができる。特に本実施の形態では、車両故障に関する情報量を大幅に増やすことができるため、以後の故障解析がしやすくなるという利点が得られる。これにより、故障解析の精度向上を図ることも可能となる。
【００３０】
管理テーブルには各ＥＣＵの優先順位に従いメモリの記憶順序が定められているため、数多くのＥＣＵが存在する場合にも、車両故障情報の振り分け先を適正に管理できる。
【００３１】
各ＥＣＵはその起動時において、空き容量をエンジンＥＣＵ１０に送信し、エンジンＥＣＵ１０は他ＥＣＵの空き容量に基づき管理テーブルを作成するため、その都度の各ＥＣＵの状態に則して適正な管理テーブルが作成できる。仮に、何らかの原因により各ＥＣＵ空き容量が変化したとしても、その変化に対処しつつ管理テーブルの作成が可能となる。
【００３２】
なお本発明は、上記以外に次の形態にて具体化できる。
上記実施の形態では、ＥＣＵ起動時に管理テーブルを作成することとしたが、これを変更しても良い。管理テーブルを一度作成したら、特に指示がない限り再度作成しないようにしても良い。また、車両の出荷前等において、予め特定のＥＣＵ（管理主体のＥＣＵ）に管理テーブルを作成しておくようにしても良い。
【００３３】
前記図６に示す管理テーブルに関して、「記憶内容」のデータを簡略化するか若しくは削除し、当該管理テーブルとしてのデータ縮小化を図るようにしても良い。例えば、「記憶内容」のデータとして故障フラグのみを記憶する。管理テーブルとして、少なくとも記憶対象のＥＣＵ、記憶Ｎｏ．、記憶済みの確認データを有するものであれば良い。また、信頼性を向上させるべく、この管理テーブルを２つのＥＣＵで記憶しておくことも可能である。
【００３４】
上記実施の形態では、車両の故障情報を記憶するために各ＥＣＵの共有可能な領域を使用したが、故障情報以外の情報を記憶するために各ＥＣＵの共有可能な領域を使用することも可能である。
【図面の簡単な説明】
【図１】発明の実施の形態における車両制御システムの概要を示す構成図。
【図２】メモリ空き領域の送信処理を示すフローチャート。
【図３】管理テーブルの作成処理を示すフローチャート。
【図４】車両故障情報の格納処理を示すフローチャート。
【図５】車両故障情報の格納処理を示すフローチャート。
【図６】管理テーブルを示す図。
【符号の説明】
１０…エンジンＥＣＵ、２０…ＡＢＳ＿ＥＣＵ、３０…メータＥＣＵ、１１〜３１…メモリ、１００…ＣＡＮ通信ライン。[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a vehicle control system in which a plurality of electronic control units (ECUs) are connected via a communication line.
[0002]
[Prior art]
2. Description of the Related Art Conventionally, a drive recorder technology for a vehicle has been proposed in order to facilitate failure analysis when a vehicle component or the like fails. That is, a drive recorder is provided in a part of the memory of the in-vehicle ECU, or a drive recorder is connected to the in-vehicle ECU, and this drive recorder stores various kinds of vehicle information such as an engine speed and a water temperature when a failure occurs. (For example, JP-A-7-172251).
[0003]
[Problems to be solved by the invention]
However, the above-described conventional technique has a problem that the storage capacity is limited by the memory size of the drive recorder. In other words, the items that can be stored are determined by the memory size of the vehicle-mounted ECU, so that desired information is limited, failure analysis becomes difficult, and in extreme cases, the drive recorder function itself must be abolished. Further, even when a drive recorder is provided separately from the in-vehicle ECU, there is a problem that the memory size is limited due to the cost, and the items that can be stored are also limited.
[0004]
In recent vehicle control systems, a large number of ECUs are communicably connected to each other via a CAN communication line or the like, so that the number of target items for failure diagnosis increases, and the vehicle information attached thereto tends to increase. Therefore, there is a demand for a configuration capable of storing and holding a large amount of information that tends to increase without any trouble.
[0005]
SUMMARY OF THE INVENTION The present invention has been made in view of the above problems, and an object of the present invention is to provide a vehicle control system capable of increasing the amount of information that can be stored and appropriately managing the state of vehicle control. That is.
[0006]
[Means for Solving the Problems]
The vehicle control system according to the first aspect includes a plurality of electronic control units communicably connected to each other via a communication line. In particular, at least one electronic control unit manages a sharable area of a memory of each electronic control unit on a management table, and an electronic control unit serving as a management subject manages various kinds of information generated in chronological order. The information is sequentially sorted and stored in any one of the electronic control units based on the table.
[0007]
According to the present invention, the memory of each electronic control unit on the communication line can be used at any time, and the amount of storable information can be greatly increased. In addition, since one electronic control unit serves as a management entity, a sharable area of each memory is managed on a management table, and time-series information is sequentially sorted and stored, so that the state of vehicle control can be appropriately managed. it can.
[0008]
According to the second aspect of the present invention, the sharable area of the memory of each electronic control unit has a priority determined in advance for each unit, and the management table stores the storage order of the memory according to the priority of each unit. Stipulated. Thereby, even when there are a large number of electronic control units, the distribution destination of various information can be properly managed.
[0009]
In the invention according to claim 3, each electronic control unit transmits a sharable memory capacity to the electronic control unit of the managing entity at the time of activation, and the electronic control unit of the managing entity transmits the shared memory capacity received from another unit. The management table is created based on a possible memory capacity. In this case, an appropriate management table can be created in accordance with the state of each electronic control unit at each time.
[0010]
When a failure occurs in an in-vehicle device or the like, it is necessary to store the vehicle information at that time together with the failure information. Therefore, as described in claim 4, each of the electronic control units individually performs a failure diagnosis of the in-vehicle device or the like, and the failure information and the vehicle information at that time are stored in the electronic control unit based on the management table. It may be stored in the memory of the control unit. In this case, as described above, the amount of information that can be stored (in particular, the amount of information relating to vehicle failures) can be significantly increased, so that there is an advantage that subsequent failure analysis becomes easier.
[0011]
The memory may be a standby RAM that is always backed up by a power supply or an electrically writable and erasable non-volatile memory.
[0012]
BEST MODE FOR CARRYING OUT THE INVENTION
An embodiment of the present invention will be described below with reference to the drawings. The present embodiment is embodied in a vehicle control system that employs CAN communication. FIG. 1 is a configuration diagram illustrating an outline of a vehicle control system according to the present embodiment.
[0013]
As shown in FIG. 1, an engine ECU 10, an ABS_ECU 20, and a meter ECU 30 are connected to the CAN communication line 100, and these ECUs 10 to 30 can communicate with each other via the CAN communication line 100. Many other electronic control units such as a transmission ECU, a door ECU, and an immobilizer ECU are connected to the CAN communication line 100. For convenience, the three ECUs 10 to 30 will be exemplified and described. Each of the ECUs 10 to 30 has memories 11, 21, and 31 for storing failure diagnosis information and the like. The memories 11 to 31 are constituted by a non-volatile memory such as a standby RAM which is always backed up by a power supply or an electrically erasable and erasable EEPROM, and the stored contents are retained even after the power supply to the ECUs 10 to 30 is cut off. It is supposed to be.
[0014]
Each of the ECUs 10 to 30 performs a failure diagnosis process. In this case, when it is diagnosed that a failure has occurred, vehicle information (engine speed, water temperature, accelerator opening, etc.) at that time is detected. Then, the failure information and the vehicle information are stored and held in one of the memories 11 to 31 as the vehicle failure information. Here, sharable areas are set in the memories 11 to 31 of each ECU, and vehicle failure information obtained by each ECU is stored and held using the sharable areas. In the following description, a sharable area in each memory is described as a “free area” for convenience.
[0015]
Next, a procedure for storing vehicle failure information in each of the ECUs 10 to 30 in the memory 11 to 31 of any one of the ECUs will be described. In particular, in the present embodiment, the engine ECU 10 is a master ECU (electronic control unit mainly for management), and the engine ECU 10 basically stores vehicle failure information of all ECUs. When the free area of the memory 11 is exhausted in the engine ECU 10, the vehicle failure information is stored in the memory of an ECU (ABS_ECU 20, meter ECU 30, etc.) other than the engine ECU 10 next. At this time, the engine ECU 10 manages an empty area (a sharable memory area) of another ECU on a management table, and allocates and stores vehicle failure information in each ECU's memory based on the management table. ing.
[0016]
When power is supplied to each of the ECUs 10 to 30 when the ignition switch of the vehicle is turned on, the ECUs other than the engine ECU 10 (the ABS_ECU 20 and the meter ECU 30 in FIG. 1) execute the processing in FIG. Execute the process. That is, FIG. 2 is a flowchart showing a process of transmitting a free memory area by each ECU other than the engine ECU 10, and FIG. 3 is a flowchart showing a process of creating a management table by the engine ECU 10.
[0017]
In FIG. 2, first, in step 101, it is determined whether or not there is a free area (an area that can be shared) in its own memory. If there is a free space, the process proceeds to step 102, and the free space is temporarily stored as free space information. If there is no free space, the process proceeds to step 103, and the data with no free space is temporarily stored as free space information.
[0018]
Thereafter, in step 104, the ID code unique to the own ECU and the free area information are used as transmission data, and in the following step 105, the transmission data is transmitted to the engine ECU 10 via the CAN communication line 100.
[0019]
In FIG. 3, the engine ECU 10 determines whether or not memory free area information has been received from another ECU (ABS_ECU 20, meter ECU 30, etc.) in step 201, and manages the information in step 202 on condition that the information is received. Create a table.
[0020]
As an example, the management table is configured in the format shown in FIG. 6, and according to this management table, storage areas for vehicle failure information provided according to the free capacity of each ECU are managed in a list. FIG. 6 shows the storage numbers of the ABS_ECU 20 having the ID code “0100” and the meter ECU 30 having the ID code “0200”. Indicates that storage areas 1 to 5 have been set. At this time, the storage No. in the management table. Indicates the data storage priority, which is determined in ascending order of the ID code of each ECU. Note that in FIG. 1 and 2 indicate that the corresponding storage information has already been stored (circles in the figure).
[0021]
Further, the engine ECU 10 performs the storage processing of the vehicle failure information shown in FIG. 4 every time a failure occurs or at a predetermined time period. In FIG. 4, first, in step 301, it is determined whether a failure has been detected. When the engine ECU 10 detects that there is a failure, step 301 becomes YES, and the routine proceeds to the subsequent step 302. In addition, when a failure is detected by another ECU and the vehicle failure information at that time is received by the engine ECU 10, step 301 becomes YES.
[0022]
In step 302, the fault flag corresponding to the occurrence of the fault is stored in the normal RAM, and vehicle information such as the engine speed, the water temperature, and the accelerator opening is stored in the normal RAM.
[0023]
Thereafter, in step 303, it is determined whether or not there is an empty area in the memory 11 of the own ECU (engine ECU 10). If there is an empty area, the process proceeds to step 304, where vehicle failure information (failure flag + vehicle information) is stored in the memory 11.
[0024]
If there is no free area in the memory 11, the process proceeds to step 305. In step 305, the control table in FIG. 6 is searched to select an ECU (target ECU) to be stored. In the following step 306, the ID code of the target ECU and the vehicle failure state (failure flag + vehicle information) are used as transmission data, and the transmission data is transmitted.
[0025]
Further, each ECU other than the engine ECU 10 executes the process of storing the vehicle failure information shown in FIG. 5 each time the failure information is received or at a predetermined time period. In FIG. 5, in step 401, it is determined whether or not vehicle failure information has been received from the engine ECU 10. At this time, the ID code (ID for each ECU assigned as the transmission data in FIG. 4) in the reception data is referred to. If the vehicle failure information is received, it is determined in step 402 whether or not there is a free area. If there is a free area, the vehicle failure information is stored in its own memory.
[0026]
According to the processes of FIGS. 4 and 5, when the engine ECU 10 has a shortage of memory area, vehicle failure information is sequentially stored in the memory of another ECU in accordance with the priority order of the management table to compensate for the shortage. At this time, the engine ECU 10 checks that the data has been stored in the management table (circles in FIG. 6). That is, the vehicle failure information generated in time series is distributed and stored in the memory of each ECU as needed, and when stored, only the history is managed in the management table of the engine ECU 10.
[0027]
After the vehicle failure information is stored, when there is a request to read the vehicle failure information from the failure diagnosis tool, the engine ECU 10 refers to the management table and appropriately reads necessary data from the data storage location (memory of each ECU). Then, the information is transmitted to the failure diagnosis tool through the engine ECU 10.
[0028]
Incidentally, the configuration may be such that the storage information stored in the memory of each ECU can be deleted from the failure diagnosis tool, and the storage area of the memory can be expanded by deleting unnecessary data.
[0029]
According to the embodiment described in detail above, the following effects can be obtained.
The memories 11 to 31 of the ECUs on the CAN communication line 100 can be used at any time, and the amount of information that can be stored can be greatly increased. Further, since the engine ECU 10 is a management entity, the sharable area of each memory is managed on the management table, and the time-series information is sequentially sorted and stored, so that the vehicle control state can be appropriately managed. In particular, in the present embodiment, since the amount of information relating to vehicle failure can be greatly increased, there is an advantage that subsequent failure analysis becomes easier. As a result, the accuracy of the failure analysis can be improved.
[0030]
Since the storage order of the memory is determined in the management table in accordance with the priority of each ECU, the destination of the vehicle failure information can be properly managed even when there are many ECUs.
[0031]
At the time of starting each ECU, the free capacity is transmitted to the engine ECU 10, and the engine ECU 10 creates a management table based on the free capacity of the other ECUs. Therefore, an appropriate management table is prepared in accordance with the state of each ECU at each time. Can be created. Even if the ECU free space changes for some reason, the management table can be created while coping with the change.
[0032]
The present invention can be embodied in the following modes other than the above.
In the above embodiment, the management table is created at the time of starting the ECU. However, the management table may be changed. Once the management table is created, it may not be created again unless otherwise specified. Further, a management table may be created in a specific ECU (ECU that is the managing entity) in advance before shipping the vehicle.
[0033]
Regarding the management table shown in FIG. 6, the data of “storage content” may be simplified or deleted, and the data as the management table may be reduced. For example, only a failure flag is stored as data of “storage content”. As the management table, at least the ECU to be stored, the storage No. It is sufficient if the data has the stored confirmation data. Further, in order to improve the reliability, the management table can be stored in two ECUs.
[0034]
In the above embodiment, the sharable area of each ECU is used to store the failure information of the vehicle, but the sharable area of each ECU may be used to store information other than the failure information. It is.
[Brief description of the drawings]
FIG. 1 is a configuration diagram showing an outline of a vehicle control system according to an embodiment of the invention.
FIG. 2 is a flowchart showing a process of transmitting a free memory area.
FIG. 3 is a flowchart illustrating a management table creation process.
FIG. 4 is a flowchart showing storage processing of vehicle failure information.
FIG. 5 is a flowchart showing storage processing of vehicle failure information.
FIG. 6 is a diagram showing a management table.
[Explanation of symbols]
10: engine ECU, 20: ABS_ECU, 30: meter ECU, 11 to 31: memory, 100: CAN communication line.
