バックナンバーはこちら。
https://www.simulationroom999.com/blog/diagnostic-communication-backnumber/
はじめに
ISO-TPのシミュレーションをしよう。のシリーズ。
ついに当初の想定する構成でシミュレーションをする回。
のBSパラメータを変化させた場合の挙動。
登場人物
博識フクロウのフクさん
イラスト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
BSパラメータの変更
正真正銘、シミュレーションのシリーズとしては今回が最後だ。たぶん。
(「たぶん」って言ってるぞ・・・。本当は前回で終わらせる予定だったんだろうなぁ。)
前回言ったようにFC(FlowControl)のBS(BlockSize)のパラメータを変更する。
オフボードテスタ側が送出するBSが4
疑似ECU側が送出するBSが1
の想定だ。
BSの話は以下で復習できるよ。
BSパラメータの変更のログ
じゃ、ログを展開。
前回と同様、ちょっと加工している。
Begin Triggerblock
0.000000 Start of measurement
// SFリクエスト、SFレスポンス
0.000000 1 18DA10F1x Rx d 8 03 22 01 0A CC CC CC CC // SF
0.001852 1 18DAF110x Rx d 8 06 62 01 0A 00 01 02 55 // SF
// SFリクエスト、MFレスポンス
0.200548 1 18DA10F1x Rx d 8 07 22 01 0A 01 0A 01 0A // SF
0.204890 1 18DAF110x Rx d 8 10 10 62 01 0A 00 01 02 // FF
0.206496 1 18DA10F1x Rx d 8 30 04 00 CC CC CC CC CC // FC
0.207487 1 18DAF110x Rx d 8 21 01 0A 00 01 02 01 0A // CF
0.208470 1 18DAF110x Rx d 8 22 00 01 02 55 55 55 55 // CF
// MFリクエスト、MFレスポンス
0.400999 1 18DA10F1x Rx d 8 10 11 22 01 0A 01 0A 01 // FF
0.401891 1 18DAF110x Rx d 8 30 01 00 55 55 55 55 55 // FC
0.403939 1 18DA10F1x Rx d 8 21 0A 01 0A 01 0A 01 0A // CF
0.404881 1 18DAF110x Rx d 8 30 01 00 55 55 55 55 55 // FC
0.406954 1 18DA10F1x Rx d 8 22 01 0A 01 0A CC CC CC // CF
0.413303 1 18DAF110x Rx d 8 10 29 62 01 0A 00 01 02 // FF
0.415973 1 18DA10F1x Rx d 8 30 04 00 CC CC CC CC CC // FC
0.416883 1 18DAF110x Rx d 8 21 01 0A 00 01 02 01 0A // CF
0.417931 1 18DAF110x Rx d 8 22 00 01 02 01 0A 00 01 // CF
0.418882 1 18DAF110x Rx d 8 23 02 01 0A 00 01 02 01 // CF
0.420954 1 18DAF110x Rx d 8 24 0A 00 01 02 01 0A 00 // CF
0.422027 1 18DA10F1x Rx d 8 30 04 00 CC CC CC CC CC // FC
0.422847 1 18DAF110x Rx d 8 25 01 02 01 0A 00 01 02 // CF
End TriggerBlock
やっぱりかなり複雑なハンドシェイクになったねぇ。
そうだね。
このBSの仕様が結構、車両診断通信の設計と実装を難しくしているところはあるね。
BSとかって結構使われるのかな？
どうだろうね？
私はあまり見たことは無いけど、
ECU側の性能があまり高くない場合は、
STminやBSでスループットのコントロールが必要な場面はあるのかもしれない。
うーん、やっぱりECU側の制約依存による仕様の振れ幅ってやつだねー。
シンプルな方が良いんだけど、それだと対応できないECUが出てくるかもしれないから、仕様に幅を持たせないといけないんだろうなー。
ここら辺は車両の宿命だね。
シリーズまとめ
普通だったらCANoe使うところをあえてPythonでやったわけなんだけど
どうだった？
最初は良く分からなかったけど、
動き始めたら割とイメージ湧いたかな。
まぁさすがにCANoeの方がいろいろやり易いんだろうけど。
そうだね。
ログを取りながら、何かするって場合はCANoeの方がやり易いだろうねー。
今回はPythonように複数のターミナルを起動してごちゃごちゃやることになったんで、結構手間だったと思う。
ここら辺は費用対効果依存かな。
ちょっと試す分にはPythonで十分で、
結構ガッツリテストする場合はCANoeの方が良いってイメージ。
あとは、うまく併用するって考え方もありかもね。
あ、
CANoeとPython-canって併用できるんだ？
うん。
今回は試してないけど、一応予備調査の時に併用できることは確認済み。
ほー。
どっかのタイミングで試してみよう。
というわけで、ISO15765-2ことIsoTp、CanTpのシミュレーションは終了～。
まとめ
まとめだよ。
- FC(FlowControl)のBS(BlockSize)パラメータを弄ったシミュレーション実施。
- シリーズのまとめ。
- CANoeとPythonの共存したテスト環境とか便利かもしれない。
バックナンバーはこちら。
コメント