IoT 時代のセーフティ設計える化今求められるセーフティ設計とえる化の技術つながるシステムでも必要となるセーフティ設計技術とは 2015 年 7 月 30 日 IPA/SECサプライチェーンにおける品質の見える化 WG 委員株式会社ヴィッツ執行役員機能安全開発部部長株式会社アトリエ取締役

(1)

IoT時代のセーフティ設計『⾒える化』

〜今求められるセーフティ設計と⾒える化の技術〜

「

つながるシステムでも必要となる

セーフティ設計技術とは」

2015年7月30日

IPA/SECサプライチェーンにおける品質の見える化WG委員

株式会社ヴィッツ執行役員機能安全開発部部長

株式会社アトリエ取締役

森川聡久

(2)

本日の内容

＜目次＞

0. 弊社の機能安全実績のご紹介

1. IoT時代にも必要となる安全への対応

2. セーフティ設計技術の基本（ISO 12100より）

3. 従来のセーフティ設計と機能安全設計の違い

4. 機能安全開発のセーフティ設計概要

5. 安全分析演習

6. その他の重要ポイント

＜達成目標＞

・現在/今後必要とされるセーフティ設計技術とは何か

を把握していただく。

(3)

(4)

IEC61508, ISO26262 機能安全プロセス認証取得

【国内初】

2010年4月：

機能安全規格

IEC61508 SIL3対応

ソフトウェアプロセス認証を取得

【世界初】

2012年3月：

自動車機能安全規格

ISO26262 ASIL-D（最高レベル）対応

ソフト

ウェアプロセス認証を

4社同時取得（

東芝

2社,

パナソニック

,ヴィッツ

）

その後、

アイシン2社、

自動車関連企業2社

の

取得支援成功！

IEC61508:1998

IEC61508:2010, ISO26262:2011

プロセス認証取得企業は、

国内外で増加傾向にあり

(5)

安全コンセプトレポート取得成功!!

・平成22年度～24年度：3年間の活動

・

軽くて厳格な保護が可能

な「ParOS」を、パーティションOSの決定版として、

仕様策定から実装まで研究開発した。

・上流レベルの

「技術安全コンセプト」

を国際認証機関TUV SUDに

アセスメント

し

ていただき、

「complete評価」をいただいた

。 ※アセスメント ≠ コンサル

※ParOS安全コンセプトレポートからの抜粋

(6)

主な機能安全支援実績

※ET2013 弊社ブース（TOPPERSパビリオン内）出展風景より ＜機能安全対応コスト＞数億円～数十億円、数年間期間半減!! 費用半減!! を目指した支援弊社の知見投入わからないから莫大なコストがかかる

支援企業実績：

社

プロジェクト

支援項目 A社 B社 C社 D社 E社 F社 G社 H社 I社 J社 K社 L社 M社 N社 O社 P社 Q社 R社 S社 T社 U社 V社 W社 X社 Y社 Z社 a社 b社 c社 d社 e社 f社 g社 h社 i社 j社 k社 l社 m社 n社 o社 ①機能安全プロセス、安全計画の構築● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ②技術安全コンセプトの構築 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ③FMEDA安全分析＆故障率算出評価 ● ● ● ● ● ④機能安全開発受託 ● ● ● ● ● ● ● ● ● ● ● ⑤機能安全第3者検証・監査 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ⑥開発ツールの機能安全対応 ● ● ● ● ● トレーサビリティ管理ツール導入 ● ● ● ● ● ● ● ● 機能安全対応RTOS導入 ● ● ノウハウコンテンツ導入 ● ● ● ● ● ● ● ● ● ● ● 機能安全教育 ● ● ● ● ● ● ● ● ● ● ● ● 機能安全規格解説（無料コンサル※） ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● 機能安全認証取得支援 ● ● ● ● ● ● ● ● ● ● ● ● ● システム、ECU対応 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ハードウェア対応 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ソフトウェア対応 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● IEC 61508 ● ● ● ● ● ● ● ● ● ● ● ISO 26262 ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ● ISO 13849 ● ● ● ● ● その他の機能安全規格 ● ● ● ● ● ● ● ● ● 2014年12月現在

41 支援プロジェクト実績：

71 自動車

建設機械

航空機

医療機器

工作機械

他にも

_{鉄道、ガス機器、農業機械}

サービスロボット、

などの対応実績もあるよ♪

(7)

弊社の機能安全実績の特徴

• ①多分野・多企業への

実開発支援によるノウハウの蓄積

• ②欧州認証機関との豊富な活動経験

– 延べ10プロジェクト以上、70回以上、

500h以上のミーティング経験

⇒ グローバル基準に対する豊富な実践経験

• ③Safety（機能安全）＆ Security（組込みセキュリティ）

– 主な組込みセキュリティ活動

• 重要生活機器連携セキュリティ協議会（CCDS）

• サポイン3件

• JASPAR 情報セキュリティ実証ＷＧ

(8)

(9)

電子化にもリスクあり

(10)

安全規格の階層構造

引用：http://www.line.co.jp/safety/anzen/

ISO 26262

従来から安全規格に適合した製品を開発されているはずです。

しかし、電子システムの複雑化に伴い、より厳しい規格として

(11)

さまざまな産業ドメインで対応必須化する機能安全

IEC 61511

化学プラント

BS EN 50128

BS EN 50129

鉄道

IEC 62061

ISO 13849

機械

ISO 26262

自動車

IEC 62304

IEC 82304

医療機器

ISO 13482

サービスロボット

IEC 61513

原子力

DO-178B

DO-178C

航空機

IEC 60730

IEC 60335

ガス機器

IEC 61508

一般安全装置

建設機械

産業機械

ISO 25119

農業機械

(12)

IoT時代のセーフティの必要性

ネットワーク連携によりシステムは益々複雑に ⇒ セーフティ対応必須

(13)

【弊社取組】異なるメーカーの製品を安全に結合する方法を検討中

欧米農機メーカー

標準通信規格

ISO 11783 / ISOBUS

機能安全規格

ISO 25119

2000年前後から対応 2010年頃から対応開始

国内農機メーカー

10年behind 5年behind

農機用次世代

ソフト基盤

ISOBUS・機能安全対応

ソフト基盤で競争力強化を支援

機能安全設計への形式手法適用、

GSN・SafeMLの利用など予定

平成26年度採択サポイン「農業機械のさらなる高度化と海外進出に資する次世代電子制御ソフトウェア基盤の開発」

(14)

2. セーフティ設計技術の基本

（ISO 12100より）

(15)

安全という概念（ガイド51）

• 「安全」＝「受容できないリスクがないこと」

• 絶対的な安全というものはあり得ない。

– 製品、プロセスまたはサービスにおいては、残留リスクが存在し、相対

