iot ì æfþgig gcgtg10¿0£ /¡0 1 fÃ - ipa...2015/03/30 · 2015/3/30 iot ì æfþgig...

2015/3/30 IoT時代のセーフティとセキュリティ ©2015 WITZ Inc

IoT時代のセーフティとセキュリティ

「IoT時代のセーフティ設計技術解説」

2015年3月30日

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

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

株式会社アトリエ取締役

森川聡久

- 1 -

- 2 - ©2015 WITZ Inc 2015/3/30 IoT時代のセーフティとセキュリティ

本日の内容

IoT時代のシステム開発において必要となるセーフティ設計技術について、機能安全を中心に一部本質安全を含めて、実施すべき開発手順・分析手法・対処法などについて解説します。

＜目次＞

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

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

2. セーフティの分析・設計技術（H&R）

3. セーフティの分析・設計技術（機能安全）

4. セーフティの立証技術

5. ガイドブックのご紹介


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

- 3 -


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

【国内初】2010年4月：機能安全規格 IEC61508 SIL3対応ソフトウェアプロセス認証を取得

【世界初】2012年3月：自動車機能安全規格 ISO26262 ASIL-D（最高レベル）対応ソフトウェアプロセス認証を 4社同時取得（東芝 2社, パナソニック,ヴィッツ）その後、アイシン2社、自動車関連企業2社の取得支援成功！

IEC61508:1998 IEC61508:2010, ISO26262:2011

プロセス認証取得企業は、国内外で増加傾向にあり

※世界初は当社調べの限り


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

・平成22年度～24年度：3年間の活動・軽くて厳格な保護が可能な「ParOS」を、パーティションOSの決定版として、仕様策定から実装まで研究開発した。・上流レベルの「技術安全コンセプト」を国際認証機関TUV SUDにアセスメントしていただき、「complete評価」をいただいた。 ※アセスメント ≠ コンサル

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


主な機能安全支援実績 ※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支援プロジェクト実績：自動車

建設機械航空機

医療機器工作機械

他にも

鉄道、ガス機器、農業機械サービスロボット、などの対応実績もあるよ♪


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

• ①多分野・多企業への実開発支援によるノウハウの蓄積

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

– 延べ10プロジェクト以上、70回以上、 500h以上のミーティング経験

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

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

– 主な組込みセキュリティ活動 • 重要生活機器連携セキュリティ協議会（CCDS）

• サポイン3件

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


農機の標準通信規格・機能安全対応を促進する基盤ソフトの整備

欧米農機メーカー

標準通信規格

ISO 11783 / ISOBUS

機能安全規格

ISO 25119

2000年前後から対応

2010年頃から対応開始

国内農機メーカー

10年behind

5年behind

農機用次世代ソフト基盤

ISOBUS・機能安全対応ソフト基盤で競争力強化を支援

機能安全設計への形式手法適用、GSN・SafeMLの利用など予定

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


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

- 9 -


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

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 農業機械


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

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

抜粋元：サプライチェーン事業者の取組み事項整理 Safety & Security Part 1（2014年7月17日）


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

従来開発 ①壊れないモノ作り

・自己努力によって壊れにくいもの、バグゼロが目標・匠の技術で作られた高信頼性部品を使用

②日本流開発スタイル・担当者間の“すり合わせ開発”で、効率的に開発を進行・開発文書の出来栄えは不十分（必要最小限）

機能安全開発 ①壊れても安全なモノ作り

・高品質の証拠を積み重ねた開発によってバグゼロが目標・万が一構成部品が故障しても危険にならない「仕組み」が必要 ②安全説明力のある開発・PL訴訟時に安全を客観的に説明できる開発文書の作成やエビデンスが必要

安全性強化

不慣れな

開発スタイルへ

組込みシステムの複雑化による事故多発への対応として「実の安全性向上」と「PL訴訟対策」のため、機能安全は生まれた


機能安全対応製品の実現ステップ

品質管理システムの構築（CMMI, A-SPICE）

機能安全管理システムの構築（IEC 61508, ISO 26262, ISO 13849, etc）

コンセプト開発

機能安全開発・評価

プロセス構築プロセス改善・定着

安全目標の定義技術安全コンセプト構築

機能安全開発機能安全評価

・システム・HW ・SW

・規定・ガイドライン・テンプレ―ト・チェックリスト ×

プロセス構築・システム・HW ・SW

・規定・ガイドライン・テンプレ―ト・チェックリスト ×

プロセス改善・定着既存開発との

ギャップ診断

・H&R分析・目標SIL/ASIL決定

