JP6020432B2 - 電子制御装置 - Google Patents

Description

本発明は、ネットワークを介してデータ通信可能に接続される電子制御装置に関する。

従来、車両に搭載された複数の電子制御装置が通信ラインを介して互いに通信可能に接続されている車両制御システムとして、車両側のコネクタを介して外部診断装置と接続可能に構成されているものが知られている（例えば、特許文献１を参照）。

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

外部診断装置と接続可能に構成されている車両制御システム内の特定の電子制御装置（以下、管理装置という）が、車両制御システム内の他の電子制御装置（以下、個別装置という）からデータを受信し、受信データに基づいて演算を行う場合に、以下のような問題が考えられる。

上記外部診断装置が、個別装置に対して、個別装置が演算した演算データを変更するデータ変更要求を発行した場合に、データ変更要求を受信した個別装置は、データ変更要求に従って演算データを変更する。一方、管理装置は、個別装置から演算データを順次受信している。そして、個別装置が演算データを送信してから管理装置が演算データを受信するまでには、通信ラインを介する通信に起因した遅延時間が存在する。このため管理装置は、個別装置から受信した演算データが、データ変更要求が発行された後のものであるか否かを判断することができず、受信データに基づいた演算を適切に行うことができないおそれがある。

本発明は、こうした問題に鑑みてなされたものであり、受信データがデータ変更要求の発行後のものであるか否かを判断した上で、受信データに基づいた演算を行うことができる技術を提供することを目的とする。

上記目的を達成するためになされた本発明の電子制御装置は、演算手段と、演算禁止手段と、禁止解除手段とを備える。
まず演算手段は、ネットワークを介してデータ通信可能に接続されるネットワークシステムを構成する複数の電子制御装置をそれぞれネットワーク構成装置として、複数のネットワーク構成装置の少なくとも１つから、ネットワークを介して、ネットワーク構成装置が演算した演算データを受信し、受信した演算データである受信演算データに基づいて演算を行う。

また演算禁止手段は、演算データを送信するネットワーク構成装置とは異なる電子制御装置である送信対象外装置から、ネットワークを介して、複数のネットワーク構成装置のうち少なくとも１つのネットワーク構成装置に対して演算データの変更を要求するデータ変更要求を受信すると、演算手段による演算を禁止する。

そして禁止解除手段は、複数のネットワーク構成装置から受信する受信演算データがデータ変更要求に従って変更された後のものであることを示す予め設定された変更済条件が成立すると、演算禁止手段による禁止を解除する。

このように構成された電子制御装置では、データ変更要求を受信すると、ネットワーク構成装置から受信した受信演算データに基づいた演算を禁止し、その後、受信演算データが変更された後のものであることを示す変更済条件が成立すると、演算の禁止を解除する。

このため、変更済条件が成立した後にネットワーク構成装置から受信した演算データは、データ変更要求に従って変更されたものであると判断することができる。これにより、ネットワーク構成装置から受信した演算データがデータ変更要求の発行後のものであるか否かを判断した上で、受信演算データに基づいた演算を行うことができる。

車両制御システム１の構成を示すブロック図である。 第１実施形態の待機状態設定処理を示すフローチャートである。 第１実施形態の統合処理を示すフローチャートである。 第１実施形態における車両制御システム１の動作を示すタイミングチャートである。 第２実施形態の待機状態設定処理を示すフローチャートである。 第２実施形態の統合処理を示すフローチャートである。 第２実施形態における車両制御システム１の動作を示す第１のタイミングチャートである。 第２実施形態における車両制御システム１の動作を示す第２のタイミングチャートである。 第２実施形態における車両制御システム１の動作を示す第３のタイミングチャートである。 車両制御システム１０１の構成を示すブロック図である。 第３実施形態の待機状態設定処理を示すフローチャートである。 第３実施形態の統合処理を示すフローチャートである。 車両制御システム１０１の動作を示す第１のタイミングチャートである。 車両制御システム１０１の動作を示す第２のタイミングチャートである。 車両制御システム１０１の動作を示す第３のタイミングチャートである。 車両制御システム１０１の動作を示す第４のタイミングチャートである。

（第１実施形態）
以下に本発明の第１実施形態を図面とともに説明する。
本実施形態の車両制御システム１は、車両に搭載され、図１に示すように、電子制御装置（Electronic Control Unit）２，３，４，５を備える。

電子制御装置２，３，４，５は、共通の通信ライン６を介して相互に通信可能となるように接続されている。
電子制御装置２，３，４，５は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ及びこれらの構成を接続するバスラインなどからなる周知のマイクロコンピュータを中心に構成されており、ＲＯＭに記憶されたプログラムに基づいて各種処理を実行する。

また電子制御装置２，３は、処理を実行することにより算出されたデータのうち車両制御システム１内で統合する必要があるデータとして予め設定された統合用個別データを、電子制御装置４へ送信する。なお 電子制御装置２，３が算出する統合用個別データは、オンまたはオフになるデータである。

また電子制御装置４は、処理を実行することにより算出されたデータのうち車両制御システム１内で統合する必要があるデータとして予め設定された統合用個別データと、電子制御装置２，３から受信した統合用個別データとを統合して、第１統合後データを算出する。なお、電子制御装置４が算出する統合用個別データは、オンまたはオフになるデータである。そして第１統合後データは、電子制御装置２，３，４の統合用個別データのうち少なくとも１つがオンである場合にオンになり、電子制御装置２，３，４の統合用個別データの全てがオフである場合にオフになる。

また電子制御装置４は、第２統合後データを算出する。第２統合後データは、第１統合後データがオンである場合にインクリメント（１加算）されるデータである。なお、第２統合後データがクリア（０に設定）される条件は後述する。

電子制御装置５は、個別トリガイベントまたは全体トリガイベントを発行する。具体的には、電子制御装置５は、個別トリガイベントまたは全体トリガイベントを示すトリガイベント情報を、通信ライン６を介して、電子制御装置２，３，４へ送信する。個別トリガイベントは、電子制御装置２，３，４の何れか１つに対して統合用個別データをクリアするイベントである。全体トリガイベントは、電子制御装置２，３，４の全てに対して統合用個別データをクリアするイベントである。

電子制御装置２，３，４は、電子制御装置５からトリガイベント情報を受信すると、トリガイベント情報に基づいて、全体トリガイベントであるか個別トリガイベントを判別するとともに、個別トリガイベントである場合には自装置を対象としたイベントであるか否かを判断する。

以下、電子制御装置２，３を個別ＥＣＵ２，３、電子制御装置４をマージＥＣＵ４、電子制御装置５をトリガＥＣＵ５という。
このように構成された車両制御システム１において、マージＥＣＵ４は、待機状態設定処理と統合処理を実行する。