的に安全であるとしか言えない。

• 安全は、許容可能なレベルまでリスクを低減することで達成さ

れる。

– 許容可能なリスクは、利便性や費用対効果、社会慣習などの複合的な

要因によって決定されるため、常に見直すべきである。

– 特に、リスク低減の改善が経済的に実現可能になったときには見直し

が必要である。

http://www.toyota.co.jp /jpn/tech/safety/technol ogy/pre_crash/

(16)

リスクとは

システムの潜在的な危険性

リスク＝危害の程度（S）×危害の発生頻度（P）

ALARP：As low as reasonably

practicable

許容域

高発生頻度（Ｐ）危害程度（Ｓ）大

社会通念とし

て容認される

便益との

トレードオフ

ＡＬＡＲＰ域

非許容域

(17)

リスクの低減

ハザードが大きくても

遠くにあるか、

防護対策があれば

リスクは小さい

(18)

セーフティ設計の基本

～リスクアセスメント＆リスク低減プロセス～

機械類の制限の決定危険源の同定リスク見積りリスクアセスメント開始リスクは適切に低減されたか？（適切なリスク低減）リスク分析リスクアセスメント設計者によって講じられる保護方策文書化いいえはい終了他の危険源を生じるか？意図したリスクの低減は達成したか？いいえはいはいいいえリスクの低減

※ISO12100より

(19)

危険源の同定（リスク分析）

• 機械のライフサイクルの全局面（運搬、組立て及び設置、コミッショニング（立ち上

げ、検収引渡し、移管）、使用、分解、利用停止、及び廃棄処分）における、

合理的

に予見可能な危険源

、

危険状態

及び／又は

危険事象

を系統的に同定する。

• 危険源の同定に用いられる『分析手法』

は、以下の通りである。

– JIS9700：2013に記載されていないが、JIS9702：2000（JIS9700：2013へ統合）に記載されている。（HAZOPは記載されていない。） – また、 ISO/TR 14121-2:2012にて、リスクアセスメントの各段階における数々の手法の実際的使用について示されている模様。（ ISO/TR 14121-2:2012 については、未調査）帰納的手法両手法の使い分け演繹的手法

PHA（予備危険源分析） HAZOP（ハザード＆オペラビリティー調査） MOSAR法（系統的リスク分析のための組織化法）ワット・イフ法 FTA（障害ツリー分析）

FMEA（故障モード及び影響分析）デルファイテクニック

危険の同定

(20)

リスク分析手法～FMEAの例～

RPN

＝発生度 × 影響度 × 検出度で評価

RPN:危険優先指数（Risk Priority Number）

機能・要求（大分類）故障モード（故障の内容）故障原因内部への影響外部への影響検出法発生度影響度検出度 RPN 対策方法経年劣化ブレーキの機能に影響。ブレーキの利きが悪い、利かなくなる定期点検 1 10 10 100 劣化しにくいネジを使用する緩みにくいネジを使用するネジの締めが甘いブレーキの機能に影響。ブレーキの利きが悪い、利かなくなる生産時の検査定期点検 1 10 5 50 生産時の検査を強化するブレーキシューの劣化経年劣化ブレーキの機能に影響。ブレーキの利きが悪い、利かなくなる定期点検 1 10 10 100 劣化しにくいブレーキシューを使用する：：アジャスタボルトが緩むブレーキ ※注：わかりやすい例として挙げており、実際の自動車の場合とは異なる可能性があります。

さまざまなシチューエーション（故障も含む）を想定して、

危険事象を洗い出す

(21)

危険源（ハザード）の同定（危険源）

• 『危険源』については、「附属書B（参考）表B.1」にて以下の例

が示されている。

• 詳細は、「附属書B（参考）表B.1」を参照すること。

– 機械的危険源

– 電気的危険源

– 熱的危険源

– 騒音による危険源

– 振動による危険源

– 放射による危険源

– 材料及び物質による危険源

– 人間工学原則の無視による危険源

– 機械が使用される環境に関連する危険源

– 危険源の組合せ

(22)

(23)

(24)

リスク見積り方法（ISO12100、従来開発）

リスク（R）＝危害の発生確率（P） × 危害の酷さ（S）

＝（F + Ps + A） × S

以下は、リスク見積り基準一覧の一例である。

参考：http://robotcare.jp/wp-content/uploads/2014/01/SG-3-2_risk_help.pdf 危険源への暴露頻度／時間 F 連続的／常時 4 頻繁／長時間 3 時々／短時間 2 まれ／瞬間的 1 危険事象の発生確率 Ps 高い 4 起こり得る 3 起こり難い 2 低い（まれ） 1 危害を回避又は制限できる可能性 A 困難 3 可能 1 危害の発生確率： F＋Ps＋A 危害の酷さ： S 3 4 5 6 7 8 9 10 11 重大傷害（長期間治療）（複数人） 8 24 32 40 48 56 64 72 80 88 重大傷害（長期間治療）（1人） 7 21 28 35 42 49 56 63 70 77 医療措置（短期間治療）（複数人） 6 18 24 30 36 42 48 54 60 66 医療措置（短期間治療）（1人） 5 15 20 25 30 35 40 45 50 55 応急手当で回復（複数人） 4 12 16 20 24 28 32 36 40 44 応急手当で回復（1人） 3 9 12 15 18 21 24 27 30 33 無傷／一時的痛み（複数人） 2 6 8 10 12 14 16 18 20 22 無傷／一時的痛み（1人） 1 3 4 5 6 7 8 9 10 11

(25)

抜粋元：「リスクアセスメントシート解説」 (独)労働安全衛生総合研究所池田博康様 http://robotcare.jp/wp-content/uploads/2013/08/130929_partnership_06_m.pdf

(26)

保護方策の種類

安全防護物固定式ガード可動式ガード調整式ガードインターロック付きガード施錠式インターロック付きガード起動機能インターロック付きガードインターロック装置イネーブル装置ホールド・ツゥ・ラン制御装置両手操作制御装置検知保護装置能動的光電保護装置機械的拘束装置制御装置動作制限制御装置ガード保護装置付加保護方策非常停止装置補足された人の脱出及び救助のための方策遮断及びエネルギの消散に関する方策設計者によって講じられる保護方策保護方策安全防護本質的安全設計方策使用上の情報使用者によって講じられる保護方策本規格の対象外ステップ1 ステップ2 ステップ3 ステップ2

(27)

本質安全と機能安全

本質安全・・・

機能安全・・・

ハザードを除去して達成する安全のこと。

例）踏切での衝突をなくすために

立体交差

にする。

ある機能によって確保される安全のこと。

例）踏切周辺に設けた

遮断器、信号、列車停止装置