・安全コンセプト・安全マニュアル・安全要求仕様書・システム安全分析

・システム開発・V&V ・HW開発・V&V ・SW開発・V&V

・回路図の安全分析・SWアーキの安全分析

・SIL/ASIL故障率評価・機能安全監査

安全計画

機能安全対応製品

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


不明確な文書化基準

＜内容＞・正確・簡潔

・理解容易性・明白な構成

・保全性・内容が妥当

どう書けば「理解容易」なのか？

どう書けば「明白」と言えるのか？

どう書けば「簡潔」と言えるのか？

規格書の要求事項は非常に曖昧。合格基準がわからない・・・。そこで、「PL訴訟対策」という、もう１つの目的が重要になってくる。

注）規格書には「PL訴訟対策のため」とは載っていないので、「機能安全規格要求」と「PL訴訟対策」は別要求なのです。しかし、「PL訴訟対策のために機能安全に適合するのだから、PL訴訟で通用するエビデンスでなければならない」ことが、「暗黙の要求事項」になっている。


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

• 機能安全が求めること – 完全性・一貫性

• 開発・管理・運用に必要な情報が全て記載/記録されていること • 過不足・矛盾がない • あらゆる観点での検証（Verification）を実施して確認されていること

– 再現性＋客観性 • 再現/再検証できること

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

– 可読性＋客観性 • 同意の理解ができること（他者が見ても、数年後に見ても）

⇒ 誤解するような内容だと･･･・関連モジュールに不具合混入の恐れ・後のメンテで誤修正の恐れ

⇒ 再現できない内容だと･･･・安全であることを、客観的に確認できない

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

安全性を説明可能満たせば

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


機能安全だけでは安全なモノは作れない!!

・リスク低減プロセス（3ステップメソッド）

1. 本質的安全設計

2. 安全防護、付加保護方策（機能安全）

3. 使用上の情報

・開発だけでなく、運用時の対応も重要！

JIS B 9700-1 図１

機能安全は「安全策の一種」にすぎない！

さまざまな対策を打ってやっと「安全」なものができる。

まずは「機械安全」 ISO12100 （JIS B 9700）：機械類の安全性－設計のための一般原則－リスクアセスメント及びリスク低減が重要!!

リスクアセスメント

(機械の定義された制限及び”意図する

使用”に基づく)

設計者によって講じられる保護法策

ステップ1 本質的安全設計方策

ステップ2 安全防護及び

付加保護方策

ステップ3 使用上の情報

□ 機械に

－警告装置・信号

－警報装置

□ 取扱説明書に

設計者入力設計者によって講じられる

保護法策

設計者によって提供された使用上の情報に基づくものを含む

使用者入力

□ 組織

－安全作業手順

－監督－作業許可システム

□ 追加安全防護物の準備と

使用

□ 保護具の使用

□ 訓練等

リスク

設計者が保護方策を講じた後の

残留リスク

すべての保護方策を講じた後の

残留リスク


2. セーフティの分析・設計技術（H&R）

- 17 -


H&R vs 安全分析

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

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

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

– リスクを評価し、

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

– 安全策を検討する。

• 安全分析（機能安全）

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

– 電気系部位について、故障しても危険にならないことを確認する。


具体的イメージ例

①ハザード制御が暴走したら危険!! ②リスク評価 SIL2

③安全策「非常停止ボタン」を付けよう!!

④安全要求の定義「非常停止ボタン押下時に確実に停止すること（SIL2）」

ボタンマイコンリレー

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

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

ボタンマイコンリレー

＜安全設計＞

＜H&R＞

2重接点ボタンリレーの故障検出

WDT

＜安全分析＞

SIL2を満たす安全設計であることを確認する。

電源マイコンの故障検出


H&Rに必要な情報

リスク分析（H&R）

機械類の説明に関連する事項

法規制、規格及び他の適用可能な文書に関する事項

使用経験に関する事項

使用者の仕様

想定される機械類の仕様

全ライフサイクルの説明

設計図面

動力源及び供給方法

以前設計した類似の関連書類

使用上の情報

適用可能な法規制

関連する規格

関連する技術仕様

関連する安全データシート

事故履歴

インシデント履歴

機能不良履歴

エミッションの履歴

使用された化学物質の履歴

加工される材料による健康被害の履歴

関連する人間工学原則

人と機械のインタラクション

(操作ミスを誘発するようなもの

【例】ボタン配置、ハンドル操作方向など)

※参照：ISO12100


• 『機械が使用される目的・条件』を明確化するため、機械類の制限の決定を行う。

• 機械類の制限の例（JIS9700：2013／5.3項）を以下に示す。

