JP5849142B2 - 電子制御装置の制御方法 - Google Patents

電子制御装置の制御方法 Download PDF

Info

Publication number
JP5849142B2
JP5849142B2 JP2014213631A JP2014213631A JP5849142B2 JP 5849142 B2 JP5849142 B2 JP 5849142B2 JP 2014213631 A JP2014213631 A JP 2014213631A JP 2014213631 A JP2014213631 A JP 2014213631A JP 5849142 B2 JP5849142 B2 JP 5849142B2
Authority
JP
Japan
Prior art keywords
ecu
communication
message
electronic control
control device
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Active
Application number
JP2014213631A
Other languages
English (en)
Other versions
JP2015039224A (ja
Inventor
真弘 浅野
真弘 浅野
百合子 西原
百合子 西原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Renesas Electronics Corp
Original Assignee
Renesas Electronics Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Renesas Electronics Corp filed Critical Renesas Electronics Corp
Priority to JP2014213631A priority Critical patent/JP5849142B2/ja
Publication of JP2015039224A publication Critical patent/JP2015039224A/ja
Application granted granted Critical
Publication of JP5849142B2 publication Critical patent/JP5849142B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Landscapes

  • Small-Scale Networks (AREA)
  • Communication Control (AREA)

Description

本発明は、通信ネットワークにおける電源管理技術に関し、特に、CAN(Controller Area Network)バスを介して通信する通信ネットワークシステムに用いられる半導体集積回路装置の低消費電力化に有効な技術に関する。
自動車には、ナビゲーションシステムやオーディオなどの情報系、エンジンやシャーシなどのパワートレイン系、あるいはエアコンやヘッドライト、ドアロックなどのボディ系などの各種制御を司るECU(Electric Control Unit)が多数搭載されている。
これらECUを接続する通信ネットワークのプロトコルとして、たとえば、CANが広く用いられている。自動車に搭載されるECUは、たとえば、エンジン、ブレーキ、エアバッグなどの常に制御が実行されるECUと、たとえば、サンルーフの開閉などイベントが発生したときのみに動作が必要なECUとに分けられるが、CANでは、自動車がエンジンを始動すると、それ以降、すべてのECUがON状態となる仕様となっている。
また、この種の通信ネットワークにおけるデータ伝搬技術としては、たとえば、データを記憶、あるいは診断を実施するためにCANプロトコルを使用することなくCANバスを使用するもの(特許文献1参照)や、有線LANの通信プロトコルにかかわらず、UART(Universal Asynchronous Receiver Transmitter)によるデータ通信を可能とするもの(特許文献2参照)などが知られている。
特表2004−535742号公報 特開2006−20038号公報
ところが、上記のような通信ネットワークプロトコルによる通信技術では、次のような問題点があることが本発明者により見い出された。
自動車に搭載されるECUは、たとえば、エンジン、ブレーキ、エアバッグなどの常に制御が実行される(メッセージ送受信を行うべきイベントの発生頻度が相対的に多い)ECUと、たとえば、サンルーフの開閉などイベントが発生したときのみに動作が必要な(メッセージ送受信を行うべきイベントの発生頻度が相対的に少ない)ECUとに分けられる。
イベントが発生した際にのみ動作が必要なECUの場合には、該イベントが発生した場合のみECUの電源を入れれば、消費電力を抑えることができる。しかしながら、前述したように、エンジンが始動した以降は、すべてのECUがON状態となってしまい、常に多くのECUが電力を消費してしまうことになる。
自動車で使用される電気は、エンジンの力でまわっているオルタネータ(交流発電器)で作られているため、消費電力が少なければ、オルタネータへの負荷が減り、ガソリンの消費も減ることになるが、消費電力が大きくなることにより、自動車の発電負荷が大きくなり、自動車の燃費が低下してしまうという問題がある。
自動車に搭載されるECUの個数は年々増加しており、これらのECUが消費する電力も増加する一方であり、自動車の燃費がより大きく低下してしまう恐れが生じてしまうことになる。
また一方で、エンジン、ブレーキ等の自動車を安全に運行するのに必要とされるECUは通信ネットワークを介して相対的に頻繁に通信を行っており、かかる通信を阻害することは自動車の安全な運行に支障をきたすことにもなる。かかる観点からも、不急のECUからの通信を抑制する一方で、そのようなECUへの通信を行う場合に自動車の安全な運行に支障を来たさないような通信を行う必要がある。
本発明の目的は、通信ネットワークに接続される各ECUの電源供給を最適に制御することにより、自動車の消費電力を大幅に低減することのできる技術を提供することにある。
本発明の前記ならびにそのほかの目的と新規な特徴については、本明細書の記述および添付図面から明らかになるであろう。
本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。
本発明は、通信バスを介して入力される第1の通信プロトコルのインタフェースとなる通信プロトコルインタフェースと、該通信プロトコルインタフェースを介して入力されたメッセージに基づいて、アクチュエータ等を制御するコントローラと、該通信プロトコルインタフェースに電源を供給する第1のレギュレータと、通信プロトコルインタフェースから出力される制御信号に基づいて、コントローラ、およびコントローラにより制御されるアクチュエータ等へ電源を供給/停止する第2のレギュレータとを備え、通信プロトコルインタフェースは、通信バスから転送され、第1の通信プロトコルと異なるプロトコルの第2の通信プロトコルのメッセージに基づいて、制御信号を生成するものである。
また、本願のその他の発明の概要を簡単に示す。
本発明は、前記通信プロトコルインタフェースが、通信バスを介して転送されるメッセージが、第1の通信プロトコルのメッセージであるか、第2の通信プロトコルのメッセージであるかを判定し、第1の通信プロトコルのメッセージの場合、該メッセージをコントローラに送信するプロトコル判定部と、プロトコル判定部が第2の通信プロトコルのメッセージであると判定した際に、そのメッセージが入力され、該メッセージ中の認識番号を検出し、検出した認識番号と、半導体集積回路装置に個別に割り付けられた認識番号とが一致しているか否かを判断し、一致している際には、第2のレギュレータを動作させる制御信号を出力するID判断部とを備えたものである。
また、本発明は、前記コントローラに電源電圧が供給されると、該コントローラのアイドル時間を計測するタイマを備え、該コントローラは、コントローラのアイドル時間が任意の時間経過すると、ID判断部に電源遮断指示信号を出力し、該ID判断部は、電源遮断指示信号を受信すると、第2のレギュレータの動作を停止する制御信号を出力するものである。
さらに、本発明は、前記通信プロトコルインタフェースが、ID判断部が前記第2のレギュレータを動作させたか、または停止させたかを示す動作情報を格納する電源動作情報格納部を備え、ID判断部は、第2のレギュレータを動作させた際、または第2のレギュレータを停止させた際に、電源動作情報格納部に動作を格納するものである。
また、本発明は、前記コントローラが、前記第1の通信プロトコルにより、前記第1の通信プロトコルにより通信を行っているすべての半導体集積回路装置に前記第1の通信プロトコルによる通信を停止させる通信停止メッセージを前記通信バスを介して出力し、前記半導体集積回路装置の通信を停止させた後、前記第1の通信プロトコルによる通信に参加させたい任意の半導体集積回路装置に対して、前記通信バスを介して前記第2の通信プロトコルのメッセージを転送して、任意の前記半導体集積回路装置の第2のレギュレータを動作させるものである。
さらに、本発明は、前記第1の通信プロトコルによる通信を停止した前記半導体集積回路装置が、前記通信停止メッセージに設定された任意の時間が経過した後、前記第1の通信プロトコルによる通信を再開するものである。
また、本発明は、前記第1の通信プロトコルによる通信を停止した前記半導体集積回路装置が、前記通信プロトコルインタフェースが、前記第2の通信プロトコルによる前記第2のレギュレータを動作させるメッセージが転送されるまで前記第2のレギュレータの動作を停止しているものである。
さらに、本発明は、前記コントローラが、前記第2の通信プロトコルにより、前記第1のレギュレータを動作させ、前記半導体集積回路装置を起動させ、前記第1の通信プロトコルによる通信を開始させるシステム起動メッセージを前記通信バスを介して出力し、起動した前記半導体集積回路装置から、プラグインされた半導体集積回路装置があるか否かを確認し、プラグインされた前記半導体集積回路装置が存在する場合、プラグインされた前記半導体集積回路装置に、少なくとも前記認識番号を含む動作認識情報を前記第1の通信プロトコルにより取得するものである。
また、本発明は、外部トリガにより前記半導体集積回路装置が動作する場合、前記第2のレギュレータは、前記コントローラ、および前記アクチュエータへ電源供給を停止せず、前記コントローラはスタンバイ状態となり、前記通信プロトコルインタフェースは、第2の通信プロトコルによるメッセージを受け付ける状態よりなるものである。
さらに、本発明は、前記コントローラが、外部トリガを検出してスタンバイ状態から動作状態に遷移すると、外部トリガにより前記半導体集積回路装置が起動したことを通知する起動通知信号を前記通信バスに転送するものである。
また、本発明は、前記コントローラが、外部トリガを検出してスタンバイ状態から動作状態に遷移すると、前記通信プロトコルインタフェースを前記第1の通信プロトコルによる通信が開始されるように設定し、外部トリガにより前記半導体集積回路装置が起動したかの問い合わせが発生した際に、起動したことを通知するものである。
さらに、本発明は、前記第1の通信プロトコルが自動車用通信プロトコルであり、CAN、またはFlexRayといった自動車内ネットワークとして主要に用いられている通信プロトコルである。
また、本発明は、前記第2の通信プロトコルが、UARTといった主に半導体集積回路間での通信に用いられる通信プロトコル、またはLIN(Local Interconnect Network)といった自動車内ネットワークとして従属的に用いられる通信プロトコルよりなるものである。または通信メッセージの構成はCANまたはFlexRayと同じであるが、通信の周波数が異なる通信プロトコルよりなるものである。
本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。
(1)コントローラ、およびアクチュエータの動作が不要な場合に、電源供給を停止することができるので、半導体集積回路装置の消費電力を大幅に低減することができる。
(2)また、所定の場合にはECU間の通信を停止させ、またはECU内の半導体集積回路の動作を停止させることで、消費電力および燃費の向上に留まらず、自動車の安全性能の向上を図ることができる。
本発明の実施の形態1による車内ネットワークの接続形態の一例を示すブロック図である。 図1のECUに設けられたCANトランシーバ/レシーバにおける構成の一例を示すブロック図である。 本発明の実施の形態1によるCANバスを介して転送される通信フォーマットの一例を示す説明図である。 図3のUARTデータフォーマットの一例を示す説明図である。 図2のECUにおける動作の一例を示すフローチャートである。 本発明の実施の形態1によるマスタECUとスレーブECUとの通信の一例を示す動作フローチャートである。 図2のCANトランシーバ/レシーバがフィルタリングを行う際のCAN通信のボーレートの一例を示す説明図である。 図2のCANトランシーバ/レシーバにおける構成の他の例を示すブロック図である。 本発明の実施の形態2によるマスタECUとスレーブECUとの通信の一例を示す動作フローチャートである。 図9におけるマスタECUの動作の一例を示すフローチャートである。 図10におけるCAN通信に参加しているスレーブECUの動作の一例を示すフローチャートである。 図10におけるCAN通信に参加していないスレーブECUにおける動作の一例を示すフローチャートである。 本発明の実施の形態3によるECUがプラグインされた際のマスタECUとスレーブECUとの通信の一例を示す動作フローチャートである。 図13の動作時におけるマスタECUの動作の一例を示すフローチャートである。 図13の動作時における既存のスレーブECUの動作の一例を示すフローチャートである。 図13の動作時におけるプラグインされたスレーブECUの動作の一例を示すフローチャートである。 本発明の実施の形態4によるマスタECUが、スレーブECUがCAN通信に参加しているかを確認する動作の一例を示すフローチャートである。
以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。
(実施の形態1)
図1は、本発明の実施の形態1による車内ネットワークの接続形態の一例を示すブロック図、図2は、図1のECUに設けられたCANトランシーバ/レシーバにおける構成の一例を示すブロック図、図3は、本発明の実施の形態1によるCANバスを介して転送される通信フォーマットの一例を示す説明図、図4は、図3のUARTデータフォーマットの一例を示す説明図、図5は、図2のECUにおける動作の一例を示すフローチャート、図6は、本発明の実施の形態1によるマスタECUとスレーブECUとの通信の一例を示す動作フローチャート、図7は、図2のCANトランシーバ/レシーバがフィルタリングを行う際のCAN通信のボーレートの一例を示す説明図、図8は、図2のCANトランシーバ/レシーバにおける構成の他の例を示すブロック図である。
本実施の形態1において、自動車の車内ネットワークの接続形態は、図1に示すように、複数のECU1,1a,1bが通信バスとなるCANバスBcを介して相互に接続された構成からなる。これらECU1,1a,1bは、たとえば、ナビゲーションシステムやオーディオなどの情報系、エンジンやシャーシなどのパワートレイン系、あるいはエアコンやヘッドライト、ドアロックなどのボディ系などの各種制御を司る半導体集積回路を有する制御装置である。これらECU1,1a,1bには、各ECU1,1a,1bによって制御されるアクチュエータAcがそれぞれ接続されている。ただし、アクチュエータが接続されていないECUであってもよい。
ECU1は、CANトランシーバ/レシーバ2、レギュレータ3,4、コントローラとなるMCU(Micro Controller Unit)5から構成されている。ECU1(,1a,1b)は、CANトランシーバ/レシーバ2を介してCANバスBcと相互に接続されている。CANバスBcには、第1の通信プロトコルであるCANプロトコルの差動信号、または第2の通信プロトコルであるUARTプロトコルの差動信号が転送される。
通信の電気的インタフェースとなるCANトランシーバ/レシーバ2は、CANバスBcを介して入力される差動信号をデジタル信号に変換、およびMCU5から出力されるデジタル信号を差動信号に変換してCANバスBcに出力すると共に、CANバスBcを介して入力される差動信号の通信プロトコルが、CANプロトコルかUARTプロトコルかを判定し、判定結果がUARTプロトコルの際には、UARTデータの解析を行い、それに基づいてレギュレータ4を制御する。
第1のレギュレータとなるレギュレータ3は、たとえば、自動車のバッテリなどから供給される電源電圧をレギュレートしてCANトランシーバ/レシーバ2の動作電源として供給するレギュレータである。
第2のレギュレータとなるレギュレータ4は、CANトランシーバ/レシーバ2から出力される制御に基づいて、自動車のバッテリなどから供給される電源電圧をレギュレートし、MCU5、およびアクチュエータAcの動作電源として供給するレギュレータである。
MCU5は、CANインタフェース6、通信制御部7、RAM(Random Access Memory)8、タイマ9、割り込みコントローラ10、CPU(Central Processing Unit)11、およびROM(Read Only Memory)12から構成されている。また、通信制御部7、RAM8、タイマ9、CPU11、およびROM12は、内部バスBsを介して相互に接続されている。
また、他のECUに対してCANプロトコル、またはUARTプロトコルのどちらかでメッセージの送信を行う場合、MCU5は送信するメッセージのデジタル信号とどちらのプロトコルで送信するかを示す情報とをCANトランシーバ/レシーバ2に送信する。
CANインタフェース6は、MCU5とCANバスBcとのインタフェースである。通信制御部7は、CANプロトコルに従って他のECUとの通信を制御する。RAM8は、データの一時的な保存に用いられ、たとえば、CANネットワークから受信したデータや、CANネットワークへ送信するデータの一時的な退避などに使用される。
タイマ9は、タイマクロックなどのカウントアップを行って所望の時間設定をし、ある時間に到達するとタイマカウンタ信号を出力する。割り込みコントローラ10は、実行中のプログラムより優先させて実行するプログラムがある場合に、実行中のプログラムの中断や、割り込みプログラムの実行を制御する。割り込みプログラムが終了すると、中断していたプログラムが再開する。通常、割り込みコントローラ10は、MCU5内部からの内部割り込みと、MCU5外部からの外部割り込みとを制御する。
たとえば、一定時間、CANネットワークからのデータ受信がない場合に、タイマ9から出力されるタイムアウト信号を受け取り、割り込みプログラムを発生させ、割り込み処理信号を出力する。
CPU11は、MCU5におけるすべての制御を司る。ROM12は、主にMCU5の動作プログラムが格納されている。動作プログラムは、たとえば、CAN通信プログラム、アクチュエータ制御プログラム、電源遮断処理プログラムなどである。
ここでは、ECU1の構成について記載したが、他のECU1a,1bについても、ECU1と同様の構成となっている。
図2は、CANトランシーバ/レシーバ2における構成の一例を示すブロック図である。
CANトランシーバ/レシーバ2は、図示するように、トランシーバ/レシーバ13、プロトコル判定部となるセレクト回路14、UART用回路15、ID判断部となるID判断回路16、電源動作情報格納部となるレジスタ17、ならびにオンチップオシレータ18から構成されている。
CANトランシーバ/レシーバ2は、前述したように、MCU5に接続されている。そして、MCU5には、アクチュエータAcが接続されており、該アクチュエータAcをMCU5が駆動制御する。
トランシーバ/レシーバ13は、CANバスBcを介して入力される差動信号をデジタル信号に変換、およびMCU5から出力されるデジタル信号を差動信号に変換してCANバスBcに出力する。
セレクト回路14は、次のような方法でCANバスBcから受信した信号のプロトコルを判別する。
CANプロトコルによる通信とUARTプロトコルとの通信を重畳可能とする場合、たとえば異なる通信周波帯域(CANプロトコル通信を高周波帯域で行い、UARTプロトコル通信を低周波帯域で行う)とする。このような異なる周波数帯の信号を重畳させて通信を行うことは、非接触ICカードや電力線通信等の公知の技術が存在しており、これらの技術を適宜採用すればよい。
受信の際はCANバスBcから受信した信号をAM復調により分離して夫々のアナログ信号状態のプロトコル信号をデジタル信号に変換する。送信の際はメッセージのデジタル信号を、どちらのプロトコルで送信するかを示す情報に基づきプロトコルに応じた通信周波帯域のアナログ信号に変換し、変換したアナログ信号をAM変調により重畳しCANバスBcに出力する。
若しくは、CANプロトコルによる通信とUARTプロトコルによる通信とを時間的に分離する場合は、トランシーバ/レシーバ13はCANバスBcから受信した信号をアナログ−デジタル変換し、後段のセレクト回路14がいずれの通信が行われるタイミングかに応じて受信したプロトコルの判別をし、送信の際はMCU5からのメッセージのデジタル信号をデジタル−アナログ変換し、いずれの通信を行うタイミングかに応じてアナログ信号をCANバスBcに出力する。時間的分離と周波数分離との両方を行うことで、プロトコルの分離をより確実にすることも可能となる。
セレクト回路14は、トランシーバ/レシーバ13を介して入力されたデジタル信号が、CANプロトコルであるか、UARTプロトコルであるかを判定し、CANプロトコルの場合には、該デジタル信号をMCU5に出力し、UARTプロトコルの際には、該デジタル信号をUART用回路15に出力するように切り替え制御を行う。
セレクト回路14は、受信したデジタル信号がCANプロトコルかUARTプロトコルかは上述した周波数の相違、若しくは予め決められている送受信タイミング情報に基づき判別する。
また、送信の場合、セレクト回路14は、MCU5から入力されたメッセージのデジタル信号とどちらのプロトコルで送信するかを示す情報とをトランシーバ/レシーバ13に送信し、またはどちらのプロトコルで送信するかを示す情報と予め決められている送受信タイミング情報とに基づき、MCU5から入力されたメッセージのデジタル信号を定められたタイミングでトランシーバ/レシーバ13に送信する。
UART用回路15は、セレクト回路14を介して入力されたデジタル信号が、UARTフォーマットに合致しているか否かを判定し、合致している場合には、ID判断回路16に該デジタル信号を出力する。
ID判断回路16は、入力されたデジタル信号の認識番号であるCAN IDを検出し、そのCAN IDが、ECU毎に割り付けられたCAN IDと同じであるか判断し、同じ場合には、レギュレータ4に制御信号であるイネーブル信号ENを出力する。
レジスタ17は、ID判断回路16によってレギュレータ4がON状態となっていることを示す情報を格納する。オンチップオシレータ18は、CANトランシーバ/レシーバ2における動作クロック信号を生成する。
図3は、CANバスBcを介して転送される通信フォーマットの一例を示す説明図である。
通信が開始される場合、始めの1メッセージ目には、UARTフォーマットのウェイトメッセージ19が転送され、続いて、2メッセージ目に、UARTフォーマットのCAN IDメッセージ20が転送される。その後、CANフォーマットのCANフレーム21が転送され、CAN通信が開始される。
図4は、1メッセージ目、および2メッセージ目に転送されるUARTデータフォーマットの一例を示す説明図である。
1メッセージ目のウェイトメッセージ19は、起動用のメッセージであり、フレームの開始を表すSOF(Start Of Frame)19a、たとえば、8ビットからなる任意のデータビット19b、パリティビット19c、およびデータの終わりを示すストップビット19dから構成されている。
また、2メッセージ目のCAN IDメッセージ20は、フレームの開始を表すSOF20a、たとえば、8ビットのCAN IDからなるデータビット20b、パリティビット20c、ならびにデータの終わりを示すストップビット20dから構成されている。
ここで、ウェイトメッセージ19は、オンチップオシレータ18が発振を開始した後、発振が安定するまで間に必要な時間を確保するための起動待ち時間処理のために用いられるが、該オンチップオシレータ18が発振安定するまでの時間がCAN IDメッセージを受信してからCANフレーム21を受信するまでの時間と比較して十分に短い場合には、省略し、CAN IDメッセージ20を転送するようにしてもよい。
また、データビット20bにおいては、CAN IDだけでなく、1対1通信(マスタのECUと特定のECUとの通信)、一斉通信(マスタのECUとその他のすべてのECUとの通信)、あるいはグループ通信(マスタのECUと特定のグループに属するECUとの通信)などの通信モードを設定する情報を含めるようにしてもよい。
このマスタのECUは、あるECUが他のECUに対してメッセージを送信する場合に、送信元のECUがその時々にマスタのECUとなるが、固定的に特定のECUがマスタとなるのであってもよい。
次に、本実施の形態によるECU1における動作について、図5のフローチャートを用いて説明する。
まず、CANトランシーバ/レシーバ2のトランシーバ/レシーバ13が、CANバスBcを介してメッセージを受信すると(ステップS101)、該トランシーバ/レシーバ13は、CANバスBcを介して受信した差動信号のメッセージをデジタル信号に変換し、セレクト回路14に出力する。
セレクト回路14は、入力された信号がCANフォーマットのメッセージであるか、UARTフォーマットのメッセージあるかを判断し(ステップS102)、CANフォーマットのメッセージの場合には、該メッセージをMCU5に出力する。
そして、MCU5は、入力されたメッセージが、ECU1自身のCAN IDを指定しているか否かを判断し(ステップS103)、ECU1のCAN IDであれば、メッセージの処理を実行する(ステップS104)。
また、ステップS102の処理において、UARTフォーマットのメッセージの場合には、UART用回路15にメッセージを出力する。UART用回路15は、入力されたメッセージがUARTフォーマットに合致しているかを判断し、合致している際には、ID判断回路16に、該メッセージを出力する。
ID判断回路16は、入力されたメッセージがECU1自身のCAN IDを指定しているか否かを判断し(ステップS105)、ECU1のCAN IDであれば、ID判断回路16は、イネーブル信号ENをレギュレータ4に出力し、該レギュレータ4をONさせてECU5、およびアクチュエータAcに電源を供給する(ステップS106)。このとき、ID判断回路16は、レジスタ17に対してレギュレータ4がON状態であることを示す情報を書き込む処理を行う。
このように、レジスタ17にレギュレータ4がON状態であることを示す情報を書き込むことにより、すでにMCU5に電源が供給されている状態で、UARTフォーマットのメッセージにより、レギュレータ4をONする指示があった場合であっても、ID判断回路16によってレギュレータ4をONさせるという処理を省略することが可能となる。
レジスタ17にレギュレータ4がON状態であることを示す情報が書き込まれると、タイマ9は、カウントアップを開始し、CANバスBcのアイドル時間を監視する。アイドル時間が任意の時間を経過すると、MCU5は、ID判断回路16に対して電源遮断指示信号SDを出力する。
ID判断回路16は、電源遮断指示信号SDを受信すると、インアクティブのイネーブル信号ENをレギュレータ4に出力し、該レギュレータ4をOFFさせて、MCU5、ならびにアクチュエータAcの電源供給を停止する。このとき、ID判断回路16は、レギュレータ4がON状態であることを示す情報をレジスタ17から削除する。
あるいは、マスタとなるECUが、動作していないECUに対して電源遮断メッセージを送信することにより、ID判断回路16がインアクティブのイネーブル信号ENをレギュレータ4に出力するようにしてもよい。
図6は、マスタECUとなるECU1aとスレーブECUとなるECU1との通信の一例を示す動作フローチャートである。
まず、ECU1aが、ECU1b宛にメッセージを送信すると(ステップS201)、ECU1のCANトランシーバ/レシーバ2は、該メッセージがECU1bに対するものであるので、レギュレータ4をONさせず、ECU1のMCU5に対して電源供給、および起動/メッセージ転送を行わない。
続いて、ECU1aが、たとえば、ECU1,1bにUARTフォーマットの1つ目のメッセージであるウェイトメッセージ19(図3)を送信すると(ステップS202)、ECU1,1bのCANトランシーバ/レシーバ2が起動する。
その後、2メッセージ目のCAN IDメッセージ20(図3)が入力され、このCAN IDメッセージ20が、たとえば、ECU1、およびECU1b宛の場合、ECU1,1bのCANトランシーバ/レシーバ2は、レギュレータ4をそれぞれ起動させて、ECU1のMCU5とアクチュエータAc、およびECU1bのMCU5とアクチュエータAcにそれぞれ電源供給を行う(ステップS203)。
そして、ECU1宛のCANプロトコルのメッセージが入力されると、該ECU1は、メッセージ処理を行い(ステップS204)、ECU1b宛のCANプロトコルのメッセージが入力されると、ECU1のMCU5は当該メッセージを処理する必要がないと判断し、当該メッセージを破棄する(ステップS205)。
また、ステップS205において、CANトランシーバ/レシーバ2がCAN IDのフィルタリング機能も持つ場合には、MCU5へのメッセージの転送は行わず、メッセージを破棄することも可能である。
その後、ECU1のアイドル時間が任意の時間を経過すると、MCU5からID判断回路16に対して電源遮断指示信号SDが出力され、ID判断回路16によってレギュレータ4がOFFされ、MCU5,ならびにアクチュエータAcの電源遮断処理が実行される(ステップS206)。
それにより、本実施の形態によれば、CAN通信が行われているECUのみに電源が供給され、通信が行われていないECUにおけるMCU、およびアクチュエータAcに対しては電源供給が停止されるので、消費電力を大幅に低減することができる。
次に、CANバスBcを介して送信されるUARTフレームとCANフレームとを識別するフィルタリング技術について説明する。ここでは、CANプロトコルによる通信のボーレートとして、たとえば、500kpsを使用した場合の動作の一例を説明する。
CAN通信のボーレートを500kpsとすると、1ビットは2μsとなる。CANフレームは、CANプロトコルで定義されているスタッフィング機能により、5ビットより長く同一レベルが続かない。
そのため、10μsより長く’Lo’が続いた場合、その信号はCANフレームのSOF信号でないと判断し、その信号をUART SOFとして検出する。
CANトランシーバ/レシーバ2は、図7に示すように、受信信号中に立ち下がりエッジを検出した場合、たとえば、1μs間隔でデータをサンプリングする。立ち下がりエッジから、11サンプル目が10μsとなる。立ち下がりエッジから12サンプル目までが、’Lo’の場合、UART SOF検出となる。
また、CANトランシーバ/レシーバ2は、UARTモード時、CANフレームは無視し、UART SOF検出後、受信データをUART用回路15(図2)へ接続してUART受信を開始する。
そして、ID判断回路16(図2)が、UARTフレームに含まれるCAN IDと 自ECUのCAN IDとが一致しているか否かを判断し、一致している場合、セレクト回路14(図2)は、接続経路をMCU5に接続し(CANモード)、以降のデータをMCU5に入出力する。
続いて、CAN IDの設定技術について説明する。
CAN IDは、たとえば、トランシーバ/レシーバ2に設定されており、たとえば、CANトランシーバ/レシーバ2にフラッシュメモリなどに例示される不揮発性半導体メモリを内蔵する。
そして、その不揮発性半導体メモリにフラッシュライタなどを用いてCAN IDを書き込む。また、フラッシュライタなどによって予めCAN IDを書き込むだけでなく、たとえば、システムの起動時にマスタとなるECUは、すべてのECUをシステム起動メッセージである全ECU起動信号などによって起動させ、すべてのECUがCANフレームを送信して、送信した順にCAN IDを取得し、不揮発性半導体メモリに格納する。
CANの既存の通信プロトコルでは、メッセージ送信を希望するECUはネットワーク上で他のECUがメッセージを送信していない場合は、いずれのECUもメッセージの送信を開始することができる。
CAN ID取得の段階ではいずれのECUも自ECUを特定してマスタとなるECUにメッセージ送信をすることができず、既存の通信プロトコルによりCAN ID取得要求メッセージを送信することになる。
この場合、複数のECUがCAN ID取得要求メッセージを送信することによりネットワーク上で信号の輻輳を生じ、マスタとなるECUがメッセージを正しく受信できないことも生じる。
CAN ID取得要求メッセージを送信したECUは、ネットワーク上で信号の輻輳を生じたことを検知した場合、一旦メッセージの送信を停止し、所定時間を経過した後にCAN ID取得要求メッセージの再送を行うことを繰り返すことで、順次CAN IDを取得する。
また、CANトランシーバ/レシーバ2に、ハードウェア的に予めCAN IDを実装したり、たとえば、図8に示すように、外付けの抵抗R1を用いてCAN IDを設定する構成としてもよい。
この場合、CANトランシーバ/レシーバ2は、分圧用の抵抗22、ならびにA/D変換器23が設けられる構成となる。抵抗R1の一方の接続部には、電源電圧VDDが接続され、該抵抗R1の他方の接続部には、抵抗22の一方の接続部が接続されている。
抵抗22の他方の接続部には、基準電位VSSが接続されている。そして、抵抗R1と抵抗22との接続部が、A/D変換器23の入力部に接続されており、該A/D変換器23の出力部がレジスタ17に接続されている。
抵抗R1と抵抗22とによって分圧された電圧は、A/D変換器23によってデジタルデータに変換され、該デジタルデータがレジスタ17に格納されることにより、CAN IDが設定される。よって、CAN IDは、抵抗R1と抵抗22とによって分圧された電圧値によって設定されることになる。
その他にも、MCU5に設けられたメモリなどにCAN IDを格納し、該MCU5によってCANトランシーバ/レシーバ2に該CAN IDを設定するようにしてもよい。
(実施の形態2)
図9は、本発明の実施の形態2によるマスタECUとスレーブECUとの通信の一例を示す動作フローチャート、図10は、図9におけるマスタECUの動作の一例を示すフローチャート、図11は、図10におけるCAN通信に参加しているスレーブECUの動作の一例を示すフローチャート、図12は、図10におけるCAN通信に参加していないスレーブECUにおける動作の一例を示すフローチャートである。
本実施の形態2では、前記実施の形態1の図1に示す自動車の車内ネットワークにおいて、電源が供給されていない(CANプロトコルによる通信が行われていない)ECUを起動させ、通信を開始させる技術について説明する。
図9は、マスタECUとなるECU1とスレーブECUとなるECU1a,1bとの通信の一例を示す動作フローチャートである。
この図9では、ECU1とECU1aとがCAN通信を行っており、その後、CAN通信を行っていないECU1bを起動し、CAN通信させるまでの動作を示している。また、図9の左側には、ECU1に設けられたレジスタ17(図2)の状態を示している。
レジスタ17の左から右にかけては、ECU1、ECU1a、およびECU1bにおけるそれぞれの状態データが格納されており、’1’はCAN通信に参加している状態(以下、CANモードという)を示しており、’0’は、UARTプロトコルによる通信が可能な状態(以下、UARTモードという)を示している。
ECU1とECU1aとがCAN通信を行っている状態において(ステップS301)、何らかの理由によってECU1bもCAN通信に参加する必要が生じると、ECU1は、CAN通信を行っているすべてのECU(この場合、ECU1a)に対して、通信停止メッセージとなるCAN通信停止フレームを送信する(ステップS302)。
このとき、ECU1aがCANモードであり、ECU1bがUARTモードであるので、レジスタ17のECU1aの状態を示すデータは’1’となっており、ECU1bの状態を示すデータは’0’となっている。
CAN通信停止するフレームは、CANプロトコルでは規定されていないため、通信システムでフレームの内容により決めることになり、たとえば、CAN通信停止フレームは、フレーム内のID(identifier)のbitがすべて’0’のフレームなどとする。
CAN通信停止フレームとしてフレーム内のID(identifier)のbit全てを‘0’とすることにより、他のECUがメッセージを送信中であったとしても、優先順位の調停により最優先となり、CANバス上のすべてのECUがこのフレームを受信可能となる。
そして、CAN通信を行っているすべてのECU(ECU1a)は、CAN通信停止フレームを受信すると、CAN通信を停止する(ステップS303)。
CAN通信を停止する場合、たとえば、ECU1によって指示された任意の期間、CANフレームの送信を停止し、その期間が経過すると自動的にCAN通信に復帰するパターンや、CAN通信を停止し、MCU5(図1)の電源をOFFし、CANトランシーバ/レシーバ2(図1)がUARTプロトコルによる通信を行うモードに遷移し、スタンバイ状態に移行するパターンなど様々なパターンが考えられる。
なお、図9において、ECU1が送信するCAN通信停止フレームは、該ECU1によって指示された任意の期間が経過すると、自動的にECU1aがCAN通信に復帰するパターンとする。
また、自動的にCAN通信に復帰する場合には、CANトランシーバ/レシーバ2は、CAN通信が行える状態で待機し、MCU5の電源はOFFしない。
続いて、ECU1は、前記実施の形態1に記載した技術により、UARTプロトコルの通信を用いて新たにCAN通信に参加させたいECU1bを起動させる(ステップS304,S305)。
ECU1bが起動したことにより、該ECU1bがCAN通信に参加し、レジスタ17のECU1bの状態を示すデータが’0’から’1’に書き換えられる。
そして、ECU1によって指示された任意の期間が経過すると、ECU1aは自動的に復帰を行い(ステップS306)、ECU1、ECU1a,ならびにECU1bのすべてがCAN通信に参加している状態となる(ステップS307)。
なお、マスタECUがCAN通信を停止する方法としては、上記したようにCANフレームによってスレーブECUのCAN通信を停止させる他に、たとえば、光通信などを用いている場合には、停止信号を通常の信号に重畳させることによっても可能である。
また、ステップS302でECU1がCAN通信停止フレームを出力する代わりに、UARTプロトコルの通信によりECU1bを起動させることも行い得る(ステップS302‘とする)。
この場合、ECU1がUARTプロトコルの通信を行っていることをECU1aが検知し、かかる通信期間中はECU1aはCAN通信を行わないように制御される。かかる動作を行った場合は、ステップS302’を行った後、ステップS307に遷移することが可能となる。
図10は、CAN通信を行っていないECUを起動させ、CAN通信を開始させる際のマスタとなるECU1における動作の一例を示すフローチャートである。
まず、ECU1は、CAN通信に参加していないECUがある場合、そのECUを起動させる必要があるか否かを判断する(ステップS401)。CAN通信に参加していないECUを起動させる必要があると判断すると、ECU1は、車内ネットワークのシステムがCAN通信中か否かを判断する(ステップS402)。
CAN通信中でない場合には、後述するステップS404の処理を実行し、CAN通信中の場合、ECU1は、CAN通信に参加しているすべてのECUに対してCAN通信停止フレームを送信し(ステップS403)、該ECUのCAN通信を停止させる。
CAN通信に参加しているすべてのECUのCAN通信が停止すると、ECU1は、UARTプロトコルの通信を用いて新たにCAN通信に参加させたいECU1bを起動させる(ステップS404)。
この場合、前記実施の形態1において説明したように、始めの1メッセージ目には、UARTフォーマットのウェイトメッセージが転送され、続いて、2メッセージ目に、UARTフォーマットのCAN IDメッセージが転送される。
そして、ステップS404の処理において、起動させたいECUが起動すると、CANフォーマットのCANフレーム21が転送され、CAN通信が開始される(ステップS405)。
図11は、CAN通信を行っていないECUを起動させ、CAN通信を開始させる際のマスタとなるECU1がCAN通信を行っていないECU1bを起動させる際のCAN通信を行っているスレーブECUであるECU1aにおける動作の一例を示すフローチャートである。
まず、ECU1bは、CANトランシーバ/レシーバ2が、CANモードであるか否かを判断し(ステップS501)、CANモードの場合には、マスタのECU1から、CAN通信停止フレームが送信されたか否かを判断する(ステップS502)。
ECU1から、CAN通信停止フレームが送信されていない場合には、通常のCANプロトコルの通信に応じた実行処理を行う(ステップS503)。ECU1から、CAN通信停止フレームが送信された際には、その指示に基づいて、ECU1aのCANトランシーバ/レシーバ2がMCU5の電源をOFFし、CANプロトコルによる通信を停止する(ステップS504)。
そして、ECU1によって指示された任意の期間の間、ステップS504の状態を維持した後(ステップS505)、CANトランシーバ/レシーバ2がMCU5の電源をONしてCANプロトコルによる通信に復帰する(ステップS506)。
ここで、ステップS504の処理では、ECU1から指示で、ECU1aのMCU5の電源をOFFしてCANプロトコルによる通信を停止するものとしたが、該ECU1の指示は、これ以外に、ECU1aのMCU5の電源をOFFせずにCANプロトコルによる通信のみを停止する処理などであってもよい。
図12は、マスタとなるECU1がCANモードでないECU1bを起動させ、CAN通信を開始させる際の該ECU1bにおける動作の一例を示すフローチャートである。
まず、ECU1bは、CANトランシーバ/レシーバ2が、CANモードであるか、あるいはUARTモードであるかを判定し(ステップS601)、CANモードの場合には、通常のCANプロトコルの通信時応じた実行処理を行う(ステップS602)。
ステップS601の処理において、UARTモードの場合には、ECUを起動させるUARTフォーマットによるメッセージを受信したか否かを判断する(ステップS603)。
ステップS603の処理において、メッセージを受信すると、ECU1bは、受信したメッセージが自ECU(1b)宛のメッセージであるか否かを判断し(ステップS604)、自ECU宛のメッセージの場合には、そのメッセージに基づいて、ECU1bのCANトランシーバ/レシーバ2がMCU5の電源をONさせ、ECU1bをCAN通信に参加させる(ステップS605)。
以上、説明した電源が供給されていない(CANプロトコルによる通信が行われていない)ECUを起動させ、通信を開始させる技術は、緊急時の損害低減や二次災害の防止などに有効である。またそのような場合の図10〜図12のUARTフォーマットによるメッセージの通信は、CANフォーマットによる通信を阻害しないように、異なる周波数帯を用いた信号重畳による通信を行うとよい。ブレーキやエアバッグ等の自動車の安全運行に必要とされるCAN通信を行いつつ、不要なECUの通信を停止させ、更に通信に参加することが必要となるECUを起動させることが可能となる。
自動車の周囲監視を行うレーダーECUが他車の異常接近を検知した場合に、衝突事故の発生に備えてエアバッグやシートベルトを制御するECUを起動することにより、衝突発生前にシートベルトを固定し、衝突発生の直前/直後にエアバックの膨張を行い、乗員の肉体的な損傷を低減することができる。若しくは自車の歩行者等への接近を検知してブレーキ制御ECUを起動して減速制御を行い、歩行者などへ与える被害を低減することができる。
たとえば、燃料電池車の場合には、衝突時に水素ガスなどのガス漏れを検出する(マスタECUとガスセンサECUとが通信)と、マスタECUは、サンルーフ、ウィンドウ、スライドドア、エアコンなどを制御する各ECUを起動することによって、車内換気を行い、車内に水素ガスが充満して火災や爆発を生じないようにすることができる。
また、ハイブリッド車や電気自動車などの場合には、衝突時などに電源制御を行うECUがCAN通信に参加していなければ、電源制御系のECUを起動させ、バッテリ、ならびに該バッテリ周辺機器をファン(およびラジエータ)などで緊急冷却し、バッテリ発火による火災を防止することができる。
さらに、衝突時などに該当するECUを起動させ、ルームランプの点灯、ハザードランプの点滅、クラクションを鳴らす、テレマティックスによる通報などによる事故発生の周知の他、ドアが施錠されている際には、避難のためにドアロックを解除するとなどを行うことができる。
(実施の形態3)
図13は、本発明の実施の形態3によるECUがプラグインされた際のマスタECUとスレーブECUとの通信の一例を示す動作フローチャート、図14は、図13の動作時におけるマスタECUの動作の一例を示すフローチャート、図15は、図13の動作時における既存のスレーブECUの動作の一例を示すフローチャート、図16は、図13の動作時におけるプラグインされたスレーブECUの動作の一例を示すフローチャートである。
本実施の形態3では、前記実施の形態1の図1に示す自動車の車内ネットワークにおいて、新たにECUがプラグインされた場合に、プラグインされたECUの動作認識情報となるECU情報をマスタのECUに通知する技術について説明する。
ここで「プラグイン」とは、たとえば、カーナビゲーションシステムを追加または交換する等、CANが以前に稼動していた時点においては存在していなかったECUがCANに新たに接続されることを意味する。
図13は、新たにECUがプラグインされた際のマスタECUとなるECU1とスレーブECUとなるECU1a,1bとの通信の一例を示す動作フローチャートである。ここで、図13においては、ECU1b(図1)が新たにプラグインされたECUであるものとする。
マスタとなるECU1は、MCU5、およびCANトランシーバ/レシーバ2に電源が供給されている状態であり、スレーブのECU1aは、CANトランシーバ/レシーバ2がUARTモードでスタンバイ状態となっており、MCU5の電源がOFFされている。また、プラグインされたECU1bは、CANトランシーバ/レシーバ2がUARTモードでスタンバイ状態となっており、MCU5の電源がOFFされている。
また、図13では、スレーブのECU1a,1bは、いずれも間欠動作を行うECUであるものとする。さらに、図の左側には、ECU1に設けられたレジスタ17(図2)の状態を示しており、レジスタ17の左から右にかけては、ECU1、ECU1a、およびECU1bにおけるそれぞれの状態データが格納されている。レジスタ17の’1’はCANモードを示しており、’0’は、UARTモードを示している。
まず、ECU1は、すべてのECUに対して、UARTフレームにより、すべてのECUを起動させる全ECU起動信号をCANバスBcを介して送信する(ステップS701)。
この全ECU起動信号は、たとえば2つのメッセージからなり、第1のメッセージは、図4のCAN IDメッセージ20において全てのECUを起動させることを示すメッセージであり、第2のメッセージは、起動情報を取得するためのメッセージであることを意味する信号である。
ECU1a,1bにおいては、全ECU起動信号を受信することにより、CANトランシーバ/レシーバ2がCANモードにより起動し、MCU5の電源がそれぞれONとなる(ステップS702)。
続いて、ECU1は、新規にプラグインされたECUがあるかを問い合わせ(ステップS703)、プラグインされたECU1bは、ECU1の要求に基づいて自ECU1bのECU情報(CAN IDや動作情報など)をCANフレームによりECU1に送信する(ステップS704)。
その後、ECU1は、残りのECU1aに対しても、ECU情報を要求し(ステップS705)、該ECU情報を取得する(ステップS706)。そして、任意の時間が経過すると、ECU1a,1bのCANトランシーバ/レシーバ2がUARTモードでスタンバイ状態となり、ECU1a,1bのMCU5の電源がOFFとなる(ステップS707)。
ECU1は、ステップS704,S706の処理でそれぞれ取得したECU情報に基づいて、任意の期間ごとに、ECU1aの起動(ステップS708)、ならびにECU1bの起動(ステップS709)を繰り返す。
図14は、図13の動作時におけるマスタとなるECU1の動作の一例を示すフローチャートである。
まず、ECU1は、UARTフレームによって全ECU起動信号をCANバスBcを介してすべてのECU(ECU1a,1b)に送信し(ステップS801)、CANモードを起動させる。続いて、ECU1は、プラグインしたECU1b、およびその他の既存のECU1aに対して、CANフレームにより、ECU情報をそれぞれ要求する(ステップS802)。
ECU1は、すべてのECUからのECU情報を取得すると、取得したECU情報をバッファなどに格納する(ステップS803)。ECU1は、ECU1aの間欠時間が経過したか否かの判断を行い(ステップS804)、その間欠時間が経過したら、UARTフレームによりECU1aを起動させて該ECU1aとのCAN通信を開始する(ステップS805)。
ステップS804の処理において、ECU1aの間欠時間が経過していない場合、ECU1は、ECU1bの間欠時間が経過したか否かの判断を行い(ステップS806)、該間欠時間が経過するとUARTフレームによりECU1bを起動させ、該ECU1bとのCAN通信を開始する(ステップS807)。
図15は、図13の動作時におけるスレーブとなる既存のECU1aの動作の一例を示すフローチャートである。
まず、ECU1aは、CANトランシーバ/レシーバ2がUARTモードか否かを判断し(ステップS901)、CANモードの場合には、通常のCANプロトコルの通信に応じた実行処理を行う(ステップS902)。
また、ステップS901の処理において、UARTモードの場合には、マスタとなるECU1から受信したUARTフレームが自ECU1a宛か否か、あるいは全ECU起動信号か否かを判断する(ステップS903)。
UARTフレームが自ECU1a宛、あるいは全ECU起動信号の場合には、CANトランシーバ/レシーバ2がCANモードに移行し、MCU5の電源をONとする(ステップS904)。また、UARTフレームが自ECU1a宛、あるいは全ECU起動信号のいずれでもない場合には、ステップS901の処理に戻る。
続いて、ECU1aは、ECU1から、自ECU1aのECU情報の取得要求があるかを判断する(ステップS905)。ECU1aのECU情報の取得要求がない場合には、ステップS902の処理を実行する。
また、ECU情報の取得要求がある場合、ECU1aは、CANバスBcがアイドル状態であるかを任意の期間確認し(ステップS906)、アイドル状態であれば、ECU1へECU1aのECU情報をCANフレームによって送信する(ステップS907)。
そして、ECU1aは、CANトランシーバ/レシーバ2をUARTモードに移行させ、ECU1からの起動メッセージを待つ(ステップS908)。ECU1からの起動メッセージを受信すると(ステップS909)、自ECU1a宛のメッセージであるか否かを判断し(ステップS910)、ECU1a宛のメッセージの場合、該ECU1aは、MCU5の電源をONし、CANモードに移行し(ステップS911)、ステップS902の処理を実行する。
図16は、図13の動作時におけるスレーブとなるプラグインされたECU1bの動作の一例を示すフローチャートである。
まず、ECU1bは、CANトランシーバ/レシーバ2がUARTモードか否かを判断し(ステップS1001)、CANモードの場合には、通常のCANプロトコルの通信に応じた実行処理を行う(ステップS1002)。UARTモードの場合には、マスタのECU1から受信したUARTフレームが自ECU1b宛か、全ECU起動信号か、またはプラグインしたECUへの取得要求であるかを判断する(ステップS1003)。
UARTフレームがECU1b宛、全ECU起動信号、あるいはプラグインしたECUへの取得要求の場合には、CANトランシーバ/レシーバ2がCANモードに移行し、MCU5の電源をONする(ステップS1004)。
続いて、ECU1bは、ECU1から、ECU1bのECU情報の取得要求があるかを判断する(ステップS1005)。ECU1bのECU情報の取得要求がない場合には、ステップS1002の処理を実行する。
ステップS1005の処理において、ECU情報の取得要求がある場合、ECU1bは、その取得要求が、プラグインしたECUへのECU情報の取得要求であるかを確認し(ステップS1006)、プラグインしたECUへのECU情報の取得要求の場合には、ECU1bは、自ECU1bはプラグインしたECUか否かを判断する(ステップS1007)。
また、ステップS1006の処理において、プラグインしたECUへのECU情報の取得要求でない場合には、ECU1bは、後述するステップS1008の処理を実行し、ステップS1007の処理において、プラグインしたECUでないと判断した場合には、ステップS1002の処理を実行する。
ECU1bがプラグインしたECUであると判断すると、該ECU1bは、CANバスBcがアイドル状態であるかを任意の期間確認し(ステップS1008)、アイドル状態であれば、ECU1へECU1bのECU情報をCANフレームによって送信する(ステップS1009)。
続いて、ECU1bは、CANトランシーバ/レシーバ2をUARTモードに移行させ、ECU1からの起動メッセージを待つ(ステップS1010)。ECU1bが、ECU1からの起動メッセージを受信すると(ステップS1011)、自ECU1b宛のメッセージであるか否かを判断し(ステップS1012)、ECU1b宛のメッセージの場合、該ECU1bは、MCU5の電源をONし、CANモードに移行し(ステップS1013)、ステップS1002の処理を実行する。
CANネットワークに接続される既存のECU(ECU1a)と追加されたECU(ECU1b)とは、図15及び図16のフローにおいて図示しない以下の処理を行ってよい。
ECU1およびECU1aが自ECUのECU情報を送信(図13のステップS706)することに応じて、ECU1bはECU1とECU1aのECU情報をECU1b内の不揮発性メモリに格納する。
また、ECU1bがECU1bのECU情報をECU1に送信(図13のステップS704)することに応じて、ECU1aはECU1bのECU情報をECU1a内の不揮発性メモリに格納する。
ECU1に代わってECU1aまたはECU1bがマスタECUとなった場合に、ECU1aまたはECU1bのECU情報を取得するために図14の処理を行うことは冗長であり、プラグインされたECU1bが存在する場合、既存のECU全てがプラグインされたECU1bの情報取得処理で共有すると共に、プラグインされたECUが既存のECU全ての情報を同様に情報取得処理で共有する。
かかる処理により、CANネットワークに接続される全てのECUが他のECUのECU情報を保持することになり、いずれのECUがマスタECUになった場合でも、他のECUの動作情報取得処理を行うことなく、他のECUの間欠動作制御等を行うことが可能になる。
上述した技術は、自動車のオプションなどによって新たに追加された機能を後付けした際に、新たにプラグインされるECUに対して有効である。
たとえば、自動車のリアウィンドウなどに設けられているリアワイパを後付けにより取り付けた場合には、ボディ系のマスタのECUは、電源ON時、CANバスを介して全ECU起動信号を送信し、すべてのECUを起動させる。
プラグインされたECUは、マスタのECUからの要求に応じて、プラグインされたECUのECU情報をマスタのECUに送信する。この場合、プラグインされたECUは、間欠動作するリアワイパを動作させるECUであるので、ECU情報として、たとえば、CAN IDとリアワイパの間欠動作情報などを送信する。
そして、マスタのECUは、リアワイパの動作がONした情報を検出すると、その情報に応じて、リアワイパを制御するプラグインされたECUを起動させる。
ここでは、一例としてリアワイパを制御するECUについて記載したが、この他に、ナビゲーションシステムやオーディオなどの様々なECUが追加された場合についても、同様の処理を行うことになる。
また、プラグインされたECUは、最適化されていた車内ネットワークシステムに新たに追加されることになるので、該システムに問題が発生した場合、既存のECUよりも故障の原因となる確率が高くなる可能性がある。
そのため、問題が発生すると、最初に、プラグインされたECUを検証する必要性が認識できる。この場合、既存のECUには、CANトランシーバ/レシーバ2に、予め設定されているCAN ID(たとえば、ID1〜ID16)を割り振っておき、プラグインされたECUには、それ以外のCAN IDを割り振り、予め設定されているCAN ID以外のCAN IDがCANバスを介して配信された際に、プラグインされたECUと認識することができる。
(実施の形態4)
図17は、本発明の実施の形態4によるマスタECUが、スレーブECUがCAN通信に参加しているかを確認する動作の一例を示すフローチャートである。
本実施の形態4では、前記実施の形態1の図1に示す自動車の車内ネットワークにおいて、あるスレーブのECUが外部トリガによって起動した際に、マスタのECUに対してスレーブの該ECUが起動したことを通知する技術について説明する。
図17は、マスタとなるECU1が、スレーブのECU1a,1bがCAN通信に参加しているかを確認する動作の一例を示すフローチャートである。
図17では、ECU1bが外部トリガによって起動可能なECUであるものとし、図17の左側には、ECU1に設けられたレジスタ17(図2)の状態を示している。レジスタ17の左から右にかけては、ECU1、ECU1a、およびECU1bにおけるそれぞれの状態データが格納されており、レジスタ17の’1’はCANモードを示しており、’0’は、UARTモードを示している。
まず、ECU1は、CANプロトコルの通信により、各ECU1a,1bが起動しているか否かを問い合わせる(ステップS1101)。ここでは、ECU1aが起動しているので、該ECU1aは、起動していることをECU1に通知する(ステップS1102)。これにより、レジスタ17のECU1aの状態を示すデータは’1’となる。
その後、ECU1bが外部トリガにより起動すると(ステップS1103)、ECU1bのMCU5がCANトランシーバ/レシーバ2を起動させる(ステップS1104)。そして、ECU1は、再びCANプロトコルの通信により、各ECU1a,1bが起動しているか否かを問い合わせる(ステップS1105)。
これを受けて、ECU1aは、起動していることをECU1に通知する(ステップS1106)。ECU1bも起動したので、同様に起動していることをECU1に通知する(ステップS1107)。これにより、レジスタ17のECU1aの状態を示すデータ、およびECU1bの状態を示すデータは、それぞれ’1’となる。
外部トリガで起動可能なECUは、外部トリガを検出する必要があるので、MCU5の電源はOFFせず、スタンバイ状態とし、CANトランシーバ/レシーバ2は、UARTモードでマスタのECUから、外部トリガで起動可能なECUを起動させるメッセージを待つ。
マスタのECUは、任意の時間毎に各スレーブのECUが起動しているかを問い合わせ、外部トリガで起動したECUは、その問い合わせは、自ECU宛か、全ECU起動信号か、あるいは新規に起動したECUへのいずれかの場合に、問い合わせに応じる。
その後、スレーブのECUは、マスタのECUの指示に従い、CANモードで待機するか、もしくはUARTモードに移行するかを指示するようにしてもよい。
また、マスタのECUは、問い合わせと共に、外部トリガにより起動したECUが、そのままCANモードで待機するか、またはUARTモードに移行するかを指示するようにしてもよい。
さらに、外部トリガによって起動したECU自身が、マスタのECUに対して起動したことを通知することも可能である。
外部トリガによってMCU5が起動すると、該MCU5は、CANトランシーバ/レシーバ2を起動させる。続いて、MCU5は、任意の期間(たとえば、1ms程度)、Lo信号をCANバスを介して送信するように制御を行い、マスタのECUにECUが起動したことを通知する。
このLo信号による通知は、別のECUが出力するCANフレームとECUからLo信号が衝突したときに、再送を繰り返さないように、ワンショット送信とする。若しくは、別のECUの出力するCANフレームとの衝突を防止するために、異なる周波数帯を用いて通信するようにしてもよい。
そして、マスタのECUがいずれかのスレーブのECUが起動したことを検出すると、マスタのECUは、CANプロトコルによる通信により、スレーブの該ECUへの問い合わせを行い、起動しているECUのECU情報を得る。
外部トリガによって起動するECUとしては、たとえば、メモリシートなどを制御するECUなどがあり、メモリシートのスイッチによって該ECUが起動すると、マスタのECUに起動を通知することになる。
以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
たとえば、前記実施の形態では、ECUが2つのレギュレータ3,4を備え、イネーブル信号ENによって、MCU5とアクチュエータAcに電源を供給するレギュレータ4をON/OFF制御する構成としたが、レギュレータを1つとし、MCU5とアクチュエータAcには、スイッチを介して電源電圧を供給する構成としてもよい。
この場合、イネーブル信号ENは、スイッチをON/OFF制御する信号とし、スイッチがONの場合には、MCU5とアクチュエータAcとに電源が供給され、スイッチがOFFすると、MCU5とアクチュエータAcとに電源供給が停止されることになる。
また、前記実施の形態では、通信ネットワークとしてCANを用い、レギュレータの電源のON/OFF制御をUARTプロトコルによって制御する場合について記載したが、通信ネットワークに、たとえば、FlexRayなどの他の通信ネットワークを用い、レギュレータの電源のON/OFFをLINなどの他のプロトコルによって制御する構成であってもよい。
本発明は、自動車などの通信システムに用いられる半導体集積回路装置における低消費電力化技術に適している。
1 ECU
1a ECU
1b ECU
2 CANトランシーバ/レシーバ
3 レギュレータ
4 レギュレータ
5 MCU
6 CANインタフェース
7 通信制御部
8 RAM
9 タイマ
10 割り込みコントローラ
11 CPU
12 ROM
13 トランシーバ/レシーバ
14 セレクト回路
15 UART用回路
16 ID判断回路
17 レジスタ
18 オンチップオシレータ
19 ウェイトメッセージ
19a SOF
19b データビット
19c パリティビット
19d ストップビット
20 CAN IDメッセージ
20a SOF
20b データビット
20c パリティビット
20d ストップビット
21 CANフレーム
22 抵抗
23 A/D変換器
R1 抵抗
Bc CANバス
Ac アクチュエータ
Bs 内部バス

Claims (9)

  1. 第1電子制御装置、第2電子制御装置、および第3電子制御装置を含む複数の電子制御装置を通信バスに接続し、
    前記第1電子制御装置は、前記通信バスを介して第1メッセージと第2メッセージとを当該順序で出力し、
    前記第2電子制御装置が前記第1メッセージを受信した場合、所定の期間において前記通信バスへのメッセージの出力を停止し、
    スタンバイ状態とされている前記第3電子制御装置が前記第2メッセージを受信した場合、前記第2メッセージに含まれるIDが自己を指定するものか否かを判定し、自己を指定するIDである場合、前記スタンバイ状態から動作状態へ遷移する、電子制御装置の制御方法。
  2. 請求項1記載の電子制御装置の制御方法において、
    前記第2電子制御装置は、前記所定の期間を経過した後、前記通信バスへのメッセージを出力可能な状態へ遷移する、電子制御装置の制御方法。
  3. 請求項1記載の電子制御装置の制御方法において、
    前記第2電子制御装置は、通信インタフェース部と制御部とを有し、
    前記第2電子制御装置が前記第1メッセージを受信した場合、前記制御部は前記スタンバイ状態へ遷移し、前記通信インタフェース部は前記通信バスからのメッセージの受信待機状態へ遷移する、電子制御装置の制御方法。
  4. 請求項1記載の電子制御装置の制御方法において、
    前記第3電子制御装置は、自動車のバッテリから電源電圧が供給された後の一定時間を経過した後、前記動作状態から前記スタンバイ状態へ遷移する、電子制御装置の制御方法。
  5. 請求項1〜4のいずれか1項に記載の電子制御装置の制御方法において、
    前記通信バスは、コントロールエリアネットワーク(CAN)バスであり、
    前記複数の電子制御装置の其々は、前記CANバスに対応したインタフェース部を有する、電子制御装置の制御方法。
  6. 自動車のコントロールエリアネットワーク(CAN)バスに接続された第1電子制御装置、第2電子制御装置、および第3電子制御装置の制御方法であって、
    1)前記第1電子制御装置は、前記CANバスへ第1メッセージを出力し、
    2)前記第2電子制御装置は、前記第1メッセージを受信した場合、所定の期間において前記CANバスへのメッセージの出力を停止し、
    3)前記2)の後、前記第1電子制御装置は、前記CANバスへ第2メッセージを出力し、
    4)スタンバイ状態とされている前記第3電子制御装置が前記第2メッセージを受信した場合、前記第2メッセージに含まれるIDが自己を指定するものか否かを判定し、自己を指定するIDである場合、前記スタンバイ状態から動作状態へ遷移する、電子制御装置の制御方法。
  7. 請求項6記載の電子制御装置の制御方法において、
    前記第2電子制御装置は、前記所定の期間を経過した後、前記CANバスへのメッセージを出力可能な状態へ遷移する、電子制御装置の制御方法。
  8. 請求項6記載の電子制御装置の制御方法において、
    前記第2電子制御装置は、通信インタフェース部と制御部とを有し、
    前記第2電子制御装置が前記第1メッセージを受信した場合、前記制御部は前記スタンバイ状態へ遷移し、前記通信インタフェース部は前記CANバスからのメッセージの受信待機状態へ遷移する、電子制御装置の制御方法。
  9. 請求項6記載の電子制御装置の制御方法において、
    前記第3電子制御装置は、自動車のバッテリから電源電圧が供給された後の一定時間を経過した後、前記動作状態から前記スタンバイ状態へ遷移する、電子制御装置の制御方法。
