コンシューマデバイス安全規格の概要と規格策定の方法論 ( 独 ) 産業技術総合研究所 セキュアシステム研究部門 (RISEC) システムライフサイクル研究グループ (IPA/SEC コンシューマデバイス安全標準化 WG 副主査 ) 田口研治 産業技術総合研究所

コンシューマデバイス安全規格の概要と

規格策定の方法論

（独）産業技術総合研究所

セキュアシステム研究部門（RISEC)

システムライフサイクル研究グループ

（

IPA/SEC コンシューマデバイス安全標準化WG 副主査）

田口研治

自己紹介

【経歴】 産業技術総合研究所 招聘研究員 （併任） 2010年4月～ （株）シーエーブイテクノロジーズ 代表取締役社長 2011年4月（設立） ～ 産業界における11年間の経験 – ソフトウェア業界における研究開発・コンサルティング 大学・研究機関での15年間の経験

– 海外の大学 講師 （5年間） Uppsala 大学. (Sweden), Bradford 大学. (UK) – 国立情報学研究所 特任教授（ 5年間）

【著作・講演・編者】 【規格、国際会議関連】

 International Conference on Formal Engineering Methods 2012 のプログラム委員長

 OMG System Assurance Platform Task Force の co-chair

 FP7 OPENCOSS プロジェクトの External Advisory Board Member

 IPA/SECコンシューマデバイス安全標準化WG 副主査

【専門分野】

＋高信頼システム開発方法論（形式検証、国際規格における認証、システム保証）

＋形式手法、ソフトウェア工学に関する、多くの国際会議の PC を歴任（iFM’03, TASE ‘03, ICFEM ’03, ASSURE ‘03, ICECCS ‘03）

謝辞

• 本資料は、コンシューマデバイス安全規格に関わられている方々の成果が含ま れています。ここで感謝の意を表したいと思います。 • 新誠一教授（電気通信大学） • 大畠明氏、石崎直哉氏（トヨタ）、K. Ueda 氏（TEMA） • 松野裕氏（電通大） • 中坊嘉宏氏、神徳徹雄氏、G. Biggs 氏（産総研） • 内田功志氏（IPA) • IPA/SEC のコンシューマデバイス安全規格WGの皆様 • Miss. D. Campara (OMG, KDM Analytics)

講演内容

1. コンシューマデバイスの安全規格 1-1 背景 1-2 コンシューマデバイス安全規格の目的 1-3 コンシューマデバイス安全規格の概要 1-4 規格策定作業母体 1-5 規格策定のスケジュール 1-6 コンシューマデバイス安全規格（RFP） 2.コンシューマデバイスにおけるシステム保証 2-1 システムの安全性保証技術 2-2 「ケース」による保証の枠組み 2-3 「ケース」の歴史的背景 2-4 セーフティケースの定義 2-5 提出が義務付けられている分野、規格 2-6 GSN (Goal Structuring Notation)

2-7 OMG による規格化 2-8 ISO など他の規格における標準化 2-9 何故「ケース」が有効か？（根拠の明確化） 2-10 適合性確認の容易さ 2-11 異なるステークホルダ間のコミュニケーショ ンの仲介 2-14 Dependability Case の作成方法 2-15 コンシューマデバイスにおけるDependability Case 3. コンシューマデバイス安全規格の策定方法論 3-1 規格の問題点 3-2 国際規格におけるモデリングの観点 3-2 規格の記述 3-3 メタモデルの利点 3-4 コンシューマデバイス安全規格の策定方法 3-5 ISO 26262 3-6 ISO 26262 Part 3 のメタモデル 3-7 Item Definition

3-8 Initiation of safety lifecycle

3-9 Hazard analysis and risk assessment 3-10 Functional safety concept

3-11 コンシューマデバイスで考慮すべき点 3-12 エラーモデル周辺

3-13 Threat の導入

3-14 Dependability 機能の導入 3-15 Integrity Level の導入

