JIS C 0508-7:2017 電気・電子・プログラマブル電子安全関連系の機能安全―第７部：技術及び手法の概観 | ページ 21

                                                                                             99
                                                                C 0508-7 : 2017 (IEC 61508-7 : 2010)
    Software Engineering. Ian Sommerville, Pearson Studium, 8. Auflage, 2007, ISBN 3827372577,
        9783827372574
    Software Configuration Management: Coordination for Team Productivity. W.A. Babich. Addison-Wesley, 1986,
        ISBN 0201101610, 9780201101614
    CMMI: guidelines for process integration and product improvement, Mary Beth Chrissis, Mike Konrad, Sandy
        Shrum, Addison-Wesley, 2003, ISBN 0321154967, 9780321154965
C.5.25 リグレッション妥当性確認
    注記 この技術及び手法は,JIS C 0508-3の表A.8で引用されている。
目的 : リグレッションテストから妥当な結論を導き出すことを確実にする。
説明 : 大きなシステム又は複雑なシステムのリグレッションテストは,通常,相当の労力及びリソースを
      必要とする。可能な場合は,リグレッションテストを,システム開発における時点で直接的に影響
      のあるシステム側面だけを対象とするように限定することが望ましい。この部分リグレッションテ
      ストでは,部分テストの範囲について明確に理解し,テストしたシステム状態について妥当な結論
      だけを導くことが重要である。

参考文献

参考文献

――――― [JIS C 0508-7 pdf 101] ―――――

100
C 0508-7 : 2017 (IEC 61508-7 : 2010)
目的 : システムモデルからの効率的で自動的なテストケース生成を容易にし,再現性の高いテスト一式を
      生成する。
説明 : モデルベーステスト(MBT)は,テストケース生成(TCG)及びテスト結果評価のような,共通テ
      ストタスクがテスト対象システム(アプリケーション)(SUT)のモデルに基づいているブラックボ
      ックスアプローチである。通常,システムデータ及び使用者挙動は,有限状態機械,マルコフ過程,
      判定表など(El-Far,2001,generalized)を利用してモデル化するだけにとどまらない。さらに,モ
      デルベーステストをソースコード水準のテストカバレッジ測定値と組み合わせることができ,機能
      モデルは既存のソースコードにベースをおくことができる。
        モデルベーステストは,システム要求事項及び規定の機能性のモデルを用いて,効率的なテスト
      ケース及び手順を自動的に生成することである(Software Tech,2009)。
        テストは非常にコストがかかるので,自動的テストケース生成ツールの需要が大きくなっている。
      したがって,モデルベーステストは,現在,非常に活発な研究分野になっており,利用可能なテス
      トケース生成(TCG)ツールが数多く生まれている。これらのツールは,通常,モデルの挙動部分
      からテスト一式を抽出しており,一定のカバレッジ要求事項を満たすことが保証されている。
        モデルは,テスト対象システム(SUT)の希望する挙動の抽象的な部分的表現である。このモデ
      ルからテストモデルを導き,抽象的なテスト一式を構築する。テストケースを,この抽象的なテス
      ト一式から導き,システムを基準として実行する。テストは,システムモデルを基準としても実行
      できる。テストケース生成(TCG)をもつモデルベーステスト(MBT)は,形式的手法の使用と強
      い関係をもっているので,推奨事項は,安全度水準(SIL)と同じものとなる。つまり,より高い
      SILに対してはHR(強く推奨する)となり,より低いSILに対しては不要となる。
        一般的な具体的な活動を,次に示す。
      − (システム要求事項からの)モデル構築
      − 期待インプットの生成
      − 期待アウトプットの生成
      − テスト実行
      − 実際のアウトプットと期待アウトプットとの比較
      − これ以上のアクション(モデル修正,更に多くのテストの生成,ソフトウェアの信頼性及び品
          質の推定)についての決定
        テストは,使用者及びシステム挙動のモデルを表現するため,様々な方法及び技術によって導く
      ことができる。次に例を示す。
      − 判定表の利用
      − 有限状態機械の利用
      − グラマーの利用
      − マルコフ連鎖モデルの利用
      − 状態図の利用
      − 定理証明
      − 制約論理プログラミング
      − モデルチェック
      − 記号実行
      − 事象フローモデルの利用

――――― [JIS C 0508-7 pdf 102] ―――――

                                                                                            101
                                                                C 0508-7 : 2017 (IEC 61508-7 : 2010)
      − リアクティブシステムテスト。並列階層有限オートマトンなど。
      − その他
        具体的には,モデルベーステストは,近年,安全クリティカル領域を目標としている。これによ
      って,仕様及び設計における曖昧な点を早期に明らかにし,複数の非反復的な効率のよいテストの
      自動的発生,リグレッションテスト一式の評価,並びにソフトウェア信頼性及び品質の評価に関す
      る能力を与え,テスト一式の更新を容易にする。
        徹底的な全体的検討をEI-Far(2001)及びSoftware Tech 2009で実施し,その他の詳細及び領域固
      有の問題点は他の文献で検討する(次の参考文献を参照)。

