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

84
C 0508-7 : 2017 (IEC 61508-7 : 2010)
                    表C.1−個々のプログラミング言語に関する推奨事項(続き)
注記6 Javaは,実行時ガベージコレクタをもつように設計されている。ガベージコレクションを必要としない,Java
       サブセットを定義することもできる。一部のJava実装は,プログラムの実行時に空きメモリを回復する進歩
       したガベージコレクションを提供し,利用可能なメモリを使い切ってしまうまでは,一定期間,実行停止を
       しないものもある。厳格な実時間処理が必要なアプリケーションは,どんな形式であっても,ガベージコレ
       クションは用いないことが望ましい。
注記7 Java実装がJava中間コードの実行時インタプリタを必要とする場合,このインタプリタは,安全関連ソフト
       ウェアの一部として,JIS C 0508-3の要求事項に従って取り扱う必要がある。
注記8 項目1524は,IEC 61131-3を参照する。

参考文献

: Concepts in Programming Languages. J. C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985,
9780521780988
IEC 60880:2006,Nuclear power plants−Instrumentation and control systems important to safety−Software
aspects for computer-based systems performing category A functions
JIS B 3503:2012 プログラマブルコントローラ−プログラム言語
注記 対応国際規格 : IEC 61131-3:2003,Programmable controllers−Part 3: Programming languages
JIS X 3001-1:2009 プログラム言語Fortran−第1部 : 基底言語
注記 対応国際規格 : ISO/IEC 1539-1:2004,Information technology−Programming languages−Fortran
−Part 1: Base language
JIS X 3008:1994 プログラム言語Pascal
注記 対応国際規格 : ISO/IEC 7185:1990,Information technology−Programming languages−Pascal
ISO/IEC 8652:1995,information technology−Programming languages−Ada
JIS X 3010:2003 プログラム言語C
注記 対応国際規格 : ISO/IEC 9899:1999,Programming languages−C
ISO/IEC 10206:1991,Information technology−Programming languages−Extended Pascal
ISO/IEC 10514-1:1996,Information technology−Programming languages−Part 1: Modula-2, Base Language
ISO/IEC 10514-3:1998,Information technology−Programming languages−Part 3: Object Oriented Modula-2
JIS X 3014:2003 プログラム言語C++
注記 対応国際規格 : ISO/IEC 14882:2003,Programming languages−C++
ISO/IEC/TR 15942:2000,Information technology−Programming languages−Guide for the use of the Ada
programming language in high integrity systems
C.4.6 自動ソフトウェア生成
注記 この技術及び手法は,JIS C 0508-3の表A.2で引用されている。
目的 : ソフトウェア実装のエラーを起こしやすいタスクを自動化する。
説明 : システム設計は,従来の実行可能コードよりも抽象度が高い水準のモデル(実行可能仕様)によっ
て記述する。モデルは,コードジェネレータによって,自動的に実行可能な形式に変換する。目的
は,エラーを起こしやすい手動コーディングタスクを排除することで,ソフトウェアの品質を向上
させることである。さらに,より高い抽象度において,より複雑な設計を行うことができるという
潜在的便益もある。

参考文献

:

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

                                                                                             85
                                                                C 0508-7 : 2017 (IEC 61508-7 : 2010)
    Embedded Software Generation from System Level Design Languages, H Yu, R. Domer, D. Gajski. In
        “ASP-DAC 2004: Proceedings of the ASP-Dac 2004 Asia and South Pacific Design Automation
        Conference, 2004”, IEEE Circuits and Systems Society. IEEE, 2004, ISBN 0780381750, 9780780381759
    Transforming Process Algebra Models into UML State Machines: Bridging a Semantic Gap・. M.F. van Amstel
        et al. In Theory and Practice of Model Transformations: First International Conference, ICMT. ed. A.
        Vallecillo. Springer, 2008, ISBN 3540699260, 9783540699262
C.4.7 テスト管理及び自動化ツール
    注記 この技術及び手法は,JIS C 0508-3の表A.5で引用されている。
目的 : ソフトウェア及びシステムのテストに対する系統的及び綿密なアプローチを奨励する。
説明 : 適切な支援ツールを用いることで,システム開発における労働集約的でエラーを起こしやすいタス
      クを機械化し,テスト管理のための系統的アプローチの能力を提供する。支援が利用できることで,
      正規テスト及び回帰テストの両方について,より綿密なアプローチを促進する。

参考文献

