JP6255072B2

JP6255072B2 - 半導体装置

Info

Publication number: JP6255072B2
Application number: JP2016180331A
Authority: JP
Inventors: 真弘浅野; 百合子西原
Original assignee: Renesas Electronics Corp
Current assignee: Renesas Electronics Corp
Priority date: 2009-05-20
Filing date: 2016-09-15
Publication date: 2017-12-27
Anticipated expiration: 2030-03-05
Also published as: JP5849142B2; JP5636479B2; JP2017028719A; JP2014003703A; JP5756879B2; JP2016048958A; JP2015039224A; JP2013243758A; JP2015013641A; JP5607219B2; JP6010207B2

Description

本発明は、通信ネットワークにおける電源管理技術に関し、特に、ＣＡＮ(Controller Area Network)バスを介して通信する通信ネットワークシステムに用いられる半導体集積回路装置の低消費電力化に有効な技術に関する。

自動車には、ナビゲーションシステムやオーディオなどの情報系、エンジンやシャーシなどのパワートレイン系、あるいはエアコンやヘッドライト、ドアロックなどのボディ系などの各種制御を司るＥＣＵ(Electric Control Unit)が多数搭載されている。

これらＥＣＵを接続する通信ネットワークのプロトコルとして、たとえば、ＣＡＮが広く用いられている。自動車に搭載されるＥＣＵは、たとえば、エンジン、ブレーキ、エアバッグなどの常に制御が実行されるＥＣＵと、たとえば、サンルーフの開閉などイベントが発生したときのみに動作が必要なＥＣＵとに分けられるが、ＣＡＮでは、自動車がエンジンを始動すると、それ以降、すべてのＥＣＵがＯＮ状態となる仕様となっている。

また、この種の通信ネットワークにおけるデータ伝搬技術としては、たとえば、データを記憶、あるいは診断を実施するためにＣＡＮプロトコルを使用することなくＣＡＮバスを使用するもの（特許文献１参照）や、有線ＬＡＮの通信プロトコルにかかわらず、ＵＡＲＴ（Universal Asynchronous Receiver Transmitter）によるデータ通信を可能とするもの（特許文献２参照）などが知られている。

特表２００４−５３５７４２号公報特開２００６−２００３８号公報

ところが、上記のような通信ネットワークプロトコルによる通信技術では、次のような問題点があることが本発明者により見い出された。

自動車に搭載されるＥＣＵは、たとえば、エンジン、ブレーキ、エアバッグなどの常に制御が実行される（メッセージ送受信を行うべきイベントの発生頻度が相対的に多い）ＥＣＵと、たとえば、サンルーフの開閉などイベントが発生したときのみに動作が必要な（メッセージ送受信を行うべきイベントの発生頻度が相対的に少ない）ＥＣＵとに分けられる。

イベントが発生した際にのみ動作が必要なＥＣＵの場合には、該イベントが発生した場合のみＥＣＵの電源を入れれば、消費電力を抑えることができる。しかしながら、前述したように、エンジンが始動した以降は、すべてのＥＣＵがＯＮ状態となってしまい、常に多くのＥＣＵが電力を消費してしまうことになる。

自動車で使用される電気は、エンジンの力でまわっているオルタネータ(交流発電器)で作られているため、消費電力が少なければ、オルタネータへの負荷が減り、ガソリンの消費も減ることになるが、消費電力が大きくなることにより、自動車の発電負荷が大きくなり、自動車の燃費が低下してしまうという問題がある。

自動車に搭載されるＥＣＵの個数は年々増加しており、これらのＥＣＵが消費する電力も増加する一方であり、自動車の燃費がより大きく低下してしまう恐れが生じてしまうことになる。

また一方で、エンジン、ブレーキ等の自動車を安全に運行するのに必要とされるＥＣＵは通信ネットワークを介して相対的に頻繁に通信を行っており、かかる通信を阻害することは自動車の安全な運行に支障をきたすことにもなる。かかる観点からも、不急のＥＣＵからの通信を抑制する一方で、そのようなＥＣＵへの通信を行う場合に自動車の安全な運行に支障を来たさないような通信を行う必要がある。

本発明の目的は、通信ネットワークに接続される各ＥＣＵの電源供給を最適に制御することにより、自動車の消費電力を大幅に低減することのできる技術を提供することにある。

本発明の前記ならびにそのほかの目的と新規な特徴については、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。

本発明は、通信バスを介して入力される第１の通信プロトコルのインタフェースとなる通信プロトコルインタフェースと、該通信プロトコルインタフェースを介して入力されたメッセージに基づいて、アクチュエータ等を制御するコントローラと、該通信プロトコルインタフェースに電源を供給する第１のレギュレータと、通信プロトコルインタフェースから出力される制御信号に基づいて、コントローラ、およびコントローラにより制御されるアクチュエータ等へ電源を供給／停止する第２のレギュレータとを備え、通信プロトコルインタフェースは、通信バスから転送され、第１の通信プロトコルと異なるプロトコルの第２の通信プロトコルのメッセージに基づいて、制御信号を生成するものである。

また、本願のその他の発明の概要を簡単に示す。

本発明は、前記通信プロトコルインタフェースが、通信バスを介して転送されるメッセージが、第１の通信プロトコルのメッセージであるか、第２の通信プロトコルのメッセージであるかを判定し、第１の通信プロトコルのメッセージの場合、該メッセージをコントローラに送信するプロトコル判定部と、プロトコル判定部が第２の通信プロトコルのメッセージであると判定した際に、そのメッセージが入力され、該メッセージ中の認識番号を検出し、検出した認識番号と、半導体集積回路装置に個別に割り付けられた認識番号とが一致しているか否かを判断し、一致している際には、第２のレギュレータを動作させる制御信号を出力するＩＤ判断部とを備えたものである。

また、本発明は、前記コントローラに電源電圧が供給されると、該コントローラのアイドル時間を計測するタイマを備え、該コントローラは、コントローラのアイドル時間が任意の時間経過すると、ＩＤ判断部に電源遮断指示信号を出力し、該ＩＤ判断部は、電源遮断指示信号を受信すると、第２のレギュレータの動作を停止する制御信号を出力するものである。

さらに、本発明は、前記通信プロトコルインタフェースが、ＩＤ判断部が前記第２のレギュレータを動作させたか、または停止させたかを示す動作情報を格納する電源動作情報格納部を備え、ＩＤ判断部は、第２のレギュレータを動作させた際、または第２のレギュレータを停止させた際に、電源動作情報格納部に動作を格納するものである。

また、本発明は、前記コントローラが、前記第１の通信プロトコルにより、前記第１の通信プロトコルにより通信を行っているすべての半導体集積回路装置に前記第１の通信プロトコルによる通信を停止させる通信停止メッセージを前記通信バスを介して出力し、前記半導体集積回路装置の通信を停止させた後、前記第１の通信プロトコルによる通信に参加させたい任意の半導体集積回路装置に対して、前記通信バスを介して前記第２の通信プロトコルのメッセージを転送して、任意の前記半導体集積回路装置の第２のレギュレータを動作させるものである。

さらに、本発明は、前記第１の通信プロトコルによる通信を停止した前記半導体集積回路装置が、前記通信停止メッセージに設定された任意の時間が経過した後、前記第１の通信プロトコルによる通信を再開するものである。

また、本発明は、前記第１の通信プロトコルによる通信を停止した前記半導体集積回路装置が、前記通信プロトコルインタフェースが、前記第２の通信プロトコルによる前記第２のレギュレータを動作させるメッセージが転送されるまで前記第２のレギュレータの動作を停止しているものである。

さらに、本発明は、前記コントローラが、前記第２の通信プロトコルにより、前記第１のレギュレータを動作させ、前記半導体集積回路装置を起動させ、前記第１の通信プロトコルによる通信を開始させるシステム起動メッセージを前記通信バスを介して出力し、起動した前記半導体集積回路装置から、プラグインされた半導体集積回路装置があるか否かを確認し、プラグインされた前記半導体集積回路装置が存在する場合、プラグインされた前記半導体集積回路装置に、少なくとも前記認識番号を含む動作認識情報を前記第１の通信プロトコルにより取得するものである。

また、本発明は、外部トリガにより前記半導体集積回路装置が動作する場合、前記第２のレギュレータは、前記コントローラ、および前記アクチュエータへ電源供給を停止せず、前記コントローラはスタンバイ状態となり、前記通信プロトコルインタフェースは、第２の通信プロトコルによるメッセージを受け付ける状態よりなるものである。

さらに、本発明は、前記コントローラが、外部トリガを検出してスタンバイ状態から動作状態に遷移すると、外部トリガにより前記半導体集積回路装置が起動したことを通知する起動通知信号を前記通信バスに転送するものである。

また、本発明は、前記コントローラが、外部トリガを検出してスタンバイ状態から動作状態に遷移すると、前記通信プロトコルインタフェースを前記第１の通信プロトコルによる通信が開始されるように設定し、外部トリガにより前記半導体集積回路装置が起動したかの問い合わせが発生した際に、起動したことを通知するものである。

さらに、本発明は、前記第１の通信プロトコルが自動車用通信プロトコルであり、ＣＡＮ、またはＦｌｅｘＲａｙといった自動車内ネットワークとして主要に用いられている通信プロトコルである。

