変換
OK/NG自動 判定モニタ
不具合 解析
vECU による網羅的検証
アルゴリズムの評価は MILS/SILS で 実行可能だが、多重割込みの影響、
入力信号のチャタリング時の動作、
入力タイミングの差による影響など、
時間軸に依存した検証はSPILSでな
ければできない。
２．５ vECUによる網羅的検証 ＜続＞
( ６ ) ．用途
① 設計確認・・・・ソフト設計時に机上で動作を確認
ｖ HILS だとソフト部品単体でも動的評価可能
② HILS 検査の代用・・・オフショア、外注先、先行開発時などハードが無い場合
のソフト検査（結合検査、動的評価）
＊アルゴリズム評価はSILSでHILSの代用が可能だが、時間依存の強い検査内容 （多重割込み、非同期動作、応答遅れなど）は時間精度の高い SPILS を使用
◆テストパターンおよび判定方法
・テストパターンおよび判定ロジックの作成は
専用のツール（ HILS と同じ）を使用
２．５ vECUによる網羅的検証 ＜続＞
( ７ ) ．主要要件
①時間精度
・ CPU 負荷見積もりや応答遅れに関する評価では 5 ％程度。
１０％程度は余裕を持って設計するので、時間精度そのものは重要でない。
（クリティカルな設計をする場合は実ハードで確認を行う。）
・割込みや IO のディレイ、カウンタ等の評価ではクロックカウンタの精度でよい。
（例えば、パルス周期の計測ではパルス間の時間を計測するが、重要なのは 実時間精度ではなくパルス間のクロックのカウント値である。）
②処理スピード
・網羅的評価では数多くのテストを繰り返し実行するので早ければ早いほど良い ( 実用上は実時間と同等であればよい）
・設計確認では対面実行するので、できれば実時間と同等、最悪でも 1/10 以上
③ユーザインタフェース ( ＵＩ )
・ UI に限らず、プラントモデルやハードウェアモデル、検査パターンは資産活用
の観点から HILS ～ MILS まで流用できることが望ましい。
２．５ vECUによる網羅的検証 ＜続＞
(８)．現状の実現状況
社内活用中。
但し、SPILSの需要は低下。（通常の評価はイベント駆動型のSILSへ移行）
（オブジェクト変換によるイベント駆動型のSILSはSPILSの範疇か？）
(10)．今後の課題
・メンテナンス要員の確保
評価システムを立ち上げるのに専門知識必要。I/Fが標準化されモデルが流通するようにな
実績
（SPILSによる効果とSILSによる効果の判別はできない。）① 検査工程の工数削減 ・・・ 50%減
② 検査期間の短縮 ・・・・・・・・約1/2に短縮
③ 設計工程の工数削減 ・・・ 55%減
④ 設計工程で検証漏れ ・・・ ﾛｼﾞｯｸに関わる検証漏れ 0件
(９)．想定効果
２．５ vECUによる網羅的検証 ＜続＞
(11) ．参考文献
オールソフトシミュレーションによる制御ソフトウェア開発：富士通テン技法 47号(2006/06) ｶﾞｲｱｼｽﾃﾑ）田中、豊通エレ）香野、富士通テン）森山他http://www.fujitsu-ten.co.jp/gihou/jp_pdf/47/47-4.pdf
Virtual CRAMAS (SILS)へのISSレス技術の適用：富士通テン技法52号(2008/12)
富士通テン）森山、深澤他http://www.fujitsu-ten.co.jp/gihou/jp_pdf/52/52-1.pdf
第１章 はじめに 第２章 現状事例（ユースケース）
２．１ 事例１：仮想車一台分シミュレーション ＜ホンダ＞
２．２ 事例２：バーチャルＨＩＬＳ （vHILS) ＜日立＞
２．３ 事例３：CPU負荷計測 ＜カルソニックカンセイ＞
２．４ 事例４：故障注入・故障解析 ＜デンソー＞
２．５ 事例５：vECUによる網羅的検証 ＜富士通テン＞
２．６ 事例６：ソフトウェア機能検証 ＜アイシン精機＞
第３章 分析 第４章 まとめ
3
10
11
18
30
39
48
58
65
74
２．６ ソフトウェア機能検証
( １ ) ．ユースケース名称 ソフトウェア機能検証
( ３ ) ．作業項目
・ＨＩＬＳの補完
・オブジェクトレベルのテスト
・ＵＩはSimulinkイメージ
( ４ ) ．目的
・機能安全対応
( ２ ) ．概要
・ソフトウェア機能検証をオブジェクトバイナリーレベルで実施できる環境。
・統合されたＥＣＵの個別ソフトのハザード分析を、シミュレーションで実施できる環境。
情報提供：アイシン精機
２．６ ソフトウェア機能検証 ＜続＞
( ５ ) ．内容説明
従来： ＩＩＳシミュレータでソフトウェアの機能検証を行ってきた。主として単体テストを担ってきた。
ユースケース： 利用コンパイラのコード生成信頼性を含んで、生成されるバイナリーレベルで、よ り実機相当環境でのシミュレーション検証が可能となる。
特に車両条件設定の困難な、場面や故障モード再現で危険であったり、再現性が難しい場面は、
ＨＩＬＳまたは、シミュレーション検証が必要となる。
より詳細な解析を伴う評価の場面では、ＨＩＬＳよりも、シミュレーションによる内部状態可視化で のモニター、ロギング、解析が効果的である。
（他の内部状態可視化手段として、ハードウェア実機でも、NBD
やJP-wire
などのマイコン内部モニタ手段もある）統合制御ＥＣＵでは、個別ソフトモジュールの、内部状態可視化での解析切り分けが難しいが、ソ フトシミュレーションではより容易。
必要条件： マイコン周辺で協調動作する ＩＣモデルや、分布乗数回路モデルを含み、総合する
２．６ ソフトウェア機能検証 ＜続＞
( ５ ) ．内容説明 ＜続＞
・新規マイコンへの、早期対応
シリーズ化されるマイコンのＩ／Ｏバリエーションに、すべて早期に対応することは、タ イムリーに難しい場面がある。タイムリーでないと、評価用実マイコンが入手できる 時期になり、シミュレータ利用価値が低くなってしまう。
マイコンコア部分のバイナリーシミュレーションがまず必要で、Ｉ／Ｏ部分は簡易シ
ミュレーション手段との標準拡張インターフエースが存在すれば、Ｉ／Ｏ部動作を
ユーザがカスタム作成できる可能性があり（簡易でよければ）、精度は低いが、検証
は可能となる。開発当初には低精度であっても、対応できるので、標準拡張インター
フエースが提起され普及すると、利用場面が便利である。
２．６ ソフトウェア機能検証 ＜続＞
( ６ ) ．用途
用途１： オブジェクトバイナリーレベルでの、統合ソフトウェア機能検証
用途２： 統合制御されたＥＣＵ等の個別ソフトのハザード分析シミュレーション
◆テストパターンおよび判定方法
・検証設備はmatlab/simulinkなどを利用するなど、従来シミュレーション環境
に組み込まれる用途。
２．６ ソフトウェア機能検証 ＜続＞
( ７ ) ．主要要件
①時間精度
用途１：時間精度は、フローの前後関係が保証されればよい。
用途２：マイコン周辺で協調動作する ＩＣモデルや分布乗数回路モデルを含み総 合するＥＣＵモデルの実現の仕組みがあること。およびＥＣＵの外側のセンサー、
アクチュエータモデル、メカモデル、車両モデル、ネットワークモデルを収集し、協 調シミュレーションが出来るためには、それらと時間精度、前後関係を合わせこむ 同期機能を有すること。またはマイクロセカンドの時間精度が必要。
②処理スピード
・パソコン上で実機相当速度またはその10倍遅い範囲。夜間テストが可 能なため、遅い速度は検証場面により、利用可能。
③ユーザインタフェース(ＵＩ)
・Matlab/simulinkまたは、相当なインターフェースが利用できる。
④その他
Ｉ／Ｏ部分は簡易シミュレーション手段との標準拡張インターフエースが存在する
２．６ ソフトウェア機能検証 ＜続＞
( ８ ) ．現状の実現状況
・カスタムＩＣモデルや、分布乗数回路モデルの協調シミュレーションが難 しいため、ケースバイケースで実現
( ９ ) ．想定効果
・ＯＥＭからのバイナリー動作環境の提供要請への対応が出来る。
・実機での再現や、動作条件設定が難しい場面や、内部動作確認を同時に行 う解析
(10) ．今後の課題
・ マイコン周辺で協調動作する ＩＣモデルや分布乗数回路モデルを含み、総合する
ＥＣＵモデルの実現の仕組みがあること。およびＥＣＵの外側のセンサー、アクチュ
第１章 はじめに
ドキュメント内
仮想マイコン（バーチャルECU）活用に関する 現状事例（ユースケース）の調査および分析
(ページ 53-65)