JP2014213631A 2009-05-20 2014-10-20 電子制御装置の制御方法 Active JP5849142B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2014213631A JP5849142B2 (ja) 2009-05-20 2014-10-20 電子制御装置の制御方法

Applications Claiming Priority (5)

Application Number Priority Date Filing Date Title
JP2009121861 2009-05-20
JP2009121861 2009-05-20
JP2009273114 2009-12-01
JP2009273114 2009-12-01
JP2014213631A JP5849142B2 (ja) 2009-05-20 2014-10-20 電子制御装置の制御方法

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2013184503A Division JP5636479B2 (ja) 2009-05-20 2013-09-05 通信システム

Related Child Applications (1)

Application Number Title Priority Date Filing Date
JP2015234141A Division JP6010207B2 (ja) 2009-05-20 2015-11-30 通信システム

Publications (2)

Publication Number Publication Date
JP2015039224A JP2015039224A (ja) 2015-02-26
JP5849142B2 true JP5849142B2 (ja) 2016-01-27

Family

ID=49844112

Family Applications (6)

Application Number Title Priority Date Filing Date
JP2013155995A Active JP5607219B2 (ja) 2009-05-20 2013-07-26 自動車用通信システム
JP2013184503A Active JP5636479B2 (ja) 2009-05-20 2013-09-05 通信システム
JP2014172688A Active JP5756879B2 (ja) 2009-05-20 2014-08-27 自動車
JP2014213631A Active JP5849142B2 (ja) 2009-05-20 2014-10-20 電子制御装置の制御方法
JP2015234141A Active JP6010207B2 (ja) 2009-05-20 2015-11-30 通信システム
JP2016180331A Active JP6255072B2 (ja) 2009-05-20 2016-09-15 半導体装置