また、本発明は、前記第２の通信プロトコルが、ＵＡＲＴといった主に半導体集積回路間での通信に用いられる通信プロトコル、またはＬＩＮ(Local Interconnect Network)といった自動車内ネットワークとして従属的に用いられる通信プロトコルよりなるものである。または通信メッセージの構成はＣＡＮまたはＦｌｅｘＲａｙと同じであるが、通信の周波数が異なる通信プロトコルよりなるものである。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

（１）コントローラ、およびアクチュエータの動作が不要な場合に、電源供給を停止することができるので、半導体集積回路装置の消費電力を大幅に低減することができる。

（２）また、所定の場合にはＥＣＵ間の通信を停止させ、またはＥＣＵ内の半導体集積回路の動作を停止させることで、消費電力および燃費の向上に留まらず、自動車の安全性能の向上を図ることができる。

本発明の実施の形態１による車内ネットワークの接続形態の一例を示すブロック図である。図１のＥＣＵに設けられたＣＡＮトランシーバ／レシーバにおける構成の一例を示すブロック図である。本発明の実施の形態１によるＣＡＮバスを介して転送される通信フォーマットの一例を示す説明図である。図３のＵＡＲＴデータフォーマットの一例を示す説明図である。図２のＥＣＵにおける動作の一例を示すフローチャートである。本発明の実施の形態１によるマスタＥＣＵとスレーブＥＣＵとの通信の一例を示す動作フローチャートである。図２のＣＡＮトランシーバ／レシーバがフィルタリングを行う際のＣＡＮ通信のボーレートの一例を示す説明図である。図２のＣＡＮトランシーバ／レシーバにおける構成の他の例を示すブロック図である。本発明の実施の形態２によるマスタＥＣＵとスレーブＥＣＵとの通信の一例を示す動作フローチャートである。図９におけるマスタＥＣＵの動作の一例を示すフローチャートである。図１０におけるＣＡＮ通信に参加しているスレーブＥＣＵの動作の一例を示すフローチャートである。図１０におけるＣＡＮ通信に参加していないスレーブＥＣＵにおける動作の一例を示すフローチャートである。本発明の実施の形態３によるＥＣＵがプラグインされた際のマスタＥＣＵとスレーブＥＣＵとの通信の一例を示す動作フローチャートである。図１３の動作時におけるマスタＥＣＵの動作の一例を示すフローチャートである。図１３の動作時における既存のスレーブＥＣＵの動作の一例を示すフローチャートである。図１３の動作時におけるプラグインされたスレーブＥＣＵの動作の一例を示すフローチャートである。本発明の実施の形態４によるマスタＥＣＵが、スレーブＥＣＵがＣＡＮ通信に参加しているかを確認する動作の一例を示すフローチャートである。

以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。

（実施の形態１）
図１は、本発明の実施の形態１による車内ネットワークの接続形態の一例を示すブロック図、図２は、図１のＥＣＵに設けられたＣＡＮトランシーバ／レシーバにおける構成の一例を示すブロック図、図３は、本発明の実施の形態１によるＣＡＮバスを介して転送される通信フォーマットの一例を示す説明図、図４は、図３のＵＡＲＴデータフォーマットの一例を示す説明図、図５は、図２のＥＣＵにおける動作の一例を示すフローチャート、図６は、本発明の実施の形態１によるマスタＥＣＵとスレーブＥＣＵとの通信の一例を示す動作フローチャート、図７は、図２のＣＡＮトランシーバ／レシーバがフィルタリングを行う際のＣＡＮ通信のボーレートの一例を示す説明図、図８は、図２のＣＡＮトランシーバ／レシーバにおける構成の他の例を示すブロック図である。

本実施の形態１において、自動車の車内ネットワークの接続形態は、図１に示すように、複数のＥＣＵ１，１ａ，１ｂが通信バスとなるＣＡＮバスＢｃを介して相互に接続された構成からなる。これらＥＣＵ１，１ａ，１ｂは、たとえば、ナビゲーションシステムやオーディオなどの情報系、エンジンやシャーシなどのパワートレイン系、あるいはエアコンやヘッドライト、ドアロックなどのボディ系などの各種制御を司る半導体集積回路を有する制御装置である。これらＥＣＵ１，１ａ，１ｂには、各ＥＣＵ１，１ａ，１ｂによって制御されるアクチュエータＡｃがそれぞれ接続されている。ただし、アクチュエータが接続されていないＥＣＵであってもよい。

ＥＣＵ１は、ＣＡＮトランシーバ／レシーバ２、レギュレータ３，４、コントローラとなるＭＣＵ(Micro Controller Unit)５から構成されている。ＥＣＵ１（，１ａ，１ｂ）は、ＣＡＮトランシーバ／レシーバ２を介してＣＡＮバスＢｃと相互に接続されている。ＣＡＮバスＢｃには、第１の通信プロトコルであるＣＡＮプロトコルの差動信号、または第２の通信プロトコルであるＵＡＲＴプロトコルの差動信号が転送される。

通信の電気的インタフェースとなるＣＡＮトランシーバ／レシーバ２は、ＣＡＮバスＢｃを介して入力される差動信号をデジタル信号に変換、およびＭＣＵ５から出力されるデジタル信号を差動信号に変換してＣＡＮバスＢｃに出力すると共に、ＣＡＮバスＢｃを介して入力される差動信号の通信プロトコルが、ＣＡＮプロトコルかＵＡＲＴプロトコルかを判定し、判定結果がＵＡＲＴプロトコルの際には、ＵＡＲＴデータの解析を行い、それに基づいてレギュレータ４を制御する。

第１のレギュレータとなるレギュレータ３は、たとえば、自動車のバッテリなどから供給される電源電圧をレギュレートしてＣＡＮトランシーバ／レシーバ２の動作電源として供給するレギュレータである。

第２のレギュレータとなるレギュレータ４は、ＣＡＮトランシーバ／レシーバ２から出力される制御に基づいて、自動車のバッテリなどから供給される電源電圧をレギュレートし、ＭＣＵ５、およびアクチュエータＡｃの動作電源として供給するレギュレータである。

ＭＣＵ５は、ＣＡＮインタフェース６、通信制御部７、ＲＡＭ(Random Access Memory)８、タイマ９、割り込みコントローラ１０、ＣＰＵ(Central Processing Unit)１１、およびＲＯＭ(Read Only Memory)１２から構成されている。また、通信制御部７、ＲＡＭ８、タイマ９、ＣＰＵ１１、およびＲＯＭ１２は、内部バスＢｓを介して相互に接続されている。

また、他のＥＣＵに対してＣＡＮプロトコル、またはＵＡＲＴプロトコルのどちらかでメッセージの送信を行う場合、ＭＣＵ５は送信するメッセージのデジタル信号とどちらのプロトコルで送信するかを示す情報とをＣＡＮトランシーバ／レシーバ２に送信する。

ＣＡＮインタフェース６は、ＭＣＵ５とＣＡＮバスＢｃとのインタフェースである。通信制御部７は、ＣＡＮプロトコルに従って他のＥＣＵとの通信を制御する。ＲＡＭ８は、データの一時的な保存に用いられ、たとえば、ＣＡＮネットワークから受信したデータや、ＣＡＮネットワークへ送信するデータの一時的な退避などに使用される。

タイマ９は、タイマクロックなどのカウントアップを行って所望の時間設定をし、ある時間に到達するとタイマカウンタ信号を出力する。割り込みコントローラ１０は、実行中のプログラムより優先させて実行するプログラムがある場合に、実行中のプログラムの中断や、割り込みプログラムの実行を制御する。割り込みプログラムが終了すると、中断していたプログラムが再開する。通常、割り込みコントローラ１０は、ＭＣＵ５内部からの内部割り込みと、ＭＣＵ５外部からの外部割り込みとを制御する。

たとえば、一定時間、ＣＡＮネットワークからのデータ受信がない場合に、タイマ９から出力されるタイムアウト信号を受け取り、割り込みプログラムを発生させ、割り込み処理信号を出力する。

ＣＰＵ１１は、ＭＣＵ５におけるすべての制御を司る。ＲＯＭ１２は、主にＭＣＵ５の動作プログラムが格納されている。動作プログラムは、たとえば、ＣＡＮ通信プログラム、アクチュエータ制御プログラム、電源遮断処理プログラムなどである。

ここでは、ＥＣＵ１の構成について記載したが、他のＥＣＵ１ａ，１ｂについても、ＥＣＵ１と同様の構成となっている。

図２は、ＣＡＮトランシーバ／レシーバ２における構成の一例を示すブロック図である。

ＣＡＮトランシーバ／レシーバ２は、図示するように、トランシーバ／レシーバ１３、プロトコル判定部となるセレクト回路１４、ＵＡＲＴ用回路１５、ＩＤ判断部となるＩＤ判断回路１６、電源動作情報格納部となるレジスタ１７、ならびにオンチップオシレータ１８から構成されている。

ＣＡＮトランシーバ／レシーバ２は、前述したように、ＭＣＵ５に接続されている。そして、ＭＣＵ５には、アクチュエータＡｃが接続されており、該アクチュエータＡｃをＭＣＵ５が駆動制御する。

トランシーバ／レシーバ１３は、ＣＡＮバスＢｃを介して入力される差動信号をデジタル信号に変換、およびＭＣＵ５から出力されるデジタル信号を差動信号に変換してＣＡＮバスＢｃに出力する。

