バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
「HILSもどき」とXCPを連携させて何かしらをやる予定。
XCP自体は以前Bypass関連で扱ったことがあるが、
その時はECU内部のアルゴリズムの疑似化だった。
対して、今回の利用方法はECUの外側の疑似化。
ここらへんの話をもう少し詳しく説明予定。
登場人物
博識フクロウのフクさん
イラスト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の外側の疑似化」とXCPの関係についてだけど、どういった意味になるの？
元々HILSだから「ECUの外側の疑似化」は出来てるわけだからXCPは関係無いような気がするのだけど？
ポイントはECUとHILSの間のインターフェースだね。
前回までだと、それをCANで実現したパターンだったけど、
それのXCP版があるってイメージ？
そうそう。
そのイメージであってる。
一応、ざっと絵を描いてきてた。
XCPによる入出力
これは・・・。
雰囲気はBypassと似てるけど・・・。
いや、なんか違うぞ！
XCPの読み書きの方向がBypassと真逆なのか？！
正解だ。
Bypassの時はECU内部アルゴリズムをPC側で疑似化することが目的だったので、
センサ入力をXCPで吸い上げて、
PC側のモデルで演算。
その結果をXCPでアクチュエータ出力手前に書き込み。
って流れだった。
対して、今回は、
センサ入力の代わりにPC側のHILSで演算した結果をXCPでセンサ入力として書き込み、
ECU側で演算した結果をXCPで読み出して、PC側のHILSへ渡す。
って流れだ。
なるほど。
確かにECUとHILSの間のインターフェースの役割をしてるね。
XCPを利用する上での欠点と利点
欠点としては
センサ入力部分、アクチュエータ出力部分の検証はできないってのはある。
対して利点は、
物理的な制約無しで直接ECUへHILSの演算結果を渡せる。
ってところだね。
これも使い分けってことだね。
CAN、ADC、DAC、PWMと違って物理インターフェース周りの調整が要らないからね。
センサ情報、制御情報が埋まってるRAMのアドレスが分かっていればOKだ。
それはいろいろ楽そうだ。
確かに試してみたくはなるねー。
というわけで次回からはXCP関連の実現方法考えていく。
まとめ
まとめだよ。
- ECUの外側の疑似化にXCPを使うってのはインターフェースをXCPにするってことだった。
- 以前やったBypassとはデータの流れは逆向きになっている。
- XCPで直接RAMの読み書きを行うことで物理的なインターフェースの制約を無視できる。
- 逆に物理的な制約に紐づいた検証はできないという欠点はある。
バックナンバーはこちら。
コメント