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

Transcription

1 仮想 ECU 活用のための ユーザ向け導入検討支援ガイド Rev 年 7 月 19 日仮想マイコン応用推進協議会 /vecu-mbd WG 1

2 目次 1. 仮想 ECU シミュレータの導入 活用の狙い 1.1 本書の目的 1.2 本書の作成経緯 1.3 用語 1.4 モデルベース開発 (MBD) 1.5 今後のシステムテストの課題 1.6 仮想マイコン 1.7 仮想 ECU 1.8 仮想 ECU シミュレータ導入の狙い 2. 開発プロセス上の位置付け 2.1 開発プロセス上の仮想 ECU 活用場面 2.2 HILS と vhils 2.3 仮想 ECU 応用モデルベース開発プロセス 3. 現状事例 ( ユースケース ) 3.1 調査経緯 3.2 事例 1: 仮想車一台分シミュレーション 3.3 事例 2: バーチャル HILS (vhils) 3.4 事例 3:CPU 負荷計測 3.5 事例 4: 故障注入 故障解析 3.6 事例 5:vECU による網羅的検証 3.7 事例 6: ソフトウェア機能検証 3.8 事例 7: フォールト注入 2

3 目次 4. 時間精度について 4.1 時間精度に関するトレードオフ 4.2 時間精度の要求分析 4.3 時間精度の誤差発生理由 4.4 時間精度の分類定義 (ATAL) 4.5 時間精度の評価方法 5. 複数シミュレータの同期化 5.1 複数 ECU 協調シミュレーションの概要 5.2 プラントモデルとコントローラモデルの同期化 5.3 複数コントローラモデル間の同期化 6. モデル間インタフェースについて 6.1 モデル間インタフェースの分類 6.2 モデル間インタフェース仕様検討時の留意点 6.3 マイコン内部のモデル間インタフェースの標準化 (TLM インタフェース ) 6.4 マイコン外部との通信インタフェースの標準化 6.5 周辺モデル付 SILS とその標準化 7. ユーザインタフェース (UI) について 7.1 ユーザインタフェース (UI) の分類 7.2 ユーザインタフェース (UI) 仕様検討時の留意点 8. フォールト注入について 8.1 フォールト注入のねらい 8.2 フォールト注入の分類 8.3 フォールト注入仕様検討時の留意点 3

4 目次 9. 性能評価 (CPU 負荷率 ) 9.1 車載制御ソフトウェアにおける CPU 負荷率とは? 9.2 CPU 最大負荷率測定の目的 9.3 用法 9.4 仮想 ECU の要件 9.5 今後の動向 10. 周辺モデル設計における留意点 4

5 2012/12/21 第 1 章仮想 ECU シミュレータの導入 活用の狙い 1.1 本書の目的 1.2 本書の作成経緯 1.3 用語 1.4 モデルベース開発 (MBD) 1.5 今後のシステムテストの課題 1.6 仮想マイコン 1.7 仮想 ECU 1.8 仮想 ECU シミュレータ導入の狙い 1.9 機能安全規格 ISO26262 と仮想 ECU 第 2 章開発プロセス上の位置付け第 3 章現状事例 ( ユースケース ) 第 4 章時間精度について第 5 章複数シミュレータの同期化第 6 章モデル間インタフェースについて第 7 章ユーザインタフェース (UI) について第 8 章フォールト注入について第 9 章性能評価 (CPU 負荷率 ) 第 10 章周辺モデル設計における留意点 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 5

6 1.1 本書の目的 本書は 仮想マイコンおよび仮想 ECU シミュレータの活用に関する啓蒙活動の一環として 自動車分野での利用目的 現状事例 ( ユースケース ) 要件分析 留意点などを解説し ユーザ向け導入検討支援ガイドとして纏めたものである 注意事項 : 本書の考え方は あくまで 現状知られている事例と一般的な見解をベースに解説したものである 仮想マイコンおよび仮想 ECU シミュレータの導入業務そのものを保証するものではない 従って 個別のシミュレーションシステムに対しては 各社の判断にて検討願いたい 今後 技術動向の変化により 本書の内容に改訂が必要となった場合には vecu-mbd WG にて審議した上で改訂するものとする vecu-mbd WG は 本書の使用により知的財産権の侵害若しくは知的財産権侵害に係る紛議が生じないこと または本書の使用に関する知的財産権の存在確認及び当該知的財産権に関する実施許諾について 一切の保証を行わない 6

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

8 1.3 用語 用語 略号 ECU MBD MILS SILS SPILS 注 1 PILS HILS 仮想マイコン仮想 ECU 注 1 vhils 注 1 説明 電子制御ユニット モデルベース開発手法 複雑化 高度化した現代の自動車制御システム開発に於て MATLAB/Simulink 等のツール活用によって 制御装置と制御対象の機能をモデル化し それらを実行可能な仕様書として用いることで 製品ライフサイクル全般に渡った品質向上と開発効率向上を目指した開発手法 Model-in-the-loop simulation モデルを用いたシミュレーション Simulink モデルなどで記述されたアプリケーションソフトをシミュレーション実行できる Software-in-the-loop simulation ソースコードを用いたシミュレーション C 言語などで記述されたアプリケーションソフトをシミュレーション実行できる Simulated-processor-in-the-loop simulation 実装対象プロセッサのモデル ( 仮想マイコン ) を用いたシミュレーション OS など基盤ソフトも含めて製品と同一のオブジェクトコード ( バイナリコード ) をシミュレーション実行できる Processor-in-the-loop simulation 実装対象プロセッサ ( マイコン ) を用いたシミュレーション Hardware-in-the-loop simulation 実装対象 ECU を用いたシミュレーション Virtual Microcontroller 実装対象プロセッサのモデル マイコン内蔵の周辺回路を含む OS など基盤ソフトも含めて製品と同一のオブジェクトコード ( バイナリコード ) をシミュレーション実行できる マイコンモデルとも呼ぶ Virtual ECU 実装対象 ECU のモデル 実装対象プロセッサのモデル ( 仮想マイコン ) を含む OS など基盤ソフトも含めて製品と同一のオブジェクトコード ( バイナリコード ) をシミュレーション実行できる バーチャル ECU vecu ECU モデルとも呼ぶ Virtual HILS 実装対象 ECU のモデル ( 仮想 ECU) を用いて HILS を仮想化したシミュレーション SPILS の応用例の 1 つである HILS ライクに利用できることが特徴である バーチャル HILS とも呼ぶ 注 1: 別の用語も使われているが 本 WG で審議の結果 この表に示すような用語を使用することにした 注 2: 上記用語および関連用語については 別資料 仮想 ECU に関わる用語集 も参照願いたい 8

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

10 1.4 モデルベース開発 (MBD) モデルとは? 資料より引用 仮想システムでのシミュレーションを可能とするもの 10

11 1.4 モデルベース開発 (MBD) 開発プロセスでのモデル活用位置付け 要求設計 要求検証 量産 プラントモデル Auto Calibration コントロールモデル 実車検証 仕様設計 実車テスト MBD 仕様書 単体検証 Rapid ECU ソフトウエア詳細設計 *** *** ECU HILS テスト プログラミング V プロセスの実物テスト ( 右側 ) 前にモデルで問題を抽出 11

12 1.5 今後のシステムテストの課題 今後のネットワークを介した複合システムテストの課題 実車テスト B-CAN HILS F-CAN 車一台分の大規模 HILS テストアプリ + プラットフォーム + ネットワークのテストは実ユニット完成後となり問題抽出の早期化が図れない 12

13 1.6 仮想マイコン 仮想マイコン ( マイコンモデル ): Virtual Microcontroller 実装対象プロセッサのモデル マイコン内蔵の周辺回路を含む OS など基盤ソフトも含めて製品と同一のオブジェクトコード ( バイナリコード ) をシミュレーション実行できる 複数 ECU モデルの内の 1 つまたは複数 ECU のオブジェクトコードを仮想エミュレーションし車両挙動と合わせたプログラム挙動解析が可能な環境 エアコン ECU モテ ル FI ECU モテ ル VSA ECU モテ ル キーレス ECU モテ ル B-CAN F-CAN 仮想 ECU で検証後 実 ECU を用いた HILS 最終検証 Plants Controller 13

14 エンジン回転数ATギア1.7 仮想 ECU 仮想 ECU( バーチャル ECU ECU モデル ): Virtual ECU 実装対象 ECU のモデル 実装対象プロセッサのモデル ( 仮想マイコン ) を含む OS など基盤ソフトも含めて製品と同一のオブジェクトコード ( バイナリコード ) をシミュレーション実行できる ECU モデル 制御対象モデル システム階層 ユニット階層 仮想 ECU 入力モデル マイコンモデル 出力モデル 実オブジェクトコード パーツ階層 仮想マイコン 14

15 1.8 仮想 ECU シミュレータ導入の狙い 実ユニットレスでオブジェクトコードベースのテスト実行 ( 製品と同一ソフトの検証 ) 実行時間を実時間かそれ以下に短縮したい実機では実施困難なテスト ( フォールト注入テストなど ) を行いたい 要求設計 要求検証 量産 プラントモデル 新ループ Auto Calibration コントロールモデル 実車検証 仕様設計 MBD 仕様書 単体検証 実車テスト Rapid ECU ソフトウエア詳細設計 *** *** OBJECT CODE プログラミング HILS テスト 15 ECU

16 1.9 機能安全規格 ISO26262 と仮想 ECU 自動車用機能安全規格 ISO26262 は 2011 年 11 月に制定された この中で 仮想 ECU の活用に関連する記述として以下がある ソフトウェア統合テストのテスト環境 Part6( ソフトウェア )-10 節 Software integration and testing ~ 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 を適宜活用可能 16

17 1.9 機能安全規格 ISO26262 と仮想 ECU フォールト注入テストのテスト環境 Part4( システム )-8 節 Hardware-software integration and testing Part5( ハードウェア )-10 節 Hardware 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. ハードウェアに対するフォールト注入テストは モデルベースのフォールト注入シミュレーションでもよい 仮想 ECU を適宜活用可能 17

18 第 1 章仮想 ECU シミュレータの導入 活用の狙い第 2 章開発プロセス上の位置付け 2.1 開発プロセス上の仮想 ECU 活用場面 2.2 HILS と vhils 2.3 仮想 ECU 応用モデルベース開発プロセス第 3 章現状事例 ( ユースケース ) 第 4 章時間精度について第 5 章複数シミュレータの同期化第 6 章モデル間インタフェースについて第 7 章ユーザインタフェース (UI) について第 8 章フォールト注入について第 9 章性能評価 (CPU 負荷率 ) 第 10 章周辺モデル設計における留意点 18

19 2.1 開発プロセス上の仮想 ECU 活用場面 ソフト制御モデフト制御モデフト制御モデフト制御モデフト制御モデフト制御モデルソフト開発の流れ この段階でもモデル活用したい MILS SILS SPILS 仮想 ECU HILS SW/HW 分割 ルソルソルソルソルソ制御アプリソフト C ソースコード 制御アプリソフトオブジェクトコード SW/HW 統合 実 ECU 要求仕様段階 ソフトプラットフォームモデル ECU ハードウエアモデル モデル仕様段階 ソフトプラットフォームモデル ECU ハードウエアモデル ハード開発の流れ C ソースコード生成段階 ソフトプラットフォームオブジェクトコード仮想マイコン ECU ハードウエアモデル ECU ハードウエア回路 マイコン組込み段階 実 ECU 統合段階 開発段階に応じたハード ソフトの最適モデル活用 オブジェクトコードマイコン ECU ハードウェア 19

20 2.1 開発プロセス上の仮想 ECU 活用場面 要求設計 実車レスデバッグ & 検証 量産 実車検証 システム要求モデル 要求側 コード ECU 要求モデル 仕様設計 供給側 仮想システム 単体実機レスデバッグ & 検証 単体実機検証 ECU 内部要求モデルソフトウエア要求モデルソフトウエア詳細設計 コード 要求側 供給側 コード 仮想 ECU コード 仮想マイコン 各設計プロセスの階層間をさかのぼった仮想 ECU 活用 20 実装