セレクト回路１４は、次のような方法でＣＡＮバスＢｃから受信した信号のプロトコルを判別する。

ＣＡＮプロトコルによる通信とＵＡＲＴプロトコルとの通信を重畳可能とする場合、たとえば異なる通信周波帯域（ＣＡＮプロトコル通信を高周波帯域で行い、ＵＡＲＴプロトコル通信を低周波帯域で行う）とする。このような異なる周波数帯の信号を重畳させて通信を行うことは、非接触ＩＣカードや電力線通信等の公知の技術が存在しており、これらの技術を適宜採用すればよい。

受信の際はＣＡＮバスＢｃから受信した信号をＡＭ復調により分離して夫々のアナログ信号状態のプロトコル信号をデジタル信号に変換する。送信の際はメッセージのデジタル信号を、どちらのプロトコルで送信するかを示す情報に基づきプロトコルに応じた通信周波帯域のアナログ信号に変換し、変換したアナログ信号をＡＭ変調により重畳しＣＡＮバスＢｃに出力する。

若しくは、ＣＡＮプロトコルによる通信とＵＡＲＴプロトコルによる通信とを時間的に分離する場合は、トランシーバ／レシーバ１３はＣＡＮバスＢｃから受信した信号をアナログ−デジタル変換し、後段のセレクト回路１４がいずれの通信が行われるタイミングかに応じて受信したプロトコルの判別をし、送信の際はＭＣＵ５からのメッセージのデジタル信号をデジタル−アナログ変換し、いずれの通信を行うタイミングかに応じてアナログ信号をＣＡＮバスＢｃに出力する。時間的分離と周波数分離との両方を行うことで、プロトコルの分離をより確実にすることも可能となる。

セレクト回路１４は、トランシーバ／レシーバ１３を介して入力されたデジタル信号が、ＣＡＮプロトコルであるか、ＵＡＲＴプロトコルであるかを判定し、ＣＡＮプロトコルの場合には、該デジタル信号をＭＣＵ５に出力し、ＵＡＲＴプロトコルの際には、該デジタル信号をＵＡＲＴ用回路１５に出力するように切り替え制御を行う。

セレクト回路１４は、受信したデジタル信号がＣＡＮプロトコルかＵＡＲＴプロトコルかは上述した周波数の相違、若しくは予め決められている送受信タイミング情報に基づき判別する。

また、送信の場合、セレクト回路１４は、ＭＣＵ５から入力されたメッセージのデジタル信号とどちらのプロトコルで送信するかを示す情報とをトランシーバ／レシーバ１３に送信し、またはどちらのプロトコルで送信するかを示す情報と予め決められている送受信タイミング情報とに基づき、ＭＣＵ５から入力されたメッセージのデジタル信号を定められたタイミングでトランシーバ／レシーバ１３に送信する。

ＵＡＲＴ用回路１５は、セレクト回路１４を介して入力されたデジタル信号が、ＵＡＲＴフォーマットに合致しているか否かを判定し、合致している場合には、ＩＤ判断回路１６に該デジタル信号を出力する。

ＩＤ判断回路１６は、入力されたデジタル信号の認識番号であるＣＡＮＩＤを検出し、そのＣＡＮＩＤが、ＥＣＵ毎に割り付けられたＣＡＮＩＤと同じであるか判断し、同じ場合には、レギュレータ４に制御信号であるイネーブル信号ＥＮを出力する。

レジスタ１７は、ＩＤ判断回路１６によってレギュレータ４がＯＮ状態となっていることを示す情報を格納する。オンチップオシレータ１８は、ＣＡＮトランシーバ／レシーバ２における動作クロック信号を生成する。

図３は、ＣＡＮバスＢｃを介して転送される通信フォーマットの一例を示す説明図である。

通信が開始される場合、始めの１メッセージ目には、ＵＡＲＴフォーマットのウェイトメッセージ１９が転送され、続いて、２メッセージ目に、ＵＡＲＴフォーマットのＣＡＮＩＤメッセージ２０が転送される。その後、ＣＡＮフォーマットのＣＡＮフレーム２１が転送され、ＣＡＮ通信が開始される。

図４は、１メッセージ目、および２メッセージ目に転送されるＵＡＲＴデータフォーマットの一例を示す説明図である。

１メッセージ目のウェイトメッセージ１９は、起動用のメッセージであり、フレームの開始を表すＳＯＦ（Start Of Frame）１９ａ、たとえば、８ビットからなる任意のデータビット１９ｂ、パリティビット１９ｃ、およびデータの終わりを示すストップビット１９ｄから構成されている。

また、２メッセージ目のＣＡＮＩＤメッセージ２０は、フレームの開始を表すＳＯＦ２０ａ、たとえば、８ビットのＣＡＮＩＤからなるデータビット２０ｂ、パリティビット２０ｃ、ならびにデータの終わりを示すストップビット２０ｄから構成されている。

ここで、ウェイトメッセージ１９は、オンチップオシレータ１８が発振を開始した後、発振が安定するまで間に必要な時間を確保するための起動待ち時間処理のために用いられるが、該オンチップオシレータ１８が発振安定するまでの時間がＣＡＮＩＤメッセージを受信してからＣＡＮフレーム２１を受信するまでの時間と比較して十分に短い場合には、省略し、ＣＡＮＩＤメッセージ２０を転送するようにしてもよい。

また、データビット２０ｂにおいては、ＣＡＮＩＤだけでなく、１対１通信（マスタのＥＣＵと特定のＥＣＵとの通信）、一斉通信（マスタのＥＣＵとその他のすべてのＥＣＵとの通信）、あるいはグループ通信（マスタのＥＣＵと特定のグループに属するＥＣＵとの通信）などの通信モードを設定する情報を含めるようにしてもよい。

このマスタのＥＣＵは、あるＥＣＵが他のＥＣＵに対してメッセージを送信する場合に、送信元のＥＣＵがその時々にマスタのＥＣＵとなるが、固定的に特定のＥＣＵがマスタとなるのであってもよい。

次に、本実施の形態によるＥＣＵ１における動作について、図５のフローチャートを用いて説明する。

まず、ＣＡＮトランシーバ／レシーバ２のトランシーバ／レシーバ１３が、ＣＡＮバスＢｃを介してメッセージを受信すると（ステップＳ１０１）、該トランシーバ／レシーバ１３は、ＣＡＮバスＢｃを介して受信した差動信号のメッセージをデジタル信号に変換し、セレクト回路１４に出力する。

セレクト回路１４は、入力された信号がＣＡＮフォーマットのメッセージであるか、ＵＡＲＴフォーマットのメッセージあるかを判断し（ステップＳ１０２）、ＣＡＮフォーマットのメッセージの場合には、該メッセージをＭＣＵ５に出力する。

そして、ＭＣＵ５は、入力されたメッセージが、ＥＣＵ１自身のＣＡＮＩＤを指定しているか否かを判断し（ステップＳ１０３）、ＥＣＵ１のＣＡＮＩＤであれば、メッセージの処理を実行する（ステップＳ１０４）。

また、ステップＳ１０２の処理において、ＵＡＲＴフォーマットのメッセージの場合には、ＵＡＲＴ用回路１５にメッセージを出力する。ＵＡＲＴ用回路１５は、入力されたメッセージがＵＡＲＴフォーマットに合致しているかを判断し、合致している際には、ＩＤ判断回路１６に、該メッセージを出力する。

ＩＤ判断回路１６は、入力されたメッセージがＥＣＵ１自身のＣＡＮＩＤを指定しているか否かを判断し（ステップＳ１０５）、ＥＣＵ１のＣＡＮＩＤであれば、ＩＤ判断回路１６は、イネーブル信号ＥＮをレギュレータ４に出力し、該レギュレータ４をＯＮさせてＥＣＵ５、およびアクチュエータＡｃに電源を供給する（ステップＳ１０６）。このとき、ＩＤ判断回路１６は、レジスタ１７に対してレギュレータ４がＯＮ状態であることを示す情報を書き込む処理を行う。

このように、レジスタ１７にレギュレータ４がＯＮ状態であることを示す情報を書き込むことにより、すでにＭＣＵ５に電源が供給されている状態で、ＵＡＲＴフォーマットのメッセージにより、レギュレータ４をＯＮする指示があった場合であっても、ＩＤ判断回路１６によってレギュレータ４をＯＮさせるという処理を省略することが可能となる。

レジスタ１７にレギュレータ４がＯＮ状態であることを示す情報が書き込まれると、タイマ９は、カウントアップを開始し、ＣＡＮバスＢｃのアイドル時間を監視する。アイドル時間が任意の時間を経過すると、ＭＣＵ５は、ＩＤ判断回路１６に対して電源遮断指示信号ＳＤを出力する。

ＩＤ判断回路１６は、電源遮断指示信号ＳＤを受信すると、インアクティブのイネーブル信号ＥＮをレギュレータ４に出力し、該レギュレータ４をＯＦＦさせて、ＭＣＵ５、ならびにアクチュエータＡｃの電源供給を停止する。このとき、ＩＤ判断回路１６は、レギュレータ４がＯＮ状態であることを示す情報をレジスタ１７から削除する。

