PowerPoint

(1)

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

機能安全対応でサプライヤーに求められる

ソフト開発環境を考える

（株）デンソー

電子プラットフォーム開発部

室長鈴木万治

[email protected]

2011年12月6日 PTC Live TechForum TOKYO

社名

株式会社デンソー

設立

1949年 12月16日

本社

愛知県刈谷市

資本金

1,874 億円

〈単独〉

〈連結〉

売上高(同)

1兆9,457億円

3兆1,315億円

従業員数(同)

38,318人 123,165人

主要得意先

トヨタ自動車(株)殿を始め

国内外カーメーカー

電子プラットフォーム開発部

車載電子プラットフォームの企画・開発

（論理ｱｰｷﾃｸﾁｬ、ソフトPF、システム開発基盤）

ＩＴＳ事業部

走行安全事業部

ボデー機器事業部

電子事業部

デ

バ

イス事業部

その他

電子プラットフォーム開発部

ｺｰﾎﾟﾚｰﾄｾﾝﾀｰ

技術開発センター

生産推進センター

ﾊﾟﾜﾄﾚｲﾝ機器事業Gr.

電気機器事業Gr.

電子機器事業Gr.

情報安全事業Gr.

技術企画部

熱機器事業Gr.

電子ﾌﾟﾗｯﾄﾌｫｰﾑ開発部

技術管理部

基礎研究所

2011年3月31日現在

研究開発部

会社と組織の紹介

₁

/ 52

(2)

1．機能安全に関する当社の取り組み

2．システム、ハード、ソフトの扱い

3．機能安全は黒船なのか？

4．複雑さを克服するためのPMT

5．Integrity試行プロジェクト事例紹介

6．お客様への柔軟な対応を目指して

7 ．モデルベース開発への適用

8 ．まとめ

本日の発表内容

₂

_{/ 52}

• 位置づけ

–

「安全に設計された車」を証明するための業界標準

の考え方／フレームワークの一つ

• 業界内の認識

–

車両電子系の安全設計に関する基本標準

–

業界内では

「規格対応は必須」

の認識

–

欧州OEMは

「規格対応を調達要件」

として適用中

–

国内OEMも

「規格対応を宣言」

し適用着手

機能安全の概要（1/2）

₃

_{/ 52}

(3)

• 機能安全の定義

機能安全の概要（2/2）

₄

_{/ 52}

• 基本方針

–

市場のお客様の為の｢安全に設計された車｣を証明するた

めの業界標準の考え方／フレームワークとして活用する

• 進め方

–

当社が取組んでいる市場のお客様の為の安全設計を、

ISO 26262

に沿って再整理する

–

社内の

既存資産を有効に活用する

–

強化･追加案件を中心に

全社で効率的に対応する

(☞次項)

機能安全に対する当社の取り組み（1/2）

₅

_{/ 52}

(4)

規格と認証の両面の分析を進め、デンソー共通基盤を整備中

共通基盤

認証取得

ノウハウ

ISO26262

規格要求

顧客要求

要素技術

社内資産

組織体制

（監査体制、支援体制、・・・）

教育体系

（開発者向け、監査者向け、・・・）

支援文書

（しくみ、技術・技法、・・・）

マニュアル

技術文書

・事業部内規程

・その他非標準

機能安全のしくみ

（マネジメントシステム）

機能安全に特有事項の

解説書、適用ガイド等

ｶｰﾒｰｶ、半導体ﾍﾞﾝﾀﾞ、ﾂｰﾙﾍﾞﾝﾀﾞとの早期の連携が必要

基盤技術

（機能安全対応

_{標準IP、SPF、ﾂｰﾙ）}

・

）

お客様要求に対応して製品へ適用

機能安全に対する当社の取り組み（2/2）

₆

_{/ 52}

1．機能安全に関する当社の取り組み

2．システム、ハード、ソフトの扱い

3．機能安全は黒船なのか？

4．複雑さを克服するためのPMT

5．Integrity試行プロジェクト事例紹介

6．お客様への柔軟な対応を目指して

7．モデルベース開発への適用

8 ．まとめ

本日の発表内容

₇

_{/ 52}

(5)