などの安全関連システムによりリスクを軽減する。

“被制御系および制御系の全体に

関する安全のうち、E/E/PE安全関

連系および他リスク軽減措置の正

常な機能に依存する部分

”

（IEC 61508）

(28)

3. 従来のセーフティ設計と

機能安全設計の違い

(29)

違いのポイント

• 機能安全設計はアドオン

– 従来開発と基本的な流れは変わらない

– 従来のセーフティ設計が実施できていてこそ、安全を

実現可能

• 評価基準などに若干の違いがある

• 機能安全設計＝故障に強い設計

• 安全説明力（PL訴訟対策）が重視されつつある

(30)

機能安全の対象範囲：製品企画～開発～運用～廃棄

※図：IEC 61508抜粋

3.ハザード＆リスク分析

（リスクアセスメント）

4～5.安全要求の決定

15.変更プロセス

16.廃棄

10.開発

14.運用・保守

(31)

Part4.システム開発

Part5.HW開発

Part6.SW開発

Part7.運用・保守・廃棄

機能安全の対象範囲：製品企画～開発～運用～廃棄

※図：ISO 26262抜粋

(32)

従来開発におけるリスクアセスメントの作業フロー

機械類の制限の決定危険源の同定リスク見積りリスクアセスメント開始リスクは適切に低減されたか？（適切なリスク低減）リスク分析リスクアセスメント設計者によって講じられる保護方策文書化いいえはい終了他の危険源を生じるか？意図したリスクの低減は達成したか？いいえはいはいいいえリスクの低減

※ISO12100より

基本的な流れは

機能安全でも同じです。

(33)

リスク見積り方法（ISO12100、従来開発）

リスク（R）＝危害の発生確率（P） × 危害の酷さ（S）

＝（F + Ps + A） × S

以下は、リスク見積り基準一覧の一例である。

参考：http://robotcare.jp/wp-content/uploads/2014/01/SG-3-2_risk_help.pdf 危険源への暴露頻度／時間 F 連続的／常時 4 頻繁／長時間 3 時々／短時間 2 まれ／瞬間的 1 危険事象の発生確率 Ps 高い 4 起こり得る 3 起こり難い 2 低い（まれ） 1 危害を回避又は制限できる可能性 A 困難 3 可能 1 危害の発生確率： F＋Ps＋A 危害の酷さ： S 3 4 5 6 7 8 9 10 11 重大傷害（長期間治療）（複数人） 8 24 32 40 48 56 64 72 80 88 重大傷害（長期間治療）（1人） 7 21 28 35 42 49 56 63 70 77 医療措置（短期間治療）（複数人） 6 18 24 30 36 42 48 54 60 66 医療措置（短期間治療）（1人） 5 15 20 25 30 35 40 45 50 55 応急手当で回復（複数人） 4 12 16 20 24 28 32 36 40 44 応急手当で回復（1人） 3 9 12 15 18 21 24 27 30 33 無傷／一時的痛み（複数人） 2 6 8 10 12 14 16 18 20 22 無傷／一時的痛み（1人） 1 3 4 5 6 7 8 9 10 11

下記は、昔から良く実施されている評価方法の一例。

機能安全では、規格に載っているパラメータに変更必要。

(34)

リスク見積り方法(IEC61508)

IEC61508-5

重篤度

回避性

暴露頻度

発生確率

(35)

リスク見積り方法（ISO26262）

分類

_{ISO 26262-3 表１重篤度の分類}

S0

傷害なし

S1

軽度および中度の傷害

S2

重度および生存を脅かす傷害（ほぼ生存できる）

S3

生存を脅かす傷害（生存は不確実）、致命傷

分類

_{ISO 26262-3 表2 暴露頻度の分類}

E0

ありえない

E1

非常に低い確率

E2

低い確率

E3

中程度の確率

E4

高い確率

分類

_{ISO 26262-3 表3 回避性の分類}

C0

一般に回避可能

C1

容易に回避可能

C2

およそ回避可能

C3

回避が困難、または、回避不可能

(36)

リスクアセスメント（ISO12100、従来開発）

• リスク分析、リスク見積り後に、

リスク低減目標を達成したか

どうかを判断

する。以下は、一例である。

参考：http://robotcare.jp/wp-content/uploads/2014/01/SG-3-2_risk_help.pdf 見積値R 評価リスク低減の必要性 30以上リスクは高く、受け入れられない必須、保護方策が不可欠 15～29 リスクの低減が必要。ただし、条件付き（他に方策がない、低減が現実的でない）で許容可能必要、保護方策が困難な場合は警告表示及び管理的方策を講じる *ALARPとして考慮もあり得る 14以下リスクは十分低い不要危害の発生確率： F＋Ps＋A 危害の酷さ： S 3 4 5 6 7 8 9 10 11 重大傷害（長期間治療）（複数人） 8 24 32 40 48 56 64 72 80 88 重大傷害（長期間治療）（1人） 7 21 28 35 42 49 56 63 70 77 医療措置（短期間治療）（複数人） 6 18 24 30 36 42 48 54 60 66 医療措置（短期間治療）（1人） 5 15 20 25 30 35 40 45 50 55 応急手当で回復（複数人） 4 12 16 20 24 28 32 36 40 44 応急手当で回復（1人） 3 9 12 15 18 21 24 27 30 33 無傷／一時的痛み（複数人） 2 6 8 10 12 14 16 18 20 22 無傷／一時的痛み（1人） 1 3 4 5 6 7 8 9 10 11

機能安全では、規格に記載された

SILやASILで分類される

(37)

ISO26262-5 表4 ASILの決定

重篤度クラス

暴露頻度クラ

ス

回避性クラス

C1

C2

S1

E1

QM

E2

QM

E3

QM

A

E4

QM

A

B

S2

E1

QM

E2

QM

A

E3

QM

A

B

E4

A

B

C

S3

E1

QM

A

E2

QM

A

B

E3

A

B

C

E4

B

C

D

(38)

保護方策の種類

安全防護物固定式ガード可動式ガード調整式ガードインターロック付きガード施錠式インターロック付きガード起動機能インターロック付きガードインターロック装置イネーブル装置ホールド・ツゥ・ラン制御装置両手操作制御装置検知保護装置能動的光電保護装置機械的拘束装置制御装置動作制限制御装置ガード保護装置付加保護方策非常停止装置補足された人の脱出及び救助のための方策遮断及びエネルギの消散に関する方策設計者によって講じられる保護方策保護方策安全防護本質的安全設計方策使用上の情報使用者によって講じられる保護方策本規格の対象外ステップ1 ステップ2 ステップ3 ステップ2

ステップ

2の電子系の安全策

が、機能安全の対象です。

(39)

従来開発と機能安全開発の大きな違い

