[go: up one dir, main page]

JP5987761B2 - 診断システム、当該診断システムを構成する診断装置及びecu - Google Patents

診断システム、当該診断システムを構成する診断装置及びecu Download PDF

Info

Publication number
JP5987761B2
JP5987761B2 JP2013079555A JP2013079555A JP5987761B2 JP 5987761 B2 JP5987761 B2 JP 5987761B2 JP 2013079555 A JP2013079555 A JP 2013079555A JP 2013079555 A JP2013079555 A JP 2013079555A JP 5987761 B2 JP5987761 B2 JP 5987761B2
Authority
JP
Japan
Prior art keywords
data
ecu
ecus
transmitted
control information
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
JP2013079555A
Other languages
English (en)
Other versions
JP2014204314A (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.)
Denso Corp
Original Assignee
Denso 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 Denso Corp filed Critical Denso Corp
Priority to JP2013079555A priority Critical patent/JP5987761B2/ja
Publication of JP2014204314A publication Critical patent/JP2014204314A/ja
Application granted granted Critical
Publication of JP5987761B2 publication Critical patent/JP5987761B2/ja
Active legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Landscapes

  • Small-Scale Networks (AREA)

Description

本発明は、CAN(Controller Area Network )などのネットワーク規格で接続されるECUへのデータ送信技術に関する。
車両内には、複数のECUが搭載される。当該ECU同士は、CANなどのネットワーク規格で接続されており、データの送受信を行う。例えばCANでは、8バイトのデータが1フレームとしてバスラインを伝送される。
このとき、バスラインに診断装置を接続して、各ECUの故障などを診断することが行われている。特に診断に関してはISO(国際標準化機構)によってISO15765が発行されており、ISO15765−2の基準の第2部には、伝送プロトコルに関して詳細な説明がなされている。そのため、この基準を前提とした種々の提案が行われている(例えば、特許文献1参照)。
特許第4448029号公報
ところで、伝送するデータのデータ長がCANの1フレームに収まる場合は、診断装置から各ECUへの個別のデータ送信(以下「ユニキャスト通信」という)も、全てのECUへのデータ送信(以下「ブロードキャスト通信」という)も、ISO15765−2に規定されている。一方、伝送するデータのデータ長がCANの1フレームに収まらない場合は、データをセグメント化して複数フレームにて送信するのであるが、ユニキャスト通信は規定されているものの、ブロードキャスト通信に関してはISO15765−2に規定がない。
そのため、従来、セグメント化されたデータを全てのECUへ送信する場合、ユニキャスト通信によって実現している。
しかしながら、各ECUに対して順番にデータを送信することになるため、通信時間が大きくなってしまう。したがって、例えば車両工場において複数台の車両の診断を順に行う場合など、その診断に要する時間が大きくなってしまっていた。また、各ECUに対して順番にデータを送信することになるため、各ECUでの受信完了時刻が異なり、当該データを同時期に渡すことができない。
本発明は、上述した課題を解決するためになされたものであり、その目的は、セグメント化されたデータを全てのECUへ送信する場合でも、通信時間を抑えることが可能で、しかも同時期にデータ送受信を完了させることが可能な診断システムを提供することにある。
上記目的を達成するためになされた本発明の診断システム(1)は、セグメント化されたデータをブロードキャスト通信にて診断装置(10)から当該診断装置にバスライン(40)を介して接続される複数のECU(21,22,23)へ送信する。
ここで特に、診断装置では、開始情報送信手段(10a)が、データ伝送の開始を示す開始情報(FF)を送信する。
開始情報送信手段にて送信される開始情報を受信すると、ECUの制御情報送信手段(21a)が、フロー制御情報(FC)を送信する。フロー制御情報には、受信可能か否かを示す情報(FS)、連続受信可能なデータ数を示す情報(BS)、及び、連続受信における受信可能間隔を示す情報(STmin)が含まれているという具合である。
診断装置では、データ送信手段(10b)が、ECUから送信されてくるフロー制御情報に基づき、当該フロー制御情報に含まれる情報の最低値を採用することで、複数のECUの全てにおいて受信可能な態様でデータを繰り返し送信する。なお、各ECUがそれぞれフロー制御情報を送信してもよいし、ある特定のECUがフロー制御情報を送信してもよい。
これに対し、ECUでは、データ受信手段(21b)が、データ送信手段にて送信されるデータを受信する。
つまり、ECUからフロー制御情報が送信されるため、当該フロー制御情報に含まれる各種情報の最低値を採用することで、複数のECUの全てに同時期にデータを送信するのである。このようにすれば、セグメント化されたデータを全てのECUへ送信する場合でも通信時間を抑えることができる。しかも同時期にデータ送受信を完了させることができる。
なお、本発明は、診断システムを構成する診断装置(10)及びECU(21〜23)に特徴を有するものであるため、診断装置やECUの発明として実現してもよい。
診断システムの概略構成を示すブロック図である。 セグメント化されたデータを送信する際の課題を示す説明図である。 FCの内容を示す説明図である。 FS、BS、STminの最低値を採用することを示す説明図である。 第1実施形態の送信処理の前半部分を示す説明図である。 第1実施形態の送信処理の後半部分を示す説明図である。 第1実施形態の受信処理の前半部分を示す説明図である。 第1実施形態の受信処理の後半部分を示す説明図である。 第2実施形態の送信処理の前半部分を示す説明図である。 第2実施形態の送信処理の後半部分を示す説明図である。 (a)は第2実施形態の特定ECU受信処理を示す説明図であり、(b)は第2実施形態の受信処理を示す説明図である。 ユニキャスト通信による通信の課題を示す説明図である。
以下、本発明の実施形態を図面に基づいて説明する。
[第1実施形態]
図1に示すように、本実施形態の診断システム1は、診断装置10と、複数のECU21,22,23と、ゲートウェイECU30と、各ECU21〜23を接続するバスライン40を備えている。
診断装置10は、車両外部に接続されるいわゆるコンピュータとして構成されており、CPU、ROM、RAM、I/O及びこれらを接続するバスラインを含む。外部のセンタ90とのデータ通信が可能となっており、必要な情報をセンタ90へアップロードしたり、センタ90からダウンロードしたりする。また、センタ90からの遠隔操作も可能である。なお、診断装置10は、開始情報送信手段10a及びデータ送信手段10bとして機能する。また、診断装置10が車両内部に接続される場合もある。例えばナビECU等の一部となるという具合である。さらにまた、ゲートウェイECU30と診断装置10とがCAN以外の通信プロトコル(Ethernet(登録商標)等)で接続され、ゲートウェイECU30が開始情報送信手段10a及びデータ送信手段10bとして機能する場合もある。したがって、この場合、ゲートウェイECU30が特許請求の範囲の「診断装置」に相当する。
ECU21〜23は、車両に搭載されるものであり、例えばエンジンECU、ナビECU、ブレーキECUなどとして具現化される。なお、本実施形態では、説明を煩雑にしないために3つのECU21〜23を備える構成としたが、さらに多くのECUを備えているのが一般的である。なお、以下では、各ECU21〜23を区別する場合、図1中の記号を用いて、A−ECU21、B−ECU22、C−ECU23と記述する。なお、A−ECU21は、制御情報送信手段21a及びデータ受信手段21bとして機能する。B及びCのECU22,23も同様の手段を備えている。
ゲートウェイECU30は、車両外部の診断装置10を接続するための構成であり、プロトコル変換を行う。
バスライン40はA〜Cの各ECU21〜23を接続するものであり、バスライン40上のデータはCANのネットワーク規格で伝送される。
このような構成により、診断装置10から各ECU21〜23へ診断要求としてのデータを送信し、これに対し各ECU21〜23が送信してくるデータによって診断を行うことが可能となる。
次に、本実施形態に対する理解を容易にするため、繰り返しになるが、従来の課題をここで述べる。
伝送するデータのデータ長がCANの1フレームに収まる場合は、ユニキャスト通信もブロードキャスト通信もISO15765−2に規定されている。ところが、伝送するデータのデータ長がCANの1フレームに収まらない場合は、データをセグメント化して複数フレームにて送信するのであるが、ユニキャスト通信は規定されているものの、ブロードキャスト通信に関してISO15765−2に規定がない。
そのため、従来、セグメント化されたデータを全てのECUへ送信する場合、ユニキャスト通信によって実現している。このとき、ユニキャスト通信によってセグメント化されたデータを送信する場合には、通信に要する時間が長くなってしまうという課題があった。また、通信完了時刻がそれぞれ異なるものになるため、同一のデータを同時に渡すことができなかった。
具体的には図12に示すように、診断装置からX及びYの2つのECUへセグメント化されたデータを送信することを考える。ユニキャスト通信では、まず一方のX−ECUへデータを送信し、次に同一のデータをY−ECUへ送信することになる。
ここではまず、診断装置がFF(First Frame )をX−ECUへ送信する。FFは、送信の開始を示す開始情報である。これに対し、X−ECUがFC(Flow Control)を送信してくる。FCは、X−ECUにおけるデータ受信に関するフロー制御情報である。詳しくは後述する。
次に、診断装置は、X−ECUからのFCに基づいて、CF(Consecutive Frame )を繰り返し送信する。そして、データ送信が完了すると、X−ECUからSF(Single Frame)で応答が得られる。
次に診断装置は、X−ECUへのデータ送信と同様の手順で、Y−ECUへのデータ送信を行う。
したがって、このようなユニキャスト通信では、通信に要する時間が長くなってしまう。また、データ送信の完了時刻がT1、T2という具合に異なるものになるため、同一のデータを同時に渡すことができない。
そこで本実施形態では、図2に示すように、セグメント化されたデータを送信する場合であっても、ブロードキャスト通信を行うようにした。なお、図2では、説明を簡単にするため、A及びBの2つのECU21,22へのデータ送信について考える。
診断装置10は、最初に、A及びBの2つのECU21,22へFFを送信する。これに対し、A及びBの各ECU21,22は、それぞれFCを送信してくる。ところが、これらのFCの内容が異なっている場合、その後、CFをどのように送信したらよいのかが分からない。
ここでFCについての説明を加える。
図3に示すように、FCは、FS、BS、STminを含んでいる。
FSは、値0,1,2のいずれかを取る。「0」は「連続受信可能」であり、「1」は今すぐには受信できないことを示す「待機」であり、「2」は、データ量が大きすぎて受信できないことを示す「オーバーフロー」である。
BSは、連続受信可能なフレーム数を示すものであり、「0」は無制限に連続受信可能であり、1〜255は連続受信可能な「フレーム数」を示す。
STminは、CFと次のCFとの受信可能間隔を示すものであり、0〜127は、0〜127(ms)間隔が空いていれば受信可能であることを示している。また、240〜249は、240を減算して100倍したもの、すなわち、100〜900μs以上空いていれば受信可能であることを示している。
したがって、図2において、診断装置10は、送信されてくるFCに基づき、CFを受信可能であるか否か、連続して受信できるフレーム数、さらに、受信可能な間隔を取得して、CFを送信する。
しかしながら、図2に示したように、A及びBのECU21,22から送信されるFCが異なっている場合、その後、CFをどのように送信したらよいのかが分からない。
そこで、本実施形態では、A〜Cの各ECU21〜23から送信されるFCについて、FS、BS、STminのそれぞれの最低値を採用する。つまり、それぞれの最低値を採用することにより、全てのECU21〜23で受信可能とするのである。
例えば図4(a)に基づきこれを説明する。
FSは、「0」が「連続受信可能」であり、「1」が「待機」であり、「2」が「オーバーフロー」である。したがって、A−ECU21からのFSが「0」であり、B−ECU22からのFSが「0」であり、C−ECU23からのFSが「1」であるとすると、最低値の「1」を採用する。FSについては、比較的動的に変化する。
また、BSは連続受信可能なフレーム数を示すものであり、「0」は無制限に連続受信可能であり、1〜255は連続受信可能な「フレーム数」を示す。この値は、ほぼ固定値となるのが一般的である。したがって、A−ECU21からのBSが「0」であり、B−ECU22からのBSが「1」であり、C−ECU23からのBSが「3」であるとすると、最低値「1」を採用する。
さらにまた、STminは、CFと次のCFとの受信可能間隔を示すものである。この値は、ほぼ固定値となるのが一般的である。A−ECU21からのSTminが「0」であり、B−ECU22からのSTminが「100」であり、C−ECU23からのSTminが「245」であるとすると、受信間隔はそれぞれ、0ms、100ms、500((245−240)×100))μsとなる。したがって、最低値100msを採用する。
つまり、このように各パラメータの最低値を採用することで、A〜CのECU21〜23のいずれでもデータ受信が可能となる。
次に、診断装置10における送信処理を、図5及び図6のフローチャートに基づいて説明する。
最初のS100では、FFをブロードキャストで送信する。この処理は、送信開始を示すFFを、A〜Cの各ECU21〜23へ送信するものである。これに対し、各ECU21〜23はFCを送信してくる。
そこで続くS110では、FCを受信する。上述したようにFCには、FS、BS、STminが含まれる。
次のS120では、オーバーフローか否かを判断する。具体的には、S110にて受信したFCに含まれるFSが「2」であるときに肯定判断される。ここでオーバーフローであると判断された場合(S120:YES)、S130にてエラー処理を行い、その後、送信処理を終了する。この場合、すべてのECU21〜23への送信が停止されることになる。一方、オーバーフローでないと判断された場合(S120:NO)、S140へ移行する。
S140では、待機か否かを判断する。具体的には、S110にて受信したFCに含まれるFSが「1」であるときに肯定判断される。ここで待機であると判断された場合(S140:YES)、S150にてタイムアウト時間をリトリガする。フローチャートには示していないが、S100でFFを送信する際、タイムアウト時間を計測するカウンタをスタートさせる。例えばタイムアウト時間は1000msとしておき、この間にFCの応答がない場合には、エラー処理を行うという具合である。ここでは、A〜CのECU21〜23のいずれかが待機となっている場合に、タイマをリセットしてタイムアウト時間をリトリガする。一方、待機でないと判断された場合(S140:NO)、すなわちFSが「0」で受信可能である場合には、S160へ移行する。
S160では、BSの性能が悪い場合に、当該BSを記憶する。この処理は、受信されるFCに含まれるBSの最低値を記憶するものである。最初は無条件にBSを記憶し、2回目以降の処理の際、既に記憶されているBSと今回受信したFCに含まれるBSとを比較し、今回受信したBSの値が悪い場合に上書きする。
続くS170では、STminの性能が悪い場合に、当該STminを記憶する。この処理は、受信されるFCに含まれるSTminの最低値を記憶するものである。最初は無条件にSTminを記憶し、2回目以降の処理の際、既に記憶されているSTminと今回受信したFCに含まれるSTminとを比較し、今回受信したSTminの値が悪い場合に上書きする。
次の図6中のS180では、全てのECU21〜23からFCの連続受信可能を受信したか否かを判断する。ECU21〜23の数は、事前にブロードキャスト通信で非セグメント化のメッセージを送信し、その応答数として、予め取得することが考えられる。ここで全てのECU21〜23からFCの連続受信可能を受信したと判断された場合(S180:YES)、S190へ移行する。一方、ECU21〜23のうちでFCを受信していないものがある場合(S180:NO)、図5中のS110からの処理を繰り返す。
S190では、S160で記憶したBS及びS170で記憶したSTminに基づき、CFを送信する。
続くS200では、全てのデータを送信したか否かを判断する。ここで全てのデータを送信したと判断された場合(S200:YES)、送信処理を終了する。一方、送信していないデータがあるうちは(S200:NO)、S210へ移行する。
S210では、送信可能なフレーム数に到達したか否かを判断する。この処理は、BSの最低値であるフレーム数に到達したか否かを判断するものである。ここで送信可能なフレーム数に到達したと判断された場合(S210:YES)、図5中のS110へ移行する。一方、送信可能なフレーム数に到達していないと判断された場合(S210:NO)、S190からの処理を繰り返す。
次に、各ECU21〜23における受信処理を、図7及び図8のフローチャートに基づいて説明する。すべてのECU21〜23で同様の処理が実行されるのであるが、ここではA−ECU21を主体として説明する。
最初のS300では、FFを受信する。この処理は、図5中のS100に対応するものであり、診断装置10からのFFを受信するものである。
続くS310では、FCを送信する。上述したようにFCには、FS、BS、STminが含まれる。
次のS320では、他のB及びCのECU22,23が送信するFCを受信する。この処理は、B及びCのECU22,23がどのような性能であるかを知るために行われる。
続くS330では、他のECU22,23がオーバーフローか否かを判断する。具体的には、S320にて受信した他のECU22,23からのFCに含まれるFSが「2」であるときに肯定判断される。ここでオーバーフローであると判断された場合(S330:YES)、S340にてエラー処理を行い、その後、受信処理を終了する。一方、オーバーフローでないと判断された場合(S330:NO)、S350へ移行する。
S350では、他のECU22,23が待機か否かを判断する。具体的には、S320にて受信した他のECU22,23からのFCに含まれるFSが「1」であるときに肯定判断される。ここで待機であると判断された場合(S350:YES)、S360にてタイムアウト時間をリトリガする。タイムアウト時間のリトリガについては診断装置10の場合と同様である。一方、待機でないと判断された場合(S350:NO)、S370へ移行する。
S370では、BSの性能が悪い場合に、当該BSを記憶する。この処理は、自身のBSと他のECU22,23からのFCに含まれるBSとを比較して、BSの最低値を記憶するものである。
続くS380では、STminの性能が悪い場合に、当該STminを記憶する。この処理は、自身のSTminと他のECU22,23からのFCに含まれるSTminとを比較して、STminの最低値を記憶するものである。
次の図8中のS390では、CFが送られてきたか否かを判断する。ここでCFが送られてきたと判断された場合(S390:YES)、S400にてCFを受信し、その後、S410へ移行する。一方、CFが送られてきていないと判断された場合(S390:NO)、図7中のS320からの処理を繰り返す。
続くS410では、全てのデータを受信したか否かを判断する。ここで全てのデータを受信したと判断された場合(S410:YES)、受信処理を終了する。一方、受信していないデータがあるうちは(S410:NO)、S420へ移行する。
S420では、受信可能なフレーム数に到達したか否かを判断する。この処理は、BSの最低値であるフレーム数に到達したか否かを判断するものである。ここで受信可能なフレーム数に到達したと判断された場合(S420:YES)、図7中のS310へ移行する。一方、受信可能なフレーム数に到達していないと判断された場合(S420:NO)、S400からの処理を繰り返す。
以上詳述したように、本実施形態では、セグメント化されたデータをブロードキャスト通信にて診断装置10から当該診断装置10にバスライン40を介して接続される複数のECU21〜23へ送信する。
診断装置10は、A〜Cの全てのECU21〜23へFFを送信し(図5中のS100)、このFFをECU21〜23が受信すると(図7中のS300)、ECU21〜23は、FCを送信する(S310)。診断装置10は、このFCに基づき、FCに含まれるBS及びSTminの最低値を記憶することで(図5中のS160,S170)、CFを送信する(図6中のS190)。各ECU21〜23は、診断装置10からCFが送られてくると(図8中のS390:YES)、CFを受信する(S400)。
すなわち、診断装置10は、データ伝送の開始を示す開始情報(FF)を送信する開始情報送信手段10aと、ECU21〜23から送信されてくるフロー制御情報(FC)に基づき、当該フロー制御情報に含まれる情報の最低値を採用することで、複数のECU21〜23の全てにおいて受信可能な態様でデータを繰り返し送信するデータ送信手段10bと、を有し、一方、ECU21〜23は、開始情報送信手段10aにて送信される開始情報を受信すると、フロー制御情報を送信する制御情報送信手段21aを有し、データ送信手段にて送信されるデータを受信するデータ受信手段21bを有している。
つまり、ECU21〜23からフロー制御情報が送信されるため、当該フロー制御情報に含まれる各種情報の最低値を採用することで、複数のECU21〜23の全てに同時期にデータを送信するのである。このようにすれば、セグメント化されたデータを全てのECU21〜23へ送信する場合でも通信時間を抑えることができる。しかも同時期にデータ送受信を完了させることができる。
また、本実施形態では、A−ECU21を例に挙げると、A−ECU21は、他のB及びCのECU22,23からのFCを受信し、FCに含まれるBS及びSTminの最低値を記憶することで(図7中のS370,S380)、診断装置10からのCFを受信する(S400)。なお、B−ECU22、C−ECU23についても同様である。すなわち、データ受信手段21bは、他のECUから送信されてくるフロー制御情報に基づき、当該フロー制御情報に含まれる情報の最低値を採用することで、データを受信する。これにより、診断装置10のCFのデータ送信に際し、ECU21〜23が適切に機能する。
さらにまた、本実施形態において診断装置10は、全てのECU21〜23からのFCの連続受信可能を受信すると(図6中のS180)、CFを送信する(S190)。すなわち、データ送信手段10bは、複数のECU21〜23のすべてからフロー制御情報を受信すると、データを送信する。これにより、全てのECU21〜23に対し、同時期にデータ送受信を完了させることができる。
具体的には、上述したように、ECU21〜23の数は、事前にブロードキャスト通信で非セグメント化のメッセージを送信し、その応答数として、予め取得することが考えられる。また、このような診断に係る処理以外で別の通信方式を利用しデータを送信することによってECUの数を調べるようにしてもよい。さらにまた、システム設計時にECUの数が決定されているならば、設計情報にあるECUの数を採用してもよい。
また、具体的には、データ送信手段10bは、開始情報送信手段10aにて開始情報を送信してから所定時間が経過した場合、複数のECU21〜23のすべてからフロー制御情報を受信したものとすることが考えられる。このように応答時間で判断する場合、図4(b)に示すように、FC応答までの時間を各ECU21〜23について予め取得し、その最低値を採用することが考えられる。例えばA−ECU21が100ms、B−ECU22が5ms、C−ECU23が0msである場合、100msを採用するという具合である。このように開始情報を送信してからの経過時間でECU21〜23の応答を判断する場合、比較的簡単に判断できるという点で有利である。
[第2実施形態]
上記実施形態では、診断装置10は、A〜Cの各ECU21〜23から送信されてくるFCに基づいてデータを送信するものであった。これに対し、本実施形態は、代表となる特定ECUを先に決定しておき、当該特定ECUが診断装置10へFCを送信する構成である。したがって、A−ECU21のみが制御情報送信手段21aを備えている。
はじめに、診断装置10における送信処理を、図9及び図10のフローチャートに基づいて説明する。なお、特定ECUがA−ECU21であるものとして説明を続ける。
最初のS500では、FFをブロードキャストで送信する。この処理は、送信開始を示すFFを、A〜Cの各ECU21〜23へ送信するものである。これに対し、A−ECU21がFCを送信してくる。
そこで続くS510では、FCを受信する。上述したようにFCには、FS、BS、STminが含まれる。この場合、FS、BS、STminの最低値をA−ECU21が代表して送信してくる。
次のS520では、オーバーフローか否かを判断する。具体的には、S510にて受信したFCに含まれるFSが「2」であるときに肯定判断される。ここでオーバーフローであると判断された場合(S520:YES)、S530にてエラー処理を行い、その後、送信処理を終了する。この場合、すべてのECU21〜23への送信が停止されることになる。一方、オーバーフローでないと判断された場合(S520:NO)、S540へ移行する。
S540では、待機か否かを判断する。具体的には、S510にて受信したFCに含まれるFSが「1」であるときに肯定判断される。ここで待機であると判断された場合(S540:YES)、S550にてタイムアウト時間をリトリガする。一方、待機でないと判断された場合(S540:NO)、すなわちFSが「0」で受信可能である場合には、S560へ移行する。
S560では、BSを記憶する。この処理は、A−ECU21からのFCに含まれるBSを記憶するものである。A−ECU21は、A〜CのECU21〜23のBSのうちで最低のものを送信してくる。
続くS570では、STminを記憶する。この処理は、A−ECU21からのFCに含まれるSTminを記憶するものである。A−ECU21は、A〜CのECU21〜23のSTminのうちで最低のものを送信してくる。
次の図10中のS580では、CFを送信する。この処理は、S560で記憶したBS及びS570で記憶したSTminに基づき、CFを送信するものである。
続くS590では、全てのデータを送信したか否かを判断する。ここで全てのデータを送信したと判断された場合(S590:YES)、送信処理を終了する。一方、送信していないデータがあるうちは(S590:NO)、S600へ移行する。
S600では、送信可能なフレーム数に到達したか否かを判断する。この処理は、BSの最低値であるフレーム数に到達したか否かを判断するものである。ここで送信可能なフレーム数に到達したと判断された場合(S600:YES)、図9中のS510へ移行する。一方、送信可能なフレーム数に到達していないと判断された場合(S600:NO)、S580からの処理を繰り返す。
次に、A−ECU21における特定ECU受信処理を、図11(a)のフローチャートに基づいて説明する。
最初のS700では、FFを受信する。この処理は、図9中のS500に対応するものであり、診断装置10からのFFを受信するものである。
続くS710では、FCを送信する。A−ECU21は、他のECU22,23の代表として、FCを診断装置10へ送信する。このFCには、FS、BS、STminの最低値が含まれる。
次のS720では、送信したFCに基づいて診断装置10から送られてくるCFを受信する。
続くS730では、全てのデータを受信したか否かを判断する。ここで全てのデータを受信したと判断された場合(S730:YES)、特定ECU受信処理を終了する。一方、受信していないデータがあるうちは(S730:NO)、S740へ移行する。
S740では、受信可能なフレーム数に到達したか否かを判断する。この処理は、BSの示すフレーム数に到達したか否かを判断するものである。ここで受信可能なフレーム数に到達したと判断された場合(S740:YES)、S710からの処理を繰り返す。一方、受信可能なフレーム数に到達していないと判断された場合(S740:NO)、S720からの処理を繰り返す。
次に、B及びCのECU22,23における受信処理を、図11(b)のフローチャートに基づいて説明する。
最初のS800では、FFを受信する。この処理は、図9中のS500に対応するものであり、診断装置10からのFFを受信するものである。
次のS810では、送信したFCに基づいて診断装置10から送られてくるCFを受信する。
続くS820では、全てのデータを受信したか否かを判断する。ここで全てのデータを受信したと判断された場合(S820:YES)、受信処理を終了する。一方、受信していないデータがあるうちは(S820:NO)、S810からの処理を繰り返す。
本実施形態においても、セグメント化されたデータをブロードキャスト通信にて診断装置10から当該診断装置10にバスライン40を介して接続される複数のECU21〜23へ送信する。
診断装置10は、A〜Cの全てのECU21〜23へFFを送信し(図9中のS500)、このFFをECU21〜23が受信すると(図11(a)中のS700,図11(b)中のS800)、A−ECU21が代表してFCを送信する(図11(a)中のS710)。診断装置10は、このFCに基づき、FCに含まれるBS及びSTminを記憶することで(図9中のS560,S570)、CFを送信する(図10中のS580)。各ECU21〜23は、診断装置10からCFが送られてくるとCFを受信する(図11(a)中のS720、図11(b)中のS810)。
すなわち、ECU21〜23のうちの特定のECU21のみが制御情報送信手段21aを有しており、制御情報送信手段21aは、各ECU21〜23のフロー制御情報に含まれる情報の最低値からなるフロー制御情報を診断装置10へ送信する。
つまり、特定のA−ECU21からフロー制御情報が送信されるため、当該フロー制御情報に含まれる各種情報を採用することで、複数のECU21〜23の全てに同時期にデータを送信するのである。このようにすれば、セグメント化されたデータを全てのECU21〜23へ送信する場合でも通信時間を抑えることができる。しかも同時期にデータ送受信を完了させることができる。
本実施形態では、A−ECU21からのFCを受信すると(図9中のS510)、CFを送信する(図10中のS580)。すなわち、データ送信手段10bは、特定のECU21からフロー制御情報を受信すると、データを送信する。このときは、FC応答までの時間がもっとも長いECUを特定ECUにすることが考えられる。この場合、代表となる特定のECU21が決められているため、ECU21〜23の数を取得する必要がないという点で有利である。
以上、本発明は、上記実施形態に何ら限定されるものではなく、その技術的範囲を逸脱しない限り、種々なる形態で実施可能である。
図5中のS130、図7中のS340、及び、図9中のS530におけるエラー処理は、以降の処理を中断するものであった。これに対し、オーバーフローとなったECUを除外して処理を継続するようにしてもよい。また、診断装置10の側でデータ長を短くするような処理を行うようにしてもよい。
1…診断システム、10…診断装置、10a…開始情報送信手段、10b…データ送信手段、21,22,23…ECU、21a…制御情報送信手段、21b…データ受信手段、30…ゲートウェイECU、40…バスライン、90…センタ