3-5 item definition

3-6 Initiation of the safety

lifecycle

3-7 Hazard analysis and risk

assessment

3-8 Functional safety

concept

3.コンセプト

4-5 Initiation of product development at the system level

4-6 Specification of the technical safety requirements

4-7 System design

4.製品開発：システム

4-11 Release for prodcution

4-10 Functional safety assessment

4-9 Safety valication

4-8 Item integration and testing

7-5 Production

7-6 Operation, Service and

decommissioning

7.生産・市場対応

6-5 Initiation of product development at the software level

6-6 Specification of software safety requirements

6-7 Software architectural design 6-8 Software unit design and implementation

6.製品開発：ソフト

6-9 Software unit testing 6-10 Software integration and testing 6-11 Software verification 5-5 Initiation of product development at the

hardware level

5-6 Specification of hardware safety requirements

5-7 Hardware design 5-8 Hardware architectural metrics

5.製品開発：ハード

5-9 Evaluation of violation of the safety goal due to random HW failures

5-10 Hardware integration and testing

2.マネージメント

2-7 Safety managemnet after release for production

2-6 Safety management during item develoopment

2-5 Overall safety management

8-5 Interfaces within distributed developments

8-6 Overall management of safety requirements

8-7 Configuration management

8-8 Change management

8-9 Verification

8-10 Documentation

8-11 Qualification of software tools

8-12 Qualification of software components

8-13 Qualification of hardware components

8-14 Proven in use argument

8.支援

9.安全分析

9-5 Requirements decomposition with respect to ASIL tailoring

9-6 Criteria for coexistence of elements

9-7 Analysis of dependenet failures

9-8 Safety analysis

10.ガイドライン

1.用語

product develop el ification of softw ents arch

開発：ソフ

sy 4-6 requir

4-7 Sy

product develop ardware safety

製品開発

6-8 Sof 6-9 So 6 y goal due e 5-5 Init hardwar 5-6 Specific requirements 7 Hardware de

rdware architectural metrics ation of violation of the safety

HW failures integration and te

s

he

gn are unit design and implement are unit testing

integration and te fication 6-5 In softwa 6-6 Speci requireme 6-7 S men 7 Software a oftware

ISO26262

機能安全規格

出典：日本IBM社資料

8 / 52

PLM/ALM

ツールのカバー範囲

PLM系

ALM系

領域

PTC

PTC/MKS

IBM

参考

SERENA

参考

Microsoft

ハード（電

電子）

ハード（メ

メカ）

仕様

ソフトウェア

設計

ソフトウェア

実装

テスト

Integrity

DOORS

RTC

QM

PVCS

VSS

Windchill

PLM ： Product Lifecycle Management

(6)

PLM

ツールとALMツールの違い（一例）

構成・変更管理、トレーサビリティ管理…など「機能」としては同じ、

但し、必要な粒度が異なる。

■PLM

■ALM

仕様

①

_{② ③}

1

2

3 ﾓｰﾀ

ﾊﾟｰﾂA

ﾊﾟｰﾂB

Assy

XXXXXX-0000

Sub-Assy

XXXXXX-0010

この図面

この行

基本は図面単位でトレーサビリティを確保

ファイル単位では不十分。ファイル中の特定

部分までのトレーサビリティを確保

10 / 52

システム、ハード、ソフトの管理ツール

全てPLM

システムをPLM

システムをALM

構成

ソフト開発に必要と

なる詳細度

最終成果物管理

中間成果物管理

既存環境へのインパクト

備考

ソースコードの該当部

分までピンポイントの

トレースが困難。

ソフト開発の中間成果

物管理に工夫要。

既存のPLM系基幹シス

テムにインパクトあ

り。

PLM

システム

ハード

ソフト

PLM

ALM

システム

ハード

ソフト

ALM

PLM

ALM

システム

ハード

ソフト

11 / 52

(7)

1．機能安全に関する当社の取り組み

2．システム、ハード、ソフトの扱い

3．機能安全は黒船なのか？

4．複雑さを克服するためのPMT

5．Integrity試行プロジェクト事例紹介

6．お客様への柔軟な対応を目指して

7．モデルベース開発への適用

