JP7283412B2 - 通信システム - Google Patents

Description

本開示は、通信システムに関する。

車両に搭載される複数の通信装置は、ＣＡＮ（登録商標）やＬＩＮといった通信プロトコルに従い通信を行い、通信システムを構築している。
例えば、ＣＡＮでは、通信バスに接続された複数の通信装置であるノードのうち、通信が必要なものを選択的にウェイクアップさせるためのセレクティブウェイクアップ機能について規定されている。これにより、通信バスに接続された一部のノードがウェイクアップした状態で通信を行うパーシャルネットワークが実現される。

具体的には、スリープ状態のノードが、特定の起動情報が含まれた通信フレームを受信することで、ウェイクアップするように構成される。
特許文献１には、通信バスに接続された複数のノードのうちスリープ状態のノードが、適度に頻繁に繰り返される対称なデータパターンを受信した場合にウェイクアップするように構成されたシステムが記載されている。

特表２００５－５２９５１７号公報

しかしながら、発明者の詳細な検討の結果、以下の課題が見出された。すなわち、車両が出荷された後であっても、新たな機能を車両に追加したい場合がある。例えば、当初はエンジン始動中のみ動作するドライブレコーダ用として設置していたカメラを、セキュリティカメラとして駐車中にも使用できるように機能を追加する場合が挙げられる。通常、カメラをドライブレコーダ用として使用する場合、関連するＥＣＵは、カメラが使用されていない状況、例えば駐車中には、消費電力を抑制するためスリープ状態となるように設定されている。一方、カメラをセキュリティカメラとして使用する場合、関連するＥＣＵは、駐車中にも状況に応じてウェイクアップする必要がある。つまり、新たな機能を車両に追加する場合、関連するＥＣＵがウェイクアップするタイミング、換言すれば、スリープ状態からノーマル状態へ遷移させるための条件である起動条件を変更する必要が生じ得る。しかし、特許文献１に記載のシステムでは、機能の追加に応じてＥＣＵがウェイクアップするタイミングを変更すること、つまり、あらかじめ設定された起動条件を事後的に変更することが想定されていなかった。仮に起動条件を事後的に変更する場合、特許文献１に記載のシステムでは、関連するＥＣＵそのものを交換するか、関連するＥＣＵごとにプログラムを書き換える必要があることが判明した。

本開示の一局面は、起動条件を簡易に変更することができる通信システムを提供する。

本開示の一態様は、特定の起動情報が含まれた通信フレームが通信バス（９）に発生した場合に複数のノード（１）のうち一部のノードがウェイクアップするように規定された通信プロトコルに従い、複数のノードが通信バスを介して通信を行う通信システムである。複数のノードは少なくとも１つのマスタノード（１ａ）と少なくとも１つのスレーブノード（１ｂ～１ｅ）とを備える。少なくとも１つのマスタノードは、決定部（２１２）と、条件送信部（２１３）と、を備える。決定部は、通信システムを構成するノード及び通信システムで実行されるアプリケーションの少なくとも一方が変化したと判定した場合、少なくとも１つのスレーブノードのそれぞれについて、スリープ状態からノーマル状態へ遷移させるための条件である起動条件を決定するように構成される。条件送信部は、決定部により決定された起動条件を通信バスに送信するように構成される。少なくとも１つのスレーブノードは、記憶処理部（２１７）と、起動部（４４）と、を備える。記憶処理部は、少なくとも１つのマスタノードから送信された起動条件を照合用記憶部（４３）に記憶するように構成される。起動部は、スリープ状態において、通信フレームに含まれた起動情報と、照合用記憶部に記憶されている起動条件と、を比較してウェイクアップ条件が成立した場合、自ノードをスリープ状態からノーマル状態へ遷移させるように構成される。

このような構成によれば、起動条件を簡易に変更することができる。

第１実施形態における通信システムの構成を示すブロック図である。 引き当て用テーブルの一例である。 起動条件テーブルの一例である。 第１実施形態における通信システムの構成を示す概略図である。 新たなノードが通信バスに接続された場合におけるシーケンス図である。 マスタ処理のフローチャートである。 スレーブ処理のフローチャートである。 第２実施形態における通信システムの構成を示す概略図である。 第３実施形態における通信システムの構成を示す概略図である。

以下、本開示の例示的な実施形態について図面を参照しながら説明する。
［１．第１実施形態］
［１－１．全体構成］
図１に示す通信システム１０は、車両に搭載された複数の電子制御装置（以下「ＥＣＵ」という。）１ａ，１ｂ，１ｃ，１ｄ（以下、個々のＥＣＵを区別しない場合はＥＣＵ１ともいう。）を備える。これら複数のＥＣＵ１は、通信バス９に接続されて車載ネットワークを構築し、通信バス９を介してＣＡＮプロトコルに従った相互通信を行う。つまり、この通信システム１０において、複数のＥＣＵ１のそれぞれがノード、つまり通信装置として機能する。以下、ＥＣＵ１ａ，１ｂ，１ｃ，１ｄを、それぞれノード１ａ，１ｂ，１ｃ，１ｄ（以下、個々のノードを区別しない場合はノード１ともいう。）ともいう。

各ＥＣＵ１は、通信処理を実行するノーマル状態と、通信処理を停止して消費電力を低減するスリープ状態と、を含む複数の状態を有する。本実施形態の通信システム１０は、通信バス９に接続された一部のＥＣＵ１がウェイクアップした状態で通信を行うパーシャルネットワークを実現することにより、通信システム１０全体としての消費電力を低減する。

なお、本実施形態の通信システム１０では、各ＥＣＵ１はスリープ状態においても、少なくともＮＭフレームの受信は可能である。ＮＭフレームとは、ネットワークの管理のためのデータをやりとりするためのものである。ＮＭフレームとしては、例えば、スリープ状態であるＥＣＵ１をノーマル状態に遷移させる、つまりウェイクアップさせるためのものや、自ノードについて所定のスリープ条件が成立した状態であるか否かを示すものなどが挙げられる。所定のスリープ条件は、例えば、アクセサリスイッチがオフになって所定の時間以上経過した場合など、ＥＣＵ１ごとに設定されている。自ノードについてスリープ条件が成立した状態であるか否かを示すためのＮＭフレームは、例えば、あらかじめ設定された一定周期で、各ＥＣＵ１により送信される。通信システム１０を構成するすべてのＥＣＵ１についてスリープ条件が成立した状態になった場合、各ＥＣＵ１は後述するスリープ許可状態に遷移した後、スリープ状態に遷移する。

［１－２．マスタＥＣＵの構成］
ＥＣＵ１のうち、マスタＥＣＵであるＥＣＵ１ａの構成について図１を用いて説明する。
ＥＣＵ１ａは、車両各部の制御処理や他のＥＣＵ１との通信処理を実行するマイクロコンピュータ（以下「マイコン」という。）２と、電源制御部３と、マイコン２と通信バス９との間を仲介するインタフェース用ＩＣであるトランシーバ４と、を備える。