１．コンシューマデバイス

（Safety Sensitive Consumer Devices)

1-1. 背景

コンシューマデバイス

（Safety Sensitive Consumer Devices）

特徴： １）変化が激しい環境での利用 ２）オープンな環境での利用 ３）安全性、信頼性、セキュリティが必要 ISO 26262 や IEC 61508 に欠けている開発技術、プロセス、システム保証 に対する新たな規格の策定が必要！

1-2.コンシューマデバイス安全規格の目的

機能安全規格・ガイドライン 電子機器（IEC 61508） 自動車（ISO 26262） 鉄道（EN 50128） 航空機（DO-178C） ・・・ 目的： 様々な機械類、電気・電子装置、ソフトウェア に対する安全性の保証。 特徴： 欧米主導型の製品の許認可制度、開発 方法論。 消費者機械規格 自動車 介護ロボット スマートハウス ・・・ 目的： コンシューマデバイスという製品カテゴリーに 対するディペンダビリティの保証。 特徴： 日本主導型の製品のシステム保証と、開発 方法論。

消費者機械規格 自動車 介護ロボット スマートハウス ・・・ 目的： コンシューマデバイスという製品カテゴリーに対するディペ ンダビリティの保証。 特徴： 日本主導型の製品のシステム保証と、開発方法論。 システム保証 開発方法論 ディペンダビリティ保証の枠組み 素早い反復開発 Proven-In-Use (PIU) 規格の主目的：

1-3.コンシューマデバイス安全規格の概要

「2.コンシューマデバイスにおけるシステム保証」において、詳 細に説明。 使用実績による安全性の保証（フィール ドデータに基づいた使用実績と、利用条 件などにより規定） 制御装置の動的振る舞いモデル 変化する要求への対応

1-4. 規格策定作業母体

• OMG (Object Management Group) System Assurance Platform Task Force

– 座長

• B. Calloni (Lockeed Martin) • D. Campara （KDM Analytics) • K. Taguchi （AIST) • IPA/SECコンシューマデバイス安全標準化 WG – 主査（新誠一、電気通信大教授）、副主査（田口研治、産総研） 規格策定の母体 標準化の母体

1-5. 規格策定のスケジュール

• 2011年12月

– RFI (Request For Interest) 承認

• 2012年06月

– RFI に対して回答した組織からの内容の発表 ① Toyota

② Trusted Computing Group

③ JST/CREST DEOSプロジェクト/名古屋大 ④ UNIFI/CHESS

• 2013年03月

– RFP （Request For Proposal）承認

• 2013年11月 – RFP に対する提案の締め切り • 2013年12月 – 提案の発表、評価 • 2014年06月 これまでの経緯 今後の予定 規格化への第一ステップ

ディペンダビリティ保証の枠組み

素早い反復開発

ソフトウェアに物理学を（Physics in software） Proven-In-Use (PIU)

1-6. コンシューマデバイス規格（RFP）

Dependability Assurance Case (DAC)

Dependability Conceptual Model (DCM)

今後策定予定

2013年3月発行の RFP の内容

2部で説明

3部で説明

2．コンシューマデバイス

2-1. システムの安全性保証技術

1. 安全分析  システムの安全性の分析（ハザード分析、リスクアセスメント） 2. 開発プロセス  開発案件（製品）の品質を保証する開発プロセス 3. 開発方法論  信頼性を考慮した、要求分析、設計、実装方法論  モデル駆動開発 4. 開発ツール  品質の高いソースコードの生成  トレーサビリティの保証  ツールチェイン 5. 検証技術  テスティング  形式検証 6. 保証技術  開発方法などが如何に信頼性を満たしているかどうかについての保証 7. 評価技術  システムの信頼性の評価基準

2-2. 「ケース」による保証の枠組み

安全要件と目的

安全の根拠資料 安全の議論

Fig 1 – The Role of Safety Argumentation ( T. Kelly [2] )