まず、マージＥＣＵ４が実行する待機状態設定処理の手順を説明する。待機状態設定処理は、マージＥＣＵ４の動作中に繰り返し実行される処理である。
この待機状態設定処理が実行されると、マージＥＣＵ４は、図２に示すように、まずＳ１０にて、トリガイベントが発行されたか否かを判断する。ここで、トリガイベントが発行されていない場合には（Ｓ１０：ＮＯ）、待機状態設定処理を一旦終了する。一方、トリガイベントが発行された場合には（Ｓ１０：ＹＥＳ）、Ｓ２０にて、待機状態カウンタの値を、予め設定された通信遅延設定値（本実施形態では、例えば１．５秒に相当する値）に設定し、待機状態設定処理を一旦終了する。

次に、マージＥＣＵ４が実行する統合処理の手順を説明する。統合処理は、マージＥＣＵ４の動作中に繰り返し実行される処理である。
この統合処理が実行されると、マージＥＣＵ４は、図３に示すように、まずＳ１１０にて、待機状態カウンタの値が０より大きいか否かを判断する。ここで、待機状態カウンタの値が０より大きい場合には（Ｓ１１０：ＹＥＳ）、Ｓ１２０にて、待機状態カウンタをデクリメント（１減算）する。

そしてＳ１３０にて、待機状態カウンタの値が０であるか否かを判断する。ここで、待機状態カウンタの値が０より大きい場合には（Ｓ１３０：ＮＯ）、Ｓ１６０に移行する。一方、待機状態カウンタの値が０である場合には（Ｓ１３０：ＹＥＳ）、Ｓ１４０にて、第１統合後データを算出し、Ｓ１６０に移行する。具体的には、待機状態カウンタの値が０になってから新たに、個別ＥＣＵ２と個別ＥＣＵ３の両方から統合用個別データを取得し、取得した２つの統合用個別データと、マージＥＣＵ４が算出した最新の統合用個別データとを統合する。

またＳ１１０にて、待機状態カウンタの値が０である場合には（Ｓ１１０：ＮＯ）、Ｓ１５０にて、第１統合後データを算出して、Ｓ１６０に移行する。具体的には、これまでに個別ＥＣＵ２と個別ＥＣＵ３から取得した最新の統合用個別データと、マージＥＣＵ４が算出した最新の統合用個別データとを統合する。

そしてＳ１６０に移行すると、第２統合後データを算出して、統合処理を一旦終了する。具体的には、トリガイベントに起因して第１統合後データがオンからオフに更新された場合に、第２統合後データをクリアする。また、上記の場合以外には、第１統合後データがオフのときに第２統合後データを保持する一方、第１統合後データがオンのときに第２統合後データをインクリメント（１加算）する。

次に、このように構成された車両制御システム１の動作の具体例を説明する。
図４は、全体トリガイベントが発行された場合の動作を示すタイミングチャートである。なお図４では、説明の簡略化のために、個別ＥＣＵ２の統合用個別データとマージＥＣＵ４の統合用個別データとを統合して第１統合後データを算出するとして説明する。

図４に示すように、まず、マージＥＣＵ４が通常状態であり、マージＥＣＵ４と個別ＥＣＵ２の統合用個別データがそれぞれオンとオフであるとする（時刻ｔ０１を参照）。このため、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ０１を参照）。

その後、個別ＥＣＵ２の統合用個別データがオフからオンに変化する（時刻ｔ０２を参照）。そして、個別ＥＣＵ２からマージＥＣＵ４へ統合用個別データを送信するために要する遅延時間（以下、送信遅延時間という）が経過した後に、マージＥＣＵ４は、個別ＥＣＵ２の統合用個別データがオフからオンに変化したことを認識する（時刻ｔ０３を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ０３を参照）。

さらに、マージＥＣＵ４の統合用個別データがオンからオフに変化する（時刻ｔ０４を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ０４を参照）。

その後、全体トリガイベントが発行されると、待機状態カウンタの値が通信遅延設定値に設定されて、マージＥＣＵ４が通常状態から待機状態に変化する（時刻ｔ０５を参照）。また、個別ＥＣＵ２の統合用個別データがオンからオフに変化する（時刻ｔ０５を参照）。そして、上記送信遅延時間が経過した後に、マージＥＣＵ４は、個別ＥＣＵ２の統合用個別データがオンからオフに変化したことを認識する（時刻ｔ０６を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ０６を参照）。

その後、待機状態カウンタの値が０になると、マージＥＣＵ４が待機状態から通常状態に変化する（時刻ｔ０７を参照）。この時点で、マージＥＣＵ４と個別ＥＣＵ２の統合用個別データが両方ともオフであるため、第１統合後データがオンからオフに変化する（時刻ｔ０７を参照）。さらに、全体トリガイベントの発行に起因して第１統合後データがオンからオフに変化したため、第２統合後データがクリアされる（時刻ｔ０７を参照）。

その後、個別ＥＣＵ２の統合用個別データがオフからオンに変化する（時刻ｔ０８を参照）。そして、上記送信遅延時間が経過した後に、マージＥＣＵ４は、個別ＥＣＵ２の統合用個別データがオフからオンに変化したことを認識する（時刻ｔ０９を参照）。これにより、第１統合後データがオフからオンに変化し、第２統合後データは０からインクリメントを開始する（時刻ｔ０９を参照）。

さらに、マージＥＣＵ４の統合用個別データがオフからオンに変化する（時刻ｔ１０を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ１０を参照）。

その後、個別ＥＣＵ２の統合用個別データがオンからオフに変化する（時刻ｔ１１を参照）。そして、上記送信遅延時間が経過した後に、マージＥＣＵ４は、個別ＥＣＵ２の統合用個別データがオンからオフに変化したことを認識する（時刻ｔ１２を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ１２を参照）。

その後、マージＥＣＵ４の統合用個別データがオンからオフに変化する（時刻ｔ１３を参照）。これにより、この時点で、マージＥＣＵ４と個別ＥＣＵ２の統合用個別データが両方ともオフであるため、第１統合後データがオンからオフに変化する（時刻ｔ１３を参照）。そして、トリガイベントの発行に起因して第１統合後データがオンからオフに変化したのではないため、第２統合後データはクリアされず、第２統合後データの値が保持される（時刻ｔ１３を参照）。

このように構成されたマージＥＣＵ４では、まず、通信ライン６を介してデータ通信可能に接続される車両制御システム１を構成する個別ＥＣＵ２，３から、通信ライン６を介して、個別ＥＣＵ２，３が演算した統合用個別データを受信し、受信した統合用個別データと、マージＥＣＵ４が演算した統合用個別データとを統合して、第１統合後データを算出する（Ｓ１４０，Ｓ１５０）。

また、個別ＥＣＵ２，３とは異なる電子制御装置であるトリガＥＣＵ５から、通信ライン６を介して、統合用個別データのクリアを要求するトリガイベントを受信すると、第１統合後データの算出を禁止する（Ｓ１０，Ｓ２０，Ｓ１１０，Ｓ１３０）。

