JP6009634B2 - 制御装置切替システム - Google Patents

Description

本発明は、車両に搭載され、共通の通信線を介して接続される複数の制御装置に対して通信を行う制御装置の切り替えを行う制御装置切替システムに関する。

車両には、ＥＣＵ（Ｅｌｅｃｔｏｒｏｎｉｃ Ｃｏｎｔｒｏｌ Ｕｎｉｔ）と呼ばれる制御装置が複数搭載されている。それらの制御装置は共通の通信線を介して情報の授受を行い、協調して車両の動作を実現している。これらの制御装置は、車両に搭載されるバッテリやオルタネータ・モータ等から電力を供給されているが、近年、車両に搭載される制御装置の数の増加に伴い、制御装置が消費する電力量が増加している。消費電力量が増加すると、オルタネータ等による発電量が増加し車両の燃費悪化につながることから、車両の省電力化が求められ、制御装置においても省電力対応が必要となっている。

制御装置の省電力対応としては、従来、様々な手法がとられている。主には起動する必要のない制御装置は電源の供給を停止させる、スリープ状態に遷移させる等の手法がとられている。しかし、異常検出装置を備えたネットワークにおいては、データ受信が所定時間行われない制御装置に対して異常が発生したものとみなし、異常処理が開始されることがある。

このような不都合を解消するため、特許文献１では、ネットワークに接続された複数の制御装置のうち、他の制御装置を電源遮断やスリープにさせることで送受信機能を停止させる機能を有する送受信制御装置を備え、この送受信制御装置により送受信が停止させられる被制御装置が行うべきデータ送信を代行することにより、ネットワークのデータ異常を検出する異常検出装置が異常を検出することなく、車両の省電力化を図っている。

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

上述のように、特許文献１では、送受信制御装置が被制御装置の送受信停止を行った後、被制御装置が送信するべきデータ送信を代行するようにしている。しかしながら、送受信制御装置が故障している場合や処理負荷が高い場合、または他の重要な処理を行っている場合には、データ送信を代行することができない事態が発生し、ネットワーク異常として異常検出装置に検知されてしまう。また、送受信制御装置の処理負荷が高い場合や重要な処理を行っている時に、被制御装置の行うべきデータ送信を代行させることによって、送受信制御装置のリアルタイム性が欠如し、車両の動作に欠陥が生じるという課題がある。

本発明は、上記のような課題を解決するためになされたものであり、共通の通信線に接続された複数の制御装置を含む制御装置切替システムにおいて、スリープ状態または電源オフ状態になる通信制御装置の行うべきデータ送信処理を確実に代行させることができ、ネットワーク異常や車両の挙動に異常を発生させない制御装置切替システムを得ることを目的とする。

本発明に係る制御装置切替システムは、車両に搭載される複数の制御装置が共通の通信線を介して互いに接続され、制御装置は、自身以外の制御装置との間でデータの送受信を行う通信制御装置と、通信制御装置が行うべきデータ送信処理を代行可能な複数の代行候補装置を含み、通信制御装置は、自身のスリープ処理または電源遮断の条件が成立するとデータの送受信を停止するデータ送受信実行／停止手段と、代行候補装置の各々についてデータ送信処理を代行可能な状態か否かを判定する代行送信可否判定手段と、データ送信処理を代行させる代行候補装置に対して代行要求を送信する代行要求送信手段とを備え、自身のスリープ処理または電源遮断の条件が成立すると、代行送信可否判定手段による判定結果に基づいてデータ送信処理を代行させる代行候補装置を決定し、その代行候補装置に対して代行要求送信手段から代行要求を送信した後、データ送受信実行／停止手段によりデータ送信処理を停止し、代行候補装置は、データ送信処理の代行を実行する代行送信手段と、所定時刻における通信制御装置からの受信データを蓄積する記憶手段と、該所定時刻における代行候補装置の内部変数と受信データとを比較して該代行候補装置がデータ送信処理を代行する際の送信データを導出する代行データ導出手段を備え、通信制御装置から代行要求を受信した場合に代行送信手段によりデータ送信処理を代行するものである。

本発明によれば、通信制御装置のスリープ処理または電源遮断の条件が成立すると、通信制御装置の代行送信可否判定手段により代行可能であると判定された代行候補装置に対して代行要求を送信するようにしたので、通信制御装置が行うべきデータ送信処理を確実に代行させることができると共に、代行候補装置が代行データ導出手段を備えることにより、通信制御装置が本来送信すべきデータに近い値を出力することができ、ネットワーク異常や車両の挙動に異常を発生させない制御装置切替システムを得ることが可能である。

本発明の実施の形態１に係る制御装置切替システムの構成を示す図である。 本発明の実施の形態１に係る制御装置切替システムの通信制御装置と代行候補装置の構成を示す図である。 本発明の実施の形態１に係る制御装置切替システムにおける代行可能処理負荷量テーブルの一例を示す図である。 本発明の実施の形態１に係る制御装置切替システムの通信制御装置が代行候補装置の中から実代行装置を決定する処理の流れの一例を示す図である。 本発明の実施の形態１に係る制御装置切替システムにおける代行可能処理重要度テーブルの一例を示す図である。 本発明の実施の形態１に係る制御装置切替システムの通信制御装置が代行候補装置の中から実代行装置を決定する処理の流れの一例を示す図である。 本発明の実施の形態１に係る制御装置切替システムの通信制御装置が代行候補装置の中から代行装置を決定する処理の流れの一例を示す図である。 本発明の実施の形態１に係る制御装置切替システムにおける代行候補装置の優先度を示す図である。 本発明の実施の形態１に係る制御装置切替システムの通信制御装置が代行候補装置の中から代行装置を決定する処理の流れの一例を示す図である。 本発明の実施の形態２に係る制御装置切替システムの構成を示す図である。 本発明の実施の形態２に係る制御装置切替システムの代行候補装置の構成を示す図である。 本発明の実施の形態２に係る制御装置切替システムの代行装置が次の代行装置を決定する処理の流れの一例を示す図である。 本発明の実施の形態２に係る制御装置切替システムの代行装置が次の代行装置を決定する処理の流れの一例を示す図である。 本発明の実施の形態２に係る制御装置切替システムの他の構成を示す図である。 本発明の実施の形態２に係る制御装置切替システムの監視制御装置が次の代行装置を決定する処理の流れの一例を示す図である。 本発明の実施の形態３に係る制御装置切替システムの構成を示す図である。 本発明の実施の形態３に係る制御装置切替システムの通信制御装置と代行候補装置の構成を示す図である。 本発明の実施の形態３に係る制御装置切替システムの代行可能ＥＣＵキューを示す図である。 本発明の実施の形態３に係る制御装置切替システムの通信制御装置が代行候補装置の中から代行装置を決定する処理の流れの一例を示す図である。 本発明の実施の形態４に係る制御装置切替システムの代行候補装置の構成を示す図である。 本発明の実施の形態４に係る制御装置切替システムの代行候補装置が備える記憶手段に記憶されるテーブルを示す図である。 本発明の実施の形態５に係る制御装置切替システムの代行候補装置の構成を示す図である。 本発明の実施の形態５に係る制御装置切替システムの代行候補装置が備えるデータ調整手段の機能を説明する図である。 本発明の実施の形態６に係る制御装置切替システムの代行候補装置の構成を示す図である。 本発明の実施の形態６に係る制御装置切替システムの代行候補装置が備える制御周期調整手段の機能を説明する図である。 本発明の実施の形態７に係る制御装置切替システムの代行候補装置の構成を示す図である。 本発明の実施の形態７に係る制御装置切替システムの代行候補装置が備えるクロック周波数調整手段の機能を説明する図である。 本発明の実施の形態８に係る制御装置切替システムの代行候補装置の構成を示す図である。 本発明の実施の形態８に係る制御装置切替システムの代行候補装置が備えるデータ同期手段の機能を説明する図である。 本発明の実施の形態９に係る制御装置切替システムの通信制御装置の構成を示す図である。 本発明の実施の形態９に係る制御装置切替システムの通信制御装置がデータ送信処理を再開する際の処理の流れを示す図である。 本発明の実施の形態１０に係る制御装置切替システムの通信制御装置と代行候補装置の構成を示す図である。 本発明の実施の形態１０に係る制御装置切替システムの通信制御装置が代行装置の代行を時間で管理する処理の流れを示す図である。 本発明の実施の形態１１に係る制御装置切替システムの代行候補装置の構成を示す図である。 本発明の実施の形態１１に係る制御装置切替システムの代行候補装置が備えるデータ通信周期調整手段の機能を説明する図である。 本発明の実施の形態１２に係る制御装置切替システムの代行候補装置の構成を示す図である。 本発明の実施の形態１２に係る制御装置切替システムの代行候補装置が備えるデータ通信周期調整手段と車両状況検出手段の機能を説明する図である。 本発明の実施の形態１２に係る制御装置切替システムの代行候補装置が備えるデータ通信周期調整手段の機能を説明する図である。

実施の形態１．
以下に、本発明の実施の形態１に係る制御装置切替システムについて、図面に基づいて説明する。図１は、本実施の形態１に係る制御装置切替システムの構成を示している。なお、以下に示す全ての図において、図中、同一または相当部分には同一符号を付し、説明を省略する。

本実施の形態１に係る制御装置切替システム１００は、車両に搭載される複数の制御装置ＥＣＵ１〜ＥＣＵｎ（ｎ＞３）が、共通の通信線であるネットワーク６を介して互いに接続されたものである。これらの制御装置には、自身以外の制御装置との間でデータの送受信を行う通信制御装置と、この通信制御装置が行うべきデータ送信処理を代行可能な複数の代行候補装置が含まれる。以下の説明では、ＥＣＵ１を通信制御装置、ＥＣＵ２〜ＥＣＵｍ（ｍ＜ｎ）を代行候補装置とし、ＥＣＵ２〜ＥＣＵｍの中から実際に代行を行う代行装置が決定される。

代行候補装置ＥＣＵ２〜ＥＣＵｍの各々は、車両に関する所定の処理を実行する制御装置であり、例えば、モータやエンジン等に関わる駆動系ＥＣＵ、エアバッグ等に関わる安全系ＥＣＵ、シートやライトの調整等に関わるボディ系ＥＣＵ、またはナビゲーション装置等に関わる情報系ＥＣＵである。これらのＥＣＵ２〜ＥＣＵｍは、ＥＣＵ１の行うべきデータ送信処理を代行することになった場合でも、本来の処理を放棄するものではなく、自身の担う本来の処理と両立させるものである。

