JP2012114537A - 電子制御装置、車両ネットワークシステム、通信方法、プログラム - Google Patents

電子制御装置、車両ネットワークシステム、通信方法、プログラム Download PDF

Info

Publication number
JP2012114537A
JP2012114537A JP2010259789A JP2010259789A JP2012114537A JP 2012114537 A JP2012114537 A JP 2012114537A JP 2010259789 A JP2010259789 A JP 2010259789A JP 2010259789 A JP2010259789 A JP 2010259789A JP 2012114537 A JP2012114537 A JP 2012114537A
Authority
JP
Japan
Prior art keywords
ecu
identification information
electronic control
unique number
communication software
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.)
Pending
Application number
JP2010259789A
Other languages
English (en)
Inventor
Yusuke Sato
雄介 佐藤
Hiroya Ando
博哉 安藤
Tomohiko Endo
知彦 遠藤
Maki Kaneda
真貴 金田
Katsutomo Sasakura
克友 笹倉
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.)
Toyota Motor Corp
Original Assignee
Toyota Motor 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 Toyota Motor Corp filed Critical Toyota Motor Corp
Priority to JP2010259789A priority Critical patent/JP2012114537A/ja
Publication of JP2012114537A publication Critical patent/JP2012114537A/ja
Pending legal-status Critical Current

Links

Images

Abstract

【課題】同じ識別情報を有する複数の電子制御装置が車載LANに接続されていても、動的に識別情報を変更できる電子制御装置を提供すること。
【解決手段】車載LANを介して他の装置と接続される電子制御装置100であって、送信メッセージに自機の識別情報を設定する、前記他の装置と共通の通信ソフト13と、予め設定されている自機の固有番号にて、前記通信ソフト13に設定された前記識別情報を変更する固有番号適用手段21と、を有する電子制御装置100を提供する。
【選択図】図2

Description