そして、個別ＥＣＵ２，３がトリガイベントに従って変更した統合用個別データを、通信ライン６を介して受信するまでに要する時間に基づいて設定された通信遅延設定値に対応する時間が経過すると（Ｓ１３０：ＹＥＳ）、第１統合後データの算出の禁止を解除する（Ｓ１３０）。

このようにマージＥＣＵ４では、トリガイベントを受信すると（Ｓ１０：ＹＥＳ）、個別ＥＣＵ２，３から受信した統合用個別データに基づいた演算を禁止し、その後、統合用個別データが変更された後のものであることを示す変更済条件が成立すると（Ｓ１３０：ＹＥＳ）、演算の禁止を解除する。

このため、変更済条件が成立した後に個別ＥＣＵ２，３から受信した統合用個別データは、トリガイベントに従って変更されたものであると判断することができる。これにより、個別ＥＣＵ２，３から受信した統合用個別データがトリガイベントの発行後のものであるか否かを判断した上で、受信した統合用個別データに基づいた演算を行うことができる。

また、通信遅延設定値に対応する時間が経過したか否かを判断するという簡便な方法で、受信した統合用個別データがトリガイベントの発行後のものであるか否かを判断することができる。

以上説明した実施形態において、車両制御システム１は本発明におけるネットワークシステム、マージＥＣＵ４は本発明における電子制御装置、個別ＥＣＵ２，３は本発明におけるネットワーク構成装置、トリガＥＣＵ５は本発明における送信対象外装置、Ｓ１４０，Ｓ１５０の処理は本発明における演算手段、Ｓ１０，Ｓ２０，Ｓ１１０，Ｓ１３０の処理は本発明における演算禁止手段、Ｓ１３０の処理は本発明における禁止解除手段である。

（第２実施形態）
以下に本発明の第２実施形態を図面とともに説明する。なお第２実施形態では、第１実施形態と異なる部分を説明する。

まず、第２実施形態の個別ＥＣＵ２，３は、トリガイベントに基づいて統合用個別データをオンからオフに変化させたときに、変更後の統合用個別データとともに反映許可情報を、マージＥＣＵ４へ送信する点が第１実施形態と異なる。

また、第２実施形態のマージＥＣＵ４は、待機状態設定処理と統合処理が変更された点が第１実施形態と異なる。
まず、第２実施形態のマージＥＣＵ４が実行する待機状態設定処理の手順を説明する。

この待機状態設定処理が実行されると、マージＥＣＵ４は、図５に示すように、まずＳ２１０にて、トリガイベントが発行されたか否かを判断する。ここで、トリガイベントが発行されていない場合には（Ｓ２１０：ＮＯ）、待機状態設定処理を一旦終了する。一方、トリガイベントが発行された場合には（Ｓ２１０：ＹＥＳ）、Ｓ２２０にて、待機状態フラグをセットし、待機状態設定処理を一旦終了する。

次に、第２実施形態のマージＥＣＵ４が実行する統合処理の手順を説明する。
この統合処理が実行されると、マージＥＣＵ４は、図６に示すように、まずＳ３１０にて、待機状態フラグがセットされているか否かを判断する。ここで、待機状態フラグがセットされている場合には（Ｓ３１０：ＹＥＳ）、Ｓ３２０にて、個別ＥＣＵ２，３のうち、トリガイベントの対象となっている個別ＥＣＵの全てから反映許可情報を受信したか否かを判断する。

ここで、トリガイベントの対象となっている個別ＥＣＵの全てから反映許可情報を受信した場合には（Ｓ３２０：ＹＥＳ）、Ｓ３３０にて、第１統合後データを算出する。具体的には、これまでに個別ＥＣＵ２と個別ＥＣＵ３から取得した最新の統合用個別データと、マージＥＣＵ４が算出した最新の統合用個別データとを統合する。

さらにＳ３４０にて、待機状態フラグをクリアして、Ｓ３６０に移行する。
またＳ３１０にて、待機状態フラグがクリアされている場合には（Ｓ３１０：ＮＯ）、Ｓ３５０にて、第１統合後データを算出して、Ｓ３６０に移行する。具体的には、これまでに個別ＥＣＵ２と個別ＥＣＵ３から取得した最新の統合用個別データと、マージＥＣＵ４が算出した最新の統合用個別データとを統合する。

そしてＳ３６０に移行すると、第２統合後データを算出して、統合処理を一旦終了する。具体的には、トリガイベントに起因して第１統合後データがオンからオフに更新された場合に、第２統合後データをクリアする。また、上記の場合以外には、第１統合後データがオフのときに第２統合後データを保持する一方、第１統合後データがオンのときに第２統合後データをインクリメント（１加算）する。

次に、このように構成された車両制御システム１の動作の具体例を説明する。
図７は、全体トリガイベントが発行された場合の動作を示すタイミングチャートである。

図７に示すように、まず、マージＥＣＵ４が通常状態であるとする（時刻ｔ２１を参照）。また、マージＥＣＵ４、個別ＥＣＵ２および個別ＥＣＵ３の統合用個別データがそれぞれ、オン、オフおよびオフであるとする（時刻ｔ２１を参照）。このため、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ２１を参照）。

その後、個別ＥＣＵ２の統合用個別データがオフからオンに変化する（時刻ｔ２２を参照）。そして、個別ＥＣＵ２からマージＥＣＵ４へ統合用個別データを送信するために要する遅延時間（送信遅延時間）が経過した後に、マージＥＣＵ４は、個別ＥＣＵ２の統合用個別データがオフからオンに変化したことを認識する（時刻ｔ２３を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ２３を参照）。

その後、個別ＥＣＵ３の統合用個別データがオフからオンに変化する（時刻ｔ２４を参照）。さらに、マージＥＣＵ４の統合用個別データがオンからオフに変化する（時刻ｔ２５を参照）。そして、個別ＥＣＵ３からマージＥＣＵ４へ統合用個別データを送信するために要する遅延時間（送信遅延時間）が経過した後に、マージＥＣＵ４は、個別ＥＣＵ３の統合用個別データがオフからオンに変化したことを認識する（時刻ｔ２６を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ２６を参照）。

その後、全体トリガイベントが発行されると、マージＥＣＵ４が通常状態から待機状態に変化する（時刻ｔ２７を参照）。また、個別ＥＣＵ２，３の統合用個別データがオンからオフに変化する（時刻ｔ２７を参照）。そして、個別ＥＣＵ２の送信遅延時間が経過した後に、マージＥＣＵ４は、個別ＥＣＵ２の統合用個別データがオンからオフに変化したことを認識するとともに、反映許可情報（矢印ＲＡ１を参照）を受信する（時刻ｔ２８を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ２８を参照）。

さらに、個別ＥＣＵ３の送信遅延時間が経過した後に、個別ＥＣＵ２の統合用個別データがオンからオフに変化したことを認識するとともに、反映許可情報（矢印ＲＡ２を参照）を受信する（時刻ｔ２９を参照）。これにより、トリガイベントの対象となっている個別ＥＣＵの全てから反映許可情報を受信したことになるため、マージＥＣＵ４が待機状態から通常状態に変化する（時刻ｔ２９を参照）。この時点で、マージＥＣＵ４と個別ＥＣＵ２，３の統合用個別データがオフであるため、第１統合後データがオンからオフに変化する（時刻ｔ２９を参照）。さらに、全体トリガイベントが発行されたことに起因して第１統合後データがオンからオフに変化したため、第２統合後データがクリアされる（時刻ｔ２９を参照）。