機械類の制限の決定（H&R）

使用上の制限空間上の制限時間上の制限

機械の運転モード

その他の制限

機械の介入手順

性別

年齢

利き手の使用方法

身体能力の限界

使用者の訓練レベル

使用者の経験レベル

使用者の能力レベル

危険源の第3者への暴露

機械の可動範囲

運転及び保全のように機械に関わる人に対する

空間要求事項

機械類と人との係わり方

機械‐動力源間のインタフェース

機械類及び／又はコンポーネントの寿命

推奨点検修理間隔

加工材料の特性

清掃レベル

環境面

機械が使用される目的・条件

有効期限は何年か？どういう目的で使用される？使用者は、どういった条件を満たす必要があるか？設置のための条件は何か？



危険源の同定（H&R）

• 機械のライフサイクルの全局面（運搬、組立て及び設置、コミッショニング（立ち上げ、検収引渡し、移管）、使用、分解、利用停止、及び廃棄処分）における、合理的に予見可能な危険源、危険状態及び／又は危険事象を系統的に同定する。

• 危険源の同定に用いられる『分析手法』は、以下の通りである。 – JIS9700：2013に記載されていないが、JIS9702：2000（JIS9700：2013へ統合）に記載されている。

（HAZOPは記載されていない。）

– また、 ISO/TR 14121-2:2012にて、リスクアセスメントの各段階における数々の手法の実際的使用について示されている模様。（ ISO/TR 14121-2:2012 については、未調査）

帰納的手法両手法の使い分け演繹的手法

PHA（予備危険源分析） HAZOP（ハザード＆オペラビリティー調査） MOSAR法（系統的リスク分析のための組織化法）

ワット・イフ法 FTA（障害ツリー分析）

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

危険の同定

合理的予見可能な危険源危険状態危険事象



リスクの見積り

• 個々の危険状態に関連するリスクは、危害の発生確率と危害の酷さとの組合せで表される。以降のスライドに、見積り基準を示す。

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

＝（F + A + Ps） × S

以下の2点を考慮して、危害の酷さ（S）を求める。 ■障害又は健康障害の酷さ 1）軽度 2）重度 3）死亡 ■危害の範囲 1） 1人 2）複数人

以下の3点を考慮して、危害の発生確率（P）を求める。 ■人の危険源への暴露（危険源にさらすこと）（F） 1）危険区域への接近の必要性 2）接近の性質 3）危険区域内での経過時間 3）接近者の数 5）接近の頻度 ■危険事象の発生確率（Ps） 1）信頼性及び他の統計データ 2）事故履歴 3）健康障害履歴 4）リスク比較 ※ ■危害の回避又は制限の可能性（A） 1）危険源に暴露される様々な人 2）危険状態から危害に至る早さ 3）リスクの認知 4）危害の回避又は制限にかかる人の能力 5）実際の経験及び知識



リスクの大きさの決定

重篤度クラス暴露頻度クラス

回避性クラス

C1 C2 C2

S1 E1 QM QM QM

E2 QM QM QM

E3 QM QM A

E4 QM A B

S2 E1 QM QM QM

E2 QM QM A

E3 QM A B

E4 A B C

S3 E1 QM QM A

E2 QM A B

E3 A B C

E4 B C D

※参照：ISO26262-5 表4 ISO26262 ASILの場合


保護方策の種類

安全防護物

固定式ガード

可動式ガード

調整式ガード

インターロック付きガード

施錠式インターロック付きガード

起動機能インターロック付きガード

インターロック装置

イネーブル装置

ホールド・ツゥ・ラン制御装置

両手操作制御装置

検知保護装置

能動的光電保護装置

機械的拘束装置

制御装置

動作制限制御装置

ガード保護装置付加保護方策

非常停止装置

補足された人の脱出及び救助の

ための方策

遮断及びエネルギの消散に関す

る方策

設計者によって講じられる保護方策

保護方策

安全防護本質的安全設計方策使用上の情報

使用者によって講じられる保護方策本規格の対象外

ステップ1 ステップ2 ステップ3 ステップ2



3. セーフティの分析・設計技術（機能安全）

- 26 -


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

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

• 単一故障と多重故障 – IEC 61508では、単一故障のみ考慮

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

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

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

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

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

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

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

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

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


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

安全機能（これが故障すると

危険に直結）

安全策１（安全機能が故障していないことを監視）

②異常を検出 ⇒ フェールセーフ処理

①故障


危険に直結）

安全策１（安全機能が故障していないことを監視）

①先に故障

②後に故障 ⇒ 危険

