バックナンバーはこちら。
https://www.simulationroom999.com/blog/diagnostic-communication-backnumber/
はじめに
CAN-FDのシミュレーションに向けての話。
登場人物
博識フクロウのフクさん
イラスト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
シミュレーションの順番
これも、下層から試していく感じかなー？
そうだねー。
一気にAUTOSAR-dcmとcan-isotpを弄って一発で終わらせるってのもありだけど、
一層ずつクリアした方が良いかな。
とすると以下の流れになるのかな？
①python-canによるCAN-FD制御
②can-isotpでCAN-FD診断通信(ISO15765-2)
③AUTOSAR-CanTpでCAN-FD診断通信(ISO15765-2)
④AUTOSAR-DcmでCAN-FD診断通信(ISO14229-1)
うん。
その流れで行こう。
大雑把に勘所を教えてもらえると助かるんだけど？
python-canによるCAN-FD制御の勘所
python-canによるCAN-FD制御の勘所は、以下だね。
- CAN-FDのフレームに紐づいたフラグの制御
- FDF（FD Format Indicator）：CAN-FDであるフラグ
- BRS（Bit Rate Switch）：FlexDataRateになる。(FDFが有効である必要あり)
あー。前回言ってたCAN-FDならではのフラグだねー。
can-isotpでCAN-FD診断通信(ISO15765-2)の勘所
can-isotpでCAN-FD診断通信(ISO15765-2)の勘所は・・・。
- 8[byte]を超えるフレーム
- 7[byte]メッセージを超えるシングルフレームがあり得る
- 4095[byte]を超えるメッセージ
あ、そうか！
CANの場合は1フレームの最大値が8[byte]だったから7[byte]を超えるシングルフレームはあり得なかったけど、
CAN-FDの場合は最大値が64[byte]だからあり得るってことになるのか？
それと・・・。
4095[byte]を超えるメッセージ？？？
これは・・・フレーム構成が大きく変わるってことなのかな？？？
変わるというか、拡張されたってイメージかな。
(まぁその時になったら、また聞くか・・・。)
AUTOSAR-CanTpでCAN-FD診断通信(ISO15765-2)
これは「can-isotpでCAN-FD診断通信(ISO15765-2)の勘所」と一緒。
まぁそうだろーねー。
元となってる規格が一緒ってのもあるけど、
can-isotpとAUTOSAR-CanTpはパラメータもほぼ一緒だから
やれることも似たり寄ったりになるよねー。
たぶん、これをやる回は単なる導通テストみたいな回になると思うよ。
それまでにCAN-FDによるISO15765-2を理解しないとヤバいってことか・・・・。
AUTOSAR-DcmでCAN-FD診断通信(ISO14229-1)
簡単に各サービスを流す感じかなー。
メッセージそのものは一緒だから、CAN-FDの回線上どうなってるってのか確認する程度になると思うよ。
ほー。
なんか上位層になるほど大変になるイメージでいたけど、
実際は下位層の方が確認する内容が多いイメージだね。
うん。
上位層は抽象化されてるんで、下位層の影響を受けないってのが
システム構成としての理想形なんで、診断通信もそれに習ってるって思って良いね。
なるほどー。
まとめ
まとめだよ。
- シミュレーション手順と勘所説明。
- python-canによるCAN-FD制御。
- can-isotpでCAN-FD診断通信(ISO15765-2)。
- AUTOSAR-CanTpでCAN-FD診断通信(ISO15765-2)。
- AUTOSAR-DcmでCAN-FD診断通信(ISO14229-1)。
バックナンバーはこちら。
コメント