21 2.2 HILS と vhils(virtual HILS) 仮想マイコン 仮想 ECU を活用した vhils(virtual HILS) の特長を以下に示す (HILS との対比で ) HILS (Hardware-in-the-loop Simulator) 構成 : 実 ECU+ プラントモデル 特長 - 製品と同一のバイナリコードを動作検証 - 実機ベースのソフトウェア検証 短所 : 場所制約 ターゲット環境切替工数 再現性不確定 観測性制約 フォールト注入の制約など HILS vhils (Virtual HILS) 構成 : 仮想 ECU+ プラントモデル 特長 - 製品と同一のバイナリコードを動作検証 - 実機ベースとほぼ等価なソフトウェア検証 - 実機レス ( 実機不要 実機完成前でもテスト可 ) - 場所制約 ターゲット環境切替工数 再現性不確定 観測性制約 フォールト注入の制約などの実機 (HILS) の短所は解決 - クラウド活用による遠隔利用や並列実行可 車両モデル HILS 装置 ソフトウェア ( バイナリコード ) ECU( 実機 ) プラントモデル ( 車両モデル ) vhils (Virtual HILS) コントローラモデル ( 仮想 ECU) ソフトウェア ( バイナリコード ) マイコンモデル ( 仮想マイコン ) Simulator Co-sim 仮想 ECU シミュレータ 21

22 2.2 HILS と vhils 仮想 ECUを使ったHILS つまり vhilsを実現するには HILSと比べて以下のモデルが必要になる マイコンモデル ECUの入出力回路のモデル(H/Wモデル) なお HILS/vHILS 共に プラントモデルとしてセンサ アクチュエータのモデルも必要であるが HILSの場合は実機を利用することも可能である オブジェクトコード HILS オブジェクトコード マイコンモデル 仮想 ECU H/W モデル H/W モデル プラントモデル vhils ECU 実機 SPILS 用ツール PC/ サーバ ECU センサ アクチュエータの実機完成前に各種モデルが整うと vhils としてのメ リットが大きい ( ソフトウェアのテストを先行できる ) 実機完成前に モデルの作成または調達ができることが望ましい 22

23 2.3 仮想 ECU 応用モデルベース開発プロセス 実機の完成前に vhils による実機レスのシステムテストを行う場合の 開発プロセスを以下に示す 自動車メーカー 要求分析 ドメイン毎に担当範囲は変化 サプライヤ システム設計 要求分析 構成設計 詳細設計 コーディング ECU ソフト 単体検証 Validation 結合検証 オブジェクトコード オブジェクトコードと各部品モデル ( ハードウェアモデル ) を組込んで実機レスシステムテスト 要求分析要求分析要求分析 構成設計構成設計構成設計 実機レスシステムテスト 部品モデル 詳細設計詳細設計詳細設計モデリングモデリングモデリング テスト 検証テスト 検証テスト 検証 実装実装 車両テスト システムテスト 単体検証単体検証 単体検証 Validation Validation 結合検証結合検証 ECU ハード センサ アクチュエータ 23 実装 Validation 結合検証 実機

24 2012/12/21 第 1 章仮想 ECUシミュレータの導入 活用の狙い第 2 章開発プロセス上の位置付け第 3 章現状事例 ( ユースケース ) 3.1 事例調査経緯 3.2 事例 1: 仮想車一台分シミュレーション 3.3 事例 2: バーチャルHILS 3.4 事例 3:CPU 負荷計測 3.5 事例 4: 故障注入 故障解析 3.6 事例 5:vECUによる網羅的検証 3.7 事例 6: ソフトウェア機能検証 3.8 事例 7: 故障注入 ( フォールト注入 ) テスト第 4 章時間精度について第 5 章複数シミュレータの同期化第 6 章モデル間インタフェースについて第 7 章ユーザインタフェース (UI) について第 8 章フォールト注入について第 9 章性能評価 (CPU 負荷率 ) 第 10 章周辺モデル設計における留意点 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 24

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

26 3.1 事例調査経緯 事例 ( ユースケース ) を利用目的ごとに分類したものを以下の表に示す 本調査では その代表事例について 各社にて分担して自社事例を中心に調査し纏めた vecu/vhils 利用目的整理表と個別事例情報提供担当 26

27 3.1 事例調査経緯 調査項目 事例 ( ユースケース ) の調査にあたっては 以下の項目に従って纏めた 1. ユースケース名称 2. 概要 3. 作業項目 4. 目的 5. 内容説明フリーフォーマットで内容紹介 6. 用途 7. 主要要件時間精度 処理スピード ユーザインタフェース (UI) など シミュレータに対する主要要件 8. 現状の実現状況 ( あるいは見通し ) 9. 想定効果 10. 今後の課題 11. 参考文献 なお 本章の内容は 11 年度調査結果である 現時点では一部状況変化している場合もあるので 留意願いたい ( 特に 8. 現状の実現状況 ( あるいは見通し ) 10. 今後の課題 など ) 備考 : 第 3 章 ( 現状事例 ) と第 4 章以降の位置づけ本ガイドの作成においては 現状事例をまず分析して そこから得られた教訓も考慮しながら 第 4 章以降に留意すべきことを整理展開した 27

28 3.2 事例 1: 仮想車一台分シミュレーション 事例 1 情報提供 : 本田技術研究所 1. ユースケース名称仮想車一台分シミュレーション 2. 概要 実 ECUを揃えてHILSシステム構築しなくとも検証可能ソフトはオブジェクトさえあれば検証可能 ( ソースコードやモデルは不要 ) UIはHILSモニター画面ライク 3. 作業項目 複数 ECU の実機レス統合試験 4. 目的 検証作業効率アップ検証期間短縮 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 28

29 3.2 事例 1: 仮想車一台分シミュレーション 5. 内容説明 Full Vehicle Off-Line simulation Full Vehicle HILS B-CAN HILS F-CAN Actual Object Code Actual Object Code Actual Object Code Actual Object Code Vehicle I/F I/F I/F I/F Operation Pattern 2012/12/21 Virtual MCU Model Virtual MCU Model Virtual MCU Model Virtual MCU Model B-CAN F-CAN All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG Environment 並列分散処理が可能な仮想車一台分シミュレーション環境 29

30 エンジン回転数ATギア3.2 事例 1: 仮想車一台分シミュレーション 5. 内容説明 < 続 > ECU モデル 制御対象モデル システム階層簡易入力モデルユニット階層仮想 ECUモデル マイコンモデル 簡易出力モデル パーツ階層 2012/12/21 仮想マイコンモデル 実オブジェクトコード All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 故障診断状態での ECU 動作 1 機能 ECU での仮想 ECU モデル化技術はあるが ECU 内回路のモデル対応も必要 30

31 3.2 事例 1: 仮想車一台分シミュレーション 6. 用途 1 走行テストモード中の故障診断警告発生がないことのテスト確認 2 バッテリー電圧変動時の故障診断警告発生がないことのテスト確認 テストパターンおよび判定方法走行モード 操作パターンに対する故障診断警告信号の有無確認 走行テストモード バッテリー電圧変動パターン 車速 ギア段 バッテリー電圧 走行位置 時間 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 31

32 3.2 事例 1: 仮想車一台分シミュレーション 7. 主要要件 1 時間精度車 1 台分としてはネットワーク通信の信号レベルの再現の観点から 500kbps の信号再現ができると良い ( サンプリング周波数 5MHz 0.2μS) エンジン回転の割り込みやモータ回転センサへの対応は個別 HILS とし車 1 台分ではサンプリング周期としては 1mS 程度が妥当と考える 2 処理スピード実時間相当または実時間より短い時間での処理を希望 3 ユーザインタフェース (UI) HILS モニター画面ライク 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 32

33 3.2 事例 1: 仮想車一台分シミュレーション 8. 現状の実現状況 複数 ECU での実現は未当面は単体 ECU に対する HILS の仮想化を進め シミュレーションスピードの向上に合わせ 1 台分への対応展開が必要と思われる 9. 想定効果 大規模 HILS の台数削減テスト設備の省スペース化テスト環境設定時間及び切り替え時間の短縮化並列実行によるテスト時間の短縮 10. 今後の課題 マイコンモデル供給体制 シミュレーションの高速化対応技術の確立 ECU ネットワーク信号の取り扱い手法の明確化 ECU 内の電気回路やセンサアクチュエータのモデル化対応 仮想マイコンモデルライブラリを意識しない仮想 ECU モデルとしての取り扱い 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 33

34 3.2 事例 1: 仮想車一台分シミュレーション 11. 参考文献 嶋田 : 車両制御システム開発におけるシミュレーションモデル活用の有効性と課題 ISIT 第 5 回カーエレクトロニクス研究会 2009 年 4 月 山口 嶋田 ほか : エレクトロニクス設計を支えるシミュレーション技術自動車技術 Vol.65, No 年 1 月 嶋田 : 仮想 ECU モデルベース開発の実現に向けた業界縦断型取り組み ISIT 第 9 回カーエレクトロニクス研究会 2011 年 10 月 /12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 34

35 3.3 事例 2: バーチャル HILS 事例 2 情報提供 : 日立オートモティブシステムズ ( 株 ) および ( 株 ) 日立製作所 / 中央研究所 1. ユースケース名称バーチャル HILS (vhils) 2. 概要 3. 作業項目 4. 目的 HILS の補間クラウド活用して回帰テストを短期間に終わらせる ( 例 :3 日 1 晩 ) UI は HILS モニター画面ライク ソフト機能検証 HILS の補間オブジェクトレベルのテスト 検証作業効率アップ検証期間短縮 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 35

36 3.3 事例 2: バーチャル HILS 5. 内容説明 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 36

37 3.3 事例 2: バーチャル HILS 5. 内容説明 < 続 > 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 37

38 3.3 事例 2: バーチャル HILS 5. 内容説明 < 続 > 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 38

39 3.3 事例 2: バーチャル HILS 5. 内容説明 < 続 > 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 39

40 3.3 事例 2: バーチャル HILS 5. 内容説明 < 続 > 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 40

41 3.3 事例 2: バーチャル HILS 5. 内容説明 < 続 > 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 41

42 3.3 事例 2: バーチャル HILS 6. 用途 1 ソフト回帰テスト (HILS の補間 ) クラウド活用して回帰テストを短期間に終わらせる 2 ソフト結合テスト (HILS の補間 ) テストケースによっては 必ずしも HILS 上でなく vhils 上でのテストで代用 3HILS の代替 HILS 環境の構築が技術的に困難な場合 あるいは vhils のみでも実効上許容可と判断された場合 テストパターンおよび判定方法 HILS の場合と同等または過去テスト結果との一致確認 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 42

43 3.3 事例 2: バーチャル HILS 7. 主要要件 1 時間精度 タスク周期は 1ms 程度 ( 製品分野によっては 一部 100μs 程度のタスクもある ) プロセッサ内の命令実行速度は ある程度考慮要だが サイクル精度は MUST 要件ではない (±10% 程度は許容 ) タスク周期時間は正確に CAN 通信は 転送遅延やバス占有順序などはある程度考慮要だが 実機との完全一致は不要 HILS も 最終製品とは完全一致はできないので 同等の精度でかまわない 2 処理スピード N 並列実行で 実機以上の処理スピードが出せること ( 単独でも 実機と同等か それ以上を期待したいが MUST 要件ではない ただし 1/10 以下など極端に遅いのでは困る ) 3 ユーザインタフェース (UI) HILS の自動テスト環境と同等の UI が好ましい 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 43

44 3.3 事例 2: バーチャル HILS 8. 現状の実現状況 技術的には実現可能 実施例あり 9. 想定効果 1 納品工程短縮 ( および品質向上 ) が可能クラウド活用して大規模な回帰テストも短期間に終わらせる ( 例 :3 日 1 晩 ) 2HILS の台数ネックを解消でき 固定資産削減が可能 10. 今後の課題 マイコンモデル提供スキーム確立 ( 高速モデル ) ASIC モデル開発スキーム確立 ( 高速モデル ) 通信インタフェースモデル ( 高速モデル ) クラウド化 ( ツールライセンス体系など ) 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 44