図２（ａ）は、通信制御装置ＥＣＵ１の構成を示し、図２（ｂ）は、代行候補装置ＥＣＵ２の構成を示している。その他の代行候補装置ＥＣＵ３〜ＥＣＵｍの構成は、ＥＣＵ２と同様であるので、図示および説明を省略する。なお、通信制御装置および代行候補装置の各々は、図２に示す以外にも様々な機能を備えているが、ここでは、通信制御装置のデータ送信処理を代行候補装置に代行させる機能に係る構成要素のみを示している。

ＥＣＵ１は、データ送受信実行／停止手段１１、代行要求送信手段１２、代行送信可否判定手段１３、スリープ条件成立判定手段１４、スリープ処理手段１５、およびウェイク処理手段１６を有している。データ送受信実行／停止手段１１は、外部とのデータの送受信を実行すると共にスリープ状態や電源が遮断された場合には外部とのデータの送受信を停止する。なお、データ送受信実行／停止手段１１がデータの送受信を停止する条件には、自身のスリープ処理や電源遮断等の他に、Ｐａｒｔｉａｌ ＮｅｔｗｏｒｋｉｎｇのようにＥＣＵ１以外のＥＣＵからネットワーク６を介して送信されるスリープ要求があった場合も含まれる。

代行要求送信手段１２は、自身が行うべきデータ送信処理を代行させる代行候補装置に対して代行要求を送信する。代行送信可否判定手段１３は、代行候補装置ＥＣＵ２〜ＥＣＵｍの各々についてデータ送信処理を代行可能な状態か否かを判定する。スリープ条件成立判定手段１４は、自身のスリープ条件が成立しているか否かを判定する。スリープ処理手段１５は、スリープ条件成立判定手段１４によりスリープ条件が成立していると判定され、データ送受信実行／停止手段１１によりデータ送受信が停止された後に、スリープ状態となる処理を行う。ウェイク処理手段１６は、スリープから復帰する処理を行う。

一方、ＥＣＵ２は、ＥＣＵ１が行うべきデータ送信処理の代行を実行する代行送信手段２１を備え、ＥＣＵ１から代行要求を受信した場合に、代行送信手段２１によりデータ送信処理の代行を開始する。

次に、本実施の形態１に係る制御装置切替システム１００におけるＥＣＵ１およびＥＣＵ２〜ＥＣＵｍの動作について、図１を用いて説明する。ＥＣＵ１は、自身のタイマ処理等によってスリープ条件が成立すると、データ送信処理を停止する前に、代行送信可否判定手段１３により、代行候補装置ＥＣＵ２〜ＥＣＵｍの各々について、データ送信処理を代行可能な状態か否かの代行送信可否判定１３ａを行う（判定基準については後述する）。ＥＣＵ１は、代行送信可否判定手段１３による判定結果に基づいて、データ送信処理を代行させる代行候補装置を決定する。

代行させる代行候補装置（図１ではＥＣＵ３）が決定すると、その旨を代行要求送信手段１２に通知する。さらに、ＥＣＵ１は、代行要求送信手段１２からネットワーク６を介してＥＣＵ３に代行要求１２ａを送信する。代行要求１２ａを送信したＥＣＵ１は、データの送信を停止し、スリープモードに遷移する。ＥＣＵ１から代行要求１２ａを受信したＥＣＵ３は、代行装置として代行送信手段２１によりデータ送信処理の代行を開始する。

なお、本実施の形態１において、ＥＣＵ１の代行送信可否判定手段１３は、代行候補装置ＥＣＵ２〜ＥＣＵｍ各々の現在の処理負荷量、あるいは処理重要度、あるいは故障判定結果のいずれかを判定基準とし、ＥＣＵ２〜ＥＣＵｍがデータ送信処理を代行可能な状態か否かを判定する。なお、それらの判定基準を複数組み合わせて判定を行うようにしても良い。

ＥＣＵ１の代行送信可否判定手段１３が、ＥＣＵ２〜ＥＣＵｍの現在の処理負荷量に基づいて代行可否の判定を行う場合、ＥＣＵ１は、図３に示すような代行可能処理負荷量テーブルを備えている。代行可能処理負荷量テーブルには、ＥＣＵ２〜ＥＣＵｍ各々について、処理負荷量の上限に基づいて設定された可能処理量ＰＬ_ｔｈが記憶されている。

一般に、ＥＣＵが搭載するマイクロコンピュータ（以下マイコンと略す）において、割込み処理が多いマイコンは、割込みがない状態での処理負荷量に余裕をもって使用されるが、割込みが多い状態では処理負荷量は１００％近くまで達する。各ＥＣＵによって割込みの数は異なるため、その数を考慮しながら上記の指標に則って処理負荷量の上限を設定する。また、各マイコンの処理負荷量の上限としてマージンを含む設計をしている場合には、そのマージンを代行に使うようにしても良い。

ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２〜ＥＣＵｍの現在の処理負荷量をネットワーク６経由で取得し、代行可能処理負荷量テーブルを参照して、代行させるＥＣＵを決定する。これにより、処理負荷が高いＥＣＵに代行させることを防止し、代行装置となったＥＣＵの本来の処理と代行処理が、本来の制御周期を超過しないようにすることができる。

本実施の形態１に係る制御装置切替システム１００において、ＥＣＵ１の代行送信可否判定手段１３が代行候補装置であるＥＣＵ２〜ＥＣＵｍの処理負荷量に基づいて、代行装置を決定するまでの処理の流れについて、図４のフローチャートを用いて説明する。なお、以下に示す全てのフローチャートにおいて、同じステップ番号は同じ処理を示し、説明を省略する。

まず、ステップ１０（Ｓ１０）において、ＥＣＵ１は、スリープ条件成立判定手段１４によりスリープ条件が成立しているか否かを判定する。Ｓ１０でスリープ条件が成立していない場合（ＮＯ）、代行に関する処理を行わない。Ｓ１０でスリープ条件が成立している場合（ＹＥＳ）、代行送信可否判定手段１３に通知し、ステップ２０（Ｓ２０）に進む。

Ｓ２０において、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２の処理負荷量を取得し、代行可能処理負荷テーブル（図３）の値と比較する。ＥＣＵ１が取得したＥＣＵ２の現在の処理負荷量が、代行可能処理負荷テーブルの代行可能処理負荷量ＰＬ_ｔｈ２（６０％）を超えていない場合（ＹＥＳ）、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２が代行可能であると判定し、ステップ３０（Ｓ３０）において、ＥＣＵ１の代行要求送信手段１２は、ＥＣＵ２に対して代行要求を送信する。

一方、Ｓ２０において、ＥＣＵ２の処理負荷量がＥＣＵ２の代行可能処理負荷量ＰＬ_ｔｈ２を超えていた場合（ＮＯ）、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２が代行不可であると判定し、ステップ２０１（Ｓ２０１）に進む。Ｓ２０１では、ＥＣＵ３の現在の処理負荷量を取得し、代行可能処理負荷テーブルの代行可能処理負荷量ＰＬ_ｔｈ３（４０％）以下であるかどうかを判定する。

Ｓ２０１において、ＥＣＵ３の処理負荷量がＥＣＵ３の代行可能処理負荷量ＰＬ_ｔｈ３を超えていない場合（ＹＥＳ）、ＥＣＵ１の代行送信可否判定手段１３はＥＣＵ３が代行可能であると判定し、ステップ２０２（Ｓ２０２）において、ＥＣＵ１の代行要求送信手段１２は、ＥＣＵ３に対して代行要求を送信する。

一方、Ｓ２０１において、ＥＣＵ３の処理負荷量がＥＣＵ３の代行可能処理負荷量ＰＬ_ｔｈ３を超えていた場合（ＮＯ）、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ３が代行不可であると判定し、別の代行候補装置ＥＣＵ４〜ＥＣＵｍに対して順次同様の判定を行う。最終的には、ステップ２０３（Ｓ２０３）において、ＥＣＵ１は、いずれかの代行候補装置ＥＣＵｍに代行指令を送信する。

続いて、ステップ４０（Ｓ４０）において、ＥＣＵ１は、データ送受信実行／停止手段１１を用いて送受信を停止し、スリープ処理手段１５によりスリープ処理を開始する。その後、ステップ５０（Ｓ５０）において、代行装置に決定したＥＣＵは、代行送信手段２１により、ＥＣＵ１の行うべきデータ送信処理の代行を開始する。

また、ＥＣＵ１の代行送信可否判定手段１３が、ＥＣＵ２〜ＥＣＵｍの処理重要度に基づいて代行可否の判定を行う場合、ＥＣＵ１は、図５に示すような代行可能処理重要度テーブルを備えている。代行可能処理重要度テーブルには、ＥＣＵ２〜ＥＣＵｍ各々について、処理重要度ＰＩの最高値が記憶されている。

処理重要度は、ＥＣＵ２〜ＥＣＵｍが実行する処理の重要度であり、例えば前回値からほとんど変化がないと推察されるセンサ値等の周期検出処理を実行中の時は、処理重要度は低く、例えば「１」と設定される。また、ハードウェア割込み等の実行強制力のある処理を実行中の時は、処理重要度は高く、例えば「１０」と設定される。処理重要度が高いほど中断することは好ましくなく、他の処理を行い難い。

代行可能処理重要度テーブルには、各ＥＣＵが代行可能な処理重要度の最高値が記憶されており、現在の処理内容がその値以下の時には代行可能であると判断される。ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２〜ＥＣＵｍが現在実施している処理の重要度をネットワーク６経由で取得し、代行可能処理重要度テーブルを参照して、代行させるＥＣＵを決定する。これにより、重要度の高い処理が中断されることを防止することができる。

図６は、制御装置切替システム１００において、ＥＣＵ１の代行送信可否判定手段１３が代行候補装置であるＥＣＵ２〜ＥＣＵｍの処理重要度に基づいて、代行装置を決定するまでの処理の流れを示すフローチャートである。ステップ２１（Ｓ２１）において、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２の処理重要度を取得し、代行可能処理重要度テーブル（図５）の値と比較する。ＥＣＵ１が取得したＥＣＵ２の処理重要度が代行可能処理重要度テーブルの代行可能処理重要度ＰＩ_ｔｈ２を超えていない場合（ＹＥＳ）、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２が代行可能であると判定し、Ｓ３０に進む。