8．まとめ

本日の発表内容

₁₃

_{/ 52}

3-5 item definition

3-6 Initiation of the safety

lifecycle

3-7 Hazard analysis and risk

assessment

3-8 Functional safety

concept

3.コンセプト

4-5 Initiation of product development at the system level

4-6 Specification of the technical safety requirements

4-7 System design

4.製品開発：システム

4-11 Release for prodcution

4-10 Functional safety assessment

4-9 Safety valication

4-8 Item integration and testing

7-5 Production

7-6 Operation, Service and

decommissioning

7.生産・市場対応

6-5 Initiation of product development at the software level

6-6 Specification of software safety requirements

6-7 Software architectural design 6-8 Software unit design and implementation

6.製品開発：ソフト

6-9 Software unit testing 6-10 Software integration and testing 6-11 Software verification 5-5 Initiation of product development at the

hardware level

5-6 Specification of hardware safety requirements

5-7 Hardware design 5-8 Hardware architectural metrics

5.製品開発：ハード

5-9 Evaluation of violation of the safety goal due to random HW failures

5-10 Hardware integration and testing

2.マネージメント

2-7 Safety managemnet after release for production

2-6 Safety management during item develoopment

2-5 Overall safety management

8-5 Interfaces within distributed developments

8-6 Overall management of safety requirements

8-7 Configuration management

8-8 Change management

8-9 Verification

8-10 Documentation

8-11 Qualification of software tools

8-12 Qualification of software components

8-13 Qualification of hardware components

8-14 Proven in use argument

8.支援

9.安全分析

9-5 Requirements decomposition with respect to ASIL tailoring

9-6 Criteria for coexistence of elements

9-7 Analysis of dependenet failures

9-8 Safety analysis

10.ガイドライン

1.用語

y goal due product develop ardware safety

製品開発

e 5-5 Init hardwar 5-6 Specific requirements 7 Hardware de

rdware archite metrics ation of violation of the safety

HW failures integration and te

s 4-5 Initiation of product development at the system level

4-6 Specification of the technical safety uirements

System design

4.製品開発：システム

4-11 Release for prodcution

4-10 Functional safety assessment

4-9 Safety valication

4-8 Item integration and testing

Initiation of pr are level ecific

6.製品開発

lopment at the ftware safety chitectural design design and

ソフト

ng product develop el ification of softw ents arch

開発：ソフ

sy 4-6 requir

4-7 Sy

ntation Software

6-10 Software integration and testing 6-11 Software verification 6-7 6-8 Sof 6-9 So 6 he gn are unit design and implement are unit testing

integration and te fication 6-5 In softwa 6-6 Speci requireme 6-7 S men 7 Software a oftware

Automotive-SPICEの

プロセス範囲

ISO26262

機能安全規格

出典：日本IBM社資料

14 / 52

(8)

機能安全対応の参照プロセスとしてAutomotive SPICEを適用することは適切。

Automotive SPICEは「要件管理」「構成・変更管理」「トレーサビリティ管理」

を全て含んでいる。

システム・ソフト開発における機能安全対応

出典：KUGLER MAAB CIE社資料

15 / 52

では、あらためて何がそれほど難しいのか？

要求されているもの

「要件管理」「構成・変更管理」「トレーサビリティ管理」

これらは、どれも「あたりまえ」という感じもする…

難しいのは、

1）複雑なものを対象に

状態爆発：

複数の要素を組み合わせて考える場合に、要素数の増加により爆発

的に組合せの数が増加する

2）きっちりとやること

パレートの法則：

80％の完成度に到達するまでは20％の時間でよいが、残りの20％を

完成させるためには80％の時間を要する

16 / 52

(9)

1．機能安全に関する当社の取り組み

2．システム、ハード、ソフトの扱い

3．機能安全は黒船なのか？

4．複雑さを克服するためのPMT

5．Integrity試行プロジェクト事例紹介

6．お客様への柔軟な対応を目指して

7 ．モデルベース開発への適用

8 ．まとめ

本日の発表内容

₁₇

_{/ 52}

manual

C-code

development

model based

development

architectural

development

models for

software architecture,

functional network,