あるいは、マスタとなるＥＣＵが、動作していないＥＣＵに対して電源遮断メッセージを送信することにより、ＩＤ判断回路１６がインアクティブのイネーブル信号ＥＮをレギュレータ４に出力するようにしてもよい。

図６は、マスタＥＣＵとなるＥＣＵ１ａとスレーブＥＣＵとなるＥＣＵ１との通信の一例を示す動作フローチャートである。

まず、ＥＣＵ１ａが、ＥＣＵ１ｂ宛にメッセージを送信すると（ステップＳ２０１）、ＥＣＵ１のＣＡＮトランシーバ／レシーバ２は、該メッセージがＥＣＵ１ｂに対するものであるので、レギュレータ４をＯＮさせず、ＥＣＵ１のＭＣＵ５に対して電源供給、および起動／メッセージ転送を行わない。

続いて、ＥＣＵ１ａが、たとえば、ＥＣＵ１，１ｂにＵＡＲＴフォーマットの１つ目のメッセージであるウェイトメッセージ１９（図３）を送信すると（ステップＳ２０２）、ＥＣＵ１，１ｂのＣＡＮトランシーバ／レシーバ２が起動する。

その後、２メッセージ目のＣＡＮＩＤメッセージ２０（図３）が入力され、このＣＡＮＩＤメッセージ２０が、たとえば、ＥＣＵ１、およびＥＣＵ１ｂ宛の場合、ＥＣＵ１，１ｂのＣＡＮトランシーバ／レシーバ２は、レギュレータ４をそれぞれ起動させて、ＥＣＵ１のＭＣＵ５とアクチュエータＡｃ、およびＥＣＵ１ｂのＭＣＵ５とアクチュエータＡｃにそれぞれ電源供給を行う（ステップＳ２０３）。

そして、ＥＣＵ１宛のＣＡＮプロトコルのメッセージが入力されると、該ＥＣＵ１は、メッセージ処理を行い（ステップＳ２０４）、ＥＣＵ１ｂ宛のＣＡＮプロトコルのメッセージが入力されると、ＥＣＵ１のＭＣＵ５は当該メッセージを処理する必要がないと判断し、当該メッセージを破棄する（ステップＳ２０５）。

また、ステップＳ２０５において、ＣＡＮトランシーバ／レシーバ２がＣＡＮＩＤのフィルタリング機能も持つ場合には、ＭＣＵ５へのメッセージの転送は行わず、メッセージを破棄することも可能である。

その後、ＥＣＵ１のアイドル時間が任意の時間を経過すると、ＭＣＵ５からＩＤ判断回路１６に対して電源遮断指示信号ＳＤが出力され、ＩＤ判断回路１６によってレギュレータ４がＯＦＦされ、ＭＣＵ５，ならびにアクチュエータＡｃの電源遮断処理が実行される（ステップＳ２０６）。

それにより、本実施の形態によれば、ＣＡＮ通信が行われているＥＣＵのみに電源が供給され、通信が行われていないＥＣＵにおけるＭＣＵ、およびアクチュエータＡｃに対しては電源供給が停止されるので、消費電力を大幅に低減することができる。

次に、ＣＡＮバスＢｃを介して送信されるＵＡＲＴフレームとＣＡＮフレームとを識別するフィルタリング技術について説明する。ここでは、ＣＡＮプロトコルによる通信のボーレートとして、たとえば、５００ｋｐｓを使用した場合の動作の一例を説明する。

ＣＡＮ通信のボーレートを５００ｋｐｓとすると、１ビットは２μｓとなる。ＣＡＮフレームは、ＣＡＮプロトコルで定義されているスタッフィング機能により、５ビットより長く同一レベルが続かない。

そのため、１０μｓより長く’Ｌｏ’が続いた場合、その信号はＣＡＮフレームのＳＯＦ信号でないと判断し、その信号をＵＡＲＴＳＯＦとして検出する。

ＣＡＮトランシーバ／レシーバ２は、図７に示すように、受信信号中に立ち下がりエッジを検出した場合、たとえば、１μｓ間隔でデータをサンプリングする。立ち下がりエッジから、１１サンプル目が１０μｓとなる。立ち下がりエッジから１２サンプル目までが、’Ｌｏ’の場合、ＵＡＲＴＳＯＦ検出となる。

また、ＣＡＮトランシーバ／レシーバ２は、ＵＡＲＴモード時、ＣＡＮフレームは無視し、ＵＡＲＴＳＯＦ検出後、受信データをＵＡＲＴ用回路１５（図２）へ接続してＵＡＲＴ受信を開始する。

そして、ＩＤ判断回路１６（図２）が、ＵＡＲＴフレームに含まれるＣＡＮＩＤと自ＥＣＵのＣＡＮＩＤとが一致しているか否かを判断し、一致している場合、セレクト回路１４（図２）は、接続経路をＭＣＵ５に接続し（ＣＡＮモード）、以降のデータをＭＣＵ５に入出力する。

続いて、ＣＡＮＩＤの設定技術について説明する。

ＣＡＮＩＤは、たとえば、トランシーバ／レシーバ２に設定されており、たとえば、ＣＡＮトランシーバ／レシーバ２にフラッシュメモリなどに例示される不揮発性半導体メモリを内蔵する。

そして、その不揮発性半導体メモリにフラッシュライタなどを用いてＣＡＮＩＤを書き込む。また、フラッシュライタなどによって予めＣＡＮＩＤを書き込むだけでなく、たとえば、システムの起動時にマスタとなるＥＣＵは、すべてのＥＣＵをシステム起動メッセージである全ＥＣＵ起動信号などによって起動させ、すべてのＥＣＵがＣＡＮフレームを送信して、送信した順にＣＡＮＩＤを取得し、不揮発性半導体メモリに格納する。

ＣＡＮの既存の通信プロトコルでは、メッセージ送信を希望するＥＣＵはネットワーク上で他のＥＣＵがメッセージを送信していない場合は、いずれのＥＣＵもメッセージの送信を開始することができる。

ＣＡＮＩＤ取得の段階ではいずれのＥＣＵも自ＥＣＵを特定してマスタとなるＥＣＵにメッセージ送信をすることができず、既存の通信プロトコルによりＣＡＮＩＤ取得要求メッセージを送信することになる。

この場合、複数のＥＣＵがＣＡＮＩＤ取得要求メッセージを送信することによりネットワーク上で信号の輻輳を生じ、マスタとなるＥＣＵがメッセージを正しく受信できないことも生じる。

ＣＡＮＩＤ取得要求メッセージを送信したＥＣＵは、ネットワーク上で信号の輻輳を生じたことを検知した場合、一旦メッセージの送信を停止し、所定時間を経過した後にＣＡＮＩＤ取得要求メッセージの再送を行うことを繰り返すことで、順次ＣＡＮＩＤを取得する。

また、ＣＡＮトランシーバ／レシーバ２に、ハードウェア的に予めＣＡＮＩＤを実装したり、たとえば、図８に示すように、外付けの抵抗Ｒ１を用いてＣＡＮＩＤを設定する構成としてもよい。

この場合、ＣＡＮトランシーバ／レシーバ２は、分圧用の抵抗２２、ならびにＡ／Ｄ変換器２３が設けられる構成となる。抵抗Ｒ１の一方の接続部には、電源電圧ＶＤＤが接続され、該抵抗Ｒ１の他方の接続部には、抵抗２２の一方の接続部が接続されている。

抵抗２２の他方の接続部には、基準電位ＶＳＳが接続されている。そして、抵抗Ｒ１と抵抗２２との接続部が、Ａ／Ｄ変換器２３の入力部に接続されており、該Ａ／Ｄ変換器２３の出力部がレジスタ１７に接続されている。

抵抗Ｒ１と抵抗２２とによって分圧された電圧は、Ａ／Ｄ変換器２３によってデジタルデータに変換され、該デジタルデータがレジスタ１７に格納されることにより、ＣＡＮＩＤが設定される。よって、ＣＡＮＩＤは、抵抗Ｒ１と抵抗２２とによって分圧された電圧値によって設定されることになる。

その他にも、ＭＣＵ５に設けられたメモリなどにＣＡＮＩＤを格納し、該ＭＣＵ５によってＣＡＮトランシーバ／レシーバ２に該ＣＡＮＩＤを設定するようにしてもよい。

（実施の形態２）
図９は、本発明の実施の形態２によるマスタＥＣＵとスレーブＥＣＵとの通信の一例を示す動作フローチャート、図１０は、図９におけるマスタＥＣＵの動作の一例を示すフローチャート、図１１は、図１０におけるＣＡＮ通信に参加しているスレーブＥＣＵの動作の一例を示すフローチャート、図１２は、図１０におけるＣＡＮ通信に参加していないスレーブＥＣＵにおける動作の一例を示すフローチャートである。

本実施の形態２では、前記実施の形態１の図１に示す自動車の車内ネットワークにおいて、電源が供給されていない（ＣＡＮプロトコルによる通信が行われていない）ＥＣＵを起動させ、通信を開始させる技術について説明する。

図９は、マスタＥＣＵとなるＥＣＵ１とスレーブＥＣＵとなるＥＣＵ１ａ，１ｂとの通信の一例を示す動作フローチャートである。

