仮想ECU活用のためのユーザ導入検討支援ガイド

(1)

仮想ECU活用のための

ユーザ向け導入検討支援ガイド

Rev1.0

2013年7月19日

仮想マイコン応用推進協議会／vECU-MBD WG

(2)

１．仮想ECUシミュレータの導入・活用の狙い

１．１本書の目的

１．２本書の作成経緯

１．３用語

１．４モデルベース開発（ＭＢＤ）

１．５今後のシステムテストの課題

１．６仮想マイコン

１．７仮想ECU

１．８仮想ECUシミュレータ導入の狙い

２．開発プロセス上の位置付け

２．１開発プロセス上の仮想ECU活用場面

２．２ HILS と vHILS

２．３仮想ECU応用モデルベース開発プロセス

３．現状事例（ユースケース）

３．１調査経緯

３．２事例１：仮想車一台分シミュレーション

３．３事例２：バーチャルＨＩＬＳ（vHILS)

３．４事例３：CPU負荷計測

３．５事例４：故障注入・故障解析

３．６事例５：vECUによる網羅的検証

３．７事例６：ソフトウェア機能検証

３．８事例７：フォールト注入

(3)

４．時間精度について

４．１時間精度に関するトレードオフ

４．２時間精度の要求分析

４．３時間精度の誤差発生理由

４．４時間精度の分類定義（ＡＴＡＬ）

４．５時間精度の評価方法

５．複数シミュレータの同期化

５．１複数ECU協調シミュレーションの概要

５．２プラントモデルとコントローラモデルの同期化

５．３複数コントローラモデル間の同期化

６．モデル間インタフェースについて

６．１モデル間インタフェースの分類

６．２モデル間インタフェース仕様検討時の留意点

６．３マイコン内部のモデル間インタフェースの標準化（ＴLMインタフェース）

６．４マイコン外部との通信インタフェースの標準化

６．５周辺モデル付SILSとその標準化

７．ユーザインタフェース(UI)について

７．１ユーザインタフェース(UI)の分類

７．２ユーザインタフェース(UI)仕様検討時の留意点

８．フォールト注入について

８．１フォールト注入のねらい

８．２フォールト注入の分類

８．３フォールト注入仕様検討時の留意点

(4)

９．性能評価（CPU負荷率）

９．１車載制御ソフトウェアにおけるCPU負荷率とは？

９．２ CPU最大負荷率測定の目的

９．３用法

９．４仮想ECUの要件

９．５今後の動向

１０．周辺モデル設計における留意点

(5)

第１章仮想ECUシミュレータの導入・活用の狙い

１．１本書の目的

１．２本書の作成経緯

１．３用語

１．４モデルベース開発（ＭＢＤ）

１．５今後のシステムテストの課題

１．６仮想マイコン

１．７仮想ECU

１．８仮想ECUシミュレータ導入の狙い

１．９機能安全規格ISO26262と仮想ECU

第２章開発プロセス上の位置付け

第３章現状事例（ユースケース）

第４章時間精度について

第５章複数シミュレータの同期化

第６章モデル間インタフェースについて

第７章ユーザインタフェース(UI)について

第８章フォールト注入について

第９章性能評価（CPU負荷率）

第１０章周辺モデル設計における留意点

5 5

(6)

１．１本書の目的

本書は、仮想マイコンおよび仮想ECUシミュレータの活用に関する啓蒙活動の一

環として、自動車分野での利用目的、現状事例（ユースケース）、要件分析、留意

点などを解説し、ユーザ向け導入検討支援ガイドとして纏めたものである。

注意事項：本書の考え方は、あくまで、現状知られている事例と一般的な見解をベースに解説したものである。仮想マイコンおよび仮想ECUシミュレータの導入業務そのものを保証するものではない。従って、個別のシミュレーションシステムに対しては、各社の判断にて検討願いたい。今後、技術動向の変化により、本書の内容に改訂が必要となった場合には、vECU-MBD WGにて審議した上で改訂するものとする。 vECU-MBD WGは、本書の使用により知的財産権の侵害若しくは知的財産権侵害に係る紛議が生じないこと、または本書の使用に関する知的財産権の存在確認及び当該知的財産権に関する実施許諾について、一切の保証を行わない。

(7)

１．２本書の作成経緯

本書の作成経緯、参加メンバは以下のとおりである。（１）作成経緯２０１１年１０月～２０１２年６月本書のベースとなる現状事例などを調査および報告書作成２０１２年７月～２０１３年２月原稿作成および編集２０１３年２月～２０１３年６月レビューおよび改訂（２）参加メンバ（情報提供、原稿作成およびレビュー）・アイシン精機株式会社・イータス株式会社・オムロンオートモーティブエレクトロニクス株式会社・ガイオ・テクノロジー株式会社・カルソニックカンセイ株式会社・株式会社デンソー・日本アイ・ビー・エム株式会社・日本シノプシス合同会社・日立オートモティブシステムズ株式会社・株式会社日立製作所（中央研究所）・株式会社半導体理工学研究センター・富士通セミコンダクター株式会社・富士通テン株式会社・株式会社本田技術研究所・マツダ株式会社・ルネサスエレクトロニクス株式会社・公益財団法人九州先端科学技術研究所

・Australian Semiconductor Technology Company株式会社・TOOL株式会社

(8)

１．３用語

用語、略号説明 ECU 電子制御ユニット MBD モデルベース開発手法。複雑化・高度化した現代の自動車制御システム開発に於て、MATLAB/Simulink等のツール活用によって、制御装置と制御対象の機能をモデル化し、それらを実行可能な仕様書として用いることで、製品ライフサイクル全般に渡った品質向上と開発効率向上を目指した開発手法