(安全分析の結果、 V&V の結果、等） (安全目標、安全機能、等）

2-3. 「ケース」の歴史的背景

・1988年７月における、北海油田における Piper Alpha 事故167名死亡（229

名中）、270億円の被害を生じた。

・Cullen 卿による事故調査レポートにより安全ケースの重要性が強調された。

“

Compliance with detailed prescriptive regulations was not sufficient to

ensure safety”

The Offshore Installations (Safety Case) Regulations 1992 に導入。

(最新版 2005 [1])

法規、規格に書かれた通りにすれば安全であるという考え方への反省から、

セーフティケースの提出、アセスメント方式の厳格化などについて社会的基盤

の形成、研究が進んだ。

2-4. セーフティケースの定義

• 英国の防衛規格（00-56) による定義

– 与えられた操作環境における、システムの適用に関して、

安全であることを、強制的かつ理解可能、妥当な事例とし

て提供する、根拠資料の集まりにより支援された構造化さ

れた議論。

– A structured argument, supported by a body of

evidence that provides a compelling,

comprehensible and valid case that a system is

safe for a given application in a given operating

environment.

2-5．

提出が義務付けられている分野、規格

• EUROCONTROL (The European Organisation for the Safety of Air Navigation) – 航空管制システムにおける安全性の保証 ([5])

• Rail Yellow Book ([6])

– 英国における鉄道信号システムの安全性の保証

• MoD Defence Standard 00-56 (Safety Management Requirements for Defence Systems)

– 英国における防衛関連の安全性の保証（[3]） • ISO 26262

– 車載E/Eシステムに関する機能安全規格 （[7]）

• US. Food and Drug Administration Infusion Pump Improvement Initiative ([8]) – 500人以上の死への関連性と 87 製品のリコール

– “… and for making an argument as to why the evidence, your data and analyses, supports the claim”

– “A safety case is the best way to both document and review a submittal based on a risk management approach because the argument shows the proportionality of the mitigation”

2-6. GSN (Goal Structuring Notation)

• 保証のための構造化された議論の記述記法（T. Kelly らにより開発）

– GSN Community Standard Ver. 1.0

• 現在入手可能な最新のリファレンス

• ゴール指向要求分析方法論 KAOS や FTA （Fault Tree Analysis) と類似

回答 戦略 ゴール 文脈 • ゴール(Goal) •システムにより満足されるべき要件、目標。 •ゴールはさらに詳細なゴール（部分ゴール） に分解される。 •文脈（Context) •議論の背景、文脈。 •戦略（Strategy) •論証の方法。 •ゴールから部分ゴールを導く際の規則や方 針。 •回答（Solution/Evidence)

GSN 記法（記述例）

システムは安全 システムの各機能の 安全性を保証する議論 ハザードが回避されて _{いることを保証する議論} 機能XXは仕様通り に機能 XXテスト の結果 システム仕様書 同定されたハ ザードリスト

2-7. OMG による規格化

• OMG （Object Management Group)

– System Assurance Platform Task Force において

Assurance Case の標準化が進行中。

• ARM (Argument Metamodel) [9]

– GSN と CAE (Claim Argument Evidence) のコア部分の標準化。

• SAEM (Software Assurance Evidence Metamodel) [10]

– 根拠資料に関するメタモデル。

– SACM (Structured Assurance Case Metamodel)

• ARM と SAEM の統合案。 • 現在、 改定中。

– MACL

(Machine-checkable Assurance Case Language)

• 機械的に検査するために必要な共通技術の規格化

(p7, Figure 8.1 - Metamodel overview [9])

ARM - OMG による構造化議論のメタモデル -

2.8 ISO など他の規格における標準化

• ISO 15026

– Systems and software engineering -- Systems and

software assurance

– システムとソフトウェアの保証に関する規格シリーズ

• 1: 2010 Concepts and Vocabulary

