【DoCAN】車両診断通信 その11【ISO-TP⑥】

【DoCAN】車両診断通信 その11【ISO-TP⑥】 車両診断通信

バックナンバーはこちら。
https://www.simulationroom999.com/blog/diagnostic-communication-backnumber/

はじめに

車両診断通信のネットワーク層の話。
メッセージを各種フレームへの分解例。

登場人物

博識フクロウのフクさん

イラストACにて公開の「kino_k」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=iKciwKA9&area=1

エンジニア歴8年の太郎くん

イラストACにて公開の「しのみ」さんのイラストを使用しています。
https://www.ac-illust.com/main/profile.php?id=uCKphAW2&area=1

メッセージから各種フレームへの分解

フクさん
フクさん

前回、各種フレームの説明をしたのだけど、
実際どんな感じになるかイメージできてるかい?

太郎くん
太郎くん

うーん、なんとなくって感じで
正直自信はないな。

フクさん
フクさん

じゃ、ここらで一回、具体的なメッセージ送受信を各種フレームに分解してみよう。

太郎くん
太郎くん

そうしてもらえると助かるよ。

SF-SF通信

フクさん
フクさん

最もシンプルなパターンはリクエストがSFでレスポンスもSFのパターン。

太郎くん
太郎くん

これは1フレームで完結しているからそんなに悩まそうかな。

フクさん
フクさん

メッセージが7byte以下の場合はこのパターンになる。
以下がメッセージと実際と各種通信結果

リクエストメッセージ(オフボードテスタ側)

TargetIDSourceIDLength
10F10701020304050607

レスポンスメッセージ(ECU側)

TargetIDSourceIDLength
F11006010203040506

回線ログ相当

CANIDDLCDataField
18DA10F1080701020304050607
18DAF1100806010203040506CC
太郎くん
太郎くん

あれ?
レスポンス側って最後にCCってのが入ってるけど、メッセージにはなかったような?

フクさん
フクさん

メッセージ自体は6byte分しかないんで、

最後のCCはメッセージには含まれないデータになる。
これをパディングと呼ぶ。

太郎くん
太郎くん

パティングってCC固定なの?

フクさん
フクさん

固定ではないよ。
ISO15765-2の例に則るとCCってことになるが、
古いISO15765-2だと55って時期もあったね。
まぁどっちにしても読まない部分なんで何を入れても良い。
良く見かけるパターンは、以下だけどね。
00、55、AA、CC、FF。

太郎くん
太郎くん

あと、そもそもDLCを8じゃなくて7にしておけばパディングも要らないんじゃない?

フクさん
フクさん

そうだね。
それでもOKだよ。

太郎くん
太郎くん

だったら、そっちの方が良くない?

フクさん
フクさん

ただ、パディングで埋めるパターンもあるんで、

今回の例ではパディングありとした。
ちなみに、DLCを8以外にしてパディング無しにするのを
DLC最適化仕様と呼ぶ。

太郎くん
太郎くん

ってことは両方知っていないとダメってことね。

フクさん
フクさん

そゆこと。

MF-MF通信

フクさん
フクさん

じゃ、次に結構ややこしいパターンで、
リクエストもレスポンスもマルチフレームになるパターン。

太郎くん
太郎くん

これは厄介そうだね。

フクさん
フクさん

早速、同じようにメッセージと回線ログを書き出すよ。

リクエストメッセージ(オフボードテスタ側)

TargetIDSourceIDLength
10F1120102030405060708090A0B0C0D0E0F101112

レスポンスメッセージ(ECU側)

TargetIDSourceIDLength
F11012131415161718191A1B1C1D1E1F2021222324

回線ログ相当

CANIDDLC備考
18DA10F1081012010203040506FF(FF_DL=0x12)
18DAF11008300000CCCCCCCCCCFC(FS=0,BS=0,STmin=0)
18DA10F108210708090A0B0C0DCF(SN=1)
18DA10F108220E0F101112CCCCCF(SN=2)
18DAF110081012131415161718FF(FF_DL=0x12)
18DA10F108300000CCCCCCCCCCFC(FS=0,BS=0,STmin=0)
18DAF1100821191A1B1C1D1E1FCF(SN=1)
18DAF11008222021222324CCCCCF(SN=2)
太郎くん
太郎くん

これはややこしい。

