仮想マイコン（バーチャルECU）活用に関する 現状事例（ユースケース）の調査および分析

仮想マイコン（バーチャルECU）活用に関する

現状事例（ユースケース）の調査および分析

Rev 1.0

2012年6月1日

仮想マイコン応用推進協議会／vECU-MBD WG／モデル流通TF

＜一般公開用＞

目次

第１章 はじめに

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

２．１ 事例１：仮想車一台分シミュレーション ＜ホンダ＞

２．２ 事例２：バーチャルＨＩＬＳ （vHILS) ＜日立＞

２．３ 事例３：CPU負荷計測 ＜カルソニックカンセイ＞

２．４ 事例４：故障注入・故障解析 ＜デンソー＞

２．５ 事例５：vECUによる網羅的検証 ＜富士通テン＞

２．６ 事例６：ソフトウェア機能検証 ＜アイシン精機＞

第３章 分析

第４章 まとめ

3

10

11

18

30

39

48

58

65

74

第１章 はじめに

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

第３章 分析

１．１ 目的

仮想マイコン（バーチャルECU）活用に関する啓蒙活動の一環として、自動車分

野での現状事例（ユースケース）を整理し、利用目的、必要要件などを明確化す

る。

１．２ 経緯

本調査の実施時期、参加メンバは以下である。

（１）調査実施時期 ２０１１年１０月～２０１２年４月 （含む報告書作成およびレビュー）

（２）参加メンバ

・アイシン精機株式会社

・ガイオ・テクノロジー株式会社

・カルソニックカンセイ株式会社

・株式会社 デンソー

・日本アイ・ビー・エム株式会社

・日本シノプシス合同会社

・日立オートモティブシステムズ株式会社

・株式会社 日立製作所 （中央研究所）

・株式会社 半導体理工学研究センター

・富士通セミコンダクター株式会社

・富士通テン株式会社

・株式会社 本田技術研究所

・マツダ株式会社

・ルネサス エレクトロニクス株式会社

備考： 本書では事例提供いただいた会社名を以下のように略記させていただく。

１．３ 用語

用語、略号

説明

ECU

電子制御ユニット

MBD

モデルベース開発手法

MILS

Model-in-the-loop simulation

モデルを用いたシミュレーション

SILS

Software-in-the-loop simulation

ソースコードを用いたシミュレーション

SPILS

_{Simulated-processor-in-the-loop simulation}

実装対象プロセッサのモデル（仮想マイコン）を用いたシミュレーション

PILS

Processor-in-the-loop simulation

実装対象プロセッサ（マイコン）を用いたシミュレーション

HILS

Hardware-in-the-loop simulation

実装対象ECUを用いたシミュレーション

vECU

_{バーチャルECU}

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

を含む）

シミュレー

ション形態

制御ソフト

（アプリソフト）

基盤ソフト

スケジューラ、割り

込み、ドライバなど

マイコン

ECU

(周辺回路含む)

制御対象（プラント）

車両、センサ、アク

チュエータなど

MILS

モデル

ツールの実行制御

機能で代行

なし

なし

モデル

SILS

ソースコード

（実物を加工し

Simullinkに変換）

ツールの実行制御

機能で代行

なし

なし

モデル

SPILS

実物（バイナリ）

（オブジェクトコード）

実物

モデル

モデル

モデル

PILS

実物（バイナリ）

(オブジェクトコード)

ツールの実行制御

機能で代行

実物

モデル

モデル

HILS

実物（バイナリ）

(オブジェクトコード)

実物

実物

実物

モデル

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

１．４ 調査事例（ユースケース）

目的の視点

機能安全対応

検証作業効率アップ

作業項目

検証カバレッジ向上

検証期間短縮

ソフト機能検証

HILSの補間

オブジェクトレベルの

テスト

事例情報提供：アイシン精機、富士通テン

オブジェクトレベルでのテストカバレッジ向上

事例情報提供：日立

HILSの補間

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

（例：３日→１晩）

ソフト性能評価

事例情報提供：カルソニックカンセイ

負荷率測定作業の容易化

複数ＥＣＵの

実機レス統合試験

事例情報提供：ホンダ

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

能

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

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

の代表事例について、各社にて分担して自社事例を中心に調査し、報告資料に纏めた。

１．５ 調査項目

１．ユースケース名称

２．概要