マイコン２は、図示しない、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＩＯポート等を備える周知の構成の他、通信コントローラ２１を備える。
通信コントローラ２１は、送受信部２１１と、決定部２１２と、条件送信部２１３と、アプリ管理部２１４と、スリープ管理部２１５と、を備える。

送受信部２１１は、ＣＡＮプロトコルに従った通信処理、例えばフレームの送受信、調停制御、通信エラー処理等を実行する。送受信部２１１は、ロウレベル又はハイレベルの送信信号をトランシーバ４へ出力し、通信バス９から入力されたバス信号の内容を表すロウレベル又はハイレベルの受信信号をトランシーバ４から入力する。

決定部２１２は、通信システム１０を構成するＥＣＵ１及び通信システム１０で実行されるアプリケーションの少なくとも一方が変化したと判定した場合、複数のＥＣＵ１のそれぞれについて、スリープ状態からノーマル状態へ遷移させるための条件である起動条件を新たに決定するように構成されている。本実施形態では、決定部２１２は、通信システム１０を構成するＥＣＵ１の接続状況が変化した場合、通信システム１０を構成するＥＣＵ１が変化したと判定する。例えば、通信システム１０に新たなＥＣＵ１が接続され、通信システム１０を構成するＥＣＵ１の数が増えた場合や、通信システム１０を構成するＥＣＵ１の数は変わらないが既存のＥＣＵ１と新たなＥＣＵ１とが交換された場合等に、決定部２１２は、通信システム１０を構成するＥＣＵ１が変化したと判定する。

決定部２１２は、引き当て用テーブルと起動条件テーブルとを用いて、複数のＥＣＵ１のそれぞれについて起動条件を決定する。具体的には、決定部２１２は、あらかじめ保持する１つの引き当て用テーブルと、あらかじめ保持する複数の起動条件テーブルのうち引き当て用テーブルにより引き当てられた１つの起動条件テーブルと、を用いて、複数のＥＣＵ１のそれぞれについて起動条件を決定する。

引き当て用テーブルは、通信バス９に接続されているＥＣＵ１及び実行されるアプリケーションの組み合わせと、起動条件テーブルと、を紐付けるためのテーブルである。具体的には、引き当て用テーブルは、通信バス９に接続されているＥＣＵ１のノードＩＤ及び実行されるアプリケーションのアプリＩＤの各組み合わせと、引き当てる起動条件テーブルと、を紐付けるように設計されている。ノードＩＤとは、ノードごとに割り振られたユニークなＩＤである。アプリＩＤとは、アプリケーションごとに割り振られたユニークなＩＤである。なお、アプリＩＤには、後述するバージョン情報が付加されていてもよい。

起動条件テーブルは、複数のＥＣＵ１のそれぞれと、各ＥＣＵ１をウェイクアップさせる条件と、を紐付けるためのテーブルである。具体的には、起動条件テーブルは、各ノードＩＤと起動条件とを紐付けるように設計されている。

図２を用いて、本実施形態における引き当て用テーブルについて説明する。便宜上、ノードＩＤは「ノードｎ」と表記し、アプリＩＤは「ＡＰＰｎ」と表記する。なお、ｎには１～３の数字が入る。通信バス９に接続されているＥＣＵ１については、「ノードｎ」に「×」がついている。実行されるアプリケーションについては、「ＡＰＰｎ」に「×」がついている。例えば、通信バス９に接続されているＥＣＵ１が「ノード１」及び「ノード２」であって、加えて、「ＡＰＰ１」が実行されている場合、起動条件テーブルのうち「テーブル３」の起動条件テーブルが割り当てられる。なお、通信バス９に接続されているＥＣＵ１及び実行されるアプリケーションの組み合わせが、引き当て用テーブルに記載されたいずれの組み合わせにも合致しなかった場合は、「設定無」とする。図２の引き当て用テーブルは、通信バス９に接続されているＥＣＵ１及び実行されるアプリケーションの組み合わせの一例であり、他のノードＩＤ及びアプリＩＤについての組み合わせとしてもよい。

続いて、図３を用いて、本実施形態における起動条件テーブルについて説明する。「ノード１」は、「条件１」、「条件２」及び「条件３」においてウェイクアップするよう規定されている。また、「ノード２」は、「条件３」においてウェイクアップするよう規定されている。また、「ノード３」は、「条件２」においてウェイクアップするよう規定されている。換言すれば、「条件１」においては、「ノード１」がウェイクアップするよう規定されている。また、「条件２」においては、「ノード１」及び「ノード３」がウェイクアップするよう規定されている。また、「条件３」においては、「ノード１」及び「ノード２」がウェイクアップするよう規定されている。つまり、起動条件テーブルからは、同時にウェイクアップすべきＥＣＵ１のグループも分かる。なお、例えば、「条件１」は駐車中、「条件２」はＥＶ充電中、「条件３」はイグニッションオン中を示す。図３の起動条件テーブルは、複数のＥＣＵ１のそれぞれと、各ＥＣＵ１をウェイクアップさせる条件との組み合わせの一例であり、他のノードＩＤ及び条件についての組み合わせとしてもよい。

図１に戻り、決定部２１２は、各ＥＣＵ１について決定した起動条件を出力する。本実施形態では、決定部２１２は、各ＥＣＵ１について決定した起動条件が載っている起動条件テーブルを出力する。

条件送信部２１３は、決定部２１２により決定された起動条件を送受信部２１１を介してトランシーバ４に送信するように構成されている。本実施形態では、条件送信部２１３は、起動条件テーブルに基づき、起動条件を通信フレームのデータフィールドに設定する。図３が示す起動条件テーブルを例にとり、データフィールドに設定する値について説明する。例えば、「条件１」の成立でウェイクアップさせる場合に、データフィールドの６ビット目に１を設定し、「条件２」の成立でウェイクアップさせる場合に、データフィールドの４ビット目に１を設定し、「条件３」の成立でウェイクアップさせる場合に、データフィールドの２ビット目に１を設定するよう設計されているとしたら、条件送信部２１３は、「ノード１」には０ｘ２Ａ、「ノード２」には０ｘ０２、「ノード３」には０ｘ０８を受信させるように、起動条件に対応する値である条件設定値をデータフィールドに設定する。条件送信部２１３は、各ＥＣＵ１に、各ＥＣＵ１に応じた起動条件を受信させるように通信フレームを送信する。