本発明は、車両ネットワークシステムに接続される電子制御装置等に関し、特に、電子制御装置がIDに基づき通信する電子制御装置、車両ネットワークシステム、通信方法及びプログラムに関する。
車両の電子制御装置は各種の車載装置の動作を制御しているが、電子化の進行により数多くの電子制御装置が搭載されるようになっている。これらの電子制御装置を車載LANにより接続し互いに情報を通信可能とすることでより高度な制御が実現されている。
各電子制御装置には、電子制御装置を識別するためのIDをCANコントローラに設定する通信ソフトが搭載される。通信ソフトの機能は複数の電子制御装置に共通の場合があるので、同じ通信ソフトを複数の電子制御装置に搭載することでコスト削減することが期待できる。しかしながら、通信ソフトが同じであることは通信ソフトが管理するIDも同じになることを意味する。このため以下のような不都合がある。
CANプロトコルの場合、CANコントローラは、CANバスを使用する各電子制御装置の使用権をCAN-IDで調停する。このため、通信ソフトが管理するIDが同じだと調停が困難になる。
図1はCANプロトコルのメッセージのフォーマットの一例を示す。CANコントローラは、「Arbitration Field」に通信ソフトが管理するCAN-IDを設定し、使用権の調停にCSMA/CD(Carrier Sense Multiple Access/Collision Detection)のアクセス制御を使用する。よって、CAN-IDが各電子制御装置で共通だとすると、同じタイミングでフレームを送信した複数のCANコントローラがCANバスの使用権を得てしまう。
しかし、その後のControl Field以降で、あるCANコントローラがリセッシブを送信し、別のCANコントローラがドミナントを送信したタイミングで、どちらのCANコントローラも自身が送信したデータを受信できないことを検知してビットエラーを誤検出する。すると、ビットエラーを検出したCANコントローラは送信未完了が継続し、通信を停止するおそれがある。このため、従来は、IDのために通信ソフトを電子制御装置毎に製造する必要があった。
複数のECUで通信ソフトを共通にする場合、車載LANの各CANコントローラに異なるCAN-IDが設定される仕組みが必要になる。このような仕組みとして、テーブルを利用してIDを変換することが考えられる(例えば、特許文献1参照。)。特許文献1には、制御機器を増設用の通信路に増設した際、増設用の通信路と主通信路の間の中継装置が、予め記憶する主通信路で通信するための識別子と増設用通信路で通信するための識別子とを関連付けて登録した識別子変換テーブルを用いて、増設用の通信路から主通信路に中継するメッセージの識別子を変換する考案が開示されている。
特開2007−196971号公報
しかしながら、特許文献1に開示された中継装置では、同じCAN-IDの電子制御装置のメッセージの識別子は、変換後も同じ識別子になるため、結局、IDの衝突が生じることになる。すなわち、単にテーブルを用意するだけでは、複数の同じCAN-IDの電子制御装置の識別子を、異なる識別子に変えることは困難である。
本発明は、上記課題に鑑み、同じ識別情報を有する複数の電子制御装置が車載LANに接続されていても、動的に識別情報を変更できる電子制御装置、車両ネットワークシステム、通信方法及びプログラムを提供することを目的とする。
本発明は、車載LANを介して他の装置と接続される電子制御装置であって、送信メッセージに自機の識別情報を設定する、前記他の装置と共通の通信ソフトと、予め設定されている自機の固有番号にて、前記通信ソフトに設定された前記識別情報を変更する固有番号適用手段と、を有する電子制御装置を提供する。
同じ識別情報を有する複数の電子制御装置が車載LANに接続されていても、動的に識別情報を変更できる電子制御装置を提供することができる。
CANプロトコルのメッセージのフォーマットの一例を示す図である。 各電子制御装置が元のIDを重複しないIDに変更する手順を模式的に説明する図の一例である。 車載LANの概略構成図の一例である。 スリープ制御又はウェイクアップ制御の手順を模式的に示す図の一例である。 本実施形態のプログラムについて説明する図の一例である。 初期IDの決定手順を示すフローチャート図の一例である。 送信周期の変更手順を示すフローチャート図の一例である。 ECU対応テーブルの一例を示す図である。 ECUがIDを決定する全体的な動作手順の一例を示す図である。 ID及び送信周期の遷移を模式的に示す図の一例である。
以下、本発明を実施するための形態について図面を参照しながら説明する。
図2は、各電子制御装置が元のIDを重複しないIDに変更する手順を模式的に説明する図の一例である。
(1)電子制御装置(以下、ECUという)には、後に説明する共通の通信ソフトが搭載されているので、それぞれ同じIDを有する(図ではECU_A=Na、ECU_A=Nb)。このID(以下、元IDという)はCAN-IDとしてメッセージに設定される。このようにIDとCAN-IDは同じものであるが、説明のため別の用語とした。
また、各ECUは、それぞれが重複しない固有番号を有している(図ではECU_A=12345、ECU_A=12346)。また、各ECUは送信するデータがある場合にメッセージを送信するだけでなく、後述する規格により定期的にメッセージを送信する。以下では、主に定期的に送信する場合を例に説明する。各ECUの通信ソフトは同じなので、送信周期はECU_AとECU_Bのいずれも一例として100ミリ秒とする。
(2)車両の車載LANに初めて電力が供給された場合(例えば、出荷後又はECUが初期化された後、初めてイグニッション・オンされた場合や初めてスタートボタンが押下された場合等)、各ECUは元IDに固有番号の全部又は一部を算術加算する。以下、加算後のIDを初期IDという。
初期ID = Na+12345(の一部)、初期ID = Nb+12346(の一部)
固有番号は重複しないので、元IDに固有番号の全体を加えれば、必ず各ECUのIDを異ならせることができるが、CAN-IDのビット数は上限(多くの場合は11bit)を有しCAN-IDの取り得る範囲に制約があるので、固有番号の一部を加算するとした。算術加算により、まず、各ECUで完全に一致していた元IDが、互いに異なる初期IDになるような処理が施されたことになる(以下、単に「分散させる」という)。
この状態で各ECUはメッセージを送信することができ、この段階で各ECUのCAN-IDが完全に異なっている可能性もある。
(3)次に、各ECUは初期IDが同じ他のECUが存在する可能性を考慮して、メッセージの送信周期を変更する。初期IDが同じECUが同じタイミングでメッセージの送信を開始した場合、上述したようにECUによってはエラーを検知するが、ECUは、そのエラーがIDの重複によるものだということは判定できない。また、元の送信周期が同じなので、単に再送信しただけでは、メッセージが再度、衝突する可能性がある。したがって、初期IDが同じ他のECUが存在する可能性のある状況では、各ECUはメッセージが正しく送受信されているか否かを確定できず、この結果、他のECUと初期IDが重複しているかどうかも判定できない。
そこで、各ECUは、必ず他のECUと送信周期が異なるように送信周期を変更する。具体的には、「送信周期=送信周期+固有番号のn桁目」を新たな送信周期として、メッセージを送信する。これを固有番号の桁数分だけ繰り返すことにより、固有番号は重複しないので、初期IDが同じECUが存在しても、各ECUは必ず1回以上、衝突なしにメッセージを送信できたことになる。
なお、各ECUは、他のECUと初期IDが重複しているか否かを判定するため、元IDを変えた後、送信周期を変え終わるまで、他のECUから受信したメッセージのCAN-IDを不揮発メモリに記録する。
(4)各ECUは不揮発メモリに記憶した他のECUのCAN-IDと自分の初期IDを比較して、一致するIDがある場合、自分の初期IDを使われていないIDに変更する。
以上の手順により、各ECUの通信ソフトが同じでも、数回のメッセージの送信で各ECUのIDを異ならせることができる。したがって、各ECUに同じ通信ソフトを搭載することができ、コストを低減することができる。
なお、各ECUは変更後のIDを記録しておくので、図示する作業は1回だけ行えばよい。したがって、各ECUがIDを設定するまでユーザに待ち時間が発生するなどの不都合も生じない。
〔構成〕
図3は、車載LAN200の概略構成図の一例を示す。各ECU100は、各ECU独自の制御のため異なる構造やアプリ11(区別する場合、アプリA,Bという)を搭載しているが、IDの変更に関する各ECUの構成は同じである。図3では、ECU_AがアプリAを有し、ECU_BがアプリBを有する点で両者の構成が異なっているだけである。すなわち、ECU_AとECU_Bのいずれも同じ通信ソフト13(以下、区別する場合、通信ソフトA、Bという)を有している。
ECU100は、CPU、RAM,EEPROM、NVRAM、I/O等を備えたマイコンである。また、マイコンは、CAN通信のCANコントローラ15、通信ソフト13及び通信ソフト13に組み込まれたプログラム14、を有する。また、図では、NVRAMをメモリ12で表した。このメモリ12には、他のECU100のIDが記憶される。
アプリAは、ECU_Aが必要な制御や処理を行うためのアプリケーションソフトである。アプリBについても同様である。アプリA、アプリBは、ECU_A、ECU_Bに接続されたセンサから信号を取得し、必要な演算や判定を行い、アクチュエータやスイッチを制御する。アプリA,Bは、必要であれば、センサの信号、演算結果を他のECU100にメッセージとして提供する。
ECU_AがHV(ハイブリッド)−ECUの場合は、アプリAは、アクセルペダル開度、ブレーキペダルの踏み込み量、シフトポジション、モータジェネレータを流れる電流値、モータジェネレータの回転速度に基づき、モータジェネレータMG1,MG2の3相コイルに流す電流を決定し、決定した電流値に応じた駆動信号をインバータへ出力する等の処理を行う。
ECU_BがブレーキECUの場合、アプリBは、車速センサが検出する車輪の回転速度からスリップ率を算出し、各輪のスリップ率に応じてASBやTRCなどの処理を行う。この他、車両にはエンジンECU、ボディECU、ナビECU等が搭載されるが、ECU_A、ECU_Bは1つの車載LAN200に接続されたECUであればよい。なお、1つの車載LAN200とは、中継装置(ゲートウェイ)を含めメッセージの送受信が可能な範囲や中継装置を超えない範囲である。車載LANに中継装置を含めるか否かは、通信ソフト13の共通性やメッセージの衝突の可能性を考慮して決定する。
アプリAはECU_Aの固有番号を保持し、アプリBはECU_Bの固有番号を保持している。具体的には、アプリAとアプリBのコードに固有番号が記述されている。アプリA,Bのコードでなくメモリ12に記憶しておくこともできる。固有番号を通信ソフト13以外に記憶させることで、各ECU100で同じ通信ソフト13を使用できる。
固有番号は、例えば、ECU100の品番、型番など、各ECU100で重複しない番号であればよい。品番や型番は、そのECU100がHV−ECUであることやブレーキECUであることを特定する番号なので、同種のECU100は1つの車載LAN200に1つしか搭載されないことを前提とすると、各ECU100の固有番号が異なっているとみなすことができる。
この他、例えば、各ECU100に重複しない識別番号を付与する特定のECUが車載LAN200に接続されている場合、この特定のECUが各ECU100に割り当てる識別番号を固有番号とすることもできる。
通信ソフト13は、アプリA又はアプリBが送信要求したデータをCANコントローラ15のバッファに設定するプログラムである。CANプロトコルでは、図1のフォーマットのメッセージを送信するので、通信ソフト13は、アプリA又はアプリBからデータの送信要求を受け付けると、「Start of Frame」に1 ビットのドミナントを、CAN-IDに上記のようにして決定したIDを、「Control Filed」にデータフィールド内のデータのバイト数を、「Data
Field」にデータを、「CRC Field」にCRC符号を、「ACK」に1ビットのリセッシブ(送信の場合)を、「End of Frame」 に7 ビットのリセッシブを、それぞれ設定する。送信ソフト13がこのようなメッセージをCANコントローラ15の送信バッファに記憶すると、CANコントローラ15がトランシーバ16を介してCANバスから送信を開始する。
また、通信ソフト13は、OSEK/VDX(Offene Systeme und deren schnittstellen fur die Elektronik im Kraftfahrzeug/Vehicle Distributed eX ecutive)仕様のOSEK/VDX―NM(Network Management)の規定に基づく通信を行うが、この通信については後述する。
CANコントローラ15は、CANの通信プロトコルに従って、送信バッファのメッセージをシリアルの送信信号に変換してトランシーバ16に出力する。すなわち、メッセージが“0”のビットには論理レベルがLowの電圧を、メッセージが“1”のビットには論理レベルがHighの電圧を出力する。
トランシーバ16はCANコントローラ15から取得した論理レベルの送信信号を対応する差動電圧に変換してCANバスに送信する。CANバスは各ECU100に接続されているので、各ECU100がメッセージを取得することができる。送信時、CANコントローラ15はCSMA/CDに基づきメッセージの衝突を検出している。
データの受信時、トランシーバ16はCANバスの差動電圧を読み取り、所定の電圧範囲に含まれるように整形した受信信号を、CANコントローラ15に出力する。CANコントローラ15の受信用の端子はコンパレータを有しており、所定の閾値電圧とトランシーバ16からの受信信号とを比較して“1”、“0”のデジタルデータを生成して受信バッファに記憶する。
CANプロトコルでは、各ECU100が同じ1つのメッセージを受信してしまうので、通信ソフト13又はアプリ11がIDに基づき受信すべきメッセージを取捨している(以下、通信ソフト13が取捨しているとする)。各ECU100にとって必要なメッセージはCAN-IDによりECU毎に定められている。
ところが、本実施形態では元IDが各ECU100で同じであり、その後、変更されるため、予め通信ソフト13に受信すべきCAN-IDを設定しておくことが困難になっている。このため、本実施形態では、図2の処理にてIDを決定する際、各ECU100が他のECU100の固有番号とIDを特定しておき、変更後のIDに基づきメッセージを取捨できるようにする。この処理の詳細は後述する。
プログラム14は、図2にて説明した処理(ソフト的処理)を実行する。プログラム14も各ECU100に共通である。図ではプログラム14が通信ソフト13に含まれるように記載したが、プログラム14はアプリ11に含まれる形でECU100に搭載することもできるし、通信ソフト13及びアプリ11に独立に搭載することもできる。プログラム14の機能については後述する。
〔OSEK−NM〕
OSEK−NMでは、1つの車載LAN200に接続された各ECU100が、自ECU100のスリープ可否を判別して、そのスリープ可否を示すNM(Network Management)メッセージを定期的にネットワークバスへ送信する。通信ソフト13はこのOSEK−NMに基づく通信処理も行う。なお、NMメッセージはCANのメッセージの一表現に過ぎず、フォーマットや送信手順はCANプロトコルに従うが、周期的に送信されるなどの特徴があるのでOSEK−NMに基づくメッセージをNMメッセージという。
OSEK−NMには各ECU100の動作モードとしてスリープモードとウェイクアップモード等が定義されている。スリープモードは、例えば、CPUに供給するクロックを最小限に小さくしたり、電力が供給されるチップを最小限にするモードである。ECU100は、車両のIG(イグニション)=OFF時において、IG=ON、ドア開、リモート制御用の電波信号受信、他のECU100からのバスエッジ受信などのイベントが長期間検知されない場合、スリープモードになる。また、スリープモードにおいてイベント発生が検知された場合、スリープモードを解除して、電源供給を受けて初期化を行い起動しウェイクアップモードになる。
1つの車載LAN200では各ECU100が通信することで処理を実行したり、正常/異常判定を行ったりするので、OSEK−NMでは各ECU100が協調してスリープ制御及びウェイクアップ制御を行うようになっている。
図4は、スリープ制御又はウェイクアップ制御の手順を模式的に示す図の一例である。各ECU100は、スリープが可能か否かの判定結果を定期的にNMメッセージに記述して送信する。図示するように、ECU_A〜ECU_Cは、順番にNMメッセージを送信する。この順番は予め定められており、ECU_AはECU_Bに、ECU_BはECU_Cに、ECU_CはECU_Aに、NMメッセージを送信する。そしてこの送信周期が上記のように各ECU100に共通に定められている。
したがって、各ECU100は、最後にNMメッセージを送信した時から送信周期が経過するとスリープが可能か否かの判定を行い、スリープ可否を示すNMメッセージを送信する。送信周期が各ECU100に共通の場合、NMメッセージを1回受信する度に、NMメッセージを1回送信することになる。各ECU100の送信周期が異なると、NMメッセージの受信と送信の頻度は一致しないが、各ECU100は、他のECU100からのNMメッセージの受信のタイミングに関係なく、送信周期に従ってNMメッセージを送信すればよい。
各ECU100は、NMメッセージを受信すると、各ECU毎にスリープ可否か否かを各ECU100に対応したフラグのON/OFFにて記録する。そして、全てのECU100がスリープ可になると、各ECU100はスリープモードへ移行する処理を開始する。
スリープモードになるまで各ECU100は周期的にNMメッセージを送信するはずなので、各ECU100はNMメッセージの受信有無により他のECU100の正常/異常判定を行うことができる。
また、スリープモードにおいていずれかのECU100がイベントを検出すると、まずそのECU100が起動する。起動したECU100はウェイクアップ要求を含むNMメッセージを予め定められた他のECU100に送信する。ウェイクアップ要求を受信したECU100が起動すると、ウェイクアップ要求を含むNMメッセージを予め定められた他のECU100に送信するので、車載LAN200の各ECU100が起動することができる。
〔プログラム〕
図5を用いて、本実施形態のプログラム14について説明する。通信ソフト13はCPUがプログラム14を実行することで得られる、ID算出部21、送信周期変更部22、ID管理部24、ID決定部23及びID記録部26を有する。また、ECU対応テーブル25は、プログラム14に定数として記述されている。
ID算出部21は、通信ソフト13から元IDを、アプリ11から固有番号をそれぞれ取得し、元IDに固有番号の一部を加算して初期IDを決定する。ここで、元IDは、CANプロトコルのフォーマットの「Arbitration Filed」の桁数の制約と、車両メーカの仕様上の制約を受ける。「Arbitration Filed」は例えば11ビットであるので、この上限を超えることはできない。また、車両メーカは、CAN-IDがある範囲に入るように定めることでECU100の管理を容易にしている。
このため、ID算出部21は仕様上の範囲に入るように、通信ソフト13から取得した元IDに固有番号の一部を加算する。なお、通信ソフト13の元IDは例えば、車両メーカのCAN-IDの仕様上の範囲の中央値又は中央値に近くなるように定められている。
図6は、初期IDの決定手順を示すフローチャート図の一例である。まず、ID算出部21は、通信ソフト13から元IDを、アプリ11から固有番号をそれぞれ取得する(S10)。
ID算出部21は、固有番号の全体の桁数nを特定する(S20)。桁数nは例えば十進数表記の桁数である。また、固有番号に「−(ハイフン)」が含まれている場合、ハイフンを取り除いて桁数nを求める。また、固有番号にアルファベットが含まれている場合、アルファベットをアルファベットに応じて予め定められた別の数字(例えばアルファベット順の下一桁)に置き換える。または、アルファベットを無視してもよい。
次に、ID算出部21は、元IDに固有番号の上位n桁を加える(S30)。最初のnは全桁数なので、1度目の加算では固有番号の全体が元IDに加算され、各ECU100のIDを必ず異ならせることができる。
そして、ID算出部21は、固有番号の加算後のIDが仕様上の範囲に入っているか否かを判定する(S40)。入っている場合は(S40のYes)、ID算出部21は現在のIDを初期IDとして決定する(S50)。
固有番号の加算後のIDが仕様上の範囲に入っていない場合(S40のNo)、ID算出部21はn桁を1つ減らす(S60)。この後、処理はステップS30に戻るので、ID算出部21は、IDに固有番号の上位n桁を加えることになる。こうすることで、固有番号から抽出する桁数を少なくできるので、いずれは必ずIDが仕様上の範囲に入るようになる。
初期IDが決定するとID算出部21は通信ソフト13に初期IDを設定して処理を終了する(S70)。
なお、ステップS30でID算出部21は上位n桁を抽出するが、下位n桁でもよいし、中央の桁からn桁でもよい。また、ステップS30では元IDに固有番号の上位n桁を加えているが、元IDから固有番号の上位n桁を減算してもよい。
図5に戻り、送信周期変更部22は、通信ソフト13から送信周期を、アプリAから固有番号をそれぞれ取得し、送信周期に、固有番号のn桁目を加算して新たな送信周期とする。n桁の全てを順番に加算することで、必ず1回は他のECU100と異なる送信周期で送信することができる。
図7は、送信周期の変更手順を示すフローチャート図の一例である。まず、送信周期変更部22は、通信ソフト13から送信周期を、アプリAから固有番号をそれぞれ取得する(S110)。
次に、送信周期変更部22は、固有番号の全体の桁数nを特定する(S120)。桁数nの決定方法は上記のとおりである。
次に、送信周期変更部22は、送信周期に固有番号のn桁目を加える(S130)。n桁は最下位桁から数えても、最上位桁から数えてもよい。そして、通信ソフト13に変更後の送信周期を設定する(S140)。これにより、通信ソフト13は、変更後の送信周期で1回以上、NMメッセージを送信することができる。
送信周期変更部22は、通信ソフト13がNMメッセージを送信するまで待機し(S150)、送信すると、送信周期変更部22はnを1つ減らす(S160)。そして、nが“0”になったか否かを判定する(S170)。
nが“0”になった場合(S170のYes)、n桁の全てを送信周期に加算したことになるので、送信周期変更部22は処理を終了する。nが“0”になっていない場合(S170のNo)、処理はステップS130に戻り、送信周期に固有番号のn桁目を加える処理を行う。
したがって、n桁の全てを加算したことで、通信ソフトAは他のECU100と異なる送信周期で送信することができた。なお、図7の処理の後、または、図7の処理に変えて、固有番号の2桁以上を送信周期に加算してもよい。すなわち、上位又は下位から2桁ずつを取り出し送信周期に加算する。同様に、3桁、4桁…を送信周期に加算することもできる。しかし、あまり大きい数値を加算すると送信周期が長くなり、IDの決定までに時間がかかることになるので、2桁まで加算することが好適となる。
また、固有番号のn桁目を送信周期に加算するのでなく、減算してもよい。元の送信周期が100ミリ秒だとすると固有番号の1桁を送信周期から減算しても、送信周期が負値となることはなく、IDの決定までの時間を短縮できる。
図5に戻りID記録部26は、図6,7の処理の間に受信したNMメッセージに基づきCAN-IDを記録する。例えば、メモリ12には、受信したCAN-IDとして「123,457,789…」のように記録される。
ID決定部23は、ID算出部21が決定した初期IDが、ID記録部26が記録した他のECU100のCAN-IDに一致するものがあるか否かを判定し、他のECU100のCAN-IDに一致するものがある場合、使われていないCAN-IDを最終的なIDに決定する。IDの決定方法には、使われている最も大きいCAN-IDに所定値を加える方法、使われている最も小さいCAN-IDから所定値を減算する方法、自ECUの初期IDと一致したCAN-IDにランダムな値を加える/減算する方法、等がある。なお、同じCAN-IDを有する2つのECUは同時にメッセージを送信できないので(いずれも通信を停止する)、2つのECUが同時にCAN-IDが重複すると判定することはない。したがって、先に重複を検出したECUのID決定部23がIDを変更すればよい。
各ECUのID決定部23がこのようにしてIDを交換することで、各ECUのIDが重複しないIDとなるが、これだけでは各IDがどのECUのIDかを各ECUが特定できない。そこで、ID管理部24は、最終的に決定したIDと自ECUの固有番号を他のECU100に通知する。通知のタイミングは図7の手順の後でもよいし、図6,7の手順と並行に通知することもできる。すなわち、OSEK−NMの規格上、NMメッセージにスリープ可否だけでなく固有番号を含めることができれば、図6,7の手順と並行に通知すればよい。
IDと固有番号の対応を受信した他のECU100のID管理部24は、下記のように他のECU100のIDと固有番号を記録する。なお、ECU_A〜Dのような名称は実際には送受信されない。
ECU_A(7821−123):123
ECU_B(8610−123):456
ECU_C(8615−123):789
ECU_D(8810−123):987
こうすることで、ID管理部24は、各ECUとIDの対応を特定することができる。このIDは車載後に決まったので、IDとECU100の対応付けを利用して、ID管理部24は通信ソフト13が受信すべきメッセージを特定する。このため、本実施形態ではECU対応テーブル25を利用する。
図8は、ECU対応テーブル25の一例を示す図である。ECU対応テーブル25には、左側のECU100が受信すべきメッセージの送信元のECU100が「○」で登録されている。ECU対応テーブル25のECU100は固有番号にて記述されているか、又は、少なくとも固有番号を含んでいる。図8によればECU_AはECU_BとECU_Dのメッセージを受信する必要があり、ECU_BはECU_AとECU_CとECU_Dのメッセージを受信する必要があり、ECU_CはECU_AとECU_Bのメッセージを受信する必要があり、ECU_DはECU_Cのメッセージを受信する必要がある。なお、各ECU100のID管理部24は、自ECU100がどのECU100であるかは、アプリ11から取得する固有番号により判定できる。
ID管理部24は、自ECUの固有番号に基づきECU対応テーブル25から、メッセージを受信すべきECU100の固有番号を特定する。そして、ID管理部24が記録した他のECU100のIDと固有番号の対応から、メッセージを受信すべきECU100のIDを特定し通信ソフト13に通知する。例えば、ECU_AのID管理部24なら、ECU_BとECU_Dを意味するID456と789を通信ソフト13に通知する。
なお、ECU対応テーブル25を有さないECUは、IDの上位数桁を固定し、その範囲に含まれるIDを持つECUであれば受信する、という規則で受信すべきメッセージを特定することができる。よって、ECU対応テーブル25は必ずしも必須ではない。
〔全体の動作手順〕
図9は、ECU100がIDを決定する全体的な動作手順の一例を、図10はID及び送信周期の遷移を模式的に示す図の一例である。
ECU100が起動すると、通信ソフト13は重複しないIDが決定されているか否かをフラグなどで判定し、決定されていない場合、プログラム14にIDの決定を要求する。図9の手順は、例えばこのようにして開始される。なお、以下ではNMメッセージにECUの固有番号を含めるとした。
まず、ID算出部21は、図6の手順を実行しIDに固有番号を加算して初期IDを加算する(S310)。通信ソフトAは初期IDを用いて、例えばNMメッセージの周期的な送信を開始する(S320)。他のECU100も同様に送信を開始するので、ID記録部26は、他のECU100から受信したメッセージのIDとメッセージに含まれる固有番号を記録する。
次に、送信周期変更部22は、図7の手順を実行して、送信周期に固有番号のn桁目を加算してメッセージを送信する(S330)。
通信ソフトAは、他のECU100から送信されたメッセージを受信する(S340)。ID記録部26は、他のECU100から受信したメッセージのIDとメッセージに含まれる固有番号を記録する。
次に、ID決定部23は、自ECUの初期IDが他のECUのIDに一致するか否かを判定する(S350)。一致する場合(S350のYes)、ID決定部23は、初期IDを使われていないIDに変更する(S360)。
この後、処理はステップ330に戻り、必ず重ならない送信周期でNMメッセージが送信されるまで継続する。ID記録部26はその間に記録したIDと固有番号の対応をID管理部24に通知し、ID管理部24はECU対応テーブル25に基づき通信ソフト13に、受信すべきIDを通知する。
図10を用いて説明する。図10では、ECU_Aの固有番号が7821-123、ECU_Bの固有番号が8610-123、ECU_Cの固有番号が8615-123、ECU_Dの固有番号が8810-123である。ECU_B〜Dの元IDは410であり、送信周期は100ミリ秒である。
ECU_Aには通信ソフトAが搭載されているが、ECU_B〜Dには通信ソフトBが搭載されている。通信ソフト13が異なるとIDも異なるので、図10ではECU_B〜DのIDを変更すればよい。実際には、ECU_B〜Dは同じ車載LAN200に接続されているECU_Aからもメッセージを受信しているので、ECU_AのIDと重複しないように自ECUのIDを決定する。
図10の1回目の送信が、ステップS320の送信に対応する。初期IDを決定するため、各ECUは固有番号の上位2桁を元IDに加算するとする。よって、ECU_Bは410+86=496を、ECU_Cは410+86=496を、ECU_Dは410+88=498を、それぞれ初期IDとする。ECU_B〜Dは少なくとも1回以上、NMメッセージを送信する。この時の送信周期は100ミリ秒である。
図10の2、3…回目の送信が、S330の送信に対応する。例えば、固有番号の上位から3桁目を送信周期に加算した場合、ECU_Bの固有番号8610-123の上位から3桁目は「1」なので、ECU_Bの送信周期は100+1=101ミリ秒となる。ECU_Cの固有番号8615-123の上位から3桁目は「1」なので、ECU_Cの送信周期は100+1=101ミリ秒となる。ECU_Dの固有番号8610-123の上位から3桁目は「1」なので、ECU_Dの送信周期は100+1=101ミリ秒となる。ECU_B〜Dは少なくとも1回以上、この送信周期でNMメッセージを送信する。
次の送信タイミングでは、固有番号の上位から4桁目を送信周期に加算する。このため、ECU_Bの送信周期は101+0=101ミリ秒となる。ECU_Cの送信周期は101+5=106ミリ秒となる。ECU_Dの送信周期は101+0=101ミリ秒となる。ECU_B〜Dは少なくとも1回以上、この送信周期でNMメッセージを送信する。固有番号に基づき送信周期を変えてNMメッセージの送信を繰り返すことで、少なくとも1回はECU_B〜Dは他のECUのNMメッセージを衝突なしに受信することができる。
すると、例えば、ECU_Cは、ECU_BとIDが496で一致していることを検知できるので、初期ID=496を、ECU_BやECU_Dが使用していないIDに変更する。例えば、ECU_Bの初期ID=496に所定値3を加えて、初期IDをID=499に変更する。
この後、各ECUは送信周期を元の100ミリ秒に戻してもよい。送信周期を変更したのは、衝突なしに各ECUのIDを受信するためだから、重複しないIDが決定された後は送信周期が共通でもよいからである。また、送信周期を共通にすることで、OSEK/VDX―NMの仕様が送信周期が共通であることを要求する場合に、その要求を満たすことができる。
以上説明したように、本実施形態のECU100は、車載LAN200上で重複しないIDを自動的に決定するので、各ECU100が同じ通信ソフトAを搭載することができ、コスト低減が可能になる。IDの変更に固有番号を利用するので、他のECU100と重複しないIDを見いだしやすい。また、送信周期の変更に固有番号を利用するので、他のECU100と重複しない送信周期に設定でき、IDが重複しているか否かを判定することができる。そして、重複している場合には重複しないIDに決定することができる。
11 アプリ
12 メモリ
13 通信ソフト
14 プログラム
15 CANコントローラ
16 トランシーバ
21 ID算出部
22 送信周期変更部
23 ID決定部
26 ID記録部
100 ECU
200 車載LAN