この図９では、ＥＣＵ１とＥＣＵ１ａとがＣＡＮ通信を行っており、その後、ＣＡＮ通信を行っていないＥＣＵ１ｂを起動し、ＣＡＮ通信させるまでの動作を示している。また、図９の左側には、ＥＣＵ１に設けられたレジスタ１７（図２）の状態を示している。

レジスタ１７の左から右にかけては、ＥＣＵ１、ＥＣＵ１ａ、およびＥＣＵ１ｂにおけるそれぞれの状態データが格納されており、’１’はＣＡＮ通信に参加している状態（以下、ＣＡＮモードという）を示しており、’０’は、ＵＡＲＴプロトコルによる通信が可能な状態（以下、ＵＡＲＴモードという）を示している。

ＥＣＵ１とＥＣＵ１ａとがＣＡＮ通信を行っている状態において（ステップＳ３０１）、何らかの理由によってＥＣＵ１ｂもＣＡＮ通信に参加する必要が生じると、ＥＣＵ１は、ＣＡＮ通信を行っているすべてのＥＣＵ（この場合、ＥＣＵ１ａ）に対して、通信停止メッセージとなるＣＡＮ通信停止フレームを送信する（ステップＳ３０２）。

このとき、ＥＣＵ１ａがＣＡＮモードであり、ＥＣＵ１ｂがＵＡＲＴモードであるので、レジスタ１７のＥＣＵ１ａの状態を示すデータは’１’となっており、ＥＣＵ１ｂの状態を示すデータは’０’となっている。

ＣＡＮ通信停止するフレームは、ＣＡＮプロトコルでは規定されていないため、通信システムでフレームの内容により決めることになり、たとえば、ＣＡＮ通信停止フレームは、フレーム内のＩＤ(identifier)のｂｉｔがすべて’０’のフレームなどとする。

ＣＡＮ通信停止フレームとしてフレーム内のＩＤ(identifier)のｂｉｔ全てを‘０’とすることにより、他のＥＣＵがメッセージを送信中であったとしても、優先順位の調停により最優先となり、ＣＡＮバス上のすべてのＥＣＵがこのフレームを受信可能となる。

そして、ＣＡＮ通信を行っているすべてのＥＣＵ（ＥＣＵ１ａ）は、ＣＡＮ通信停止フレームを受信すると、ＣＡＮ通信を停止する（ステップＳ３０３）。

ＣＡＮ通信を停止する場合、たとえば、ＥＣＵ１によって指示された任意の期間、ＣＡＮフレームの送信を停止し、その期間が経過すると自動的にＣＡＮ通信に復帰するパターンや、ＣＡＮ通信を停止し、ＭＣＵ５（図１）の電源をＯＦＦし、ＣＡＮトランシーバ／レシーバ２（図１）がＵＡＲＴプロトコルによる通信を行うモードに遷移し、スタンバイ状態に移行するパターンなど様々なパターンが考えられる。

なお、図９において、ＥＣＵ１が送信するＣＡＮ通信停止フレームは、該ＥＣＵ１によって指示された任意の期間が経過すると、自動的にＥＣＵ１ａがＣＡＮ通信に復帰するパターンとする。

また、自動的にＣＡＮ通信に復帰する場合には、ＣＡＮトランシーバ／レシーバ２は、ＣＡＮ通信が行える状態で待機し、ＭＣＵ５の電源はＯＦＦしない。

続いて、ＥＣＵ１は、前記実施の形態１に記載した技術により、ＵＡＲＴプロトコルの通信を用いて新たにＣＡＮ通信に参加させたいＥＣＵ１ｂを起動させる（ステップＳ３０４，Ｓ３０５）。

ＥＣＵ１ｂが起動したことにより、該ＥＣＵ１ｂがＣＡＮ通信に参加し、レジスタ１７のＥＣＵ１ｂの状態を示すデータが’０’から’１’に書き換えられる。

そして、ＥＣＵ１によって指示された任意の期間が経過すると、ＥＣＵ１ａは自動的に復帰を行い（ステップＳ３０６）、ＥＣＵ１、ＥＣＵ１ａ，ならびにＥＣＵ１ｂのすべてがＣＡＮ通信に参加している状態となる（ステップＳ３０７）。

なお、マスタＥＣＵがＣＡＮ通信を停止する方法としては、上記したようにＣＡＮフレームによってスレーブＥＣＵのＣＡＮ通信を停止させる他に、たとえば、光通信などを用いている場合には、停止信号を通常の信号に重畳させることによっても可能である。

また、ステップＳ３０２でＥＣＵ１がＣＡＮ通信停止フレームを出力する代わりに、ＵＡＲＴプロトコルの通信によりＥＣＵ１ｂを起動させることも行い得る(ステップＳ３０２‘とする)。

この場合、ＥＣＵ１がＵＡＲＴプロトコルの通信を行っていることをＥＣＵ１ａが検知し、かかる通信期間中はＥＣＵ１ａはＣＡＮ通信を行わないように制御される。かかる動作を行った場合は、ステップＳ３０２’を行った後、ステップＳ３０７に遷移することが可能となる。

図１０は、ＣＡＮ通信を行っていないＥＣＵを起動させ、ＣＡＮ通信を開始させる際のマスタとなるＥＣＵ１における動作の一例を示すフローチャートである。

まず、ＥＣＵ１は、ＣＡＮ通信に参加していないＥＣＵがある場合、そのＥＣＵを起動させる必要があるか否かを判断する（ステップＳ４０１）。ＣＡＮ通信に参加していないＥＣＵを起動させる必要があると判断すると、ＥＣＵ１は、車内ネットワークのシステムがＣＡＮ通信中か否かを判断する（ステップＳ４０２）。

ＣＡＮ通信中でない場合には、後述するステップＳ４０４の処理を実行し、ＣＡＮ通信中の場合、ＥＣＵ１は、ＣＡＮ通信に参加しているすべてのＥＣＵに対してＣＡＮ通信停止フレームを送信し（ステップＳ４０３）、該ＥＣＵのＣＡＮ通信を停止させる。

ＣＡＮ通信に参加しているすべてのＥＣＵのＣＡＮ通信が停止すると、ＥＣＵ１は、ＵＡＲＴプロトコルの通信を用いて新たにＣＡＮ通信に参加させたいＥＣＵ１ｂを起動させる（ステップＳ４０４）。

この場合、前記実施の形態１において説明したように、始めの１メッセージ目には、ＵＡＲＴフォーマットのウェイトメッセージが転送され、続いて、２メッセージ目に、ＵＡＲＴフォーマットのＣＡＮＩＤメッセージが転送される。

そして、ステップＳ４０４の処理において、起動させたいＥＣＵが起動すると、ＣＡＮフォーマットのＣＡＮフレーム２１が転送され、ＣＡＮ通信が開始される（ステップＳ４０５）。

図１１は、ＣＡＮ通信を行っていないＥＣＵを起動させ、ＣＡＮ通信を開始させる際のマスタとなるＥＣＵ１がＣＡＮ通信を行っていないＥＣＵ１ｂを起動させる際のＣＡＮ通信を行っているスレーブＥＣＵであるＥＣＵ１ａにおける動作の一例を示すフローチャートである。

まず、ＥＣＵ１ｂは、ＣＡＮトランシーバ／レシーバ２が、ＣＡＮモードであるか否かを判断し（ステップＳ５０１）、ＣＡＮモードの場合には、マスタのＥＣＵ１から、ＣＡＮ通信停止フレームが送信されたか否かを判断する（ステップＳ５０２）。

ＥＣＵ１から、ＣＡＮ通信停止フレームが送信されていない場合には、通常のＣＡＮプロトコルの通信に応じた実行処理を行う（ステップＳ５０３）。ＥＣＵ１から、ＣＡＮ通信停止フレームが送信された際には、その指示に基づいて、ＥＣＵ１ａのＣＡＮトランシーバ／レシーバ２がＭＣＵ５の電源をＯＦＦし、ＣＡＮプロトコルによる通信を停止する（ステップＳ５０４）。

そして、ＥＣＵ１によって指示された任意の期間の間、ステップＳ５０４の状態を維持した後（ステップＳ５０５）、ＣＡＮトランシーバ／レシーバ２がＭＣＵ５の電源をＯＮしてＣＡＮプロトコルによる通信に復帰する（ステップＳ５０６）。

ここで、ステップＳ５０４の処理では、ＥＣＵ１から指示で、ＥＣＵ１ａのＭＣＵ５の電源をＯＦＦしてＣＡＮプロトコルによる通信を停止するものとしたが、該ＥＣＵ１の指示は、これ以外に、ＥＣＵ１ａのＭＣＵ５の電源をＯＦＦせずにＣＡＮプロトコルによる通信のみを停止する処理などであってもよい。

図１２は、マスタとなるＥＣＵ１がＣＡＮモードでないＥＣＵ１ｂを起動させ、ＣＡＮ通信を開始させる際の該ＥＣＵ１ｂにおける動作の一例を示すフローチャートである。

まず、ＥＣＵ１ｂは、ＣＡＮトランシーバ／レシーバ２が、ＣＡＮモードであるか、あるいはＵＡＲＴモードであるかを判定し（ステップＳ６０１）、ＣＡＮモードの場合には、通常のＣＡＮプロトコルの通信時応じた実行処理を行う（ステップＳ６０２）。