図１に戻り、アプリ管理部２１４は、自ノードで実行されるアプリケーションに追加又は変更があったか否かを判定する。本実施形態では、アプリ管理部２１４は、アプリ管理部２１４があらかじめ保持するアプリリストと、通信コントローラ２１が有する記憶領域以外であってマイコン２が有する図示しない記憶領域から取得した最新のアプリリストと、を比較し、差分があると判定した場合、アプリケーションの追加又は変更があったと判定する。アプリリストとは、自ノードで実行されるアプリケーションに割り振られたアプリＩＤ及びアプリケーションのバージョンを示すバージョン情報の一覧である。最新のアプリリストは、例えば、ＯＴＡ等によりソフトウェアが更新された場合に合わせて更新される。最新のアプリリストでは、アプリケーションの追加があった場合にはアプリＩＤが追加され、アプリケーションの変更があった場合にはアプリケーションのバージョン情報が更新されている。また、アプリ管理部２１４があらかじめ保持するアプリリストは、アプリケーションの追加又は変更があったと判定された後、適宜最新のアプリリストに更新される。これにより、アプリ管理部２１４は、同一のアプリケーションについて、追加又は変更があったと何度も判定することを回避できる。なお、ＯＴＡは、Ｏｖｅｒ Ｔｈｅ Ａｉｒの略である。

スリープ管理部２１５は、スリープ状態への遷移が許可されているスリープ許可状態へ自ノードが遷移可能か否かを判定する。スリープ管理部２１５は、スリープ許可状態へ自ノードが遷移可能であると判定した場合、自ノードをスリープ許可状態へ遷移させる。本実施形態では、スリープ管理部２１５は、すべてのＥＣＵ１からスリープ条件が成立した状態である旨を示すＮＭフレームを受信した場合、自ノードがスリープ許可状態へ遷移可能であると判定する。一方、スリープ管理部２１５は、通信システム１０を構成するＥＣＵ１のうち少なくとも１つのＥＣＵ１からスリープ条件が成立した状態でない旨のＮＭフレームを受信した場合、スリープ状態への遷移が禁止されているスリープ禁止状態であると判定する。

スリープ管理部２１５は、スリープ禁止状態からスリープ許可状態へ自ノードが遷移した場合、自ノードが実際にスリープ状態になる前に、任意の起動情報が含まれたＮＭフレームを受信することで自ノードをスリープ状態からノーマル状態へ遷移させるフェール値を、起動条件として照合用記憶部４３に記憶する。具体的には、スリープ管理部２１５は、ドミナントを受信した場合にウェイクアップするようにフェール値を照合用記憶部４３に記憶する。なお、ＥＣＵ１は、スリープ許可状態に遷移してから、所定の時間経過後、スリープ状態に遷移する。

また、マイコン２は、ＣＰＵが動作するための動作クロックを生成する図示しないクロック回路を備え、クロック回路への電源供給が停止することで、クロック回路の動作、ひいてはＣＰＵ自身の動作が停止する。前述したノーマル状態とは、マイコン２のクロック回路が動作している状態であり、スリープ状態とは、マイコン２のクロック回路が動作を停止している状態である。なお、クロック回路がメインクロック回路とメインクロック回路よりも消費電力の少ないサブクロック回路とを備えている場合、ノーマル状態においてはメインクロック回路を動作させ、スリープ状態においてはメインクロック回路に代えてサブクロック回路を動作させることとしてもよい。

電源制御部３は、マイコン２への電源供給を制御する。ＥＣＵ１ａは、マイコン２への電源供給が途絶えると、スリープ状態へ遷移し、マイコン２への電源供給が開始されると、ノーマル状態へ遷移、つまりウェイクアップする。

トランシーバ４は、送信回路４１と、受信回路４２と、照合用記憶部４３と、比較回路４４と、を備える。
送信回路４１は、マイコン２から入力した論理値を示す送信信号を、通信バス９を介して送受信されるバス信号に変換して、通信バス９へ出力する。具体的には、送信回路４１は、マイコン２から「１」を表すハイレベルの送信信号を入力した場合には、レセッシブを表すバス信号を通信バス９へ出力し、マイコン２から「０」を表すロウレベルの送信信号を入力した場合には、ドミナントを表すバス信号を通信バス９へ出力する。

受信回路４２は、通信バス９から入力したバス信号を、論理値を示す受信信号に変換して、マイコン２へ出力する。具体的には、受信回路４２は、通信バス９からレセッシブを表すバス信号を入力した場合には、「１」を表すハイレベルの受信信号をマイコン２へ出力し、通信バス９からドミナントを表すバス信号を入力した場合には、「０」を表すロウレベルの受信信号をマイコン２へ出力する。

照合用記憶部４３は、自ノードの起動条件を記憶するレジスタである。
比較回路４４は、スリープ状態において通信バス９に発生したＮＭフレームに含まれる起動情報と、照合用記憶部４３に書き込まれている起動条件と、を１ビットごとに比較する。そして、比較回路４４は、ウェイクアップ条件が成立している場合に、マイコン２への電源供給を電源制御部３に行わせるための電源供給信号を電源制御部３へ出力する。本実施形態では、比較回路４４は、スリープ状態において通信バス９から入力したＮＭフレームに含まれる起動情報と、照合用記憶部４３に書き込まれている起動条件と、の論理積を１ビットごとに算出し、いずれかのビットでその結果が真であった場合、ウェイクアップ条件が成立しているとする。例えば、照合用記憶部４３に起動条件として０ｘ２Ａの条件設定値が設定されていた場合、スリープ状態において通信バス９から入力したＮＭフレームに起動情報として２ビット目、４ビット目及び６ビット目の少なくとも１つに「１」が設定されていた場合に、比較回路４４は、ウェイクアップ条件が成立しているとして電源供給信号を出力する。これにより、前述したように、当該ＥＣＵ１がスリープ状態からノーマル状態へ遷移、つまりウェイクアップする。なお、本実施形態では、ＥＣＵ１ａの照合用記憶部４３にはフェール値が記憶されているため、比較回路４４は、何ビット目であってもドミナントを受信すればウェイクアップ条件が成立しているとする。

［１－３．スレーブＥＣＵの構成］
ＥＣＵ１のうち、スレーブＥＣＵであるＥＣＵ１ｂの構成について図１を用いて説明する。

ＥＣＵ１ｂは、マイコン２と、電源制御部３と、トランシーバ４と、を備える。なお、電源制御部３と、トランシーバ４と、の構成はＥＣＵ１ａと同様である。
マイコン２は、図示しない、ＣＰＵ、ＲＯＭ、ＲＡＭ、ＩＯポート等を備える周知の構成の他、通信コントローラ２１と、保管用記憶部２２と、を備える。

通信コントローラ２１は、送受信部２１１と、アプリ確認部２１６と、記憶処理部２１７と、を備える。なお、送受信部２１１の構成はＥＣＵ１ａと同様である。
アプリ確認部２１６は、ＥＣＵ１ａのアプリ管理部２１４と同様に、自ノードで実行されるアプリケーションに追加又は変更があったか否かを判定する。アプリ確認部２１６は、アプリケーションに追加又は変更があったと判定した場合、追加又は変更があったと判定したアプリケーションのアプリＩＤを送受信部２１１を介してトランシーバ４に出力する。