hardware topology

implementation model

functional behavior

model

車載ソフトウェア開発環境の変化

出典：dSPACE社資料

18 / 52

(10)

コーディング能力

車載ソフトウェア開発に求められる能力

モデル活用能力

開発ツール活用能力

開発プロセス（環境）構築能力

・複雑さを管理する能力

・OEM/サプライヤをまたぐ開発プロセスの構築

（C言語ベース）

（モデルによる記述）

（ツール活用による効率化）

19 / 52

大規模構造物に必要となる要素

Process

Methods

Tools

24 / 52

(11)

大規模電子システム開発のためのPMT

■プロセス（Process）

・Automotive SPICE

®

■手法（Methods）

・V&V（Validation and Veriﬁcation）

■ツール（Tools）

・管理ツール

（要件管理、構成・変更管理、トレーサビリティ管理）

25 / 52

1．機能安全に関する当社の取り組み

2．システム、ハード、ソフトの扱い

3．機能安全は黒船なのか？

4．複雑さを克服するためのPMT

5．Integrity試行プロジェクト事例紹介

6．お客様への柔軟な対応を目指して

7．モデルベース開発への適用

8 ．まとめ

本日の発表内容

₂₈

_{/ 52}

(12)

当社におけるソフト管理ツール開発経緯

2003年

Eclipse

の技術調査開始

2008年

Eclipse

＋OSSでのソフト管理ツール開発開始

並行して、市販ツールの調査開始（機能安全対応）

2009年

Eclipse

＋OSS管理ツール基本部分完成

−構成・変更管理をサポート

−CDT、SubVersion、Mylyn、Trac、Bugzilla、JWT、PDE、Pleiades

Eclipse＋OSS環境では

トレーサビリティ確保が困難

なため機能安全

およびAutomotive SPICE対応プロジェクト向けに市販ツールを実践

評価、ベンチマーク開始。

2011年

MKS Integrity

を全社導入

ASILのレベルに関係なく、Automotive SPICEと同様の要件管理、

構成・変更管理、トレーサビリティ管理が要求されるため、ほぼ全て

の製品群が対象になると判断。

29 / 52

トレース

影響分析

ノード同士でトレースを確立することが可能

㱺ファイル間の追跡効率がUP

ノードを変更した場合、下位にあるノードに要検討フラグ表示

㱺影響分析のモレヌケを防ぐことが可能

仕様書

要件1

要件2

テスト成績書

テストケース1

テストケース2

トレース

要検討フラグ

変更発生

機能安全規格要求

■要件間のトレーサビリティ

（上位要求㱻下位要求、要求㱻テスト）

１２６の成果物

要件間の

トレーサビリティ

要件間のトレーサビリティや影響解析を

手作業で確認することは困難・・・

■影響しあう要件の解析

Integrity

ドラッグ＆ドロップ

でトレースを構築

影響解析を支援

出典：日本IBM社資料

Integrity

によるトレース管理と影響分析機能の実現

₃₀

_{/ 52}

(13)

マネージャ

_開発者

ＭＫＳ

依頼

受け取り

完了・デー

タ格納

ワーク

スペース

Integrity導入

_{構成管理・変更管理}

機能安全規格要求

作業

安全活動に対する説明責任を要求

・成果物の構成管理

・成果物の変更管理

安全管理者の変更承認が必要

変更理由と変更対象成果物の関連保持

・・・

１２６の成果物を

すべての構成管理・変更管理

変更管理支援

成果物の構成管理

進の可視化

Excelでの

手作業の

変更管理

ネットワーク

上での管理

現状の管理方法では不十分かつ工数大

構成管理：作業成果物をすべて格納

変更管理：変更作業をツールが自動記録

㱺作業のタスクもれのチェックが簡単に可能

IBM資料より引用

Integrity

による構成管理・変更管理の実現

₃₁

_{/ 52}

要件数

２ 機能数

５ 検証数

４ 要件数

８５ 機能数

１２ 検証数

１８５８

要件数

８４ 機能数・・・

検証数・・・

要件数

４８ 機能数

５８ 検証数

２８３ 要件

機能図

FMEA

テスト

コンセプト

システム