a) 安全なケース

b) 危険なケース

対策例


危険に直結）

安全策１（安全機能と安全策２が故障していない

ことを監視）

安全策２（安全策１が故障していないことを監視）


安全分析が必要な工程

システム安全要求仕様工程

システムアーキテクチャ設計工程

安全コンセプト

ソフトウェア安全要求仕様工程

ソフトウェアアーキテクチャ設計工程

ソフトウェアモジュール設計工程

コーディング工程

ソフトウェアモジュールテスト工程

ソフトウェア統合テスト工程

ソフトウェア安全妥当性確認工程

システム統合テスト工程

システム安全妥当性確認工程

(HAZOP or FMEA) and/or FTA

ハードウェア安全要求仕様工程

回路設計

基板製作

HAZOP or FMEA

FMEDA

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


ASILと安全策の例（RAM故障対策） ISO26262-5

90%

99%

60%

99%

99%

99%

DC


ソフトウェアにおける安全の確保方法

故障モード主な安全策 ISO26262-5

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

RAM故障

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

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

Table D.6

CPUコア故障・レジスタのテスト

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

クロック故障・タイムウインド付きWDT Table D.10

内部バス故障検出・ウォーキングビットによるバス故障検出 Table D.14

ソフトウェアの誤動作・実行シーケンスモニタ＋WDT Table D.10

①厳密な機能安全プロセスでソフトウェアの開発を行う。

②システムレベルで導き出されたソフトウェアの技術的な安全策について、詳細レベルで十分であるかを確認する。不足している場合、新たな安全策を追加する。

ソフトウェアにおける主な安全策


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

ISO26262-6

＜従来開発＞テストがしっかり出ていてバグが無い。＜機能安全＞テストの完全性は不可能。バグが潜んでいることを前提に対処。


4. セーフティの立証技術

- 33 -


安全ケース（Safety case）

• 安全ケースとは、アイテムに対する安全要求が完全であり、かつ、満足されているということを、開発における安全活動の成果物からまとめたエビデンスによって主張すること

• 目的： – 安全ケースは、特定のコンテキストで運用されるシス

テムが、非合理的なリスクを伴わないということの、明確で包括的でディフェンス可能な（エビデンスに基づく）主張を伝える。

• 主要な3要素 – 要求事項 – アーギュメント – エビデンス

（第10部5.3「安全ケースの理解」より）

Safety Requirements & Objectives

Safety Evidence

Safety Argument

Safety Requirements & Objectives

Safety Evidence

Safety Argument


GSNでSafety Caseの目次を表現 • GSN ＝ Goal Structuring Notation

– 安全などの「主張」と、それを支持する「議論」の構造を表す図。

• Safety CaseのTOP（目次）をGSNで表す。 • GSNの末端のSolutionから、具体的な開発成果物へのリン

クを貼り、全ての成果物の紐付けを行う。

※抜粋元： http://www-users.cs.york.ac.uk/tpk/dsn2004.pdf

※注）実際は、あらゆる成果物が紐付くレベルの、詳細なGSNになる。


成果物一式でSafety Caseを主張

• その場合、 – 技術的なTOP文書：技術安全コンセプト – プロセスのTOP文書：機能安全対応プロセス規定／認証取得済プロセ

ス規定

• 各TOP文書からのトレースがとれていることが重要！！

実現（開発）フェーズ

コンセプトフェーズ

安全

技術的安全確保安全プロセス

低故障率部品部品の故障に

対する安全対策

機能安全プロセス実施

機能安全対応プロセス規定

ギャップ分析＆プロセス構築

機能安全開発

FMEDA

安全分析

SIL

達成評価

安全コンセプト

Validation

（妥当性確認）

AND

AND AND

AND

ランダムハードウェア故障への対策

決定論的原因故障への対策

機能安全監査

AND

Verification

（一致性検証）

全ての成果物＝SafetyCase

要件のトレーサビリティプロセスの

トレーサビリティ


【弊社事例】技術安全コンセプト４文書による立証

Safety Concept

（SC）

安全分析結果

安全要求仕様書（SRS）

Safety Manual （SM）

詳細を参照

仕様（SRS）・制約事項（SM）の下、安全であることを証明

安全であることの確認エビデンス

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

安全分析（詳細の検証）

技術安全コンセプト

の構築（安全証明）

ｼｽﾃﾑ

概要

想定

状況

安全

要件

安全

目標

安全分

析結果

SC(TSC)

SRS SM

仕様定義


「可読性」の向上～準形式手法～

ISO26262-6

IEC61508-3:2010

独自の図

フォーマットが決められた図（UMLなど）