記憶処理部２１７は、マスタＥＣＵであるＥＣＵ１ａから送信された起動条件を、照合用記憶部４３に記憶する前に、保管用記憶部２２に記憶する。そして記憶処理部２１７は、スリープ禁止状態からスリープ許可状態へ自ノードが遷移した場合、自ノードが実際にスリープ状態になる前に、保管用記憶部２２に記憶された起動条件を照合用記憶部４３に記憶する。記憶処理部２１７は、ＥＣＵ１ａのスリープ管理部２１５と同様に、スリープ許可状態へ自ノードが遷移可能か否かを判定する。そして記憶処理部２１７は、スリープ許可状態へ自ノードが遷移可能であると判定した場合、自ノードをスリープ許可状態へ遷移させる。

保管用記憶部２２は、データの書き換えが可能な不揮発性のメモリである。保管用記憶部２２には、自ノードの起動条件が記憶される。
なお、ＥＣＵ１ｃ及びＥＣＵ１ｄもＥＣＵ１ｂと同様の構成である。

［１－４．処理］
［１－４－１．通信システム１０を構成するＥＣＵ１が変化した場合］
図４に示すように、通信バス９に後付けＥＣＵ１ｅが新たに接続された場合における処理を、図５のシーケンス図を用いて説明する。なお、後付けＥＣＵ１ｅはＥＣＵ１ｂ～１ｄと同様の構成である。以下、後付けＥＣＵ１ｅを、ＥＣＵ１ｅともいう。

［１－４－１－１．スリープ状態への遷移］
まず、後付けＥＣＵ１ｅは、Ｓ１で、通信バス９に新たに接続されると、直ちに特定フレームを送信する。本実施形態で、特定フレームとは、認証情報と、ノードＩＤ又はアプリＩＤと、を含んだフレームである。この例で送信される特定フレームには、認証情報とノードＩＤとが含まれる。認証情報は、機器認証のための情報であって、新たに接続されたＥＣＵ１について接続が許可されている有効なＥＣＵ１であるか否かの判定に用いられる。本実施形態では、認証情報として、各ＥＣＵ１に割り振られたＭＡＣアドレスが特定フレームに設定される。つまり、後付けＥＣＵ１ｅは、後付けＥＣＵ１ｅに割り振られたＭＡＣアドレスと、自ノードのノードＩＤと、を含んだ特定フレームを送信する。

続いて、ＥＣＵ１ａは、Ｓ２で、受信した特定フレームに含まれる認証情報に基づき、後付けＥＣＵ１ｅについて接続が許可されている有効なＥＣＵ１であるか否かを判定する。本実施形態では、ＥＣＵ１ａは、あらかじめ保持する接続許可リストと、受信した特定フレームが含むＭＡＣアドレスと、に基づき、後付けＥＣＵ１ｅについて接続が許可されている有効なＥＣＵ１であるか否かを判定する。接続許可リストとは、接続が許可された有効なＥＣＵ１に割り振られたＭＡＣアドレスの一覧である。具体的には、ＥＣＵ１ａは、接続許可リストの中に、受信した特定フレームが含むＭＡＣアドレスがあれば、後付けＥＣＵ１ｅについて接続が許可されている有効なＥＣＵ１であると判定する。

続いて、ＥＣＵ１ａは、後付けＥＣＵ１ｅについて接続が許可されている有効なＥＣＵ１であると判定した場合、Ｓ３で、通信システム１０を構成する複数のＥＣＵ１のそれぞれについて起動条件を決定し、決定した起動条件を複数のＥＣＵ１のそれぞれに受信させるように送信する。受信した特定フレームに含まれるノードＩＤは、引き当て用テーブルを参照する際に用いられる。

続いて、ＥＣＵ１ｂ～１ｄは、ＥＣＵ１ａから送信された起動条件をメモリに格納する。また、後付けＥＣＵ１ｅも、ＥＣＵ１ａから送信された起動条件をメモリに格納する。なお、ここでいうメモリとは、保管用記憶部２２である。

続いて、ＥＣＵ１ａ～１ｅは、Ｓ５で、スリープ許可状態へ自ノードが遷移可能か否かを判定する。
ＥＣＵ１ａ～１ｅは、スリープ許可状態へ自ノードが遷移可能であると判定した場合、Ｓ６で、自ノードをスリープ許可状態へ遷移させる。

続いて、ＥＣＵ１ａ～１ｄ及び後付けＥＣＵ１ｅは、Ｓ７で、トランシーバ４のレジスタに起動条件を記憶する。このとき、ＥＣＵ１ａは、フェール値を起動条件としてレジスタに記憶する。ＥＣＵ１ｂ～１ｄは、Ｓ４でメモリに格納した起動条件をレジスタに記憶する。なお、ここでいうレジスタとは、照合用記憶部４３である。

続いて、ＥＣＵ１ａ～１ｄ及び後付けＥＣＵ１ｅは、Ｓ８で、スリープ状態に遷移する。
［１－４－１－２．ノーマル状態への遷移］
続いて、図示されていないが、ＥＣＵ１ａ～ＥＣＵ１ｅのうち一部のＥＣＵ１がスリープ状態からノーマル状態へ遷移する場合の一例を説明する。

例えばＥＣＵ１ｂは、ＥＣＵ１ｂとイグニッションスイッチとをつなぐジカ線を介して、イグニッションスイッチの信号を取得し、当該信号がアクティブになったらスリープ状態からノーマル状態へ遷移するようにマイコン２に設定されていたとする。また、他のＥＣＵ１は、イグニッションスイッチと接続されていないとする。

この場合、ＥＣＵ１ｂは、当該信号がアクティブになることでスリープ状態からノーマル状態へ遷移したら、ＥＣＵ１ｂと同様にイグニッションオン中にウェイクアップすべきＥＣＵ１が受信できるように特定の起動情報が含まれたＮＭフレームを送信する。具体的には、前述の例だと「条件３」の成立でウェイクアップさせる場合に該当するので、ＥＣＵ１ｂは、データフィールドの２ビット目に１を設定、つまり起動情報として０ｘ０２を設定したＮＭフレームを送信する。これにより、ＥＣＵ１ｂと同じく「条件３」の成立でウェイクアップするグループに属するＥＣＵ１は、スリープ状態からノーマル状態へ遷移することができる。一方、「条件３」の成立でウェイクアップする必要がないグループに属するＥＣＵ１は、スリープ状態のままである。

［１－４－２．通信システム１０で実行されるアプリケーションが変化した場合］
続いて、図示されていないが、通信システム１０で実行されるアプリケーションが変化した場合における処理を説明する。