参考文献

――――― [JIS C 0508-7 pdf 103] ―――――

102
C 0508-7 : 2017 (IEC 61508-7 : 2010)
    注記 この技術及び手法は,JIS C 0508-3の表A.10及び表B.7で引用されている。
目的 : 明確で首尾一貫した仕様,並びに複雑な論理結合及び論理関係の解析を与える。
説明 : この方法では,ブールプログラムの真理値変数間の論理関係を簡潔に説明する2次元表を用いる。
        この方法は,簡潔さ及び表を用いるという特性から,コードで表現される複雑な論理結合の解析
      手法として適している。
        この方法は,仕様に対して適用可能である。
C.6.2 ソフトウェア潜在危険及び操作性の研究(CHAZOP,FMEA)
目的 : 提案した又は現存するシステムにおける安全上の潜在危険,これらの考えられる原因及び結果,並
      びにこれらの発生機会を最小限に抑えるための推奨手法を求める。
説明 : 設計の構造的調査には,スケジュールに従って開かれる一連の会議を通じて,考慮中のシステム全
      体に及ぶ専門知識をもつ技術者のチームが参加する。これらの技術者は,設計の機能面及びシステ
      ムが実際にどのように動作するか(人間の行動及び保全を含め)の両方について検討する。リーダ
      ーは,チームのメンバーに対して考えられる潜在危険を探り出すことに創造的であるように促し,
      システムの各部分を,幾つかの見出し語,すなわち,“なし”,“もっと多く”,“もっと少なく”,“の
      一部”,“より多く”(又は“と同様に”)及び“以外の”,と結合して示すことによって手順を進め
      る。全ての適用する条件又は故障モードは,それぞれ,その実行可能性,どのようにこれが起こる
      か,考えられる結果(潜在危険があるか),これをどのように回避できるか,及びその回避技術は
      費用に値する価値があるか,について検討する。
        潜在危険解析は,プロジェクト開発の多くの段階において実施することができるが,主要設計及
      び操作性の決定に影響を与えるのに十分間に合う早期に実施すると最も有効である。
        HAZOP技術はプロセス業界において発展してきたものであり,ソフトウェアアプリケーション
      の場合,部分改修が必要である。種々の派生方法[又はコンピュータHAZOP(“CHAZOP”)]が提
      案されており,これらは,一般に,システム及びソフトウェアアーキテクチャに系統的に適用する
      ために,新しい見出し語及び/又は枠組みを導入している。

参考文献

――――― [JIS C 0508-7 pdf 104] ―――――

                                                                                            103
                                                                C 0508-7 : 2017 (IEC 61508-7 : 2010)
      ある。これは,データの正しい処理を妨げようとする構成部品又はサブシステムのランダムハード
      ウェア故障を回避するためのものである。
        なお,故障によっては,複数の構成部品又はサブシステムに共通のものもある。例えば,システ
      ムが単一の部屋に据え付けられた場合,空気調節の欠点のために冗長性の利点が低減される可能性
      がある。同じことが,システムに及ぼす他の外部の影響,例えば,火災,洪水,電磁妨害,航空機
      の墜落及び地震についても言える。システムは,運用及び保全に関わる事象によっても影響を受け
      る場合がある。したがって,運用及び保全に関して,十分,かつ,明確に文書化した手順を作成し,
      運用要員及び保全要員を広範囲な知識にわたって訓練することが必須である。
        内的影響も,共通原因故障の主要な要因である。共通原因故障は,共通又は同一構成部品,及び
      これらのインタフェースの設計フォールト,並びに構成部品の老化によって起こる可能性がある。
      共通原因故障解析では,そのような潜在共通故障がないかどうか,システムを調査しなければなら
      ない。共通原因故障分析の方法としては,一般的な品質管理,デザインレビュー,独立チームによ
      る適合確認及びテスト,並びに同様なシステムから得た経験のフィードバックによる実際の事故解
      析がある。ただし,解析の範囲は,ハードウェアだけではない。冗長システムの幾つかのチャネル
      においてソフトウェア多様性を用いる場合であっても,ソフトウェアアプローチにおいて,共通原
      因故障,例えば,共通仕様のフォールト,を引き起こす可能性について何らかの共通性をもつこと
      がある。
        共通原因故障が全く同時には起こらない場合,ある故障が全てのチャネルに共通なものになる前
      にその故障を検出することを可能にするために,複数チャネル間の比較方法による予防措置を講じ
      ることができる。共通原因故障分析では,この技術を考慮に入れることが望ましい。

参考文献

参考文献

――――― [JIS C 0508-7 pdf 105] ―――――

次のページ PDF 106