一方、Ｓ２１において、ＥＣＵ２の処理重要度が代行可能処理重要度ＰＩ_ｔｈ２を超えていた場合（ＮＯ）、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２が代行不可であると判定し、ステップ２１１（Ｓ２１１）に進む。Ｓ２１１では、ＥＣＵ３の処理重要度を取得し、代行可能処理重要度テーブルの代行可能処理重要度ＰＩ_ｔｈ３以下であるかどうかを判定する。Ｓ２１１において、ＥＣＵ３の処理重要度がＥＣＵ３の代行可能処理重要度ＰＩ_ｔｈ３を超えていない場合（ＹＥＳ）、ＥＣＵ１の代行送信可否判定手段１３はＥＣＵ３が代行可能であると判定し、ステップ２１２（Ｓ２１２）においてＥＣＵ１の代行要求送信手段１２は、ＥＣＵ３に対して代行要求を送信する。

一方、Ｓ２１１において、ＥＣＵ３の処理重要度がＥＣＵ３の代行可能処理重要度ＰＩ_ｔｈ３を超えていた場合（ＮＯ）、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ３が代行不可であると判定し、別の代行候補装置ＥＣＵ４〜ＥＣＵｍに対して順次同様の判定を行っていく。最終的には、ステップ２１３（Ｓ２１３）において、ＥＣＵ１は、代行候補装置ＥＣＵｍに代行指令を送信する。以下の処理については図４と同様であるので説明を省略する。

また、図７は、本実施の形態１に係る制御装置切替システム１００において、ＥＣＵ１の代行送信可否判定手段１３が代行候補装置ＥＣＵ２〜ＥＣＵｍの故障判定結果に基づいて、代行装置を決定するまでの処理の流れを示すフローチャートである。ステップ２２（Ｓ２２）において、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２の故障判定結果をネットワーク６経由で取得する。ＥＣＵ２の故障判定結果が「故障無し」であった場合（ＹＥＳ）、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２が代行可能であると判定し、Ｓ３０に進む。

一方、Ｓ２２において、ＥＣＵ２の故障判定結果が「故障有り」であった場合（ＮＯ）、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２が代行不可であると判定し、ステップ２２１（Ｓ２２１）に進む。Ｓ２２１では、ＥＣＵ３の故障判定結果を取得し、これが「故障無し」であった場合（ＹＥＳ）、ＥＣＵ１の代行送信可否判定手段１３はＥＣＵ３が代行可能であると判定し、ステップ２２２（Ｓ２２２）において、ＥＣＵ１の代行要求送信手段１２は、ＥＣＵ３に対して代行要求を送信する。

一方、Ｓ２２１において、ＥＣＵ３の故障判定結果が「故障有り」であった場合（ＮＯ）、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ３が代行不可であると判定し、別の代行候補装置ＥＣＵ４〜ＥＣＵｍに対して順次同様の判定を行っていく。最終的には、ステップ２２３（Ｓ２２３）において、ＥＣＵ１は、いずれかの代行候補装置ＥＣＵｍに代行指令を送信する。以下の処理については図４と同様であるので説明を省略する。

さらに、ＥＣＵ１の代行送信可否判定手段１３は、ＥＣＵ２〜ＥＣＵｍがデータ送信処理を代行可能な状態か否かを判定する際に、各々のＥＣＵの処理重要度を参照し、処理重要度が低いＥＣＵから順に判定を行うようにしても良い。すなわち、重要度の高い処理を行っているＥＣＵには本来の処理を優先させ、重要度の低い処理を実施しているＥＣＵに代行させようとするものである。

図８は、代行候補装置である各ＥＣＵの処理重要度の一例を示している。代行送信可否判定手段１３は、図８に示すような各ＥＣＵの処理重要度を記憶したテーブルを備えており、代行候補装置であるＥＣＵ２〜ＥＣＵｍに対して代行可能な状態か否かを判定する順番を、各ＥＣＵの処理重要度に基づいて決定する。

車両走行中においては、走行に関する駆動系、事故防止等に必要となる安全系ＥＣＵの処理重要度が高くなる。ここで、ＥＣＵ５をシート調整、ライト調整等に関わるボディ系ＥＣＵ、ＥＣＵ４をナビゲーション装置またはスマートフォン連携等に係る情報系ＥＣＵ、ＥＣＵ３をＡＤＡＳ（Ａｄｖａｎｃｅｄ Ｄｒｉｖｉｎｇ Ａｓｓｉｓｔａｎｔ Ｓｙｓｔｅｍ）、エアバッグ等に関わる安全系ＥＣＵ、ＥＣＵ２をモータおよびエンジンに係る駆動系ＥＣＵとした時、その重要度は図８に示す順となる。

一方、車両停止中においては、ボディ系のライトやキーレスエントリー等が使われることが予想されるため、ボディ系ＥＣＵであるＥＣＵ５の重要度が高くなる。つまり、停止中においては、ＥＣＵ５の重要度が上がり、駆動系ＥＣＵであるＥＣＵ２の重要度が下がる。

図９は、本実施の形態１に係る制御装置切替システム１００において、ＥＣＵ１の代行送信可否判定手段１３がＥＣＵ２〜ＥＣＵｍの処理重要度に基づいて、代行装置を決定するまでの処理の流れを示すフローチャートである。図９では、車両走行中を想定しており、各ＥＣＵの処理重要度は図８に示す通りである。

ステップ２３（Ｓ２３）において、ＥＣＵ１の代行送信可否判定手段１３は、処理重要度の最も低いＥＣＵ５に対して、代行可能な状態か否かを判定する。この時の判定基準としては、前述のＥＣＵ５の処理負荷量や処理重要度、故障判定結果等が用いられる。Ｓ２３において、ＥＣＵ５が代行可能であると判定した場合（ＹＥＳ）、ステップ３１（Ｓ３１）に進み、ＥＣＵ１の代行要求送信手段１２はＥＣＵ５に対して代行要求を送信する。

一方、Ｓ２３において、ＥＣＵ５が代行不可であると判定した場合（ＮＯ）、ステップ２３１（Ｓ２３１）に進み、次に処理重要度の低いＥＣＵ４に対して代行可能な状態か否かを判定する。Ｓ２３１において、ＥＣＵ４が代行可能であると判定した場合（ＹＥＳ）、ステップ２３２（Ｓ２３２）に進み、代行要求送信手段１２はＥＣＵ４に対して代行要求を送信する。Ｓ２３１において、ＥＣＵ４が代行不可であると判定した場合は、次に処理重要度の低いＥＣＵ３に対して同様の判定を行い、最終的には、ステップ２３３（Ｓ２３３）において、ＥＣＵ１は、最も処理重要度の高いＥＣＵ２に代行指令を送信する。

このように、代行送信可否判定手段１３がＥＣＵ２〜ＥＣＵｍの処理重要度を考慮して代行可否判定を行うことにより、走行中に重要度の高い駆動系ＥＣＵや安全系ＥＣＵに代行させることを防止し、車両の動作を安定化させることができる。また、走行中と停止中で代行送信可否判定手段１３による判定の順番を変更することにより、ＥＣＵ２〜ＥＣＵｍ各々がシーン別に所望の動作を実行することが可能となる。

以上のように、本実施の形態１に係る制御装置切替システム１００によれば、通信制御装置ＥＣＵ１がスリープ状態や電源オフ状態になる前に、代行候補装置ＥＣＵ２〜ＥＣＵｍの中から、代行送信可否判定手段１３により代行可能であると判定されたＥＣＵに対して代行要求を送信するようにしたので、ＥＣＵ１が行うべきデータ送信処理を確実に代行させることができる。

さらに、ＥＣＵ１の代行送信可否判定手段１３がＥＣＵ２〜ＥＣＵｍの中から代行装置を決定する際の判定基準として、各ＥＣＵの代行可能処理負荷量、代行可能処理重要度、または故障判定結果を用い、さらに、走行中あるいは停止中における各ＥＣＵの処理重要度を考慮した順番で判定を行うことにより、ネットワーク６の異常や車両の挙動異常の発生を防止することができる。

実施の形態２．
図１０は、本発明の実施の形態２に係る制御装置切替システム１００Ａの構成を示している。また、図１１は、本実施の形態２における代行候補装置ＥＣＵ２の構成を示している。なお、本実施の形態２における通信制御装置ＥＣＵ１の構成は、上記実施の形態１と同様であるので図２（ａ）を流用する。

制御装置切替システム１００Ａにおいて、代行候補装置ＥＣＵ２〜ＥＣＵｍは、第２の代行要求送信手段である代行要求送信手段２２と、第２の代行送信可否判定手段である代行送信可否判定手段２３を備えている。代行要求送信手段２２は、データ送信処理を代行させる自身以外の代行候補装置に対して代行要求を送信する。また、代行送信可否判定手段２３は、自身および自身以外の代行候補装置について、データ送信処理を代行可能な状態か否かを判定する。

本実施の形態２に係る制御装置切替システム１００ＡにおけるＥＣＵ１およびＥＣＵ２〜ＥＣＵｍの動作について、図１０を用いて説明する。スリープ条件が成立したＥＣＵ１から代行要求１２ａを受信したＥＣＵ２は、データ送信処理の代行を開始した後、自身の代行送信可否判定手段２３により、自身がデータ送信処理を代行可能な状態か否かを判定する。なお、代行送信可否判定手段２３による判定基準としては、上記実施の形態１と同様に、各ＥＣＵの代行可能処理負荷量や代行可能処理重要度が用いられる。

自身が代行可能な状態ではないと判定した場合、自身以外の代行候補装置（ここではＥＣＵ３）に対し、代行送信可否判定手段２３により代行可否判定２３ａを行う。ＥＣＵ３が代行可能であると判定されると、ＥＣＵ２の代行要求送信手段２２はＥＣＵ３に代行要求２２ａを送信する。ＥＣＵ２から代行要求２２ａを受けたＥＣＵ３は、次の代行装置としてデータ送信処理の代行を開始する。

図１２は、制御装置切替システム１００Ａにおいて、代行装置ＥＣＵ２の代行送信可否判定手段２３が、他の代行候補装置ＥＣＵ３〜ＥＣＵｍの処理負荷量に基づいて、次の代行装置を決定するまでの処理の流れを示すフローチャートである。なお、図１２において、代行送信可否判定手段２３が参照する代行可能処理負荷量テーブルは、上記実施の形態１と同様であるので説明を省略する（図３参照）。

