消費者機械安全保証標準化活動 IPA コンシューマデバイス安全標準化 WG 委員 SICE 国際標準化委員トヨタ自動車株式会社エンシン技術開発部主幹石崎直哉 2013/11/20 1

(1)

消費者機械安全保証

標準化活動

IPA コンシューマデバイス安全標準化WG 委員

SICE 国際標準化委員

トヨタ自動車株式会社ｴﾝｼﾞﾝ技術開発部主幹

石崎直哉

2013/11/20

(2)

2

本日の内容

背景

標準化に対する4つの提案



OMGでの国際標準化活動

まとめ

(3)

本日の内容

背景

標準化に対する4つの提案



OMGでの国際標準化活動

(4)

4 ・現状把握の遅れ ⇒ 意思決定の遅れ

・問題は北米から一気に全世界へ広がった

・想定外の使われ方も「想定外」では済まされない

（フロアマット）

・システム安全への厳しい要求、説明の難しさ

（ＢＯＳ、電子スロットル）

・お客様のトヨタに対する信頼失墜

・クルマに求められる安全・品質の変化

・電子制御システムの安全も大きな問題に

2010/2月米国公聴会での証言

発端：

2010年の品質・安全問題

＜問題を通して痛感したこと＞

安全性認識の高まりと制御開発管理上の課題

ISO26262規格に準拠した製品開発を実施することに決定

(5)

機能安全規格ＩＳＯ２６２６２とは

【例】鉄道の線路横断に対する対策 ①鉄道と道路が平面交差 ⇒危険な状態（電車との衝突） ②警報機や遮断機を設定 ⇒危険な状態（電車との衝突）が許容できる程度以下 ⇒機能安全の状態 ③立体交差を設定 ⇒危険な状態（電車との衝突）を回避 ⇒本質安全の状態

◆ 2011年11月に規格制定

◆対象システム

--- 安全に関連する

電気

/電子システム（※純粋なメカは対象外）

◇機能安全

【定義】システムのリスクを

許容できる程度以下に対策

して安全を確保する

【対義語】本質安全 ⇒対策によってリスクを

なくして

安全を確保する

◇

ISO26262規格

◇

ISO26262と従来トヨタ安全設計/品質との関係

ISO26262はあくまでミニマム/必要最低限の安全設計要件しか規定していない．

例: エンストはISO26262の対象外

⇒ISO26262とは関係なくエンストしないよう従来トヨタ品質を満たすように作りこむ必要あり．

第三者への安全性の説明性のために設計エビデンスを残す

安全性

ISO26262要件

従来トヨタ設計

ISO26262及びﾄﾖﾀ安全基準を全て満たす

ための仕組みが必要。

(6)

6 自動車制御関連の安全に関する

課題まとめ



ISO26262規格で説明できる安全ﾚﾍﾞﾙとトヨタとして証明しな

ければならない安全ﾚﾍﾞﾙに相違がある。

 “想定外“の使われ方も想定外では済まされない。

 もはや、自動車はネットワーク端末である。自動車と社会ｲﾝ

ﾌﾗ及びそれらの連携による社会ｼｽﾃﾑの安全性と信頼性を

保証しなければならない。

 変化し続ける社会ｲﾝﾌﾗ、年々厳しくなり続ける排気規制・燃

費要求へ対応し続けなければならない。

自動車単体だけでなく、消費者機械及び変化し続ける社会ｲﾝﾌﾗ・規

制・機能要求に対応可能な安全性議論の方法論が必要である。

(7)

本日の内容

背景

標準化に対する4つの提案



OMGでの国際標準化活動

(8)

8

標準化に関する提案：4つの概念

 新しい概念

 消費者機械 : 一般消費者が使用する安全性に関わる電子機器

 Dependability : Safety・Reliability・Maintainability etcなどを統合し

た“高信頼”性

 Argumentation

 Assurance Case ：議論の構造を記録する方法論

 新しい開発ﾌﾟﾛｾｽ概念

 Top-Down的Waterfall 開発 ⇒ 素早い繰り返し（Agile的）

 モデルベース保証手法

 上記概念を効率的に開発・管理するﾂｰﾙ・仕組み

(9)

消費者機械(Consumer Devices)

とは

Factory machineries

Consumer devices

The number of the

production

A few to Many

A huge number

Users

Experts

General users

Cost

High

Sufficiently low

Maintenance

Real field

(strongly managed)

Users, Service stations

(weekly managed)

Environment

Factory environment

(almost stable)

Factory environment

User environment

(Open, dynamic and diverse)

(10)

10 Dependabilityとは

Safety, Reliabilityなどの複合的“高信頼性”を示す。