３．作業項目

４．目的

５．内容説明

フリーフォーマットで内容紹介

６．用途

７．主要要件

時間精度、処理スピード、ユーザインタフェース(ＵＩ)

などに関する要件

８．現状の実現状況（あるいは見通し）

９．想定効果

１０．今後の課題

１１．参考文献

現状事例（ユースケース）の調査にあたっては、以下の目次に従って、調査し

報告資料に纏めた。

第１章 はじめに

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

２．１ 事例１：仮想車一台分シミュレーション ＜ホンダ＞

２．２ 事例２：バーチャルＨＩＬＳ （vHILS) ＜日立＞

２．３ 事例３：CPU負荷計測 ＜カルソニックカンセイ＞

２．４ 事例４：故障注入・故障解析 ＜デンソー＞

２．５ 事例５：vECUによる網羅的検証 ＜富士通テン＞

２．６ 事例６：ソフトウェア機能検証 ＜アイシン精機＞

第３章 分析

第４章 まとめ

3

10

11

18

30

39

48

58

65

74

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

(１)．ユースケース名称 仮想車一台分シミュレーション

(３)．作業項目

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

(４)．目的

検証作業効率アップ

検証期間短縮

(２)．概要

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

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

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

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

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

＜続＞

(５)．内容説明

HILS

B-CAN F-CAN

Full Vehicle HILS

Vehicle

Operation

Pattern

I/F

I/F

I/F

I/F

Full Vehicle Off-Line simulation

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

＜続＞

(５)．内容説明

制御対象モデル

ECUモデル

簡易入力モデル

マイコンモデル

簡易出力モデル

システム階層

ユニット階層

パーツ階層

仮想マイコンモデル

実オブジェクトコード

エ

ン

ジ

ン

回

転

数

Ａ

Ｔ

ギ

ア

仮想ECUモデル

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

故障診断状態でのECU動作

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

＜続＞

(６)．用途

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

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

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

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

ギ

ア段

車速

_テ

リ

ー電圧

バッテリー電圧変動パターン

走行テストモード

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

＜続＞

(７)．主要要件

①時間精度

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

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

_{μ S）}

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

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

②処理スピード

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

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

HILSモニター画面ライク

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

＜続＞

(８)．現状の実現状況

複数ECUでの実現は未

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

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

(９)．想定効果

大規模HILSの台数削減

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

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

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

(10)．今後の課題

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

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

＜続＞

(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

第１章 はじめに

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

２．１ 事例１：仮想車一台分シミュレーション ＜ホンダ＞

２．２ 事例２：バーチャルＨＩＬＳ （vHILS) ＜日立＞

２．３ 事例３：CPU負荷計測 ＜カルソニックカンセイ＞

２．４ 事例４：故障注入・故障解析 ＜デンソー＞

２．５ 事例５：vECUによる網羅的検証 ＜富士通テン＞

２．６ 事例６：ソフトウェア機能検証 ＜アイシン精機＞

第３章 分析

第４章 まとめ

3

10

11

18

30

39

48

58

65

74

２．２ バーチャルＨＩＬＳ

(１)．ユースケース名称

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

(３)．作業項目

ソフト機能検証

HILSの補間

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

(４)．目的

検証作業効率アップ

検証期間短縮

(２)．概要

HILSの補間

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

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

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

２．２ バーチャルＨＩＬＳ

＜続＞

２．２ バーチャルＨＩＬＳ

＜続＞

２．２ バーチャルＨＩＬＳ

＜続＞

２．２ バーチャルＨＩＬＳ

＜続＞

２．２ バーチャルＨＩＬＳ

＜続＞

２．２ バーチャルＨＩＬＳ

＜続＞

２．２ バーチャルＨＩＬＳ

＜続＞

(６)．用途

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

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

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

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

③ＨＩＬＳの代替

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

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

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

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

２．２ バーチャルＨＩＬＳ

＜続＞

(７)．主要要件

①時間精度

・タスク周期は、１ｍｓ程度

（製品分野によっては、一部、100

_{μ ｓ程度のタスクもある）}

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

サイクル精度はMUST要件ではない。 （±１０％程度は許容）

・タスク周期時間は正確に

・ＣＡＮ通信は、転送遅延やバス占有順序などはある程度考慮要

だが、実機との完全一致は不要。ＨＩＬＳも、最終製品とは完全一致は

