バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
AsamMdf付属Viewerで各信号を物理値変換含めて確認を始めたところで、
前回はAsamMdf付属Viewerのちょっとした便利な使い方について説明。
引き続き、各信号の確認をしていく。
登場人物
博識フクロウのフクさん
イラスト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
tabular without interpolation
再び、AsamMdf付属Viewerで各信号の物理値変換を含めた確認の続きだね。
前回の手法を使って、t10ms_tabularの
物理変換後の値と生値を表示してみよう。
生値は時刻と同じリニアな値が入ってて、
物理値がtabularで変換されてるから、
階段状になっているわけか。
そうそう。
人間が見る場合は物理値だけでOKなんだが、
ECU内部の変数としていくつだったかを知りたい場合は生値を見るって感じだね。
場合によっては、この生値をECUに対するテストデータとして書き込むこともある。
なるほど。
生値があるとテストもやり易くなるってことか。
ここら辺の理屈は今回のtabularに限らずすべての物理変換で言えるところだな。
tabular with interpolation
次はt10ms_tabular_inpを同じように表示するねー。
うん。
これもOKそうだね。
さっきのtabular without interpolationでは補間がないから、階段状になっていたけど、
今回の信号は線形補間が効くから、表示も指定点間の補間が効いてるし、
レンジ外はそれぞれ両端のサチってる感じだ。
これも想定通りの動きってところだな。
Viewer毎に表示が変わってしまう可能性
でも補間自体の情報はMDFに埋まってるわけじゃないから、
これはViewer側が補間処理をしてくれてるってことなのかな？
うん。
その通り。
とすると、実はViewer毎に微妙に表示が異なるってこともあり得るってことになるのか・・・。
そうだねー。
ほぼ変わらないはずではあるが、
浮動小数点の演算誤差とかも関わってくるから、
同じViewerでもPCが変わると微妙に値が変わるってのもあるかもね。
といっても、浮動小数点の演算誤差まで含めて考えてしまうと、
今回の信号に限らずあらゆる物理値変換がその問題を持ってることになるな。
なるほど。
浮動小数点の演算誤差の問題はシミュレーションのときにも出る問題だよねー。
まぁシミュレーションと比べると遥かにシンプルな演算なので、
現実的には気にするレベルの問題ではないと思ってOKだろうね。
一応、浮動小数点の問題がもっと広い範囲の問題として存在していることは認識しておくことも大事だけど。
まぁそんな感じで「認識しておく」くらいしかできないよねー。
まとめ
まとめだよ。
- AsamMdf付属Viewerで信号確認再開。
- tabular without interpolationを確認。
- tabular with interpolationを確認。
- 補間処理はViewer側で行っているため浮動小数点の演算誤差問題が絡む場合がある。
- 実際は気にするレベルではない。
バックナンバーはこちら。
コメント