ステップ１１（Ｓ１１）において、代行装置ＥＣＵ２は、通信制御装置ＥＣＵ１の代行を開始する。続いてステップ２４（Ｓ２４）において、ＥＣＵ２の代行送信可否判定手段２３は、自身の処理負荷量ＰＬ_ｔｈ２を取得し、その値が代行可能処理負荷テーブルの代行可能処理負荷量ＰＬ_ｔｈ２を超えていない場合（ＹＥＳ）、そのまま代行を継続する。

一方、Ｓ２４において、ＥＣＵ２の処理負荷量が代行可能処理負荷量を超えていた場合（ＮＯ）、ＥＣＵ２の代行送信可否判定手段２３は、代行の継続が不可であると判定し、ステップ２４１（Ｓ２４１）に進む。Ｓ２４１では、ＥＣＵ２の代行送信可否判定手段２３は、ＥＣＵ３の処理負荷量を取得し、その値が代行可能処理負荷テーブルの代行可能処理負荷量ＰＬ_ｔｈ３を超えていない場合（ＹＥＳ）、ＥＣＵ３が代行可能であると判定し、その旨を代行要求送信手段２２に通知する。

続いてステップ２４２（Ｓ２４２）において、ＥＣＵ２の代行要求送信手段２２は、ＥＣＵ３に対して代行要求２２ａを送信する。その後、ステップ２４３（Ｓ２４３）でＥＣＵ２は代行を停止し、ステップ２４４（Ｓ２４４）でＥＣＵ３が代行を開始する。

一方、Ｓ２４１において、ＥＣＵ３の処理負荷量が代行可能処理負荷量ＰＬ_ｔｈ３を超えていた場合（ＮＯ）、ＥＣＵ２の代行送信可否判定手段２３は、ＥＣＵ３が代行不可であると判定し、別の代行候補装置ＥＣＵ４〜ＥＣＵｍに対して順次同様の判定を行っていく。最終的には、ステップ２４５（Ｓ２４５）において、ＥＣＵ２は、代行候補装置ＥＣＵｍに代行指令を送信し、ステップ２４６（Ｓ２４６）でＥＣＵ２は代行を停止し、ステップ２４７（Ｓ２４７）でＥＣＵｍが代行を開始する。

また、図１３は、制御装置切替システム１００Ａにおいて、代行装置ＥＣＵ２の代行送信可否判定手段２３が、他の代行候補装置ＥＣＵ３〜ＥＣＵｍの処理重要度に基づいて、次の代行装置を決定するまでの処理の流れを示すフローチャートである。なお、図１３において代行送信可否判定手段２３が参照する代行可能処理重要度テーブルは、上記実施の形態１と同様であるので説明を省略する（図６参照）。

Ｓ１１においてＥＣＵ１の代行を開始したＥＣＵ２は、ステップ２５（Ｓ２５）において、ＥＣＵ２の代行送信可否判定手段２３は、自身の処理重要度ＰＩ_ｔｈ２を取得し、その値が代行可能処理重要度テーブルの代行可能処理重要度ＰＩ_ｔｈ２を超えていない場合（ＹＥＳ）、そのまま代行送信を継続する。

一方、Ｓ２５において、ＥＣＵ２の処理重要度が代行可能処理重要度を超えていた場合（ＮＯ）、ＥＣＵ２の代行送信可否判定手段２３は、代行送信の継続が不可であると判断し、ステップ２５１（Ｓ２５１）に進む。Ｓ２５１では、ＥＣＵ２の代行送信可否判定手段２３は、ＥＣＵ３の処理重要度を取得し、その値が代行可能処理重要度テーブルの代行可能処理重要度ＰＩ_ｔｈ３を超えていない場合（ＹＥＳ）、ＥＣＵ３が代行可能であると判定し、その旨を代行要求送信手段２２に通知する。

一方、Ｓ２５１において、ＥＣＵ３の処理重要度が代行可能処理重要度ＰＩ_ｔｈ３を超えていた場合（ＮＯ）、ＥＣＵ２の代行送信可否判定手段２３は、ＥＣＵ３が代行不可であると判定する。以降のＳ２５２〜Ｓ２５７については、図１２のＳ２４２〜Ｓ２４７と同様であるので説明を省略する。

また、図１４は、本実施の形態２に係わる制御装置切替システムの他の構成を示している。図１４に示す制御装置切替システム１００Ｂでは、代行候補装置ＥＣＵ２〜ＥＣＵｍのうち、少なくとも１つ（図１４ではＥＣＵｍ）を監視制御装置とし、この監視制御装置により、通信制御装置ＥＣＵ１および代行候補装置ＥＣＵ２〜ＥＣＵ（ｍ−１）の故障を検出するものである。

監視制御装置は、少なくとも、故障判定手段と、代行送信継続判定手段と、第３の代行要求送信手段（いずれも図示省略）を有している。故障判定手段は、ＥＣＵ１およびＥＣＵ２〜ＥＣＵ（ｍ−１）の故障の有無を故障判定（図１４中、２３ｂで示す）する。代行送信継続判定手段は、データ送信処理を代行している代行候補装置（図１４ではＥＣＵ２）について代行の継続が可能か否かを故障判定手段の判定結果に基づいて判定する。第３の代行要求送信手段は、故障判定手段により故障が無いと判定された代行候補装置（図１４ではＥＣＵ３）に対してデータ送信処理の代行要求２２ｂを送信する。

図１５は、制御装置切替システム１００Ｂにおいて、監視制御装置ＥＣＵｍによる故障判定結果に基づいて次の代行装置を決定するまでの処理の流れを示すフローチャートである。ステップ２６（Ｓ２６）において、監視制御装置ＥＣＵｍの故障判定手段は、代行装置ＥＣＵ２の故障の有無を判定し、故障が無いと判定した場合（ＹＥＳ）、ＥＣＵｍの代行送信継続判定手段はＥＣＵ２による代行の継続が可能であると判定し、ＥＣＵ２はそのまま代行送信を継続する。

一方、Ｓ２６において、ＥＣＵ２に故障が有ると判定された場合（ＮＯ）、ＥＣＵｍの代行送信継続判定手段はＥＣＵ２による代行の継続が不可であると判定し、ステップ２６１（Ｓ２６１）に進む。Ｓ２６１では、ＥＣＵｍの故障判定手段がＥＣＵ３の故障の有無を判定し、故障が無いと判定した場合（ＹＥＳ）、ステップ２６２（Ｓ２６２）において、ＥＣＵｍの第３の代行要求送信手段は、ＥＣＵ３に対して代行要求２２ｂを送信する。その後、ステップ２６３（Ｓ２４３）でＥＣＵ２は代行を停止し、ステップ２６４（Ｓ２６４）でＥＣＵ３が代行を開始する。

一方、Ｓ２６１において、ＥＣＵ３に故障が有ると判定された場合（ＮＯ）、ＥＣＵｍは、次の代行候補装置ＥＣＵ４〜ＥＣＵ（ｍ−１）に対して順次同様の故障判定を行っていく。最終的には、ステップ２６５（Ｓ２６５）において、ＥＣＵｍは、代行候補装置ＥＣＵ（ｍ−１）に代行指令を送信し、ステップ２６６（Ｓ２６６）でＥＣＵ２は代行を停止し、ステップ２６７（Ｓ２６７）でＥＣＵ（ｍ−１）が代行を開始する。

本実施の形態２に係わる制御装置切替システム１００Ａによれば、上記実施の形態１と同様の効果に加え、代行候補装置ＥＣＵ２〜ＥＣＵｍの各々が代行要求送信手段２２と代行送信可否判定手段２３を備えているので、代行装置がデータ送信処理の代行を継続することができなくなった場合に、スリープ状態のＥＣＵ１を介さずに、次の代行装置を決定することができ、システムの信頼性が向上する。さらに、監視制御装置ＥＣＵｍを備え、ＥＣＵ２〜ＥＣＵ（ｍ−１）の故障を検出することにより、代行装置の故障を早期に検出することができると共に、故障が有る代行候補装置に代行させることを防止することができる。

実施の形態３．
図１６は、本発明の実施の形態３に係る制御装置切替システム１００Ｃの構成を示している。また、図１７（ａ）は、通信制御装置ＥＣＵ１の構成を示し、図１７（ｂ）は、代行候補装置ＥＣＵ２の構成を示している。その他の代行候補装置ＥＣＵ３〜ＥＣＵｍの構成は、ＥＣＵ２と同様であるので、図示および説明を省略する。

本実施の形態３における通信制御装置ＥＣＵ１は、データ送受信実行／停止手段１１、代行要求送信手段１２、スリープ条件成立判定手段１４、スリープ処理手段１５、およびウェイク処理手段１６を有している。また、ＥＣＵ２〜ＥＣＵｍから送信された代行要求送信手段２３Ａによる判定結果を一時的に蓄積する一時記憶装置７（図１８）を備えている。一方、実施の形態１および実施の形態２におけるＥＣＵ１が備えていた代行送信可否判定手段１３を備えていない。

代行要求送信手段１２は、ＥＣＵ１がデータ送信処理を停止する前に全ての代行候補装置ＥＣＵ２〜ＥＣＵｍに対して一斉に仮代行要求を送信すると共に、データ送信処理を代行させる代行候補装置（図１６ではＥＣＵ２）に対して本代行要求を送信する。

また、本実施の形態３における代行候補装置ＥＣＵ２は、代行送信手段２１と、第３の代行要求送信手段である代行要求送信手段２２Ａと、第３の代行送信可否判定手段である代行送信可否判定手段２３Ａを備えている。代行送信可否判定手段２３Ａは、ＥＣＵ１からの仮代行要求を受信した場合に自身がデータ送信処理を代行可能な状態か否かを判定する。代行要求送信手段２２Ａは、データ送信処理を代行させる自身以外の代行候補装置に対して代行要求を送信する。代行送信手段２１は、ＥＣＵ１からの本代行要求を受信した場合にデータ送信処理の代行を実行する。

本実施の形態３に係る制御装置切替システム１００ＣにおけるＥＣＵ１およびＥＣＵ２〜ＥＣＵｍの動作について、図１６を用いて説明する。ＥＣＵ１は、自身のタイマ処理等によってスリープ条件が成立すると、データ送信処理を停止する前に、代行要求送信手段１２により、全ての代行候補装置ＥＣＵ２〜ＥＣＵｍに対して一斉に仮代行要求１２ａを送信する。