MILS Model-in-the-loop simulation。モデルを用いたシミュレーション。Simulinkモデルなどで記述されたアプリケーションソフトをシミュレーション実行できる。

SILS Software-in-the-loop simulation。ソースコードを用いたシミュレーション。C言語などで記述されたアプリケーションソフトをシミュレーション実行できる。

SPILS 注１ _{Simulated-processor-in-the-loop simulation。実装対象プロセッサのモデル（仮想マイコン）を用いたシミュレーショ}

ン。ＯＳなど基盤ソフトも含めて製品と同一のオブジェクトコード（バイナリコード）をシミュレーション実行できる。 PILS Processor-in-the-loop simulation。実装対象プロセッサ（マイコン）を用いたシミュレーション。

HILS Hardware-in-the-loop simulation。実装対象ECUを用いたシミュレーション。

仮想マイコン Virtual Microcontroller。実装対象プロセッサのモデル。マイコン内蔵の周辺回路を含む。ＯＳなど基盤ソフトも含めて製品と同一のオブジェクトコード（バイナリコード）をシミュレーション実行できる。マイコンモデルとも呼ぶ。仮想ECU 注１ _{Virtual ECU。実装対象ECUのモデル。実装対象プロセッサのモデル（仮想マイコン）を含む。ＯＳなど基盤ソフトも}

含めて製品と同一のオブジェクトコード（バイナリコード）をシミュレーション実行できる。バーチャルECU、vECU、 ECUモデルとも呼ぶ。

vHILS 注１ _{Virtual HILS。実装対象ECUのモデル（仮想ECU）を用いてHILSを仮想化したシミュレーション。}

SPILSの応用例の１つである。HILSライクに利用できることが特徴である。バーチャルHILSとも呼ぶ。

注１：別の用語も使われているが、本WGで審議の結果、この表に示すような用語を使用することにした。注２：上記用語および関連用語については、別資料「仮想ＥＣＵに関わる用語集」も参照願いたい。

(9)

１．３用語

シミュレー ション形態 制御ソフト （アプリソフト） 基盤ソフト スケジューラ、割り込み、 ドライバなど マイコン ECU (周辺回路含む) 制御対象（プラント） 車両、センサ、アク チュエータなど MILS モデル ツールの実行制御機能 で代行 なしなし モデル SILS ソースコード （実物を加工し Simullinkに変換） ツールの実行制御機能 で代行 なしなし モデル SPILS 実物（バイナリ） （オブジェクトコード） 実物（バイナリ） （オブジェクトコード） モデル モデル モデル PILS 実物（バイナリ） (オブジェクトコード) ツールの実行制御機能 で代行 実物 （ハードウェア） モデル モデル HILS 実物（バイナリ） (オブジェクトコード) 実物（バイナリ） (オブジェクトコード) 実物 （ハードウェア） 実物 （ハードウェア） モデル

参考：各シミュレーション形態の概要説明

：実物（ハードウェア） ：ソフトウェア（モデル） ：実物（ソフトウェア）

(10)

１．４モデルベース開発（ＭＢＤ）

モデルとは？

仮想システムでのシミュレーションを可能とするもの

資料より引用

(11)

１．４モデルベース開発（ＭＢＤ）

Auto Calibration

HILS テスト

*** ･･ *** …

単体検証

量産

実車テスト

ECU

要求設計ソフトウエア詳細設計仕様設計 Rapid ECU MBD仕様書プラントモデルコントロールモデル要求検証

Vプロセスの実物テスト（右側）前にモデルで問題を抽出

×

プログラミング

開発プロセスでのモデル活用位置付け

実車検証

(12)

１．５今後のシステムテストの課題

今後のネットワークを介した複合システムテストの課題

HILS B-CAN F-CAN

実車テスト

車一台分の大規模HILSテスト

アプリ＋プラットフォーム＋ネットワークのテストは

実ユニット完成後となり問題抽出の早期化が図れない

(13)

１．６仮想マイコン

複数ECUモデルの内の1つまた

は複数ECUのオブジェクトコード

を仮想エミュレーションし車両挙

動と合わせたプログラム挙動解

析が可能な環境

FI ECU ﾓﾃﾞﾙ VSA ECU ﾓﾃﾞﾙｴｱｺﾝ ECU ﾓﾃﾞﾙｷｰﾚｽ ECU ﾓﾃﾞﾙ B-CAN F-CAN

仮想ECUで検

証後、実ECU

を用いたHILS

最終検証

Plants Controller

仮想マイコン（マイコンモデル）: Virtual Microcontroller

実装対象プロセッサのモデル。マイコン内蔵の周辺回路を含む。

OSなど基盤ソフトも含めて製品と同一のオブジェクトコード(バイナリコード)をシミュレーション実行できる。

(14)

１．７仮想ＥＣＵ

制御対象モデル ECUモデル 入力モデル マイコンモデル 出力モデル

システム階層

ユニット階層

パーツ階層

仮想マイコン 実オブジェクトコード エンジン回転数ＡＴギア 仮想ECU

仮想ＥＣＵ（バーチャルＥＣＵ、ＥＣＵモデル）： Virtual ECU

実装対象ECUのモデル。実装対象プロセッサのモデル（仮想マイコン）を含む。

OSなど基盤ソフトも含めて製品と同一のオブジェクトコード(バイナリコード)をシミュレーション実行できる。

(15)

１．８仮想ECUシミュレータ導入の狙い

Auto Calibration

HILS テスト

*** ･･ *** …

単体検証

量産

実車テスト

ECU

