1

１５分で話す機能安全が示す摺り合わせ反復設計

アイシン・コムクルーズ㈱ suzumura-nobuyasu@aisin-comcruise.com 鈴村延保

２０１５ｰ３ｰ１０

ESD21/JASA共催

「TPS/Agile組込システム」セミナー

2

� 今回の私の使命は、

企画側として、“アジャイル”を特殊な言葉でなく、普通に取り組むべき(既に取り組んでいる）言葉に落とし込むこと。

そのために、組み込み現場目線で、広く俯瞰し、

補完して伝えること。

機能安全事周辺で説明すれば、腹に落ちるかと．．

3

自己紹介1977年 広島大学/工学部電子工学科卒 アイシン精機入社後2014年アイシン・コムクルーズへ

� 4ビットマイコンの時代から自動変速機やアクテイブ・サスペンション,ＡＢＳ,ＥＳＣ等のコンンピユータ、関連するシステム、ソフト、ハード、パワー内蔵大規模ＩＣ設計、実装技術の開発・製品化に従事。その後開発比重の高くなったソフトウェア課題に取り組む。 機能安全は、その延長で取り組んで現在に至る。 ＡＳＥＡＮ連携も関心事。

� 自動車技術会 電子・電装部会/電子機能対応分科会 ISO26262規格審議委員 (‘8-’13)� (財）日本自動車研究所ＪＡＲＩ OEM/ｻﾌﾟﾗｲﾔ機能安全共同研究 参加（’12-’13)

� 経済産業省委託 海外自動車電子化調査ＷＧリーダ等� 「平成18年度 Jaspar委託調査 Autosar周辺調査 」� 「平成19-24年度 （財)JARI ITS規格化事業/ITS自動車の電子化に係る欧州調査 」