図８は、個別ＥＣＵ２を対象とする個別トリガイベントが発行された場合の動作を示すタイミングチャートである。
図８に示すように、時刻ｔ３１から時刻ｔ３６までの動作は、図７における時刻ｔ２１から時刻ｔ２６までの動作と同じである。そして、時刻ｔ３７にて、個別ＥＣＵ２を対象とする個別トリガイベントが発行されると、マージＥＣＵ４が通常状態から待機状態に変化する（時刻ｔ３７を参照）。また、個別ＥＣＵ２の統合用個別データがオンからオフに変化する（時刻ｔ３７を参照）。なお、発行された個別トリガイベントは個別ＥＣＵ２を対象とするものであるため、個別ＥＣＵ３とマージＥＣＵ４の統合用個別データはオンのままである（時刻ｔ３７を参照）。

その後、個別ＥＣＵ３の統合用個別データがオフからオンに変化する（時刻ｔ３８を参照）。そして、個別ＥＣＵ３の送信遅延時間が経過した後に、マージＥＣＵ４は、個別ＥＣＵ３の統合用個別データがオフからオンに変化したことを認識する（時刻ｔ３９を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ３９を参照）。

そして、個別ＥＣＵ２の送信遅延時間が経過した後に、マージＥＣＵ４は、個別ＥＣＵ２の統合用個別データがオンからオフに変化したことを認識するとともに、反映許可情報（矢印ＲＡ３を参照）を受信する（時刻ｔ４０を参照）。これにより、トリガイベントの対象となっている個別ＥＣＵの全てから反映許可情報を受信したことになるため、マージＥＣＵ４が待機状態から通常状態に変化する（時刻ｔ４０を参照）。この時点で、マージＥＣＵ４と個別ＥＣＵ２，３の統合用個別データがオフであるため、第１統合後データがオンからオフに変化する（時刻ｔ４０を参照）。ただし、個別トリガイベントが発行された時点では、個別ＥＣＵ３の統合用個別データはオンのままであったため、第２統合後データは保持される（時刻ｔ４０を参照）。

図９は、個別ＥＣＵ２を対象とする個別トリガイベントが発行された場合の動作を示すタイミングチャートである。
図９に示すように、まず、マージＥＣＵ４が通常状態であるとする（時刻ｔ５１を参照）。また、マージＥＣＵ４、個別ＥＣＵ２および個別ＥＣＵ３の統合用個別データがそれぞれ、オン、オフおよびオフであるとする（時刻ｔ５１を参照）。このため、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ５１を参照）。

その後、個別ＥＣＵ２の統合用個別データがオフからオンに変化する（時刻ｔ５２を参照）。そして、個別ＥＣＵ２からマージＥＣＵ４へ統合用個別データを送信するために要する遅延時間（送信遅延時間）が経過した後に、マージＥＣＵ４は、個別ＥＣＵ２の統合用個別データがオフからオンに変化したことを認識する（時刻ｔ５３を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ５３を参照）。

その後、マージＥＣＵ４の統合用個別データがオンからオフに変化する（時刻ｔ５４を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ５４を参照）。

その後、個別ＥＣＵ２を対象とする個別トリガイベントが発行されると、マージＥＣＵ４が通常状態から待機状態に変化する（時刻ｔ５５を参照）。また、個別ＥＣＵ２の統合用個別データがオンからオフに変化する（時刻ｔ５５を参照）。この時点では、第１統合後データがオンであり、第２統合後データは定期的にインクリメントされる（時刻ｔ５５を参照）。

そして、個別ＥＣＵ２の送信遅延時間が経過した後に、マージＥＣＵ４は、個別ＥＣＵ２の統合用個別データがオンからオフに変化したことを認識するとともに、反映許可情報（矢印ＲＡ４を参照）を受信する（時刻ｔ５６を参照）。これにより、トリガイベントの対象となっている個別ＥＣＵの全てから反映許可情報を受信したことになるため、マージＥＣＵ４が待機状態から通常状態に変化する（時刻ｔ５６を参照）。この時点で、マージＥＣＵ４と個別ＥＣＵ２，３の統合用個別データがオフであるため、第１統合後データがオンからオフに変化する（時刻ｔ５６を参照）。さらに、個別トリガイベントが発行されたことに起因して第１統合後データがオンからオフに変化したため、第２統合後データがクリアされる（時刻ｔ５６を参照）。

このように構成されたマージＥＣＵ４では、まず、通信ライン６を介してデータ通信可能に接続される車両制御システム１を構成する個別ＥＣＵ２，３から、通信ライン６を介して、個別ＥＣＵ２，３が演算した統合用個別データを受信し、受信した統合用個別データと、マージＥＣＵ４が演算した統合用個別データとを統合して、第１統合後データを算出する（Ｓ３３０，Ｓ３５０）。

また、個別ＥＣＵ２，３とは異なる電子制御装置であるトリガＥＣＵ５から、通信ライン６を介して、統合用個別データのクリアを要求するトリガイベントを受信すると、第１統合後データの算出を禁止する（Ｓ２１０，Ｓ２２０，Ｓ３１０，Ｓ３２０）。

そして、トリガイベントが統合用個別データのクリアの対象としている全ての個別ＥＣＵから、トリガイベントに従って統合用個別データをクリアしたことを示す反映許可情報を受信すると（Ｓ３２０：ＹＥＳ）、第１統合後データの算出の禁止を解除する（Ｓ３２０）。

このようにマージＥＣＵ４では、トリガイベントを受信すると（Ｓ２１０：ＹＥＳ）、個別ＥＣＵ２，３から受信した統合用個別データに基づいた演算を禁止し、その後、統合用個別データが変更された後のものであることを示す変更済条件が成立すると（Ｓ３２０：ＹＥＳ）、演算の禁止を解除する。

このため、変更済条件が成立した後に個別ＥＣＵ２，３から受信した統合用個別データは、トリガイベントに従って変更されたものであると判断することができる。これにより、個別ＥＣＵ２，３から受信した統合用個別データがトリガイベントの発行後のものであるか否かを判断した上で、受信した統合用個別データに基づいた演算を行うことができる。

また、トリガイベントが統合用個別データのクリアの対象としている全ての個別ＥＣＵから反映許可情報を受信するという方法を用いることにより、受信した統合用個別データがトリガイベントの発行後のものであるか否かを確実に判断することができる。

以上説明した実施形態において、Ｓ３３０，Ｓ３５０の処理は本発明における演算手段、Ｓ２１０，Ｓ２２０，Ｓ３１０，Ｓ３２０の処理は本発明における演算禁止手段、Ｓ３２０の処理は本発明における禁止解除手段である。