要求設計ソフトウエア詳細設計仕様設計 Rapid ECU MBD仕様書プラントモデルコントロールモデル要求検証

実ユニットレスでオブジェクトコードベースのテスト実行（製品と同一ソフトの検証）

実行時間を実時間かそれ以下に短縮したい

実機では実施困難なテスト（フォールト注入テストなど）を行いたい

×

プログラミング

実車検証

OBJECT CODE

新ループ

(16)

2012/12/21 16 16

１．９機能安全規格ISO26262と仮想ECU

自動車用機能安全規格ISO26262は、2011年11月に制定された。

この中で、仮想ECUの活用に関連する記述として以下がある。

Part6(ソフトウェア)-10節 Software integration and testing

～

10.4.8 The test environment for software integration testing shall correspond

as closely as possible to the target environment

～

NOTE 2 ～ Such test environments can be the target processor for final integration,

or a processor emulator

or a development system for the previous integration steps.

テスト環境は極力

ターゲット環境と一致させること

テスト環境は、プロセッサエミュレータでもよい

⇒基盤ソフト含めてオブジェクトコードがそのまま走る

仮想ECUを適宜活用可能

ソフトウェア統合テストのテスト環境

(17)

2012/12/21 17 17

１．９機能安全規格ISO26262と仮想ECU

Part5(ハードウェア)-10節 Hardware integration and testing

備考：＋：推奨、＋＋：強く推奨

Part4(システム)-8節 8.4.2 Hardware-software integration and testing

安全度水準が高い場合 （ASIL-C以上） ↓ フォールト注入テストの実施が 要求される。 備考：＋：推奨、＋＋：強く推奨

フォールト注入テストのテスト環境

＋＋＋＋ ＋＋＋＋ ハードウェアに対するフォールト注入テストは、モデルベースのフォールト注入シミュレーションでもよい。 ⇒仮想ＥＣＵを適宜活用可能

b) ～ Model-based fault injection (e.g. fault injection done at the gate-level netlist level) is also

applicable, especially when fault injection testing is very difficult to do at the hardware product

level.

(18)

第１章仮想ECUシミュレータの導入・活用の狙い

第２章開発プロセス上の位置付け

２．１開発プロセス上の仮想ECU活用場面

２．２ HILS と vHILS

２．３仮想ECU応用モデルベース開発プロセス

第３章現状事例（ユースケース）

第４章時間精度について

第５章複数シミュレータの同期化

第６章モデル間インタフェースについて

第７章ユーザインタフェース(UI)について

第８章フォールト注入について

第９章性能評価（CPU負荷率）

第１０章周辺モデル設計における留意点

(19)

２．１開発プロセス上の仮想ＥＣＵ活用場面

19 実ECU 統合段階ソフト制御モデルソフト制御モデルソフト制御モデルソフト制御モデルソフト制御モデルソフト制御モデル ECUハードウエアモデル ソフトプラットフォームモデル 制御アプリソフト オブジェクトコード ソフトプラットフォーム オブジェクトコード ECUハードウエアモデル 制御アプリソフト Cソースコード モデル仕様段階 Cソースコード生成段階マイコン組込み段階要求仕様段階

ソフト開発の流れ

ハード開発の流れ

開発段階に応じたハード・ソフトの最適モデル活用

ECUハードウエアモデル 仮想マイコン

この段階でも

モデル活用

したい

ECUハードウエア回路

MILS SILS SPILS 仮想ECU HILS

SW/HW 分割 SW/HW 統合 ソフトプラットフォームモデル オブジェクトコード マイコン ECUハードウェア 実ECU

(20)

２．１開発プロセス上の仮想ＥＣＵ活用場面

20

単体実機

検証

量産要求設計ソフトウエア詳細設計仕様設計

各設計プロセスの階層間をさかのぼった仮想ECU活用

実装

実車検証

要求側

供給側

要求側

供給側

単体実機レス

デバッグ＆検証

実車レス

デバッグ＆検証

仮想マイコン 仮想ECU コード コード ECU内部要求モデル システム要求モデル ソフトウエア要求モデル ECU要求モデル コード 仮想システム コード

(21)

2012/12/21 21

２．２ HILS と vHILS(Virtual HILS)

21 HILS 01001010 01101011 11101010 01010111 ・・・・・・・・ HILS装置 車両モデル ECU（実機） ソフトウェア (バイナリコード)

ＨＩＬＳ（Hardware-in-the-loop Simulator)

■構成：実ＥＣＵ＋プラントモデル

■特長

－製品と同一のバイナリコードを動作検証

－実機ベースのソフトウェア検証

■短所：場所制約、ターゲット環境切替工数、再

現性不確定、観測性制約、フォールト注入の制

約など

ｖＨＩＬＳ（Virtual HILS)

■構成：

仮想ＥＣＵ

＋プラントモデル

■特長

－製品と同一のバイナリコードを動作検証

－実機ベースと

ほぼ等価

なソフトウェア検証

－

実機レス

（実機不要、実機完成前でもテスト可）

－

場所制約、ターゲット環境切替工数、再現性

不確定、観測性制約、フォールト注入の

制約などの実機

(HILS)の短所は解決

－クラウド活用による遠隔利用や並列実行可

vHILS

(Virtual HILS)

プラントモデル (車両モデル) 仮想ECU シミュレータ Co-sim マイコンモデル（仮想マイコン）コントローラモデル (仮想ECU) ソフトウェア（バイナリコード） Simulator

(22)

２．２ HILS と vHILS

22 HILS ECU実機オブジェクトコード

仮想ECUを使ったHILS つまり vHILSを実現するには、HILSと比べて以下のモデル

が必要になる

・マイコンモデル