Claims (12)

  1. 車載LANを介して他の装置と接続される電子制御装置であって、
    送信メッセージに自機の識別情報を設定する、前記他の装置と共通の通信ソフトと、
    予め設定されている自機の固有番号にて、前記通信ソフトに設定された前記識別情報を変更する固有番号適用手段と、
    を有する電子制御装置。
  2. 予め設定されている自機の固有番号にて、前記通信ソフトに設定された送信メッセージの送信周期を変更する送信周期変更手段を有し、
    前記通信ソフトは変更後の送信周期にて送信メッセージを送信する、
    を有することを特徴とする請求項1記載の電子制御装置。
  3. 前記他の装置から受信した受信メッセージに含まれる前記他の装置の前記識別情報と、自機の前記識別情報を比較して、自機の前記識別情報を前記他の装置が使用していない前記識別情報に変更する識別情報決定手段、
    を有することを特徴とする請求項2記載の電子制御装置。
  4. 前記固有番号適用手段は、前記通信ソフトに設定された前記識別情報に対し、前記固有番号の全部又は桁数の一部を用いた算術処理を施して前記通信ソフトに設定された前記識別情報を変更する、ことを特徴とする請求項1〜3いずれか1項記載の電子制御装置。
  5. 前記固有番号適用手段は、前記固有番号の全体を用いて前記識別情報に対する算術処理を開始し、算術処理された前記識別情報が予め定められた前記識別情報の許容範囲に入らない場合、前記固有番号から取り出す桁数を徐々に減らして算術処理と前記許容範囲に入るか否かの判定を繰り返す、ことを特徴とする請求項4記載の電子制御装置。
  6. 前記送信周期変更手段は、前記固有番号の上位桁又は下位桁から所定数の桁を取り出し、前記送信周期に加えること又は前記送信周期から減らすことで前記送信周期を変更し、
    前記固有番号の全ての桁を取り出すまで、前記送信周期の変更を繰り返す、
    ことを特徴とする請求項2又は3記載の電子制御装置。
  7. 前記他の装置から受信した受信メッセージに含まれる前記他の装置の前記識別情報と、前記他の装置の固有番号を対応づけて記録する識別情報記録手段と、
    受信メッセージを受信すべき前記他の装置の固有番号が予め登録された登録テーブルと、
    前記登録テーブルに登録された前記他の装置の固有番号に基づき、受信メッセージを受信する前記他の装置の前記識別情報を前記通信ソフトに指示する識別情報管理手段と、
    を有することを特徴とする請求項1〜6いずれか1項記載の電子制御装置。
  8. 前記通信ソフトは、OSEK/VDX−NMの仕様に基づき、定期的に送信メッセージを送信する、ことを特徴とする請求項1〜7いずれか1項記載の電子制御装置。
  9. 前記固有番号は、当該電子制御装置又は前記他の装置の品番又は型番である、ことを特徴とする請求項1〜8いずれか1項記載の電子制御装置。
  10. 車載LANを介して複数の電子制御装置が接続された車両ネットワークシステムであって、
    各電子制御装置が、送信メッセージに自機の識別情報を設定する、前記他の電子制御装置と共通の通信ソフトと、
    予め設定されている自機の固有番号にて、前記通信ソフトに設定された前記識別情報を変更する固有番号適用手段と、
    を有する車両ネットワークシステム。
  11. 車載LANを介して他の装置と共通の通信ソフトにより通信する電子制御装置の通信方法であって、
    固有番号適用手段が、予め設定されている自機の固有番号にて、前記通信ソフトに設定されている識別情報を変更するステップと、
    前記通信ソフトが、自機の識別情報を設定して送信メッセージを送信するステップと、を有する電子制御装置の通信方法。
  12. 車載LANを介して他の装置と共通の通信ソフトにより通信する電子制御装置のCPUに、
    予め設定されている自機の固有番号を取得するステップと、
    前記通信ソフトに設定されている識別情報を、前記固有番号にて変更するステップと、
    前記通信ソフトに変更後の前記識別情報を設定するステップと、
    を実行させるプログラム。