できないので、同等の精度でかまわない。

②処理スピード

Ｎ並列実行で、実機以上の処理スピードが出せること

（単独でも、実機と同等か、それ以上を期待したいが、MUST要件で

はない。ただし、１／１０以下など極端に遅いのでは困る。）

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

ＨＩＬＳの自動テスト環境と同等のＵＩが好ましい。

２．２ バーチャルＨＩＬＳ

＜続＞

(８)．現状の実現状況

技術的には実現可能、実施例あり

(９)．想定効果

①納品工程短縮（および品質向上）が可能

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

②ＨＩＬＳの台数ネックを解消でき、固定資産削減が可能

(10)．今後の課題

・マイコンモデル提供スキーム確立 （高速モデル）

・ASICモデル開発スキーム確立 （高速モデル）

・通信インタフェースモデル （高速モデル）

２．２ バーチャルＨＩＬＳ

＜続＞

(11)．参考文献



Y. Ito et al, "A Model Based Software Validation for Automotive Control Systems", International

Conference on Control, Automation and Systems (ICCAS), pp.102, 2010



Y. Ito, et. al., "VIRTUAL HILS : A Model-Based Control Software Validation Method," SAE Paper

2011-01-1018, SAE Int. J. Passeng. Cars, Electron. Electr. Syst. June 2011.



宮崎： 車載電子システムのプラットフォーム開発動向 ～課題と対応事例～

カーエレジャパン2011 専門技術セミナー （CAR－10） 2011年1月



於保： 自動車ＥＣＵの仮想開発とクラウド環境

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

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

第１章 はじめに

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

２．１ 事例１：仮想車一台分シミュレーション ＜ホンダ＞

２．２ 事例２：バーチャルＨＩＬＳ （vHILS) ＜日立＞

２．３ 事例３：CPU負荷計測 ＜カルソニックカンセイ＞

２．４ 事例４：故障注入・故障解析 ＜デンソー＞

２．５ 事例５：vECUによる網羅的検証 ＜富士通テン＞

２．６ 事例６：ソフトウェア機能検証 ＜アイシン精機＞

第３章 分析

第４章 まとめ

3

10

11

18

30

39

48

58

65

74

２．３ CPU負荷計測

(１)．ユースケース名称

CPU負荷計測

(３)．作業項目

ソフト性能評価

(４)．目的

検証作業効率アップ

検証期間短縮

(２)．概要

負荷率測定作業の容易化

UIはデバッガーライク

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

２．３ CPU負荷計測

＜続＞

(５)．内容説明

(５)．１．CPU負荷計測とは

実行周期

実行時間

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

関数1

関数2

割込1 関数3

テストパターン

入力装置(HILS等)

２．３ CPU負荷計測

＜続＞

(５)．内容説明

＜続＞

テスト

シナリオ

入力

出力

_最大実行

時間

(負荷)

ｿｰｽ

ｺｰﾄﾞ

入力

(５)．２．現状の実施内容

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

となるテストを実行。

デバッガ

ICE

ターゲット

ボード

２．３ CPU負荷計測

＜続＞

(５)．３．現状の問題点

(５)．内容説明

＜続＞

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

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

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

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

設備が必要

２．３ CPU負荷計測

＜続＞

(５)．内容説明

＜続＞

(５)．４．理想形

テスト

シナリオ

入力

出力

_最大実行

時間

(負荷)

SPILS

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

を算出する。

ｿｰｽ

ｺｰﾄﾞ

入力

２．３ CPU負荷計測

＜続＞

(６)．用途

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

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

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

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

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

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

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

認

２．３ CPU負荷計測

＜続＞

(７)．主要要件

①時間精度

・実マイコンでのクロック数と完全一致すること

②処理スピード

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

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

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

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

２．３ CPU負荷計測

＜続＞

(８)．現状の実現状況

技術的には実現可能

(９)．想定効果

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

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

(10)．今後の課題

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

・SPILSへの入出力I/F

第１章 はじめに

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

２．１ 事例１：仮想車一台分シミュレーション ＜ホンダ＞

２．２ 事例２：バーチャルＨＩＬＳ （vHILS) ＜日立＞

２．３ 事例３：CPU負荷計測 ＜カルソニックカンセイ＞

２．４ 事例４：故障注入・故障解析 ＜デンソー＞