例えばＥＣＵ１ｂに新たなアプリケーションが追加又はＥＣＵ１ｂのアプリケーションが変更されると、ＥＣＵ１ｂは、特定フレームを直ちに送信する。この例で送信される特定フレームには、認証情報とアプリＩＤとが含まれる。なお、アプリＩＤには、バージョン情報が付加されていてもよい。

続いて、ＥＣＵ１ａは、受信した特定フレームに含まれる認証情報に基づき、ＥＣＵ１ｂについて接続が許可されている有効なＥＣＵ１であるか否かを判定する。
続いて、ＥＣＵ１ａは、通信システム１０を構成する複数のＥＣＵ１のそれぞれについて起動条件を決定し、決定した起動条件を複数のＥＣＵ１のそれぞれに受信させるように送信する。受信した特定フレームに含まれるアプリＩＤは、引き当て用テーブルを参照する際に用いられる。

以降の処理は、図５のＳ４～Ｓ８と同様である。
［１－４－３．マスタ処理］
続いて、ＥＣＵ１ａのコントローラ２１が実行するマスタ処理について、図６のフローチャートを用いて説明する。マスタ処理は、所定の開始条件が成立した場合に開始される。本実施形態では、次の２とおりのうちいずれかの開始条件が成立した場合にマスタ処理が開始される。１つ目は、ＥＣＵ１ａの電源がオンになった場合である。２つ目は、ＥＣＵ１ａがウェイクアップした場合である。マスタ処理は、開始後ノーマル状態である間、所定の周期で繰り返し実行される。これにより、例えば複数のノードが新たに接続された場合でも、コントローラ２１はその都度起動条件を決定し送信することができる。

まず、Ｓ１０１で、コントローラ２１は、特定フレームを受信したか否かを判定する。
コントローラ２１は、Ｓ１０１で特定フレームを受信したと判定した場合には、Ｓ１０２へ移行し、特定フレームに含まれる認証情報に基づき、特定フレームを送信したノード１が有効なノード１であるか否かを判定する。

コントローラ２１は、Ｓ１０２で、特定フレームを送信したノード１が有効なノード１であると判定した場合には、Ｓ１０３へ移行し、複数のノード１のそれぞれについて起動条件を決定する。なお、Ｓ１０３が、決定部２１２としての処理に相当する。

続いて、Ｓ１０４で、コントローラ２１は、複数のノード１のそれぞれについて決定した起動条件を複数のノード１のそれぞれに受信させるように送信する。その後、コントローラ２１は、Ｓ１０５へ移行する。なお、Ｓ１０４が、条件送信部２１３としての処理に相当する。

コントローラ２１は、Ｓ１０１で特定フレームを受信していないと判定した場合にも、Ｓ１０５へ移行する。
コントローラ２１は、Ｓ１０２で、特定フレームを送信したノード１が有効なノード１でないと判定した場合にも、Ｓ１０５へ移行する。

Ｓ１０５で、コントローラ２１は、ＥＣＵ１ａに新たに追加されたアプリケーション又は変更されたアプリケーションがあるか否かを判定する。
コントローラ２１は、Ｓ１０５でＥＣＵ１ａに新たに追加されたアプリケーション又は変更されたアプリケーションがあると判定した場合には、Ｓ１０６へ移行し、自ノードの認証情報及び新たに追加されたアプリケーション又は変更されたアプリケーションのアプリＩＤを含んだ特定フレームを送信した後、Ｓ１０１に戻り、マスタ処理を繰り返す。なお、Ｓ１０５，Ｓ１０６が、アプリ管理部２１４としての処理に相当する。

一方、コントローラ２１は、Ｓ１０５でＥＣＵ１ａに新たに追加されたアプリケーション及び変更されたアプリケーションがないと判定した場合には、Ｓ１０７へ移行し、スリープ許可状態へ自ノードが遷移可能であるか否かを判定する。

コントローラ２１は、Ｓ１０７でスリープ許可状態へ自ノードが遷移可能でないと判定した場合には、Ｓ１０１に戻り、マスタ処理を繰り返す。
一方、コントローラ２１は、Ｓ１０７でスリープ許可状態へ自ノードが遷移可能であると判定した場合には、Ｓ１０８へ移行し、フェール値を起動条件としてレジスタに記憶する。なお、Ｓ１０７，Ｓ１０８が、スリープ管理部２１５としての処理に相当する。

続いて、Ｓ１０９で、コントローラ２１は、マイコン２をスリープ状態に遷移させた後、図６のマスタ処理を終了する。
［１－４－４．スレーブ処理］
続いて、ＥＣＵ１ｂ～１ｅのコントローラ２１が実行するスレーブ処理について、図７のフローチャートを用いて説明する。なお、本説明では、ＥＣＵ１ｂについて説明するが、他のＥＣＵ１ｃ～１ｅについても同様である。スレーブ処理は、所定の開始条件が成立した場合に開始される。本実施形態では、次の３とおりのうちいずれかの開始条件が成立した場合にスレーブ処理が開始される。１つ目は、ＥＣＵ１ｂの電源がオンになった場合である。２つ目は、ＥＣＵ１ｂがウェイクアップした場合である。３つ目は、ＥＣＵ１ｂが通信バス９に新たに接続された場合である。スレーブ処理は、開始後ノーマル状態である間、所定の周期で繰り返し実行される。これにより、例えば複数回にわたり起動条件が送信された場合でも、コントローラ２１はその都度最新の起動条件に更新することができる。

まず、Ｓ２０１で、コントローラ２１は、メモリに起動条件が記憶されているか否かを判定する。
コントローラ２１は、Ｓ２０１でメモリに起動条件が記憶されていないと判定した場合には、Ｓ２０２へ移行し、特定フレームを送信する。このときに送信される特定フレームには、認証情報とノードＩＤとが含まれる。これにより、一度もＥＣＵ１ａから起動条件を受信していない場合や、ノイズの影響等によりメモリに記憶された起動条件が消失した場合等にも、ＥＣＵ１ａから起動条件を送信してもらうことができる。その後、コントローラ２１は、Ｓ２０３へ移行する。

一方、コントローラ２１は、Ｓ２０１でメモリに起動条件が記憶されていると判定した場合には、Ｓ２０２をとばして、Ｓ２０３へ移行する。
続いて、Ｓ２０３で、コントローラ２１は、ＥＣＵ１ａから起動条件を新たに受信したか否かを判定する。

コントローラ２１は、Ｓ２０３でＥＣＵ１ａから起動条件を新たに受信したと判定した場合には、Ｓ２０４へ移行し、ＥＣＵ１ａから新たに受信した起動条件をメモリに記憶する。その後、コントローラ２１は、Ｓ２０５へ移行する。

一方、コントローラ２１は、Ｓ２０３でＥＣＵ１ａから起動条件を新たに受信していないと判定した場合には、Ｓ２０４をとばして、Ｓ２０５へ移行する。
続いて、Ｓ２０５で、コントローラ２１は、ＥＣＵ１ｂに新たに追加されたアプリケーション又は変更されたアプリケーションがあるか否かを判定する。