従来は個別の保証を検証してきたが、ｼｽﾃﾑが複雑になり

個別の保証では不十分となってきた。

1. Security

2. Availability

3. Reliability

4. Maintainability

5. Safety

6. Functional

7. Integrity

8. Trustfulness

9. Justifiable

10. Robust

11. Resilient

12. No vulnerability

13. Accessibility

14. Performability

15. Comfort

*Obtained from Wikipedia

(11)

Argumentationとは

• Assurance Case

– ｼｽﾃﾑの保証を、ｴﾋﾞﾃﾞﾝｽを基に議論するための方法

• Assurance Case ⇒ 拡張 : Dependability Case の導入

ゴール

ｴﾋﾞﾃﾞﾝｽ

例：ＦＴＡ結果

例：ｼｽﾃﾑは安全である

戦略：ｼｽﾃﾑの

FTAを議論

出典：

D-Case入門

戦略：ｼｽﾃﾑの

FMEAを議論

例：

FMEA結果

(12)

12

Dependability Caseのメリット

 問題全体のスコープの明確化

 議論に用いる資料の明示化

 個々のFTA/FMEA等のリスク分析結果の統合

 既存の安全や技術規格との適合結果の統合

 個々のゴールに対する問題設定と合意条件の議論の明示化



Evidenceによってどのように“OK”と判断したか主張

（

Argument）の明確化

ゴールｴﾋﾞﾃﾞﾝｽｴﾋﾞﾃﾞﾝｽｴﾋﾞﾃﾞﾝｽ例：ＦＴＡ結果例：ｼｽﾃﾑは安全である戦略：ｼｽﾃﾑのFTAを議論戦略：ｼｽﾃﾑのFMEAを議論例：FMEA結果

(13)

消費者機械保証の難しさ

Controller Software

Drivers

Physical Systems

Operation Environment

(e.g. Passengers, Pedestrians, Atmosphere, Road)

• 制御ｼｽﾃﾑと自然界（物理ｼｽﾃﾑ）, 操作環境との相互作用

• 自然界・操作環境は全てを予想することは困難

(14)

14

消費者機械開発の基本ｱﾌﾟﾛｰﾁ

Experiences

Assumptions

Assumption

Errors

New Assumptions

Outside of Assumptions

_Trial

 過去の経験から開発開始

 ある想定を仮定し、試行錯誤を繰り返しながら適切な機能要件を定義

 素早い繰り返しによる開発 ⇒ 自動車業界で実績

(15)

素早い繰り返しによる開発ﾌﾟﾛｾｽ（案）

Control

Design

Objective

Requirements

Control

Model

Simplification

Optimization

Generation

Code

Calibration

Verification & Validation

Control Design

Process

Implementation

Process

Auto

Code

Ge

n.

Dependability

Goal Definition

Dependability

Analysis

Certification

Doc. Gen.

Argument

Construction

(16)

16

たとえば、トヨタでは

…

実車評価による走行距離

– 日当たり評価時間 : 4Hr/day

– 平均車速 : 30km/h

– 年間評価日数 : 200 days/year

– ﾌﾟﾛｼﾞｪｸﾄ当り試作車 : 100 prototype vehicles /

project

– 開発期間 : 3 ~ 5 years / project to finish

Total Km = 4 x 30 x 200 x 100 x 3

(17)

モデルベース保証とは

（Model Based System Assurance)

• Dependability Caseによる保証に対する議

論の明確化は可能

⇔ ｺｽﾄ・時間の制約の下で実現可能か？

• Model Based System Assurance

– Compositional Argumentationの実装

– Proven In Use Argumentの明確化

(18)

18 自動車制御開発への

D-Case 適用

想定

: 新ﾌﾟﾘｳｽ開発におけるｴﾝｽﾄD-Caseを定義する

•旧ﾌﾟﾘｳｽをﾍﾞｰｽとして新ﾌﾟﾘｳｽを開発する

•旧ﾌﾟﾘｳｽｴﾝｼﾞﾝ ⇒ 旧ﾌﾟﾘｳｽｴﾝｼﾞﾝ + VVT

VVT 機能追加

新ﾌﾟﾘｳｽ開発

トヨタにおけるｴﾝｽﾄ評価・開発のﾌﾟﾛｾｽを

D-Caseを適用

(19)

(20)

20 ｴﾝｼﾞﾝｽﾄｰﾙ

D-Case 記述概略