（第３実施形態）
以下に本発明の第３実施形態を図面とともに説明する。
本実施形態の車両制御システム１０１は、車両に搭載され、図１０に示すように、後処理ＥＣＵ１０２、変速機ＥＣＵ１０３、エンジンＥＣＵ１０４および故障診断装置１０５を備える。

ＥＣＵ１０２，１０３，１０４および故障診断装置１０５は、共通の通信ライン１０６を介して相互に通信可能となるように接続されている。
ＥＣＵ１０２，１０３，１０４および故障診断装置１０５は、ＣＰＵ、ＲＯＭ、ＲＡＭ、Ｉ／Ｏ及びこれらの構成を接続するバスラインなどからなる周知のマイクロコンピュータを中心に構成されており、ＲＯＭに記憶されたプログラムに基づいて各種処理を実行する。

エンジンＥＣＵ１０４は、車両のエンジン１５０（本実施形態ではディーゼルエンジン）の制御を行う。
エンジン１５０には、エンジン１５０の気筒に燃料を噴射するインジェクタ１５１が設けられている。

インジェクタ１５１には、燃料の蓄圧容器であるコモンレール１５２から伸びた燃料供給用配管１５３が接続されている。またコモンレール１５２には、車両の燃料タンク１５４に貯留された燃料が、燃料ポンプ１５５によって圧送される。これにより、コモンレール１５２に蓄えられた高圧の燃料は、燃料供給用配管１５３を介してインジェクタ１５１に供給される。

そしてエンジンＥＣＵ１０４は、エンジン１５０の回転数、アクセル開度、およびコモンレール１５２の燃料圧力（レール圧）などに基づいて、インジェクタ１５１の燃料噴射圧力を制御する噴射圧制御と、インジェクタ１５１の燃料噴射量および噴射時期を制御する燃料噴射制御を実行する。

後処理ＥＣＵ１０２は、エンジン１５０から排出される排気を浄化する浄化装置１７０を制御する。
浄化装置１７０は、ＳＣＲ（Selective Catalytic Reduction）触媒１７１、尿素水インジェクタ１７２、尿素水タンク１７３、配管１７４、尿素水ポンプ１７５、ＮＯｘセンサ１７６およびレベルセンサ１７７を備える。

ＳＣＲ触媒１７１と尿素水インジェクタ１７２は、エンジン１５０から排出される排気の通路を構成する排気管１８０に設けられている。
ＳＣＲ触媒１７１は、アンモニアにより排気中の窒素酸化物（ＮＯｘ）を還元して、窒素と水蒸気に分解するための触媒である。

尿素水インジェクタ１７２は、排気管１８０において排気がエンジン１５０からＳＣＲ触媒１７１に到るまでの経路上のＳＣＲ触媒１７１付近に配置され、排気管１８０内に尿素水を噴射する。なお、尿素水インジェクタ１７２から噴射された尿素水は、ＳＣＲ触媒１７１に吸着され、排気温度が所定温度以上になると加水分解されることによりアンモニアと二酸化炭素とに分解される。

尿素水インジェクタ１７２には、尿素水を貯留する尿素水タンク１７３から伸びた配管１７４が接続されている。そして、尿素水タンク１７３に貯留された尿素水が、尿素水ポンプ１７５によって圧送され、配管１７４を介して尿素水インジェクタ１７２に供給される。

ＮＯｘセンサ１７６は、排気管１８０において排気がＳＣＲ触媒１７１から車両外に到るまでの経路上のＳＣＲ触媒１７１付近に配置され、排気管１８０内の排気のＮＯｘ濃度を検出する。

レベルセンサ１７７は、尿素水タンク１７３に設けられ、尿素水タンク１７３内における尿素水の水位を検出する。
そして後処理ＥＣＵ１０２は、ＮＯｘセンサ１７６およびレベルセンサ１７７の検出信号を入力する。

後処理ＥＣＵ１０２は、ＮＯｘセンサ１７６により検出されたＮＯｘ濃度に基づいて、排気中に含まれるＮＯｘがＳＣＲ触媒１７１における還元反応で除去できるように尿素水量を算出する。そして後処理ＥＣＵ１０２は、算出した尿素水量に基づいて尿素水インジェクタ１７２を駆動することにより、尿素水の噴射量を制御する。

また後処理ＥＣＵ１０２は、レベルセンサ１７７の検出結果に基づいて、尿素噴射前における尿素水の水位と、尿素噴射後における尿素水の水位とを比較し、尿素噴射前後の水位差が予め設定された故障判定値よりも大きいか否かを判断する。そして後処理ＥＣＵ１０２は、尿素噴射前後の水位差が故障判定値よりも大きい場合には、尿素の消費量の故障が発生したと判断し、その旨を示す尿素消費量故障通知を通信ライン１０６を介してエンジンＥＣＵ１０４へ送信する。

変速機ＥＣＵ１０３は、運転者が操作するシフトレバー（不図示）の操作位置（Ｐ，Ｒ，ＮＤ，１ｓｔ，２ｎｄ等）、アクセル開度、および車速などに基づいて、自動変速機（不図示）の変速比を車両の運転状態に応じて変化させる制御を実行する。

故障診断装置１０５は、所謂ダイアグツールである。故障診断装置１０５は、例えばコネクタ（不図示）を介して着脱可能になっており、故障診断時等に、通信ライン１０６を介してＥＣＵ１０２，１０３，１０４と通信可能に接続される。なお故障診断装置１０５は、マイコンおよび表示装置を備えたハンディタイプの装置または小型のパソコン等である。

また車両制御システム１０１は、車両全体のＭＩ（Malfunction Indicator）状態と、ＥＣＵ１０２，１０３，１０４それぞれのＭＩ状態を算出するように構成されている。
ＭＩ状態は、厳しいものから「Continuous-MI」、「Short-M」、「On demand MI」および「正常」に分類される。

ＥＣＵ１０２，１０３，１０４それぞれのＭＩ状態は、ＥＣＵ１０２，１０３，１０４自身により算出される。なお、ＥＣＵ１０２のＭＩ状態は、ＥＣＵ１０２が故障診断を行う複数の診断項目のＭＩ状態を統合（マージ）することにより算出される。同様に、ＥＣＵ１０３，１０４のＭＩ状態はそれぞれ、ＥＣＵ１０３，１０４が故障診断を行う複数の診断項目のＭＩ状態を統合することにより算出される。

車両全体のＭＩ状態は、エンジンＥＣＵ１０４が、後処理ＥＣＵ１０２および変速機ＥＣＵ１０３から通信により取得したＭＩ状態と、エンジンＥＣＵ１０４自身のＭＩ状態とを統合（マージ）することにより算出される。