: Managing the Testing Process: Practical Tools and Techniques for Managing Hardware and Software Testing.
R.Black, John Wiley and Sons, 2002, ISBN 0471223980, 9780471223986
C.5 適合確認及び部分改修
C.5.1 確率的テスト
注記 この技術及び手法は,JIS C 0508-3の表A.5,表C.15,表A.7及び表C.17で引用されている。
目的 : 調査したソフトウェアの信頼性特性についての定量的数値を得る。
説明 : この方法は,ソフトウェア信頼性の統計的推定値をもたらす。この定量的数値は,関係する信頼水
準及び重要度を考慮している場合があり,次の確率を与えることができる。
− 作動要求当たりの故障確率
− 定められた時間内での故障確率
− エラー抑制の確率
これらの数値から他のパラメータ,例えば,次のパラメータを導き出してもよい。
− 無故障で実行する確率
− 残存する確率
− 可用性
− MTBF又は故障率
− 安全な実行の確率
確率的考察は,確率的テスト又は運用実績のいずれかに基づく。通常,テストケース又は運用の
観察事例の数は非常に多い。一般に,作動要求モードは,連続モードに比べ,テストに要する時間
ははるかに短い。
テストデータを与えてテスト結果を監視するためには,通常,自動化されたテストツールを用い
る。大規模なテストは,適切なプロセスシミュレーション用の周辺機器をもつ大形のホストコンピ
ュータによって実行する。テストデータは,決定論的原因故障及びランダムハードウェア故障の両
方の視点によって選択する。テストの全体管理によって,例えば,テストデータプロフィールを保

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

86
C 0508-7 : 2017 (IEC 61508-7 : 2010)
      証する一方,ランダム選択によって,個々のテストケースを詳細に管理することができる。
        個々のテストハーネス,テスト実行及びテスト管理を,上記のように詳細なテスト目的によって
      決める。その他の重要な条件は,テスト評価が意図したテスト目的に適合する必要がある場合に,
      満たさなければならない数学的前提条件によって決める。
        テストオブジェクトの挙動についての確率的数値は,運用経験から導き出してもよい。同じ条件
      を満たしている場合,テスト結果の評価について同じ数学的技術を適用することができる。
        実際には,この技術を用いて極めて高い水準の信頼性を実証することは非常に困難である。

参考文献

: A discussion of statistical testing on a safety-related application. S Kuball, J H R May, Proc IMechE Vol. 221
Part O: J. Risk and Reliability, Institution of Mechanical Engineers, 2007
Estimating the Probability of Failure when Testing Reveals No Failures, W.K. Miller, L.J. Morell, et al.. IEEE
Transactions on Software Engineering, VOl. 18, NO.1, pp33-43, January 1992
Reliability estimation from appropriate testing of plant protection software, J. May, G. Hughes, A.D. Lunn. IEE
Software Engineering Journal, v10 n6 pp 206-218, Nov 1995 (ISSN: 0268-6961)
Validation of ultra high dependability for software based systems, B. Littlewood and L. Strigini. Comm. ACM
36 (11), 69-80, 1993
C.5.2 データの記録及び解析
注記 この技術及び手法は,JIS C 0508-3の表A.5及び表A.8(部分改修)で引用されている。
目的 : 適合確認,妥当性確認,評価及び保全を容易にするために,ソフトウェアプロジェクトにおける全
てのデータ,決定事項及び論理的根拠を文書化する。
説明 : 次の内容を含む詳細文書類を,プロジェクトの期間中維持管理する。
− 各ソフトウェアモジュールについて実施したテスト
− 決定事項及びその論理的根拠
− 問題及びその解決策
プロジェクトの期間中及び終了時に,この文書類を解析して様々な情報を導き出すことができる。
特に,開発プロジェクト中に下される決定事項の論理的根拠を保全技術者に常に知らせるとは限ら
ないため,データ記録はコンピュータシステムを保全するために非常に重要となる。

参考文献

: Dependability of Critical Computer Systems 2. F. J. Redmill, Elsevier Applied Science, 1989, ISBN ISBN
1851663819, 9781851663811
C.5.3 インタフェーステスト
注記 この技術及び手法は,JIS C 0508-3の表A.5で引用されている。
目的 : サブプログラムのインタフェースのエラーを検出する。
説明 : テストの詳細さ又は完全性に対する幾つかの水準は,実現可能である。次の事項に対するテスト
は,最も重要な水準である。
− 全てのインタフェース変数を,極端な値とする。
− 全てのインタフェース変数に対して,他のインタフェース変数を通常値としたまま,個別に極
端な値にする。

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

                                                                                             87
                                                                C 0508-7 : 2017 (IEC 61508-7 : 2010)
      − 各インタフェース変数に対して,他のインタフェース変数を通常値としたまま,変域の全ての
          値をとる。
      − 全ての変数と全ての値とを組み合わせる(これは小さなインタフェースに対してだけ実行可能
          である。)。
      − 各サブルーチンの各呼出しに関わる定めた条件でテストする。
        これらのテストは,正しくないパラメータ値を検出するアサーションをインタフェースが含まな
      い場合,特に重要である。これらのテストは,既存のサブプログラムの新しい構成を生成した後に
      おいて重要となる。
