バックナンバーはこちら。
https://www.simulationroom999.com/blog/model-based-of-minimum-2-backnumber/
はじめに
前回はASAM ODSとASAM MDFの育ってきた文化について説明した。
加えて、ASAMのような「緩い標準化」が日本人的には誤解を招きやすい話も。
今回は具体的に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の具体的な問題

前回の話でそれぞれの仕様の育ってきた文化はなんとなくわかったけど、
それだとそもそも仕様的に噛み合わないんじゃない?

そうね。
噛み合わない方が普通ではある。
しかし、計測という目的が一致しているためか、そこそこ噛み合ってしまってるってのが実情だ。

もしや、そこそこ噛み合ってるが故に、噛み合ってない部分が問題ってパターン?

端的に言うとそうだね。
「同じASAM仕様だから噛み合うべき!」
って考え方もあるだろうが、
前回も話した通りASAM仕様側としては部分最適の結果に過ぎないので
噛み合わない方が普通ではあるから、本来としては幸運と考えるべきなのだが・・・。

経緯を知らない人からしたら、
「噛み合ってないとはけしからん!」
ってことになりそうだなー。

まぁそこら辺はじわじわっと解決方向には向かってるけどね。

じゃー、とりあえず、具体的にどんな問題があるのか教えて。
計測結果の再現性

まずは「計測結果の再現性」だな。

再現性?

MDFの場合はECUから計測した生値と物理値変換式の組み合わせでビューワで表示することを想定してて、この生値が残っていることが重要だったりする。

生値を直接見るわけじゃないから、別に要らないんじゃない?

ECUから取得した値なんで、再度ECUに流し込む場合は生値の方が再現度は高いと言える。

言われてみればそうだね。

対して、ODSの方は分析に使えれば良いのでそれほど生値は重要視されていない。
まぁODSも物理変換式を入れられるんでMDFのような構造は取れなくもないが、
文化的には先に物理値変換しちゃうんだよね。

それだと生値がなくなっちゃうのか・・・。

あと、ODS側は扱うデータ量が半端無いから全てに対して毎回物理変換するのは処理負荷的にもネガになるね。
計測データのレートの考え方

「計測データのレートの考え方」も異なる。

どういうふうに?

ODS側は一定サンプリング。
MDF側は可変サンプリング。
MDFの方はマスターチャネルにタイムスタンプが居るんで、サンプリング間の時間が固定じゃない。

それ、大問題じゃん!

まぁここもODS側のデータ構造としてMDFと同じようにマスターチャネル相当を定義すれば管理できなくもない。
つまりODSの内部データを扱う側がうまくハンドリングすれば対応可能。

なんか段々と無理やり辻褄を合わせてきてる感がにじみ出てきてるよ・・・。
計測データの格納状態

最後に最大に揉めてると思われる「計測データの格納状態」

MDFの方だとChannel Groupで1レコードみたいになってたね。

ODS側の文化だと1チャンネルごとに個別に計測データを抱える文化だな。

MDFみたいにレコードにはしないの?

レコード方式はあくまで計測する側の都合だからね。
管理する側の都合としてはチャンネル別に抱えてたいってことになる。

そこのギャップは埋められてないの?

埋められなくもないのだが、
ここでsorted MDFとunsorted MDFの問題が浮上する。
まぁ掘り下げると長くなるから次回説明だな。

(あ、unsorted MDFの方はレコードがごちゃるからむっちゃ揉めそう)
まとめ

まとめだよ。
- ODSとMDFの具体的な問題に突入。
- 計測結果の再現性ポリシーが違う。
- MDFはECUに生値を入れたい動機がある。
- 計測データのレートの取り方が違う。
- ODSは一定サンプリング、MDFは可変サンプリング。
- 計測データの格納状態が違う。
- ODSはチャンネル別、MDFはCG単位のレコード。
バックナンバーはこちら。
コメント