ＥＣＵ１０２，１０３，１０４のＭＩ状態と車両全体のＭＩ状態とに基づいて、ＭＩＬ（Malfunction Indicator Lamp）の点灯と消灯とが切り替わる。
また車両制御システム１０１は、車両Continuous-ＭＩカウンタ（以下、車両ＭＩカウンタという）、後処理Continuous-ＭＩカウンタ（以下、後処理ＭＩカウンタという）、変速機Continuous-ＭＩカウンタ（以下、変速機ＭＩカウンタという）およびエンジンContinuous-ＭＩカウンタ（以下、エンジンＭＩカウンタという）を備える。

車両ＭＩカウンタは、車両全体のＭＩ状態が「Continuous-MI」であるときのエンジン稼働時間を積算するためのカウンタである。後処理ＭＩカウンタは、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」であるときのエンジン稼働時間を積算するためのカウンタである。変速機ＭＩカウンタは、変速機ＥＣＵ１０３のＭＩ状態が「Continuous-MI」であるときのエンジン稼働時間を積算するためのカウンタである。エンジンＭＩカウンタは、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」であるときのエンジン稼働時間を積算するためのカウンタである。

そして、車両ＭＩカウンタ、後処理ＭＩカウンタ、変速機ＭＩカウンタおよびエンジンＭＩカウンタは、ＭＩ状態が「Continuous-MI」以外であるとき、またはエンジン１５０が稼動していないときに保持される。

また、車両ＭＩカウンタ、後処理ＭＩカウンタ、変速機ＭＩカウンタおよびエンジンＭＩカウンタは、以下に示す第１消去条件、第２消去条件および第３消去条件の何れかが成立したときに、カウンタ値が０に設定（以下、クリアという）される。

第１消去条件は、ＭＩ状態が「Continuous-MI」以外の状態で４０回のウォームアップサイクルが経過することである。第２消去条件は、ＭＩ状態が「Continuous-MI」以外の状態で３回のドライビングサイクルが経過した後に、ＭＩ状態が再度「Continuous-MI」になることである。第３消去条件は、故障診断装置１０５からのダイアグクリア要求を受信することである。

なお、故障診断装置１０５からのダイアグクリア要求は、車両全体を対象とするものと、ＥＣＵ１０２，１０３，１０４それぞれを対象とするものがある。
このように構成された車両制御システム１において、エンジンＥＣＵ１０４は、待機状態設定処理と統合処理を実行する。

まず、エンジンＥＣＵ１０４が実行する待機状態設定処理の手順を説明する。待機状態設定処理は、エンジンＥＣＵ１０４の動作中に繰り返し実行される処理である。
この待機状態設定処理が実行されると、エンジンＥＣＵ１０４は、図１１に示すように、まずＳ４１０にて、故障診断装置１０５からダイアグクリア要求を受信したか否かを判断する。ここで、ダイアグクリア要求を受信していない場合には（Ｓ４１０：ＮＯ）、待機状態設定処理を一旦終了する。一方、ダイアグクリア要求を受信した場合には（Ｓ４１０：ＹＥＳ）、Ｓ４２０にて、ダイアグクリア要求がエンジンＥＣＵ１０４を対象とするものであるか否かを判断する。ここで、エンジンＥＣＵ１０４を対象とするものでない場合には（Ｓ４２０：ＮＯ）、Ｓ４７０に移行する。

一方、エンジンＥＣＵ１０４を対象とするものである場合には（Ｓ４２０：ＹＥＳ）、Ｓ４３０にて、エンジンＥＣＵ１０４の複数の診断項目のＭＩ状態を更新する。具体的には、本実施形態では、ダイアグクリア要求が車両全体を対象とするものである場合には、全ての診断項目のＭＩ状態が「正常」に設定される。また、ダイアグクリア要求が車両全体を対象とするものでない場合には、複数の診断項目のうち一部の診断項目はＭＩ状態が保持され、残りの診断項目は「正常」に設定される。

その後Ｓ４４０にて、Ｓ４３０で更新された診断項目のＭＩ状態を統合することにより、エンジンＥＣＵ１０４のＭＩ状態を更新する。
そしてＳ４５０にて、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」以外であるか否かを判断する。ここで、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」である場合には（Ｓ４５０：ＮＯ）、待機状態設定処理を一旦終了する。一方、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」以外である場合には（Ｓ４５０：ＹＥＳ）、Ｓ４６０にて、エンジンＭＩカウンタをクリアし、Ｓ４７０に移行する。

そしてＳ４７０に移行すると、待機状態カウンタの値を、予め設定された通信遅延設定値（本実施形態では、例えば１．５秒に相当する値）に設定し、待機状態設定処理を一旦終了する。

次に、エンジンＥＣＵ１０４が実行する統合処理の手順を説明する。統合処理は、エンジンＥＣＵ１０４の動作中に繰り返し実行される処理である。
この統合処理が実行されると、エンジンＥＣＵ１０４は、図１２に示すように、まずＳ５１０にて、待機状態カウンタの値が０より大きいか否かを判断する。ここで、待機状態カウンタの値が０より大きい場合には（Ｓ５１０：ＹＥＳ）、Ｓ５２０にて、待機状態カウンタをデクリメント（１減算）する。

そしてＳ５３０にて、待機状態カウンタの値が０であるか否かを判断する。ここで、待機状態カウンタの値が０より大きい場合には（Ｓ５３０：ＮＯ）、Ｓ５６０に移行する。一方、待機状態カウンタの値が０である場合には（Ｓ５３０：ＹＥＳ）、Ｓ５４０にて、車両全体のＭＩ状態を算出して、Ｓ５６０に移行する。具体的には、待機状態カウンタの値が０になってから新たに、後処理ＥＣＵ１０２と変速機ＥＣＵ１０３の両方からＭＩ状態を取得し、取得した２つのＭＩ状態と、エンジンＥＣＵ１０４が算出した最新のＭＩ状態とを統合する。

またＳ５１０にて、待機状態カウンタの値が０である場合には（Ｓ５１０：ＮＯ）、Ｓ５５０にて、車両全体のＭＩ状態を算出して、Ｓ５６０に移行する。具体的には、これまでに後処理ＥＣＵ１０２と変速機ＥＣＵ１０３から取得した最新のＭＩ状態と、エンジンＥＣＵ１０４が算出した最新のＭＩ状態とを統合する。

そしてＳ５６０に移行すると、車両ＭＩカウンタを更新して、統合処理を一旦終了する。具体的には、ダイアグクリア要求に起因して車両全体のＭＩ状態が「Continuous-MI」から「Continuous-MI」以外に更新された場合、および、上記第１消去条件または上記第２消去条件が成立した場合の何れかで、車両ＭＩカウンタをクリアする。また、上記の場合以外には、車両全体のＭＩ状態が「Continuous-MI」以外のときに車両ＭＩカウンタを保持する一方、車両全体のＭＩ状態が「Continuous-MI」のときに車両ＭＩカウンタをインクリメント（１加算）する。