ハード

ソフト

要件追加

変更箇所の

影響分析

規格要求：成果物（要件㱻機能㱻検証）に対するトレース管理

要件機能図 FMEA テスト要件機能図 FMEA テスト要件機能図 FMEA テスト

試行事例の紹介

要件数

と成果物の種類分トレース管理が発生

→プロジェクト規模中・大は導入しないと膨大な管理工数が発生

32 / 52

(14)

Integrity導入事例

要件変更によって

影響分析実施箇所にマークが表示

複雑なトレーサビリティ関係を

Integrity上に実装

事例紹介：トレーサビリティ管理

₃₃

_{/ 52}

現状とほぼ同じ作業で変更と成果物のトレース管理可能

コードの変更履歴を

グラフィカルに表示

開発者

Integrity

依頼

受け取り

完了・データ

格納

ワーク

スペース

作業

マネージャ

タスクを追加し、担当者に割り

振り

作業の進確認

タスクを受け取り作業を実施

事例紹介：構成管理・変更管理

₃₄

_{/ 52}

(15)

ツールの認証とSafety Manual

₃₅

_{/ 52}

成果物

共有

Firewall

サーバー

同期

国内拠点・海外OS

本社

原本は本社

で一元管理

自動で同期

必要最低限

のみ開示

案件は項目毎

に管理

切り出しやすい

仕事のやり方

品番・ﾊﾞｰｼﾞｮﾝ

違いを撲滅

FSA

を活用した分散開発環境の構築

₃₆

_{/ 52}

(16)

1．機能安全に関する当社の取り組み

2．システム、ハード、ソフトの扱い

3．機能安全は黒船なのか？

4．複雑さを克服するためのPMT

5．Integrity試行プロジェクト事例紹介

6．お客様への柔軟な対応を目指して

7 ．モデルベース開発への適用

8 ．まとめ

本日の発表内容

₃₇

_{/ 52}

企業間の文書インタフェースに関する標準化活動

ReqIF（OMG）

RIF（HIS）

http://www.omg.org/spec/ReqIF/

http://www.automotive-his.de/rif/doku.php?id=welcomeeng

38 / 52

(17)

企業間での文書インタフェース

出典：http://www.omg.org/spec/ReqIF/1.0.1/PDF

ReqIFの想定シナリオ例

39 / 52

お客様に対する柔軟な対応を目指して

要件データの標準規格

RIF/Req IF

コンバータ

拡張の口

_MIIP

DOORS

Team Center

独自

Word

Integrity

他ツールとの接続部

Gateway

40 / 52

(18)

JasPar

機能安全WG（ツールチェーン）

■課題

1．RIF/ReqIFが並立状態、かつ、いずれも完動していないのが現状

2．Ofﬁce2003など国内固有の環境に未対応

3．日本語に対する処理、細かな図表の処理に課題を残す

■実施項目

1．国内ツール環境と欧州の規格調査（RIF、ReqIF）・・・デンソー、委託先

2．相互変換規格の仕様策定・・・デンソー、委託先

3．相互変換ツールのプロトタイプ作成・・・委託先

4．プロトタイプの評価・・・デンソー

Word2003

Word2007

DOORS

XXXXX

JasPar

文書交換標準

規格

Integrity

TeamCenter

Rational Team Concert

YYYYY

自動変換ツール

今回のテスト環境

その他

45 / 52

欧州動向と要件管理ツールの今後

PLM系

ALM系

領域

PTC

PTC/MKS

IBM

参考

SERENA

参考

Microsoft

ハード（電

電子）

ハード（メ

メカ）

仕様

ソフトウェア

設計

ソフトウェア

実装

テスト

Integrity

DOORS

RTC

QM

PVCS

VSS

Windchill

46 / 52

y

DOOR

IBM

参考

SERENA

参考

Microsoft

RSRS

単一レポジトリによる一気通

貫効果、コスト低減などのお

客様メリットを明確にしつつ

今後議論していく

ity

ALMとPLMの

最適融合

(19)

1．機能安全に関する当社の取り組み

2．システム、ハード、ソフトの扱い

3．機能安全は黒船なのか？

4．複雑さを克服するためのPMT