• 2: 2011 Assurance cases

• 3: 2011 System integrity levels

• BS 5760-18:2010

– Reliability of systems, equipment and components.

Guide to the demonstration of dependability

requirements. The dependability case

米国の防衛製品調達におけるシステム保証

米国における戦略的な Safety Case への取り組み DHS (Department of Homeland Security)

DoD (Department of Defense)

CBK [24]

[24] Software Assurance: A Curriculum Guide to the Common Body of Knowledge to Produce, Acquire and Sustain Secure Software,

Software Assurance Workforce Education and Training Working Group, Oct 2007, Homeland Security

[25] National Defense Industrial Association (NDIA) System Assurance Committee, Engineering For System Assurance, 2008, version 1.0

Engineering For System Assurance [25]

2-9. 何故ケースが有効か？（根拠の明確化）

どのような規格、ガイドライン、システム範囲が想定され、どのような根拠資がど

のように利用されて安全性が保障されているかを明確に示すことが可能。

ガイドライン システム範囲 社内規定集を参照

2-10. 適合性確認の容易さ

XXX part3 XXX part4 スパゲティ構造 XXX part8

規格に書かれている、必要な提出資料、満足すべき条件等を、構造化された

議論という形で整理することが可能。

議論構造

2-11. 異なるステークホルダ間のコミュニケーションの仲介

異なるステークホルダ（開発者、品質保証部門、認証者）間で、安全性がどのよ

うに達成されたかの確認が容易。

開発者 機能安全要件は同定され たハザードを軽減していま す。 品質保証 機能安全要件は適切な ASIL の基づいて記述され ている？ 規定の成果物は全て示さ れている？

2-12. Dependability の定義

• 様々な定義

– 伝統的には信頼性（Reliability) の延長で考えられている。

– 現在の考え方（[20]）

• Umbrella concept – 多くのシステム特性の組み合わせ » 可用性、信頼性、安全性、セキュリティ（の一部）など ([20])

2-13. Dependability Case の定義

A dependability case is a clear, defensible, and traceable argument that

a system is acceptably dependable to operate in a given operational

context. ([21], p27)

• Dependability case は、開発者に保証を与えながら、システムのディペ

ンダビリティ属性の達成に関する議論を伝えなければならない。

• Dependability case はシステムのステークホルダに対する関心事である、

ディペンダビリティ属性の全てに対して確信を与えなければならない。

• Dependability case は、それに対する目的、議論、根拠資料、トレードオ

フ間を明確にトレースすることが可能であるべきである。そのようなトレー

サビリティは、システム設計の受容可能性のシステマチックなレビューの

評価を可能にする。

2-14. Dependability Case の作成方法

TOM (Trade-Off Methodology) トレードオフ方法論

Dependability 要件の獲得・分析

Dependability Case のアーキテクチャ

DDA (Dependability Deviation Analysis)

FANDA (Factors, Analysis and Decision Alternatives)

要求仕様 制御モデル 実装 カリブレーション & V& V 制御設計プロセス 実装プロセス 簡略化 最適化 自動コード生成 Dependability分析 Evidence 収集 Argument 構築 Dependabilityゴール定義 制御設計 Dependability認証根拠資料

2-15. コンシューマデバイスにおける Dependability

Case

Dependability Case

3. コンシューマデバイス安全規格の

策定方法論

3-1. 規格の問題点

• 多くのエンジニアが、規格を理解することの難しさを表明してい

る。

• いくつかの理由

– 必ずしも平坦な用語で記述されていない。

• 用語集は必ず提供されるが、説明が十分で無い場合が

ある。

• 独特の用語を利用していて通常の意味と異なる場合が

ある。

– 記述が曖昧である。

• 厳密に書かれていても、自然言語で記述されていること

による曖昧さが残っている。

• 複数の著者の間での表現が異なる。

3-2． 国際規格におけるモデリングの観点