コントローラ２１は、Ｓ２０５でＥＣＵ１ｂに新たに追加されたアプリケーション又は変更されたアプリケーションがあると判定した場合には、Ｓ２０２に戻り、特定フレームを送信する。このときに送信される特定フレームには、認証情報と新たに追加されたアプリケーション又は変更されたアプリケーションのアプリＩＤとが含まれる。その後、コントローラ２１は、Ｓ２０３以降の処理を繰り返す。なお、Ｓ２０５が、アプリ確認部２１６としての処理に相当する。

一方、コントローラ２１は、Ｓ２０５でＥＣＵ１ｂに新たに追加されたアプリケーション及び変更されたアプリケーションがないと判定した場合には、Ｓ２０６へ移行し、スリープ許可状態へ自ノードが遷移可能であるか否かを判定する。

コントローラ２１は、Ｓ２０６でスリープ許可状態へ自ノードが遷移可能でないと判定した場合には、Ｓ２０３に戻り、以降の処理を繰り返す。
一方、コントローラ２１は、Ｓ２０６でスリープ許可状態へ自ノードが遷移可能であると判定した場合には、Ｓ２０７へ移行し、メモリに起動条件が記憶されているか否かを判定する。

コントローラ２１は、Ｓ２０７でメモリに起動条件が記憶されていると判定した場合には、Ｓ２０８へ移行し、メモリに記憶されている起動条件をレジスタに記憶する。
一方、コントローラ２１は、Ｓ２０７でメモリに起動条件が記憶されていないと判定した場合には、Ｓ２０９へ移行し、フェール値を起動条件としてレジスタに記憶する。具体的には、コントローラ２１は、ドミナントを受信した場合にウェイクアップするようにフェール値をレジスタに記憶する。これは、例えば、コントローラ２１がＳ２０２で特定フレームを送信したが、ＥＣＵ１ａから起動条件をまだ受信していない状態においてスリープ許可状態へ遷移した場合等におけるフェール処理である。ＥＣＵ１は、レジスタに起動条件を記憶せずにスリープ状態に遷移してしまうと、ウェイクアップできなくなってしまうからである。なお、Ｓ２０４，Ｓ２０６～Ｓ２０９が、記憶処理部２１７としての処理に相当する。

続いて、Ｓ２１０で、コントローラ２１は、マイコン２をスリープ状態に遷移させた後、図７のスレーブ処理を終了する。
［１－５．効果］
以上詳述した第１実施形態によれば、以下の効果が得られる。

（１ａ）ＥＣＵ１ａは、通信システム１０を構成するＥＣＵ１及び通信システム１０で実行されるアプリケーションの少なくとも一方が変化したと判定した場合、複数のＥＣＵ１のそれぞれについて、起動条件を決定し、決定した起動条件を通信バス９に送信する。また、ＥＣＵ１は、ＥＣＵ１ａから送信された起動条件を照合用記憶部４３に記憶し、スリープ状態において、ＮＭフレームに含まれた起動情報と、照合用記憶部４３に記憶されている起動条件と、を比較してウェイクアップ条件が成立した場合、自ノードをスリープ状態からノーマル状態へ遷移させる。このような構成によれば、ＥＣＵ１は、現在照合用記憶部４３に記憶している起動条件を、ＥＣＵ１ａから送信された起動条件に更新するだけで、ウェイクアップする条件を事後的に変更することができる。よって、ＥＣＵ１そのものを交換したり、ＥＣＵ１ごとにプログラムを書き換えたりする場合と比較して、起動条件を簡易に変更することができる。

（１ｂ）ＥＣＵ１ａは、通信バス９に新たにＥＣＵ１が接続されたと判定した場合、複数のＥＣＵ１のそれぞれについて起動条件を決定する。このような構成によれば、通信バス９に新たにＥＣＵ１が接続されたタイミングで、起動条件を変更することができる。

（１ｃ）ＥＣＵ１ａは、複数のＥＣＵ１のうち少なくとも１つについてアプリケーションが新たに追加された又はアプリケーションが変更されたと判定した場合、複数のＥＣＵ１のそれぞれについて起動条件を決定する。このような構成によれば、新たにアプリケーションが追加されたタイミング又はアプリケーションが変更されたタイミングで、起動条件を変更することができる。

（１ｄ）ＥＣＵ１は、ＥＣＵ１ａから送信された起動条件を照合用記憶部４３に記憶する前に、保管用記憶部２２に起動条件を記憶し、スリープ禁止状態からスリープ許可状態へ自ノードが遷移した場合、自ノードが実際にスリープ状態になる前に、保管用記憶部２２に記憶された起動条件を照合用記憶部４３に記憶する。通常、照合用記憶部４３はバッテリバックアップのため給電されなくなると記憶していた起動条件を消失するが、このような場合でも、ＥＣＵ１は、不揮発性である保管用記憶部２２に記憶された起動条件を照合用記憶部４３に再度書き込むことができる。よってＥＣＵ１は、起動条件を照合用記憶部４３に記憶する前に保管用記憶部２２に記憶しておくことで、ＥＣＵ１ａに再度起動条件を送信してもらわなくても済む。

また、ＥＣＵ１は、起動条件を受信してすぐに照合用記憶部４３に記憶せず、自ノードが実際にスリープ状態になる直前で起動条件を記憶する。よって、ＥＣＵ１は、自ノードが実際にスリープ状態になる直前での最新の起動条件のみを照合用記憶部４３に書き込むことになる。したがって、ＥＣＵ１は、自ノードが実際にスリープ状態になる直前であるか否かに関わらず起動条件を受信する度に照合用記憶部４３に起動条件を記憶する構成と比較して、照合用記憶部４３に起動条件を書き込む回数を抑制することができる。

（１ｅ）ＥＣＵ１は、保管用記憶部２２に記憶された起動条件を照合用記憶部４３に記憶するタイミングにおいて、起動条件が保管用記憶部２２に記憶されていない場合、フェール値を起動条件として照合用記憶部４３に記憶する。このような構成によれば、例えばＥＣＵ１ａが故障する等して、ＥＣＵ１ａから起動条件を受信できなかったとしても、ＥＣＵ１は、ウェイクアップできないという事態を回避できる。

なお、本実施形態では、比較回路４４が起動部としての処理に相当する。
［２．第２実施形態］
［２－１．第１実施形態との相違点］
第２実施形態は、基本的な構成及び処理は第１実施形態と同様であるため、共通する構成及び処理については説明を省略し、相違点を中心に説明する。

第１実施形態では、ＥＣＵ１ａは、あらかじめ保持する引き当て用テーブルと、あらかじめ保持する起動条件テーブルと、を用いて起動条件を決定した。引き当て用テーブル及び起動条件テーブルを参照する際にはノードＩＤ及びアプリＩＤが用いられる。