Family Applications Before (3)

Application Number Title Priority Date Filing Date
JP2013155995A Active JP5607219B2 (ja) 2009-05-20 2013-07-26 自動車用通信システム
JP2013184503A Active JP5636479B2 (ja) 2009-05-20 2013-09-05 通信システム
JP2014172688A Active JP5756879B2 (ja) 2009-05-20 2014-08-27 自動車

Family Applications After (2)

Application Number Title Priority Date Filing Date
JP2015234141A Active JP6010207B2 (ja) 2009-05-20 2015-11-30 通信システム
JP2016180331A Active JP6255072B2 (ja) 2009-05-20 2016-09-15 半導体装置

Country Status (1)

Country Link
JP (6) JP5607219B2 (ja)

Families Citing this family (13)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5607219B2 (ja) * 2009-05-20 2014-10-15 ルネサスエレクトロニクス株式会社 自動車用通信システム
JP5732836B2 (ja) * 2010-12-08 2015-06-10 株式会社オートネットワーク技術研究所 制御システム及び制御装置
KR101524143B1 (ko) * 2013-12-13 2015-05-29 현대자동차주식회사 부분적 통신 네트워킹을 위한 전자 제어기 및 동작 제어 방법
JP6323219B2 (ja) * 2014-07-04 2018-05-16 いすゞ自動車株式会社 通信機能バイパス装置
KR101585856B1 (ko) * 2014-12-30 2016-01-15 주식회사 현대케피코 차량 내 uart 및 can 통합 통신 방법 및 장치
JP6471613B2 (ja) * 2015-05-28 2019-02-20 株式会社オートネットワーク技術研究所 中継装置及び通信システム
DE102016216066A1 (de) 2016-08-26 2018-03-01 Robert Bosch Gmbh Teilnehmer für ein digitales Kommunikationssystem und zugehöriges Kommunikationssystem
JP6307574B1 (ja) * 2016-10-28 2018-04-04 エルアンドビー テクノロジー カンパニー リミテッド Can通信を用いたパブリックアドレス装置
JP6535039B2 (ja) 2017-02-14 2019-06-26 株式会社東海理化電機製作所 電子制御装置
CN108319217A (zh) * 2018-03-19 2018-07-24 延锋伟世通汽车电子有限公司 基于stm32系统的can、lin控制电路
IT201800003980A1 (it) 2018-03-26 2019-09-26 Stmicroelectronics Application Gmbh Procedimento di comunicazione, sistema, dispositivi, segnale e veicolo corrispondenti
IT202100005354A1 (it) 2021-03-08 2022-09-08 Stmicroelectronics Application Gmbh Circuito microcontrollore, dispositivo, sistema e procedimento di funzionamento corrispondenti
CN114900392B (zh) * 2022-05-16 2023-07-25 株洲嘉成科技发展股份有限公司 一种利用can总线传输串口数据的方法