• 国際規格を広く考察した際に、どのように規格を

仕様記述

しているかについ

て考えてみる。

• 曖昧性の排除

– 準形式手法／形式手法の利用

• 形式手法が利用されている例（WWW Consortium における WSDL (Web Services Description Language) – メタモデル (UMLのクラス図を作成) • OMG において広く適用

• 問題点・疑問点

– 規格のモデル化が効率的かつ有効に行われるのか? • 規格の策定に対して、コストがかかりすぎないのか？ • どのような効用があるのかが不明?

WSDL

• WSDL (Web Services Description Language) by W3C

– WSDL は ドキュメント主体か手続き主体の情報を含むメッセージ上で操作されるエンド ポイントの集合として記述されるネットワークサービスのための XML フォーマット。 – 仕様記述言語 Z により記述され、ツールにより型検査をされた

– コンポーネントとその性質の集まりとしてのWSDL 2.0 の概念モデルはウェッブサービス として記述される。

3-3. メタモデルの利点

• 利用されている概念の洗い出し

• 概念の（共通）理解の促進

• 概念間の相互関係の明確化

• 他システムとの連携を考慮する際の仕様の明確化

 理解するのが難しいと言われている、機能安全規格の理解の支援。  ツール実装の一助

3-4.コンシューマデバイス安全規格の策定方法

UML BPMN SysML CORBA … ツールの相互利用 メタモデルによる仕様記述

コンシューマデバイス安全規格

メタモデルによる仕様の策定！

安全規格をメタモデル

から策定する世界初の試み！

ISO 26262 のメタモデルを作成 コンシューマデバイス安全規格 のメタモデルを作成

3-5. ISO 26262([1])

• 自動車向け電気・電子機能システムの機能安全規格

– 機能安全規格 IEC61508より派生

• Part 1 から Part 10 で構成（内容により分割）。

1. Vocabulary

2. Management of functional safety

3. Concept phase

4. Product development: system level

5. Product development: hardware level 6. Product development: software level 7.Production and operation 8. Supporting processes

9. ASIL-oriented and safety-oriented analyses

10. Guideline on ISO 26262

【規格の全体構造】

今回のコンシューマデ バイス安全規格の対 象範囲

3-6. ISO 26262 Part 3 のメタモデル

第5章 Item definition アイテムの定義。

第6章 Initiation of safety lifecyle 開発種別ごとの安全ライフサイクル。 第7章 Hazard analysis and risk

assessment

ハザード分析、リスクアセスメント、ASIL の決定。

第8章 Functional safety concept 安全目標から機能安全要件の導出。

Clause 5 から Clause 8までを Clause ごとにモデル化

• 同一の概念が現れるが、別の観点から定義されているので、

各 Clause 毎にモデル化を実施

3-7. Item definition

• アイテム定義とその記述、理解が目的。

• アイテムがどのような構造をしているか、アイテムの環境、他アイテムとの依存関係やインタラ クションも含まれる。

3-8. Initiation of safety lifecycle

3-9. Hazard analysis and risk assessment

ISO 26262のインテグリティレベルであるASILがSeverity, Probability of exposure, Controllabilityからなること、それらが何からestimateされるのかが記述されている。

3-10. Functional safety concept

3-11.コンシューマデバイスで考慮すべき点

•ISO 26262は安全性の保証を目的としている

のに対し、コンシューマデバイスではディペン

ダビリティの保証が目的

_。

• ディペンダビリティの定義を利用し、考慮すべき

点としては以下が含まれる。

• エラーモデル

• ディペンダビリティゴール

• インテグリティレベル

• Proven In Use

• マネジメント関係

3-12. エラーモデル周辺

Fault, Error, Failureへの対応

3-13. Threat の導入

• Threat と fault, error, failure の解釈は以下のように

可能（緑色の部分はが dependability を考慮した拡

張）。

3-14. Dependability 機能の導入

• ISO 26262でsafety

