モデルベース開発

事例

【ASAM】最小構成のMBD事例 第2章 その280【MDF⑨】

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

【ASAM】最小構成のMBD事例 第2章 その279【MDF⑧】

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

【ASAM】最小構成のMBD事例 第2章 その278【MDF⑦】

ASAM OSDが育ってきた文化について説明。 車両のNVH(Noise、Vibration、Harshness)評価を想定したもの。 ベンダー的にはあまりMDFは使用しない。 ASAM MDFが育ってきた文化について説明。 ベンダーが積極的にMDF利用。 標準化の認識が日本人的には強烈なギャップあり。
事例

【ASAM】最小構成のMBD事例 第2章 その277【MDF⑥】

MDF仕様単体以外の有用性としてASAM ODSとの連携がある。 ASAM OSDはテスト自動化にあたり、表現の曖昧性に課題とした仕様。 ざっくり言うと「テスト管理のパラメータの標準化」。 ASAM OSDの中のMEASURMENTS領域とDIMENSION&UNIT領域がMDFと関係する。
事例

【ASAM】最小構成のMBD事例 第2章 その276【MDF⑤】

MDFの有用性についての話に突入。 計測生値以外の情報も格納されている。 物理値変換式。 単位。 異なるファイルとの同期を取り易い構造になっている。 複数のDGを読み取る機能があれば、異なるMDF間でも同様の処理になるため、結果的に同期が取れるビューワになることが多い。 動画への参照も可能。
事例

【ASAM】最小構成のMBD事例 第2章 その275【MDF④】

MDFのDGに含まれるCGの数によってunsorted MDFとsorted MDFに分けられる。 unsorted MDFが複数CG、sorted MDFが単一のCG。 Version3は無条件でunsorted MDF相当になる。 Vector MDF ValidatorでMDFの内部構造を参照できる。
事例

【ASAM】最小構成のMBD事例 第2章 その274【MDF③】

今回はMDFを利用することを目的としているのでMDFの細かい仕様は把握する必要はない。 ただ、ポリシーや存在するデータなどは把握しておいた方が良い。 MDF DT内のレコードについて説明。 レコードという単位で格納されている。 このレコードがCGと紐づいた情報。 よって、CGの数だけレコードが混在することになる。
事例

【ASAM】最小構成のMBD事例 第2章 その273【MDF②】

MDFの説明はVersion4のみとする。 ASAM仕様として公開されてるので妥当な判断。 MDFのデータ構造について説明。 基本はASAM公式サイトのMDFで説明されている。 それだけだととっかかりが無さ過ぎるので、簡単に説明する。 MDF内部はHD,DG,CG,CN,DTがツリー構造を取っている。
事例

【ASAM】最小構成のMBD事例 第2章 その272【MDF①】

Python環境下の仮想HILSで収録データが無いことが問題に。さらに収録データフォーマットはMDFが望ましいらしい。MDFはASAMで規定されてる標準仕様。ただしVersion4がASAM仕様で、それより以前のVersionは非ASAM。Version3,Version4のどちらかについて解説していく方向にしたい。
事例

【CANoe】最小構成のMBD事例 第2章 その271【仮想ECU連携⑧】

CANoe仮想HILS、AUTOSAR-XCP仮想ECUの実験構成を再確認 上記の動作確認実施。 かなりキレイな波形が取れている。 CANoe環境であれば1msオーダーの応答性が確保可能。 Python環境、CANoe環境を検証プロセスに含めると確保難な設備利用の回数を減らす効果が期待できる。