ステップＳ６０１の処理において、ＵＡＲＴモードの場合には、ＥＣＵを起動させるＵＡＲＴフォーマットによるメッセージを受信したか否かを判断する（ステップＳ６０３）。

ステップＳ６０３の処理において、メッセージを受信すると、ＥＣＵ１ｂは、受信したメッセージが自ＥＣＵ（１ｂ）宛のメッセージであるか否かを判断し（ステップＳ６０４）、自ＥＣＵ宛のメッセージの場合には、そのメッセージに基づいて、ＥＣＵ１ｂのＣＡＮトランシーバ／レシーバ２がＭＣＵ５の電源をＯＮさせ、ＥＣＵ１ｂをＣＡＮ通信に参加させる（ステップＳ６０５）。

以上、説明した電源が供給されていない（ＣＡＮプロトコルによる通信が行われていない）ＥＣＵを起動させ、通信を開始させる技術は、緊急時の損害低減や二次災害の防止などに有効である。またそのような場合の図１０〜図１２のＵＡＲＴフォーマットによるメッセージの通信は、ＣＡＮフォーマットによる通信を阻害しないように、異なる周波数帯を用いた信号重畳による通信を行うとよい。ブレーキやエアバッグ等の自動車の安全運行に必要とされるＣＡＮ通信を行いつつ、不要なＥＣＵの通信を停止させ、更に通信に参加することが必要となるＥＣＵを起動させることが可能となる。

自動車の周囲監視を行うレーダーＥＣＵが他車の異常接近を検知した場合に、衝突事故の発生に備えてエアバッグやシートベルトを制御するＥＣＵを起動することにより、衝突発生前にシートベルトを固定し、衝突発生の直前／直後にエアバックの膨張を行い、乗員の肉体的な損傷を低減することができる。若しくは自車の歩行者等への接近を検知してブレーキ制御ＥＣＵを起動して減速制御を行い、歩行者などへ与える被害を低減することができる。

たとえば、燃料電池車の場合には、衝突時に水素ガスなどのガス漏れを検出する(マスタＥＣＵとガスセンサＥＣＵとが通信)と、マスタＥＣＵは、サンルーフ、ウィンドウ、スライドドア、エアコンなどを制御する各ＥＣＵを起動することによって、車内換気を行い、車内に水素ガスが充満して火災や爆発を生じないようにすることができる。

また、ハイブリッド車や電気自動車などの場合には、衝突時などに電源制御を行うＥＣＵがＣＡＮ通信に参加していなければ、電源制御系のＥＣＵを起動させ、バッテリ、ならびに該バッテリ周辺機器をファン（およびラジエータ）などで緊急冷却し、バッテリ発火による火災を防止することができる。

さらに、衝突時などに該当するＥＣＵを起動させ、ルームランプの点灯、ハザードランプの点滅、クラクションを鳴らす、テレマティックスによる通報などによる事故発生の周知の他、ドアが施錠されている際には、避難のためにドアロックを解除するとなどを行うことができる。

（実施の形態３）
図１３は、本発明の実施の形態３によるＥＣＵがプラグインされた際のマスタＥＣＵとスレーブＥＣＵとの通信の一例を示す動作フローチャート、図１４は、図１３の動作時におけるマスタＥＣＵの動作の一例を示すフローチャート、図１５は、図１３の動作時における既存のスレーブＥＣＵの動作の一例を示すフローチャート、図１６は、図１３の動作時におけるプラグインされたスレーブＥＣＵの動作の一例を示すフローチャートである。

本実施の形態３では、前記実施の形態１の図１に示す自動車の車内ネットワークにおいて、新たにＥＣＵがプラグインされた場合に、プラグインされたＥＣＵの動作認識情報となるＥＣＵ情報をマスタのＥＣＵに通知する技術について説明する。

ここで「プラグイン」とは、たとえば、カーナビゲーションシステムを追加または交換する等、ＣＡＮが以前に稼動していた時点においては存在していなかったＥＣＵがＣＡＮに新たに接続されることを意味する。

図１３は、新たにＥＣＵがプラグインされた際のマスタＥＣＵとなるＥＣＵ１とスレーブＥＣＵとなるＥＣＵ１ａ，１ｂとの通信の一例を示す動作フローチャートである。ここで、図１３においては、ＥＣＵ１ｂ（図１）が新たにプラグインされたＥＣＵであるものとする。

マスタとなるＥＣＵ１は、ＭＣＵ５、およびＣＡＮトランシーバ／レシーバ２に電源が供給されている状態であり、スレーブのＥＣＵ１ａは、ＣＡＮトランシーバ／レシーバ２がＵＡＲＴモードでスタンバイ状態となっており、ＭＣＵ５の電源がＯＦＦされている。また、プラグインされたＥＣＵ１ｂは、ＣＡＮトランシーバ／レシーバ２がＵＡＲＴモードでスタンバイ状態となっており、ＭＣＵ５の電源がＯＦＦされている。

また、図１３では、スレーブのＥＣＵ１ａ，１ｂは、いずれも間欠動作を行うＥＣＵであるものとする。さらに、図の左側には、ＥＣＵ１に設けられたレジスタ１７（図２）の状態を示しており、レジスタ１７の左から右にかけては、ＥＣＵ１、ＥＣＵ１ａ、およびＥＣＵ１ｂにおけるそれぞれの状態データが格納されている。レジスタ１７の’１’はＣＡＮモードを示しており、’０’は、ＵＡＲＴモードを示している。

まず、ＥＣＵ１は、すべてのＥＣＵに対して、ＵＡＲＴフレームにより、すべてのＥＣＵを起動させる全ＥＣＵ起動信号をＣＡＮバスＢｃを介して送信する（ステップＳ７０１）。

この全ＥＣＵ起動信号は、たとえば２つのメッセージからなり、第１のメッセージは、図４のＣＡＮＩＤメッセージ２０において全てのＥＣＵを起動させることを示すメッセージであり、第２のメッセージは、起動情報を取得するためのメッセージであることを意味する信号である。

ＥＣＵ１ａ，１ｂにおいては、全ＥＣＵ起動信号を受信することにより、ＣＡＮトランシーバ／レシーバ２がＣＡＮモードにより起動し、ＭＣＵ５の電源がそれぞれＯＮとなる（ステップＳ７０２）。

続いて、ＥＣＵ１は、新規にプラグインされたＥＣＵがあるかを問い合わせ（ステップＳ７０３）、プラグインされたＥＣＵ１ｂは、ＥＣＵ１の要求に基づいて自ＥＣＵ１ｂのＥＣＵ情報（ＣＡＮＩＤや動作情報など）をＣＡＮフレームによりＥＣＵ１に送信する（ステップＳ７０４）。

その後、ＥＣＵ１は、残りのＥＣＵ１ａに対しても、ＥＣＵ情報を要求し（ステップＳ７０５）、該ＥＣＵ情報を取得する（ステップＳ７０６）。そして、任意の時間が経過すると、ＥＣＵ１ａ，１ｂのＣＡＮトランシーバ／レシーバ２がＵＡＲＴモードでスタンバイ状態となり、ＥＣＵ１ａ，１ｂのＭＣＵ５の電源がＯＦＦとなる（ステップＳ７０７）。

ＥＣＵ１は、ステップＳ７０４，Ｓ７０６の処理でそれぞれ取得したＥＣＵ情報に基づいて、任意の期間ごとに、ＥＣＵ１ａの起動（ステップＳ７０８）、ならびにＥＣＵ１ｂの起動（ステップＳ７０９）を繰り返す。

図１４は、図１３の動作時におけるマスタとなるＥＣＵ１の動作の一例を示すフローチャートである。

まず、ＥＣＵ１は、ＵＡＲＴフレームによって全ＥＣＵ起動信号をＣＡＮバスＢｃを介してすべてのＥＣＵ（ＥＣＵ１ａ，１ｂ）に送信し（ステップＳ８０１）、ＣＡＮモードを起動させる。続いて、ＥＣＵ１は、プラグインしたＥＣＵ１ｂ、およびその他の既存のＥＣＵ１ａに対して、ＣＡＮフレームにより、ＥＣＵ情報をそれぞれ要求する（ステップＳ８０２）。

ＥＣＵ１は、すべてのＥＣＵからのＥＣＵ情報を取得すると、取得したＥＣＵ情報をバッファなどに格納する（ステップＳ８０３）。ＥＣＵ１は、ＥＣＵ１ａの間欠時間が経過したか否かの判断を行い（ステップＳ８０４）、その間欠時間が経過したら、ＵＡＲＴフレームによりＥＣＵ１ａを起動させて該ＥＣＵ１ａとのＣＡＮ通信を開始する（ステップＳ８０５）。

ステップＳ８０４の処理において、ＥＣＵ１ａの間欠時間が経過していない場合、ＥＣＵ１は、ＥＣＵ１ｂの間欠時間が経過したか否かの判断を行い（ステップＳ８０６）、該間欠時間が経過するとＵＡＲＴフレームによりＥＣＵ１ｂを起動させ、該ＥＣＵ１ｂとのＣＡＮ通信を開始する（ステップＳ８０７）。

図１５は、図１３の動作時におけるスレーブとなる既存のＥＣＵ１ａの動作の一例を示すフローチャートである。

まず、ＥＣＵ１ａは、ＣＡＮトランシーバ／レシーバ２がＵＡＲＴモードか否かを判断し（ステップＳ９０１）、ＣＡＮモードの場合には、通常のＣＡＮプロトコルの通信に応じた実行処理を行う（ステップＳ９０２）。