mechanism, safety measureと していた部分をdependabilityと

し、safetyはそのサブクラスとし て定義。

3-15. Integrity Level の導入

ISO 26262本来の

インテグリティレベル(ASIL) コンシューマデバイスにおける

4-1. まとめ

• 現時点での、コンシューマデバイス安全規格の策定目的、概要と今後の予定につ いて述べた。

• 規格の内容として重要な次の二点について、その技術的詳細について述べた

– DCM (Dependability Conceptual Model） – DAC (Dependability Assurance Case)

• DAC に関する背景技術として、システム保証の技術、特に「ケース」に基づく技術 を解説した。

• コンシューマデバイス安全規格の策定方法論としてメタモデルによるアプローチの 説明と、現在作成中の ISO 26262 のメタモデルと、そのコンシューマデバイスへの 拡張の提案について説明した。

参考文献

[1] http://www.legislation.gov.uk/uksi/2005/3117/contents/made

[2] T. Kelly, “Arguing Safety – A Systematic Approach to Managing Safety Cases”, U. of York, Dept of Computer Science, 1998.

[3] UK Ministry of Defence, 00-56 Safety Management Requirements for Defence Systems, Part 1: Requirements, Issue 3, UK Ministry of Defence 2004）.

[4] ASCAD, Adelard Safety Case Development Manual, 1998, Adelard.

[5] http://www.eurocontrol.int/corporate/public/subsite_homepage/index.html

[6] http://www.yellowbook-rail.org.uk/

[7] ISO 26262-1~10, Road vehicles – Functional safety, 2011. [8]

http://www.fda.gov/MedicalDevices/ProductsandMedicalProcedures/GeneralHospi talDevicesandSupplies/InfusionPumps/ucm202501.htm

[9] OMG SysA, Argument Metamodel (ARM), FTF Beta 1, ptc/2010-08-36 , Aug 2010, http://www.omg.org/cgi-bin/doc?ptc/10-08-36.pdf

[10] OMG SysA, Software Assurance Evidence Metamodel (SAEM), FTF Beta1, ptc/2010-08-37 , Aug 2010, http://www.omg.org/cgi-bin/doc?ptc/10-08-37.pdf

[12] http://www.il.is.s.u-tokyo.ac.jp/deos/dcase/ [13] http://wiki.portal.chalmers.se/agda/pmwiki.php?n=D-Case-Agda.D-Case-Agda [14] http://www.nil.co.jp/Japanese/Nirvana/plugin_safety.html [15] http://nasa.github.com/CertWare/ [16] http://www.dependablecomputing.com/tools/index.html [17] http://www.adelard.com/asce/index.html [18] http://www.dependable-os.net/osddeos/tech.html

[19] I. Habli, et. al., “Model-Based Assurance for Justifying Automotive Functional

Safety”, in the proceedings of the 2010 SAE World Congress, Detroit, Michigan, USA, April 2010

[20] A. Avizienis, J-C Laprie, Randell, “Basic Concepts and Taxonomy of Dependable and Secure Computing”, IEEE Transactions on Dependable And Secure Computing, Vol. 1, 2004

[21] G. Despotou, “Managing the Evolution of Dependability Cases for Systems of Systems”, U. of York, Dep. Of Computer Science, 2007

[22] G. Despotou, T. Kelly, “A Failure Oriented Model of Dependability”, presented at OMG SysA PTF, 2011, Dec, Santa Clara.

[23] 大畠, 他, “消費者機械安全性・信頼性保証の国際標準化”, SEC journal No. 27, 2012年1月, 第7巻第4号

[24] Software Assurance: A Curriculum Guide to the Common Body of Knowledge to Produce, Acquire and Sustain Secure Software, Software Assurance Workforce

Education and Training Working Group, Oct 2007, Homeland Security [25] National Defense Industrial Association (NDIA) System Assurance Committee, Engineering For System Assurance, 2008, version 1.0