45 3.3 事例 2: バーチャル HILS 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 , SAE Int. J. Passeng. Cars, Electron. Electr. Syst. June 宮崎 : 車載電子システムのプラットフォーム開発動向 ~ 課題と対応事例 ~ カーエレジャパン 2011 専門技術セミナー (CAR-10) 2011 年 1 月 於保 : 自動車 ECU の仮想開発とクラウド環境 ISIT 第 10 回カーエレクトロニクス研究会 2012 年 1 月 /12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 45

46 3.4 事例 3:CPU 負荷計測 事例 3 情報提供 : カルソニックカンセイ ( 株 ) 1. ユースケース名称 CPU 負荷計測 2. 概要 負荷率測定作業の容易化 UI はデバッガーライク 3. 作業項目 ソフト性能評価 4. 目的 検証作業効率アップ検証期間短縮 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 46

47 3.4 事例 3:CPU 負荷計測 5. 内容説明 5.1.CPU 負荷計測とは CPU 負荷率 (%) = 最大実行時間 実行周期 *100 で求める 実行周期 関数 1 関数 2 割込 1 関数 3 実行時間 実行時間が最大となるテストパターンを入力し 測定する 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 47

48 3.4 事例 3:CPU 負荷計測 5. 内容説明 < 続 > 5.2. 現状の実施内容 ターゲットボード + エミュレーターデバッガで最大実行時間 ( 負荷 ) となるテストを実行 テストシナリオ 入力 テストパターン入力装置 (HILS 等 ) テストシナリオ 出力 最大実行時間 ( 負荷 ) ソースコート 入力 デバッガ ソースコート ICE ターゲットボード 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 48

49 3.4 事例 3:CPU 負荷計測 5. 内容説明 < 続 > 5.3. 現状の問題点 1 ターゲットボード エミュレーターデバッガ等の設備が必要 2 ターゲットボード等の開発拠点とソフト開発拠点が違う場合 設備を送付しなければならない 3CPU 負荷測定用のテストを自動で実施する為には HILS 等の設備が必要 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 49

50 3.4 事例 3:CPU 負荷計測 5. 内容説明 < 続 > 5.4. 理想形 ソースコードとテストシナリオを入力し 最大実行時間 ( 負荷 ) を算出する テストシナリオ 入力 SPILS 出力 最大実行時間 ( 負荷 ) ソースコート 入力 ソースコート テストシナリオ 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 50

51 3.4 事例 3:CPU 負荷計測 6. 用途 1 ターゲットボード / デバッガの代替 従来の測定方法では ターゲットボード / デバッガが必要 SPILS で実施できれば SPILS の入った PC のみで実施可能 2 テストパターン入力装置 (HILS 等 ) の代替 負荷測定の為のテストパターン入力が容易 テストパターンおよび判定方法ターゲットボード / デバッガ使用時と同等または過去テスト結果との一致確認 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 51

52 3.4 事例 3:CPU 負荷計測 7. 主要要件 1 時間精度 誤差数 % 以内 注 : ユーザーとしては 実マイコンでのクロック数と完全一致することが望ましいが 誤差数 % 以内とし ユーザーの運用でカバーする 4.2 時間精度の要求分析 を参照 2 処理スピード 実機以上の処理スピードが出せることが望ましい (Must 要件ではない ) 自動化等により 人手がかかる時間が削減できれば良い 3 ユーザインタフェース (UI) CPU 負荷測定結果が精度良く算出できれば UI は規定しない 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 52

53 3.4 事例 3:CPU 負荷計測 8. 現状の実現状況 技術的には実現可能 9. 想定効果 試験環境の台数ネックを解消でき 固定資産削減が可能 グローバルで実施可能 (PC さえあれば ボード等の準備無しで実施可能 ) 10. 今後の課題 マイコンモデル提供スキーム確立 ( 精度モデル ) SPILS への入出力 I/F 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 53

54 3.5 事例 4: 故障注入 故障解析 事例 4 情報提供 : デンソー ( 株 ) 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 54

55 3.5 事例 4: 故障注入 故障解析 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 55

56 3.5 事例 4: 故障注入 故障解析 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 56

57 3.5 事例 4: 故障注入 故障解析 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 57

58 3.5 事例 4: 故障注入 故障解析 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 58

59 3.5 事例 4: 故障注入 故障解析 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 59

60 3.5 事例 4: 故障注入 故障解析 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 60

61 3.5 事例 4: 故障注入 故障解析 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 61

62 3.6 事例 5: vecu による網羅的検証 事例 5 情報提供 : 富士通テン 1. ユースケース名称 vecu による網羅的検証 2. 概要 ソフトウェアの設計検証を網羅的に実行 HILS 用のモデルおよび検査パターンを流用 3. 作業項目 組合せ 割り込み 動作タイミングのズレによる異常動作検出 ( 潜在的バグの検出 ) 4. 目的 検証作業効率アップ検証期間短縮 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 62

63 3.6 事例 5: vecu による網羅的検証 5. 内容説明 準備に時間がかかる HILS の問題点 設計段階では使用できない 高価 1 台 500 万 ~2000 万 上流工程のツールとして使えない ソフトを ECU に実装しないと使えない ソフト設計段階では 設備が揃わない 設備の移動困難 本体 PC ECU 擬似負荷等 必要スペース約 5 m2 ECU 手配 ( 約 3か月 ) ハーネス作成( 約 2 週間 ) セッティンク ( 約 2 日 ) 事前に計画立て 関連部署と連携を取り 計画に沿った準備が必要 共有設備 ( 予約制 ) ( 問題点 ) 設備の空き待ち 段換え工数発生 稼働率低下 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 63

64 制御ソフト3.6 事例 5: vecu による網羅的検証 5. 内容説明 < 続 > Virtual HILS 導入の狙い 1. ソフト設定のみで環境構築 設定時間の短縮 開発環境の配付 ECU モデル 車両モデル 回転数 / 割込み +B 電圧水温 燃料噴射時間 CAP AD CMP テ ータ変換 テ ータ変換テ ータ変換 テ ータ変換 テ ータ変換テ ータ変換 エンシ ン回転数 +B 電圧水温 噴射量 2. 設計段階で活用 ECU ができる前に検証可能 Virtual HILS 試作ソフトを作成設計者の思い込み検討漏れ誤解釈 実際に動かして検証 設計ミスを見つけ即修正 レビュー ( 見える化 ) 検証結果をそのままレビュー資料に利用 実装工程での手戻り無し 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 64

65 3.6 事例 5: vecu による網羅的検証 5. 内容説明 < 続 > Virtual HILS の構成 自動化 条件設定運転ハ ターン Vehicle Model MATLAB/Simulink 2012/12/21 テ ータ計測 モニタ自動判定 CRAMAS CoMET/METeor (Synopsys 社 ) VPM( マイコンシミュレータ ) コート レヘ ルでのマイコン動作をシミュレーション 仮想環境下でのシステム評価をすべてソフトで実現 SPILS 2005 年 11 月 16 日 Virtual ECU Club Hardware Model All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 株式会社豊通エレクトロニクス株式会社ガイア システム ソリューション株式会社トヨタテクノサービス富士通テン株式会社 ECU Model MATLAB/Simulink 65

66 3.6 事例 5: vecu による網羅的検証 5. 内容説明 < 続 > vecu による網羅的検証 検査条件設定 (SPOC) 変換 検査ハ ターン自動生成 試験実行 & データ計測 結果解析 OK/NG 自動判定モニタ システム構成自動設定 不具合解析 条件網羅試験 AND 条件 A 条件 B 条件 C チャタリング試験 A B C アルゴリズムの評価は MILS/SILS で実行可能だが 多重割込みの影響 入力信号のチャタリング時の動作 入力タイミングの差による影響など 時間軸に依存した検証は SPILS でなければできない ばらつき試験 A B 2012/12/21 A B B B B All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 66

67 3.6 事例 5: vecu による網羅的検証 6. 用途 1 設計確認 ソフト設計時に机上で動作を確認 vhils ではソフト部品単体でも動的評価可能 2 HILS 検査の代用 オフショア 外注先 先行開発時などハードが無い場合のソフト検査 ( 結合検査 動的評価 ) * アルゴリズム評価は SILS で HILS の代用が可能だが 時間依存の強い検査内容 ( 多重割込み 非同期動作 応答遅れなど ) は時間精度の高い SPILS を使用 テストパターンおよび判定方法 テストパターンおよび判定ロジックの作成は専用のツール (HILS と同じ ) を使用 ATG( 自動テスト生成 ) は現在検討中 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 67

68 3.6 事例 5: vecu による網羅的検証 7. 主要要件 1 時間精度 CPU 負荷見積もりや応答遅れに関する評価では 5% 程度 10% 程度は余裕を持って設計するので 時間精度そのものは重要でない ( クリティカルな設計をする場合は実ハードで確認を行う ) 割込みや IO のディレイ カウンタ等の評価ではクロックカウンタの精度でよい ( 例えば パルス周期の計測ではパルス間の時間を計測するが 重要なのは実時間精度ではなくパルス間のクロックのカウント値である ) 2 処理スピード 網羅的評価では数多くのテストを繰り返し実行するので早ければ早いほど良い ( 実用上は実時間と同等であればよい ) 設計確認では対面実行するので できれば実時間と同等 最悪でも 1/10 以上 3 ユーザインタフェース (UI) UI に限らず プラントモデルやハードウェアモデル 検査パターンは資産活用の観点から HILS~MILS まで流用できることが望ましい 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 68

69 3.6 事例 5: vecu による網羅的検証 8. 現状の実現状況 社内活用中 但し SPILS の需要は低下 ( 通常の評価はイベント駆動型の SILS へ移行 ) ( オブジェクト変換によるイベント駆動型の SILS は SPILS の範疇か?) 9. 想定効果 実績 (SPILS による効果と SILS による効果の判別はできない ) 1 検査工程の工数削減 50% 減 2 検査期間の短縮 約 1/2 に短縮 3 設計工程の工数削減 55% 減 4 設計工程で検証漏れ ロシ ックに関わる検証漏れ 0 件 10. 今後の課題 メンテナンス要員の確保評価システムを立ち上げるのに専門知識必要 I/F が標準化されモデルが流通するようになれば 設計者自身で設定できるようになると考える 機能安全への対応 ISO26262 では HILS でオブジェクトコードでの動作確認を推奨しているが SPILS も HILS と同等にオブジェクトコードで動作確認をしたものとみなすよう提案すべき 活用範囲の拡大全ての検査をソフトシミュレーションで可能なように機能 性能を上げていく 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 69

70 3.6 事例 5: vecu による網羅的検証 11. 参考文献 オールソフトシミュレーションによる制御ソフトウェア開発 : 富士通テン技法 47 号 (2006/06) カ イアシステム ) 田中 豊通エレ ) 香野 富士通テン ) 森山他 Virtual CRAMAS (SILS) への ISS レス技術の適用 : 富士通テン技法 52 号 (2008/12) 富士通テン ) 森山 深澤他 /12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 70

71 3.7 事例 6: ソフトウェア機能検証 事例 6 情報提供 : アイシン精機 1. ユースケース名称ソフトウェア機能検証 2. 概要 ソフトウェア機能検証をオブジェクトバイナリーレベルで実施できる環境 統合された ECU の個別ソフトのハザード分析を シミュレーションで実施できる環境 3. 作業項目 4. 目的 HILS の補完 オブジェクトレベルのテスト UI は Simulink イメージ 機能安全対応 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 71