ＥＣＵ１からの仮代行要求１２ａを受信したＥＣＵ２〜ＥＣＵｍは、代行送信可否判定手段２３Ａにより、自身がデータ送信処理を代行可能な状態か否かを判定し、代行可能であると判定された場合、その判定結果２３ｃをＥＣＵ１に送信する。なお、代行送信可否判定手段２３Ａによる判定基準としては、上記実施の形態１と同様に、各ＥＣＵの代行可能処理負荷量や代行可能処理重要度が用いられる。ＥＣＵ１は、ＥＣＵ２〜ＥＣＵｍから送信された判定結果を一時記憶装置７に記憶する。

ＥＣＵ１は、ＥＣＵ２〜ＥＣＵｍから送信された判定結果２３ｃに基づいてデータ送信処理を代行させる代行候補装置を決定し（図１６ではＥＣＵ２）、ＥＣＵ２に対して代行要求送信手段１２から本代行要求１２ｂを送信する。ＥＣＵ２の代行送信手段２１は、ＥＣＵ１からの本代行要求１２ｂを受信し、データ送信処理の代行を開始する。

なお、一時記憶装置７には、図１８に示すような代行可能ＥＣＵキューが用いられる。代行可能ＥＣＵキューは、代行可能なＥＣＵ２〜ＥＣＵｍが自身の識別情報を登録するリストである。なお、代行可能ＥＣＵキューは、ＥＣＵ１だけでなくＥＣＵ２〜ＥＣＵｍが共有するようにしても良い。これにより、上記実施の形態２に係わる制御装置切替システム１００Ａにおいて、代行装置が次の代行装置を決定する際に代行可能ＥＣＵキューを用いることができる。

また、代行可能ＥＣＵキューは、代行送信可否判定手段２３Ａによる判定の結果、代行可能であると判定された代行候補装置を、処理重要度の低いものから順に蓄積する優先度付きキューである。図１８では、ＥＣＵ２、ＥＣＵ４・・の順に処理重要度が低いことになる。ＥＣＵ１の代行要求送信手段１２は、代行可能ＥＣＵキューに蓄積された順に本代行要求１２ｂを送信する。このように、処理重要度の低いＥＣＵからキューに格納し、その順に本代行要求１２ｂを送信することにより、処理重要度の低いＥＣＵを代行装置として選択するようにし、重要度の高い処理を行うＥＣＵを代行装置にする可能性を小さくする。

図１９は、本発明の実施の形態３に係る制御装置切替システム１００Ｃにおいて、ＥＣＵ１がＥＣＵ２〜ＥＣＵｍの中から代行装置を決定する処理の流れを示すフローチャートである。まず、Ｓ１０において、ＥＣＵ１のスリープ条件が成立すると（ＹＥＳ）、ステップ３２（Ｓ３２）において、ＥＣＵ１の代行要求送信手段１２は、ＥＣＵ２〜ＥＣＵｍに対して仮代行要求１２ａを一斉送信する。

続いてステップ３３（Ｓ３３）において、仮代行要求１２ａを受信したＥＣＵ２〜ＥＣＵｍは、自身の代行送信可否判定手段２３Ａにより代行可能な状態であるか否かを判定し、代行可能であると判定されたＥＣＵは、自身の識別番号を代行可能ＥＣＵキューに登録する。ステップ３４（Ｓ３４）において、ＥＣＵ１は代行可能ＥＣＵキューを参照し、キューに蓄積が有るか否かを判断する。

Ｓ３４において蓄積がある場合（ＹＥＳ）は、ステップ３５（Ｓ３５）に進み、ＥＣＵ１の代行要求送信手段１２は、代行可能ＥＣＵキューに一番目に蓄積されたＥＣＵ２に本代行要求１２ｂを送信すると共に、スリープ処理手段１５に通知しスリープを開始する。続いてステップ３６（Ｓ３６）においてＥＣＵ２が代行を開始し、ステップ３７（Ｓ３７）に進む。一方、Ｓ３４において蓄積がない場合（ＮＯ）、ステップ３４１（Ｓ３４１）に進み、蓄積が有るまで待ち、蓄積無しが１０回以上となった場合（ＹＥＳ）は、代行させるＥＣＵがないものとして代行させない。

Ｓ３７において、代行装置であるＥＣＵ２は、自身の代行送信可否判定手段２３Ａにより代行可能な状態であるか否かを判定し、代行可能であると判定された場合（ＹＥＳ）、そのまま代行を継続する。一方、代行不可であると判定された場合（ＮＯ）、ステップ３８（Ｓ３８）に進み、代行可能ＥＣＵキューを参照する。

Ｓ３８において、キューに蓄積が有る場合（ＹＥＳ）、ＥＣＵ２の代行要求送信手段２２Ａは、代行可能ＥＣＵキューに蓄積されたＥＣＵ４に代行要求を送信する。続いてステップ３９（Ｓ３９）において、代行要求を受信したＥＣＵ４が代行を開始すると共に、ＥＣＵ２は代行を停止する。一方、Ｓ３８において蓄積がない場合（ＮＯ）、Ｓ３７、Ｓ３８を繰り返し、代行可能なＥＣＵがキューに登録するのを待つ。

なお、図１９では、Ｓ３４１において、キューを確認する回数を１０回までとしているが、ＥＣＵ１のスリープ条件成立時において、マイコンのリアルタイム性が保証される時間内であれば、１１回目以降もキューの確認を実施することができる。また、本実施の形態３では、代行可能ＥＣＵキューとして、ＥＣＵの処理重要度が低い順に蓄積する優先度付きキューとしたが、単に登録された順に蓄積するものを用いることもできる。

本実施の形態３によれば、通信制御装置ＥＣＵ１がスリープ状態や電源オフ状態になる前に、全ての代行候補装置ＥＣＵ２〜ＥＣＵｍに対して一斉に仮代行要求１２ａを送信し、代行送信可否判定手段２３Ａにより代行可能であると判定された代行候補装置に対して本代行要求１２ｂを送信するようにしたので、通信制御装置が行うべきデータ送信処理を確実に代行させることができる。

また、ＥＣＵ１に特別な代行送信可否判定手段を実装する必要がなく、ＥＣＵ１による処理数を少なくできるため、スリープ条件成立からスリープ状態に入るための時間を短くすることができる。また、ＥＣＵ２〜ＥＣＵｍ各々による代行可否判定結果を記憶する一時記憶装置７として、処理重要度の低いＥＣＵから順に蓄積する優先度付きキューを用いることにより、重要度の高い処理を行うＥＣＵが代行装置となる可能性が小さくなり、車両の動作に異常を与える可能性が軽減される。

実施の形態４．
図２０は、本発明の実施の形態４における代行候補装置ＥＣＵ２の構成を示している。その他の代行候補装置ＥＣＵ３〜ＥＣＵｍの構成は、ＥＣＵ２と同様であるので、図示および説明を省略する。なお、本実施の形態４における通信制御装置ＥＣＵ１の構成は、上記実施の形態１と同様であるので図２（ａ）を流用する。

本実施の形態４における代行候補装置ＥＣＵ２〜ＥＣＵｍは、所定時刻における通信制御装置ＥＣＵ１からの受信データとその時の自身の内部変数を蓄積する記憶手段である記憶装置２４と、該所定時刻における代行候補装置の内部変数と受信データとを比較して、該代行候補装置がデータ送信処理を代行する際の送信データを導出する代行データ導出手段２５を備えている。

記憶装置２４は、通信制御装置ＥＣＵ１がスリープによって送受信を停止するまでデータの記憶を行う。記憶装置２４に記憶されるデータは、ＥＣＵ１からの受信データと、その時自身がもつグローバル変数等の内部変数のデータである。記憶する周期等は、代行候補装置ＥＣＵ２〜ＥＣＵｍ各々の処理負荷の余裕度等から決定される。代行データ導出手段２５は、記憶装置２４が蓄積したデータから、対応するＥＣＵ１の受信データの履歴とグローバル変数の相関を導出し、この相関に従って自身が代行する送信データを決定する。これにより、代行候補装置により代行される送信データは、ＥＣＵ１により送信されていたデータに適合したものとなる。

図２１は、代行装置ＥＣＵ３の記憶装置２４に記憶されるテーブルであり、（ａ）は通常時のＥＣＵ１からの受信データとその時のＥＣＵ３の内部変数Ｂ、（ｂ）は代行時のＥＣＵ３による送信データとその時のＥＣＵ３の内部変数Ｂを示している。通常時、ＥＣＵ３は、所定時刻におけるＥＣＵ１からの受信データ（ＥＣＵ１シグナルＡ）と、その時のＥＣＵ３の内部変数Ｂを記憶し、変数Ｂに対応したシグナルＡのテーブルを作成する。代行時には、代行データ導出手段２５は、ＥＣＵ１からの受信データとその時の自身の内部変数に基づいて、代行装置から送信する送信データ（ＥＣＵ３シグナルＡ）を導出する。

具体的には、図２１（ａ）に示すように、時刻ｔ１ではＥＣＵ１のシグナルはＡ１、ＥＣＵ３の変数ＢはＢ１であり、時刻ｔ２ではＥＣＵ１のシグナルはＡ２、ＥＣＵ３の変数ＢはＢ２、時刻ｔ３ではＥＣＵ１のシグナルはＡ３、ＥＣＵ３の変数ＢはＢ３・・・となっている。ここで、ＥＣＵ１のシグナルＡとＥＣＵ３の変数Ｂが１対１の関係である場合、代行時にＥＣＵ３が送信するデータのシグナルは図２１（ｂ）のようになる。すなわち、時刻ｔｎにおいてＥＣＵ３の変数ＢがＢ３であった場合、ＥＣＵ３が代行する送信データのシグナルはＡ３となり、時刻ｔｎ＋１においてＥＣＵ３の変数ＢがＢ１であった場合、ＥＣＵ３が代行する送信データのシグナルはＡ１となる。

なお、図２１に示す例では、ＥＣＵ３が出力すべきデータと対応するＥＣＵ１の出力データの履歴と、その時のＥＣＵの内部変数とが１対１の関係である場合について例を挙げて説明したが、代行データ導出手段２５によるデータ導出方法はこれに限定されるものではなく、両データに相関がとれるような手段であればよい。例えば、変数Ｂに対するシグナルＡの値が逐次異なる場合は、或る変数Ｂ１に対応するシグナルＡの値を平均する手法や統計手法等を用いてもよい。

本実施の形態４によれば、代行候補装置ＥＣＵ２〜ＥＣＵｍが代行データ導出手段２５を備えることにより、代行装置は、通信制御装置ＥＣＵ１が本来送信すべきデータに近い値を出力することができ、他のＥＣＵが該データを受信する際に、データが所定範囲で変動するようになるため、ネットワーク異常として検出されにくい。また、該データを用いて演算等の処理を行うＥＣＵがある場合、それらの演算結果に与える影響を小さくすることができる。