従来開発

①壊れないモノ作り

・自己努力によって

壊れにく

いもの

、バグゼロが目標

・匠の技術で作られた

高信頼

性部品

を使用

②日本流開発スタイル

・担当者間の“すり合わせ開

発”で、効率的に開発を進行

・開発文書の出来栄えは

不

十分（必要最小限）

機能安全開発

①壊れても安全なモノ作り

・高品質の

証拠を積み重ねた

開発

によってバグゼロが目標

・

万が一構成部品が故障して

も危険にならない「仕組み」

が

必要

②安全説明力のある開発

・PL訴訟時に

安全を客観的

に説明できる開発文書

の作

成や

エビデンス

が必要

安

全

性

強

化

不

慣

れ

な

開

発

ス

タ

イ

ル

へ

組込みシステムの複雑化

による事故多発への対応として

「実の安全性向上」

と

「PL訴訟対策」

のため、機能安全は生まれた。

機能安全規格への適合で、

過剰な安全対策を排除

可能。

(40)

【機能安全】安全関連システムの故障4分類

自己診断可能な

安全側故障

自己診断可能な

危険側故障

（

DD故障）

自己診断不能な

安全側故障

自己診断不能な

危険側故障

（

DU故障）

危険側

安全側

診断できる

診断できない

• 安全機能の性能の指標

• 機能失陥に伴うリスクに応じた目標値設定が必要

(41)

【機能安全】 SILとPLの関係

SIL：Safety Integrity Level （IEC 61508）

PL：Performance Level （ISO 13849）

(42)

【機能安全】安全機能の失陥

組織要因

技術要因

人的要因

 貧弱な安全文化

 不十分な開発管理

安全機能

失陥

 スキル不足

 「ひとは間違える」

 ハードウェア部品故障

 ソフトウェアバグ

 「ものは壊れる」

リスク

増大

(43)

【機能安全】「信頼性」の“積み重ね”が安全を実現

品質管理システムの構築

（CMMI, A-SPICE）

機能安全管理システムの構築

（IEC 61508, ISO 26262, ISO 13849, etc）

コンセプト開発

機能安全開発・評価

プロセス構築

プロセス改善・定着

安全目標の定義

技術安全コンセプト構築

機能安全開発

機能安全評価

・システム ・HW ・SW ・規定・ガイドライン・テンプレ―ト・チェックリスト

×

プロセス構築

×

プロセス改善・定

着

既存開発との

ギャップ診断

・H&R分析 ・目標SIL/ASIL決定 ・安全コンセプト・安全マニュアル・安全要求仕様書・システム安全分析 ・システム開発・V&V ・HW開発・V&V ・SW開発・V&V ・回路図の安全分析 ・SWアーキの安全分析 ・SIL/ASIL故障率評価 ・機能安全監査

安全計画

機能安全

対応製品

・FSMプラン ・V&Vプラン ・調達（ツール・外注）

(44)

H&R と安全分析の違い

• ハザード＆リスク分析（H&R）≒ ISO12100

– ハザード（危険事象）を抽出し、

• 機能安全では「万が一故障した場合の誤動作」も想定

– リスクを評価し、

• 機能安全では「SIL/ASIL」などが決定

– 安全策を検討する。

• 安全分析（機能安全）

– 前提：電気系部位の故障対策（安全設計）が検討済

– 電気系部位について、故障しても危険にならないこ

とを確認する。

(45)

H&R と安全分析の違い：具体的イメージ例

①ハザード

制御が暴走したら危険!!

②リスク評価

SIL2

③安全策

「非常停止ボタン」を付けよう!!

④安全要求の定義

「非常停止ボタン押下時に確実に

停止すること（SIL2）」

ボタン

マイコン

リレー

＜従来設計（機能実現）＞

※注）非常停止ボタンだけで十分安全になるかは不明

ボタン

マイコン

リレー

＜安全設計＞

＜

H&R＞

2重接点ボタン

リレーの

_故障検出

WDT

＜安全分析＞

SIL2を満たす安全設計

であることを確認する。

電源

マイコンの

故障検出

(46)

(47)

安全目標（Safety Goal）とは

• 安全上守らなければならない機能要件

– 安全状態（Safety State）

– 安全時間（Safety Time）

例）電動パワステ（EPS）

安全目標

Safety Mechanism

Main Function

例）意図しないセルフステア（電子制御システムが

勝手にハンドルを切る）が100ms以上発生しないこと

EPSの基本機能

部品が故障しても、安全目標を達成できるための対策

FTTI

ISO26262-1

(48)

安全分析にて考慮すべき故障のパターン

• 系統的原因故障（バグ）とランダムHW故障

• 単一故障と多重故障

– IEC 61508では、単一故障のみ考慮

– ISO 26262（自動車）では、２重故障まで考慮必要

– BS EN 50129（鉄道）では、３重故障まで考慮必要

• 恒久故障と一時故障

– 一時故障の例）ノイズによるメモリ化け

• 従属故障

– ある故障が原因で、その影響を受け、別の箇所が故障する

• 共通原因故障

– １つの原因により、複数箇所への同時故障が生じること

– 例１）電源異常により、２マイコン共誤動作

– 例２）ノイズの影響（環境）により、２マイコン共誤動作

– 例３）安全系のある変数が化け、各出力系全てが誤動作

– 例４）同一設計のソフトのため、同じ箇所にバグが存在

(49)

潜在故障

• 安全策（Safety Mechanism；SM）の潜在故障

安全機能

（これが故障すると

危険に直結）

安全策１

（安全機能が故障し

ていないことを監視）

②異常を検出

⇒ フェールセーフ処理

①故障

安全機能

（これが故障すると

危険に直結）

安全策１

（安全機能が故障し

ていないことを監視）

①先に故障

②後に故障

⇒ 危険

a) 安全なケース

b) 危険なケース

対策例

安全機能

（これが故障すると

危険に直結）

安全策１

（安全機能と安全策

２が故障していない

ことを監視）

安全策２

（安全策１が故障して

いないことを監視）

(50)

安全性能達成のための安全アーキテクチャの例

“Design Patterns for Safety-Critical Embedded

Systems” by Ashraf Armoushより

(51)

安全分析が必要な工程

システム

安全要求仕様工程

システム

アーキテクチャ設計工程

安全コンセプト

ソフトウェア

安全要求仕様工程

ソフトウェア

アーキテクチャ設計工程

ソフトウェア

モジュール設計工程

コーディング工程

ソフトウェア

モジュールテスト工程

ソフトウェア

統合テスト工程

ソフトウェア

安全妥当性確認工程

システム

統合テスト工程

システム

安全妥当性確認工程

(HAZOP or FMEA)

and/or FTA

