バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はODSとMDFの具体的な問題に突入。
- 計測結果の再現性ポリシーが違う。
- 計測データのレートの取り方が違う。
- 計測データの格納状態が違う。
などがあった。
今回は「計測データの格納状態」に対しての問題の掘り下げた話をする。
登場人物
博識フクロウのフクさん

イラスト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
ODSとMDFの計測データの格納状態の違いに起因する問題

前回の「計測データの格納状態」が割と根深い問題を抱えてそうな言い方だったけど、
具体的にはどういうのがあるの?

まずODS側の理想としては1チャンネル1計測データの構成ではあるのだけど、
これがMDFのレコード構成と相性が良くない。
まぁ相性が良くないだけでMDFのようなレコード構造でも読めなくもないんだけどね。

なんだ。
一応なんとかなるのか。

なのだが、前回もちょっと言ったがunsorted MDFだと事情が変わる。

(まぁそりゃそうだろうねぇ)
sorted MDFとunsorted MDF

まずsorted MDFのデータ構造を元にODSが参照するイメージを図示すると以下のイメージになる。
尚、4チャンネル1レコードの構成。


これは分かりやすい。
実際はリニアなデータ配置になるから、
今回の図だと4チャンネル飛ばしでデータを参照すれば見たいチャンネルのデータが参照できるってことか。

次にunsorted MDFの構造を図示する。
4チャンネルのレコードと5チャンネルのレコードが混在した状態だ。


予想通りだけど、これだとうまく走査できないってところか・・・。

というわけでMDFはsorted MDFが推奨ってのが自動車業界の流れになっている。

あ、ちゃんと歩み寄りみたいなのはあるのね。
それでも・・・

と言ってもsorted MDFもODSが得意な参照方法とは言い難い。
データ量が増えれば増えるほど非効率な参照方法だからね。

そこはどうにもならないのかな?

MDF仕様もversion UPしていくだろうから、
今後、もしかしたらODS都合のチャンネル別にデータが固まってるMDF仕様ってのも出てきて、ツールベンダ―側の生成するMDFもODS都合MDF推奨ってことになる可能性は高いな。
もしくはコンバータ付属とか。

そこは、うまく調整して便利になっていくと良いね。
まとめ

まとめだよ。
- ODSとMDFの計測データの格納状態の違いに起因する問題。
- MDFのレコードを走査する仕様はODS側にある。
- unsorted MDFの場合、ODSのレコード走査仕様は使えない。
- よって、自動車業界としてはsorted MDF推奨の流れ。
- さらにMDF仕様がversion UPしてODS都合の仕様になる可能性もある。
バックナンバーはこちら。
コメント