ここで、例えば、車両の出荷時には実際に通信バス９に接続されていなくても、今後接続されることが想定されていれば、そのＥＣＵ１のノードＩＤを、車両の出荷時にあらかじめ引き当て用テーブルや起動条件テーブルに記載しておくことができる。しかし、車両の出荷時に想定されていないＥＣＵ１やアプリケーションが後から追加されることも考えられる。このような場合、第１実施形態では、あらかじめ保持する引き当て用テーブルや起動条件テーブルに、新たに追加されたノードＩＤやアプリＩＤが載っていないため、当該ノードＩＤやアプリＩＤについての起動条件を決定することができない。

そこで、第２実施形態では、ＥＣＵ１ａは、車両の外部から起動条件を取得可能に構成されている。具体的には、図８に示すように、ＥＣＵ１ａは、外部装置１００との間で無線通信を行うように構成されている通信部５を備える。本実施形態では、通信部５は、サービスセンタに設置された外部装置１００との間で無線通信を行うように構成されている。ＥＣＵ１ａは、例えば、ＥＣＵ１やアプリケーションが追加されたタイミングで、ＯＴＡ等により、サービスセンタが保持する引き当て用テーブル及び起動条件テーブルの最新のセットを受信する。ＥＣＵ１ａは、仮に、現在保持している引き当て用テーブル及び起動条件テーブルのセットがあれば、受信した最新のセットで上書きする。つまりＥＣＵ１ａは、常に最新の起動条件を保持している。

［２－２．効果］
（２ａ）ＥＣＵ１ａは、外部装置１００との間で無線通信を行うように構成された通信部５を備える。通信部５は、外部装置１００から起動条件を受信可能である。このような構成によれば、例えば車両の出荷時に想定されていないＥＣＵ１やアプリケーションが追加された場合でも、ＥＣＵ１ａは、新たなノードＩＤやアプリＩＤについての起動条件を取得することができる。加えて、このような場合でも、ＥＣＵ１そのものを交換したり、ＥＣＵ１ごとにプログラムを書き換えたりすることなく、ＥＣＵ１は、ＥＣＵ１ａから新たな起動条件を取得することができる。よって、このような構成によれば、外部装置１００から起動条件を受信できない構成と比較して、起動条件を簡易に変更することができる。

［３．第３実施形態］
［３－１．第１実施形態との相違点］
第３実施形態は、基本的な構成及び処理は第１実施形態と同様であるため、共通する構成及び処理については説明を省略し、相違点を中心に説明する。

第１実施形態では、図１に示すように、１本の通信バス９を介して複数のＥＣＵ１が相互通信を行っていた。一方、第３実施形態では、図９に示すように、通信システム１０は、ゲートウェイＥＣＵ１ｚを備える。ゲートウェイＥＣＵ１ｚは、複数のＥＣＵ１間、つまり複数のノード１間の通信フレームの送受信を中継するために、複数の通信バス９を相互に接続する。また、ゲートウェイＥＣＵ１ｚは、マスタＥＣＵとして機能する。つまり、ゲートウェイＥＣＵ１ｚが、前述したＥＣＵ１ａの決定部２１２と、条件送信部２１３と、を備える。

［３－２．効果］
（３ａ）ゲートウェイＥＣＵ１ｚがマスタＥＣＵとして機能するため、起動条件の更新に支障を来しにくくすることができる。すなわち、仮に、複数の通信バス９のうちいずれか１つの通信バス９にマスタＥＣＵが接続されている場合、その通信バス９が例えば断線やショートにより通信不能になると、マスタＥＣＵは決定した起動条件を複数の通信バス９のいずれにも送信できなくなる。つまり、他のＥＣＵ１は、マスタＥＣＵから起動条件を受信できないことにより、起動条件を更新することができない。しかし、ゲートウェイＥＣＵ１ｚにマスタＥＣＵの機能が備わっていれば、いずれの通信バス９が通信不能になったとしても、通信不能でないその他の通信バス９には決定した起動条件を送信することができる。つまり、通信不能でない通信バス９に接続するＥＣＵ１は、起動条件を受信することができるため、起動条件を更新することができる。

［４．他の実施形態］
以上、本開示の実施形態について説明したが、本開示は、上記実施形態に限定されることなく、種々の形態を採り得ることは言うまでもない。

（４ａ）上記第２実施形態では、ＥＣＵ１ａは、サービスセンタから引き当て用テーブル及び起動条件テーブルの最新のセットを受信した。しかし例えば、サービスセンタから受信するデータは、引き当て用テーブルのみでもよいし起動条件テーブルのみでもよい。また、引き当て用テーブル又は起動条件テーブルのうちの、必要な部分のデータのみでもよい。

（４ｂ）上記実施形態では、１つのマスタＥＣＵと複数のスレーブＥＣＵとにより通信システム１０が構成されていた。しかし、通信システム１０を構成するマスタＥＣＵの個数及びスレーブＥＣＵの個数はこれに限定されるものではない。例えば、通信システム１０は、複数のマスタＥＣＵを備える構成でもよいし、１つのスレーブＥＣＵを備える構成でもよい。

（４ｃ）上記実施形態では、マスタＥＣＵであるＥＣＵ１ａが、通信システム１０を構成する複数のＥＣＵ１のそれぞれについて起動条件を決定していた。しかし例えば、サービスセンタ、つまりサーバ側において、複数のＥＣＵ１のそれぞれについて起動条件が決定されてもよい。具体的には、ＥＣＵ１ａは、例えば後付けＥＣＵ１ｅが接続された場合、無線通信によりサービスセンタに問い合わせる。このとき、ＥＣＵ１ａは、後付けＥＣＵ１ｅから受信した後付けＥＣＵ１ｅのノードＩＤをサービスセンタに送信する。サービスセンタは、通信システム１０の構成を管理しており、通信システム１０を構成する複数のＥＣＵ１のそれぞれについて起動条件を決定する。つまり、ＥＣＵ１ａの代わりに、サービスセンタが引き当て用テーブル及び起動条件テーブルを保持している。サービスセンタは、決定した起動条件をＥＣＵ１ａに送信する。ＥＣＵ１ａは、サービスセンタから受信した起動条件を各ＥＣＵ１にそれぞれ受信させるように通信バス９に送信する。

ＥＣＵ１ａは、通信システム１０を構成するＥＣＵ１の接続状況が変化したり、通信システム１０で実行されるアプリケーションが変化したりする度に、サービスセンタに問い合わせてもよいし、ノードＩＤやアプリＩＤが未知のものである場合のみサービスセンタに問い合わせることとしてもよい。