２．５ 事例５：vECUによる網羅的検証 ＜富士通テン＞

２．６ 事例６：ソフトウェア機能検証 ＜アイシン精機＞

第３章 分析

第４章 まとめ

3

10

11

18

30

39

48

58

65

74

２．４ 故障注入・故障解析

情報提供：デンソー（株）

( )

( )

２．４ 故障注入・故障解析

＜続＞

２．４ 故障注入・故障解析

＜続＞

２．４ 故障注入・故障解析

＜続＞

２．４ 故障注入・故障解析

＜続＞

２．４ 故障注入・故障解析

＜続＞

２．４ 故障注入・故障解析

＜続＞

( )

( )

２．４ 故障注入・故障解析

＜続＞

第１章 はじめに

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

２．１ 事例１：仮想車一台分シミュレーション ＜ホンダ＞

２．２ 事例２：バーチャルＨＩＬＳ （vHILS) ＜日立＞

２．３ 事例３：CPU負荷計測 ＜カルソニックカンセイ＞

２．４ 事例４：故障注入・故障解析 ＜デンソー＞

２．５ 事例５：vECUによる網羅的検証 ＜富士通テン＞

２．６ 事例６：ソフトウェア機能検証 ＜アイシン精機＞

第３章 分析

第４章 まとめ

3

10

11

18

30

39

48

58

65

74

２．５ vECUによる網羅的検証

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

(３)．作業項目

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

（潜在的バグの検出）

(４)．目的

検証作業効率アップ

検証期間短縮

(２)．概要

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

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

情報提供：富士通テン

２．５ vECUによる網羅的検証

＜続＞

(５)．内容説明

共有設備（予約制）

 準備に時間がかかる

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

 設備の移動困難

・・・

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

 高価

・・・1台500万～2000万

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

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

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

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

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

HILSの問題点

２．５ vECUによる網羅的検証

＜続＞

(５)．内容説明

＜続＞

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

実際に動かして検証

試作ソフトを作成

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

→

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

実装工程での

手戻り無し

レビュー（見える化）

ｴﾝｼﾞﾝ

回転数

車両モデル

AD

CAP

回転数/

割込み

制

御

ソ

フ

ト

ＥＣＵモデル

CMP

燃料噴射

時間

ﾃﾞｰﾀ

変換

ﾃﾞｰﾀ

変換

ﾃﾞｰﾀ

変換

ﾃﾞｰﾀ

変換

ﾃﾞｰﾀ

変換

ﾃﾞｰﾀ

変換

噴射量

+B電圧

水温・・・

+B電圧

水温・・・

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

Virtual HILS

設計者の思い込み

誤解釈

検討漏れ

設計ﾐｽを見つけ即修正

検証結果をそのまま

レビュー資料に利用

２．５ vECUによる網羅的検証

＜続＞

５．内容説明

＜続＞

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

CoMET/METeor

(Synopsys社)

VPM

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

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

動作をｼﾐｭﾚｰｼｮﾝ

Vehicle Model

MATLAB/Simulink

CRAMAS

条件設定

運転ﾊﾟﾀｰﾝ

ﾃﾞｰﾀ計測･ﾓﾆﾀ

自動判定

自動化

Hardware Model

ECU Model

２．５ vECUによる網羅的検証

＜続＞

(５)．内容説明

＜続＞

ｼｽﾃﾑ構成

自動設定

検査ﾊﾟﾀｰﾝ

自動生成

試験実行＆データ計

測

結果解析

A

B

’

B

’’

B

’’’

B

’’’’

・チャタリング試験

・条件網羅試験

条件Ａ

条件Ｂ

条件Ｃ

ＡＮＤ

A

B

C

A

B

・ばらつき試験

検査条件設定

（SPOC）

変換

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)

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

第１章 はじめに

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

２．１ 事例１：仮想車一台分シミュレーション ＜ホンダ＞

２．２ 事例２：バーチャルＨＩＬＳ （vHILS) ＜日立＞

２．３ 事例３：CPU負荷計測 ＜カルソニックカンセイ＞

２．４ 事例４：故障注入・故障解析 ＜デンソー＞

２．５ 事例５：vECUによる網羅的検証 ＜富士通テン＞

２．６ 事例６：ソフトウェア機能検証 ＜アイシン精機＞

