機能安全対応でサプライヤーに求められるソフト開発環境を...

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日現在

研究開発部

会社と組織の紹介 1/ 52


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

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

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

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

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

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

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

8．まとめ

本日の発表内容 2/ 52


• 位置づけ– 「安全に設計された車」を証明するための業界標準の考え方／フレームワークの一つ

• 業界内の認識– 車両電子系の安全設計に関する基本標準

– 業界内では「規格対応は必須」の認識

– 欧州OEMは「規格対応を調達要件」として適用中

– 国内OEMも「規格対応を宣言」し適用着手

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


• 機能安全の定義

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


• 基本方針– 市場のお客様の為の｢安全に設計された車｣を証明するための業界標準の考え方／フレームワークとして活用する

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

ISO 26262に沿って再整理する– 社内の既存資産を有効に活用する– 強化･追加案件を中心に全社で効率的に対応する

(☞次項)

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


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

共通基盤

関連規格

認証取得ノウハウ

ISO26262規格要求

顧客要求要素技術

社内資産

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

教育体系（開発者向け、監査者向け、・・・）

支援文書（しくみ、技術・技法、・・・）マニュアル

技術文書・事業部内規程・その他非標準

機能安全のしくみ

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

機能安全に特有事項の解説書、適用ガイド等

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

基盤技術（機能安全対応標準IP、SPF、ﾂｰﾙ）

・））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））））

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

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









8．まとめ

本日の発表内容7/ 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 production2-6 Safety management during item develoopment2-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 developel

ification of softwents

arch

開発：ソフ

sy

4-6requir

4-7 Sy

product develop

ardware safety

製品開発

6-8 Sof

6-9 So

6

y goal due

e 5-5 Inithardwar

5-6 Specificrequirements

7 Hardware de

rdware architectural metrics

ation of violation of the safetyHW failures

integration and te

s

he

gn

are unit design and implement

are unit testing

integration and te

fication

6-5 Insoftwa

6-6 Specirequireme

6-7 S

men

7 Software a

oftware

ISO26262 機能安全規格

出典：日本IBM社資料

8/ 52


PLM/ALMツールのカバー範囲

PLM系 ALM系

　領域 PTC PTC/MKS IBM参考

SERENA

参考Microsoft

ハード（電電子）

ハード（メメカ）

仕様

ソフトウェア設計

ソフトウェア実装

テスト

Inte

grity D

OO

RSRT

CQ

M

PVCS

VSS

Win

dchi

ll

PLM ： Product Lifecycle ManagementALM ： Application Lifecycle Management 9/ 52


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

構成・変更管理、トレーサビリティ管理…など「機能」としては同じ、但し、必要な粒度が異なる。

■PLM ■ALM

仕様

① ② ③

123

ﾓｰﾀﾊﾟｰﾂAﾊﾟｰﾂB

AssyXXXXXX-0000

Sub-AssyXXXXXX-0010

この図面この行

基本は図面単位でトレーサビリティを確保ファイル単位では不十分。ファイル中の特定部分までのトレーサビリティを確保

10/ 52


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

全てPLM システムをPLM システムをALM

構成

ソフト開発に必要となる詳細度

最終成果物管理

中間成果物管理

既存環境へのインパクト

備考ソースコードの該当部分までピンポイントのトレースが困難。

ソフト開発の中間成果物管理に工夫要。

既存のPLM系基幹システムにインパクトあり。

PLM

PLM PLM

システム

ハードソフト

PLM

PLM ALM

システム

ハードソフト

ALM

PLM ALM

システム

ハードソフト

11/ 52









8．まとめ



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





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



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 production2-6 Safety management during item develoopment2-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 Specificrequirements

7 Hardware de

rdware archite metrics

ation of violation of the safetyHW failures

integration and te

s

4-5 Initiation of product development at thesystem level

4-6 Specification of the technical safety uirements

System design





Initiation of prare level

ecific

6.製品開発lopment at the

ftware safety

chitectural design

design and

ソフト

ng

product developel

ification of softwents

arch

開発：ソフ

sy

4-6requir

4-7 Sy

ntation

Software



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 Insoftwa

6-6 Specirequireme

6-7 S

men

7 Software a

oftware

Automotive-SPICEのプロセス範囲

ISO26262 機能安全規格


14/ 52


機能安全対応の参照プロセスとしてAutomotive SPICEを適用することは適切。Automotive SPICEは「要件管理」「構成・変更管理」「トレーサビリティ管理」を全て含んでいる。

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

出典：KUGLER MAAB CIE社資料

15/ 52


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

要求されているもの

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

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

難しいのは、

　1）複雑なものを対象に

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

　2）きっちりとやること