ハードウェア

安全要求仕様工程

回路設計

基板製作

HAZOP or FMEA

FMEDA

目的：故障が生じても危険にならないことの確認

(52)

故障挿入試験（FIT：Fault Injection Test）

システム

安全要求仕様工程

システム

アーキテクチャ設計工程

安全コンセプト

ソフトウェア

安全要求仕様工程

ソフトウェア

アーキテクチャ設計工程

ソフトウェア

モジュール設計工程

コーディング工程

ソフトウェア

モジュールテスト工程

ソフトウェア

統合テスト工程

ソフトウェア

安全妥当性確認工程

システム

統合テスト工程

システム

安全妥当性確認工程

ハードウェア

安全要求仕様工程

回路設計

基板製作

FIT

（

ISO26262）

FIT

（

ISO26262）

FIT

（

IEC61508, ISO26262）

安全分析結果

目的：故障が生じても危険にならないことの確認（実物に対して）

※黄色の工程は、ISO 26262において安全分析を行う必要のある工程です。

(53)

ソフトウェアの誤動作に影響する故障原因(Fault)の代表例

コンポーネント

故障モード

固着

タイムアウト

固着

データ化け

固着

データ化け

固着

データ化け

誤った命令の実行

命令が実行されない

データの固着

アドレスの固着

データ化け

アドレス化け

データの固着

アドレスの固着

データ化け

アドレス化け

クロック

周期の誤り

ソフトウェア

ソフトウェアのバグ

スタックポインタ

命令デコーダ

ROM

RAM

バス

汎用レジスタ

プログラムカウンタ

(54)

マイコン故障に対する主なソフトウェアによる安全策

故障モード

主な安全策（故障診断方法）

ISO26262-5

ROM故障

・チェックサムやCRCによるROM故障検出

Table D.5

RAM故障

・チェックサムやパターンテストによるRAM故

障検出

・安全関連データの2重管理

Table D.6

CPUコア故障

・レジスタのテスト

・スタックオーバー／アンダーフロー検出

・実行シーケンスモニタ＋WDT

Table D.4

Table D.10

クロック故障

・タイムウインド付きWDT

Table D.10

内部バス故障検出

・ウォーキングビットによるバス故障検出

Table D.14

(55)

RAM故障に対する安全策（故障診断）の例

ISO26262-5

90%

99%

60%

99%

DC

(56)

ソフトウェアのバグ（誤動作）検出機構（IEC61508）

(57)

ソフトウェアのバグ（誤動作）検出機構（ISO26262）

ISO26262-6

＜従来開発＞

テストがしっかり出ていてバグが無い。

＜機能安全＞

テストの完全性は不可能。

バグが潜んでいることを前提に対処。

(58)

ソフトウェアの誤動作に影響する故障原因(Fault)

と異常動作の一例

1．v_req_heatの上下限補正（0～5の範囲にする） 20．v_req_heat --S3押下割込み 30．v_req_heat ++ S4押下割込み main 2．v_req_heatに対応したS1,S2出力時間(t)を変換テーブルから取得し、v_t に格納する 3．S1のポートに‘1’を出力 4．Wait(v_t) 5．S1のポートに‘0’を出力 6．Wait(d) 7．S2のポートに‘1’を出力 8．Wait(v_t) 9．S2のポートに‘0’を出力 10．Wait(d)

処理のスキップ

処理の繰り返し

原因：

ROM故障

原因：割込みコントローラ故障

・割込みが不要に入る

・割込みが入らない

原因：

RAM故障、

ノイズによる

RAM化け

・変数が異なる値になる

原因：クロック故障

待ち時間が期待値より長い・短い

誤処理

原因：

CPUコア故障

（

PC,SP,レジスタ,デコー

ダ

,etc）

※IHクッキングヒーターの例

(59)

ソフトウェア詳細設計の改善例

(60)

(61)

【再掲】H&R と安全分析の違い

• ハザード＆リスク分析（H&R）≒ ISO12100

– ハザード（危険事象）を抽出し、

• 機能安全では「万が一故障した場合の誤動作」も想定

– リスクを評価し、

• 機能安全では「SIL/ASIL」などが決定

– 安全策を検討する。

• 安全分析（機能安全）

– 前提：電気系部位の故障対策（安全設計）が検討済

– 電気系部位について、

故障しても危険にならないこ

とを確認する。

(62)

主な安全分析手法の概要

FTA

（Fault Tree

Analysis）

故障原因

のリスト

単一の故障

FMEA

（Failure Mode and

Effect Analysis）

単一の故障原因

故障のリスト

HAZOP

（Hazard and

Operability Study）

故障原因の

故障のリスト

単一の逸脱（deviation）

・トップダウン解析手法

・

Fault Treeを描いて分析

利点：特定の故障に対する分析がしやすい

・ボトムアップ解析手法

・ワークシート（表）を書いて分析

利点：システムの故障率の算出に必要

・トップダウンとボトムアップの中間的な方法（探索的な方法）

・性質やタイミングに関するガイドワードを用いて分析

利点：網羅的な分析が可能

アーキテクチャレベル（概略レベル）への適用に向く

(63)

HAZOPワークシートとガイドワードの例

Item

No.

Item

属性

（Attribute）

ガイドワード故障

モード

原因

影響

対策

（１）

（２）

（３）

（４）

（５）

（６）

（７）

もし、[アイテム] の [属性] が [ガイドワード] だったら？

HAZOP Question：

アイテム×属性×ガイドワードを組み合わせ分の実施が必要

⇒ （想定外も含めて）故障モードの網羅的な洗い出しが可能

一般的な性質に関する

ガイドワード

• No

• More

• Less

• As well as（複製）

タイミングに関する

ガイドワード

• Early

• Late

• Before

• After

• Part of（未完）

• Reverse

• Other than（不正）

(64)

【事例】安全分析結果

＜

安全分析シートの記載項目の例＞

• 機能グループ

• API

• コンフォーマンスクラス

• ガイドワード

• 故障モード

• SGへの影響

• 影響

• 原因

• 予防策

• 検出策

• 達成DC

• 検出後のOSの状態

• 参照ID

• 対策ID

※上記は(株)ヴィッツ開発ParOSの安全分析結果の記載内容

(65)

【演習】題材概要（VCS）

• 車両はVCS（車両制御システム）を含む

• VCSは運転者に制限速度を表示し、速度超過

の場合は自動的にブレーキをかける

• VCSは車両の速度計とは独立に動作する

– ビーコン間の時間から、車速を計算する

• VCSに接続されたアンテナが、ビーコンからの

メッセージを受信する

– ビーコン信号は、ビーコンに十分近づいたときの

み受信可能

– 通常速度では、4回から2回、メッセージが受信さ