72 3.7 事例 6: ソフトウェア機能検証 5. 内容説明 従来 : ISS シミュレータでソフトウェアの機能検証を行ってきた 主として単体テストを担ってきた ユースケース : 利用コンパイラのコード生成信頼性を含んで 生成されるバイナリーレベルで より実機相当環境でのシミュレーション検証が可能となる 特に車両条件設定の困難な 場面や故障モード再現で危険であったり 再現性が難しい場面は HILS または シミュレーション検証が必要となる より詳細な解析を伴う評価の場面では HILS よりも シミュレーションによる内部状態可視化でのモニター ロギング 解析が効果的である ( 他の内部状態可視化手段として ハードウェア実機でも NBD や JP-wire などのマイコン内部モニタ手段もある ) 統合制御 ECU では 個別ソフトモジュールの 内部状態可視化での解析切り分けが難しいが ソフトシミュレーションではより容易 必要条件 : マイコン周辺で協調動作する IC モデルや 分布乗数回路モデルを含み 総合する ECU モデルの実現の仕組みがあること および ECU の外側のセンサー アクチュエータモデル メカモデル 車両モデル ネットワークモデルを収集し 協調シミュレーションが出来ることで 対応が可能となる このため それらヘテロジニアスシミュレーション手段との接続が必要 実使用現場では使用実績の高い Matlab/simulink をユーザインターフエースだけでなく それらヘテロジニアスシミュレーション手段とのインターフエースとして 利用できることが 要望 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 72

73 3.7 事例 6: ソフトウェア機能検証 5. 内容説明 < 続 > 新規マイコンへの 早期対応 シリーズ化されるマイコンの I/O バリエーションに すべて早期に対応することは タイムリーに難しい場面がある タイムリーでないと 評価用実マイコンが入手できる時期になり シミュレータ利用価値が低くなってしまう マイコンコア部分のバイナリーシミュレーションがまず必要で I/O 部分は簡易シミュレーション手段との標準拡張インターフエースが存在すれば I/O 部動作をユーザがカスタム作成できる可能性があり ( 簡易でよければ ) 精度は低いが 検証は可能となる 開発当初には低精度であっても 対応できるので 標準拡張インターフエースが提起され普及すると 利用場面が便利である 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 73

74 3.7 事例 6: ソフトウェア機能検証 6. 用途 用途 1: オブジェクトバイナリーレベルでの 統合ソフトウェア機能検証 用途 2: 統合制御された ECU 等の個別ソフトのハザード分析シミュレーション テストパターンおよび判定方法 検証設備は matlab/simulink などを利用するなど 従来シミュレーション環境に組み込まれる用途 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 74

75 3.7 事例 6: ソフトウェア機能検証 7. 主要要件 1 時間精度用途 1: 時間精度は フローの前後関係が保証されればよい 用途 2: マイコン周辺で協調動作する IC モデルや分布乗数回路モデルを含み総合する ECU モデルの実現の仕組みがあること および ECU の外側のセンサー アクチュエータモデル メカモデル 車両モデル ネットワークモデルを収集し 協調シミュレーションが出来るためには それらと時間精度 前後関係を合わせこむ同期機能を有すること またはマイクロセカンドの時間精度が必要 2 処理スピード パソコン上で実機相当速度またはその 10 倍遅い範囲 夜間テストが可能なため 遅い速度は検証場面により 利用可能 3 ユーザインタフェース (UI) Matlab/simulink または 相当なインターフェースが利用できる 4 その他 I/O 部分は簡易シミュレーション手段との標準拡張インターフエースが存在する 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 75

76 3.7 事例 6: ソフトウェア機能検証 8. 現状の実現状況 カスタム IC モデルや 分布乗数回路モデルの協調シミュレーションが難しいため ケースバイケースで実現 9. 想定効果 OEM からのバイナリー動作環境の提供要請への対応が出来る 実機での再現や 動作条件設定が難しい場面や 内部動作確認を同時に行う解析 10. 今後の課題 マイコン周辺で協調動作する IC モデルや分布乗数回路モデルを含み 総合する ECU モデルの実現の仕組みがあること および ECU の外側のセンサー アクチュエータモデル メカモデル 車両モデル ネットワークモデルを作成 収集し 協調シミュレーションすることを効率的に実現する方策の整備 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 76

77 3.8 事例 7: 故障注入 ( フォールト注入 ) テスト 事例 7 情報提供 : ( 株 ) 日立製作所 / 中央研究所 1. ユースケース名称故障注入 ( フォールト注入 ) テスト 2. 概要 クラウドを活用して 膨大な故障注入 ( フォールト注入 ) テストを短期間に終わらせる ( 例 :67 万テストケース /600 計算機ノード 12 時間 ) 3. 作業項目 故障注入 故障解析 4. 目的 検証カバレッジ向上検証作業効率アップ ( 検証期間短縮 ) 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 77

78 3.8 事例 7: 故障注入 ( フォールト注入 ) テスト 5. 内容説明 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG Copyright Hitachi Ltd. All rights reserved 78

79 3.8 事例 7: 故障注入 ( フォールト注入 ) テスト 5. 内容説明 < 続 > 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG Copyright Hitachi Ltd. All rights reserved 79

80 3.8 事例 7: 故障注入 ( フォールト注入 ) テスト 6. 用途 用途 1 故障注入 ( フォールト注入 ) テストクラウドを活用して 膨大な故障注入 ( フォールト注入 ) テストを短期間に終わらせる 2HILS の補完 HILS 環境ではフォールト注入テストの実施が困難な場合でも シミュレータ上では実施可能 テストパターンおよび判定方法 テストパターン : HILS の場合と同等フォールト注入シナリオ : 新規に準備 ( 任意指定またはランダム発生 ) 判定方法 : 安全目標を侵害しないこと ( 例 : 意図しない加速が発生せぬこと ) 備考 : 自動車用機能安全規格 ISO26262 では ASIL-C 以上の場合 フォールト注入テストの実施を 強く推奨 ( 実際の運用上は必須 ) としている 実施形態は 実機テストでもシミュレーションテストでもよい 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 80

81 3.8 事例 7: 故障注入 ( フォールト注入 ) テスト 7. 主要要件 1 時間精度 タスク周期は 1ms 程度 プロセッサ内の命令実行速度は ある程度考慮要だが サイクル精度は MUST 要件ではない (±10% 程度は許容 ) 2 処理スピード N 並列実行で 実機以上の処理スピードが出せること ( 単独でも 実機と同等か それ以上を期待したいが MUST 要件ではない ただし 1/10 以下など極端に遅いのでは困る ) 3 ユーザインタフェース (UI) HILS の自動テスト環境と同等の UI が好ましい フォールト注入テストシナリオ入力 UI が追加されること 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 81

82 3.8 事例 7: 故障注入 ( フォールト注入 ) テスト 8. 現状の実現状況 技術的には実現可能 実施例あり 9. 想定効果 1 検証カバレッジ向上フォールト注入箇所 タイミング フォールトモード製品と同一ソフトウェア ( オブジェクトレベル ) でのフェールセーフ機能検証 2 検証作業効率アップ仮想化によるフォールト注入作業工数削減クラウド活用 ( 多並列処理 ) による検証期間短縮仮想化による再現性 ( 回帰テスト容易 ) 観測性 ( トラブル解析容易 ) 10. 今後の課題 クラウド活用 ( 多並列処理 ) に適したツールライセンス体系 フォールト注入仕様の標準化とフォールト注入機能付き ECU モデル提供スキーム確立 フォールト注入テストカバレッジ要求仕様の標準化 2012/12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 82

83 3.8 事例 7: 故障注入 ( フォールト注入 ) テスト 11. 参考文献 於保 : 自動車 ECU の仮想開発とクラウド環境 ISIT 第 10 回カーエレクトロニクス研究会 2012 年 1 月 日立製作所 国立大学法人神戸大学ニュースリリース : 半導体メモリエラーの産業機器や自動車制御への影響を解析するクラウド型の評価 検証シミュレーション技術を開発, 2011 年 12 月 2 日 伊藤 : 機能安全テストを加速する故障注入技術を用いた仮想 ECU テスト環境の構築, Synopsys Users Meeting Japan /12/21 All Rights Reserved by 仮想マイコン応用推進協議会 /vecu-mbd WG 83

84 第 1 章仮想 ECU シミュレータの導入 活用の狙い第 2 章開発プロセス上の位置付け第 3 章現状事例 ( ユースケース ) 第 4 章時間精度について 4.1 時間精度に関するトレードオフ 4.2 時間精度の要求分析 4.3 時間精度の誤差発生理由 4.4 時間精度の分類定義 (ATAL) 4.5 時間精度の評価方法第 5 章複数シミュレータの同期化第 6 章モデル間インタフェースについて第 7 章ユーザインタフェース (UI) について第 8 章フォールト注入について第 9 章性能評価 (CPU 負荷率 ) 第 10 章周辺モデル設計における留意点 84

85 4.1 時間精度に関するトレードオフ 仮想 ECU シミュレータにおいては 当該プロセッサでの演算処理時間 ( プロセッサクロックサイクル数 ) が実 ECU と同一でシミュレーションできれば プロセッサの正確な挙動確認や性能評価ができるので ユーザにとってはありがたい しかし その一方で 仮想 ECU シミュレータにおいて 当該プロセッサでの演算処理時間 ( プロセッサクロックサイクル数 ) を実 ECU と同一に保証させることは 後述するように困難な状況にあり 開発工数 費用や納期の問題が発生する シミュレータである以上 時間精度の誤差についても 要求と実現とのトレードオフを考慮必要である 時間精度の許容誤差を極めて小さくしようとした場合ユーザにとってはプロセッサ命令処理時間をより精度良く評価できるベンダ ( マイコン ツール ) にとっては開発工数 費用がかかり 納期も遅くなる可能性が高いシミュレーション実行時間が長くなる 時間精度の許容誤差が大きくても許容するとした場合ユーザにとってはプロセッサ命令処理時間の評価が概略評価しかできなくなるベンダ ( マイコン ツール ) にとっては開発工数 費用が少なくてすみ 納期も早くできるメリットがあるシミュレーション実行時間を短くできるメリットがある 時間精度 開発工数開発費用納期 時間精度 実行時間 85

86 4.2 時間精度の要求分析 (1) 時間精度の要求分析整理 要求される時間精度を ユースケースごとに 以下に纏めた ユースケース 仮想車一台分 シミュレーション 時間精度 車 1 台分としてはネットワーク通信の信号レベルの再現の観点から 500kbps の信号再現ができると良い ( サンプリング周波数 5MHz 0.2μS) ( 本見解には別意見もある ネットワーク上のアナログ波形が見たいのではなく ネットワーク競合待ち状態が考慮されることなので それを考慮した仮想ネットワークモデルでもよいのではないか?) エンジン回転の割り込みやモータ回転センサへの対応は個別 HILS とし 車 1 台分ではサンプリング周期としては 1mS 程度が妥当と考える バーチャル HILS タスク周期は 1ms 程度 ( 製品分野によっては 一部 100μs 程度のタスクもある ) プロセッサ内の命令実行速度は ある程度考慮要だが サイクル精度は MUST 要件ではない (±10% 程度は許容 ) タスク周期時間は正確に CAN 通信は 転送遅延やバス占有順序などはある程度考慮要だが 実機との完全一致は不要 HILS も 最終製品とは完全一致はできないので 同等の精度でかまわない CPU 負荷計測 誤差数 % 以内 注 : ユーザーとしては 実マイコンでのクロック数と完全一致することが望ましいが 誤差数 % 以内とし ユーザーの運用でカバーする ( 次ページに続く ) 86

