ecuソフトウェア開発における検証・検査技術開発への取り …...150 2 0...

This information is the exclusive property of DENSO CORPORATION. Without their consent, it may not be reproduced or given to third parties.

MathWorks Automotive Conference 2014２０１４年６月２７日 (金)

ECUソフトウェア開発における検証・検査技術開発への取り組み

株式会社デンソー

電子基盤システム開発部モデルベース技術開発室長

野村肇


1 /30

1949年12月16日

（就業人員ベース）

設立

資本金

売上高

経常利益

従業員数

（日本62、北米26、欧州35、豪亜56、南米/その他6）

連結子会社数

（日本13、北米4、欧州3、豪亜11、南米/その他2）

持分法適用関連会社数

1,874 億円

185

33

連結単独

4兆 959 億円2兆 4,908 億円

連結単独

4,196 億円2,993 億円

139,842 名38,581 名

連結単独

/ 2014年3月31日現在

0.1. 会社紹介


2 /30

快適・利便

ハイブリッド車・電気自動車用製品、ガソリンエンジンマネジメントシステム、ディーゼルエンジンマネジメントシステム、スタータ、オルタネータ、ラジエータ、など

安心・安全走行支援システム用センシングシステム、ABS／ESC用アクチュエータ＆コンピュータ、ヘッドランプコントロールシステム（AFS）、エアバッグ用センサ＆コンピュータ、車両周辺監視システム、コンビネーションメータ、ワイパシステム、など

カーエアコンシステム、バス用エアコン、空気清浄器

カーナビゲーションシステム、ETC車載器、リモートセキュリティシステム、リモートタッチコントローラ、スマートキー、車両運用システム（ドライビングパートナー）など

環境

0.1. 会社紹介

自動車分野の主要製品


3 /300.2. 本日の講演内容

1. 背景1. モビリティ社会の動向

2. 車載電子システムの動向と課題

2. ECUソフトウェア開発1. 車載制御ソフトウェア開発の現状

2. 開発プロセスとモデルベース開発

3. 検証・検査技術開発への取り組み1. 機能安全（ISO26262）

2. Auto Test Generation（ATG）の導入

3. 今後の取り組みの方向

4. まとめ


4 /301. 背景


1. モビリティ社会を取り巻く動向

2. モビリティ社会の将来像

2. 車載電子システムの動向と課題1. カーエレクトロニクスの歴史と分野

2. 車載ソフトウェアの特徴

3. 車載電子システムの規模の推移

4. 車載電子システムの変遷とデンソーの取組み


5 /301.1.1. モビリティ社会を取り巻く動向

車の電動化により、家や地域とエネルギー連携スマートグリッド、マイクログリッド

インフラ協調（車車、路車）による半自動運転

常時接続により、IT・クラウドサービス活用

車の利用スタイルの変化カーシェアリング、マルチモーダル

車の電動化により、家や地域とエネルギー連携スマートグリッド、マイクログリッド

インフラ協調（車車、路車）による半自動運転

常時接続により、IT・クラウドサービス活用

車の利用スタイルの変化カーシェアリング、マルチモーダル

将来社会将来社会

交通事故ゼロ社会の実現

衝突安全～予防安全～運転支援

普及のための既存製品の低コスト化と更なる先進安全装備の開発

交通事故ゼロ社会の実現

衝突安全～予防安全～運転支援

普及のための既存製品の低コスト化と更なる先進安全装備の開発

交通安全交通安全地球にやさしい環境作りへの貢献

温暖化防止に向けたＣＯ２排出量低減、燃費改善、エネルギー多様化

電動化（ハイブリッド、PHV、EV）エンジン → モータへの変化

地球にやさしい環境作りへの貢献

温暖化防止に向けたＣＯ２排出量低減、燃費改善、エネルギー多様化

電動化（ハイブリッド、PHV、EV）エンジン → モータへの変化

地球環境地球環境


6 /301.1.2. モビリティ社会の将来像