また、ステップＳ９０１の処理において、ＵＡＲＴモードの場合には、マスタとなるＥＣＵ１から受信したＵＡＲＴフレームが自ＥＣＵ１ａ宛か否か、あるいは全ＥＣＵ起動信号か否かを判断する（ステップＳ９０３）。

ＵＡＲＴフレームが自ＥＣＵ１ａ宛、あるいは全ＥＣＵ起動信号の場合には、ＣＡＮトランシーバ／レシーバ２がＣＡＮモードに移行し、ＭＣＵ５の電源をＯＮとする（ステップＳ９０４）。また、ＵＡＲＴフレームが自ＥＣＵ１ａ宛、あるいは全ＥＣＵ起動信号のいずれでもない場合には、ステップＳ９０１の処理に戻る。

続いて、ＥＣＵ１ａは、ＥＣＵ１から、自ＥＣＵ１ａのＥＣＵ情報の取得要求があるかを判断する（ステップＳ９０５）。ＥＣＵ１ａのＥＣＵ情報の取得要求がない場合には、ステップＳ９０２の処理を実行する。

また、ＥＣＵ情報の取得要求がある場合、ＥＣＵ１ａは、ＣＡＮバスＢｃがアイドル状態であるかを任意の期間確認し（ステップＳ９０６）、アイドル状態であれば、ＥＣＵ１へＥＣＵ１ａのＥＣＵ情報をＣＡＮフレームによって送信する（ステップＳ９０７）。

そして、ＥＣＵ１ａは、ＣＡＮトランシーバ／レシーバ２をＵＡＲＴモードに移行させ、ＥＣＵ１からの起動メッセージを待つ（ステップＳ９０８）。ＥＣＵ１からの起動メッセージを受信すると（ステップＳ９０９）、自ＥＣＵ１ａ宛のメッセージであるか否かを判断し（ステップＳ９１０）、ＥＣＵ１ａ宛のメッセージの場合、該ＥＣＵ１ａは、ＭＣＵ５の電源をＯＮし、ＣＡＮモードに移行し（ステップＳ９１１）、ステップＳ９０２の処理を実行する。

図１６は、図１３の動作時におけるスレーブとなるプラグインされたＥＣＵ１ｂの動作の一例を示すフローチャートである。

まず、ＥＣＵ１ｂは、ＣＡＮトランシーバ／レシーバ２がＵＡＲＴモードか否かを判断し（ステップＳ１００１）、ＣＡＮモードの場合には、通常のＣＡＮプロトコルの通信に応じた実行処理を行う（ステップＳ１００２）。ＵＡＲＴモードの場合には、マスタのＥＣＵ１から受信したＵＡＲＴフレームが自ＥＣＵ１ｂ宛か、全ＥＣＵ起動信号か、またはプラグインしたＥＣＵへの取得要求であるかを判断する（ステップＳ１００３）。

ＵＡＲＴフレームがＥＣＵ１ｂ宛、全ＥＣＵ起動信号、あるいはプラグインしたＥＣＵへの取得要求の場合には、ＣＡＮトランシーバ／レシーバ２がＣＡＮモードに移行し、ＭＣＵ５の電源をＯＮする（ステップＳ１００４）。

続いて、ＥＣＵ１ｂは、ＥＣＵ１から、ＥＣＵ１ｂのＥＣＵ情報の取得要求があるかを判断する（ステップＳ１００５）。ＥＣＵ１ｂのＥＣＵ情報の取得要求がない場合には、ステップＳ１００２の処理を実行する。

ステップＳ１００５の処理において、ＥＣＵ情報の取得要求がある場合、ＥＣＵ１ｂは、その取得要求が、プラグインしたＥＣＵへのＥＣＵ情報の取得要求であるかを確認し（ステップＳ１００６）、プラグインしたＥＣＵへのＥＣＵ情報の取得要求の場合には、ＥＣＵ１ｂは、自ＥＣＵ１ｂはプラグインしたＥＣＵか否かを判断する（ステップＳ１００７）。

また、ステップＳ１００６の処理において、プラグインしたＥＣＵへのＥＣＵ情報の取得要求でない場合には、ＥＣＵ１ｂは、後述するステップＳ１００８の処理を実行し、ステップＳ１００７の処理において、プラグインしたＥＣＵでないと判断した場合には、ステップＳ１００２の処理を実行する。

ＥＣＵ１ｂがプラグインしたＥＣＵであると判断すると、該ＥＣＵ１ｂは、ＣＡＮバスＢｃがアイドル状態であるかを任意の期間確認し（ステップＳ１００８）、アイドル状態であれば、ＥＣＵ１へＥＣＵ１ｂのＥＣＵ情報をＣＡＮフレームによって送信する（ステップＳ１００９）。

続いて、ＥＣＵ１ｂは、ＣＡＮトランシーバ／レシーバ２をＵＡＲＴモードに移行させ、ＥＣＵ１からの起動メッセージを待つ（ステップＳ１０１０）。ＥＣＵ１ｂが、ＥＣＵ１からの起動メッセージを受信すると（ステップＳ１０１１）、自ＥＣＵ１ｂ宛のメッセージであるか否かを判断し（ステップＳ１０１２）、ＥＣＵ１ｂ宛のメッセージの場合、該ＥＣＵ１ｂは、ＭＣＵ５の電源をＯＮし、ＣＡＮモードに移行し（ステップＳ１０１３）、ステップＳ１００２の処理を実行する。

ＣＡＮネットワークに接続される既存のＥＣＵ(ＥＣＵ１ａ)と追加されたＥＣＵ(ＥＣＵ１ｂ)とは、図１５及び図１６のフローにおいて図示しない以下の処理を行ってよい。

ＥＣＵ１およびＥＣＵ１ａが自ＥＣＵのＥＣＵ情報を送信(図１３のステップＳ７０６)することに応じて、ＥＣＵ１ｂはＥＣＵ１とＥＣＵ１ａのＥＣＵ情報をＥＣＵ１ｂ内の不揮発性メモリに格納する。

また、ＥＣＵ１ｂがＥＣＵ１ｂのＥＣＵ情報をＥＣＵ１に送信(図１３のステップＳ７０４)することに応じて、ＥＣＵ１ａはＥＣＵ１ｂのＥＣＵ情報をＥＣＵ１ａ内の不揮発性メモリに格納する。

ＥＣＵ１に代わってＥＣＵ１ａまたはＥＣＵ１ｂがマスタＥＣＵとなった場合に、ＥＣＵ１ａまたはＥＣＵ１ｂのＥＣＵ情報を取得するために図１４の処理を行うことは冗長であり、プラグインされたＥＣＵ１ｂが存在する場合、既存のＥＣＵ全てがプラグインされたＥＣＵ１ｂの情報取得処理で共有すると共に、プラグインされたＥＣＵが既存のＥＣＵ全ての情報を同様に情報取得処理で共有する。

かかる処理により、ＣＡＮネットワークに接続される全てのＥＣＵが他のＥＣＵのＥＣＵ情報を保持することになり、いずれのＥＣＵがマスタＥＣＵになった場合でも、他のＥＣＵの動作情報取得処理を行うことなく、他のＥＣＵの間欠動作制御等を行うことが可能になる。

上述した技術は、自動車のオプションなどによって新たに追加された機能を後付けした際に、新たにプラグインされるＥＣＵに対して有効である。

たとえば、自動車のリアウィンドウなどに設けられているリアワイパを後付けにより取り付けた場合には、ボディ系のマスタのＥＣＵは、電源ＯＮ時、ＣＡＮバスを介して全ＥＣＵ起動信号を送信し、すべてのＥＣＵを起動させる。

プラグインされたＥＣＵは、マスタのＥＣＵからの要求に応じて、プラグインされたＥＣＵのＥＣＵ情報をマスタのＥＣＵに送信する。この場合、プラグインされたＥＣＵは、間欠動作するリアワイパを動作させるＥＣＵであるので、ＥＣＵ情報として、たとえば、ＣＡＮＩＤとリアワイパの間欠動作情報などを送信する。

そして、マスタのＥＣＵは、リアワイパの動作がＯＮした情報を検出すると、その情報に応じて、リアワイパを制御するプラグインされたＥＣＵを起動させる。

ここでは、一例としてリアワイパを制御するＥＣＵについて記載したが、この他に、ナビゲーションシステムやオーディオなどの様々なＥＣＵが追加された場合についても、同様の処理を行うことになる。

また、プラグインされたＥＣＵは、最適化されていた車内ネットワークシステムに新たに追加されることになるので、該システムに問題が発生した場合、既存のＥＣＵよりも故障の原因となる確率が高くなる可能性がある。

そのため、問題が発生すると、最初に、プラグインされたＥＣＵを検証する必要性が認識できる。この場合、既存のＥＣＵには、ＣＡＮトランシーバ／レシーバ２に、予め設定されているＣＡＮＩＤ（たとえば、ＩＤ１〜ＩＤ１６）を割り振っておき、プラグインされたＥＣＵには、それ以外のＣＡＮＩＤを割り振り、予め設定されているＣＡＮＩＤ以外のＣＡＮＩＤがＣＡＮバスを介して配信された際に、プラグインされたＥＣＵと認識することができる。