Claims (9)

  1. セグメント化されたデータをブロードキャスト通信にて診断装置(10又は30)から当該診断装置にバスライン(40)を介して接続される複数のECU(21,22,23)へ送信する診断システム(1)であって、
    前記診断装置は、
    データ伝送の開始を示す開始情報(FF)を送信する開始情報送信手段(10a)と、
    前記ECUから送信されてくるフロー制御情報(FC)に基づき、当該フロー制御情報に含まれる情報の最低値を採用することで、前記複数のECUの全てにおいて受信可能な態様で前記データを繰り返し送信するデータ送信手段(10b)と、を有し、
    前記ECUは、
    前記開始情報送信手段にて送信される前記開始情報を受信すると、前記フロー制御情報を送信する制御情報送信手段(21a)を有し、
    前記データ送信手段にて送信される前記データを受信するデータ受信手段(21b)を有していること
    を特徴とする診断システム。
  2. 請求項1に記載の診断システムにおいて、
    前記データ受信手段は、他のECUから送信されてくる前記フロー制御情報に基づき、当該フロー制御情報に含まれる情報の最低値を採用することで、前記データを受信すること(S400)
    を特徴とする診断システム。
  3. 請求項1又は2に記載の診断システムにおいて、
    前記データ送信手段は、前記複数のECUのすべてから前記フロー制御情報を受信すると、前記データを送信すること(S180:YES,S190)
    を特徴とする診断システム。
  4. 請求項3に記載の診断システムにおいて、
    前記データ送信手段は、前記開始情報送信手段にて前記開始情報を送信してから所定時間が経過した場合、前記複数のECUのすべてから前記フロー制御情報を受信したものとすること
    を特徴とする診断システム。
  5. 請求項1に記載の診断システムにおいて、
    前記ECUのうちの特定のECUのみが前記制御情報送信手段を有しており、
    前記制御情報送信手段は、各ECUの前記フロー制御情報に含まれる情報の最低値からなる前記フロー制御情報を前記診断装置へ送信すること(S710)
    を特徴とする診断システム。
  6. 請求項5に記載の診断システムにおいて、
    前記データ送信手段は、前記特定のECUから前記フロー制御情報を受信すると、前記データを送信すること(S580)
    を特徴とする診断システム。
  7. 請求項1〜6の何れか一項に記載の診断システムにおいて、
    前記フロー制御情報には、受信可能か否かを示す情報(FS)、連続受信可能なデータ数を示す情報(BS)、及び、連続受信における受信可能間隔を示す情報(STmin)が含まれていること
    を特徴とする診断システム。
  8. 請求項1〜7の何れか一項に記載の診断システムを構成する診断装置。
  9. 請求項1〜7の何れか一項に記載の診断システムを構成するECU。