87 4.2 時間精度の要求分析 ユースケース 時間精度 故障注入 故障解析 システム検証には 15% 程度以上が望ましいが 故障再現のみではこの限りではない vecuによる網羅的検証ソフトウェア機能検証 CPU 負荷見積もりや応答遅れに関する評価では 5% 程度 10% 程度は余裕を持って設計するので 時間精度そのものは重要でない ( クリティカルな設計をする場合は実ハードで確認を行う ) 割込みや IO のディレイ カウンタ等の評価ではクロックカウンタの精度でよい ( 例えば パルス周期の計測ではパルス間の時間を計測するが 重要なのは 実時間精度ではなくパルス間のクロックのカウント値である ) 用途 1: オブジェクトバイナリーレベルでの 統合ソフトウェア機能検証 時間精度は フローの前後関係が保証されればよい 用途 2: 統合制御された ECU 等の個別ソフトのハザード分析シミュレーション マイコン周辺で協調動作する IC モデルや分布乗数回路モデルを含み総合する ECU モデルの実現の仕組みがあること および ECU の外側のセンサー アクチュエータモデル メカモデル 車両モデル ネットワークモデルを収集し 協調シミュレーションが出来るためには それらと時間精度 前後関係を合わせこむ同期機能を有すること またはマイクロセカンドの時間精度が必要 87

88 4.2 時間精度の要求分析 (2)( 参考 ) 追加ヒアリング事項 討議事項 現状事例 ( ユースケース ) の調査時に 時間精度の要求について 疑問や要望を追加ヒアリングし討議した その主なものを以下に紹介する ユースケース疑問や要望ユーザ回答あるいは討議結果 仮想車一台分シミュレーション 仮想 ECU では CAN のデータリンク層以上をモデル化し 実行速度重視のバーチャル CAN を活用することも可能と思われる このユースケースにおいて タスク実行時間の時間精度はどの程度必要と考えるか? 一番の関心事は CAN 通信時のデータ衝突により通信が待たされ状態の再現である このユースケースにおいては 複数 ECU の統合動作で問題ないかといった検証が主目的で 主な検証対象は CAN データリンク層より上位の基盤ソフト アプリケーションソフトなどだと思うので パケット転送タイプの CAN 通信モデルの検討も考えてみたい CAN 通信でのデータ遅れは考慮してほしいが タスク実行時間の精度は 周期起動なので 極端に言えば MILS と同様でよく プロセッサの命令実行時間はゼロでもかまわない 88

89 4.2 時間精度の要求分析 ユースケース疑問や要望ユーザ回答あるいは討議結果 CPU 負荷計測 当初 理想の要求として 実マイコンでのクロック数と完全一致すること と提示された しかし 完全一致 という要求だと 現実解がなくなってしまう可能性がある そこで 許容誤差を示してほしい旨をユーザに要請 ( モデルである以上 現物との完全一致は保証困難 ) タスク実行時間の誤差数 % 以内でも許容不可か? 完全一致保証を究極まで追求させるとなると 相当に詳細なモデルにせねばならないので 実行速度は相当に悪くなる (2 桁以上?) と予想されるが どこまでなら許容できるか? ユーザとしては 実マイコンでのクロック数と完全一致すること は当初必須要件と考えていた 命令に対するマシンサイクル数は変わらない様に構築することは可能と思っていた 保証困難なのであれば その理由の説明資料がほしい 誤差数 % 以内が保証可能であれば 運用で対処可能かもしれない 但し CPU 負荷の測定について そのまま置き換えを考えると 完全一致が必須となる CPU 負荷の測定については テストケースさえ出せば ms オーダーで終了するので 実行速度については 2 桁悪くなっても問題ないと考える 89

90 4.2 時間精度の要求分析 (3) 考察と対応案 1 プロセッサ命令実行の時間精度 と シミュレーション実行速度 ( およびマイコンモデル開発工数 ) とのトレードオフが課題である プロセッサ命令実行の時間精度の完全性を追求する場合のベンダ側の技術的困難性を ユーザに理解いただくための説明資料の作成 提供が必要と考える また ユーザにとって 時間精度要求仕様の決め方をガイドする必要があると思われる ( 例 : ツール上での負荷 80% 以内を判定基準とした場合 時間精度の誤差を 1% とすれば 実機では 81% 以下と推定でき 100% に対してはマージンあるから OK と判断するといったことで運用できるなど ) 関連する解説や分析結果を本章に記載した 2 プロセッサ命令実行の時間精度は ユースケースにより 高精度モデル ( 低速 ) と高速モデル ( 低精度 ) を使い分けることが必要と思われる 時間精度の種別定義 精度評価手法 相互利用可能化のためのモデル間インタフェースの標準化などを検討することが望ましいと考える 関連する解説を本章および第 5 章に記載した 3 複数 ECU 間を接続するインタフェースについて 時間精度と実行速度のトレードオフを考慮した標準インタフェースモデルを検討することが望ましい ( 例 :CAN インタフェースモデルの標準化 ) 関連する解説を第 6 章に記載した 90

91 4.3 時間精度の誤差発生理由 本節では 演算処理時間精度 ( プロセッサクロックサイクル数 ) の誤差発生理由を解説する (1) プロセッサ内部の多様な高速処理方式 バーチャル ECU シミュレータにおいて 当該プロセッサでの演算処理時間 ( プロセッサクロックサイクル数 ) が実 E CU と同一でシミュレーションできることを保証するには プロセッサ内部の多様な高速処理方式を実プロセッサと完全に一致するようにしなければならない しかし 最近のプロセッサでは 高い性能を得るために多様な高速化手法が用いられている その一例を以下に示す プロセッサの高速化手法 ( 例 ) No. 高速化手法説明 1 パイプライン制御 プロセッサ処理を複数サイクルに分割し 前のサイクルが終了する前に次の命令を実行 ( パイプライ ン処理 ) することにより 1 命令当たりの消費クロックを少なく見せる手法 2 キャッシュメモリ プロセッサがデータや命令などの情報を低帯域バス上にある主記憶から取得する際に プロセッサ との性能差を埋めるために用いる高速小容量メモリのこと プロセッサと主記憶との間に置かれ 主 記憶に代わってデータを入出力する 3 スーパースカラプロセッサ内部に複数の処理系統を用意し 複数の命令を同時実行すること 4 分岐予測 パイプライン制御では分岐命令が発生すると 既にパイプライン処理を開始した後続の命令を破棄 するため処理効率の低下となる これを防ぐため命令分岐を予測し 分岐しそうな場合には分岐先 の命令をパイプラインに流しこむこと 5 命令先行読み出しバッファ バス上の主記憶から命令を取得する際に次の命令も予め取得し プロセッサからの命令要求後 主記憶からの命令取得を待たずに次命令を供給するための高速メモリ またはレジスタのこと 6 内部バス制御方式 プロセッサを構成するプロセッサコア メモリ 周辺回路を結合する回路および動作仕様 16bit, 32bitなどバス幅の他 バス構造も単一バスからクロスバースイッチ等 様々なアーキテクチャが存 在する 7 マルチコア 2つ以上のプロセッサコアを1つのパッケージに集積したプロセッサ コア数増加による性能向上の 他 キャッシュメモリの共有等により性能向上を実現できる 91

92 4.3 時間精度の誤差発生理由 このようなプロセッサの多様な高速化手法は 各マイコンベンダのノウハウでもあり その制御方式は必ずしも公開されていない 従って ツールベンダがマイコンのマニュアルなど開示された仕様のみでは実マイコンの挙動に完全一致する仮想マイコンを開発することは実質困難である 一方で マイコンベンダが多様な高速化手法を全てモデル化した仮想マイコンを開発 & 提供することは マイコン設計データ (RTL) の提供と等価であり モデル開発工数が増大する またシミュレーション速度が得られず アプリケーションの開発や評価に適さない このため 仮想マイコンではある想定した条件下での処理時間を用いており 実マイコンでの動作時間と仮想マイコンの動作時間に違いが発生する 各高速化手法で発生する誤差の例を以下に示す No. 高速化手法誤差要因 1 パイプライン制御パイプラインハザード パイプラインストール発生の有無による処理時間の相違 2 キャッシュメモリキャッシュヒット ミスヒットでの処理時間の相違 3 スーパースカラ複数命令によるデータや資源 ( バス メモリ等 ) の競合有無による処理時間の相違 4 分岐予測命令分岐予測によるパイプラインへの先行投機の有無による処理時間の相違 5 命令先行読み出しバッファ プロセッサが要求した命令データと 先行読み出しした命令データが一致した場合と 命令デー タが要求と異なり再読出しを行った場合の処理時間の相違 6 内部バス制御方式バスの競合による処理時間の相違 7 マルチコア複数プロセッサによるデータや資源 ( バス メモリ等 ) の競合有無による処理時間の相違 92

93 4.3 時間精度の誤差発生理由 (2) 非同期やアナログ回路によるタイミングばらつき 周辺との入出力や 複数マイコン間の通信などでは 使用クロックが別であり 当該プロセッサのクロックとは非同期のタイミングで送受信が行われる 例えば CAN 通信はマイコン間では非同期のタイミング要素があり データ送受信タイミングに ばらつきが発生する また アナログ回路では素子特性のばらつきにより データ受信タイミングにばらつきが発生する 以上のようなタイミングばらつきは 実 ECU において発生する 一方で 仮想 ECU シミュレータにおいては 非同期やアナログ回路も値を一意的に決めれば シミュレータ上の挙動としてはタイミングばらつきは発生せず 入力条件が同一であれば同一の挙動結果を得られる しかし 実機との時間精度という観点では 非同期部位やアナログ回路の特性はある想定した値を用いるので タイミングを実 ECU と完全に一致させることは保証困難である 93

94 4.4 時間精度の分類定義 (ATAL) 仮想 ECU シミュレータの導入においては その時間精度について 開発工数 費用および納期や 実行速度とのトレードオフを考慮する必要がある 要件分析の節でも記述したが 要求される時間精度は ユースケースによっていくつかに分類される しかし 時間精度の分類について 共通的な定義が従来なかったため ユーザとツールベンダとの間で認識合わせが困難という課題があった 本節では 時間精度の分類を定義する この検討においては 自動車制御分野向けのユースケースを念頭に定義付けを行った 94

95 4.4 時間精度の分類定義 (ATAL) シミュレーション時間精度の定義 ATAL Automotive Timing Accuracy Level シミュレータの実行時間の精度を分類するためのレベル 車載制御システムのシミュレーション用途の視点で分類されている 以下の 3 レベルが定義される 主な用途 備考 : トレードオフ レベル定義および説明ソフト 機能検証 ソフト 性能評価 時間精度 開発工数開発費用 実行時間 ATAL-3 誤差 5% 以内 バス調停やパイプライン制御をモデル化することでプロセッサクロックサイクル数をある程度厳密に模擬 高 大 長 ATAL-2 誤差 15% 以内 各命令毎 アクセス先毎 平均実行サイクル数設定等によりプロセッサクロックサイクル数をラフに推定して模擬 ATAL-1 誤差最大値保証せず 全命令一律に 1 プロセッサクロックサイクル等で模擬 時間指定されたタイマ割込みやイベント発生のタイミングは保証するが プロセッサ命令実行時間精度は保証しない 低 小 短 備考 : 上記定義は vecu-mbd WG 合議結果による 本 WG で審議の結果 この表に示す用語を使用することにした 95

96 4.4 時間精度の分類定義 (ATAL) 補足 TLM(SystemC TLM-2.0) で規定されるシミュレーション時間精度の分類定義との関連を以下に示す 車載制御用途での時間精度の分類定義 TLM(SystemC TLM-2.0) で規定されるシミュレーション時間精度の分類定義 レベル ATAL-3 ATAL-2 定義および説明 誤差 5% 以内 バス調停やパイプライン制御をモデル化することでプロセッサクロックサイクル数をある程度厳密に模擬 誤差 15% 以内 各命令毎 アクセス先毎 平均実行サイクル数設定等によりプロセッサクロックサイクル数をラフに推定して模擬 ATAL-1 誤差最大値保証せず 全命令一律に 1 プロセッサクロックサイクル等で模擬 時間指定されたタイマ割込みやイベント発生のタイミングは保証するが プロセッサ命令実行時間精度は保証しない レベル AT LT 定義および説明 Approximately-timed 別名 cycle-accurate マイコン内部アーキテクチャの性能調査に十分な精度 Loosely-timed O/S 起動とマルチコアシステム実行のための十分なタイミング精度各トランザクションは開始と終了の 2 つのタイミング ポイントを持つ AT と ATAL-3 とは 同等の精度 LT は ATAL-2 と ATAL-1 との間の精度 96