・ECUの入出力回路のモデル(H/Wモデル)

なお、HILS/vHILS共に、プラントモデルとしてセンサ・アクチュエータのモデルも必

要であるが、HILSの場合は実機を利用することも可能である。

プラントモデル SPILS用ツール PC/サーバマイコンモデル H/W モデル H/W モデルオブジェクトコード vHILS 仮想_ECU

ECU・センサ・アクチュエータの実機完成前に各種モデルが整うと、vHILSとしてのメ

リットが大きい（ソフトウェアのテストを先行できる）

⇒ 実機完成前に、モデルの作成または調達ができることが望ましい

(23)

２．３仮想ＥＣＵ応用モデルベース開発プロセス

23

要求分析

システム設計

システムテスト

車両テスト

実装単体検証 Validation 結合検証 要求分析 コーディング 構成設計 単体検証 Validation 詳細設計 結合検証

ECUソフト

ECUハード・センサ・アクチュエータ

実機の完成前に、vHILSによる実機レスのシステムテストを行う場合の

開発プロセスを以下に示す

実機レス

システムテスト

オブジェクトコードと

各部品モデル（ハードウェアモデル）を

組込んで実機レスシステムテスト

要求分析 構成設計 詳細設計 モデリング テスト・検証 実装単体検証 Validation 結合検証実装 単体検証 Validation 結合検証 要求分析 構成設計 詳細設計 モデリング テスト・検証 要求分析 構成設計 詳細設計 モデリング テスト・検証 ドメイン毎に担当範囲は変化

実機

部品

モデル

オブジェクト

コード

自動車メーカーサプライヤ

(24)

第１章仮想ECUシミュレータの導入・活用の狙い

第２章開発プロセス上の位置付け

第３章現状事例（ユースケース）

３．１事例調査経緯

３．２事例１：仮想車一台分シミュレーション

３．３事例２：バーチャルＨＩＬＳ

３．４事例３：CPU負荷計測

３．５事例４：故障注入・故障解析

３．６事例５：vECUによる網羅的検証

３．７事例６：ソフトウェア機能検証

３．８事例７：故障注入（フォールト注入）テスト

第４章時間精度について

第５章複数シミュレータの同期化

第６章モデル間インタフェースについて

第７章ユーザインタフェース(UI)について

第８章フォールト注入について

第９章性能評価（CPU負荷率）

第１０章周辺モデル設計における留意点

(25)

３．１事例調査経緯

備考：本章では事例提供いただいた会社名を以下のように略記させていただく。正式会社名略記アイシン精機株式会社アイシン精機カルソニックカンセイ株式会社カルソニックカンセイ株式会社デンソーデンソー日立オートモティブシステムズ株式会社および株式会社日立製作所日立富士通テン株式会社富士通テン株式会社本田技術研究所ホンダ本調査の実施時期、参加メンバは以下である。（１）調査実施時期２０１１年１０月～２０１２年４月（含む資料作成およびレビュー）（２）参加メンバ・アイシン精機株式会社・ガイオ・テクノロジー株式会社・カルソニックカンセイ株式会社・株式会社デンソー・日本アイ・ビー・エム株式会社・日本シノプシス合同会社・日立オートモティブシステムズ株式会社・株式会社日立製作所（中央研究所）・株式会社半導体理工学研究センター・富士通セミコンダクター株式会社・富士通テン株式会社・株式会社本田技術研究所・マツダ株式会社・ルネサスエレクトロニクス株式会社（３）追加調査 2012年度の事例調査から事例７を追加した。

(26)

３．１事例調査経緯

vECU/vHILS利用目的整理表と個別事例情報提供担当

事例（ユースケース）を利用目的ごとに分類したものを以下の表に示す。本調査では、その代表事例

について、各社にて分担して自社事例を中心に調査し纏めた。

(27)

３．１事例調査経緯

◆調査項目

１．ユースケース名称２．概要３．作業項目４．目的５．内容説明フリーフォーマットで内容紹介６．用途７．主要要件時間精度、処理スピード、ユーザインタフェース(ＵＩ) など、シミュレータに対する主要要件８．現状の実現状況（あるいは見通し）９．想定効果１０．今後の課題１１．参考文献 事例（ユースケース）の調査にあたっては、以下の項目に従って纏めた。 なお、本章の内容は、１１年度調査結果である。現時点では一部状況変化している場合もあるので、留意願いたい。（特に、「８．現状の実現状況（あるいは見通し）」「１０．今後の課題」など） 備考：第３章（現状事例）と第４章以降の位置づけ 本ガイドの作成においては、現状事例をまず分析して、そこから得られた教訓も考慮しながら、第４章以降に 留意すべきことを整理展開した。

(28)

３．２事例１：仮想車一台分シミュレーション

１．ユースケース名称

仮想車一台分シミュレーション

３．作業項目

複数ＥＣＵの実機レス統合試験

４．目的

検証作業効率アップ

検証期間短縮

２．概要

実ＥＣＵを揃えてHILSシステム構築しなくとも検証可能

ソフトはオブジェクトさえあれば検証可能（ソースコードやモデルは不要）

UIはHILSモニター画面ライク

情報提供：本田技術研究所

事例１

28 28

(29)

３．２事例１：仮想車一台分シミュレーション

29 29

５．内容説明

HILS B-CAN F-CAN

Full Vehicle HILS

B-CAN F-CAN Vehicle Environment Operation Pattern

I/F I/F I/F I/F

Virtual MCU Model Actual Object Code

Full Vehicle Off-Line simulation

Actual Object Code Actual Object Code Actual Object Code

Virtual MCU Model Virtual MCU Model Virtual MCU Model