JP2013079555A 2013-04-05 2013-04-05 診断システム、当該診断システムを構成する診断装置及びecu Active JP5987761B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP2013079555A JP5987761B2 (ja) 2013-04-05 2013-04-05 診断システム、当該診断システムを構成する診断装置及びecu

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2013079555A JP5987761B2 (ja) 2013-04-05 2013-04-05 診断システム、当該診断システムを構成する診断装置及びecu

Publications (2)

Publication Number Publication Date
JP2014204314A JP2014204314A (ja) 2014-10-27
JP5987761B2 true JP5987761B2 (ja) 2016-09-07

Family

ID=52354387

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2013079555A Active JP5987761B2 (ja) 2013-04-05 2013-04-05 診断システム、当該診断システムを構成する診断装置及びecu

Country Status (1)

Country Link
JP (1) JP5987761B2 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN119404489A (zh) * 2022-07-19 2025-02-07 日立安斯泰莫株式会社 车载通信系统及车载通信方法

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
DE4131133B4 (de) * 1991-09-19 2005-09-08 Robert Bosch Gmbh Verfahren und Vorrichtung zum Austausch von Daten in Datenverarbeitungsanlagen
DE10234348B4 (de) * 2002-07-26 2018-01-04 Robert Bosch Gmbh Verfahren und Vorrichtung zur Überwachung einer Datenübertragung