実施の形態５．
図２２は、本発明の実施の形態５における代行候補装置ＥＣＵ２の構成を示している。その他の代行候補装置ＥＣＵ３〜ＥＣＵｍの構成は、ＥＣＵ２と同様であるので、図示および説明を省略する。なお、本実施の形態５における通信制御装置ＥＣＵ１の構成は、上記実施の形態１と同様であるので図２（ａ）を流用する。

本実施の形態５における代行候補装置ＥＣＵ２〜ＥＣＵｍは、所定時刻において送信不要なデータを判定する不要データ判定手段（図示省略）と、該代行候補装置がデータ送信処理を代行する際に不要データ判定手段による判定結果に基づいて送信データを間引きし送信データの内容を調整するデータ調整手段２６とを備えている。

図２３は、通信制御装置ＥＣＵ１と代行装置ＥＣＵ３のデータ送信処理に関し、ＥＣＵ１のスリープ条件成立前後における変化を示すタイムチャートである。図２３において、横軸は時間を示し、時刻ｔ１は、ＥＣＵ１のスリープ条件成立時を示している。また、「送１」は、ＥＣＵ１以外のＥＣＵ向けのデータ送信処理、「送２」は、ＥＣＵ１向けのデータ送信処理、「送３」は、ＥＣＵ３以外のＥＣＵ向けのデータ送信処理である。

時刻ｔ１においてＥＣＵ１のスリープ条件が成立すると、代行要求を受信し代行装置となったＥＣＵ３の不要データ判定手段は、ＥＣＵ１に向けてのデータ送信処理、図２３では「送２」は、不要であると判定する。ＥＣＵ３のデータ調整手段２６は、ＥＣＵ１から代行要求を受信した後、不要データ判定手段による判定結果に基づいて「送２」を停止し、ＥＣＵ１が本来行うべき「送１」を削減した送信データ部に割り当てる。

このようなデータ調整手段２６による送信データの削減および割り当て機能により、ＥＣＵ２〜ＥＣＵｍがＥＣＵ１から受信するデータ量（代行装置が送信すべきデータ量）が、ＥＣＵ２〜ＥＣＵｍからＥＣＵ１に向けて送信されるデータ量以下である場合は、ＥＣＵ１がスリープする前後でＥＣＵ２〜ＥＣＵｍが代行装置となった時に送信するデータ量は、変化無しまたは減少することになる。

本実施の形態５によれば、代行候補装置ＥＣＵ２〜ＥＣＵｍがデータ調整手段２６を備えることにより、代行装置の制御周期に影響を与えることなく、通信制御装置ＥＣＵ１のデータ送信処理を代行することが可能である。これにより、代行装置の処理負荷の増加を抑えることができ、代行装置の処理負荷が所定の制御周期内に収まらずシステムのリアルタイム性を失うような事態を防止することができる。

実施の形態６．
図２４は、本発明の実施の形態６における代行候補装置ＥＣＵ２の構成を示している。その他の代行候補装置ＥＣＵ３〜ＥＣＵｍの構成は、ＥＣＵ２と同様であるので、図示および説明を省略する。なお、本実施の形態６における通信制御装置ＥＣＵ１の構成は、上記実施の形態１と同様であるので図２（ａ）を流用する。

本実施の形態６における代行候補装置ＥＣＵ２〜ＥＣＵｍは、自身の制御周期を調整する制御周期調整手段２７を備え、ＥＣＵ１から代行要求を受信した際に、制御周期調整手段２７により自身の制御周期を平常時よりも長くするものである。

図２５は、通信制御装置ＥＣＵ１と代行装置ＥＣＵ３のデータ送信処理に関し、ＥＣＵ１のスリープ条件成立前後における変化を示すタイムチャートである。図２５において、横軸は時間を示し、時刻ｔ１は、ＥＣＵ１のスリープ条件成立時を示している。また、「送１」は、ＥＣＵ１以外のＥＣＵ向けのデータ送信処理、「送３」は、ＥＣＵ３以外のＥＣＵ向けのデータ送信処理であり、ここではＥＣＵ１の代行装置として割り当てられたデータ送信処理である。

時刻ｔ１においてＥＣＵ１のスリープ条件が成立すると、代行要求を受信し代行装置となったＥＣＵ３の制御周期調整手段２７は、自身の制御周期を平常時の処理周期１よりも長い処理周期２に変更する。その際、制御周期２は、ＥＣＵ３の通常時の演算処理に加えてＥＣＵ１が行うべきデータ送信処理の代行を行えるように設定される。これにより、ＥＣＵ１が本来行うべきデータ送信処理を代行する場合でも、制御周期２内に処理を完了させることができる。

本実施の形態６によれば、代行候補装置ＥＣＵ２〜ＥＣＵｍが制御周期調整手段２７を備えることにより、代行装置となった際に制御周期を長くすることができるため、代行を開始しても制御周期内に自身の本来行うべき演算処理と代行装置としてのデータ送信処理とを完了させることができる。また、処理負荷に余裕がある場合は、制御周期を長くすることにより、制御周期内のアイドル時間が増加するため、消費電力を削減することができる。

実施の形態７．
図２６は、本発明の実施の形態７における代行候補装置ＥＣＵ２の構成を示している。その他の代行候補装置ＥＣＵ３〜ＥＣＵｍの構成は、ＥＣＵ２と同様であるので、図示および説明を省略する。なお、本実施の形態７における通信制御装置ＥＣＵ１の構成は、上記実施の形態１と同様であるので図２（ａ）を流用する。

本実施の形態７における代行候補装置ＥＣＵ２〜ＥＣＵｍは、ＥＣＵ１がスリープ状態になることを検出した際に、自身の動作クロック周波数を調整するクロック周波数調整手段２８を備えている。代行候補装置は、ＥＣＵ１から代行要求を受信した際に、クロック周波数調整手段２８により自身のクロック周波数を通常時よりも低下させる。

図２７は、代行装置ＥＣＵ３のデータ送信処理に関し、ＥＣＵ１のスリープ条件成立前後における変化を示すタイムチャートである。図２７において、横軸は時間を示し、時刻ｔ１は、ＥＣＵ１のスリープ条件成立時を示している。また、「送３」は、ＥＣＵ３以外のＥＣＵ向けのデータ送信処理であり、ここではＥＣＵ１の代行装置として割り当てられたデータ送信処理である。

時刻ｔ１においてＥＣＵ１のスリープ条件が成立すると、代行要求を受信し代行装置となったＥＣＵ３のクロック周波数調整手段２８は、時刻ｔ１以前よりもクロック周波数を通常時よりも低く例えば半分にする。クロック周波数を低くすることにより、処理に要する時間が長くなる。ＥＣＵ３のクロック周波数を低くする際には、通常の処理周期１内に、ＥＣＵ３の通常時の演算処理に加えてＥＣＵ１が行うべきデータ送信処理の代行を行えるようにクロック周波数を設定する。

本実施の形態７によれば、代行候補装置ＥＣＵ２〜ＥＣＵｍがクロック周波数調整手段２８を備えることにより、代行装置となった際にアイドル時間の減少により消費電力が増加するのに対し、クロック周波数の低減による消費電力の削減を行い、全体的な消費電力増加を抑制することができる。

実施の形態８．
図２８は、本発明の実施の形態８における代行候補装置ＥＣＵ２の構成を示している。その他の代行候補装置ＥＣＵ３〜ＥＣＵｍの構成は、ＥＣＵ２と同様であるので、図示および説明を省略する。なお、本実施の形態８における通信制御装置ＥＣＵ１の構成は、上記実施の形態１と同様であるので図２（ａ）を流用する。

本実施の形態８における代行候補装置ＥＣＵ２〜ＥＣＵｍは、データ同期手段２９を備えており、ＥＣＵ１から代行要求を受信した際に、次のデータ送信制御周期においてデータ送信処理を開始することができる。

図２９は、通信制御装置ＥＣＵ１と代行装置ＥＣＵ３のデータ送受信信号に関し、ＥＣＵ１のスリープ条件成立前後における変化を示すタイムチャートである。図２９において、横軸は時間を示し、時刻ｔ１は、ＥＣＵ１のスリープ条件成立時を示している。

時刻ｔ１においてＥＣＵ１のスリープ条件が成立すると、ＥＣＵ３は、ｔ１の後の時刻ｔ２における受信周期（ｓ１）で代行要求を受信する。代行要求の受信により代行装置となったＥＣＵ３のデータ同期手段２９は、受信周期（ｓ１）の直後の時刻ｔ３における送信周期（ｓ２）で代行を開始する。すなわち、代行要求を受信した後、１回目の送信周期でＥＣＵ１の代行としてのデータ送信処理を行うものである。

本実施の形態８によれば、代行候補装置ＥＣＵ２〜ＥＣＵｍがデータ同期手段２９を備えることにより、通信制御装置の通信の停止から代行装置による代行開始までの時間を短くすることができ、ネットワーク異常として検出されることを防止することができる。

実施の形態９．
図３０は、本発明の実施の形態９における通信制御装置ＥＣＵ１の構成を示している。また、本実施の形態９における代行候補装置ＥＣＵ２〜ＥＣＵｍの構成は、上記実施の形態８と同様であるので、図示および説明を省略する。

本実施の形態９における通信制御装置ＥＣＵ１は、代行装置に対しデータ送信処理を停止させる代行停止要求送信手段１７を備えている。ＥＣＵ１は、スリープ状態から復帰しデータ送信処理を再開する際に、代行停止要求送信手段１７により代行装置に対して代行停止要求を送信する。代行停止要求を受信した代行装置は、データ送信処理を停止する。

図３１は、本実施の形態９に係る制御装置切替システムのＥＣＵ１が、代行装置ＥＣＵ３に代行を停止させる際の処理の流れを示すフローチャートである。ステップ１２（Ｓ１２）において、スリープ状態にあるＥＣＵ１がスリープ状態から解除され、データ送信処理が可能となる条件が成立した場合（ＹＥＳ）、ステップ１２１（Ｓ１２１）に進み、ＥＣＵ１の代行停止要求送信手段１７は、ＥＣＵ３の代行送信手段２１に代行停止要求を送信する。

