バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はややこしくなった仮想ECUと仮想HILSの連携についての構成を確認。
ネットワーク構成と論理的構成を確認したが、
機能単位でノード分割しているためネットワーク構成側がややこしい。
しかし、この単位で分割していると一部を本物に差し替えることも理屈上可能なわけで応報範囲は広くなる。
というわけで今回はついに仮想ECUと仮想HILSの連携動作確認の回となる。
登場人物
博識フクロウのフクさん
イラスト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と仮想HILSの連携動作
ついに仮想ECUと仮想HILSの連携だね。
(きっと動くきっと動くきっと動くきっと動くきっと動く・・・)
なんか念じとる・・・。
まぁ悩んでもしようがないし、とりあえず動かすねーﾎﾟﾁｰ
仮想ECUと仮想HILSの連携動作状況
お！
なんか動いてるっぽいぞ！
何！？
早く！録画するんだ！早く！
一応、録画しておいた。
よし！
少し編集するからちょっと待ってて！
仮想ECUと仮想HILSの連携動作を動画で確認
・・・30分後・・・
よし！
それっぽい動画にしてYoutubeに上げた！
動画：仮想ECUと仮想HILSの連携動作
バッチリ動いてるね！
一応、画像としてもキャプチャーしておいた。
仮想HILSの波形
仮想ECUの内部状態をXCPリスナーで拾った波形
![仮想ECUの内部状態をXCPリスナーで拾った波形、Target[rad/s]、voltaget[V]、speed[rad/s]](https://www.simulationroom999.com/blog/wp-content/uploads/2021/12/03_仮想ECUの内部状態をXCPリスナーで拾った波形-1024x665.png)
動作を見た感想
若干カクついてる動きはしてるけど、これは以前からあったのものだから仕方ないのかな？
そうだねー。
想定よりもキレイな気はするが、もう少しなんとかしたいねー。
なんとか出来るもんなの？
うーん、やってみないとわからないんだけど、
カクついてる理由に信号の精度が含まれているとするとちょっと改善できるかもしれない。
信号の精度を上げる方法があるのか？
精度？
うん。
今回の物理値の精度は1/256になってる。
これは2byte(16bit)長の変数の上位byteを整数、下位byteを小数点以下としたわけなのだが、
これを4byte(32bit)長の変数にして上位2byteを整数、下位2byteを小数点以下とすると精度については劇的に上がる。
だったら、4byte(32bit)長の変数にしよう！
ただ、変数それぞれ4byte(32bit)長にすると、1ODTあたり1変数しか乗らなくなるんだよねー。
そっか。
1ODTの最大長が7byteまでだから、
4byte占有すると残り3byte。
他の変数が載らなくなるのか・・・。
だったら、ODTを増やせばいいんじゃない？
それだとCANの負荷が上がって別の問題でカクつく原因を作ってしまいそうだ。
じゃーどうするの？
XCPonCANからXCPonCAN-FDにする！
また、なんか新たなネタが・・・。(よくいろいろ思いつくな。このフクロウ)
ソースコードとか
今回使用したソースコードはGithubに上げとく。
仮想ECU(AUTOSAR-XCP)
指令器＆仮想HILS
まとめ
まとめだよ。
- ついに仮想ECUと仮想HILSの連携動作。
- とりあえず動いたんで録画してYoutubeに上げた。
- 想定よりもキレイだはあるが、やはりカクついている。
- カクついている原因は変数の精度も含まれているかもしれない。
- 変数を32bit長にすることで精度を上げられるがODTを増やす必要がある。
- CAN-FDを使うと・・・。
バックナンバーはこちら。
コメント