いつでも、どこでも、誰でも、ストレスなく、ネットワークから様々なサービスを享受ユビキタス社会ユビキタス社会

スマートグリッドITサービス利用増加

社会官制自動運転

BATT

運用管理センター

BATT

発電

発電送電管理

モニタリング

PLC or 無線スマートメータ

管制センター

マルチモーダル移動通行課金

ｶｰｼｪｱﾘﾝｸﾞ

ﾊﾟｰｸ＆ﾗｲﾄﾞ車間制御

衝突防止

歩行者衝突防止

充電ｽﾎﾟｯﾄ

電力ﾏﾈｼﾞﾒﾝﾄ

POI

地図

経路計算

・・・

クラウド

ｸﾗｳﾄﾞ活用ｸﾗｳﾄﾞ活用

常時接続継続走行距離

携帯電話網

WiFi

インフラ通信

車々間通信

DSRC

ｽﾏｰﾄﾌｫﾝ連携ｽﾏｰﾄﾌｫﾝ連携

常時接続

社会インフラとの連携による新しいモビリティ社会に社会インフラとの連携による新しいモビリティ社会に


7 /301.2.1. カーエレクトロニクスの歴史と分野20101970 1980 1990 2000

●半導体●マイコン ●高密度実装

●システムオンSi

●デジタル化●ネットワーク化●ソフトウェア化

分散化統合化

環境

安全

快適

利便

●排ガス対策 ●燃費向上

●ITS

オルタネータ

燃料噴射制御リーンバーン

直噴

自動課金システム

●快適性向上

●情報通信化

●安全性追求

カーエアコンオートエアコン

ナビ自動車電話

VICS ATIS

ABS エアバック VSC ACC

ASV

イグナイタ

ICレギュレータ点火時期制御

エンジン制御空気圧警報配光制御

ナイトビジョン

GPSナビ

エアサス制御車高制御

VVT ハイブリッド

by ワイヤ

DSRC

イモビライゼーション

製品動向製品動向製品動向

●メカニカル制御→エレクトロニクス化

支える技術支える技術支える技術●オプトエレクトロニクスIC LSI ASIC

・カーナビゲーションシステム・自動車電話・ETCシステム・オーディオシステム

情報通信情報通信情報通信

・パワーステアリング制御システム・電子制御ブレーキシステム・運転支援システム

シャーシ制御シャーシ制御シャーシ制御

・エアコンシステム・エアバッグシステム・スマートエントリ・セキュリティシステム

ボデー制御ボデー制御ボデー制御

・エンジン制御システム－ガソリンエンジン制御－ディーゼルエンジン制御

・トランスミッション制御システム

パワートレイン制御パワートレイン制御パワートレイン制御

PHV,EVISS

PCS 衝突回避インフラ協調

WiFi

●SiC

車載システムの高度化に伴い、カーエレクトロニクスの重要性は高まる一方車載システムの高度化に伴い、カーエレクトロニクスの重要性は高まる一方

2020

ｽﾏｰﾄｸﾞﾘｯﾄﾞ

インフラ協調

限定自動運転

●PF化

ECU(Electronic Control Unit)


8 /301.2.2. 車載ソフトウェアの特徴

プロダクトとしての特徴プロダクトとしての特徴

高い品質要求機能性・信頼性・効率性

（+ 使用性・保守性・移植性）

ハードリアルタイム性省リソースドメインによる違い

制御系・ボデー系・情報系

規模

／リ

ソー

ス規

模／

リソ

ース

リアルタイム性リアルタイム性

情報系情報系

ボデー系ボデー系

制御系制御系

カーメーカとの分担開発すり合わせ開発

車両開発に同期した開発実機検証と不具合修正

バリエーションの多さ仕向け/使用環境/オプション

機能改良/車種展開

プロセスとしての特徴プロセスとしての特徴アイデア/構想

制御仕様設計

ソフトウェア設計

実装

テスト

適合

車両評価