� 九州工大 産官学連携講座 非常勤講師 (’08～）

� ＮＥＤＯ 生活支援ロボット実用化プロジェクト第２期 準代表と研究員 ‘１１～’１３/４

� IPA高信頼性部会 委員（’14～）

� ＮＥＤＯ新技術ヴェンチャー発掘調査 委員（‘１４下期～）

� 地域コンソーシアムプロジェクト活動アドバイザー参加 （経済産業省助成）� 自動車統合制御用組込みＯＳの開発 ’05～� 機能安全対応自動車制御用プラットフォームの開発 ‘06～� 形式的仕様記述を用いた高信頼ソフト開発プロセス研究とツール開発 ’10～� 故障未然防衛機能を有す高信頼ソフトウェアプラットフォームの開発 ’10～� 高度IT 融合社会を支える次世代自動車用セキュリティ・ゲートウェイ・ECU の開発 ’14～� 農業機械の次世代電子制御ソフトウェア基盤の開発 ’14～

4

今回セミナーのキーワード

� アジャイル（ＸＰ(2000年)）、ＴＰＳ（トヨタ生産方式）、リーンプログラミング、摺り合わせ、コンカレント設計、

機能安全、Ｖ＆Ｖ、System of Systems

システム工学 Systems Engineering, 実行可能仕様書 Executable Specification

5

述べたいこと 1/3

� 機能安全は、車両レベルの安全要件、設計からシステム、コンポーネント、電子回路、ソフトの設計の手順をベストプラクテイス ｓｔａｔｅ ｏｆ ａｒｔでまとめている。

� そこに関係する多数のステークホルダ、企業、組織、メンバーの間で交換する必要ドキュメントは１００以上で、それをすべて固有の名前で定義し、どのように処理すべきか記載している。

(プロセス、ガイド、テンプレート）

6

述べたいこと 2/3

� 文書(要件）交換の基本は、受け取ったら鵜呑みにせず、必ずレビューを含む要件確認、理解、その段階での検証を行い、交換元（ステークホルダー）にフィードバックをすること。 フィードバックされたことを必ず確認し、次の工程へ進む。

(進み方は任されている、 後述のポイントがある）

� 複数の階層を経て上流へフィードバックされることも、当然重要で必要と記載されている。

アジャイル、ＴＰＳ（トヨタ生産方式）、リーンプログラミング、摺り合わせ、コンカレント設計、

7

今回セミナーのキーワードを実現するための根底で重要で、当然機能安全で重視されている事項

-これらは時代で進化しているため、アジャイルが提案された頃(2000)と情況は変化している-

� 構成管理、文書管理、課題管理、変更管理、トレーサビリテイ管理、ベースライン管理が大切。

� コンピユータの進化によるシミュレーション利用、単体テスト、レビューなどＶ＆Ｖの手法、ツールの進化、活用が大切。

8

機能安全とは？機能安全とは？

機能安全 ( Functional safety )

新しい用語、 本質安全と対比する用語。

本質安全と機能安全

本質安全：立体交差にすれば、踏切を渡って事故に遭遇する可能性はない → 根源からリスクを無くして達成する安全

機能安全：現実は線路をすべて立体交差にすることはできない

本質安全を達成できない場合、信号や列車停止装置等の周辺安全機能により相対的なリスクを軽減し、許容リスク以下にする安全

本質安全と機能安全

本質安全：立体交差にすれば、踏切を渡って事故に遭遇する可能性はない → 根源からリスクを無くして達成する安全

機能安全：現実は線路をすべて立体交差にすることはできない

本質安全を達成できない場合、信号や列車停止装置等の周辺安全機能により相対的なリスクを軽減し、許容リスク以下にする安全

9

機能安全とは？機能安全とは？

機能安全 ( Functional safety )

新しい用語、 本質安全と対比する用語。

本質安全と機能安全

本質安全：立体交差にすれば、踏切を渡って事故に遭遇する可能性はない → 根源からリスクを無くして達成する安全

機能安全：現実は線路をすべて立体交差にすることはできない

本質安全を達成できない場合、信号や列車停止装置等の周辺安全機能により相対的なリスクを軽減し、許容リスク以下にする安全

本質安全と機能安全

本質安全：立体交差にすれば、踏切を渡って事故に遭遇する可能性はない → 根源からリスクを無くして達成する安全

機能安全：現実は線路をすべて立体交差にすることはできない

本質安全を達成できない場合、信号や列車停止装置等の周辺安全機能により相対的なリスクを軽減し、許容リスク以下にする安全

機能安全 ( Functional safety )は、本質安全と対比する。しかし機械安全の考え方もリスクが基本の考え方に既に移行し、機能安全の考え方が主となっている。

例：機械類の安全性－リスクアセスメントの原則 ISO14121(2000年制定)

10

ＩＳＯ２６２６２Ｅ／Ｅシステム（電気/電子プログラマブル電子系）を含む安全関連系システムに適用する機能安全

� 第１部：用語集

� 第２部：マネジメント

� 第３部：ASILの決定と機能安全コンセプトの作成

� 第４部：システム開発

� 第５部：ハードウェア開発

� 第６部：ソフトウェア開発

� 第７部：量産以降

� 第８部：サブプロセス、共通規定群

� 第９部：ASILのハンドリングに関する手法など

� 第１０部：ISO26262のガイドライン

11

安全構想

システム設計

部品設計

ﾊｰﾄﾞ設計

部品評価

ﾊｰﾄﾞ評価

ｿﾌﾄ評価

システム評価

妥当性検証ＰＡＲＴ３

ＰＡＲＴ４

ＰＡＲＴ６

ｿﾌﾄ設計

ＰＡＲＴ５ ＰＡＲＴ６ＰＡＲＴ５

安全計画ｾｰﾌﾃｨｰｺﾝｾﾌﾟﾄ

ｼｽﾃﾑ仕様書

ﾊｰﾄﾞ/ｿﾌﾄ仕様書

ｼｽﾃﾑ ﾃｽﾄ仕様ｼｽﾃﾑ ﾃｽﾄ結果

ﾊｰﾄﾞ/ｿﾌﾄ ﾃｽﾄ仕様ﾊｰﾄﾞ/ｿﾌﾄ ﾃｽﾄ結果

規格の具体的要求事項

成果物のトレーサビリティ

・作業成果物は、システムから部品まで一貫性、正確性、遵守性が要求される・カーメーカーの監査では、成果物で機能安全目標達成の説明責任がある

Ｖ字プロセスと呼ぶ

12

システム/アーキテクチャレベル(早い段階）設計の重要性

現在 名古屋大学教授

13

システム/アーキテクチャレベル(早い段階）設計の重要性

14

� 自動車分野のシステム機能安全の国際規格で、カーメーカは順次適用を始めた。

� 部品故障や異常信号発生時に想定される乗員の危険度レベル（ＡＳＩＬ）に応じた安全設計を義務付けた指針。

� システム、コンポーネント、電子回路、およびソフトウェアは、基準以上の安全機構（フェールセーフ）を備えなければならない。例） 冗長設計、故障検知、故障率の低い部品の使用

� ＥＣＵだけでなく、電子制御に関連するセンサ、アクチュエータ、電子部品にも波及する。(機械部品も安全機構に含まれれば、管理が要求される）

規格の概要

ISO26262機能安全規格 の概要(1/2)

15

ISO26262機能安全規格 の概要(2/2)

� 設計、管理の工程名と、手順、成果物に唯一の名前が決められている。世界中で理解できる。工程はプロセス、作業成果物はWork Productと呼ばれる。

� 車両での影響、構想から、部品設計管理まで網羅しており、得意先、サプライヤTier1、サプライヤTier2、仕入先の何処の誰が実施する事項なのか、意識しながら、理解する必要がある。（ これらをプロジェクト毎に取り決めるのが DIA:Development Interface Agreement ）

� ハザード分析、安全分析は別物で、ＦＭＥＡメインであるが、新たにガイドワードを用いた分析を求められる。

規格の概要

・ﾊｰﾄﾞ（ﾒｶ、電気）・ｿﾌﾄｲﾝﾀｰﾌｪｰｽ(HIS)

・安全機構による対策

開発要件

・製品開発におけるｼｽﾃﾑﾚﾍﾞﾙの

Part ４．システム開発

・ASIL決定方法

・ﾊｻﾞｰﾄﾞ分析、ﾘｽｸｱｾｽﾒﾝﾄ(H&R)

要件を記載

ﾌｪｰｽﾞにおける前提条件を決定する

ｼｽﾃﾑ開発の前段階で、以降の開発

Part ３．ＡＳＩＬと機能安全構想

・安全ﾗｲﾌｻｲｸﾙ

管理要件が記載

開発時の管理要件、製造開始後の

開発に関連する組織の管理要件、

Part ２．マネジメント

Part １．用語集

Part ５．ハード開発

・ﾊｰﾄﾞｳｴｱ（ﾒｶ、電気）開発ﾌﾟﾛｾｽに対する要件･HWｱｰｷﾃｸﾁｬ評価・安全目標を侵害する確立の評価

Part ６．ソフト開発

(要求事項は記載なし)

ISO26262を適用する際のｶﾞｲﾄﾞﾗｲﾝ

Part １０．ｶﾞｲﾄﾞﾗｲﾝ

をまとめたもの

ASILまたはsafetyに関係する要件

Part ９．ASILのﾊﾝﾄﾞﾘﾝｸﾞ他

まとめたもの

全章に関わる共通的なﾌﾟﾛｾｽを

Part ８．ｻﾎﾟｰﾃｨﾝｸﾞﾌﾟﾛｾｽ

関する要件を規定

製造工程、市場運用から廃棄までに

Part ７．量産以降

･ｿﾌﾄｳｴｱﾚﾍﾞﾙの各種ﾁｪｯｸ

・ｿﾌﾄｳｴｱ開発ﾌﾟﾛｾｽに対する要件

規格の構成、内容

17

機能安全の補足(1/2)

� ISO26262(機能安全） はまったく新しい考えのように見えますが、違います。機械安全も既に機能安全の考えになっており、最近の安全設計を、このように呼んでいる。

� 根本の流れは、総ての製品分野で安全設計が、リスクﾍﾞｰｽの設計になっていること。

� リスクとはＦＭＥＡでいう危険優先数の概念であり、その意味で車の安全設計は既にリスクベースの安全設計になっている。

� しかし、自動車業界は、安全設計の塊といわれているが、自動車業界は固有の言葉、文化で長年取り組んでおり、車業界外で広まっている一般の安全設計の言葉や手法がわかりにくい場面がある。（リスクアセスメント、ハザード分析）

18

機能安全の補足(2/2)

� 今までどおりの取り組みで良い製品はＱＭランクと呼び、

� 機能安全対応が必要な製品はＡＳＩＬランク A,B,C,D と呼ぶ。（Dが最も厳しく、マイコンも場合によりASIL-D対応デュアルコアへの再設計が必要になります）

� ASILランクは、車両としてのリスクアセスメント（ハザード分析）で開発初期(構想初期）に検討します。分析対象はシステムで、対象範囲を明確にするためアイテムと呼ぶ。

� アイテムの構成要素をエレメントと呼ぶ。

� アイテム＝システム、 エレメント＝コンポーネント(部品＝製品）のイメージであるが、統合制御など機能がコンポーネントに分散、連携している場合が最近多いので、リスクアセスメントの検討開始時点では、アイテム、エレメントと呼び、機能から分析を始めるため、この言葉を使う。

19

述べたいこと 1/3

� 機能安全は、車両レベルの安全要件、設計からシステム、コンポーネント、電子回路、ソフトの設計の手順をベストプラクテイス ｓｔａｔｅ ｏｆ ａｒｔでまとめている。

� そこに関係する多数のステークホルダ、企業、組織、メンバーの間で交換する必要ドキュメントは１００以上で、それをすべて固有の名前で定義し、どのように処理すべきか記載している。

(プロセス、ガイド、テンプレート）

繰り返し

20

述べたいこと 2/3

� 文書(要件）交換の基本は、受け取ったら鵜呑みにせず、必ずレビューを含む要件確認、理解、その段階での検証を行い、交換元（ステークホルダー）にフィードバックをすること。 フィードバックされたことを必ず確認し、次の工程へ進む。

(進み方は任されている、 後述のポイントがある）

� これは、複数の階層を経て上流へフィードバックされることも、当然重要で必要と記載されている。

アジャイル、ＴＰＳ（トヨタ生産方式）、リーンプログラミング、摺り合わせ、コンカレント設計、

繰り返し

21

今回セミナーのキーワードを実現するための根底で重要で、当然機能安全で重視されている事項

-これらは時代で進化しているため、アジャイルが提案された頃(2000)と情況は変化している-

� 構成管理、文書管理、課題管理、変更管理、トレーサビリテイ管理、ベースライン管理が大切。

� コンピユータの進化によるシミュレーション利用、単体テスト、レビューなどＶ＆Ｖの手法、ツールの進化、活用が大切。

繰り返し

22

機能安全を補完する手法の必要性例

� 状態遷移図で完全であっても、状態遷移表で確認すると、ユーザ目線では漏れがあります。状態遷移表で確認をしましょう。

� 状態遷移表で完全であっても、安全分析をすると、システム目線では漏れがあります。安全分析をしましょう。

� これらはＣ言語開発の課題ではありませんが、カスタマー目線での基本課題です。

� sysML等はこれら分析を支援するものではなく、結果を記載する場です。

参考

23

� 機能安全規格の解釈はJasPar,JARI活動で共有されてきた。そこから踏み込んだ相場観は、すべては議論できない。（各社活動）

� 一方で、ある程度相場観を支援できないか、提起が始まっている。

� GSN, D-Case, SafeML, SCDL GSN: Goal Structure Notation (2011）

システムが達成すべき目的や性質について、その達成を導く方法・思考を可視化する際に用いる記法

D-Case: Dependability Case （2013）GSNを利用した合意の表記法（一般社団法人 ディペンダビリティ技術推進協会：IEC 62853/62741,IEC60300-1,ISO/IEC15026)

SafeML: Safety Modeling Language産総研活動：安全関連情報をコミュニケーションよく交換するモデリング記法

SCDL: Safety Concept Description Language（2013～）エレメントの表記法、安全要求の表記法、それらを統合した安全コンセプトの表記法

機能安全を補完する手法の台頭 参考

24

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

suzumura-nobuyasu@aisin-comcruise.com 鈴村延保