(30)

３．２事例１：仮想車一台分シミュレーション

30 30

５．内容説明

＜続＞ 制御対象モデル ECUモデル 簡易入力モデル マイコンモデル 簡易出力モデル システム階層ユニット階層パーツ階層 仮想マイコンモデル 実オブジェクトコード エンジン回転数ＡＴギア 仮想ECUモデル

１機能ECUでの仮想ECUモデル化技術はあるがECU内回路のモデル対応も必要

故障診断状態でのECU動作

(31)

３．２事例１：仮想車一台分シミュレーション

31 31

６．用途

①走行テストモード中の故障診断警告発生がないことのテスト確認

②バッテリー電圧変動時の故障診断警告発生がないことのテスト確認

◆テストパターンおよび判定方法

走行モード・操作パターンに対する故障診断警告信号の有無確認

ギア段時間車速走行位置バッテリー電圧バッテリー電圧変動パターン走行テストモード

(32)

３．２事例１：仮想車一台分シミュレーション

32 32

７．主要要件

①時間精度

車1台分としてはネットワーク通信の信号レベルの再現の観点から

500kbpsの信号再現ができると良い（サンプリング周波数５MHｚ 0.2μS）

エンジン回転の割り込みやモータ回転センサへの対応は個別HILSとし

車1台分ではサンプリング周期としては1mS程度が妥当と考える。

②処理スピード

実時間相当または実時間より短い時間での処理を希望

③ユーザインタフェース(ＵＩ)

HILSモニター画面ライク

(33)

３．２事例１：仮想車一台分シミュレーション

33 33

８．現状の実現状況

複数ECUでの実現は未

当面は単体ECUに対するHILSの仮想化を進め、シミュレーションスピードの向

上に合わせ１台分への対応展開が必要と思われる

９．想定効果

大規模HILSの台数削減

テスト設備の省スペース化

テスト環境設定時間及び切り替え時間の短縮化

並列実行によるテスト時間の短縮

10．今後の課題

・マイコンモデル供給体制

・シミュレーションの高速化対応技術の確立

・ECUネットワーク信号の取り扱い手法の明確化

・ECU内の電気回路やセンサアクチュエータのモデル化対応

・仮想マイコンモデルライブラリを意識しない仮想ECUモデルとしての取り扱い

(34)

３．２事例１：仮想車一台分シミュレーション

34 34

11．参考文献



嶋田：車両制御システム開発におけるシミュレーションモデル活用の有効性と課題

ISIT第5回カーエレクトロニクス研究会 2009年4月

http://www.car-electronics.jp/schedule.php?name=CE05



山口、嶋田、ほか：エレクトロニクス設計を支えるシミュレーション技術

自動車技術 Vol.65, No.1 2011年1月



嶋田：仮想ECUモデルベース開発の実現に向けた業界縦断型取り組み

ISIT第9回カーエレクトロニクス研究会 2011年10月

http://www.car-electronics.jp/schedule.php?name=CE09

(35)

３．３事例２：バーチャルＨＩＬＳ

１．ユースケース名称

バーチャルＨＩＬＳ（vHILS)

３．作業項目

ソフト機能検証

HILSの補間

オブジェクトレベルのテスト

４．目的

検証作業効率アップ

検証期間短縮

２．概要

HILSの補間

クラウド活用して回帰テストを短期間に終わらせる（例：３日→１晩）

UIはHILSモニター画面ライク

情報提供：日立オートモティブシステムズ（株）および (株)日立製作所／中央研究所 35 35

事例２

(36)

３．３事例２：バーチャルＨＩＬＳ

36 36

①ソフト回帰テスト（ＨＩＬＳの補間）

クラウド活用して回帰テストを短期間に終わらせる

②ソフト結合テスト（ＨＩＬＳの補間）

テストケースによっては、必ずしもＨＩＬＳ上でなく、ｖＨＩＬＳ上でのテストで代用

③ＨＩＬＳの代替

ＨＩＬＳ環境の構築が技術的に困難な場合、あるいは、

ｖＨＩＬＳのみでも実効上許容可と判断された場合

◆テストパターンおよび判定方法

→ＨＩＬＳの場合と同等または過去テスト結果との一致確認

(43)

３．３事例２：バーチャルＨＩＬＳ

43 43

７．主要要件

①時間精度

・タスク周期は、１ms程度

（製品分野によっては、一部、100μs程度のタスクもある）

・プロセッサ内の命令実行速度は、ある程度考慮要だが、

３．４事例３：CPU負荷計測

46 46

事例３

１．ユースケース名称

CPU負荷計測

３．作業項目

ソフト性能評価

４．目的

検証作業効率アップ

検証期間短縮

２．概要

負荷率測定作業の容易化

UIはデバッガーライク

情報提供：カルソニックカンセイ（株）

(47)

３．４事例３：CPU負荷計測

47 47

５．内容説明

５．１．CPU負荷計測とは

実行周期実行時間

CPU負荷率(%) = 最大実行時間÷実行周期＊100 で求める。

※実行時間が最大となるテストパターンを入力し、測定する。 関数1 関数2 割込1 関数3

(48)

３．４事例３：CPU負荷計測

48 48

テストパターン

入力装置(HILS等)

５．内容説明

＜続＞テストシナリオ

入力

出力

_最大実行

時間

(負荷)

ｿｰｽ

ｺｰﾄﾞ

入力

ｿｰｽｺｰﾄﾞﾃｽﾄｼﾅﾘｵ

５．２．現状の実施内容

ターゲットボード＋エミュレーターデバッガで最大実行時間(負荷)

となるテストを実行。

デバッガ

ICE

ターゲット