続いてステップ１２２（Ｓ１２２）において、ＥＣＵ１は、データ送受信実行／停止手段１１によりデータの送受信を再開し、ステップ１２３（Ｓ１２３）においてＥＣＵ３の代行送信手段２１は、代行停止要求に応じて代行しているデータ送信を停止する。

本実施の形態９によれば、通信制御装置ＥＣＵ１が代行停止要求送信手段１７を備えることにより、ＥＣＵ１がデータ送信処理を再開する際に代行装置による代行を停止することができ、ＥＣＵ１が送信するデータを代行装置が上書きすることを防止することができる。

実施の形態１０．
図３２（ａ）は、本発明の実施の形態１０における通信制御装置ＥＣＵ１の構成を示し、図３２（ｂ）は、代行候補装置ＥＣＵ２の構成を示している。その他の代行候補装置ＥＣＵ３〜ＥＣＵｍの構成は、ＥＣＵ２と同様であるので、図示および説明を省略する。

本実施の形態１０における通信制御装置ＥＣＵ１は、代行装置の代行を時間で管理するための機能として、ウェイクタイマ設定手段１８とタイマ割込みウェイク手段１９を備えている。また、代行候補装置ＥＣＵ２〜ＥＣＵｍは、再開時間計測手段であるウェイクタイマカウント手段３０を備えている。

ＥＣＵ１に搭載されるウェイクタイマ設定手段１８は、ＥＣＵ１がスリープ開始してからデータ送信処理の再開が可能となるまでの再開時間であるウェイクタイマの値をスリープ条件に応じて設定する。ウェイクタイマには、例えばマイクロコンピュータのＲＯＭ書き換えに必要な時間が設定される。ＲＯＭ書き換え時には、マイクロコンピュータの送受信処理が一定時間停止するが、書き換えに要する時間は予測できるため、ウェイクタイマ設定手段１８でその予測時間を設定すると、書き換え終了次第復帰することができる。

タイマ割込みウェイク手段１９は、ウェイクタイマ設定手段１８により設定された所定の再開時間後に、ＥＣＵ１のデータ送信処理を再開させる。ＥＣＵ１は、代行候補装置に代行要求と再開時間を送信し、ウェイクタイマ設定手段１８によって設定された再開時間が経過後、タイマ割込みウェイク手段１９によってウェイクアップし、データ送信処理を再開する。なお、タイマ割込みウェイク手段１９は、例えば外付けに搭載されたタイマ割込み用ハードウェア等による割込みによって行われる。

一方、代行装置は、代行要求を受信しデータ送信処理の代行を開始すると同時にウェイクタイマカウント手段３０により時間を計測し、所定の再開時間後にデータ送信処理の代行を停止する。ウェイクタイマカウント手段３０は、代行候補装置ＥＣＵ２〜ＥＣＵｍに搭載されており、代行装置が代行要求を受信した後カウントアップが始まり、ウェイクタイマ設定手段１８によって設定された値までカウントすると代行を停止させる。

図３３は、本実施の形態１０に係る制御装置切替システムのＥＣＵ１が、代行装置ＥＣＵ３の代行を時間で管理する処理の流れを示すフローチャートである。Ｓ１０において、ＥＣＵ１は、スリープ条件成立判定手段１４によりスリープ条件が成立しているか否かを判定し、スリープ条件が成立している場合（ＹＥＳ）、ステップ１０１（Ｓ１０１）に進み、ウェイクタイマ設定手段１８により、スリープ条件に適したウェイクタイマの値ＷＴ_ｔｈ３を設定する。ウェイクタイマ設定手段１８は、設定を完了した旨を代行要求送信手段１２に通知する。なお、Ｓ１０において、スリープ条件が成立していない場合は、代行に関する処理を行わない。

続いてステップ１０２（Ｓ１０２）において、代行要求送信手段１２は、代行要求とウェイクタイマ値を、代行装置であるＥＣＵ３に送信する。ステップ１０２（Ｓ１０３）では、ＥＣＵ１は、タイマ割込みウェイク手段１９のタイムカウント機能により、ウェイクアップまでの時間カウントを開始し、ＥＣＵ３は代行を開始する。続いてステップ１０４（Ｓ１０４）において、代行を開始したＥＣＵ３は、ウェイクタイマカウント手段３０により、設定されたウェイクタイマＷＴ_ｔｈ３の値までカウントアップする

Ｓ１０４において、ウェイクタイマカウント値＜ＷＴ_ｔｈ３の場合（ＹＥＳ）はそのままカウントアップを続け、ウェイクタイマカウント値≧ＷＴ_ｔｈ３の場合（ＮＯ）、ステップ１０５（Ｓ１０５）に進む。Ｓ１０５では、ＥＣＵ３は、代行送信手段２１により代行を停止する。それと同期する形で、ＥＣＵ１はタイマ割込みウェイク手段１９によりウェイクしてデータ送信処理を再開する。

なお、ウェイクタイマ設定手段１８により設定される値は、ＥＣＵ３が代行要求を受信するまでの時間と、ＥＣＵ１がスリープ開始によってデータ送信処理を停止してから再開されるまでの時間とを足した時間とすることで、ＥＣＵ１の送信再開とＥＣＵ３の代行停止のタイムラグを少なくすることができる。

本実施の形態１０によれば、通信制御装置ＥＣＵ１がウェイクタイマ設定手段１８とタイマ割込みウェイク手段１９を備えると共に、代行候補装置ＥＣＵ２〜ＥＣＵｍがウェイクタイマカウント手段３０を備えることにより、ＥＣＵ１がスリープ解除しデータ送信処理を再開する際に、代行装置に対して代行停止要求を送信する必要がなく、即座に通常のデータ送信処理を再開することができる。

実施の形態１１．
図３４は、本発明の実施の形態１１における代行候補装置ＥＣＵ２の構成を示している。その他の代行候補装置ＥＣＵ３〜ＥＣＵｍの構成は、ＥＣＵ２と同様であるので、図示および説明を省略する。なお、本実施の形態１１における通信制御装置ＥＣＵ１の構成は、上記実施の形態１と同様であるので図２（ａ）を流用する。

本実施の形態１１における代行候補装置ＥＣＵ２〜ＥＣＵｍは、自身のデータ送信周期を調整するデータ通信周期調整手段３１を備え、通信制御装置ＥＣＵ１から代行要求を受信した際に、データ通信周期調整手段３１によりデータ送信周期を通常時よりも短くするものである。

データ送信周期の調整方法について説明する。通信制御装置ＥＣＵ１と代行装置の送信周期が同じ２００ｍｓｅｃであり、ＥＣＵ１の送信タイミングに対し代行装置の送信タイミングが５０ｍｓｅｃ遅いと仮定した場合、代行装置の送信タイミングを通常時より５０ｍｓｅｃ以上早くする必要がある。５０ｍｓｅｃ早くするためには、送信周期を１５０ｍｓｅｃ以下にする必要があり、送信周期を１５０／２００＝０．７５倍すれば良い。ただしデータ送信周期の調整方法はこれに限定されるものではない。

図３５は、通信制御装置ＥＣＵ１と代行装置ＥＣＵ３のデータ送受信信号に関し、ＥＣＵ１のスリープ条件成立前後における変化を示すタイムチャートである。図３５において、（ａ）はデータ通信周期調整手段３１による周期調整を行わないＮＧ例、（ｂ）はデータ通信周期調整手段３１による周期調整を行ったＯＫ例である。図３５において、横軸は時間を示し、時刻ｔ１はＥＣＵ１のスリープ条件成立時を示している。

図３５（ａ）では、時刻ｔ１においてＥＣＵ１のスリープ条件が成立すると、ＥＣＵ３は、時刻ｔ１の後の受信周期（ｓ１）で代行要求を受信する。代行要求の受信により代行装置となったＥＣＵ３は、通常周期であるため、時刻ｔ４における次の送信周期（ｓ２）でＥＣＵ１の代行としてのデータ送信処理を含むデータ送信を行う。この場合、ＥＣＵ１の本来の送信周期（ｓ３）の時刻ｔ３よりも遅くなり、遅延時間（Δｔ）が生じている。

この例のように、ＥＣＵ１とＥＣＵ３のデータ送信周期のオフセットによっては、ＥＣＵ１が本来データ送信していなければならない時刻ｔ３において、ＥＣＵ３はデータを送信できていないため、ネットワーク異常を発生させる可能性がある。

一方、図３５（ｂ）では、時刻ｔ１においてＥＣＵ１のスリープ条件が成立し、時刻ｔ１の後の受信周期（ｓ１）で代行要求を受信した代行装置ＥＣＵ３は、データ通信周期調整手段３１により、データ送信周期を通常時よりも短い例えば１／２周期にする。これにより、時刻ｔ２における次の送信周期（ｓ２）でＥＣＵ１の代行としてのデータ送信処理を含むデータ送信を行うことができ、ＥＣＵ１の本来の送信周期（ｓ３）の時刻ｔ３に間に合う。

本実施の形態１１によれば、代行候補装置ＥＣＵ２〜ＥＣＵｍがデータ通信周期調整手段３１を備えることにより、代行装置によるデータ送信処理のタイミングを、通信制御装置ＥＣＵ１により本来送信される時刻に間に合うように調整することができるため、ネットワーク異常を発生させることを防止することができる。

実施の形態１２．
図３６は、本発明の実施の形態１２における代行候補装置ＥＣＵ２の構成を示している。その他の代行候補装置ＥＣＵ３〜ＥＣＵｍの構成は、ＥＣＵ２と同様であるので、図示および説明を省略する。なお、本実施の形態１２における通信制御装置ＥＣＵ１の構成は、上記実施の形態１と同様であるので図２（ａ）を流用する。

本実施の形態１２における代行候補装置ＥＣＵ２〜ＥＣＵｍは、上記実施の形態１１で説明したデータ通信周期調整手段３１に加え、さらに、通信制御装置ＥＣＵ１がデータ送信処理を停止すると予測される車両状況や車両周辺状況を検出する車両状況検出手段３２を備えている。ＥＣＵ２〜ＥＣＵｍは、車両状況検出手段３２により、ＥＣＵ１がデータ送信処理を停止すると予測される車両状況が検出された際には、データ通信周期調整手段３１によりデータ送信周期を通常時よりも短くするものである。

車両状況検出手段３２により検出される車両状況について説明する。例えばＥＣＵ１がアイドリング中にスリープ状態に入るシャーシ系ＥＣＵ等の場合、車両状況検出手段３２は、アイドリング状態になる前に現れる車速の減速を検出する。また、ＥＣＵ１が走行中にスリープ状態に入るボディ系ＥＣＵ等の場合、車両状況検出手段３２は、停車状態から走行状態になる前に現れる車速の増加を検出する。