れる

(66)

【演習】題材概要

A

B

_C

自動ブ

レーキ

運転者

ブレーキ

制限速度

VCS: 車両制御システム

車速超過保護システムは、車両の危険な速度超過に対する保護方策である

路側に一定間隔でビーコンが設置される

各ビーコンは、制限速度および

IDを含むメッセージを送信する

自動運転

ビーコン

車両は、以下の例外を除き、速度範囲

V_minからV_maxの範囲で運用される

静止状態からすぐに

V_minに至る

進行方向は反転できる

(67)

【演習】VCSシステム要求仕様

ビーコン信号

（制限速度、ビーコンID）

アンテナ

ビーコン

電波

自動

ブレーキ

運転者

ブレーキ

運転者ブレーキ

デマンド

表示器

制限速度

（表示パターン）

自動ブレー

キ指示

VCS: 車両制御システム

ID 要求事項 SR1 車両起動時に、システムの初期化を行う。 SR2 隣接するビーコン間の移動に要する時間から、車速を計算する。 SR3 車速計算結果と、ビーコンから送信される制限速度を比較する。計算車速が制限速度を超過する場合は、自動ブレーキをかける。 SR4 自動ブレーキは、運転者がブレーキをかけたときにリリースされる。ただし自動ブレーキは、少なくともT_brake時間は、かけ続ける。 SR5 ビーコンから受信した制限速度を、表示する。

(68)

【演習】安全ゴール、安全状態

• 以下の安全ゴールを想定する：

– SG1:制限速度を超過した場合、少なくともT_brake

の間は自動ブレーキをかけ続けなければならない

／ASIL D相当

– SG2：制限速度を過小に表示してはならない

／ASIL B相当

• 以下の安全状態を想定する：

– 自動ブレーキ：かかっている状態

– 制限速度の表示器：何も表示しない状態

(69)

【演習】システムアーキテクチャ設計

RIU

BCU

DC

データバス自動ブレーキ指示運転者ブレーキデマンド制限速度（表示パターン）

VCS: 車両制御システム

コンポーネント名

処理概要

RIU（RFインター

フェースユニット）

• 車両のアンテナに接続され、路側のビーコンからの信号を受信する

• 隣接するビーコン間の移動に要する時間から、車速を算出する

BCU（ブレーキ制

御ユニット）

• 緊急時に自動ブレーキを作動または解除する

• 運転者ブレーキを監視する（運転者は自動ブレーキとは独立に、運

転者ブレーキを制御する）

DC（表示制御）

• 制限速度の表示器を制御する

メッセージ

送信者

受信者

自動ブレーキ指

示

RIU

BCU

運転者ブレーキ

デマンド

BCU

RIU

制限速度

RIU

DC

(70)

【演習】システムアーキテクチャ設計

ID

コンポーネントに対する要求

割当て先

CR1

アンテナを介して路側のビーコンからの信号を受信する

RIU

CR2

ビーコン信号から、ビーコンIDと制限速度を取得する

RIU

CR3

隣接するビーコン間の移動に要する時間から、車速を決定する

RIU

CR4

計算した車速が制限速度を超過する場合は、自動ブレーキ指示を

BCUへ送信する

RIU

CR5

運転者ブレーキデマンドを受信した場合は、自動ブレーキ指示の送信

からT_brake時間が経過していれば、自動ブレーキ指示を解除する

RIU

CR6

制限速度の値をDCへ送信する

RIU

CR7

RIUからの自動ブレーキ指示を受信したら、自動ブレーキをかける

BCU

CR8

運転者ブレーキをモニタし、運転者ブレーキがかけられたことをRIUへ

伝達する

BCU

CR9

制限速度の値をRIUから受信する

DC

CR10

制限速度表示器の表示パターンを算出する

DC

CR11

制限速度表示器の表示を更新する

DC

(71)

【演習】SHARDのガイドワード・分析の例

分析の例（RTOSのタスク管理に関して）

機能

ガイドワード故障モード

Omission

タスクが実行すべき時に実行されない

Commission タスクが実行すべきでない時に実行される

Early

適切な時間より早く、タスクが実行する

Late

適切な時間より遅く、タスクが実行する

Value

異なるタスクが実行される

※株式会社ヴィッツによるRTOSに対する適用例

タスクを適切な時間に実行

する。

ガイドワード

ガイドワード解釈

詳細分類

Omission

サービスが実行されない。

（例えば、通信がされない。）

・完全に

・部分的に

Commission

要求していないサービスが実行される。

（例えば、期待していない通信が実行される。）

・偽装

・重複

Early

期待するよりも早くサービスが実行される。

・絶対時間

・相対時間

Late

期待するよりも遅くサービスが実行される。

・絶対時間

・相対時間

Value

間違った値のデータ（情報）が伝達される。

SHARD（Software Hazard Analysis and Resolution in Design）

(72)

【演習問題】システムアーキテクチャの安全分析（1/2）

No. ガイドワード故障モード原因コンポーネントレベル影響 VCSレベル 影響 SG侵害 対応策 1 Omissi on ビーコン信号を受信しないビーコン故障、アンテナ故障、RIU不具合実際よりも遅い車速を算出する自動ブレーキ指示をしない SG1 一定時間ビーコン信号を受信しない場合は、自動ブレーキをかける 2 Commi ssion 3 Early 4 Late 5 Value

CR1：アンテナを介して路側のビーコンからの信号を受信する（RIU）

(73)

【演習問題】システムアーキテクチャの安全分析（2/2）

No. ガイドワード故障モード原因コンポーネントレベル影響 VCSレベル 影響 SG侵害 対応策 1 Omissi on ビーコン信号を受信しないビーコン故障、アンテナ故障、RIU不具合実際よりも遅い車速を算出する自動ブレーキ指示をしない SG1 一定時間ビーコン信号を受信しない場合は、自動ブレーキをかける 2 Commi ssion 3 Early 4 Late 5 Value

CR5：運転者ブレーキデマンドを受信した場合は、自動ブレーキ指示の送信から

T_brake時間が経過していれば、自動ブレーキ指示を解除する（RIU）

(74)

【解答例】システムアーキテクチャの安全分析（1/2）