（実施の形態４）
図１７は、本発明の実施の形態４によるマスタＥＣＵが、スレーブＥＣＵがＣＡＮ通信に参加しているかを確認する動作の一例を示すフローチャートである。

本実施の形態４では、前記実施の形態１の図１に示す自動車の車内ネットワークにおいて、あるスレーブのＥＣＵが外部トリガによって起動した際に、マスタのＥＣＵに対してスレーブの該ＥＣＵが起動したことを通知する技術について説明する。

図１７は、マスタとなるＥＣＵ１が、スレーブのＥＣＵ１ａ，１ｂがＣＡＮ通信に参加しているかを確認する動作の一例を示すフローチャートである。

図１７では、ＥＣＵ１ｂが外部トリガによって起動可能なＥＣＵであるものとし、図１７の左側には、ＥＣＵ１に設けられたレジスタ１７（図２）の状態を示している。レジスタ１７の左から右にかけては、ＥＣＵ１、ＥＣＵ１ａ、およびＥＣＵ１ｂにおけるそれぞれの状態データが格納されており、レジスタ１７の’１’はＣＡＮモードを示しており、’０’は、ＵＡＲＴモードを示している。

まず、ＥＣＵ１は、ＣＡＮプロトコルの通信により、各ＥＣＵ１ａ，１ｂが起動しているか否かを問い合わせる（ステップＳ１１０１）。ここでは、ＥＣＵ１ａが起動しているので、該ＥＣＵ１ａは、起動していることをＥＣＵ１に通知する（ステップＳ１１０２）。これにより、レジスタ１７のＥＣＵ１ａの状態を示すデータは’１’となる。

その後、ＥＣＵ１ｂが外部トリガにより起動すると（ステップＳ１１０３）、ＥＣＵ１ｂのＭＣＵ５がＣＡＮトランシーバ／レシーバ２を起動させる（ステップＳ１１０４）。そして、ＥＣＵ１は、再びＣＡＮプロトコルの通信により、各ＥＣＵ１ａ，１ｂが起動しているか否かを問い合わせる（ステップＳ１１０５）。

これを受けて、ＥＣＵ１ａは、起動していることをＥＣＵ１に通知する（ステップＳ１１０６）。ＥＣＵ１ｂも起動したので、同様に起動していることをＥＣＵ１に通知する（ステップＳ１１０７）。これにより、レジスタ１７のＥＣＵ１ａの状態を示すデータ、およびＥＣＵ１ｂの状態を示すデータは、それぞれ’１’となる。

外部トリガで起動可能なＥＣＵは、外部トリガを検出する必要があるので、ＭＣＵ５の電源はＯＦＦせず、スタンバイ状態とし、ＣＡＮトランシーバ／レシーバ２は、ＵＡＲＴモードでマスタのＥＣＵから、外部トリガで起動可能なＥＣＵを起動させるメッセージを待つ。

マスタのＥＣＵは、任意の時間毎に各スレーブのＥＣＵが起動しているかを問い合わせ、外部トリガで起動したＥＣＵは、その問い合わせは、自ＥＣＵ宛か、全ＥＣＵ起動信号か、あるいは新規に起動したＥＣＵへのいずれかの場合に、問い合わせに応じる。

その後、スレーブのＥＣＵは、マスタのＥＣＵの指示に従い、ＣＡＮモードで待機するか、もしくはＵＡＲＴモードに移行するかを指示するようにしてもよい。

また、マスタのＥＣＵは、問い合わせと共に、外部トリガにより起動したＥＣＵが、そのままＣＡＮモードで待機するか、またはＵＡＲＴモードに移行するかを指示するようにしてもよい。

さらに、外部トリガによって起動したＥＣＵ自身が、マスタのＥＣＵに対して起動したことを通知することも可能である。

外部トリガによってＭＣＵ５が起動すると、該ＭＣＵ５は、ＣＡＮトランシーバ／レシーバ２を起動させる。続いて、ＭＣＵ５は、任意の期間（たとえば、１ｍｓ程度）、Ｌｏ信号をＣＡＮバスを介して送信するように制御を行い、マスタのＥＣＵにＥＣＵが起動したことを通知する。

このＬｏ信号による通知は、別のＥＣＵが出力するＣＡＮフレームとＥＣＵからＬｏ信号が衝突したときに、再送を繰り返さないように、ワンショット送信とする。若しくは、別のＥＣＵの出力するＣＡＮフレームとの衝突を防止するために、異なる周波数帯を用いて通信するようにしてもよい。

そして、マスタのＥＣＵがいずれかのスレーブのＥＣＵが起動したことを検出すると、マスタのＥＣＵは、ＣＡＮプロトコルによる通信により、スレーブの該ＥＣＵへの問い合わせを行い、起動しているＥＣＵのＥＣＵ情報を得る。

外部トリガによって起動するＥＣＵとしては、たとえば、メモリシートなどを制御するＥＣＵなどがあり、メモリシートのスイッチによって該ＥＣＵが起動すると、マスタのＥＣＵに起動を通知することになる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

たとえば、前記実施の形態では、ＥＣＵが２つのレギュレータ３，４を備え、イネーブル信号ＥＮによって、ＭＣＵ５とアクチュエータＡｃに電源を供給するレギュレータ４をＯＮ／ＯＦＦ制御する構成としたが、レギュレータを１つとし、ＭＣＵ５とアクチュエータＡｃには、スイッチを介して電源電圧を供給する構成としてもよい。

この場合、イネーブル信号ＥＮは、スイッチをＯＮ／ＯＦＦ制御する信号とし、スイッチがＯＮの場合には、ＭＣＵ５とアクチュエータＡｃとに電源が供給され、スイッチがＯＦＦすると、ＭＣＵ５とアクチュエータＡｃとに電源供給が停止されることになる。

また、前記実施の形態では、通信ネットワークとしてＣＡＮを用い、レギュレータの電源のＯＮ／ＯＦＦ制御をＵＡＲＴプロトコルによって制御する場合について記載したが、通信ネットワークに、たとえば、ＦｌｅｘＲａｙなどの他の通信ネットワークを用い、レギュレータの電源のＯＮ／ＯＦＦをＬＩＮなどの他のプロトコルによって制御する構成であってもよい。

本発明は、自動車などの通信システムに用いられる半導体集積回路装置における低消費電力化技術に適している。

１ＥＣＵ
１ａＥＣＵ
１ｂＥＣＵ
２ＣＡＮトランシーバ／レシーバ
３レギュレータ
４レギュレータ
５ＭＣＵ
６ＣＡＮインタフェース
７通信制御部
８ＲＡＭ
９タイマ
１０割り込みコントローラ
１１ＣＰＵ
１２ＲＯＭ
１３トランシーバ／レシーバ
１４セレクト回路
１５ＵＡＲＴ用回路
１６ＩＤ判断回路
１７レジスタ
１８オンチップオシレータ
１９ウェイトメッセージ
１９ａＳＯＦ
１９ｂデータビット
１９ｃパリティビット
１９ｄストップビット
２０ＣＡＮＩＤメッセージ
２０ａＳＯＦ
２０ｂデータビット
２０ｃパリティビット
２０ｄストップビット
２１ＣＡＮフレーム
２２抵抗
２３Ａ／Ｄ変換器
Ｒ１抵抗
ＢｃＣＡＮバス
Ａｃアクチュエータ
Ｂｓ内部バス

Claims

アクティブモードと低消費電力モードとを有する半導体装置であって、
通信バスから信号を受信するインタフェース部と、
前記アクティブモード時には電源が供給されて所定の制御動作を行い、前記低消費電力モード時には電源供給が停止されるコントローラと、を有し、
前記半導体装置は、予め決められたＩＤ情報を有し、
前記コントローラが前記低消費電力モード時に、前記インタフェース部が前記通信バスから所定時間、同レベルが継続する信号を検出した場合は、その後に受信した信号の中に前記ＩＤ情報を含むかどうかを確認し、含まれていた場合は前記コントローラを前記アクティブモードへ遷移させ、
前記インタフェース部は、第１のプロトコルと第２のプロトコルによる信号を受信可能であり、前記コントローラが前記低消費電力モード時は、前記同レベルで継続する信号と前記ＩＤ情報を含む信号とを前記第１のプロトコルで受信し、前記第２のプロトコルの信号は無視する、半導体装置。
請求項１記載の半導体装置において、
前記インタフェース部は、前記通信バスの信号を差動信号で受信するレシーバと、受信した信号が前記第１と第２のプロトコルのいずれかであるかを判定する判定部と、前記第１のプロトコルを処理する回路と、を有する半導体装置。
請求項１または２記載の半導体装置において、
前記第２のプロトコルは、前記アクティブモード時の前記コントローラによって処理される、半導体装置。
請求項１〜３のいずれか１項に記載の半導体装置において、
前記第２のプロトコルはＣＡＮ（ＣｏｎｔｒｏｌｌｅｒＡｒｅａＮｅｔｗｏｒｋ）であり、前記ＩＤ情報はＣＡＮＩＤである、半導体装置。
請求項１〜４のいずれか１項に記載の半導体装置において、
前記コントローラは、前記アクティブモード時に前記通信バスから通信停止メッセージを受信した場合は、前記低消費電力モードに遷移する、半導体装置。