次に、このように構成された車両制御システム１０１の動作の具体例を説明する。
図１３は、車両全体を対象とするダイアグクリア要求が発行された場合の動作を示すタイミングチャートである。なお図１３では、説明の簡略化のために、後処理ＥＣＵ１０２のＭＩ状態とエンジンＥＣＵ１０４のＭＩ状態とを統合して車両全体のＭＩ状態を算出するとして説明する。

図１３に示すように、まず、待機状態カウンタの値が０であり、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外であり、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」であるとする（時刻ｔ６１を参照）。このため、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ６１を参照）。

その後、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」に変化し、後処理ＥＣＵ１０２からエンジンＥＣＵ１０４へＭＩ状態を送信するために要する遅延時間（送信遅延時間）が経過した後に、エンジンＥＣＵ１０４は、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」に変化したことを認識する（時刻ｔ６２を参照）。この時点では、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ６２を参照）。

その後、車両全体を対象とするダイアグクリア要求が発行されると、待機状態カウンタの値が通信遅延設定値に設定されるとともに、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」以外に変化する（時刻ｔ６３を参照）。

また、車両全体を対象とするダイアグクリア要求により、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外に変化し、送信遅延時間が経過した後に、エンジンＥＣＵ１０４は、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外に変化したことを認識する（時刻ｔ６４を参照）。この時点では、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ６４を参照）。

その後、待機状態カウンタの値が０になると、後処理ＥＣＵ１０２とエンジンＥＣＵ１０４のＭＩ状態が両方とも「Continuous-MI」以外であるため、車両全体のＭＩ状態が「Continuous-MI」以外に変化する（時刻ｔ６５を参照）。さらに、ダイアグクリア要求の発行に起因して車両全体のＭＩ状態が「Continuous-MI」以外に変化したため、車両ＭＩカウンタがクリアされる（時刻ｔ６５を参照）。

図１４は、エンジンＥＣＵ１０４を対象とするダイアグクリア要求が発行された場合の動作を示すタイミングチャートである。なお図１４では、説明の簡略化のために、後処理ＥＣＵ１０２のＭＩ状態とエンジンＥＣＵ１０４のＭＩ状態とを統合して車両全体のＭＩ状態を算出するとして説明する。

図１４に示すように、まず、待機状態カウンタの値が０であり、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外であり、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」であるとする（時刻ｔ７１を参照）。このため、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ７１を参照）。

その後、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」に変化し、後処理ＥＣＵ１０２からエンジンＥＣＵ１０４へＭＩ状態を送信するために要する遅延時間（送信遅延時間）が経過した後に、エンジンＥＣＵ１０４は、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」に変化したことを認識する（時刻ｔ７２を参照）。この時点では、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ７２を参照）。

その後、エンジンＥＣＵ１０４を対象とするダイアグクリア要求が発行されると、待機状態カウンタの値が通信遅延設定値に設定されるとともに、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」以外に変化する（時刻ｔ７３を参照）。

そして、待機状態カウンタの値が０になると、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」であり、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」以外であるため、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ７４を参照）。

その後、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外に変化し、送信遅延時間が経過した後に、エンジンＥＣＵ１０４は、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外に変化したことを認識する（時刻ｔ７５を参照）。この時点では、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外であり、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」以外であるため、車両全体のＭＩ状態が「Continuous-MI」以外に変化する（時刻ｔ７５を参照）。さらに、ダイアグクリア要求の発行に起因して車両全体のＭＩ状態が「Continuous-MI」以外に変化したのではないため、車両ＭＩカウンタが保持される（時刻ｔ７５を参照）。

図１５は、エンジンＥＣＵ１０４を対象とするダイアグクリア要求が発行された場合の動作を示すタイミングチャートである。なお図１５では、説明の簡略化のために、後処理ＥＣＵ１０２のＭＩ状態とエンジンＥＣＵ１０４のＭＩ状態とを統合して車両全体のＭＩ状態を算出するとして説明する。

図１５に示すように、まず、待機状態カウンタの値が０であり、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外であり、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」であるとする（時刻ｔ８１を参照）。このため、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ８１を参照）。

その後、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」に変化し、後処理ＥＣＵ１０２からエンジンＥＣＵ１０４へＭＩ状態を送信するために要する遅延時間（送信遅延時間）が経過した後に、エンジンＥＣＵ１０４は、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」に変化したことを認識する（時刻ｔ８２を参照）。この時点では、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ８２を参照）。

さらに、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」以外に変化する（時刻ｔ８３を参照）。この時点では、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ８３を参照）。

その後、エンジンＥＣＵ１０４を対象とするダイアグクリア要求が発行されると、待機状態カウンタの値が通信遅延設定値に設定される（時刻ｔ８４を参照）。なお、エンジンＥＣＵ１０４のＭＩ状態は、「Continuous-MI」以外を保持する（時刻ｔ８４を参照）。この時点では、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ８４を参照）。

そして、待機状態カウンタの値が０になると、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」であり、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」以外であるため、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ８５を参照）。

その後、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外に変化し、送信遅延時間が経過した後に、エンジンＥＣＵ１０４は、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外に変化したことを認識する（時刻ｔ８６を参照）。この時点では、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外であり、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」以外であるため、車両全体のＭＩ状態が「Continuous-MI」以外に変化する（時刻ｔ８６を参照）。さらに、ダイアグクリア要求の発行に起因して車両全体のＭＩ状態が「Continuous-MI」以外に変化したのではないため、車両ＭＩカウンタが保持される（時刻ｔ８６を参照）。

図１６は、後処理ＥＣＵ１０２を対象とするダイアグクリア要求が発行された場合の動作を示すタイミングチャートである。なお図１６では、説明の簡略化のために、後処理ＥＣＵ１０２のＭＩ状態とエンジンＥＣＵ１０４のＭＩ状態とを統合して車両全体のＭＩ状態を算出するとして説明する。

図１６に示すように、まず、待機状態カウンタの値が０であり、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外であり、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」であるとする（時刻ｔ９１を参照）。このため、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ９１を参照）。

その後、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」に変化し、後処理ＥＣＵ１０２からエンジンＥＣＵ１０４へＭＩ状態を送信するために要する遅延時間（送信遅延時間）が経過した後に、エンジンＥＣＵ１０４は、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」に変化したことを認識する（時刻ｔ９２を参照）。この時点では、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ９２を参照）。

さらに、エンジンＥＣＵ１０４のＭＩ状態が「Continuous-MI」以外に変化する（時刻ｔ９３を参照）。この時点では、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ９３を参照）。

その後、後処理ＥＣＵ１０２を対象とするダイアグクリア要求が発行されると、待機状態カウンタの値が通信遅延設定値に設定される（時刻ｔ９４を参照）。なお、エンジンＥＣＵ１０４のＭＩ状態は、「Continuous-MI」以外を保持する（時刻ｔ９４を参照）。この時点では、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ９４を参照）。