Family Cites Families (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH11316629A (ja) * 1998-05-07 1999-11-16 Oki Electric Ind Co Ltd 電子機械装置
JP3724318B2 (ja) * 2000-03-16 2005-12-07 松下電工株式会社 テレビドアホン装置
JP2002140111A (ja) * 2000-11-01 2002-05-17 Shimizu Corp 設備機器制御統合化システム
DE10134584B4 (de) * 2001-07-17 2005-12-08 Siemens Ag Bussystem und Verfahren zum Austausch von Daten
JP3797166B2 (ja) * 2001-09-18 2006-07-12 株式会社デンソー ネットワークシステム
US8566466B2 (en) * 2002-06-10 2013-10-22 Nxp B.V. Method and system for switching between subnetwork operation and full network operation
DE10358584A1 (de) * 2002-12-30 2004-07-15 Robert Bosch Gmbh Verfahren und Vorrichtung zum Aufwecken von Teilnehmern eines Bussystems und entsprechender Teilnehmer
JP4083598B2 (ja) * 2003-03-07 2008-04-30 本田技研工業株式会社 ネットワークシステム
JP2006020038A (ja) * 2004-07-01 2006-01-19 Denso Corp 物理量センサ装置およびその検査装置
JP4225264B2 (ja) * 2004-10-06 2009-02-18 株式会社デンソー 通信装置
JP2006327217A (ja) * 2005-05-23 2006-12-07 Fujitsu Ten Ltd 車両制御用プログラム及び車両用電子制御装置
JP4807497B2 (ja) * 2005-12-14 2011-11-02 日本電気株式会社 複数の送信機を制御するための方法およびシステム
US7539888B2 (en) * 2006-03-31 2009-05-26 Freescale Semiconductor, Inc. Message buffer for a receiver apparatus on a communications bus
JP2008199253A (ja) * 2007-02-13 2008-08-28 Fujitsu Ten Ltd 異常診断システム及び診断情報管理装置
JP2008222051A (ja) * 2007-03-13 2008-09-25 Denso Corp マイクロコンピュータ、プログラム、電子制御装置、及び通信システム
JP2008263294A (ja) * 2007-04-10 2008-10-30 Sharp Corp 通信端末装置
JP5363379B2 (ja) * 2009-05-20 2013-12-11 ルネサスエレクトロニクス株式会社 通信システム
JP5607219B2 (ja) * 2009-05-20 2014-10-15 ルネサスエレクトロニクス株式会社 自動車用通信システム

Also Published As

Publication number Publication date
JP5636479B2 (ja) 2014-12-03
JP2015013641A (ja) 2015-01-22
JP5607219B2 (ja) 2014-10-15
JP2015039224A (ja) 2015-02-26
JP6255072B2 (ja) 2017-12-27
JP6010207B2 (ja) 2016-10-19
JP2014003703A (ja) 2014-01-09
JP2017028719A (ja) 2017-02-02
JP5756879B2 (ja) 2015-07-29
JP2013243758A (ja) 2013-12-05
JP2016048958A (ja) 2016-04-07

Similar Documents

Publication Publication Date Title
JP5363379B2 (ja) 通信システム
JP6255072B2 (ja) 半導体装置
JP4483694B2 (ja) 車両用通信システム
CN110535667A (zh) 用于选择性唤醒车辆网络中的通信节点的方法和装置
JP2007251722A (ja) 通信装置、車載システム、データ保存方法及びプログラム
JP2009296280A (ja) 通信ネットワークシステム及びその通信制御方法
JP4847847B2 (ja) 中継接続ユニット及び車載用の多重通信システム
JP2008113211A (ja) 車両用通信システム
WO1999034559A1 (fr) Procede de transmission multiplex
JP2007030714A (ja) 車両用通信システム
JP2012114537A (ja) 電子制御装置、車両ネットワークシステム、通信方法、プログラム
JP2009124480A (ja) 車載ゲートウェイ及び車両用通信システム
JP5614365B2 (ja) データ中継装置、車載ネットワーク
JP2020059355A (ja) 車両用描画装置
JP2019009678A (ja) 車載通信ネットワークシステム
JP2010258635A (ja) 制御装置
JP2024118192A (ja) 車載制御装置、給電制御方法および給電制御プログラム
JP2014086848A (ja) 通信システムおよび通信方法
JP2007251444A (ja) シリアル通信方法

Legal Events

Date Code Title Description
A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20150528

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20150616

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20150806

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20151104

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20151130

R150 Certificate of patent or registration of utility model

Ref document number: 5849142

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150