バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
ついに仮想HILSのPythonコードが完成したところ。
基本的には前回までの修正内容を盛り込んだだけだが、
指令値取得用のCANバス初期化のタイミングだけ後ろにずらした。
(XCP設定用のパケットを受信FIFOに詰まないようにするため)
早速動作させてみたいところだが、
結構構成がややこしいことになっている。
一旦整理のため構成を確認する。
登場人物
博識フクロウのフクさん
イラスト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の実験構成
今回は動作実験の回・・・。
と見せかけて構成確認の回だっけ？
そうだね。
前回も行ったが、構成がちょっと複雑で概念的になってしまってるんで、
ネットワークとしての構成と論理的な構成の2点を整理しよう。
仮想ECUと仮想HILSのネットワークとしての構成
まずはネットワークとしての構成。
以下の図になる。
仮想HILS側が結構ややこしいことになってるねー。
XCPとFMUの2つの処理が入ってるからね。
あと構成としては出てきてないが波形表示もやってるし。
まぁ大体HILS側がヤバイことになるってのはあるあるだなー。
仮想ECUと仮想の論理的な構成
次は論理的な構成。
以下の図になる。
こっちは結構シンプルだね。
元々はModelicaモデルとして定義していたものだからね。
信号として繋がっていた部分がCANになったりXCPに変わっただけだ。
構成について
つまり論理的にはシンプル。
そして、それら機能を複数のノードに割り当てて、信号の経路を確保するために複雑になったってことか。
その通り。
最初は純粋にフィードバックループだけで確認していたものを
実際の役割別に分割。
その分割した姿をPC上でシミュレーションする。
ってのが今回の目的だな。
なんか、シミュレーションでやっていたものを
別の形でシミュレーションしてるから話がややこしくなるんだな。
まぁ各処理をノード分割すると同時に実機にしてしまうってのもありだが、
今回のようにノード分割の状態に置いてもシミュレーションにしておくといろいろ利点が出てくる。
ほう？
例えばどんな？
例えば、以下のパターンかな
- 指令器と制御対象を偽物にして実ECUをテスト
- ECUと制御対象を偽物にして指令器をテスト
- 指令器とECUを偽物にして制御対象をテスト
あーなるほど！
一部だけを本物にしてそれに対するテストができるのか。
今回はECUは1個想定だが、これが複数ECUとかになると、さらに効果は大きくなるね。
確かにECU間連携とかになると、異なるECUサプライヤのECUに相当するものを用意しなきゃいけないから、結構大変なんだよねー。
最初から全部がシミュレーションできる環境があって、その一部だけを本物に差し替えればOKって状態だとすごく助かると思う。
まぁ今回の我々のやってる範疇ではそこまでは(めんどくさくて)やらないけどね。
(途中、「めんどくさくて」って心の声が聞こえたような・・・。)
構成の確認もできたんで、次回が実際に動作実験する回となる。
まとめ
まとめだよ。
- 構成がややこしいことになってきたので仮想ECUと仮想HILSの実験構成を再確認。
- ネットワーク構成と論理的構成を確認。
- 論理的構成はModelicaモデルベースでシンプルだが、ネットワーク構成は各信号をCANやXCPに変えてるため複雑化。
- このようにノードを分割しておくと部分的に実物に差し替えるなどがし易くなる。
バックナンバーはこちら。
コメント