No. ガイドワード故障モード原因コンポーネントレベル影響 VCSレベル影 響 SG 侵害対応策 1 Omissi on ビーコン信号を受信しないビーコン故障、アンテナ故障、 RIU不具合実際よりも遅い車速を算出する自動ブレーキ指示を送信しない SG1 一定時間ビーコン信号を受信しない場合は、自動ブレーキをかける 2 Commi ssion ビーコン信号がないのにビーコン信号を誤認識するノイズ、RIU不具合実際よりも早い車速を算出する不要な自動ブレーキ指示を送信するなし－ 3 Early ビーコン信号の受信タイミングが早すぎるビーコン信号の強度過大、アンテナのゲイン過大実際よりも早い車速を算出する不要な自動ブレーキ指示を送信するなし－ 4 Late ビーコン信号の受信タイミングが遅すぎするビーコン信号の強度過小、アンテナのゲイン過小実際よりも遅い車速を算出する自動ブレーキ指示を送信しない SG1 一定時間ビーコン信号を受信しない場合は、自動ブレーキをかける 5 Value ビーコン信号の誤った値を受信するビーコン故障、ノイズ、RIU不具合実際とは異なる車速を算出する／制限速度を誤認する自動ブレーキ指示を送信しない／過小な制限速度を送信する SG1 ／ SG2 信号の正しさを検証する（CRCによる完全性確保、同一信号が2回連続することを確認など）

CR1：アンテナを介して路側のビーコンからの信号を受信する（RIU）

(75)

【解答例】システムアーキテクチャの安全分析（2/2）

No. ガイドワード故障モード原因コンポーネントレベル影響 VCSレベル影 響 SG 侵害対応策 1 Omissi on 運転者ブレーキデマンドを受信して所定時間経過したのに、自動ブレ― キ指示を解除しない運転者ブレ― キデマンドの誤認識、RIU判定不具合自動ブレーキを指示を解除しない不要な自動ブレーキ指示を送信するなし－ 2 Commi ssion 運転者ブレーキデマンドを受信していないのに、自動ブレ― キ指示を解除する運転者ブレ― キデマンドの誤認識、RIU判定不具合自動ブレーキを指示しない自動ブレーキ指示を送信しない SG1 BCUでも確認する（冗長化） 3 Early 自動ブレーキ指示の送信後 T_brake時間たたないうちに解除する運転者ブレ― キデマンドの誤認識、タイマ不具合、RIU判定不具合自動ブレーキを指示しない自動ブレーキ指示を送信しない SG1 タイマ機能の異常監視

CR5：運転者ブレーキデマンドを受信した場合は、自動ブレーキ指示の送信から

T_brake時間が経過していれば、自動ブレーキ指示を解除する（RIU）

(76)

【解答例】システムアーキテクチャの安全分析（2/2）

No. ガイドワード故障モード原因コンポーネントレベル影響 VCSレベル影 響 SG 侵害対応策 4 Late 運転者ブレーキデマンドを受信後、T_brake 時間以上経過し自動ブレーキ指示を解除する運転者ブレ― キの誤認識、タイマ不具合、 RIU判定不具合自動ブレーキ指示の解除が遅れる不要な自動ブレーキ指示の送信が続くなし－ 5 Value 運転者ブレーキ指示とは誤った動作（Omission、 Commissionと同一）－－－

(77)

(78)

【再掲】「信頼性」の“積み重ね”が安全を実現

品質管理システムの構築

（CMMI, A-SPICE）

機能安全管理システムの構築

（IEC 61508, ISO 26262, ISO 13849, etc）

コンセプト開発

機能安全開発・評価

プロセス構築

プロセス改善・定着

安全目標の定義

技術安全コンセプト構築

機能安全開発

機能安全評価

×

プロセス構築

×

プロセス改善・定

着

既存開発との

ギャップ診断

・H&R分析 ・目標SIL/ASIL決定 ・安全コンセプト・安全マニュアル・安全要求仕様書・システム安全分析 ・システム開発・V&V ・HW開発・V&V ・SW開発・V&V ・回路図の安全分析 ・SWアーキの安全分析 ・SIL/ASIL故障率評価 ・機能安全監査

安全計画

機能安全

対応製品

・FSMプラン ・V&Vプラン ・調達（ツール・外注）

(79)

文書化要件の重要ポイント

• 機能安全が求めること

– 完全性・一貫性

• 開発・管理・運用に必要な情報が全て記載/記録されていること

• 過不足・矛盾がない

• あらゆる観点での検証（Verification）を実施して確認されていること

– 再現性＋客観性

• 再現/再検証できること

（他者でも、数年後でも）

– 可読性＋客観性

• 同意の理解ができること

（他者が見ても、数年後に見ても）

⇒ 誤解するような内容だと･･･

・関連モジュールに不具合混入の恐れ

・後のメンテで誤修正の恐れ

⇒ 再現できない内容だと･･･

・安全であることを、客観的に確認できない

・後の不具合発生時に、問題原因を追究で

きない

安全性を説明可能

満たせば

PL訴訟で通用するには、再現性・客観性・可読性が重要!!

(80)

【弊社事例】安全コンセプトレポート取得成功!!

2013/11/21

• 軽くて厳密な保護機能を搭載した「Partition OS」仕様を策定．

・安全コンセプト

・安全要求仕様

・安全分析結果

・安全マニュアル

Partition OS

上流レベルの

技術安全コンセプト

を国際認証機関

TUV SUDに

アセスメント

を依頼したところ，「この仕

様ならアプリケーションの独立性を保証できる」と

判断して頂き，

「complete評価」のレポートを貰った

．

※アセスメント ≠ コンサル

(81)

【弊社事例】技術安全コンセプト構築における重要ポイント

• 安全目標（SG）の明確化

• SGの実現の明確化

– SGを達成するための要求が妥当であるかの確認

• 安全分析（システムFMEA）

• 図で分かりやすく説明する

• 安全性を証明（説明）するための文書作成

– SRS, SC, SM, 安全分析結果

• 明確な安全マニュアル（SM）の作成

(82)

【弊社事例】コンセプトフェーズの安全分析の規模

EXCELシート名

コンテンツ

分析項目数

APP | SYS-MEM

機能グループ

“APP | SYS-MEM” に対する安全分析結果

24 APP |

SYS-EXECUTIVE_API

機能グループ

“APP | SYS-EXECUTIVE_API” に対する安全分

析結果

194 OS-EXECTUIVE_API

機能グループ

“OS-EXECTUIVE_API” に対する安全分析結果

181 OS-EXECUTIVE

機能グループ

“OS-EXECUTIVE” に対する安全分析結果

326 APP | SYS-IPC

機能グループ

“APP | SYS-IPC” に対する安全分析結果

72 APP | SYS-COM_API

機能グループ

“APP | SYS-COM_API” に対する安全分析結果

244 OS-COM_API

機能グループ

“OS-COM_API” に対する安全分析結果

319 OS-COM

機能グループ

“OS-COM” に対する安全分析結果

28 APP | SYS-SAFE_API

機能グループ

“APP | SYS-SAFE_API” に対する安全分析結果

19 OS-SAFE_API

機能グループ

“OS-SAFE_API” に対する安全分析結果

19 OS-SAFE