ボード

(49)

３．４事例３：CPU負荷計測

49 49

５．３．現状の問題点

５．内容説明

＜続＞

①ターゲットボード、エミュレーターデバッガ等の設備が必要

②ターゲットボード等の開発拠点とソフト開発拠点が違う場合、

設備を送付しなければならない

③CPU負荷測定用のテストを自動で実施する為には、HILS等の

設備が必要

(50)

３．４事例３：CPU負荷計測

50 50

５．内容説明

＜続＞

５．４．理想形

テストシナリオ

入力

出力

_最大実行

時間

(負荷)

SPILS

ソースコードとテストシナリオを入力し、最大実行時間(負荷)

を算出する。

ｿｰｽ

ｺｰﾄﾞ

入力

ｿｰｽｺｰﾄﾞﾃｽﾄｼﾅﾘｵ

(51)

３．４事例３：CPU負荷計測

51 51

６．用途

①ターゲットボード/デバッガの代替

→ 従来の測定方法では、ターゲットボード/デバッガが必要。

SPILSで実施できればSPILSの入ったPCのみで実施可能。

②テストパターン入力装置(HILS等)の代替

→ 負荷測定の為のテストパターン入力が容易。

◆テストパターンおよび判定方法

ターゲットボード/デバッガ使用時と同等または過去テスト結果との一致確

認

(52)

３．４事例３：CPU負荷計測

52 52

７．主要要件

①時間精度

・誤差数%以内

注：ユーザーとしては、実マイコンでのクロック数と完全一致することが望ま

しいが、誤差数％以内とし、ユーザーの運用でカバーする。

「４．２時間精度の要求分析」を参照

②処理スピード

・実機以上の処理スピードが出せることが望ましい(Must要件ではない)

※自動化等により、人手がかかる時間が削減できれば良い

③ユーザインタフェース(ＵＩ)

・CPU負荷測定結果が精度良く算出できればUIは規定しない

(53)

３．４事例３：CPU負荷計測

53 53

８．現状の実現状況

技術的には実現可能

９．想定効果

・試験環境の台数ネックを解消でき、固定資産削減が可能

・グローバルで実施可能(PCさえあれば、ボード等の準備無しで実施可能)

10．今後の課題

・マイコンモデル提供スキーム確立 (精度モデル)

・SPILSへの入出力I/F

(54)

61 61

(62)

３．６事例５： vECUによる網羅的検証

62 62

事例５

１．ユースケース名称 vECUによる網羅的検証

３．作業項目

組合せ、割り込み、動作タイミングのズレによる異常動作検出

（潜在的バグの検出）

４．目的

検証作業効率アップ 検証期間短縮

２．概要

ソフトウェアの設計検証を網羅的に実行。

ＨＩＬＳ用のモデルおよび検査パターンを流用。

情報提供：富士通テン

(63)

３．６事例５： vECUによる網羅的検証

63 63

５．内容説明

共有設備（予約制）

 準備に時間がかかる

ECU手配(約3か月)、ﾊｰﾈｽ作成(約2週間)、ｾｯﾃｨﾝｸﾞ (約2日)

 設備の移動困難

・・・

本体、 PC、ＥＣＵ、擬似負荷等、必要スペース約5㎡

 高価

・・・1台500万～2000万

⇒ 事前に計画立て、関連部署と連携を取り、計画に沿った準備が必要

 設計段階では使用できない

・上流工程のツールとして使えない

・ソフトをＥＣＵに実装しないと使えない。

・ソフト設計段階では、設備が揃わない。

HILSの問題点

（問題点）

・設備の空き待ち

・段換え工数発生

・稼働率低下

(64)

３．６事例５： vECUによる網羅的検証

64 64

５．内容説明

＜続＞

ＶｉｒｔｕａｌＨＩＬＳ導入の狙い

実際に動かして検証試作ソフトを作成

1.ソフト設定のみで環境構築

→

設定時間の短縮、開発環境の配付

実装工程での

手戻り無し

レビュー（見える化）ｴﾝｼﾞﾝ回転数

車両モデル

AD CAP 回転数/ 割込み

制御ソ

フ

ト

ＥＣＵモデル

CMP 燃料噴射時間ﾃﾞｰﾀ変換ﾃﾞｰﾀ変換ﾃﾞｰﾀ変換ﾃﾞｰﾀ変換ﾃﾞｰﾀ変換ﾃﾞｰﾀ変換噴射量 +B電圧水温・・・ +B電圧水温・・・

2.設計段階で活用→ECUができる前に検証可能

Virtual HILS

設計者の思い込み

誤解釈

検討漏れ

設計ﾐｽを見つけ即修正

検証結果をそのまま

レビュー資料に利用

(65)

３．６事例５： vECUによる網羅的検証

65 65

５．内容説明

＜続＞

ＶｉｒｔｕａｌＨＩＬＳの構成

仮想環境下でのｼｽﾃﾑ評価をすべてソフトで実現 ⇒ SPILS

MATLAB/Simulink

CoMET/METeor

(Synopsys社)

VPM

(ﾏｲｺﾝｼﾐｭﾚｰﾀ)

ｺｰﾄﾞﾚﾍﾞﾙでのﾏｲｺﾝ

動作をｼﾐｭﾚｰｼｮﾝ

Vehicle Model

MATLAB/Simulink

CRAMAS

条件設定

運転ﾊﾟﾀｰﾝ

ﾃﾞｰﾀ計測･ﾓﾆﾀ

自動判定

自動化

Hardware Model

ECU Model

「Virtual ECU Club™」

株式会社豊通エレクトロニクス

株式会社ガイア･システム・ソリューション株式会社トヨタテクノサービス