第３章 分析

第４章 まとめ

3

10

11

18

30

39

48

58

65

74

２．６ ソフトウェア機能検証

(１)．ユースケース名称

ソフトウェア機能検証

(３)．作業項目

・ＨＩＬＳの補完

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

・ＵＩはSimulinkイメージ

(４)．目的

・機能安全対応

(２)．概要

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

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

情報提供：アイシン精機

２．６ ソフトウェア機能検証

＜続＞

(５)．内容説明

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

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

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

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

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

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

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

（他の内部状態可視化手段として、ハードウェア実機でも、

NBDやJP-wireなどのマイコン内部モニタ手段もある）

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

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

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

２．６ ソフトウェア機能検証

＜続＞

(５)．内容説明

＜続＞

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

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

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

時期になり、シミュレータ利用価値が低くなってしまう。

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

ミュレーション手段との標準拡張インターフエースが存在すれば、Ｉ／Ｏ部動作を

ユーザがカスタム作成できる可能性があり（簡易でよければ）、精度は低いが、検証

は可能となる。開発当初には低精度であっても、対応できるので、標準拡張インター

フエースが提起され普及すると、利用場面が便利である。

２．６ ソフトウェア機能検証

＜続＞

(６)．用途

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

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

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

・検証設備はmatlab/simulinkなどを利用するなど、従来シミュレーション環境

に組み込まれる用途。

２．６ ソフトウェア機能検証

＜続＞

(７)．主要要件

①時間精度

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

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

合するＥＣＵモデルの実現の仕組みがあること。およびＥＣＵの外側のセンサー、

アクチュエータモデル、メカモデル、車両モデル、ネットワークモデルを収集し、協

調シミュレーションが出来るためには、それらと時間精度、前後関係を合わせこむ

同期機能を有すること。またはマイクロセカンドの時間精度が必要。

②処理スピード

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

能なため、遅い速度は検証場面により、利用可能。

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

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

④その他

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

２．６ ソフトウェア機能検証

＜続＞

(８)．現状の実現状況

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

しいため、ケースバイケースで実現

(９)．想定効果

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

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

う解析

(10)．今後の課題

・

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

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

第１章 はじめに

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

第３章 分析

３．１ ヒアリング事項、討議事項

本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間の接続インタフェース

の標準化

モデリングツール間のモデル流用ができないこと

モデル活用フェーズ毎のシミュレーション動作精度と

実行時間要求の違いによる複数シミュレーション

モデル対応の必要性

標準がない

モデルの役割が階層的に定義できていない

当初検討課題

（今回提案と関連するものみ抜粋）

_{今回提案の対応策}

モデリング工数が多大

（⇒ユーザ要求ごとに個別開発していることも原因の１つ）

第１章 はじめに

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

第３章 分析

まとめ

◆目的

仮想マイコン（バーチャルECU）活用に関する啓蒙活動の一環として、現状事例（ユースケー

ス）を整理し、利用目的、必要要件などを明確化する。

◆調査方法

現状の事例（ユースケース）を利用目的ごとに分類し、今回調査では、その代表事例について、

各社にて分担して自社事例を中心に調査し、報告資料に纏めた。

◆事例紹介： ６つの事例を紹介

事例１： 仮想車一台分シミュレーション ＜ホンダ＞

事例２： バーチャルＨＩＬＳ （vHILS) ＜日立＞

事例３： CPU負荷計測 ＜カルソニックカンセイ＞

事例４： 故障注入・故障解析 ＜デンソー＞

事例５： vECUによる網羅的検証 ＜富士通テン＞

事例６： ソフトウェア機能検証 ＜アイシン精機＞

◆分析： 調査結果から追加導出した課題への対応策を提案

来歴

作成・編集来歴

年月日

作成・編集者

来歴

所 属

氏 名

2011.9～12

(株)本田技術研究所

嶋田 敏

調査および資料提供

カルソニックカンセイ（株）

小澤 哲也

（株）デンソー

上杉 浩

富士通テン（株）

斗納 宏敏

アイシン精機（株）

鈴村 延保

日立オートモティブシステムズ（株）

宮崎 義弘

2012.１～4

日立オートモティブシステムズ（株）

宮崎 義弘

報告書編集およびモデル流通TFでのレビュー結果

反映

2012.5～6

一般公開向け報告書編集