97 4.5 時間精度の評価方法 基本的考え方 時間精度の評価方法の基本的考え方を以下に示す プロセッサ命令実行の時間精度を評価 標準テストベンチ ( 何本か流す ) の範囲で評価 標準テストベンチで実行した場合 誤差何 % と言う評価 評価のリファレンスは実機による測定 ( マイコンのタイマー活用 ) ( リファレンスの別案として設計データ RTL のシミュレーションも考えられるが シミュレーション時間が大きく現実的ではない ) 標準推奨テストベンチ 以下のテストベンチを標準推奨する EEMBC-Automotive 同テストベンチは 自動車などのアプリケーション分野におけるマイコンの性能評価に用いられているベンチマークテストプログラムである. 97

98 4.5 時間精度の評価方法 参考 標準推奨テストベンチ選定の理由 (1) 方式案として 以下の 2 案を考慮した 案 1: 従来のテストベンチのいずれかを選定する 選定候補 : EEMBC-Automotive ( 現状 最も一般的なテストベンチである ) 案 2: 本 WG で ユースケースのモデルから新たなテストベンチを開発するたとえば 実証実験で活用の パワーウインドウシステムモデル から抜粋する同モデルをターゲットマイコン用に作成し 少なくとも以下の 3 種の負荷率を評価する 1 基盤ソフト部 ( 含む入出力ドライバ ) 2 アプリソフト部 ( 浮動小数点 ) 3 アプリソフト部 ( 固定小数点 ) (2) 両案の比較を以下に示す 総合評価の結果 案 1: EEMBC-Automotive を標準推奨とした 方式 仮想マイコンでの測定容易性 実マイコン ( ターゲットボード ) での測定容易性 案 1: 従来のテストベンチ EEMBC-Automotive 案 2: ユースケースのモデルから新たなテストベンチを開発 ( プラントモデルと連動させるのは困難 ) 標準化 ユースケースとの親和性 ( 国際標準的なテストベンチといえる ) 性能評価のためのベンチマークであり 実際のアプリソフトではない ( 国際標準的なテストベンチ用モデルは知られていない ) ユースケースのモデルから生成されるので 実際のアプリソフトには近いと考えられる 総合評価 標準推奨 (3) ただし 標準推奨テストベンチ (EEMBC-Automotive) でも以下の課題は残る a. I/O 系の時間精度は評価されない b DMA やマルチコアなどによるバス競合負荷は評価されない 98

99 第 1 章仮想 ECU シミュレータの導入 活用の狙い第 2 章開発プロセス上の位置付け第 3 章現状事例 ( ユースケース ) 第 4 章時間精度について第 5 章複数シミュレータの同期化 5.1 複数 ECU 協調シミュレーションの概要 5.2 プラントモデルとコントローラモデルの同期化 5.3 複数コントローラモデル間の同期化第 6 章モデル間インタフェースについて第 7 章ユーザインタフェース (UI) について第 8 章フォールト注入について第 9 章性能評価 (CPU 負荷率 ) 第 10 章周辺モデル設計における留意点 99

100 5.1 複数 ECU 協調シミュレーションの概要 複数 ECU 協調シミュレーションのビジョン : 仮想車一台分シミュレーションの実現 新方式 Full Vehicle Off-Line simulation コントローラも含め全て仮想化 従来方式 Full Vehicle HILS コントローラは実機 B-CAN HILS F-CAN Actual Object Code Actual Object Code Actual Object Code Actual Object Code Vehicle I/F I/F I/F I/F Operation Pattern Virtual ECU Virtual ECU Virtual ECU Virtual ECU B-CAN F-CAN 事例 1 仮想車一台分シミュレーション より引用 Environment 100

101 5.1 複数 ECU 協調シミュレーションの概要 複数 ECU 協調シミュレーションのシステム構成 プラントモデル 車両挙動モデル Engine モデル 車両モデル Head Light モデル Driving Position モデル T/M モデル ブレーキシステムモデル EPS G/B ASSY モデル Power Window /Mirror モデル Wiper モデル Door モデル コントローラモデル ECU モデル エンジン系 ECU シャシー系 ECU ボディー系 ECU FI/AT ECU ADAS ECU ESC ECU EPS ECU Power Window ECU 通信バスモデル ( 例 :CAN バスモデル ) 101

102 5.2 プラントモデルとコントローラモデルの同期化 プラントモデルとコントローラモデルの協調シミュレーションの構成 本節では ECU1 台の場合における プラントモデルとコントローラモデルの協調シミュレーションの構成と同期化について解説する Simulink プラントモデル 仮想 ECU シミュレータ コントローラモデル (ECU モデル ) マイコンモデル Simulink プラントモデル サンプリング サンプリング ポート ポート サンプリング サンプリング サンプリング サンプリング ポート ポート サンプリング サンプリング サンプリング サンプリング ADC サンプリング サンプリング タイマ タイマ サンプリング サンプリング 連成するツール間のデータの受け渡しで 適切なサンプリング時間を指定要連成するツール間のデータの受け渡しで 固定したサンプリング時間を使用 102

103 5.2 プラントモデルとコントローラモデルの同期化 シミュレータ構成 ( 例 ) MATLAB/Simulink と仮想 ECU シミュレータを組み合わせた例を以下に示す シミュレーションの対象 シミュレーション用ツール 可変サンプリング時間を使用 最小サンプリング時間 :XXmsec 対象制御システム MATLAB/Simulink No1 仮想システムシミュ ECUシミュレーレータと連成するたタと連成するためのめの S-function S-function サンプリング時間の設定 コントローラ (ECU) No1システムシミュ レータ側の設定サンプリング時間を設定 サンプリング時間 ( 上記 s- function を設定と同じ値を ( 上記 s- 使用 function ) と同じ値を使用 ) マイコン マイコン上で実行するソフトウエア 仮想 ECU シミュレータ 103

104 5.2 プラントモデルとコントローラモデルの同期化 同期化周期とシミュレーション実行速度 ECU モデルとプラントモデルの同期化周期についても 以下を考慮要である 同期化周期は短いほど タイミング精度は上がるが シミュレーション実行速度は下がる長いほど タイミング精度は下がるが シミュレーション実行速度は上がる 当該インタフェースごとに 必要とされるタイミング精度を検討し 適切な同期化周期を定めることが望ましい 協調シミュレーション同期マスタスケジューラは その周期設定機能およびチューニング機能を持つことが望ましい その評価事例を以下に示す この試行事例の場合であれば 同期化周期を 10μs に短くするとシミュレーション実行速度が低下するので どうしても 10μs が必要なインタフェースを除いて 他のインタフェースは 100μs 以上の同期化周期とすることが望ましいことがわかる 同期化周期とシミュレーション実行速度の評価例 シミュレーション実行時間比 N/A 10ms 1ms 100us 10us MILS SPILS 備考 : (1)MILS は ECU モデル プラントモデル共に 1 ノードのプロセッサコアで実行した場合を示す SPILS は 2 ノードのプロセッサコアを用いて 1 台で ECU モデルを もう 1 台でプラントモデルを実行した場合を示す (2) この評価事例は あくまでも 1 つの試行事例であり モデルの規模や構成 利用するシミュレータ環境や PC の環境によって 評価結果は相違する 同期化周期 104

105 5.3 複数コントローラモデル間の同期化 複数 ECU 連動のための協調シミュレーション同期マスタスケジューラ 各 ECU/ 通信バス / プラントモデルのところでそれぞれ独立して実行するシミュレータ同士が データをやりとりして協調シミュレーションを実施 CAN 等の通信モデルとシミュレータ間データ同期を 協調シミュレーション同期マスタスケジューラ が実施 協調シミュレーション同期マスタスケジューラ データ同期 ( マスタ ) テ ータ同期 テ ータ同期 テ ータ同期 テ ータ同期 通信バス調停 通信バス調停 プラント連携 -1 通信ハ ス -1 通信ハ ス -2 プラント連携 -2 フ ラントシミュレータ ECU シミュレータ ECU シミュレータ ECU シミュレータ ECU シミュレータフ ラントシミュレータ 105

106 5.3 複数コントローラモデル間の同期化 複数 ECU 協調シミュレーションの同期化における留意点 各 ECU/ 通信バス / プラントモデルのところでそれぞれ独立して実行するシミュレータ同士が データをやりとりする場合には 同期化が必要である 同期化の周期は 以下のトレードオフがある 短いほど タイミング精度は上がるが シミュレーション実行速度は下がる長いほど タイミング精度は下がるが シミュレーション実行速度は上がる シミュレータ同士のデータのやり取りのインタフェースごとに 必要とされるタイミング精度を検討し 適切な同期化周期を定めることが望ましい 同期化周期は協調シミュレーション全体で同一値とするのではなく 各 ECU/ 通信バス / プラントモデル間インタフェースごとに適切な同期化周期を選択できるようにすることが望ましい 非同期インタフェースや ビット単位のタイミングが詳細動作に関与するインタフェース ( 例 :CAN バス ) においては 協調シミュレーション全体で期待される時間精度によって 同期化周期を選択できるようにすることが望ましい 例えば CAN バスの場合は メッセージレベルのラフなタイミング精度でもよいケースとビットレベルの詳細なタイミング精度を要求されるケースの 2 種が考えられ その各々で同期化周期は適切なものを選定する必要がある 同期化は 必ずしも定周期でなくともよい インタフェースによっては 次の同期化タイミングを延期してもよい場合もある 延期してもよい時間を算定し 同期化タイミングを可変調整することで シミュレーション実行速度を上げることができる ( ただし 延期してもよい時間を 簡易に予測計算できるモデルであることが前提条件となる ) ユーザへの要求事項 インタフェースごとに 期待する時間精度を考慮して同期化周期を指定すること ツールベンダ ( またはツール環境構築者 ) への要求事項 インタフェースごとに 適切な同期化周期を設定すること 同期化タイミングを可変調整することで シミュレーション実行速度を上げることができる場合には そのような高速化処理の実装を期待する 106

107 第 1 章仮想 ECU シミュレータの導入 活用の狙い第 2 章開発プロセス上の位置付け第 3 章現状事例 ( ユースケース ) 第 4 章時間精度について第 5 章複数シミュレータの同期化第 6 章モデル間インタフェースについて 6.1 モデル間インタフェースの分類 6.2 モデル間インタフェース仕様検討時の留意点 6.3 マイコン内部のモデル間インタフェースの標準化 (TLM インタフェース ) 6.4 マイコン外部との通信インタフェースの標準化 6.5 周辺モデル付 SILS とその標準化第 7 章ユーザインタフェース (UI) について第 8 章フォールト注入について第 9 章性能評価 (CPU 負荷率 ) 第 10 章周辺モデル設計における留意点 107

108 6.1 モデル間インタフェースの分類 (1) 仮想 ECU 入力回路モデル 入力ペリフェラルモデル 例 :A/D コンバータ マイコンコアモデル 出力ペリフェラルモデル 例 :PWM タイマー 出力回路モデル コア内インターフェース 双方向ペリフェラルモデル 例 :CAN コア外インターフェース 仮想マイコン 双方向回路モデル 仮想 ECU の外側には MODELISAR の FMI や VDA FAT-AK30 のライブラリなどが考えられる 108

109 6.1 モデル間インタフェースの分類 (2) コア内インタフェース マイコンコアモデルとマイコンペリフェラルモデルとの間のインタフェース 標準推奨仕様 SystemC/TLM2.0 インタフェース コア外インタフェース マイコン外部のモデルとのインタフェース DI DO AI AO PWM 通信 ( シリアル CAN LIN FlexRay など ) 109