また、後処理ＥＣＵ１０２を対象とするダイアグクリア要求により、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外に変化し、送信遅延時間が経過した後に、エンジンＥＣＵ１０４は、後処理ＥＣＵ１０２のＭＩ状態が「Continuous-MI」以外に変化したことを認識する（時刻ｔ９５を参照）。この時点では、車両全体のＭＩ状態が「Continuous-MI」であり、車両ＭＩカウンタは定期的にインクリメントされる（時刻ｔ９５を参照）。

その後、待機状態カウンタの値が０になると、後処理ＥＣＵ１０２とエンジンＥＣＵ１０４のＭＩ状態が両方とも「Continuous-MI」以外であるため、車両全体のＭＩ状態が「Continuous-MI」以外に変化する（時刻ｔ９６を参照）。さらに、ダイアグクリア要求の発行に起因して車両全体のＭＩ状態が「Continuous-MI」以外に変化したため、車両ＭＩカウンタがクリアされる（時刻ｔ９６を参照）。

このように構成されたエンジンＥＣＵ１０４では、まず、通信ライン１０６を介してデータ通信可能に接続される車両制御システム１０１を構成する後処理ＥＣＵ１０２および変速機ＥＣＵ１０３から、通信ライン１０６を介して、後処理ＥＣＵ１０２および変速機ＥＣＵ１０３が演算したＭＩ状態を受信し、受信したＭＩ状態と、エンジンＥＣＵ１０４が演算したＭＩ状態とを統合して、車両全体のＭＩ状態を算出する（Ｓ５４０，Ｓ５５０）。

また、後処理ＥＣＵ１０２および変速機ＥＣＵ１０３とは異なる故障診断装置１０５から、通信ライン１０６を介して、ダイアグクリア要求を受信すると、車両全体のＭＩ状態の算出を禁止する（Ｓ４１０，Ｓ４７０，Ｓ５１０，Ｓ５３０）。

そして、後処理ＥＣＵ１０２および変速機ＥＣＵ１０３がダイアグクリア要求に従って変更したＭＩ状態を、通信ライン１０６を介して受信するまでに要する時間に基づいて設定された通信遅延設定値に対応する時間が経過すると（Ｓ５３０：ＹＥＳ）、車両全体のＭＩ状態の算出の禁止を解除する（Ｓ５３０）。

このようにエンジンＥＣＵ１０４では、ダイアグクリア要求を受信すると（Ｓ４１０：ＹＥＳ）、後処理ＥＣＵ１０２および変速機ＥＣＵ１０３から受信したＭＩ状態に基づいた演算を禁止し、その後、ＭＩ状態が変更された後のものであることを示す変更済条件が成立すると（Ｓ５３０：ＹＥＳ）、演算の禁止を解除する。

このため、変更済条件が成立した後に後処理ＥＣＵ１０２および変速機ＥＣＵ１０３から受信したＭＩ状態は、ダイアグクリア要求に従って変更されたものであると判断することができる。これにより、後処理ＥＣＵ１０２および変速機ＥＣＵ１０３から受信したＭＩ状態がダイアグクリア要求の発行後のものであるか否かを判断した上で、受信したＭＩ状態に基づいた演算を行うことができる。

以上説明した実施形態において、車両制御システム１０１は本発明におけるネットワークシステム、エンジンＥＣＵ１０４は本発明における電子制御装置、後処理ＥＣＵ１０２および変速機ＥＣＵ１０３は本発明におけるネットワーク構成装置、故障診断装置１０５は本発明における送信対象外装置、Ｓ５４０，Ｓ５５０の処理は本発明における演算手段、Ｓ４１０，Ｓ４７０，Ｓ５１０，Ｓ５３０の処理は本発明における演算禁止手段、Ｓ５３０の処理は本発明における禁止解除手段である。

以上、本発明の一実施形態について説明したが、本発明は上記実施形態に限定されるものではなく、本発明の技術的範囲に属する限り種々の形態を採ることができる。
例えば上記実施形態では、車両制御システム１が２台の個別ＥＣＵを備えるものを示したが、個別ＥＣＵを３台以上備えるようにしてもよい。

また上記第３実施形態では、上記第１実施形態のように、通信遅延設定値に対応する時間が経過すると、車両全体のＭＩ状態の算出の禁止を解除するものを示した。しかし、上記第３実施形態において、上記第２実施形態のように、ダイアグクリア要求の対象となっている全てのＥＣＵから反映許可情報を受信した場合に、車両全体のＭＩ状態の算出の禁止を解除するようにしてもよい。

１…車両制御システム、２，３…個別ＥＣＵ、４…マージＥＣＵ、５…トリガＥＣＵ、６…通信ライン、１０１…車両制御システム、１０２…後処理ＥＣＵ、１０３…変速機ＥＣＵ、１０４…エンジンＥＣＵ、１０５…故障診断装置、１０６…通信ライン

Claims (3)

1. ネットワーク（６，１０６）を介してデータ通信可能に接続されるネットワークシステム（１，１０１）を構成する複数の電子制御装置をそれぞれネットワーク構成装置（２，３，１０２，１０３）として、複数の前記ネットワーク構成装置の少なくとも１つから、前記ネットワークを介して、前記ネットワークシステムで統合する必要があるデータとして予め設定されるとともに前記ネットワーク構成装置が演算した統合用個別データを受信し、受信した前記統合用個別データである受信演算データに基づいて、複数の前記統合用個別データを統合した統合後データを算出する演算を行う演算手段（Ｓ１４０，Ｓ１５０，Ｓ３３０，Ｓ３５０，Ｓ５４０，Ｓ５５０）と、
   前記統合用個別データを送信する前記ネットワーク構成装置とは異なる電子制御装置である送信対象外装置から、前記ネットワークを介して、複数の前記ネットワーク構成装置のうち少なくとも１つの前記ネットワーク構成装置に対して前記統合用個別データの変更を要求するデータ変更要求を受信すると、前記演算手段による演算を禁止する演算禁止手段（Ｓ１０，Ｓ２０，Ｓ１１０，Ｓ１３０，Ｓ２１０，Ｓ２２０，Ｓ３１０，Ｓ３２０）と、
   複数の前記ネットワーク構成装置から受信する前記受信演算データが前記データ変更要求に従って変更された後のものであることを示す予め設定された変更済条件が成立すると、前記演算禁止手段による禁止を解除する禁止解除手段（Ｓ１３０，Ｓ３２０，Ｓ５３０）とを備える
   ことを特徴とする電子制御装置（４，１０４）。
2. 前記変更済条件は、
   前記演算手段による演算を前記演算禁止手段が禁止してから、複数の前記ネットワーク構成装置が前記データ変更要求に従って変更した前記統合用個別データを、前記ネットワークを介して受信するまでに要する時間に基づいて設定された通信遅延時間が経過することである
   ことを特徴とする請求項１に記載の電子制御装置。
3. 前記変更済条件は、
   前記データ変更要求が前記演算データの変更の対象としている全ての前記ネットワーク構成装置から、前記データ変更要求に従って前記統合用個別データを変更したことを示す変更要求反映情報を受信することである
   ことを特徴とする請求項１に記載の電子制御装置。

Images