G : ｴﾝｼﾞﾝｽﾄｰﾙが発生しないこと S : 過去ｴﾝｼﾞﾝでｴﾝｽﾄしないことを確認する S :新ｴﾝｼﾞﾝに対する DRBFMを実施する S : 総合車両評価を実施する SG : 旧ｴﾝｼﾞﾝ開発時にｴﾝｽﾄ発生しないことが検証されていること SG : 市場でｴﾝｽﾄ実績がないこと SG : 要求仕様開発できていること SG : 制御仕様開発できていること SG : 実装できていること SG : 検証できていること SG : 適合できていること C : 新ﾌﾟﾘｳｽ・ｴﾝｼﾞﾝ諸元 1．ｴﾝｼﾞﾝCADﾃﾞｰﾀ 2．部品表・構造図 3．変更点・変化点一覧 4．ｴﾝｼﾞﾝ機能・要求仕様 5．相互影響マトリクス SG : 実ﾕｰｽｹｰｽに従った車両評価できていること C : Engine Operating Condition 1．ｴﾝｼﾞﾝ水温 2．吸入空気温 3．大気圧 4．電気負荷 5．ﾊﾟﾜｽﾃ状況 6．ﾌﾞﾚｰｷﾝｸﾞ状況 7．ｴｱｺﾝ運転状況 8. ｴﾝｼﾞﾝ慣らし状況 C : DRBFM 1．DRBFM手順書 2．DRBFM妥当性 3．DRBFM結果 SS : 要求仕様書に対する変化点の影響ﾁｪｯｸを実施 SS : 制御仕様書に対する変化点の影響ﾁｪｯｸを実施 SS : ｴﾝｽﾄを回避する制御開発 SS : ｼﾐｭﾚｰｼｮﾝでｴﾝｽﾄなきことを確認 SS : 適合定数に対する変化点の影響ﾁｪｯｸ SS : 過去の開発結果を検証し、ｴﾝｽﾄなきことを確認する。 SS : 市場調査結果を検証し、ｴﾝｽﾄなきことを確認する SS : EOCの複合条件による評価を実施する

(21)

ｴﾝｼﾞﾝｽﾄｰﾙ

D-Case 記述課題

①差分開発

(22)

22 ｴﾝｼﾞﾝｽﾄｰﾙ

D-Case 記述課題

②

Prove In Use

(23)

ｴﾝｼﾞﾝｽﾄｰﾙ

D-Case 記述課題

③想定外

(24)

24

本日の内容

背景

標準化に対する4つの提案



OMGでの国際標準化活動

まとめ

(25)

OMGでの国際標準化活動

• 2011年末：Requirement for Information (RFI)を発行

• 2012年6月:RFIに対するﾚｽﾎﾟﾝｽをOMGで議論

• 2012年9月：標準化に対するwhite paperを提出

• 2012年12月：Requirement for Proposalドラフトを提出

– 発行の見通しが立つ。

• 2013年3月：RFPを発行

– RFP発行後最短18ヶ月でOMG標準化を目指す。その後ISO化を目

指す。

• 2013年12月: Initial Submission（規格初案承認）

• 2014年9月 : 最終規格承認

(26)

26 OMG規格化方針

o 規格化目的

– “Dependable”システムを効果的に開発/保証する標準（方

法論）を提供する

– 他規格（ISOxxxxxx)などを補完する

o 規格内容

– Dependability Assurance Caseの導入

• D-Caseを規格化し、保証議論の骨格とする

– Dependability Conceptual Modelの導入

• 規格全体像をﾒﾀﾓﾃﾞﾙで表現可能にし、保証議論の曖昧性を排除

– Dependability Process Modelの導入

• 保証議論のﾌﾟﾛｾｽを明確化し、開発ﾌﾟﾛｾｽの中で議論可能とする

(27)

本日の内容

背景

標準化に対する4つの提案



OMGでの国際標準化活動

(28)

28

まとめ

 自動車制御安全性認識の高まり

 消費者機械Dependability保証の国際標準化活動

日本が得意とするものづくりの方法を標準化

ｼｽﾃﾑが正しく動作しているかどうか検証・証明するには、

ﾃｽﾄを繰り返すしかない。

従来のｼｽﾃﾑ保証手法（FMEA/FTA）を超えて、どのよう

にｼｽﾃﾑが正しいと判断したか記録を残し、説明する。



OMGでの国際標準化活動

(29)

(30)

30

OMG 団体概要

Object Management Group（OMG)は、ｿﾌﾄｳｪｱ開

発の標準化に関する国際的・オープンな非営利団

体で、

1989年に発足。

企業・大学・官庁・ｴﾝﾄﾞﾕｰｻﾞｰがOMGに加入し、共

消費者機械安全保証 標準化活動 IPA コンシューマデバイス安全標準化 WG 委員 SICE 国際標準化委員トヨタ自動車株式会社エンシ ン技術開発部主幹 石崎直哉 2013/11/20 1