　　　パレートの法則：　　　　80％の完成度に到達するまでは20％の時間でよいが、残りの20％を　　　　完成させるためには80％の時間を要する

16/ 52









8．まとめ



manual C-code development

model based development

architectural development

models forsoftware architecture,

functional network, hardware topology

implementation model

functional behavior model

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

出典：dSPACE社資料

18/ 52


コーディング能力

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

モデル活用能力

開発ツール活用能力

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

　・複雑さを管理する能力

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

（C言語ベース）

（モデルによる記述）

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

19/ 52


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

Process

Methods Tools

24/ 52


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

■プロセス（Process）

　・Automotive SPICE®

■手法（Methods）

　・V&V（Validation and Verification）

■ツール（Tools）

　・管理ツール

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

25/ 52









8．まとめ



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

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

ドラッグ＆ドロップでトレースを構築

影響解析を支援


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


マネージャ　開発者

ＭＫＳ依頼

受け取り

完了・データ格納

ワーク

スペース

Integrity導入構成管理・変更管理機能安全規格要求

作業

安全活動に対する説明責任を要求・成果物の構成管理・成果物の変更管理　　安全管理者の変更承認が必要　　変更理由と変更対象成果物の関連保持　・・・

１２６の成果物をすべての構成管理・変更管理

変更管理支援

成果物の構成管理

進捗の可視化Excelでの　　手作業の変更管理

ネットワーク上での管理

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

構成管理：　作業成果物をすべて格納変更管理：　変更作業をツールが自動記録作業のタスクもれのチェックが簡単に可能

IBM資料より引用

Integrityによる構成管理・変更管理の実現 31/ 52


要件数　２機能数　５検証数　４

要件数　８５機能数　１２検証数　１８５８

要件数　８４機能数　・・・検証数　・・・

要件数　４８機能数　５８検証数　２８３

要件

機能図

FMEA

テスト

コンセプト

システム

ハードソフト

要件追加

変更箇所の影響分析

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

要件

機能図

FMEA

テスト

要件

機能図

FMEA

テスト

要件

機能図

FMEA

テスト

試行事例の紹介

要件数と成果物の種類分トレース管理が発生→プロジェクト規模中・大は導入しないと膨大な管理工数が発生

32/ 52


Integrity導入事例

要件変更によって影響分析実施箇所にマークが表示

複雑なトレーサビリティ関係をIntegrity上に実装

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


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

コードの変更履歴を　グラフィカルに表示

開発者

Integrity依頼

受け取り

完了・データ格納

ワークスペース

作業

マネージャ　

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

作業の進捗確認

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

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


ツールの認証とSafety Manual 35/ 52


成果物共有

Firewall

サーバー同期

国内拠点・海外OS本社

原本は本社で一元管理

自動で同期

必要最低限のみ開示

最新のファイル

案件は項目毎に管理

切り出しやすい仕事のやり方

品番・ﾊﾞｰｼﾞｮﾝ違いを撲滅

FSAを活用した分散開発環境の構築 36/ 52









8．まとめ



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

ReqIF（OMG） RIF（HIS）

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

38/ 52


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

出典：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


JasPar機能安全WG（ツールチェーン）■課題　1．RIF/ReqIFが並立状態、かつ、いずれも完動していないのが現状　2．Office2003など国内固有の環境に未対応　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

ハード（電電子）

ハード（メメカ）

仕様

ソフトウェア設計

ソフトウェア実装

テスト

Inte

grity D

OO

RSRT

CQ

M

PVCS

VSS

Win

dchi

ll

46/ 52

y DO

OR

IBM参考

SERENA

参考Microsoft

RSRS

単一レポジトリによる一気通貫効果、コスト低減などのお客様メリットを明確にしつつ今後議論していく

ity

ALMとPLMの最適融合









8．まとめ



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

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

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

48/ 52


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

Simulinkモデルを取り込みトレーサビリティを確保

Tests

Model

Code

Requirements

49/ 52


49

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

Matlab/Simulink

AutomationDesk

HILS

TargetLink

50/ 52









8．まとめ



まとめ

• 当社では、機能安全を、市場のお客様の為の｢安全に設計された車｣を証明するための業界標準の考え方／フレームワークとして活用する

• 機能安全に適切に対応するためのPMTを検討した。　　Process：Automotive SPICE　Method：V&V　Tool：ソフト管理ツール

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

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

• お客様との接点となる企業間の文書インタフェースに関して、標準規格に加えて、より柔軟に対応できる構えを構築中。

• レガシー開発プロセスに続き、モデルベース開発にも適用できるよう、PTC社と協力して機能拡張を継続する。

52/ 52


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

機能安全対応でサプライヤーに求められる ソフト開発環境を...

Documents

機能安全対応でサプライヤーに求められるソフト開発環境を...