形式記述

客観的に曖昧

明確詳細

ブロック間I/F シーケンスデータ

状態時間＋状態

通信条件

関連

従来：様々な観点で設計

機能安全：様々な観点をわかりやすく図示

機能安全では、準形式手法を推奨


要件のトレーサビリティ管理方法

• 要求番号の付与粒度は文章単位（認証機関指摘事項）

• 上流文書との紐付を手作業で実施する必要あり（膨大な作業量） – どんな優れたツールを用いても回避不可能！

※当社製機能安全RTOSの安全要求仕様書からの抜粋 ※赤字は要求番号

【NG事例】章番号単位で番号付与【OK事例】文章単位で番号付与


厳格なレビューの実施：レビューの種類

• ピアレビュー

– 作成した開発文書の中身に誤りが無いかを、同僚やチームメンバーがチェックすること。非公式レビューの一種。

– 第３者観点が欠落するため、開発時の思い込みミスや、非可読性に関する検出が弱い。

• ウォークスルー

– 開発文書の中身に誤りが無いかを、複数人で集まりチェックすること。公式レビューの一種。

– レビュア：開発の専門家、ターゲットシステムの専門家、品質の専門家、安全の専門家。

• インスペクション

• 開発文書の中身に誤りが無いかを、複数人でチェックすること。公式レビューの一種。

• レビュア：開発の専門家、ターゲットシステムの専門家、品質の専門家、安全の専門家。文書作成者は参加できない。

• 各レビューは事前レビューを実施する必要あり。

• 事前レビューと、合同レビューの２段階実施する。機能安全で要求される高い説明力が必要!!


レビューの完全性・各開発工程（アーキテクチャ設計工程、モジュール設計工程、実装、単体テスト、統合テスト、・・・）にてゲートが必要。・ゲートでは、厳密なレビューとエビデンス（記録）が必要。

レビュー内容が本当に正しいことを説明できる文書化が必要。（従来の指摘事項の記録だけではNG）

※当社の認証プロセスの例


トレーサビリティツール活用による効率化

①同時に複数文書間の内容を確認

③複数人のレビュ結果をマージし

インスペクションレビュー活用

影響分析も同様に実施

②そのままレビュー結果を記録

本ツールの画面：当社製トレーサビリティ管理ツール “Greyhound ” より平成21年度全国中小企業団体中央会試作開発等支援事業にて開発


5. ガイドブックのご紹介

- 44 -


ガイドブックのセーフティ設計関連目次（仮）

SEC BOOKS：品質向上のためのセーフティ＆セキュリティ設計の勧め（仮） ※ガイドブック発刊に向けて、IPA/SECにて現在取りまとめ中です。 ※下記目次は、サプライチェーンにおける品質の見える化WG検討資料より一部抜粋。

セーフティのためのソフトウェア設計セーフティ設計の開発プロセス

セーフティを考慮した設計とはセーフティを考慮したソフトウェア開発プロセス

セーフティ設計の手法 • ハザード＆リスク分析 • セーフティを実現するための技術

セーフティに有効な設計手法安全性を高める考え方

セーフティ設計の評価手法と認証 • セーフティ設計の妥当性確認 • 機能安全認証


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

本内容についてのご質問は下記にお願いします

株式会社ヴィッツ執行役員

機能安全開発部部長森川聡久

[email protected]

Tel: 052-220-1218

本内容の関連サイトもご覧ください。 ◎当社ホームページ：http://www.witz-inc.co.jp/ ◎TÜV SÜD による認証確認サイト： http://www.tuev-sued.de/industry_and_consumer_products/certificates （Search欄で、"Witz Corporation"と入力してください） ◎プロセス認証プレス発表記事日本経済新聞：http://release.nikkei.co.jp/detail.cfm?relID=306435&lindID=1 EDN：http://ednjapan.com/edn/articles/1203/29/news083.html Tech On!：http://techon.nikkeibp.co.jp/article/NEWS/20120329/210429/ パナソニック：http://panasonic.co.jp/corp/news/official.data/data.dir/jn120329-8/jn120329-8.html 東芝：http://www.toshiba.co.jp/about/press/2012_03/pr_j2901.htm iPROS：http://www.ipros.jp/news/article/detail/3649/ Response：http://response.jp/article/2012/03/30/172177.html Tech-On!（IEC61508）：http：//techon.nikkeibp.co.jp/article/NEWS/20100512/182502/

iot ì æfþgig gcgtg10¿0£ /¡0 1 fÃ - ipa...2015/03/30 · 2015/3/30 iot ì æfþgig...

Documents