バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はXCPonCANの課題を列挙。
そもそもとしてCANのデータフィールドが8byteであるが故の問題。
CAN-FDにすることで、このデータフィールドが最大で64byteになり、いろいろを改善ができそう。
と言っても何もせずにCANからCAN-FD切り替えられるわけもなく、
今回はXCPonCAN-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
現状の仮想ECU、仮想ECU構成
XCPonCAN-FDにするための手順を考えるんだっけか？
そうだね。
まぁその前に現状の仮想ECU、仮想ECU構成を再確認しよう。
結局はVirtual CAN Busと絡んでるところをCAN-FDとして辻褄を合わせる感じになるのかな・・・。
あとはXCPのODTに載せる変数のデータ長が変わるからね。
XCP関連も微小ではあるが変化する。
とすると、
大体以下の作業が必要そうってことかな。
- AUTOSAR-XCPのCAN-FD対応
- 仮想ECU内部変数の32bit化
- 指令器のCAN-FD化
- xcp_canクラスのCAN-FD対応
- 仮想HILSの内部変数の32bit化
うん。
大雑把な流れとしてはこれで良いだろうね。
細かい部分としては
それぞれをCAN-FDにしたり32bit化した段階での確認方法をどうするか。
ってはあるけど。
そうか。
確認方法も一緒に考えておく必要があるのか。
単純にCAN-FDフレームが出てるかはpython-canのcan.loggerで確認すれば良いし、
XCP部分の確認は恐らくはPyXCPで対応できるだろう。
PyXCPってXCPonCANFDは対応してるのかな？
まぁPyXCPの下層に位置するpython-can自体がCAN-FDに対応しているのと、
PyXCPのコンフィグレーションに一応CAN-FDに関連するパラメータが居るのと、
XCPレベルまで抽象化されていると、CANとCAN-FDの差はMAX_CTOとMAX_DTOというパラメータ差でしか無いため、
問題無いと思って良いだろう。
大丈夫かなぁ。
最悪、python-canでXCPパケットをガチで作って送りつけて確認ってことにはなるな。
まぁ確認手段が全くないって状態にはならないはずだ。
ここでグダグダ考えても始まらないから、
そこら辺はその時になったら調べて悩もう。
そうね。
「7、8割方いけるんじゃね？」
くらいで行動に移してしまうのもありだね。
失敗したとしても誰に迷惑掛からないし。
(このシリーズがどんどん伸びるという問題はあるだろうけどね・・・。)
まとめ
まとめだよ。
- XCPonCAN-FDに対応すべく現状の仮想ECU、仮想HILS構成を再確認。
- CANのところをCAN-FD化。
- XCP経由で変数のやり取りをしている部分を32bit化。
- 改造方針と同時に動作確認手段も模索する必要あり。
- python-can、PyXCPを駆使すればなんとかなりそうという当たりだけ付けた。
バックナンバーはこちら。
コメント