機能グループ

“OS-SAFE” に対する安全分析結果

20 SA Group No

共通の安全対策のグループ化

－

全安全分析項目数：1446

（弊社が共同研究開発したパーティションOSの範囲のみ）

(83)

【弊社事例】安全分析のための機能グループ定義

Partition1 SafeOS Instance Partition2 SafeOS Instance Partition3 SafeOS Instance Task1 Task2 Task3

Memory1

(CODE/DATA)

Device1 Device2 Device3 Memory2 (CODE/DATA) Memory3 (CODE/DATA) ParOS Cha nnel1 Cha nnel2 Appli cation SafeOS COM Executive Partition1 SafeOS Instance Partition2 SafeOS Instance Partition3 SafeOS Instance Task1 Task2 Task3

Memory1

(CODE/DATA)

Device1 Device2 Device3 Memory2 (CODE/DATA) Memory3 (CODE/DATA) ParOS Cha nnel1 Cha nnel2 COM SafeOS Executive

Illegal Memory Operation (APP-MEM/SYS-MEM) Illegal Call ParOS API

(APP-EXECUTE_API /SYS-EXECTIVE_API)

Illegal inter-partition com (APP-IPC/SYS-IPC)

Patition1 Object

Illegal Execute COM Function (OS-COM) Illegal Execute COM API (OS-COM_API) Illegal Call COM API

(APP-COM_API /SYS-COM_API) SafeOS/ParOS/COM API User Program ParOS Program Illegal Execute ParOS Function (OS-EXECTIVE) : execute

: fault : access / call

Illegal Execute ParOS API (OS-EXECTIVE_API)

Illegal Execute SafeOS API (OS-SAFE_API) Illegal Execute

SafeOS Function (OS-SAFE)

Illegal Call SafeOS API (APP-SAFE_API /SYS-SAFEAPI) 機能グループ • Application • COM • Executive • SafeOS

機能グループの詳細化

⇒ 全11グループを定義

Application 1 time window Application 2 time window

APP-MEM / SYS-MEM / APP-IPC / SYS-IPC

Call ParOS API

APP-EXECUTIVE_API / SYS-EXECUTIVE_API OS-EXECUTIVE_API Application 1 Application 2 ParOS COM APP-COM_API / SYS-COM_API OS-OCM_API

Call COM API

OS-EXECUTIVE OS-COM

OS Processing

SafeOS

Call SafeOS API

APP-SAFE_API / SYS-SAFE_API OS-SAFE ※各機能グループの処理タイミング図 ※機能グループと故障モードの関係 ※図は弊社が共同研究開発したパーティションOSの安全分析結果からの抜粋

(84)

【弊社事例】安全分析の網羅性の説明

＜認証機関指摘事項＞

故障検出や結果について定量化された情報がない。

＜対策例＞

・「定量化の情報＝安全分析が網羅できているという情報」との合意を得て、

以下の手法にて、網羅的に安全分析が出来ているという証明を行った。

- 分析対象範囲の明確化（機能ブロック図、APIマッピング）

×

- HAZOPガイドワードによる網羅的抽出

・Compliance Matrixを用いた確認

Partition1 SafeOS Instance Partition2 SafeOS Instance Partition3 SafeOS Instance Task1 Task2 Task3

Memory1

(CODE/DATA)

Device1 Device2 Device3

SafeOS/ParOS/COM API _Memory2 (CODE/DATA) Memory3 (CODE/DATA) ParOS Cha nnel1 Cha nnel2 COM SafeOS

Exectuive Patition1 Object Patition2 Object

Illegal Execute ParOS API

Call ParOS API

サブグループ C Language API システムを開始・停止する API 自パーティションを開始・停止する API データグループを操作する API スケジューリングモードを変更する API アトミックハンドラを実行する API 例外を発生させる API タイムウィンドウハンドラを操作する API システム割込みハンドラを操作する API 状態を参照する API StartSystem(void) ○ - - - - ShutdownSystem(void) ○ - - - - StartPartition(ID parid) - ○ - - - - ShutDownPartition(ID parid) - ○ - - - - InitDataGroup(ID dgid, ATR init_atr) - - ○ - - - - ChangeSchedulingMode(ID schmid, ATR schmatr) - - - ○ - - - - - CallAtomicHandler(ID athid) - - - - ○ - - - - RaiseSoftwareException(SWERNO swerno); - - - ○ - - - StartTWCyclicHandler(ID twcycid) - - - ○ - - StopTWCyclicHandler(ID twcycid) - - - ○ - - StartTWAlarmHandler(ID twalmid, uint_t twalmcnt) - - - ○ - - StopTWAlarmHandler(ID twalmid) - - - ○ - - EndSystemInterruptHandler(); - - - ○ - GetSystemState(T_SSTATE *pk_sstate) - - - ○ GetPartitionState(ID parid, T_PSTATE *pk_pstate) - - - ○ GetExceptionInformation(T_EXCINFO pk_excinfo); - - - ○ RefTWCyclicHandler(ID twcycid, T_RTWCYC - - - ○

■弊社が共同研究開発したパーティションOSの APIマッピングの例（一部抜粋）

■弊社が共同研究開発したパーティションOSの機能ブロック図の例（一部抜粋）

(85)

【弊社事例】安全分析実施方法の明確化

＜認証機関指摘事項＞

以下の情報を明確にする必要がある。

・安全分析や，それを実施するための基本的な手続

きを実施するチームのステートメント

・分析に関係していたチームメンバーのリスト

・分析の種類（例えば、FMEA、レビュー、ウォークス

ルー、インスペクション、...）についての情報

・入力（分析に関連する文書）と安全分析の出力（例

えば、FMEA、レビュー記録、議事録、...）についての

情報

＜対策方針例＞

・詳細な「安全分析ガイドライン」「安全分析計

画書」を作成

1 はじめに 1.1 本ドキュメントの目的 1.2 関連文書 2 分析計画 2.1 分析の目的 2.2 分析対象 2.3 分析手順 3 分析メンバー 3.1 メンバーの役割 3.2 メンバーリスト 4 分析準備 4.1 ParOSの機能グループと分析対象 4.1.1 機能グループの定義 4.1.2 分析対象とする機能グループの定義 4.1.3 分析対象となるAPI 4.2 各グループ詳細 4.3 ガイドワード 4.3.1 ParOS機能のガイドワード 4.3.2 COM機能のガイドワード 4.4 考慮すべき故障 4.5 考慮すべき影響 4.6 考慮すべき対策 4.7 考慮すべき原因 4.8 HAZOPシートテンプレート 5 分析活動 6 分析結果詳細 7 内部レビュー 8 インスペクションレビュー

「安全分析計画書」（全

79ページ）

の目次