以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。
(実施の形態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などの他のプロトコルによって制御する構成であってもよい。