第１章 はじめに
３．１ ヒアリング事項、討議事項
本TFにおいては、現状事例（ユースケース）の調査資料を集めた後に、疑問や要望をヒアリングおよび討議 した。その主なものを以下に紹介する。
該当箇所 疑問や要望 回答あるいは討議結果
仮想車一台分シ ミュレーション
バーチャルＥＣＵでは、ＣＡＮのデータ リンク層以上をモデル化し、実行速度 重視のバーチャルＣＡＮを活用するこ とも可能と思われる。
一番の関心事は
CAN
通信時のデータ衝突 により通信が待たされ状態の再現である。このユースケースにおいては、複数ＥＣＵの 統合動作で問題ないかといった検証が主目 的で、主な検証対象は、ＣＡＮデータリンク 層より上位の基盤ソフト、アプリケーションソ フトなどだと思うので、バーチャルＣＡＮの検 討も考えてみたい。
このユースケースにおいて、タスク実 行時間の時間精度はどの程度必要と 考えるか？
CAN
通信でのデータ遅れは考慮してほしい が、タスク実行時間の精度は、周期起動な ので、極端に言えば、ＭＩＬＳと同様でよく、時間ゼロでもかまわない。
３．１ ヒアリング事項、討議事項＜続＞
該当箇所 疑問や要望 回答あるいは討議結果
CPU負荷計測 「実マイコンでのクロック数と完全一致 すること」とあるが、「完全一致」という 要求だと、現実解がなくなってしまう。
許容誤差を示してほしい。（モデルで ある以上、現物との完全一致は保証 困難）
ユーザとしては「実マイコンでのクロック数と 完全一致すること」は必須要件と考えていた。
命令に対するマシンサイクル数は変わらな い様に構築することは可能と思っていた。保 証困難なのであれば、その理由の説明資料 がほしい。
タスク実行時間の誤差
1%
以内でも許 容不可か？誤差１％以内が保証可能であれば、運用で 対処可能かもしれない。但し、
CPU
負荷の 測定について、そのまま置き換えを考えると、完全一致が必須となる。
完全一致保証を究極まで追求させる となると、相当に詳細なモデルにせね ばならないので、実行速度は相当に 悪くなる（２桁以上？）と予想されるが、
どこまでなら許容できるか？
CPU
負荷の測定については、テストケース さえ出せば、ms
オーダーで終了するので、実行速度については、２桁悪くなっても問題 無いと考える。
該当箇所 疑問や要望 回答あるいは討議結果 故障注入・故障解
析
今回紹介の方式では、マイコンモデ ル外部は故障注入に必要な粒度にモ デルを分けて記述することで任意の 粒度で対応できるが、マイコンモデル 内部の故障注入の粒度については、
どのように考えるべきか？
現状では、「マイコンモデル内部を主要ブ ロック(ROM/RAM/プロセッサコアなど）に分 けて定義し、その主要ブロック単位に出力 故障注入ができること」が要求仕様である。
診断機能はこの粒度で入れるため、この粒 度が適切と考えている。 一方、故障注入の 粒度を細かくしすぎると、シミュレーション速 度が遅くなる懸念がある。したがって、シス テムレベルで調べたい場合には、この粒度 でよいと考えている。
３．１ ヒアリング事項、討議事項＜続＞
３．２ 時間精度分析
ユースケース 時間精度 仮想車一台分
シミュレーション
・車
1
台分としてはネットワーク通信の信号レベルの再現の観点から500kbps
の信号再現 ができると良い（サンプリング周波数５MH
ｚ0.2μS
）（本見解には別意見もある。ネットワーク上のアナログ波形が見たいのではなく、ネット ワーク競合待ち状態が考慮されることなので、それを考慮した仮想ネットワークモデルでも よいのではないか？）
・エンジン回転の割り込みやモータ回転センサへの対応は個別
HILS
とし、車1
台分ではサ ンプリング周期としては1mS
程度が妥当と考える。バーチャルＨＩＬＳ ・タスク周期は、１ｍｓ程度 （製品分野によっては、一部、100μｓ程度のタスクもある）
・プロセッサ内の命令実行速度は、ある程度考慮要だが、サイクル精度は
MUST
要件では ない。 （±１０％程度は許容）・タスク周期時間は正確に
・ＣＡＮ通信は、転送遅延やバス占有順序などはある程度考慮要だが、実機との完全一致 は不要。ＨＩＬＳも、最終製品とは完全一致はできないので、同等の精度でかまわない。
CPU
負荷計測 ・実マイコンでのクロック数と完全一致すること（本見解には別意見もある。実マイコンの完全置き換えを狙うのであれば、上記要求とな るが、少し誤差があっても、クリティカルな設計部位は実ハードで追加確認を行うといった 併用運用で活用できるのではないか？）
（次ページに続く）
要求される時間精度を、ユースケースごとに、以下に纏めた。
ユースケース 時間精度 故障注入・
故障解析
・システム検証には
15%
程度以上が望ましいが、故障再現のみではこの限りではないvECU
による 網羅的検証・
CPU
負荷見積もりや応答遅れに関する評価では5
％程度。１０％程度は余裕を持って設計するので、時間精度そのものは重要でない。
（クリティカルな設計をする場合は実ハードで確認を行う。）
・割込みやIOのディレイ、カウンタ等の評価ではクロックカウンタの精度でよい。
（例えば、パルス周期の計測ではパルス間の時間を計測するが、重要なのは 実時間精度ではなくパルス間のクロックのカウント値である。）
ソフトウェア 機能検証
・用途１：オブジェクトバイナリーレベルでの、統合ソフトウェア機能検証 時間精度は、フローの前後関係が保証されればよい。
・用途２：統合制御されたＥＣＵ等の個別ソフトのハザード分析シミュレーション
マイコン周辺で協調動作する ＩＣモデルや分布乗数回路モデルを含み総合するＥＣＵモデ ルの実現の仕組みがあること。およびＥＣＵの外側のセンサー、アクチュエータモデル、メ カモデル、車両モデル、ネットワークモデルを収集し、協調シミュレーションが出来るため には、それらと時間精度、前後関係を合わせこむ同期機能を有すること。またはマイクロ
３．２ 時間精度分析＜続＞
３．３ 考察と今後の対応案
①「プロセッサ命令実行の時間精度」と、「シミュレーション実行速度（およびマイコンモデル 開発工数）」とのトレードオフが課題である。
プロセッサ命令実行の時間精度の完全性を追求する場合のベンダ側の技術的困難性を、
ユーザに理解いただくための説明資料の作成・提供が必要と考える。
また、ユーザにとって、時間精度要求仕様の決め方をガイドする必要があると思われる。
（例：ツール上での負荷80％以内を判定基準とした場合、時間精度の誤差を１％とすれば、
実機では81％以下と推定でき、100%に対してはマージンあるからOKと判断するといったこと で運用できるなど。）
このあたりのことを含めて解説したユーザ向けの「ツール導入ガイド」（案）を整備するとよい と考える。
②プロセッサ命令実行の時間精度は、ユースケースにより、高精度モデル（低速）と高速モ デル（低精度）を使い分けることが必要と思われる。時間精度の種別定義、精度評価手法、
相互利用可能化のためのモデル間インタフェースの標準化などを検討することが望ましいと 考える。
③複数ECU間を接続するインタフェースについて、時間精度と実行速度のトレードオフを考
慮した標準インタフェースモデルを検討することが望ましい。（例：バーチャルCANインタ
フェースの標準化）
３．４ 活動当初の課題との関係
本TFでは、バーチャルECUの活用に当たっての課題を当初検討したが、本調査報告で提案 の対応策との関係を以下に示す。
今回作成済：
現状事例（ユースケース）
調査報告書 提案１：
ユーザ導入ガイド資料作成 提案２：
モデル種別、評価方法、
モデル間インタフェースの標準化 提案３：
複数ECU間の接続インタフェース の標準化
モデリングツール間のモデル流用ができないこと
モデル活用フェーズ毎のシミュレーション動作精度と 実行時間要求の違いによる複数シミュレーション モデル対応の必要性
標準がない
モデルの役割が階層的に定義できていない
当初検討課題 （今回提案と関連するものみ抜粋） 今回提案の対応策
モデリング工数が多大