(57)【要約】【課題】所定のボーレートで通信を行う評価対象とネットワークを介して接続される評価ツールにおいて、簡易な仕組みで評価対象をバスオフ状態に移行させることができるようにする。【解決手段】評価ツールは、所定のボーレートで通信を行う評価対象とネットワークを介して接続される評価ツールであって、評価ツールのボーレートを、評価対象がネットワークにデータを送信可能であり、かつ評価対象が送信するデータにより、評価ツールで第１のエラーが発生するように予め定められた第１のボーレートに設定する第１の設定部と、評価ツールで第１のエラーが発生したとき、評価ツールのボーレートを、評価ツールが送信するエラーフレームにより、評価対象で送受信が禁止となる所定数の第２のエラーが発生するように予め定められた第２のボーレートに設定する第２の設定部と、を有する。【選択図】図１
2019087890.tif 000002
【特許請求の範囲】
【請求項１】
所定のボーレートで通信を行う評価対象とネットワークを介して接続される評価ツールであって、
前記評価ツールのボーレートを、前記評価対象が前記ネットワークにデータを送信可能であり、かつ前記評価対象が送信する前記データにより、前記評価ツールで第１のエラーが発生するように予め定められた第１のボーレートに設定する第１の設定部と、
前記評価ツールで前記第１のエラーが発生したとき、前記評価ツールのボーレートを、前記評価ツールが送信するエラーフレームにより、前記評価対象で送受信が禁止となる所定数の第２のエラーが発生するように予め定められた第２のボーレートに設定する第２の設定部と、
を有する、評価ツール。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、評価ツールに関する。
【背景技術】
【０００２】
例えば、ＣＡＮ（Controller Area Network）等の車載ネットワークにおいて、評価対象となるＥＣＵ（Electric Control Unit）を、データの送受信を行うことができないバスオフ状態に移行させる評価ツールが知られている。
【０００３】
例えば、ＣＡＮネットワークにおいて、所定のエラーメッセージを送出することにより評価対象のエラーカウンタを溢れさせて、評価対象をバスオフ状態に移行させるエラーメッセージ送信装置が知られている（例えば、特許文献１参照）。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００２−０７３４３０号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
例えば、特許文献１に開示された技術により、評価対象をバスオフ状態に移行させて、評価対象がバスオフ発生時にＣＡＮの仕様通りに動作しているかを評価することができる。
【０００６】
しかし、このような従来の技術では、所定のエラーメッセージを送出する特別な評価ツールが必要であり、評価ツールの構成が複雑になるという問題がある。
【０００７】
本発明の実施の形態は、上記の問題点に鑑みてなされたものであって、所定のボーレートで通信を行う評価対象とネットワークを介して接続される評価ツールにおいて、簡易な仕組みで評価対象をバスオフ状態に移行させることができるようにする。
【課題を解決するための手段】
【０００８】
上記の課題を解決するため、本発明の一実施形態に係る評価ツールは、所定のボーレートで通信を行う評価対象とネットワークを介して接続される評価ツールであって、前記評価ツールのボーレートを、前記評価対象が前記ネットワークにデータを送信可能であり、かつ前記評価対象が送信する前記データにより、前記評価ツールで第１のエラーが発生するように予め定められた第１のボーレートに設定する第１の設定部と、前記評価ツールで前記第１のエラーが発生したとき、前記評価ツールのボーレートを、前記評価ツールが送信するエラーフレームにより、前記評価対象で送受信が禁止となる所定数の第２のエラーが発生するように予め定められた第２のボーレートに設定する第２の設定部と、を有する。
【０００９】
評価ツールは、評価ツールのボーレートを、評価対象が通信を行う所定のボーレートとは異なるボーレートに設定することにより、評価対象が送信するデータを受付した評価ツールにおいて、第１のエラーを発生させることができる。ただし、この第１のエラーに応じて評価ツールが送信するエラーフレームが、評価対象が送信する通信フレームのアービトレーションフィールドに出力されてしまうと、評価対象が、アービトレーションに負けてデータを送信できない場合がある。そこで、評価ツールは、評価ツールのボーレートを、評価対象がネットワークにデータを送信可能であり、かつ評価対象が送信するデータにより、評価ツールで第１のエラーが発生するように予め定められた第１のボーレートに設定する。
【００１０】
また、評価ツールは、第１のエラーが発生したとき、評価ツールのボーレートを、評価ツールが送信するエラーフレームにより、評価対象で送受信が禁止となる所定数の第２のエラーが発生するように予め定められた第２のボーレートに設定する。
【００１１】
これにより、評価ツールは、ＣＡＮ通信を行うＣＡＮトランシーバ等のボーレートを変更するだけで、評価対象をバスオフ状態に移行させることができるようになる。
【発明の効果】
【００１２】
本発明の実施の形態によれば、所定のボーレートで通信を行う評価対象とネットワークを介して接続される評価ツールにおいて、簡易な仕組みで評価対象をバスオフ状態に移行させることができるようになる。
【図面の簡単な説明】
【００１３】
【図１】一実施形態に係る評価システムの構成例を示す図である。
【図２】一実施形態に係るバスオフ状態について説明するための図である。
【図３】一実施形態に係るバスオフの発生方法について説明するための図である。
【図４】一実施形態に係る評価ツールの処理の例を示すフローチャートである。
【図５】第１の実施形態に係る第１のボーレートについて説明するための図である。
【図６】第１の実施形態に係る第２のボーレートについて説明するための図である。
【図７】第２の実施形態に係るメッセージ再送時の対策について説明するための図である。
【図８】第３の実施形態に係る対応情報のイメージを示す図である。
【図９】第４の実施形態に係る波形パターンの例を示す図である。
【発明を実施するための形態】
【００１４】
以下、図面を参照して発明を実施するための形態について説明する。
【００１５】
＜評価システムの構成＞
図１は、一実施形態に係る評価システムの構成例を示す図である。評価システム１００は、所定のボーレートで通信を行う評価対象１２０と、ネットワーク１３０を介して評価対象１２０に接続される評価ツール１１０とを含む。ここでは、ネットワーク１３０が、ＣＡＮ（Controller Area Network）プロトコルを用いて通信を行うＣＡＮネットワークであるものとして以下の説明を行う。
【００１６】
評価対象１２０は、例えば、自動車等の車両に搭載されるＥＣＵ（Electric Control Unit）であり、車両制御系、ボディー系、マルチメディア系等の所定の機能を制御する。評価対象１２０は、例えば、ＣＰＵ（Central Processing Unit）、ＲＡＭ（Random Access Memory）、フラッシュＲＯＭ（Read Only Memory）、及び通信インタフェース等を含み、ＣＰＵで所定のプログラムを実行することにより、所定の機能を実現する。また、評価対象１２０は、ＣＡＮトランシーバ等の通信インタフェースを介してネットワーク１３０に接続され、所定のボーレート（Baud Rate）で、例えば、評価ツール１１０等の他のノードとＣＡＮプロトコルによる通信を行うことができる。
【００１７】
ここで、ボーレートは、変調速度の単位であり、１秒間に変調、復調できる回数を表している。また、データの転送速度の単位として知られているｂｐｓ（又はｂｉｔ／ｓ）は、１秒間に転送できるビット数を表している。例えば、１秒間に２４００回変調、復調を行い、１回の変調、復調で２ビットのデータが送信できるシステムでは、ボーレートは１２００ｂｐｓとなり、転送速度は２４００ｂｐｓとなる。ここでは、ボーレートを用いて以下の説明を行う。
【００１８】
評価ツール１１０は、評価対象１２０とネットワーク１３０を介して接続され、評価対象１２０を評価するための情報処理装置である。評価ツール１１０は、例えば、評価対象１２０でバスオフが発生したときの動作が、仕様通りであるか等を評価するために、評価対象１２０を強制的にバスオフ状態に移行させる機能を有している。
【００１９】
ここで、バスオフ状態とは、ＣＡＮのノードが通信に参加できない状態であり、データの送受信が禁止される。
【００２０】
（バスオフ状態について）
図２は、一実施形態に係るバスオフ状態について説明するための図である。ＣＡＮには、図２に示すように、「エラーアクティブ状態」、「エラーパッシブ状態」、及び「バスオフ状態」の３つのエラー状態がある。
【００２１】
このうち、「エラーアクティブ状態」は、ノードが、通信に正常に参加できる状態を表す。「エラーパッシブ状態」は、ノードが、通信には参加できるが、エラーを起こしやすいと判断された状態を表す。エラーパッシブ状態のノードは、エラーアクティブ状態のノードを優先的に送信させるために送信待機を行い、バスアイドル状態を検知した後でないと送信処理を行うことができない。「バスオフ状態」は、ノードが、通信に参加できない状態を表す。
【００２２】
これら３つの状態は、ＣＡＮのノードが備えるＴＥＣ（Transmit Error Counter）とＲＥＣ（Receive Error Counter）という２つのカウンタによって管理されている。これらのカウンタは、ノードがエラーを検出すると、その内容によって増減される。
【００２３】
例えば、図２に示すように、エラーアクティブ状態のノードは、ＴＥＣ又はＲＥＣの値が１２７を超えるとエラーパッシブ状態に移行する。また、エラーパッシブ状態のノードは、ＴＥＣ及びＲＥＣの値が１２７以下になるとエラーアクティブ状態に戻り、ＴＥＣの値が２５５を超えるとバスオフ状態に移行する。
【００２４】
バスオフ状態に移行したノードは、データの送受信が禁止され、１１ビットの連続したリセッシブビットを検出した場合、エラーアクティブ状態に遷移する。
【００２５】
なお、ＣＡＮでは、論理値の「０」をドミナント（Dominant）と呼び、論理値の「１」をリセッシブ（Recessive）と呼ぶ。また、複数のノードからドミナントとリセッシブが送信された場合、ドミナントが優先され、バスの値はドミナントとなる。
【００２６】
（バスオフの発生方法）
図３は、一実施形態に係るバスオフの発生方法について説明するための図である。
【００２７】
評価対象１２０をバスオフ状態に移行させる方法（バスオフの発生方法）として、例えば、バスの値を強制的にドミナント、又はリセッシブに固定する方法がある。ただし、この方法では、例えば、自動的に検査を行いたい場合や、所定の期間内にバスオフを発生させてタイミングを計りたい場合等には、バスの値を強制的に固定するための追加の機材が必要になる。
【００２８】
また、追加の機材を用いずに、評価対象１２０にバスオフを発生させる方法として、他のノード（例えば、評価ツール１１０）のボーレートを変更する方法が考えられる。
【００２９】
例えば、図３において、評価ツール１１０のボーレートをＸとし、評価対象１２０のボーレートをＹとする。ここで、Ｙは、評価対象１２０が通信を行う既定のボーレートであり、Ｘは、Ｙより低いボーレートに設定されているものとする。
【００３０】
図３において、評価対象１２０が、メッセージ３０１を送信する。一方、評価ツール１１０は、評価対象１２０とボーレートが異なるため、評価対象１２０が送信するメッセージ３０１を正しくサンプリングすることができず、スタッフエラー３０２が発生し、エラーフレーム３０３を送信する。
【００３１】
ＣＡＮでは、同じ値（ドミナント、又はリセッシブ）のデータが５ビット続いたとき、その次のビットにスタッフビットと呼ばれる反転ビットを入れるというスタッフィングルールが定められている。また、ＣＡＮのノードは、連続して同じ値のビットを６ビット以上受信したとき、スタッフエラーを検出し、例えば、６ビットのドミナント（又はリセッシブ）から成るエラーフラグを含むエラーフレームを送信する。
【００３２】
また、評価対象１２０は、評価ツール１１０が送信するエラーフレーム３０３により、評価対象１２０が送信したデータと、バス波形が一致しないためビットエラー３０４を検出し、送信エラーをカウントするＴＥＣに所定の値を加算する。
【００３３】
一方、評価ツール１１０は、エラーフレーム３０３においてエラーフラグに続く、エラーデリミタ３０５において、評価対象１２０が送信するデータにより、フォームエラー３０６を検出し、エラーフレーム３０７を再送信する。
【００３４】
ＣＡＮのエラーフレームには、６ビットのドミナント、又はリセッシブからなるエラーフラグと、エラーフラグに続く８ビットのエラーデリミタが含まれる。エラーデリミタは、本来は８ビットのリセッシブであり、エラーフレームを送信したノードは、このエラーデリミタの期間にドミナントが検出されると、フォームエラーと判断して、再度エラーフレームを送信する。
【００３５】
評価ツール１１０が再送信したエラーフレーム３０７により、評価対象１２０は、再びビットエラー３０８を検出し、ＴＥＣに所定の値を加算する。このように、評価ツール１１０のボーレートＸを変更することにより、評価ツールにエラーフレームを送信させて、送信したエラーフレームにより、評価対象１２０にビットエラーを発生させることができる。また、評価ツール１１０は、このような処理を、評価対象１２０のＴＥＣの値が２５５を超えるまで繰り返すことにより、評価対象１２０にバスオフを発生させることができる。
【００３６】
ただし、この方法では、評価ツール１１０のボーレートＸの値によっては、評価対象１２０がバスオフ状態に移行しない場合がある。
【００３７】
例えば、ＣＡＮでは、バスが空いていれば、いずれのノードでも送信することができるマルチマスタ方式を採用しており、複数のノードが同時に送信処理を行った場合、通信フレームの先頭に設けられたアービトレーションフィールドで調停が行われる。各ノードは、通信フレームの先頭にＣＡＮ−ＩＤと呼ばれる識別情報を付加して送信する。また、各ノードは、バスの値をモニタし、アービトレーションフィールドにおいて、送信した値とモニタした値とが一致しない場合、送信を中止する（以下、アービトレーション負けと呼ぶ）。
【００３８】
従って、例えば、図３において、評価ツール１１０が送信するエラーフレーム３０３が、評価対象１２０が送信する通信フレームのアービトレーションフィールドに出力されてしまうと、アービトレーション負けにより、評価対象１２０は送信を行うことができない。従って、評価対象１２０において、送信エラーをカウントするＴＥＣの値が加算されず、評価対象１２０をバスオフ状態に移行させることができない。
【００３９】
また、例えば、評価対象１２０が、エラーフレームを送信した後、メッセージを再送信する際にも、評価ツール１１０が送信するエラーフレームにより、アービトレーション負けが発生する場合がある。
【００４０】
このような問題を解決するため、本実施形態に係る評価ツール１１０は、例えば、図１に示すような機能構成を有している。
【００４１】
＜評価ツールの機能構成＞
評価ツール１１０は、例えば、ＣＰＵ、ＲＡＭ、ストレージデバイス、及びＣＡＮトランシーバ等の通信インタフェースを有している。また、評価ツール１１０は、例えば、ストレージデバイスに記憶した所定のプログラムをＣＰＵで実行することにより、第１の設定部１１１、第２の設定部１１２、及び送受信部１１３等を実現している。なお、評価ツール１１０の各機能のうち、少なくとも一部は、ハードウェアによって実現されるものであっても良い。
【００４２】
第１の設定部１１１は、評価ツール１１０のボーレートを、評価対象１２０がデータを送信可能であり、かつ評価対象１２０が送信するデータにより、評価ツール１１０で第１のエラーが発生するように予め定められたボーレートＸ１に設定する。なお、ボーレートＸ１については、複数の実施形態を例示して後述する。
【００４３】
第２の設定部１１２は、第１のエラーが発生したとき、評価ツール１１０のボーレートを、評価ツール１１０が送信するエラーフレームにより、評価対象１２０でバスオフが発生する所定数の第２のエラーが発生するように予め設定された第２のボーレートに設定する。例えば、第２の設定部１１２は、評価ツール１１０で第１のエラーが発生したとき、評価ツール１１０のボーレートを、評価対象１２０で送信エラーカウントが２５５回を超える送信エラーが発生するように予め定められたボーレートＸ２に設定する。なお、ボーレートＸ２についても、複数の実施形態を例示して後述する。
【００４４】
送受信部１１３は、例えば、ＣＰＵで実行されるプログラム、及びＣＡＮトランシーバ等の通信インタフェース等によって実現され、ＣＡＮプロトコルの仕様に従って、通信を行う。例えば、送受信部１１３は、図３の説明した、スタッフエラー、フォームエラーの検出、及びエラーフレームの送信等を、ＣＡＮプロトコルの仕様に従って実行する。
【００４５】
なお、図１に示す評価ツール１１０の機能構成は一例である。例えば、第１の設定部１１１と、第２の設定部１１２とは同じ設定部であっても良い。
【００４６】
［第１の実施形態］
続いて、第１の実施形態に係る評価ツール１１０が実行する評価方法の流れについて説明する。
【００４７】
＜処理の流れ＞
図４は、第１の実施形態に係る評価ツールの処理の例を示すフローチャートである。評価ツール１１０は、例えば、評価対象１２０をバスオフ状態に移行させるとき等に、図４に示す処理を実行する。
【００４８】
ステップＳ４０１において、評価ツール１１０の第１の設定部１１１は、評価ツール１１０のボーレートを第１のボーレートＸ１に設定する。このとき、第１の設定部１１１は、例えば、送受信部１１３のボーレート設定用のレジスタを変更すること等により、評価ツール１１０のボーレートを変更することができる。
【００４９】
ここで、第１のボーレートＸ１は、評価対象１２０が、ネットワーク１３０にデータを送信可能であり、かつ評価対象１２０が送信するデータにより、評価ツール１１０で第１のエラーが発生するように予め定められたボーレートである。
【００５０】
図５は、第１の実施形態に係る第１のボーレートについて説明するための図である。
図５において、評価対象のビット列５１０は、評価対象１２０が送信する通信フレームの先頭に含まれるアービトレーションフィールド５１５と、その前後のビット列のイメージを示している。
【００５１】
通信フレームの先頭では、ＳＯＦ（Start Of Frame）と呼ばれるドミナントビットが送信される。ＣＡＮでは、バスアイドル状態であるリセッシブから、ＳＯＦによりドミナントに変化することによりデータフレームの送信を表し、受信側と同期を取る。
【００５２】
また、ＳＯＦに続いて、メッセージの識別コードであるＣＡＮ−ＩＤ５１２が送信される。ＣＡＮ−ＩＤは、１１ビットの長さの識別コードであり、ここでは、ＣＡＮ−ＩＤ「０」が送信されている。
【００５３】
例えば、図５において、ＳＯＦの後に、論理値の「０」を示すドミナントが４ビット送信された後、前述したスタッフィングルールにより、スタッフビット５１３としてリセッシブが１ビット挿入されている。さらに、スタッフビット５１３に続いて、ドミナントが５ビット送信された後、同様にして、スタッフビットとしてリセッシブが１ビット挿入されている。このように、ＣＡＮ−ＩＤ自体の長さは１１ビットであるが、スタッフビットが挿入されることにより、ＣＡＮ−ＩＤ５１２のフィールドは最大で１３ビットになる場合がある。
【００５４】
また、ＣＡＮ−ＩＤ５１２の後には、１ビットのＲＴＲ（Remote Transmission Request）５１４が送信される。このＣＡＮ−ＩＤ５１２と、ＲＴＲ５１４とを合わせて、アービトレーションフィールド５１５と呼ぶ場合がある。
【００５５】
また、図５において、評価ツールのビット列５２０は、評価対象１２０が送信する通信フレームに対する、評価ツール１１０側のビット列の一例を示している。ここでは、評価ツール１１０のボーレートＸ１は、評価対象１２０のボーレートＹより低く設定されており、評価対象１２０の１ビット幅よりも、評価ツール１１０の１ビット幅の方が、幅が広くなっている。
【００５６】
評価ツール１１０は、受信側として動作し、１ビット毎に所定のサンプリングタイミング５２１で、バス上の波形をサンプリングする。図５の例では、評価ツール１１０は、５ビット連続したドミナントを検出し、スタッフエラー５２２が発生した状態を示している。このスタッフエラー５２２に応じて、評価ツール１１０がエラーフレームを送信することにより、評価対象１２０に送信ビットエラー５１６を発生させることができる。
【００５７】
ここで、例えば、評価対象１２０が、ＣＡＮ−ＩＤ５１２を送信している期間に、評価ツールがエラーフレームを送信してしまうと、前述したアービトレーション負けにより、評価対象１２０が送信を停止し、送信ビットエラー５１６が発生しない。従って、評価ツール１１０は、スタッフエラー５２２によるエラーフレームが、ＣＡＮ−ＩＤ５１２が送信された後に送信されるように、第１のボーレートＸ１を設定する。
【００５８】
図５の例では、ＳＯＦのビット数１と、ＣＡＮ−ＩＤのビット数１１と、スタッフビットの最大ビット数２と、を加算した１４ビットの範囲内に、評価ツール１１０によるエラーフレームが送信されないようにする。この場合、評価ツール１１０で、スタッフエラー５２２を検出して、エラーフレームを送信するまでに、最低６ビット必要なので、評価対象１２０のボーレートをＹとすると、第１のボーレートＸ１を次の式（１）を満たすように設定する。
Ｘ１ ≦ Ｙ／（１４／６）  ・・・（１）
これにより、評価ツール１１０は、評価対象１２０がネットワーク１３０にデータを送信可能であり、かつ評価ツール１１０で第１のエラー（スタッフエラー、ＣＲＣエラー等）が発生するように、第１のボーレートＸ１を決定することができる。
【００５９】
なお、第１のボーレートＸ１の値は、評価対象１２０がＣＡＮ−ＩＤ５１２を送信した後、評価ツール１１０が速やかにエラーフレームを送信することができるように、式（１）を満たす範囲内で、できるだけ大きな値とすることが望ましい。
【００６０】
ここで、図４に戻り、フローチャートの説明を続ける。
【００６１】
ステップＳ４０２において、評価ツール１１０の送受信部１１３は、設定された第１のボーレートＸ１で、評価対象１２０が送信する通信フレームを受信する。
【００６２】
ステップＳ４０３において、評価ツール１１０は、送受信部１１３がスタッフエラー、ＣＲＣエラー等の第１のエラーを検出した場合、評価ツール１１０は、処理をステップＳ４０４に移行させる。
【００６３】
ステップＳ４０４に移行すると、評価ツール１１０の第２の設定部１１２は、評価ツール１１０のボーレートを第２のボーレートＸ２に設定する。ここで、第２のボーレートＸ２は、評価ツール１１０が送信するエラーフレームにより、評価対象１２０がバスオフ状態に移行する所定数の第２のエラー（送信エラーカウントが２５５回を超える送信エラー）が発生するように、予め定められたボーレートである。
【００６４】
図６は、第１の実施形態に係る第２のボーレートについて説明するための図である。
図６に示すように、評価ツール１１０は、評価ツール１１０のボーレートを第１のボーレートＸ１に設定した後、スタッフエラー５２２を検出すると、第２のボーレートＸ２で６ビットのドミナントで構成されるエラーフラグ６１０を含むエラーフレームを送信する。
【００６５】
一方、評価対象１２０は、評価ツール１１０が送信するエラーフラグ６１０により、例えば、矢印６０１のタイミングでエラー（ビットエラー、又はスタッフエラー）を検出すると、エラーフラグを送信すると共に、送信エラーカウンタＴＥＣに「８」を加算する。
【００６６】
また、評価対象１２０は、エラーフラグの先頭から１４ビット連続したドミナントを検出したときと、その後、８ビットの連続したドミナントを検出するたびに、送信エラーカウンタＴＥＣに「８」を加算する。
【００６７】
図６の例では、矢印６０１、６０２、６０３、・・・のタイミングで、送信エラーカウンタＴＥＣの値が「８」ずつ増加し、ＴＥＣの値が「２５６」に達すると、評価対象１２０は、バスオフ状態に移行する。ここで、評価ツール１１０がエラーフラグ６１０の送信を開始してから、評価対象１２０がバスオフ状態に移行するまでの評価対象１２０側のビット数は、６＋１４＋８×３０＝２６０ビットとなる。
【００６８】
一方、評価ツール１１０が送信するエラーフラグの長さは６ビットなので、この間に、評価対象１２０の送信エラーカウンタＴＥＣが２５５を超えるように、第２のボーレートＸ２を設定すれば良い。この場合、評価対象のボーレートをＹとすると、第２のボーレートＸ２を次の式（２）を満たすように設定する。
Ｘ２ ≦ Ｙ／（２６０／６）  ・・・（２）
これにより、評価ツール１１０は、評価ツール１１０が送信するエラーフレームにより、評価対象１２０がバスオフ状態に移行する所定数の第２のエラー（送信エラーカウントが２５５回を超える送信エラー）が発生するように、第２のボーレートＸ２を設定することができる。
【００６９】
この場合、評価対象１２０は、メッセージを再送する前にバスオフ状態に移行するので、メッセージを再送する際のアービトレーション負けにより、バスオフが発生しないという問題も回避することができる。
【００７０】
以上、本実施形態によれば、所定のボーレートで通信を行う評価対象１２０とネットワーク１３０を介して接続される評価ツール１１０において、簡易な仕組みで評価対象１２０をバスオフ状態に移行させることができるようになる。
【００７１】
［第２の実施形態］
第１の実施形態では、評価ツール１１０が送信する６ビットのエラーフラグにより、評価対象１２０がメッセージを再送する前に、評価対象１２０をバスオフ状態に移行させる場合の例について説明した。第２の実施形態では、評価対象１２０がメッセージを再送する際のアービトレーション負けの対策について説明する。
【００７２】
図７は、第２の実施形態に係るメッセージ再送時の対策について説明するための図である。図７に示す評価ツール１１０の「エラーデリミタ２ビット分」７０１は、例えば、図３において、評価ツール１１０が送信するエラーフレーム３０３のエラーデリミタ３０５、及びフォームエラー３０６検出時のエラーデリミタの２ビットに対応している。
【００７３】
図３の例では、評価対象１２０は、エラーフレームを再送信しているので、アービトレーションが行われていない。しかし、評価対象１２０がメッセージ（例えば、データフレーム）を再送する場合、評価対象１２０がＣＡＮ−ＩＤを送信しているときに、評価ツール１１０がエラーフレームを送信すると、評価対象１２０でアービトレーション負けが発生する。
【００７４】
そこで、本実施形態では、図７において、評価ツール１１０の「エラーデリミタ２ビット分」７０１の期間が、評価対象１２０のエラーデリミタ７０２からＣＡＮ−ＩＤ７０３までの期間より長くなるように、評価ツール１１０のボーレートＸ３を設定する。
【００７５】
例えば、図７において、評価対象１２０のエラーデリミタ７０２からＣＡＮ−ＩＤ７０３までの期間には、エラーデリミタ７０２、ＩＴＭ（Intermission）、サスペンドトランスミッション、ＳＯＦ、ＣＡＮ−ＩＤ、及びスタッフビット等が含まれる。このうち、エラーデリミタ７０２は８ビット、ＩＴＭは３ビット、サスペンドトランスミッションは８ビット、ＳＯＦは１ビット、ＣＡＮ−ＩＤは１１ビット、スタッフビットは最大２ビットである。従って、評価ツール１１０のボーレートＸ３は、評価対象１２０のボーレートをＹとすると、次の式（３）で表される。
Ｘ３ ≦ Ｙ／（（８＋３＋８＋１＋１１＋２）／２）＝Ｙ／１６．５  ・・・（３）
さらに、本実施形態では、図７において、評価対象１２０の８ビットのエラーデリミタ７０２と、３ビットのＩＴＭとの計１１ビットの期間に、評価ツール１１０のサンプリングタイミングを設定する。この１１ビットの期間は、リセッシブなので、この期間にサンプリングを行うことにより、評価ツール１１０の「エラーデリミタ２ビット分」７０１の最初のビットで、フォームエラーが発生することを防止することができる。この場合、評価ツールのサンプリングタイミングは、評価対象のボーレートをＹとすると、次の式（４）で表される。
サンプリングタイミング ＜ １１／（Ｙ／Ｘ３）  ・・・（４）
なお、このサンプリングタイミングは、例えば、評価ツール１１０が、各ビットをサンプリングするタイミングを示している。例えば、サンプリングタイミング＝０．６の場合は、１ビットのビット幅のうち、０．６ビットの位置でサンプリングを行うことを示している。
【００７６】
このように、評価ツール１１０において、式（３）により算出されるボーレートＸ３に設定し、サンプリングタイミングを、式（４）により算出されるサンプリングタイミングに設定することにより、再送時のアービトレーション負け対策を行うことができる。
【００７７】
なお、式（３）により算出されるボーレートＸ３は、例えば、式（１）で示されるボーレートＸ１の条件を満たしており、かつ再送時におけるアービトレーション負けを防止することができる。従って、ボーレートＸ３を用いることにより、ボーレートをＸ１からＸ２に切替えることなく、評価対象１２０をバスオフ状態に移行させることができるようになる。
【００７８】
このように、評価ツール１１０の第１の設定部１１１が設定する第１のボーレートＸ１と、第２の設定部１１２が設定する第２のボーレートＸ２は、同じボーレート（例えば、Ｘ３）であっても良い。
【００７９】
［第３の実施形態］
第１、２の実施形態では、式（１）〜（３）により評価ツール１１０のボーレートを設定する場合の例を示したが、評価ツール１１０のボーレートや、サンプリングタイミングは、例えば、図８に示すような対応情報８０１に予め記憶しておくものであっても良い。
【００８０】
対応情報８０１には、ＣＡＮ−ＩＤとＤＬＣ（Data Length Code）とに対応付けて、実験又はシミュレーション等により、予め決定されたＸ１とＸ２、又はＸ３とサンプリングタイミングが記憶されているものとする。
【００８１】
例えば、第１の実施形態において、評価ツール１１０の第１の設定部１１１は、評価対象１２０のＣＡＮ−ＩＤとＤＬＣに対応するＸ１の値を、対応情報８０１から取得して、第１のボーレートＸ１を設定する。また、第２の設定部１１２は、評価対象１２０のＣＡＮ−ＩＤとＤＬＣに対応するＸ２の値を、対応情報８０１から取得して、第２のボーレートＸ２を設定する。
【００８２】
また、第２の実施形態において、評価ツール１１０は、評価対象１２０のＣＡＮ−ＩＤとＤＬＣに対応するＸ３の値と、サンプリングタイミングを取得して、評価ツール１１０のボーレートＸ３と、サンプリングタイミングを設定する。
【００８３】
例えば、このように、第１のボーレートＸ１、第２のボーレートＸ２、第３のボーレートＸ３、及びサンプリングタイミング等は、第１、２の実施形態に示した式（１）〜（４）に限られず、予め適切な値が定められているものであれば良い。
【００８４】
［第４の実施形態］
評価対象１２０が送信するメッセージのデータ内容を設定することができる場合、データを全てリセッシブ（又はドミナント）とし、評価ツール１１０が、スタッフビットをサンプリングしないように、評価ツール１１０のボーレートを設定しても良い。
【００８５】
例えば、図９（ａ）は、評価ツール１１０で、スタッフエラーが発生する場合の例を示している。評価対象１２０は、リセッシブを連続して送信しており、スタッフィングルールにより、スタッフビットが挿入されている。また、図９（ａ）の例では、評価対象１２０のスタッフビットの発生周期と、評価ツール１１０の１ビットの幅は一致している。この場合、評価ツール１１０は、適切なサンプリングタイミングを設定することにより、継続的に、スタッフビットをサンプリングしないように、すなわち、スタッフエラーが発生するように設定することができる。
【００８６】
一方、図９（ｂ）は、評価ツール１１０で、スタッフビットが発生しない場合の例を示している。図９（ｂ）の例では、評価対象１２０のスタッフビットの発生周期と、評価ツール１１０の１ビットの幅が異なる。この場合、図９（ｂ）に示すように、同じサンプリングタイミングでサンプリングを行っていても、スタッフビットの位置が変るので、スタッフビットをサンプリングしてしまい、スタッフエラーが発生しない場合がある。例えば、図９（ｂ）の例では、評価ツール１１０は、時間ｔ１において、スタッフビットをサンプリングしており、スタッフエラーが発生していない。
【００８７】
このように、評価対象１２０が送信するメッセージのデータ内容を設定することができる場合、データを全てリセッシブ又はドミナントすることにより、評価ツール１１０の適切なボーレート、及びサンプリングタイミングを、容易に決定することができるようになる。
【符号の説明】
【００８８】
１００      評価システム
１１０      評価ツール
１１１      第１の設定部
１１２      第２の設定部
１２０      評価対象
１３０      ネットワーク
【図１】
2019087890.tif 000003
【図２】
2019087890.tif 000004
【図３】
2019087890.tif 000005
【図４】
2019087890.tif 000006
【図５】
2019087890.tif 000007
【図６】
2019087890.tif 000008
【図７】
2019087890.tif 000009
【図８】
2019087890.tif 000010
【図９】
2019087890.tif 000011