Also Published As

Publication number Publication date
JP2014204314A (ja) 2014-10-27

Similar Documents

Publication Publication Date Title
JP5423736B2 (ja) ゲートウェイ装置
JP5709055B2 (ja) 車両用電子制御装置
JP5949416B2 (ja) 中継装置
JP5664799B2 (ja) 通信システム及び通信方法
WO2016017088A1 (ja) ゲートウェイ装置
CN109863778B (zh) 用于监控数据连接的质量的方法以及用于在该方法中使用的订户站和网络管理单元
CN105282209A (zh) 车辆用网络系统和其中异构通信控制器的数据传输方法
CN110574345A (zh) 车载通信系统、车载中继装置及消息中继方法
US20220182258A1 (en) In-vehicle network system
CN103592935A (zh) 一种实现汽车诊断的方法、装置和智能终端
KR20180077673A (ko) 차량용 무선 데이터 교환 시스템 및 그 제어방법
JP5987761B2 (ja) 診断システム、当該診断システムを構成する診断装置及びecu
JP2020022019A (ja) 車両システム
CN114503518A (zh) 检测装置、车辆、检测方法及检测程序
CN104253727B (zh) 车辆lin网络的诊断方法及其系统
US20160352470A1 (en) Communication device, communication method, and communication system
JPWO2020194748A5 (ja) 端末、無線通信方法及びシステム
CN114237195A (zh) 一种obd排放诊断方法及相关设备
JP2014017614A (ja) 通信システム、中継装置及び通信装置
CN111007839A (zh) 车辆远程诊断方法、装置、系统和存储介质
CN117834617A (zh) 远程登录和诊断方法、装置、电子设备、车辆及存储介质
CN114650194B (zh) 数据通信的方法、装置、电子设备及存储介质
US10777079B2 (en) Methods and systems for estimating an end of a vehicle trip
JP2017163344A (ja) 通信システム
CN115633075B (zh) 设备通信方法、装置、终端设备和存储介质

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20150904

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20160624

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: 20160712

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20160725

R151 Written notification of patent or utility model registration

Ref document number: 5987761

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R151

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250