富士通テン株式会社

(66)

３．６事例５： vECUによる網羅的検証

66 66

５．内容説明

＜続＞

ｼｽﾃﾑ構成

自動設定

検査ﾊﾟﾀｰﾝ

自動生成

試験実行＆データ計測結果解析 A B’ B’’ B’’’ B’’’’ ・チャタリング試験・条件網羅試験条件Ａ条件Ｂ条件ＣＡＮＤ A B C A

B

・ばらつき試験検査条件設定（SPOC）

変換

OK/NG自動

判定モニタ

不具合解析

vECUによる網羅的検証

アルゴリズムの評価はMILS/SILSで実行可能 だが、多重割込みの影響、入力信号のチャタリング時の動作、入力タイミングの差による影響 など、時間軸に依存した検証はSPILSでなけれ ばできない。

(67)

３．６事例５： vECUによる網羅的検証

67 67

６．用途

① 設計確認・・・・ソフト設計時に机上で動作を確認

ｖHILSではソフト部品単体でも動的評価可能

② HILS検査の代用・・・オフショア、外注先、先行開発時などハードが無い場合

のソフト検査（結合検査、動的評価）

＊アルゴリズム評価はSILSでHILSの代用が可能だが、時間依存の強い検査内容（多重割込み、非同期動作、応答遅れなど）は時間精度の高いSPILSを使用

◆テストパターンおよび判定方法

・テストパターンおよび判定ロジックの作成は

専用のツール（HILSと同じ）を使用

・ATG（自動テスト生成）は現在検討中

(68)

３．６事例５： vECUによる網羅的検証

68 68

７．主要要件

①時間精度

・CPU負荷見積もりや応答遅れに関する評価では5％程度。

10%程度は余裕を持って設計するので、時間精度そのものは重要でない。

（クリティカルな設計をする場合は実ハードで確認を行う。）

・割込みやIOのディレイ、カウンタ等の評価ではクロックカウンタの精度でよい。

（例えば、パルス周期の計測ではパルス間の時間を計測するが、重要なのは実時間精度ではなくパルス間のクロックのカウント値である。）

②処理スピード

・網羅的評価では数多くのテストを繰り返し実行するので早ければ早いほど良い