（４ｄ）上記実施形態では、通信システム１０で実行されるアプリケーションが変化した場合、新たなアプリケーションの追加又はアプリケーションの変更があったＥＣＵ１ｂが認証情報とアプリＩＤとを含む特定フレームを送信した。そして、ＥＣＵ１ａは、受信した特定フレームに含まれる認証情報に基づき、ＥＣＵ１ｂについて接続が許可されている有効なＥＣＵ１であるか否かを判定した。しかし例えば、通信システム１０で実行されるアプリケーションが変化した場合、ＥＣＵ１ｂはノードＩＤとアプリＩＤとが含まれる特定フレームを送信してもよい。そして、ＥＣＵ１ａは、受信した特定フレームに含まれるノードＩＤに基づき、ＥＣＵ１ｂについて接続が許可されている有効なＥＣＵ１であるか否かを判定してもよい。この時点では、ＥＣＵ１ｂは、認証情報に基づき接続が許可されている有効なＥＣＵ１であると既に判定されているからである。

（４ｅ）上記実施形態では、認証情報として、各ＥＣＵ１に割り振られたＭＡＣアドレスが特定フレームに設定された。しかし認証情報はこれに限定されるものではない。認証情報として、例えば、あらかじめ設定しておいた所定の合い言葉や暗号等が用いられてもよい。また、上記実施形態では、ＥＣＵ１ａにおいて、認証情報に基づき有効なＥＣＵ１であるか否かが判定されたが、例えば、サービスセンタにおいて、認証情報に基づき有効なＥＣＵ１であるか否かが判定されてもよい。この場合、例えば、ＥＣＵ１ａが無線通信でサービスセンタに後付けＥＣＵ１ｅ等から受信した認証情報を送信し、サービスセンタから判定の結果を受信する。

（４ｆ）上記実施形態では、ＥＣＵ１ａは、フェール値を照合用記憶部４３に記憶していた。しかし例えば、Ｓ１０３で自ノードについても起動条件を決定し、Ｓ１０８で当該起動条件を照合用記憶部４３に記憶してもよい。さらに、ＥＣＵ１ａは、保管用記憶部２２を備えていてもよく、当該起動条件を照合用記憶部４３に記憶する前に、保管用記憶部２２に記憶し、スリープ禁止状態からスリープ許可状態へ自ノードが遷移した場合、自ノードが実際にスリープ状態になる前に、保管用記憶部２２に記憶された当該起動条件を照合用記憶部４３に記憶してもよい。

（４ｇ）上記実施形態では、保管用記憶部２２として不揮発性メモリが用いられた。しかしメモリの種類はこれに限定されるものではない。保管用記憶部２２として、例えば、バッテリバックアップＲＡＭが用いられてもよい。

（４ｈ）上記実施形態では、通信システム１０ではＣＡＮプロトコルに従った通信を行っていた。しかし、通信プロトコルはこれに限定されるものではなく、他の通信プロトコルが用いられてもよい。

（４ｉ）上記実施形態における１つの構成要素が有する機能を複数の構成要素として分散させたり、複数の構成要素が有する機能を１つの構成要素に統合したりしてもよい。また、上記実施形態の構成の一部を省略してもよい。また、上記実施形態の構成の少なくとも一部を、他の上記実施形態の構成に対して付加、置換等してもよい。

１，１ａ～１ｅ…ＥＣＵ、９…通信バス、１０…通信システム、４３…照合用記憶部、４４…比較回路、２１２…決定部、２１３…条件送信部、２１７…記憶処理部。

Claims (7)

1. 特定の起動情報が含まれた通信フレームが通信バス（９）に発生した場合に複数のノード（１）のうち一部のノードがウェイクアップするように規定された通信プロトコルに従い、前記複数のノードが前記通信バスを介して通信を行う通信システムであって、
   前記複数のノードは少なくとも１つのマスタノード（１ａ）と少なくとも１つのスレーブノード（１ｂ～１ｅ）とを備え、
   前記少なくとも１つのマスタノードは、
   前記通信システムを構成するノード及び前記通信システムで実行されるアプリケーションの少なくとも一方が変化したと判定した場合、前記少なくとも１つのスレーブノードのそれぞれについて、スリープ状態からノーマル状態へ遷移させるための条件である起動条件を決定するように構成された決定部（２１２）と、
   前記決定部により決定された前記起動条件を前記通信バスに送信するように構成された条件送信部（２１３）と、を備え、
   前記少なくとも１つのスレーブノードは、
   前記少なくとも１つのマスタノードから送信された前記起動条件を照合用記憶部（４３）に記憶するように構成された記憶処理部（２１７）と、
   前記スリープ状態において、前記通信フレームに含まれた前記起動情報と、前記照合用記憶部に記憶されている前記起動条件と、を比較してウェイクアップ条件が成立した場合、自ノードを前記スリープ状態から前記ノーマル状態へ遷移させるように構成された起動部（４４）と、
   を備える、通信システム。
2. 請求項１に記載の通信システムであって、
   前記決定部は、前記通信バスに新たにノードが接続されたと判定した場合、前記少なくとも１つのスレーブノードのそれぞれについて前記起動条件を決定する、通信システム。
3. 請求項１又は請求項２に記載の通信システムであって、
   前記決定部は、前記複数のノードのうち少なくとも１つについてアプリケーションが新たに追加又は変更されたと判定した場合、前記少なくとも１つのスレーブノードのそれぞれについて前記起動条件を決定する、通信システム。
4. 請求項１から請求項３までのいずれか１項に記載の通信システムであって、
   前記記憶処理部は、前記少なくとも１つのマスタノードから送信された前記起動条件を前記照合用記憶部に記憶する前に、前記照合用記憶部とは異なる記憶領域である保管用記憶部（２２）に前記起動条件を記憶し、前記スリープ状態への遷移が禁止されているスリープ禁止状態から、前記スリープ状態への移行が許可されているスリープ許可状態へ自ノードが遷移した場合、自ノードが実際に前記スリープ状態になる前に、前記保管用記憶部に記憶された前記起動条件を前記照合用記憶部に記憶する、通信システム。
5. 請求項４に記載の通信システムであって、
   前記記憶処理部は、前記保管用記憶部に記憶された前記起動条件を前記照合用記憶部に記憶するタイミングにおいて、前記起動条件が前記保管用記憶部に記憶されていない場合、任意の前記起動情報が含まれた前記通信フレームを受信することで自ノードを前記スリープ状態から前記ノーマル状態へ遷移させるフェール値を前記起動条件として前記照合用記憶部に記憶する、通信システム。
6. 請求項１から請求項５までのいずれか１項に記載の通信システムであって、
   前記少なくとも１つのマスタノードは、
   外部装置（１００）との間で無線通信を行うように構成された通信部（５）を更に備え、
   前記通信部は、前記外部装置から前記起動条件を受信可能である、通信システム。
7. 請求項１から請求項６までのいずれか１項に記載の通信システムであって、
   前記複数のノード間の前記通信フレームの送受信を中継するノードである少なくとも１つのゲートウェイ（１ｚ）が前記少なくとも１つのマスタノードとして機能する、通信システム。

Images