110 6.2 モデル間インタフェース仕様検討時の留意点 期待すること 個別モデルの組合せ接続が可能なモデル間インターフェース仕様が望ましい シミュレータが異なっても共通に使えるモデル間インタフェース仕様が望ましい 仕様検討時の留意点 既存の標準仕様やデファクト仕様は極力活用する コア内インタフェースには SystemC/TLM2.0 を適用する 時間精度と処理速度や開発工数はトレードオフの関係にあるので 両立が困難な場合には 種別を定義し ユーザが選択できるようにする 本 WG では CAN 通信インタフェースモデルについては 以下の 2 種を検討処理速度優先の メッセージレベル 時間精度優先の ビットレベル ソフトウェアとの間のインタフェースや 試験シナリオなどユーザインタフェースについても標準化を考慮する 110

111 6.3 マイコン内部のモデル間インタフェースの標準化 (TLM インタフェース ) 概要 マイコン内部のモデル間インタフェースに関する標準化は すでにツール業界主導で推進され TLM インタフェース (TLM2.0) として制定されている 既存の標準仕様やデファクト仕様は極力活用するべきであり 本 WG においてもコア内インタフェースには TLM インタフェース (TLM2.0) の適用を推奨する TLM の経緯 2005/6 TLM 1.0 transaction-level modeling standard リリース 2008/6 TLM TLM library リリース 2009/7 TLM-2.0 LRM リリース TLM library リリース 2012/1 IEEE standard for Standard SystemC LRM の中に TLM2.0 は包含されてリリース 2012/7 ASI (Accellera System Initiative) SystemC 2.3 で公開リリース 111

112 6.3 マイコン内部のモデル間インタフェースの標準化 (TLM インタフェース ) TLM の特徴 データ転送を PIN I/F で行わず 関数コールにより表現する 効果 - シミュレーション高速化 - バス仕様によらない共通の関数表現 通常転送は以下の 2 種類を使用する blocking transport I/F (b_transport) 高速モデルで使用される (SW 開発向け ) non blocking transport I/F (nb_transport_fw, nb_transport_bw) 時間精度モデルにおいて使用される ( 性能見積もり ) 高速なメモリアクセスには direct memory I/F (DMI) が使用される 時刻を進めないアクセスにおいては debug transport I/F(transport_dbg) が使用される 112

113 6.3 マイコン内部のモデル間インタフェースの標準化 (TLM インタフェース ) TLM の記述例 出典 :IEEE standard for Standard SystemC LRM Blocking transport I/F ATAL-1 Initiator( マスタ ) から Target( スレーブ ) に転送開始時に Target での消費時間がわかる LT (Loosely Timed) Non-blocking transport I/F Initiator( マスタ ) から Target( スレーブ ) に転送後 Target から Initiator にレスポンスされるタイミングが 時間経過しないとわからない ATAL-3 AT (Approximately Timed) 113

114 6.4 マイコン外部との通信インタフェースの標準化 背景 マイコン外部のモデル間インタフェースに関する標準化は 一般化が困難であり 未だ標準化されていない 本 WG では 自動車制御用途で利用頻度が高い通信インタフェースのモデルの標準化を検討する方針とし その第 1 ステップとして CAN バスインタフェースに取り組むこととした CAN バスインタフェースは複数 ECU 間の通信に広く利用されており サプライヤの異なる複数 ECU モデルの接続を容易にするためにも 標準化が望ましい 本 WG で審議した標準推奨の CAN バスインタフェースモデルの名称は 以下とした vecu-can バスモデル 114

115 6.4 マイコン外部との通信インタフェースの標準化 vecu-can バスモデルの概要 ユースケースに応じて使い分けられるよう 2 種のタイミング精度のモデルを定義した 名称 vecu-can ハ スモテ ル _ メッセーシ レヘ ル vecu-can ハ スモテ ル _ ヒ ットレヘ ル 特徴高速版高精度版 概要図 ECU 1 マイコンモテ ル CPU CAN ECU n マイコンモテ ル CPU CAN ECU 1 マイコンモテ ル CPU CAN ECU n マイコンモテ ル CPU CAN Tx 値受け渡し CAN バス Rx 値受け渡し Tx Rx メッセージレベル転送 Tx 値受け渡し CAN バス Rx 値受け渡し Tx ビットレベル転送 Rx タイミング精度 メッセーシ レヘ ル ヒ ットレヘ ル 要求機能 アーヒ トレーションをメッセーシ 単位で制御 CAN2.0b 準拠 アーヒ トレーションをヒ ット単位で制御 ユースケース 仮想車 1 台シミュレーション ソフトウェア機能検証 フォールト注入 ( メッセージレベルタイミング ) CAN バス競合動作評価 フォールト注入 ( ビットレベルタイミング ) 115

116 6.4 マイコン外部との通信インタフェースの標準化 CAN バスと複数 ECU との同期化制御 CAN バスにフォーカスした場合の複数 ECU 協調シミュレーションの構成を以下に示す CAN バスモデルおよびその他のモデルとの同期化制御は 協調シミュレーション同期マスタスケジューラによって行われる 協調シミュレーション同期マスタスケジューラ ( マスタースケジューラ ) データ同期 ( マスタ ) データ同期 データ同期 テ ータ同期 テ ータ同期 CAN バス時間調停 高速 CAN ハ ス用 CAN バス時間調停 低速 CAN ハ ス用 通信バス調停 その他の通信ハ ス用 プラント連携用 高速 CAN バスモデル 低速 CAN バスモデル シグナル I/F シグナル I/F ECU シミュレータ ECU シミュレータ ECU シミュレータ ECU シミュレータ 116

117 6.5 周辺モデル付 SILS とその標準化 周辺モデル付 SILS とは SPILS ではターゲットオブジェクトをシミュレートするが 周辺モデル付 SILS ではシミュレーション実行 PC のオブジェクトである X86 オブジェクトで実行する 周辺モデルとはマイコン内の周辺機構 ( タイマ ADC PWM CAN など ) のモデルを指す また 周辺モデルおよび標準基盤ソフトモデルは ターゲットマイコンとは非依存の標準化を図る 周辺モデル付 SILS アプリソフト (X86 オブジェクト ) 標準 OS モテ ル -x86 標準入出力サービスモデル -x86 標準ドライバモデル -x86 (ISS レス ) ペリフェラル標準 HW モデル (ATAL1) 回路モデル プラントモデル 117

118 6.5 周辺モデル付 SILS とその標準化 SPILS および SILS との比較 メリット SPILS との比較 マイコンコア ( プロセッサ ) モデルあるいは ISS が不要なので マイコンモデル開発工数が省略できる シミュレーション処理実行速度が速い SILS との比較 周辺モデルが付いているので SPILS で構成した他のマイコンモデルや ECU モデルと接続できる プロセッサ命令実行時間やイベント割込などをシミュレーションできる ( ただしプロセッサ命令実行時間の時間精度は低い 時間精度レベル :ATAL-1) デメリット C ソースコードの検証はできるが ターゲットオブジェクトの検証はできない マイコン非依存部の検証はできるが マイコン依存部の検証はできない 周辺モデル付 SILS 用に基盤ソフトを開発し組み込む必要がある (SILS はシミュレータツールによる周期起動 ) 118

119 6.5 周辺モデル付 SILS とその標準化 周辺モデル付 SILS の用途周辺モデル付 SILS は以下の用途に利用できると考えられる (1) 複数マイコンや複数 ECU の検証において 搭載オブジェクトコードの検証対象以外の 副次的なマイコンや ECU の簡易モデルを作成するのに利用できる 例 1: サブマイコンのモデル化サブマイコンのマイコンモデルが提供されなくとも サブマイコンの機能を周辺モデル付 SILS 上で構築する 検証対象のメインマイコンは SPILS 上で構築する 両者を接続し ECU モデルとして作り上げる 例 2: 複数 ECU システムにおいて 検証対象のメイン ECU は SPILS 上で構築する 副次的な ECU は もちろん SPILS 上で構築してもよいが マイコンモデルが提供されなくても 同 ECU の機能を周辺モデル付 SILS 上で構築する これらの ECU モデルを接続し 複数 ECU システムとして作り上げる 119

120 6.5 周辺モデル付 SILS とその標準化 標準基盤ソフトモデル (OS 入出力サービス ドライバ ) および周辺モデルの標準化とメリット ユーザへのメリット標準ドライバモデルにより 周辺モデル付 SILS のペリフェラルプログラミングモデルを標準化できる 標準 OS モデル 標準入出力サービスモデルにより アプリソフトの搭載を容易にする 仮想 ECU 環境開発者へのメリット OS 入出力サービス ドライバのモデルの標準化により 1 種類開発すれば済む 周辺モデル付 SILS ( マイコンによらず共通 ) SPILS ( マイコン毎に異なる ) 周辺モデル付 SILS B 社マイコン 標準 OS モテ ル -x86 アプリソフト (X86 オブジェクト ) (ISS レス ) 標準入出力サービスモデル - x86 標準ドライバモデル -x86 標準化 A 社マイコン 通信インターフェース ( 標準化 ) SPILS アプリソフト 基盤ソフト ISS-a vecu-a ペリフェラル標準 HW モデル (ATAL1) 回路モデル プラントモデル ペリフェラル対象 HW モデル -a 回路モデル -a プラントモデル 120

121 6.5 周辺モデル付 SILS とその標準化 アプリソフトの作成方法 方法 1: 新規に作る ( 簡易な機能であれば この方法でも十分 ) 方法 2: SILS で動いているアプリソフトを移植したいタスク周期処理を 標準 OS モデルの割り込みハンドラに登録する周辺機構への入出力処理を 標準入出力サービスモデルの対象変数リストに登録する 121

122 第 1 章仮想 ECU シミュレータの導入 活用の狙い第 2 章開発プロセス上の位置付け第 3 章現状事例 ( ユースケース ) 第 4 章時間精度について第 5 章複数シミュレータの同期化第 6 章モデル間インタフェースについて第 7 章ユーザインタフェース (UI) について 7.1 ユーザインタフェース (UI) の分類 7.2 ユーザインタフェース (UI) 仕様検討時の留意点第 8 章フォールト注入について第 9 章性能評価 (CPU 負荷率 ) 第 10 章周辺モデル設計における留意点 122

123 7.1 ユーザインタフェース (UI) の分類 (1) 概要 仮想 ECU 環境においては ユーザインタフェース (UI) に関する標準化は 従来あまり検討されておらず ユーザごとに個別開発されるケースが主流であった そのため その個別開発費用が初期導入費用を押し上げるという課題があった 本 WG では 自動車制御用途で利用頻度が高いユーザインタフェース (UI) を分類整理し その標準化を検討する 標準化においては 標準共通仕様とユーザ個別仕様に分離し 標準共通仕様のカバーする範囲をなるべく多くすることと ユーザ個別仕様を全く付加しなくとも 標準共通仕様のみで基本的な利用ができることが望ましい 備考 標準装備 UI とは 本章内で用いる 標準装備 UI とは 仮想 ECU シミュレータを提供するツールベンダが標準的に装備する UI を意味する ユーザ個別仕様をヒアリングしてカスタマイズ開発する ユーザ個別開発 UI と区別するために用いる 標準装備 UI は 本章で記述する標準共通仕様をカバーするものであり どのツールベンダでも標準的に装備することが望ましい しかし その詳細仕様や画面仕様などはツールベンダの間で異なってもかまわない 備考 UI: User Interface 123

124 7.1 ユーザインタフェース (UI) の分類 (2) ユーザインタフェース (UI) の分類一般的には以下を考慮要である テストシナリオ設定 UI: テストシナリオを設定する 画面操作および設定 API が必要である 結果収集 UI テスト結果を収集する 画面表示および収集 API が必要である テスト実行制御 UI テスト実行を制御する 画面操作および設定 API が必要である 仮想 ECU 特有の追加機能として以下も考慮要である フォールト注入シナリオ設定 UI CPU 負荷率測定設定 UI 124