図３７は、通信制御装置ＥＣＵ１と代行装置ＥＣＵ３のデータ送受信信号に関し、ＥＣＵ１のスリープ条件成立前後における変化を示すタイムチャートである。図３７において、横軸は時間を示し、時刻ｔ１はＥＣＵ１のスリープ条件成立時を示している。ＥＣＵ３は、時刻ｔ０におけるデータ受信周期（ｓ０）で、車両状況検出手段３２からＥＣＵ１のスリープを予測するデータを受信する。このスリープ予測データを受信したＥＣＵ３は、データ通信周期調整手段３１により、データ受信とデータ送信周期を通常時よりも短い例えば１／２周期にする。

これにより、通常周期よりも早い時刻となった受信周期（ｓ１）でＥＣＵ１の代行要求を受信し、代行を開始することができる。さらに、時刻ｔ２における次の送信周期（ｓ２）でＥＣＵ１の代行としてのデータ送信処理を含むデータ送信を行うことができ、ＥＣＵ１の本来の送信周期（ｓ３）の時刻ｔ３に間に合う。

また、データ通信周期調整手段３１は、データ通信周期を短くするだけでなく、長くすることもできる。データ通信周期調整手段３１は、代行候補装置がデータ送信処理の代行を開始した後、通常時よりも短くしたデータ送信周期を元に戻す。

図３８は、通信制御装置ＥＣＵ１と代行装置ＥＣＵ３のデータ送受信信号に関し、ＥＣＵ１のスリープ条件成立前後における変化を示すタイムチャートである。図３８において、横軸は時間を示し、時刻ｔ１はＥＣＵ１のスリープ条件成立時を示している。受信周期（ｓ１）でＥＣＵ１の代行要求を受信し、代行を開始したＥＣＵ３は、データ通信周期調整手段３１により、データ送信周期を通常周期の１／２とする。その後、データ送信周期が所定回数経過した時刻ｔ５において、データ送信周期を通常周期に戻す。

ＥＣＵ３がデータ通信周期調整手段３１によりデータ送信周期を通常周期よりも短くしている場合、代行を開始した後もその状態を継続していると、ＥＣＵ３のデータ送受信の負荷が増加し、全体的に処理負荷が増加する。所定の周期後にデータ送信周期を元に戻すことにより、代行送信を行う際のＥＣＵ３の処理負荷の増加を抑えることができる。

本実施の形態１２によれば、代行候補装置ＥＣＵ２〜ＥＣＵｍがデータ通信周期調整手段３１と車両状況検出手段３２を備えることにより、代行要求を受信してから代行装置としてデータ送信処理を開始するまでの時間をさらに短くすることができ、ネットワーク異常を発生させることを防止することができる。なお、本発明は、その発明の範囲内において、各実施の形態を自由に組み合わせたり、各実施の形態を適宜、変形、省略したりすることが可能である。

本発明は、車両に搭載され共通の通信線を介して接続される複数の制御装置に対して、通信を行う制御装置の切り替えを行う制御装置切替システムとして利用することができる。

１ ＥＣＵ（通信制御装置）、２、３、４、５ ＥＣＵ（代行候補装置）、
６ ネットワーク、７ 一時記憶装置、１１ データ送受信実行／停止手段、
１２ 代行要求送信手段、１３ 代行送信可否判定手段、
１４ スリープ条件成立判定手段、１５ スリープ処理手段、１６ ウェイク処理手段、１７ 代行停止要求送信手段、１８ ウェイクタイマ設定手段、
１９ タイマ割込みウェイク手段、２１ 代行送信手段、
２２、２２Ａ 代行要求送信手段、２３、２３Ａ 代行送信可否判定手段、
２４ 記憶装置、２５ 代行データ導出手段、２６ データ調整手段、
２７ 制御周期調整手段、２８ クロック周波数調整手段、２９ データ同期手段、
３０ ウェイクタイマカウント手段、３１ データ通信周期調整手段、
３２ 車両状況検出手段、
１００、１００Ａ、１００Ｂ、１００Ｃ、制御装置切替システム

Claims (14)

1. 車両に搭載される複数の制御装置が共通の通信線を介して互いに接続され、前記制御装置は、自身以外の前記制御装置との間でデータの送受信を行う通信制御装置と、前記通信制御装置が行うべきデータ送信処理を代行可能な複数の代行候補装置を含み、
   前記通信制御装置は、自身のスリープ処理または電源遮断の条件が成立するとデータの送受信を停止するデータ送受信実行／停止手段と、前記代行候補装置の各々について前記データ送信処理を代行可能な状態か否かを判定する代行送信可否判定手段と、前記データ送信処理を代行させる前記代行候補装置に対して代行要求を送信する代行要求送信手段とを備え、自身のスリープ処理または電源遮断の条件が成立すると、前記代行送信可否判定手段による判定結果に基づいて前記データ送信処理を代行させる前記代行候補装置を決定し、その代行候補装置に対して前記代行要求送信手段から代行要求を送信した後、前記データ送受信実行／停止手段により前記データ送信処理を停止し、
   前記代行候補装置は、前記データ送信処理の代行を実行する代行送信手段と、所定時刻における前記通信制御装置からの受信データを蓄積する記憶手段と、該所定時刻における前記代行候補装置の内部変数と前記受信データとを比較して該代行候補装置が前記データ送信処理を代行する際の送信データを導出する代行データ導出手段を備え、前記通信制御装置から代行要求を受信した場合に前記代行送信手段により前記データ送信処理を代行することを特徴とする制御装置切替システム。
2. 前記代行送信可否判定手段は、前記代行候補装置の処理負荷量に基づいて、前記代行候補装置が前記データ送信処理を代行可能な状態か否かを判定することを特徴とする請求項１記載の制御装置切替システム。
3. 前記代行送信可否判定手段は、前記代行候補装置の処理重要度に基づいて、前記代行候補装置が前記データ送信処理を代行可能な状態か否かを判定することを特徴とする請求項１記載の制御装置切替システム。
4. 前記代行送信可否判定手段は、前記代行候補装置の故障判定結果に基づいて、前記代行候補装置が前記データ送信処理を代行可能な状態か否かを判定することを特徴とする請求項１記載の制御装置切替システム。
5. 前記代行送信可否判定手段は、前記代行候補装置が前記データ送信処理を代行可能な状態か否かを判定する際に、各々の前記代行候補装置の処理重要度を参照し、処理重要度が低い前記代行候補装置から順に判定を行うことを特徴とする請求項１から請求項４のいずれか一項に記載の制御装置切替システム。
6. 前記代行候補装置は、自身および自身以外の前記代行候補装置について前記データ送信処理を代行可能な状態か否かを前記代行候補装置の処理重要度に基づいて判定する第２の代行送信可否判定手段と、前記データ送信処理を代行させる自身以外の前記代行候補装置に対して代行要求を送信する第２の代行要求送信手段とを備え、
   前記データ送信処理の代行を開始した前記代行候補装置は、自身の前記第２の代行送信可否判定手段により自身が前記データ送信処理を代行可能な状態ではないと判定した場合、前記第２の代行送信可否判定手段により前記データ送信処理を代行可能な状態であると判定された自身以外の前記代行候補装置に対して、前記第２の代行要求送信手段から代行要求を送信することを特徴とする請求項１記載の制御装置切替システム。
7. 前記制御装置は、前記通信制御装置および前記代行候補装置の故障を検出する監視制御装置を含み、
   前記監視制御装置は、前記通信制御装置および前記代行候補装置の故障の有無を判定する故障判定手段と、前記データ送信処理を代行している前記代行候補装置について代行の継続が可能か否かを前記故障判定手段の判定結果に基づいて判定する代行送信継続判定手段と、前記故障判定手段により故障が無いと判定された前記代行候補装置に対して前記データ送信処理の代行要求を送信する第３の代行要求送信手段を備えたことを特徴とする請求項１記載の制御装置切替システム。
8. 前記代行候補装置は、所定時刻において送信不要なデータを判定する不要データ判定手段と、該代行候補装置が前記データ送信処理を代行する際に前記不要データ判定手段による判定結果に基づいて送信データを間引きするデータ調整手段とを備えたことを特徴とする請求項１記載の制御装置切替システム。
9. 前記代行候補装置は、自身の制御周期を調整する制御周期調整手段を備え、前記通信制御装置から代行要求を受信した際に、前記制御周期調整手段により自身の制御周期を通常時よりも長くすることを特徴とする請求項１記載の制御装置切替システム。
10. 前記代行候補装置は、自身の動作クロック周波数を調整するクロック周波数調整手段を備え、前記通信制御装置から代行要求を受信した際に、前記クロック周波数調整手段により、自身のクロック周波数を通常時よりも低下させることを特徴とする請求項１記載の制御装置切替システム。
11. 前記通信制御装置は、前記データ送信処理を停止してから所定の再開時間後に前記データ送信処理を再開させるタイマ割込みウェイク手段を備え、前記データ送信処理を停止する際に、前記代行候補装置に対して代行要求と再開時間を送信し、再開時間が経過後、前記タイマ割込みウェイク手段により前記データ送信処理を再開し、
    前記代行候補装置は、再開時間をカウントする再開時間計測手段を備え、代行要求を受信し前記データ送信処理の代行を開始すると同時に前記再開時間計測手段により時間を計測し、所定の再開時間後に前記データ送信処理の代行を停止することを特徴とする請求項１記載の制御装置切替システム。
12. 前記代行候補装置は、自身のデータ送受信周期を調整するデータ通信周期調整手段を備え、前記通信制御装置から代行要求を受信した際に、前記データ通信周期調整手段によりデータ送信周期を通常時よりも短くすることを特徴とする請求項１記載の制御装置切替システム。
13. 前記代行候補装置は、前記通信制御装置が前記データ送信処理を停止すると予測される車両状況を検出する車両状況検出手段を備え、前記車両状況検出手段により前記車両状況が検出された際に、前記データ通信周期調整手段によりデータ送信周期を通常時よりも短くすることを特徴とする請求項１２記載の制御装置切替システム。
14. 前記データ通信周期調整手段は、前記代行候補装置が前記データ送信処理の代行を開始した後、通常時よりも短くしたデータ送信周期を元に戻すことを特徴とする請求項１２または請求項１３に記載の制御装置切替システム。

Images