C.5.4 境界値解析
    注記 この技術及び手法は,JIS C 0508-3の表B.2,表B.3及び表B.8で引用されている。
目的 : パラメータの限界値又は境界で起こる,ソフトウェアエラーを検出する。
説明 : プログラムの入力領域は,等価関係によって,複数の入力クラスに分割できる(C.5.7を参照)。テ
      ストは,クラスの境界値及び極端な条件について実施することが望ましい。テストでは,仕様で定
      義する入力領域の境界値が,プログラムの境界値と一致することをチェックする。直接的及び間接
      的変換においてゼロ値を用いる場合,エラーを起こすことがよくあるので,次の点に特別な注意が
      必要である。
      − ゼロ除数
      − 空白ASCII文字
      − 空スタック又はリスト要素
      − フルマトリックス
      − ゼロ表項目
        通常,入力の境界値は,出力範囲の境界値に直接的に対応する。テストケースを,出力が限定さ
      れた値となるように設定することが望ましい。また,出力が仕様の境界値を超えるように,テスト
      ケースを指定することが可能かどうかを考慮する。
        出力が一連のデータ,例えば印刷された表である場合,最初及び最後の要素,並びに要素がゼロ,
      一つ又は二つの場合のリストには特に注意することが望ましい。

参考文献

: The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and
Sons, 2004, ISBN 0471469122, 9780471469124
C.5.5 エラー推定
注記 この技術及び手法は,JIS C 0508-3の表B.2及び表B.8で引用されている。
目的 : 一般的なプログラミングのミスを除去する。
説明 : テスト経験,知見に基づく直感及びテストするシステムについての興味から,設計したテストケー
スセットに,幾つかの区分されていないテストケースを加えてもよい。
特殊な値又は値の組合せは,エラーを起こしやすいことがある。幾つかの興味深いテストケース
を,検査チェックリストから導き出すことができる場合がある。これによって,システムが十分に
堅固であるかどうかを考慮することができる場合がある。このような例として,フロントパネル上
のボタンの押され方が速すぎたり,頻繁すぎたりしても大丈夫か,二つのボタンが同時に押された

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

88
C 0508-7 : 2017 (IEC 61508-7 : 2010)
      ら何が起こるか,などがある。

参考文献

: The Art of Software Testing, second edition. G. J. Myers, T. Badgett, T. M. Codd, C. Sandler, John Wiley and
Sons, 2004, ISBN 0471469122, 9780471469124
C.5.6 エラーシーディング
注記 この技術及び手法は,JIS C 0508-3の表B.2で引用されている。
目的 : 一連のテストケースが十分かどうかを確認する。
説明 : 幾つかの知られた種類の間違いをプログラムに挿入(シーディング)し,そのプログラムをテスト
条件によるテストケースによって実行する。シーディングしたエラーが幾つかしか発見できない場
合,そのテストケースセットは十分とはいえない。シーディングしたエラーの総数に対する,発見
したシーディングされたエラーの比率は,実際のエラー総数に対する発見した実際のエラーの比率
の推定値である。これによって,残存エラー数及びそのために残されたテストの作業量を推定する
ことができる(次式を参照。)。
NFS NFR
NS NR
ここに, NFS : 発見したシーディングエラー
NS : シーディングしたエラーの総数
NFR : 発見した実際のエラー
NR : 実際のエラー総数
シーディングした全てのエラーを発見した場合,そのテストケースセットが十分であること,又
はシーディングされたエラーがあまりにも発見しやすいものであったことを示す。この方法の限界
は,使用可能な結果を得るためには,間違いの種類及びシーディング位置が,実際のエラーの統計
的分布を反映するものでなければならないということである。

参考文献

: Software Fault Injection: Inoculating Programs Against Errors. J. Voas, G. McGraw. Wiley Computer Pub.,
1998, ISBN 0471183814, 9780471183815
Faluts, Injection Methods, and Fault Attacks. Chong Hee Kim, Jean-Jacques Quisquater, IEEE Design and Test
of Computers, vol. 24, no. 6, pp. 544-545, Nov., 2007
Fault seeding for software reliability model validation. A. Pasquini, E. De Agostino. Control Engineering
Practice, Volume 3, Issue 7, July 1995. Elsevier Science Ltd
C.5.7 同値クラス及び入力分割テスト
注記 この技術及び手法は,JIS C 0508-3の表B.2及び表B.3で引用されている。
目的 : 最小限のテストデータを用いて,ソフトウェアを十分にテストする。テストデータは,ソフトウェ
ア実行に必要な入力領域を分割した区画を選定することによって得ることができる。
説明 : このテスト戦略は,入力領域の一つの区画を決める,入力の同値関係に基づく。
テストケースを,あらかじめ規定した区画の全てをカバーするように選択する。一つ以上のテス
トケースを,各同値クラスから取り出す。
入力の区画を決めるためには,次の二つの基本的可能性がある。

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

次のページ PDF 91