125 7.2 ユーザインタフェース (UI) 仕様検討時の留意点 (1) 想定すべきユースケースと期待される標準装備ユーザインタフェース (UI) 仮想 ECU のユースケースとしては 以下が考えられる その各々について 期待される標準装備ユーザインタフェース (UI) を以下に示す 1 上流設計におけるシステム検証標準装備ユーザインタフェース (UI) としては Simulink モデルのユーザインタフェース (UI) が有力候補である 本 WG で 11 年度に実証実験したユースケースが本ケースにあたる テストシナリオ設定 UI 結果収集 UI テスト実行制御 UI などについては Simulink の環境が準備する UI を活用できることが期待される 2 仮想 HILS 標準装備ユーザインタフェース (UI) としては HILS ライクのユーザインタフェース (UI) が有力候補である テストシナリオ設定 UI 結果収集 UI テスト実行制御 UI などについて 標準装備 UI の提供が期待される 3 仮想 ICE 標準装備ユーザインタフェース (UI) としては ICE ライクのユーザインタフェース (UI) が有力候補である テストシナリオ設定 UI 結果収集 UI テスト実行制御 UI などについて 標準装備 UI の提供が期待される 125

126 7.2 ユーザインタフェース (UI) 仕様検討時の留意点 (2) 4 フォールト注入フォールト注入は 実機に比較して仮想 ECU が得意とする評価項目である フォールト注入シナリオ設定 UI について 標準装備 UI の提供が期待される フォールト注入については 多様な仕様が考えられるが 標準装備 UI の検討においては簡易なレベルに留め 複雑なレベルについては API を設けてユーザが追加設計できるようにすることが望ましい 5 性能評価 (CPU 負荷率 ) 性能評価 (CPU 負荷率 ) は 実機に比較して仮想 ECU が得意とする評価項目である CPU 負荷率測定設定 UI について 標準装備 UI の提供が期待される CPU 負荷率測定については 多様な仕様が考えられるが 標準装備 UI の検討においては簡易なレベルに留め 複雑なレベルについては API を設けてユーザが追加設計できるようにすることが望ましい 標準装備 UI の検討においては 評価すべき対象項目を限定することが必要となる 例えば 評価できるタスク群の周期は 3 レベルとするなど 126

127 7.2 ユーザインタフェース (UI) 仕様検討時の留意点 (3) 6CAN アナライザ実機の場合に CAN アナライザを利用するケースを仮想化するユースケースにおいては CAN アナライザライクのユーザインタフェース (UI) が有力候補である 本 WG では CAN インタフェースの標準化を検討中である CAN アナライザライクのユーザインタフェース (UI) の提供が期待される あるいは CAN アナライザベンダが仮想 CAN アナライザを提供してくれる場合には 仮想 CAN アナライザと仮想 CAN インタフェースとの接続インタフェースの標準化が期待される 127

128 第 1 章仮想 ECU シミュレータの導入 活用の狙い第 2 章開発プロセス上の位置付け第 3 章現状事例 ( ユースケース ) 第 4 章時間精度について第 5 章複数シミュレータの同期化第 6 章モデル間インタフェースについて第 7 章ユーザインタフェース (UI) について第 8 章フォールト注入について 8.1 フォールト注入のねらい 8.2 フォールト注入の分類 8.3 フォールト注入仕様検討時の留意点第 9 章性能評価 (CPU 負荷率 ) 第 10 章周辺モデル設計における留意点 128

129 8.1 フォールト注入のねらい 実機システムによるフォールト注入テストの課題 1. 任意の場所や タイミングでフォールト注入 ( 再現 ) できない 2. 任意の場所を観測が困難 3. 設計検証の着手に遅延 実機検証環境 HILS ECU 単体 車両モデル ECU 評価ベンチ SW BOX ECU IC ECU 外部端子や内部端子の電源短絡 地絡 断線を検証 故障再現に限界あり 安全要求に対するテストカバレッジ向上のために制御性や観測性 網羅性の面で仮想環境が活用できる 129

130 8.1 フォールト注入のねらい 目的仮想環境におけるフォールト注入テストを可能とし システムレベルでの安全設計の要求を完全に検証する うれしさ 1. 任意の場所やタイミングでフォールト注入が可能 2. システム内部状態の任意の挙動を可視化 3. 実機完成前に事前検証を前倒しかつ 検証環境の高速化 4. 実機を壊さずに検証可能 仮想検証環境 LAN システムレベル ECU ECU ECU ECU マイコン + フ ラントを PC 上で模擬 オフ シ ェクトコート マイコンモテ ル 仮想 ECU H/W モテ ル H/W モテ ル SPILS 用ツール PC/ サーバ フ ラントモテ ル マイコン内外の情報を可視化 あらゆる故障を注入できる仮想モデルを用いてシステム検証を可能にする 130

131 8.2 フォールト注入の分類 フォールトモード 半導体レベル ECU( マイコン ) レベル Low 固着 電源 クロック断 High 固着 ROM/RAM 誤データ書込 / 読出 ドリフト I/Oポートからの誤出力 発振等 割り込みタイミングずれ等 システムレベル パリティエラー フレームエラー オーバーフロー タイミングエラー等 仮想環境におけるフォールトモードの実装 入力ヘ リフェラル Ex. ADC ECU マイコン コア 双方向ヘ リフェラル 出力ヘ リフェラル Ex. PWM Ex. CAN 入力 H/W 回路 H/W 回路 ~ 実回路 ~ 機能ブロック 出力 半導体の基本故障は オーフ ン, ショート, 固着等 抽象化 入力 ~ 仮想回路 ~ 機能ブロックモデル 機能レベル a+b=c 出力 機能ブロックモデルの入出力でフォールトを注入 ( 再現 ) フォールトモードの種類 実装手法の検討が必要である 131

132 8.3 フォールト注入仕様検討時の留意点 フォールト注入方針の策定 安全設計の検証対象レベルは? 必要なフォールトの分類は? 要求精度と検証時間は? フォールト注入する箇所は? フォールト注入をどう実装する? 対象レベル Ex. ECU, マイコン, フ ラントモテ ル等 LAN オフ シ ェクトコート システムモデル ECU ECU ECU ECU 仮想 ECU マイコンモテ ル H/W モテ ル H/W モテ ル SPILS 用ツール PC/ サーバ vhils フ ラントモテ ル モデル抽象度 Ex. トランサ クション, 端子レヘ ル等 注入手法 機能ブロックモデル トランサ クションレヘ ル ( 高抽象度 ) 端子レヘ ル ( 高精度 ) Ex. マイコンモテ ル外 / 内部実装, 機能フ ロック外 / 内実装等 マイコンモデル 機能ブロック マイコン外部実装 ( マイコン影響なし ) フォールトシナリオ 機能ブロックモデルフォールトモデル 利用目的に応じたフォールト注入の方針を明確にすることが重要である 132 入力機能機能フ ロック 仮想 ECU マイコンモテ ル コア 双方向機能 H/W モテ ル H/W モテ ル 出力機能 I/F 機能 マイコン内部実装 ( 機能影響なし )

133 第 1 章仮想 ECU シミュレータの導入 活用の狙い第 2 章開発プロセス上の位置付け第 3 章現状事例 ( ユースケース ) 第 4 章時間精度について第 5 章複数シミュレータの同期化第 6 章モデル間インタフェースについて第 7 章ユーザインタフェース (UI) について第 8 章フォールト注入について第 9 章性能評価 (CPU 負荷率 ) 9.1 車載制御ソフトウェアにおける CPU 負荷率とは? 9.2 CPU 最大負荷率測定の目的 9.3 用法 9.4 仮想 ECU の要件 9.5 今後の動向第 10 章周辺モデル設計における留意点 133

134 9.1 車載制御ソフトウェアにおける CPU 負荷率とは? <CPU 負荷率と CPU 最大負荷率 > CPU 負荷率 (%) = 実行時間 実行周期 *100 で求める CPU 最大負荷率は実行時間が最大となる場合 つまり CPU 最大負荷率 (%) = 最大実行時間 実行周期 *100 となる 実行周期 関数 1 関数 2 割込 1 関数 3 割込 2 アイドル動作 アイドル動作 実行時間 最大となる場合を最大実行時間とする ここで 実行時間とは実行周期内に実行 / 動作する状態の時間つまりアイドル動作 ( 実行周期経過待ち ) している状態を除く 134

135 9.2 CPU 最大負荷率測定の目的 CPU 負荷率が 100% を超えると 処理が飛ばされる 処理タイミングにズレが発生する 意図していない処理順序になる等が発生し 結果意図しない動作になることが懸念される CPU 最大負荷率を測定し 100% 迄のマージンを把握することを目的とする 例 関数 1 に於いて割り込みを使用した通信の送受信処理を実施している場合 CPU 負荷率が 100% を超えると以下の様な動作となることが懸念される 実行周期 3 次周期との間隔が短くなる 関数 1 関数 2 割込 1 関数 3 割込 2 関数 1 関数 1 実行時間 1 実行時間が実行周期をオーバー 2 起動タイミングにズレが発生 4 通信処理が終了しない状態で関数 1を実行してしまう 135

136 9.3 用法 複数のタスクに対しての測定 機能により要求性能が異なるため 複数のタスク ( 実行周期 ) を持つ場合がある その際には 全てのタスクに於いて CPU 最大負荷率を確認しなければならない 1ms タスク 10ms タスク < タイミングチャート ( 例 )> 10ms それぞれのタスクに対して負荷測定 以下 < タイミングチャート ( 例 )> の様に周期が長いタスク実行の間に周期が短いタスクが実行される為 そのことも考慮する 1ms タスク 1ms 10msタスクタスク アイドル動作 1ms 136

137 9.3 用法 実機での測定方法 ( 例 ) 10ms 経過? Yes No <10ms タスクを内部タイマを使用して経過待ちをチェックして実現している場合 > CPU 最大実行時間保存用の RAM を準備 10ms 経過判断用のタイマカウンタを利用し カウンタ値が保存されたデータより大きければ更新 という処理を 10ms タスクの最終処理に入れる 最大実行時間となるような条件を ECU に入力する RAM モニタ機能を利用し結果の読み出しを行う その他 簡易的に ICE のトレース機能を利用する方法等もある 137

138 9.4 仮想 ECU の要件 < 負荷率の計測機能 > ソースコードとテストシナリオ ( 最大負荷率となるシナリオ ) を入力し レポートを出力する テストシナリオ レポート ソースコード 138

139 9.4 仮想 ECU の要件 < 負荷率の計測手段 > 1 関数毎の実行時間を計測する ( 関数の call~return) Input Output 関数毎の ** クロック or **ms ** クロック or **ms **% 2 全体の実行時間 ( アイドル ~ アイドル ) を計測する Input Output ** クロック or **ms **% 3 負荷率を算出する Input Output **% 出せるOutputにより Inputとして必要な情報も変化する 139

140 9.4 仮想 ECU の要件 参考 : 最大負荷率となるパスの検索機能 ソースコードから最大実行時間となるパスを検索そのテストシナリオを出力するツールが存在する この様なツールとの連携やこの様な機能の取り込みがあるのが望ましい 最大実行時間となるパス テストシナリオ 140

141 9.4 仮想 ECU の要件 ネック箇所の検出 NG の場合 ( マージンが無い場合 ) 関数毎や機能毎の処理時間が測定できれば 負荷の大きい処理 ( ネック箇所 ) を特定できる 特定したことにより 負荷分散や処理の効率化を施すことも可能になる 関数 x 処理時間妥当 関数 y 処理時間長い 関数 y 141 負荷分散や処理効率化を実施し処理時間を妥当に

142 9.5 今後の動向 マルチコア マルチコアを使用した場合の CPU 負荷測定について 今後 組込みソフトウェアでもマルチコアを使用したシーンの増加が見込まれる バスの負荷 リソースのロック等コア間のやりとりまで仮想化する必要がある またシングルコア時には単純にマージンをとるだけで良かったモデルの精度が 複数のコア間のやりとりが発生する為 コア間のやりとりに影響が出る ( 単純に使用できるかは構成 / 構造に依存する ) 142