バックナンバーはこちら。
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以下の場合はこのパターンになる。
以下がメッセージと実際と各種通信結果
リクエストメッセージ(オフボードテスタ側)
| TargetID | SourceID | Length | |||||||
| 10 | F1 | 07 | 01 | 02 | 03 | 04 | 05 | 06 | 07 |
レスポンスメッセージ(ECU側)
| TargetID | SourceID | Length | ||||||
| F1 | 10 | 06 | 01 | 02 | 03 | 04 | 05 | 06 |
回線ログ相当
| CANID | DLC | DataField | |||||||
| 18DA10F1 | 08 | 07 | 01 | 02 | 03 | 04 | 05 | 06 | 07 |
| 18DAF110 | 08 | 06 | 01 | 02 | 03 | 04 | 05 | 06 | CC |
あれ？
レスポンス側って最後にCCってのが入ってるけど、メッセージにはなかったような？
メッセージ自体は6byte分しかないんで、
最後のCCはメッセージには含まれないデータになる。
これをパディングと呼ぶ。
パティングってCC固定なの？
固定ではないよ。
ISO15765-2の例に則るとCCってことになるが、
古いISO15765-2だと55って時期もあったね。
まぁどっちにしても読まない部分なんで何を入れても良い。
良く見かけるパターンは、以下だけどね。
00、55、AA、CC、FF。
あと、そもそもDLCを8じゃなくて7にしておけばパディングも要らないんじゃない？
そうだね。
それでもOKだよ。
だったら、そっちの方が良くない？
ただ、パディングで埋めるパターンもあるんで、
今回の例ではパディングありとした。
ちなみに、DLCを8以外にしてパディング無しにするのを
DLC最適化仕様と呼ぶ。
ってことは両方知っていないとダメってことね。
そゆこと。
MF-MF通信
じゃ、次に結構ややこしいパターンで、
リクエストもレスポンスもマルチフレームになるパターン。
これは厄介そうだね。
早速、同じようにメッセージと回線ログを書き出すよ。
リクエストメッセージ(オフボードテスタ側)
| TargetID | SourceID | Length | ||||||||||||||||||
| 10 | F1 | 12 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 0A | 0B | 0C | 0D | 0E | 0F | 10 | 11 | 12 |
レスポンスメッセージ(ECU側)
| TargetID | SourceID | Length | ||||||||||||||||||
| F1 | 10 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 1A | 1B | 1C | 1D | 1E | 1F | 20 | 21 | 22 | 23 | 24 |
回線ログ相当
| CANID | DLC | 備考 | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 18DA10F1 | 08 | 10 | 12 | 01 | 02 | 03 | 04 | 05 | 06 | FF(FF_DL=0x12) |
| 18DAF110 | 08 | 30 | 00 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=0,STmin=0) |
| 18DA10F1 | 08 | 21 | 07 | 08 | 09 | 0A | 0B | 0C | 0D | CF(SN=1) |
| 18DA10F1 | 08 | 22 | 0E | 0F | 10 | 11 | 12 | CC | CC | CF(SN=2) |
| 18DAF110 | 08 | 10 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | FF(FF_DL=0x12) |
| 18DA10F1 | 08 | 30 | 00 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=0,STmin=0) |
| 18DAF110 | 08 | 21 | 19 | 1A | 1B | 1C | 1D | 1E | 1F | CF(SN=1) |
| 18DAF110 | 08 | 22 | 20 | 21 | 22 | 23 | 24 | CC | CC | CF(SN=2) |
これはややこしい。
でも、慣れでなんとかなるかもしれないかな。
そうだね。
慣れたら普通にCAN回線読んで、
脳内でメッセージを組み立てるとかできるようになると思うよ。
MF-MF通信(BSあり)
最後にさらに複雑なパターンで、
さっきのMF-MF通信でBSが1の時。
あ、さっきのが一番厄介だと思ってたらもっとヤバイのが残ってたのか？！
メッセージと回線ログ書くよ。
リクエストメッセージ(オフボードテスタ側)
| TargetID | SourceID | Length | ||||||||||||||||||
| 10 | F1 | 12 | 01 | 02 | 03 | 04 | 05 | 06 | 07 | 08 | 09 | 0A | 0B | 0C | 0D | 0E | 0F | 10 | 11 | 12 |
レスポンスメッセージ(ECU側)
| TargetID | SourceID | Length | ||||||||||||||||||
| F1 | 10 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 1A | 1B | 1C | 1D | 1E | 1F | 20 | 21 | 22 | 23 | 24 |
回線ログ相当
| CANID | DLC | 備考 | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|
| 18DA10F1 | 08 | 10 | 12 | 01 | 02 | 03 | 04 | 05 | 06 | FF(FF_DL=0x12) |
| 18DAF110 | 08 | 30 | 01 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=1,STmin=0) |
| 18DA10F1 | 08 | 21 | 07 | 08 | 09 | 0A | 0B | 0C | 0D | CF(SN=1) |
| 18DAF110 | 08 | 30 | 01 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=1,STmin=0) |
| 18DA10F1 | 08 | 22 | 0E | 0F | 10 | 11 | 12 | CC | CC | CF(SN=2) |
| 18DAF110 | 08 | 10 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | FF(FF_DL=0x12) |
| 18DA10F1 | 08 | 30 | 01 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=1,STmin=0) |
| 18DAF110 | 08 | 21 | 19 | 1A | 1B | 1C | 1D | 1E | 1F | CF(SN=1) |
| 18DA10F1 | 08 | 30 | 01 | 00 | CC | CC | CC | CC | CC | FC(FS=0,BS=1,STmin=0) |
| 18DAF110 | 08 | 22 | 20 | 21 | 22 | 23 | 24 | CC | CC | CF(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。
バックナンバーはこちら。
コメント
パッチングは、0xAA,0x55で埋めるのが、負荷が少なく速いと聞いております。
bitで0b01010101 0b10101010となります、結果スタッフィングbitを入れる必要がなく、icの処理にも優しい。
はい。その通りです。
なのですが、実は諸説ありまして・・・。
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固定仕様であることは多いです。