サプライヤの担当範囲


9 /301.2.3. 車載電子システム規模の推移

世の中の予測では、2015年に1億行レクサスLS460は、1700万行（ナビを除いて700万行）

世の中の予測では、2015年に1億行レクサスLS460は、1700万行（ナビを除いて700万行）

注：表中に該当するOEM名とデータの出所を明記（）内がデータの出所出所：記事検索、BCGデータベース及び分析

コー

ド行

数

1

10

100

1000

10000

100000

1000000

10000000

1960 1970 1980 1990 2000 2010 2020

GM(eWeek）

（日経エレクトロニクス）日産

GM(eWeek）（日経金融新聞）

GM(eWeek）（Ward' Auro

World）

（ECN)

DC(BCGデータ）

DC(BCGデータ）

DC(BCGデータ）

DC(BCGデータ）

DC(BCGデータ）

トヨタ（日経産業新聞）（Ward' Auro World）日産（日経エレクトロニクス）

DC(BCGデータ）

（日経ビジネス）

2015

１億行


10 /30

1990 2005 2010 201x

1.2.4. 車載電子システムの変遷とデンソーの取組み

独立制御車両ｼｽﾃﾑのｲﾝﾃﾘｼﾞｪﾝﾄ化

＋インフラ統合運動制御

統合システム

制御システム制御システム制御システム

車両統合システム

コンポーネントベース開発

モデルベース開発

プラットフォームベース開発

従来（コードベース開発）

組織連携

業界連携

職人技

チーム連携

デンソーの取組みデンソーの取組みデンソーの取組み

個別単独階層化、構造化、大規模化ネットワーク化

ECUシステムECUECUシステムシステム


11 /302. ECUソフトウェア開発








4. まとめ


12 /30

車載制御ソフト開発の動向・法規制対応による緻密化

・システムバリエーション増加

・電動化による大規模化

・短期開発競争の激化

車両日程

★試作

X ヶ月

X/2 ヶ月

★試作

★試作

★試作

2.1. 車載制御ソフトウェア開発の現状

コントローラ開発の動向・仕様作成のルールは協調、実装は競争→ AUTOSAR ・安全性を確保する設計思想→ 機能安全(ISO26262) ｱｲﾄﾞﾙｽﾄｯﾌﾟ

EV

ﾏｲﾙﾄﾞHVｽﾄﾛﾝｸﾞHVｽﾄﾛﾝｸﾞPHV

FC

CO2規制強化

‘15 ‘20

(日)

(欧)

(米)

‘10‘08

6千万台

8千万台

‘15 ‘20‘10

(g/km)

100

150

200

HV/EV/FCﾎﾞﾘｭｰﾑ増加

短期開発

(自動車生産台数予測)

(CO2規制予測)

標準規格に従った自動化手法の適用が重要

標準規格に従った自動化手法の適用が重要

ｼｽﾃﾑﾊﾞﾘｴｰｼｮﾝ増加


13 /302.2. 開発プロセスとモデルベース開発

ユニットプロセス MBDによる、制御仕様開発の高品質化・効率化• 仕様検証• 要件記述手法･記法の確立

ソフトプロセス MBDによる、ソフト開発の自動化･効率化• 自動コード生成• 自動テスト生成

車両プロセスMBDによる、機能最適配置/統合制御の実現• 車両レベルシミュレーション環境• プラントモデル管理･再利用

車両レベルシミュレーション

論理アーキ設計

物理アーキ設計

仕様(機能)ATG

MILS

Program levelATG

Auto CodeGeneration

要件記述手法･記法

形式的検証

Simulation

Generation

本日のテーマ

自動化を進めるためには、モデルベース開発が必要（一つの解）自動化を進めるためには、モデルベース開発が必要（一つの解）


14 /303. 検証・検査技術開発への取り組み








4. まとめ


15 /303. 検証・検査技術開発への取り組み


2. Auto Test Generation（ATG）導入1. 可視性（Observability）

2. 可視性の実現

3. 適用結果

3. 今後の取り組みの方向1. 機能ATG


16 /30

For model-based development, software unit testing can be carried out at the model level followed by back-to-back comparison tests between the model and the object code. The back-to-back comparison tests are used to ensure that the behaviour of the models with regard to the test objectives is equivalent to the automatically-generated code.

■ ISO26262 Part6 9.4.6 NOTE4

3.1. 機能安全（ISO26262）

ISO26262で求めるB to B比較テストを満足する自動化を実現する

ISO26262で求めるB to B比較テストを満足する自動化を実現する

機能安全規格では、ソフトウェアユニットテストにおいて、コードに対して、要求ベースのテストが要求されているが、モデルベース開発の場合、以下の方法も許容されている。

・要求ベースのテストをモデルで実施し・モデル－コード一致性検証（B to B比較テスト）

※B to B比較テストの役割をテスト対象の振る舞いが、モデル－コードで一致することの保障と位置付け


17 /303.2. Auto Test Generation（ATG）の導入


C Code実装モデル

仕様モデル

要求定義最終評価／適合

単体検査コーディング

システム仕様設計システム検証

ソフトウェア検証

検証

検証

検証

検証void untitled_obs_step(void){int16_T rtb_Switch;

if (In2) {rtb_Switch = In1;

} else {rtb_Switch = In3;

}if (In4 < rtb_Switch) {

rtb_Switch = In4;}Out1 = rtb_Switch;}

TestVectorTestVectorTestVector

Model Sim.resultOut1

Model Simulation

Code Simulation



Code Sim.resultOut1

Code Sim.resultOut1

Code Sim.resultOut1

出力結果比較

単体検査B to B比較テスト（一致性検証）

ISO26262で推奨されているカバレッジ（MC/DC、DCなど）を満たすテストベクタの自動生成を実現

導入のポイント

可視性の実現可視性 : Observability

ATG技術を導入

Simulink® Design Verifier TM を活用※し、B to B比較テスト環境を構築

※Simulink Design Verifierの機能を利用し可視性を実現

Simulink® Design Verifier TM を活用※し、B to B比較テスト環境を構築

※Simulink Design Verifierの機能を利用し可視性を実現

Simulink Design Verifier：形式的手法を使用し、テストケースの生成、各種検証を行うSimulink® の検証ツール


18 /303.2.1. 可視性（Observability）

テストベクタ Out1

No. In1 In2 In3 In4

1 12 False 10 11 10

2 12 True 10 11 11

void untitled_obs_step(void){int16_T rtb_Switch;







Model Simulation

Code Simulation



Code Sim.resultOut1

Code Sim.resultOut1

Code Sim.resultOut1

出力結果比較









No. In1 In2 In3 In4

1 12 False 10 11 10

2 12 True 10 11 11








Model Simulation

Code Simulation



Code Sim.resultOut1

Code Sim.resultOut1

Code Sim.resultOut1

出力結果比較









No. In1 In2 In3 In4

1 12 False 10 11 10

2 12 True 10 11 11








Model Simulation

Code Simulation



Code Sim.resultOut1

Code Sim.resultOut1

Code Sim.resultOut1

出力結果比較






CコードのMC/DCを満たしているが、

B to B比較テストとして充分ですか？


22 /303.2.1. 可視性（Observability）テストベクタ Out1

No. In1 In2 In3 In4

1 12 False 10 11 10

2 12 True 10 11 11






TestVectorTest

VectorTestVector


Model Simulation

Code Simulation



Code Sim.resultOut1

Code Sim.resultOut1

Code Sim.resultOut1

出力結果比較

検査対象

出力結果比較対象

テスト対象の出力が、結果比較できる出力に反映（可視化）されなければならない=可視性のあるテストベクタが必要テスト対象の出力が、結果比較できる出力に反映（可視化）されなければならない=可視性のあるテストベクタが必要

このテストベクタでは検査対象の出力がOut1に反映されない

Switch 第1入力選択の検査


23 /303.2.2. 可視性の実現


可視性実現のために

Switch

第1入力を選択

A = True

A B

C

第1入力を出力

B < C設定条件

A=True && B<C

SimulinkDesignVerifier

条件設定


24 /30

条件設定部分

-160

1

0

159.9951

テスト生成

テスト生成

※スクリプト形式（Sig1==1 && Sig2<Sig3）での記述も可能

3.2.2. 可視性の実現

具体的には


Switch

○

<Simulink Design Verifier テスト生成レポート>


25 /303.2.2. 可視性の実現

要求されるテストベクタ数

MC/DC

Max ( m, n ) + 1

MC/DC + Observability

Sum ( m, n ) + 1

n 条件

m 条件

テストベクタ数の増加は許容できるレベルテストベクタ数の増加は許容できるレベル


26 /30

Component Subsystemカバレッジ率

MC/DC + Observabiliy

条件設定なし条件設定あり

A Total(19Subsystems)

47% 93%

B Subsystem1 - 94%

Subsystem2 - 100%

Subsystem3 - 97%

Subsystem4 - 26%

Subsystem5 - 100%

Subsystem6 - 74%

Subsystem7 - 100%

Subsystem8 - 82%

Subsystem9 - 95%

Total - 91%

モデル規模、記述内容により、カバレッジが低いケースがある

3.2.3. 適用結果

効果は出ているが、まだまだ問題があり改善が必要効果は出ているが、まだまだ問題があり改善が必要

※ここでのカバレッジ率＝

総MC/DC観点数

可視性を満たすMC/DC観点数

これの出来た率


27 /30


C Code実装モデル

仕様モデル

要求定義最終評価／適合

単体検査コーディング

システム仕様設計システム検証

ソフトウェア検証

検証

検証

検証

検証

①機能検査データ生成（機能ATG）

開発工程上流からシームレスに最適化されたプロセスを構築まずは、機能ATGの実現を検討中

開発工程上流からシームレスに最適化されたプロセスを構築まずは、機能ATGの実現を検討中

②要件検証形式的検証技術等を用いた、要件の妥当性・整合性の検証

3.3. 今後の取り組みの方向

機能検査データの自動生成

仕様・実装モデル

制御要件

モデル検査

要件モデル

安全要件安全要件検証要件

上流へ

機能検査データ


28 /30

機能実現シナリオと対応付けられるモデル記法の確立が重要機能実現シナリオと対応付けられるモデル記法の確立が重要

3.3.1. 機能ATG機能検査：機能が時間を追ってどう動くかを確認する

振舞いモデル

仕様・実装モデル

機能ATG実現のアイデア

機能が時間を追ってどう振舞うかをモデルとして記述し、振舞いモデルを対象にテスト生成を実施する

時間を追った動作を記述する為に、状態遷移等で記述

テスト

生成

テスト

生成

機能検査データ


29 /304. まとめ








4. まとめ


30 /304. まとめ

『ECUソフトウェア開発における検証・検査技術開発への取り組み』

• ECUソフトウェア開発では大規模・複雑化／各種ルール・規格への対応が必要

• デンソーでは、モデルベースを一つの解として自動化等取り組んでいる

• B to B比較テストの自動化に取り組んでいる

• 可視性（Observabilty）の実現が重要

• Simulink Design Verifier への条件設定により可視性を実現

• 高い効果が得られているが、改善ポイントも残っている

• 今後は、要件検証、機能検査自動化等上流工程へ拡張して行く

MathWorksさんの協力を得て、

より洗練された効果的な検証を実現していきたいと考えている

MathWorksさんの協力を得て、

より洗練された効果的な検証を実現していきたいと考えている


31 /30

ご清聴ありがとうございました

ecuソフトウェア開発における 検証・検査技術開発への取り …...150 2 0...

Documents

ecuソフトウェア開発における検証・検査技術開発への取り …...150 2 0...