(実用上は実時間と同等であればよい）

・設計確認では対面実行するので、できれば実時間と同等、最悪でも1/10以上

③ユーザインタフェース(ＵＩ)

・UIに限らず、プラントモデルやハードウェアモデル、検査パターンは資産活用

の観点からHILS～MILSまで流用できることが望ましい。

(69)

３．６事例５： vECUによる網羅的検証

69 69

８．現状の実現状況

社内活用中。

但し、SPILSの需要は低下。（通常の評価はイベント駆動型のSILSへ移行）

（オブジェクト変換によるイベント駆動型のSILSはSPILSの範疇か？）

10．今後の課題

・メンテナンス要員の確保

評価システムを立ち上げるのに専門知識必要。I/Fが標準化されモデルが流通するようにな

れば、設計者自身で設定できるようになると考える。

・機能安全への対応

ISO26262ではHILSでオブジェクトコードでの動作確認を推奨しているが、SPILSも HILSと同

等にオブジェクトコードで動作確認をしたものとみなすよう提案すべき。

・活用範囲の拡大

全ての検査をソフトシミュレーションで可能なように機能・性能を上げていく。

実績（SPILSによる効果とSILSによる効果の判別はできない。）

① 検査工程の工数削減・・・ 50%減

② 検査期間の短縮・・・・・・・・約1/2に短縮

③ 設計工程の工数削減・・・ 55%減

④ 設計工程で検証漏れ・・・ﾛｼﾞｯｸに関わる検証漏れ 0件

９．想定効果

(70)

３．６事例５： vECUによる網羅的検証

70 70

11．参考文献



オールソフトシミュレーションによる制御ソフトウェア開発：富士通テン技法 47号(2006/06)

ｶﾞｲｱｼｽﾃﾑ）田中、豊通エレ）香野、富士通テン）森山他

http://www.fujitsu-ten.co.jp/gihou/jp_pdf/47/47-4.pdf



Virtual CRAMAS (SILS)へのISSレス技術の適用：富士通テン技法 52号(2008/12)

富士通テン）森山、深澤他

(71)

３．７事例６：ソフトウェア機能検証

71 71

事例６

１．ユースケース名称

ソフトウェア機能検証

３．作業項目

・ＨＩＬＳの補完

・オブジェクトレベルのテスト

・ＵＩはSimulinkイメージ

４．目的

・機能安全対応

２．概要

・ソフトウェア機能検証をオブジェクトバイナリーレベルで実施できる環境。

・統合されたＥＣＵの個別ソフトのハザード分析を、シミュレーションで実施できる環境。

情報提供：アイシン精機

(72)

３．７事例６：ソフトウェア機能検証

72 72

５．内容説明

従来：ＩSＳシミュレータでソフトウェアの機能検証を行ってきた。主として単体テストを担ってきた。

ユースケース：利用コンパイラのコード生成信頼性を含んで、生成されるバイナリーレベルで、よ

り実機相当環境でのシミュレーション検証が可能となる。

特に車両条件設定の困難な、場面や故障モード再現で危険であったり、再現性が難しい場面は、

ＨＩＬＳまたは、シミュレーション検証が必要となる。

より詳細な解析を伴う評価の場面では、ＨＩＬＳよりも、シミュレーションによる内部状態可視化で

のモニター、ロギング、解析が効果的である。

（他の内部状態可視化手段として、ハードウェア実機でも、 NBDやJP-wireなどのマイコン内部モニタ手段もある）

統合制御ＥＣＵでは、個別ソフトモジュールの、内部状態可視化での解析切り分けが難しいが、ソ

フトシミュレーションではより容易。

必要条件：マイコン周辺で協調動作するＩＣモデルや、分布乗数回路モデルを含み、総合する

ＥＣＵモデルの実現の仕組みがあること。およびＥＣＵの外側のセンサー、アクチュエータモデル、

メカモデル、車両モデル、ネットワークモデルを収集し、協調シミュレーションが出来ることで、対

応が可能となる。このため、それらヘテロジニアスシミュレーション手段との接続が必要。実使用

現場では使用実績の高いMatlab/simulinkをユーザインターフエースだけでなく、それらヘテロジ

ニアスシミュレーション手段とのインターフエースとして、利用できることが、要望。

(73)

３．７事例６：ソフトウェア機能検証

73 73

５．内容説明

＜続＞

・新規マイコンへの、早期対応

シリーズ化されるマイコンのＩ／Ｏバリエーションに、すべて早期に対応することは、タイムリー

に難しい場面がある。タイムリーでないと、評価用実マイコンが入手できる時期になり、シミュ

レータ利用価値が低くなってしまう。

マイコンコア部分のバイナリーシミュレーションがまず必要で、Ｉ／Ｏ部分は簡易シミュレーショ

ン手段との標準拡張インターフエースが存在すれば、Ｉ／Ｏ部動作をユーザがカスタム作成で

きる可能性があり（簡易でよければ）、精度は低いが、検証は可能となる。開発当初には低精

度であっても、対応できるので、標準拡張インターフエースが提起され普及すると、利用場面が

便利である。

(74)

３．７事例６：ソフトウェア機能検証

74 74

６．用途

用途１：オブジェクトバイナリーレベルでの、統合ソフトウェア機能検証

用途２：統合制御されたＥＣＵ等の個別ソフトのハザード分析シミュレーション

◆テストパターンおよび判定方法

・検証設備はmatlab/simulinkなどを利用するなど、従来シミュレーション環境に組み込まれる用途。

(75)

３．７事例６：ソフトウェア機能検証

75 75

７．主要要件

①時間精度

用途１：時間精度は、フローの前後関係が保証されればよい。

用途２：マイコン周辺で協調動作するＩＣモデルや分布乗数回路モデルを含み総合するＥＣＵ

モデルの実現の仕組みがあること。およびＥＣＵの外側のセンサー、アクチュエータモ

デル、メカモデル、車両モデル、ネットワークモデルを収集し、協調シミュレーションが

出来るためには、それらと時間精度、前後関係を合わせこむ同期機能を有すること。

またはマイクロセカンドの時間精度が必要。

②処理スピード

・パソコン上で実機相当速度またはその10倍遅い範囲。夜間テストが可能なため、遅い速度は

検証場面により、利用可能。

③ユーザインタフェース(ＵＩ)

・Matlab/simulinkまたは、相当なインターフェースが利用できる。

④その他

・Ｉ／Ｏ部分は簡易シミュレーション手段との標準拡張インターフエースが存在する

(76)

３．７事例６：ソフトウェア機能検証

76 76

８．現状の実現状況

・カスタムＩＣモデルや、分布乗数回路モデルの協調シミュレーションが難しいため、ケース

バイケースで実現

９．想定効果

・ＯＥＭからのバイナリー動作環境の提供要請への対応が出来る。

・実機での再現や、動作条件設定が難しい場面や、内部動作確認を同時に行う解析

10．今後の課題

・マイコン周辺で協調動作するＩＣモデルや分布乗数回路モデルを含み、総合するＥＣＵモデ

ルの実現の仕組みがあること。およびＥＣＵの外側のセンサー、アクチュエータモデル、メカモ

デル、車両モデル、ネットワークモデルを作成、収集し、協調シミュレーションすることを効率的

に実現する方策の整備。

(77)

３．８事例７：故障注入（フォールト注入）テスト

１．ユースケース名称

故障注入（フォールト注入）テスト

３．作業項目

故障注入・故障解析

４．目的

検証カバレッジ向上

検証作業効率アップ（検証期間短縮）

２．概要

クラウドを活用して、膨大な故障注入（フォールト注入）テストを短期間に

終わらせる

（例：６７万テストケース／６００計算機ノード→１２時間）

情報提供： (株)日立製作所／中央研究所 77 77

事例７

(78)

３．８事例７：故障注入（フォールト注入）テスト

78 78

５．内容説明

(79)

３．８事例７：故障注入（フォールト注入）テスト

79 79

５．内容説明

＜続＞

(80)

３．８事例７：故障注入（フォールト注入）テスト

80 80

６．用途

◆用途

①故障注入（フォールト注入）テスト

クラウドを活用して、膨大な故障注入（フォールト注入）テストを短期間に終わらせる

②ＨＩＬＳの補完

ＨＩＬＳ環境ではフォールト注入テストの実施が困難な場合でも、シミュレータ上では実施可能

◆テストパターンおよび判定方法

→テストパターン：ＨＩＬＳの場合と同等

フォールト注入シナリオ：新規に準備（任意指定またはランダム発生）

判定方法：安全目標を侵害しないこと（例：意図しない加速が発生せぬこと）

備考：

自動車用機能安全規格ISO26262では、ASIL-C以上の場合、フォールト注入テストの実施を「強

く推奨」（実際の運用上は必須）としている。実施形態は、実機テストでもシミュレーションテストで

もよい。

(81)

３．８事例７：故障注入（フォールト注入）テスト

81 81

仮想ECU活用のための ユーザ導入検討支援ガイド