Comments
Description
Transcript
ソフトウェア機能安全 F＆Q ポイント集 - RT-net
1/4 Confidential 1/4 機能安全に関する技術検討会・後期・ソフトウェア編 F&Q ポイント集 生活支援ロボット実用化プロジェクト 機能安全検討WG 質問 回答 参照 スライド (１) IEC 61508の概略 IEC 61508 は総意規格(concensus standard)であるので、 1 他の規格が変わるとこの規格も変わるのか。 IEC 61508のカバーしている範囲は、広いのか？機械制御や 2 交通業界でも使用される。 3 IEC61508はコンポーネントのみには使えないのか。 総意で作られた規格であるが、独立した規格いるので他が変わって 11,12 も影響されることは無い。 機械制御(ISO13849-1)や交通業界(IEC62278)でも使用され、更に 16,17 電気制御(IEC62061)や自動車(ISO262602)などへも適用されてい コンポーネントのみにも適応可。 15 ISO26262は車業界の安全規格で IEC61508基本安全規格に基づ 26262-10 4 ISO26262はIEC 61508 と同じようなプロセスを共有するか？ いている。 ISO 26262はIEC61508 が持つ異なる安全機能モデルの代わりに安 26262-10 5 ISO 26262への適用はどういう形か？ 全ゴールや安全概念を用いる。 IEC61508はノーマティブ(要求事項)とインフォーマティブ(ガイドライ 18 6 IEC61508の定める内容はどういう考え方か？ ン)の両部分を有する。 HSE(イギリス安全衛生庁)に依る産業事故ケースの分類で多い HSE研究によると仕様問題が基で起きた事故は全体の44%に達して 19 7 のは何か? いる。2番目は導入後の変更で22%となっている。 背景と用語定義 (2) IEC61508のED2では、セキュリティの脅威が考えられるときは、IEC IEC61508ではセキュリティの脅威に対し、どう取り組んでいる 62443(all parts), Industrial communication networks – Network and 26,27 8 か？ system securityに従って対応するとしている。 低頻度作動要求モードの故障確率(Probability of Failure on 10 9 PFDの意味は？ Demand)か又は危険側故障確率(Probability of Dangerous Failure) PLLはIEC61508ではフェーズロックドループ(Phase Locked PLLは、機能安全では人名損失確率(Probability of Loss of Life)で 10 10 Loop：電子回路などで使用される周波数を固定する回路方式) ある。 SFF は安全故障割合(Safe Failure Fraction)を意味する。ＳＦＦ=(λ 10 11 SFFの意味は？ Ｓ＋λＤＤ)/( λＳ＋λＤ) (全故障) 安全系(Safety Related System)又は安全要求仕様(Safety 10 12 SRSは２つの用語の略である。何か？ Requirements Specification) 主目的は安全管理システムを構築し、適切な技術要求事項を確証 20 13 IEC61508 の対処の主目的は何か？ し、資格ある要員を確証することにより事故原因に対処することであ 14 IEC61508認証対象は何か？ プロダクトレベルとプロセスに与えられる。 21 プルーフテストは手起動テストでSIF(Safety Instrumented Function：安全実装機能) 又はSIS(Safety Instrumented プルーフテストの定義は正しいが、現実ではプルーフテストは全て 44 15 System：安全実装系)の故障を検知することを目的とする。プ の故障を検知することはできない。 ルーフテストは全ての故障を検知しなくてはならないのか。 SIL決定に関し運用モード(エンドユーザー、契約者の使用)は CCF(共通原因故障)のスコア表には運用や環境の評価が盛り込ま 45 16 なんらの影響も与えない。 れている。 ソフトウェアのよる自己診断によって危険側故障の検出ができるの ソフトウェアは危険側故障確率は、低頻度作動要求モードであ で、検出できない危険側故障確率を減らすことができる。低頻度作 53,54 17 ろうが高頻度作動要求モード、連続モードであろうがSILレベル 動要求モードでもが高頻度作動要求モード、連続モードでもSILレ には影響を与えないか？ ベルに影響を与える。 低頻度作動要求モード及び高頻度作動要求モード、連続モー 高頻度作動要求モード、連続モードの危険側故障率は低頻度作動 53,54 18 ドに対するSIL要求事項のうち、危険側故障確率は同じか？ 要求モードに比較して約10,000倍厳しい。 ランダム故障ではない。これはJIS C508 に、決定論的原因故障と訳 56 19 Systematic Failureはシステムのランダム故障を意味するか？ されており、ランダム故障ではないことが日本語でも明白。 SILはシステム故障を低減させるためにも役立つ。しかし定量解析は 20 SILはランダム故障に対してのみ与えられるのか？ ランダム故障のみに用いられる。決定論的故障の場合はSILに応じ 55,57 た技法が推奨される。 21 IEC61508の定量解析はランダム故障のみに当てはまるのか？ IEC61508の定量解析はランダム故障のみに当てはまる。 22 23 24 25 26 27 (3) 28 危険側に故障する(Fail Danger)とは設計者が安全機能を実装 することを怠ったことを意味するのか？ 故障は、危険側故障と、安全側故障の2つの状態か？ 診断テスト間隔はオンライン及びオフラインテストに対して定義 されているのか？ IEC61508規格中のRecommendedとは推奨を意味し、強制的で はないのか？ IEC61508規格中のHighly Recommendedとは非常に推奨 することを意味し、強制的ではないのか。 IEC61508規格中のNot recommendedとは使わない方が いいという意味であるが、強制的ではないのか。 全安全ライフサイクルの計画プロセス SIF(安全関連機:Safety Instrumented Function) 又は SIS(安全 関連系:Safety Instrumented System) は,認証を受けるには常 に診断を伴うソフトウェアが必要なのか？ 危険側に故障するとは、機器や要素の部品がランダム故障した時、 危険状態になると言う意味である。 更に無影響(故障)、決定論的故障がある。 60 診断テスト間隔はオンラインで定義されている。 67 正しい、但し、やらなければその理由を明記する。 68 強制である。 68 NRとはいかなる環境下でも使ってはならない。 68 診断は、ハードウェアのみで行っての良いし、ソフトウェアと協調して も良い。例えば、マイコンの立ち上げる前の電源異常診断は、ソフト ウェアが始動していないので、ハードウェアで行うことになる。 60 2/4 Confidential 2/4 ソフトウェアもハードウェアも計画プロセスを経て設計することが規定 ソフトウェア設計は常に細かなコントロールを伴う。このような現 されている。計画と違ったこと(変更追加)が調整段階で発生したら、 発生の理由を明確にし、計画段階に戻り、変更追加の影響範囲を 29 状に合わせて、下からの積み上げ(ボトムアップ)設計が 明確にし、文書変更が必要と判断すれば、文書を変更し、責任者の IEC61508では許されているか？ 許可の元に変更追加を実施する。 SILの決定はハードウェアとソフトウェアの構造が決まった後で 目標のSIL決定は、安全要求事項の解析に基づいてなされる。構造 30 なされるのか？ 選択･決定はプロジェクトの実装段階でなされる。 潜在危険及びリスク解析はソフトウェアの詳細設計・実装後に 安全要求事項の解析段階で行われる。 31 なされるのか？ 安全要求事項の解析により、ハードウェア、ソフトウェアの割り付けを 32 ソフトウェア安全要求仕様は概念設計直後に行われるか？ 行った時、ソフトウェアの安全要求仕様が決められる。 多くの要素がSFFに影響を及ぼす(構造、FITS、コンポーネント選 33 自動診断テストのみがSFFを影響するのか？ 択、自己テスト、複雑性等)。 Proven-In-Use(使用実績)はシステムレベルに適応されるが、 下部レベルのコンポーネントにも適応されるが、下部レベルが低い 34 それのみとは限らないのか？ PIU(Proven-In-Use)システムの場合は、それによって影響される。 目標SILが提案されている設計を満足しているか、PFD,PFH値、SIL 35 SIF 適合確認タスクは、何を行うか？ に対応したアーキテクチャ適合性、IEC61508で認証された要素でシ ステム能力が十分かなどが解析、検証される。 低頻度作動要求モード運用と高頻度作動要求モード、連続モード 36 プルーフテスト間隔はSFFに影響を及ぼすか？ 運用の多数決方式のものに影響する。 改修が必ずしも安全機能に影響するとはいえない。インパクト解析 認証後、ソフトウェアのどのような改修も再認証が必要である で安全がいかに影響されるか調べる。影響が軽微か影響しない場 37 か？ 合は申告だけで済むことがある。 (4) 安全ライフサイク ソフトウェアライフサイクルは主に製品実装段階に関して考慮さ 解析及び運用段階も含む。 38 れているか？ 39 93,94 92 94-97 49,101 90-94 ソフトウェア要求事項の割当ては安全要求事項作成の一部の ソフトウェア要求事項の割当ては安全要求事項作成の一部の作業 7, 130,160 作業として行われるか？ として行われる。割り当ては、ハードウェアに対しても行われる。 40 IEC61508によるとライフサイクルには3つの主な段階がある。 41 システム安全ライフサイクルは反復しないプロセスか？ 解析、実現、運用･保守段階がある。 反復する(前後する)プロセスである。ある段階で改修が起きれば、そ の改修は解析段階の要求事項に対してチェックされねばならない。 PDCAを常に回していく。 93 (5) 製品開発 42 必ずしも必要だといえない。全ての改修は文書化されねばならない 製品のどのようなソフトウェアの変更でも安全マニュアルに記述 が、改修が安全マニュアルに必ずしも影響するとは限らない場合、 しなければならないのか？ 文書化は内部に留まるかもしれない。特に安全運用に関わることは 使用者が知る必要があるので文書化が望ましい。 43 SIL 3 以上の認証に対しては、ソフトウェアの文書化は、SRS、モ SIL 3 以上の認証に対しては、ソフトウェアの文書化は、どう考 ジュール仕様書、検証文書など、厳格なものが要求される。特に えればよいか？ 前、後方向のトレーサビリティは明確になっていることが望ましい。 44 ソフトウェア安全要求事項はどの段階で作成され検査される か？ 45 ソフトウェア妥当性確認テスト計画は詳細設計がなされた後に 安全要求事項の割り当ての後、ソフトウェア妥当性確認テスト計画が 作成されるのか？ 作られる。詳細設計は妥当性確認を行うことを前提に作られる。 ソフトウェア妥当性確認テスト計画はどこまで考えれば良い か？ ソフトウェアの妥当性確認テスト一つでいくつもの安全要求事 47 項をカバーできるか？ システム構造でのプロセスは順序だって進められねばならない 48 か？ ソフトウェアのHAZOPやクリティカル性解析はソフトウェアの実 49 装後に行われるべきである。 46 ソフトウェア安全要求事項は解析段階で作成され検査される。 ソフトウェア妥当性確認テスト計画はソフトウェア要求の各々をカ バーしなければならない。 正しいけれども、これが通常のケースとしてどのテストも複数の要求 事項をテストするべきではない。 システム構造でのプロセスは順序だって進められねばならないが、 他のステップからの又は他のステップへの影響で反復されてもい これらの解析は、ソフトウェア要求事項の解析段階で行われる。 手書きの議事録とかスプレッドシートとかemailでも検討課題やアク IEC61508はソフトウェアの設計検討会議を正式なレポート形式 50 ション事項を要約し記録がトレーサブルである限り許されている。 で記録しなくてはならないか？ チェックリスト付きの雛形があればなおさら良い。(技法や対策を参 (6) 安全要求事項 SIL2以下の認証ではソフトウェア安全要求事項と構造間のト トレーサビリティは推奨されているのでトレーサビリティが無ければ、 51 レーサビリティは必要とされていないか？ トレーサビリティが無い正統性を提供しなければならない。 安全要求事項は安全機能や安全度水準の要求事項を含まね 安全要求事項は安全機能や安全度水準の要求事項を含む。 52 ばならないか。 安全機能の一例として、容器の温度がYを超えればモーターX 安全要求事項から箇条書きのように安全機能の要旨を決めていく。 53 を止めるといった記述で良いのか？ 安全機能の一例として、持上げ用のモーターの重量がYを超え 安全機能の一例として、持上げ用のモーターの重量がYを超えれば 54 ればアラームを鳴らしモーターXを止めるといった記述では不 アラームを鳴らしモーターXを止めるといった記述でよい。要求事項 十分であるか？ をもれなく、簡易な文章で書き出していく。 製品開発に対し、SILレベルとは次のことを意味する。構造制約、 55 製品開発に対し、SILレベルとは何を意味するか？ PFD、PFH、プロセス又はProven-In-Use、及び故障を検知するため 111 113,114 115 115 117 119 121 129 129 129 3/4 Confidential 3/4 一つのソフトウェア製品で多くの用途をカバーするための方策 56 のひとつとして、いろいろなアプリに対しそれぞれ異なった意味 に解釈できるようなソフトウェア安全要求事項を作ると良いか？ ある安全要求をどのようにテストするかは設計やコードがある程 57 度固まってから考慮すべきか？ 安全機能の記述には手動のオフライン診断機能は含まれるべ 58 きか？ (7) 安全妥当性確認テスト計画 妥当性確認テスト計画は二度手間を避けるために詳細設計が 59 行われてから作成しても良いか？ 妥当性確認は、要求事項によっては実際のテストをしなくても 60 良いか？ 安全妥当性計画は設計次第なので、作成しなくても良い場合 61 があるのか？ 妥当性確認計画の検討手段の一つとしては議事録と共に記録 62 されたようなチェックリストは認められるか？ 妥当性計画作成後は安全要求仕様には手を入れてはいけな 63 いか？ (8) 開発 オペレーティングシステム(OS)の選択により構造設計が左右さ 64 れるか？ ハードウェアとは異なり、ソフトウエアは一貫性を保つためにで 65 きるだけ一人で大きなファイルを作った方がいいとされるが、機 能安全ではどうか？ 66 データフロー図やブロック図は、セミフォーマル方法で IEC61508で非常に薦められて(HR)いるか？ 67 FMEAはボトムアップ設計であるのでソフトウェアには関係が無 いのか？ 68 FMEAのソフトウェアにおける役割はなにか？ 69 70 71 72 73 (9) 74 75 76 77 78 79 80 81 統合テスト計画のハードウェアとソフトウェアの確証はどうなって いるか？ IEC61508によると、統合テスト計画と同じように計画されたテス トケースは、フォーマル(正式)にでもインフォーマルにでも文書 化しても良いか？ 安全マニュアルはエンドユーザーに使われるので設計に対し ての入力情報を提供するものなのか？ FMEDAはFMEAと似ているが、ハードウェアの解析にのみ使わ れるのでソフトウェアには依存しないか？ FMEDAとFMEAの関係は？ ソフトウェア技法 どんなSILレベルに対しても、IEC61508はトップレベルの設計 (要求仕様に基づくコンセプト設計のレベル)のみをセミフォーマ ルな方法で文書化することを推奨しているか？ プログラムフローコントロールはSIL3以上のプログラムのみで必 要とされている方法か？ 安全バッグ技法は航空機業界で使われ始めたため、それ以外 の業界ではあまり使われていない。 ソフトウェアはできるだけ汎用性を持たせない方が良い。また、ソー スコードも短くし、1つの要素機能で1つのソフトウェアモジュールす るのが良い。汎用的の場合、インパクトの検証が難しくなる。 安全要求のテストは、計画段階で決め、テスト方法を考慮して設計 やコードを決める。 安全機能の記述にはプロセスが作動中でない時に手動で行われる オフラインテストも診断機能も含む。 詳細設計前に安全機能の各々に対し、ハイレベルのテスト目標を作 成し検査しなければならない。 要求事項によっては実際のテストではなく、解析や統計で妥当性を 確認することができる。 安全妥当性計画は設計のやり方に関わらず作成されねばならな い。 妥当性確認計画の検討手段の一つとしては、議事録と共に記録さ れたようなチェックリストでもよい。 安全要求事項と妥当性確認計画は変更を鑑み反復できる。変更が あった時は前後し仕様にも変更を行う。 135 136 142 143 143 144 146 オペレーティングシステム(OS)によってはメモリー空間やアドレスス ペースを厳密に隔離し、リソースを保障するものもある。 ソフトウエアは、単一機能ごとに小さくし、ソフトウェアの構造を複雑 のしないようにする。 例えば、IEC61508-3のTable A.4 – Software design and development detailed designでは、SIL2,3において、HRとなってい る。また、セミフフォーマルの方法は、Table B.7 – Semi-formal ソフトウェアのFMEAが推奨されている。これは、あるソフトウェアモ ジュールの順序が変わったり、無くなったしたことを想定して、どのよ うな危険が起きるかを検討する。これによって、ソフトウェアモジュー ルの重大性がわかる。 FMEAは設計欠陥を見出す可能性があり、それによりソフトウェアの 安全要求事項変更を余儀なくさせる可能性がある。 統合テスト計画はハードウェアとソフトウェアが適切には相互に働く ことを確証しなければならない。 計画は必ずフォーマルに文書化されなければならない。IEC61508 は計画されたテストケースやその結果を統合計画と共にフォーマル に文書化することを要求する。 安全マニュアルは設計からの出力である。IEC 61508 で認証された 製品の各々は安全マニュアルが必要 FMEDAは診断カバレージを記入する行があり、診断は、しばしばソ フトウェアによって提供される。 FMEDAはFMEAの拡張されたものであるのでFMEAの結果を使う。 IEC61508では、トップレベルの設計に対し、セミフォーマルな方法で 文書化することを推奨するが、それより下の詳細レベルのどこまでセ ミフォーマル方法を使うかの定義はない。 エラー検出の方法としてプログラムフローコントロール及び診断はす べてのSILレベルでの必要事項である。 伝統的な方法でプロセスを別の安全系で監視するものである。 IEC61508-7ED2からは説明が削除された。 CRCの適切さや効果はCRCの長さ(保護されるメモリーのサイズ)と使 CRCの適切さや効果はどのようなものか？ われるCRCポリノミアル(多項式：polynomial)による。 フレッチャー・チェックサムはCRCより速く計算できるが、エラー検知 16 ビットのフレッチャーチェックサム(Fletcher’s Checksum)は、 はCRCほどではない。 フレッチャー・チェックサムは256バイト以上の CRCと同じように効果的であるか？ データブロックには使われるべきではない。 設計検討及び検査は適合確認プロセスの一部で文書化され 設計検討及び検査は適合確認プロセスの一部で文書化され、ト る。トレーサブルはどうか？ レーサブルでなければならない。 ソフトウェア HAZOP はソフトウェアモジュールや機能を厳しく解析 ソフトウェア HAZOPの働きはなにか？ するための形式を提供する。 必要なSILを取得するためには、コード規約が使われ、ツールが適 文書化されていればどのようなソフトウェアのツールでもC言語 切なものであることが必要である。ツールは製品の全ライフサイクル に使って良いか？ で使用できるものを考慮する。 82 アッセンブリー言語はどのように扱われるか？ 134 殆どのSILに対して、ハイレベルのソフトウェア言語を用いて実装す る方法がローレベルのアッセンブリー言語を使うより好まれている。 83 "increased confidence from use"として資格のあるツールは現 在は無いのか？ 84 Cはそれ全体ではSIL3以上のプロジェクトでの使用は推奨されてい SIL3以上の機能安全プロジェクトでStandard Cはプログラム言 ない。しかし、Cのサブセット、コード規約や静的解析ツールを使用 語として 推奨されているか。 すればどの段階でも推奨されている。 151 195 154 156 158 158 161 179 178-179 210 213 214 215… 216 221 227+ 235 238 Green Hills Compiler V4.x は資格がある。 257 4/4 Confidential 4/4 85 MISRA CはC言語に対する一連のルールであるか？ 86 どの組織でもIEC61508に準拠する限り固有のコード規約を 作ってよいか？ 87 ソフトウェアのソースコード規約には何が要求されているか？ 88 89 (11) 90 91 92 (11) 93 94 コーディング規約によると無条件ジャンプは使ってはならないと されている。また割込みにはどのような推奨があるか？ IEC61508はソースコードはテストできなければならないがコード 内のコメントはテストに影響しないので必ずしも必要ないとして いるか？ 文書化 ソフトウェアモジュール計画やテストは文書化されねばならない か？ インパクト解析はどんな安全関係改修にもされねばならない か？ プロジェクトの全ての関連文書は文書管理によって電子的に制 御されねばならないか？ 管理 機能安全の各々のプロジェクトはどのような人がプロジェクトに 指針を与えるか？ プロジェクトのSILレベルによりけりではあるが、一人の監査員が 設計、テスト、及び品質確証の全てを監視しても良いか？ C言語のコーディング規約であり、IEC61508準拠のソフトウェアをC 言語で開発時、この規約に準拠すれば、MISRA C準拠を検査する ツールが市販されている。 IEC61508に準拠する限り、コーディング規約は、各社で作成するこ とができる。各社の慣習に応じた、使用してはいけない記述方式、プ ログラムの長さなどが規定される。 コード規約(標準書)によるとソースコードには最小限次を含まねばな らない: 作者、説明、入出力や設定管理経歴とかの法的項目を含 260 275-277 276 割込みは設計を簡素化するためのみに使われるべきである。 277 ソースコードは読めて理解できなければならない。コメントは、各行 全てに付けるくらいにしなければならない。(例として他の技術者が コードを変更しなくてはならないかも知れない) 288 テストの計画と結果も文書化され、他の作業者が追跡テストできるこ と。 インパクトテストは、ソフトウェアの変更が及ぶ範囲をトレーサビリティ をチェックし、検証する。 電子的に制御されていれば更にいいが、電子的でなくても、紙、ファ イルによる管理でもよい。 機能安全の各々のプロジェクトは、外部のサービス要員に依頼して も良いし、資格のある内部の専門家がプロジェクトに指針を与えても 各々のプロジェクトに対し、監査責任の独立性が設計、テスト品質確 証のそれぞれに要求されている。 290 320 342 357