太郎くん
太郎くん

でも、慣れでなんとかなるかもしれないかな。

フクさん
フクさん

そうだね。
慣れたら普通にCAN回線読んで、

脳内でメッセージを組み立てるとかできるようになると思うよ。

MF-MF通信(BSあり)

フクさん
フクさん

最後にさらに複雑なパターンで、
さっきのMF-MF通信でBSが1の時。

太郎くん
太郎くん

あ、さっきのが一番厄介だと思ってたらもっとヤバイのが残ってたのか?!

フクさん
フクさん

メッセージと回線ログ書くよ。

リクエストメッセージ(オフボードテスタ側)

TargetIDSourceIDLength
10F1120102030405060708090A0B0C0D0E0F101112

レスポンスメッセージ(ECU側)

TargetIDSourceIDLength
F11012131415161718191A1B1C1D1E1F2021222324

回線ログ相当

CANIDDLC備考
18DA10F1081012010203040506FF(FF_DL=0x12)
18DAF11008300100CCCCCCCCCCFC(FS=0,BS=1,STmin=0)
18DA10F108210708090A0B0C0DCF(SN=1)
18DAF11008300100CCCCCCCCCCFC(FS=0,BS=1,STmin=0)
18DA10F108220E0F101112CCCCCF(SN=2)
18DAF110081012131415161718FF(FF_DL=0x12)
18DA10F108300100CCCCCCCCCCFC(FS=0,BS=1,STmin=0)
18DAF1100821191A1B1C1D1E1FCF(SN=1)
18DA10F108300100CCCCCCCCCCFC(FS=0,BS=1,STmin=0)
18DAF11008222021222324CCCCCF(SN=2)
太郎くん
太郎くん

まぁ事前に普通のMF-MF通信を見てたから思ったほど複雑さは感じないかな。

太郎くん
太郎くん

これが一番厄介ってことでOK?

フクさん
フクさん

あとはFCのFSが0以外、例えばWAITとかが来たときとかあるけど。
まぁそんなに出てくることは無いし、ここまで例を見れば予想はつくんじゃない?

太郎くん
太郎くん

まぁFCが連続に入るんだろうなって予想は立ってる。

フクさん
フクさん

じゃ、メッセージの分解と再構築はOKってことで。

太郎くん
太郎くん

(これはちょっと別のパターンでこっそり練習しておこう。)

まとめ

フクさん
フクさん

まとめだよ。

  • SF-SF通信とMF-MF通信の各種フレームへの分解を実施。
    • MF-MF通信はFCのBSやFSで若干挙動が変わる。
  • DLCの都合でメッセージに含まれない部分はパディングで埋める。
    • パディングで使用する値は何でも良い。
    • 良く使われ鵜値は00,55,AA,CC,FF。

バックナンバーはこちら。

コメント

  1. 小貫 より:

    パッチングは、0xAA,0x55で埋めるのが、負荷が少なく速いと聞いております。
    bitで0b01010101 0b10101010となります、結果スタッフィングbitを入れる必要がなく、icの処理にも優しい。

    • KEI より:

      はい。その通りです。

      なのですが、実は諸説ありまして・・・。
      ISO15765-2が
      draft時はAAh,55hが推奨のような書き方。
      final-draft時は55h推奨な書き方。
      publishの段階でcch推奨な書き方。

      で、ここからは推測になってしまうのですが、
      当初は単純にスタッフビット抑制のみが焦点にあたっており、aah、55h推奨
      途中から頻繁に再同期させるのもコントローラ対してはやさしくない可能性を加味して、
      2bit幅でエッジになるcch推奨になっている気がします。

      と、ここで話が終わればきれいなのですが、
      SEA-J2534のいわゆるパススルー仕様だと00hがデフォルト値となっており、
      診断通信の仕様策定者を常に悩ませるプチ魔境と化しています・・・。
      また、建機系だとSEA-J1939の「無効値はFFhにすべき」という文化も入り込んで、
      「パディングもFFhにすべき」論があったりします。

      私はAAh,55hあたりで十分だとは思ってます。
      00h,FFhにせざるを得ない理由があるならば、報告義務を条件とした上で可。みたいな感じです。
      現在では、00h,FFhにしかできないというECUもツールもほぼないので、55h固定仕様であることは多いです。

タイトルとURLをコピーしました