JP2010259789A 2010-11-22 2010-11-22 電子制御装置、車両ネットワークシステム、通信方法、プログラム Pending JP2012114537A (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2010259789A JP2012114537A (ja) 2010-11-22 2010-11-22 電子制御装置、車両ネットワークシステム、通信方法、プログラム

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2010259789A JP2012114537A (ja) 2010-11-22 2010-11-22 電子制御装置、車両ネットワークシステム、通信方法、プログラム

Publications (1)

Publication Number Publication Date
JP2012114537A true JP2012114537A (ja) 2012-06-14

Family

ID=46498302

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2010259789A Pending JP2012114537A (ja) 2010-11-22 2010-11-22 電子制御装置、車両ネットワークシステム、通信方法、プログラム

Country Status (1)

Country Link
JP (1) JP2012114537A (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014011621A (ja) * 2012-06-29 2014-01-20 Toyota Motor Corp 通信システム
US10050983B2 (en) 2015-11-13 2018-08-14 Kabushiki Kaisha Toshiba Communication system, receiving apparatus, receiving method, and computer program product
CN109204188A (zh) * 2017-07-03 2019-01-15 矢崎总业株式会社 设定装置和计算机

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2014011621A (ja) * 2012-06-29 2014-01-20 Toyota Motor Corp 通信システム
US10050983B2 (en) 2015-11-13 2018-08-14 Kabushiki Kaisha Toshiba Communication system, receiving apparatus, receiving method, and computer program product
CN109204188A (zh) * 2017-07-03 2019-01-15 矢崎总业株式会社 设定装置和计算机

Similar Documents

Publication Publication Date Title
CN105981336B (zh) 不正常检测电子控制单元、车载网络系统以及不正常检测方法
US11570184B2 (en) In-vehicle network system, fraud-detection electronic control unit, and fraud-detection method
US10609049B2 (en) Method for sensing fraudulent frames transmitted to in-vehicle network
US20200136993A1 (en) Method and apparatus for allocating transmission opportunities in vehicle network
JP5363379B2 (ja) 通信システム
US10153825B2 (en) Vehicle-mounted control device
JP6255072B2 (ja) 半導体装置
JP4766160B2 (ja) 通信システムおよび通信ノード
US11171807B2 (en) Method and apparatus for allocating priority transmission opportunities in vehicle network
WO2014078678A1 (en) Failsafe communication system and method
CN113093687B (zh) 一种基于域控制器的故障诊断系统和方法
US11016925B2 (en) Protocol-tolerant communications in controller area networks
JP2008290666A (ja) 電子制御装置
JP5286659B2 (ja) 車載装置中継システム、車載装置中継方法及び中継装置
US11616843B2 (en) Method and apparatus for operating communication node using network management function in vehicle network
JP2019139315A (ja) 車載通信システム
JP2012114537A (ja) 電子制御装置、車両ネットワークシステム、通信方法、プログラム
US11671269B2 (en) Method for operating a sensor arrangement in a motor vehicle on the basis of a DSI protocol
JP2005145262A (ja) 車載用lanシステム
JP7151930B2 (ja) 中継装置、通信ネットワークシステム及び通信制御方法
JP7347391B2 (ja) 通信装置
Khan Design of a High Efficiency In-Vehicle Network with a Single ECU for a Network (SEN)
JP2009071773A (ja) 中継接続ユニット
JP2014187545A (ja) 通信システム、及び監視通信ノード並びに監視方法