5．Integrity試行プロジェクト事例紹介

6．お客様への柔軟な対応を目指して

7 ．モデルベース開発への適用

8 ．まとめ

本日の発表内容

₄₇

_{/ 52}

モデルベース開発への適用：Matlab Integration（1/2）

http://www.mks.com/images/ModelingScreenshot.png

Matlab Integration機能によりSimulinkモデルを参照することが可能

48 / 52

(20)

モデルベース開発への適用：Matlab Integration（2/2）

Simulinkモデルを取り込み

トレーサビリティを確保

Tests

Model

Code

Requirements

49 / 52

モデルベース開発への適用（ツールチェーンの融合）

Matlab/Simulink

AutomationDesk

HILS

TargetLink

50 / 52

(21)

1．機能安全に関する当社の取り組み

2．システム、ハード、ソフトの扱い

3．機能安全は黒船なのか？

4．複雑さを克服するためのPMT

5．Integrity試行プロジェクト事例紹介

6．お客様への柔軟な対応を目指して

7 ．モデルベース開発への適用

8 ．まとめ

本日の発表内容

₅₁

_{/ 52}

まとめ

• 当社では、機能安全を、市場のお客様の為の｢安全に設計された車｣を証明する

ための業界標準の考え方／フレームワークとして活用する

• 機能安全に適切に対応するためのPMTを検討した。

Process：Automotive SPICE Method：V&V Tool：ソフト管理ツール

• ソフト管理ツールとして、PTC社のIntegrityを選定し、全社導入準備中。

• 社内の先行評価では大きな課題なし。従来のプロセスからの移行に工夫が

必要。

• お客様との接点となる企業間の文書インタフェースに関して、標準規格に加え

て、より柔軟に対応できる構えを構築中。

• レガシー開発プロセスに続き、モデルベース開発にも適用できるよう、PTC社

と協力して機能拡張を継続する。

52 / 52

(22)

PowerPoint

機能安全対応でサプライヤーに求められる

ソフト開発環境を考える

（株）デンソー

電子プラットフォーム開発部

室長 鈴木万治

[email protected]

2011年12月6日 PTC Live TechForum TOKYO

社 名

株式会社デンソー

設 立

1949年 12月16日

本 社

愛知県刈谷市

資本金

1,874 億円

〈単独 〉

〈連結 〉

売上高(同)

1兆9,457億円

3兆1,315億円

従業員数(同)

38,318人 123,165人

主要得意先

トヨタ自動車(株)殿を始め

国内外カーメーカー

電子プラットフォーム開発部

車載電子プラットフォームの企画・開発

（論理ｱｰｷﾃｸﾁｬ、ソフトPF、システム開発基盤）

ＩＴＳ事業部

走行安全事業部

ボデー機器事業部

電子事業部

デ

バ

イス事業部

その他

関連事業部

電子プラットフォーム開発部

ｺｰﾎﾟﾚｰﾄｾﾝﾀｰ

技術開発センター

生産推進センター

ﾊﾟﾜﾄﾚｲﾝ機器事業Gr.

電気機器事業Gr.

電子機器事業Gr.

情報安全事業Gr.

技術企画部

熱機器事業Gr.

電子ﾌﾟﾗｯﾄﾌｫｰﾑ開発部

技術管理部

基礎研究所

2011年3月31日現在

研究開発部

会社と組織の紹介

1

/ 52

1．機能安全に関する当社の取り組み

2．システム、ハード、ソフトの扱い

3．機能安全は黒船なのか？

4．複雑さを克服するためのPMT

5．Integrity試行プロジェクト事例紹介

6．お客様への柔軟な対応を目指して

7

．モデルベース開発への適用

8

．まとめ

本日の発表内容

2

/ 52

•

位置づけ

–

「安全に設計された車」を証明するための業界標準

の考え方／フレームワークの一つ

•

業界内の認識

–

車両電子系の安全設計に関する基本標準

–

業界内では

室長鈴木万治

社名

設立

本社

〈単独〉

〈連結〉

₁

₂

_{/ 52}

₃

_{/ 52}

₄

_{/ 52}

₅

_{/ 52}

・その他非標準