この規格ページの目次
69
C 0508-7 : 2017 (IEC 61508-7 : 2010)
想定によって根拠を与えた能力の範囲を厳守して適用したことを確認する必要がある。
参考文献
: Component-Based Software Development: Case Studies. Kung-Kiu Lau. World Scientific, 2004, ISBN9812388281, 9789812388285
Software Reuse and Reverse Engineering in Practice. P. A. V. Hall (ed.), Chapman & Hall, 1992, ISBN
0-412-39980-6
Software criticality analysis of COTS/SOUP.P.Bishop, T.Clement, S.Guerra. In Reliability
Engineering & System Safety, Volume 81, Issue 3, September 2003, Elsevier Ltd., 2003
C.2.11 トレーサビリティ
目的 : ライフサイクル段階の間で整合性を維持する。
説明 : ライフサイクル活動から生まれたソフトウェアが,安全関連系の適切な運用に関する要求事項を確
実に満たせるように,ライフサイクル段階の間の整合性を確保することが重要である。ここでの重
要なコンセプトが,諸活動の間の“トレーサビリティ”という概念である。これは,基本的に,(1)
前段階で行った決定を後の段階で適切に実装しているか(前方トレーサビリティ),及び(2)後の
段階で行った決定が前段階の決定によって実際に必要かつ必須であるかを確認する影響解析であ
る。
前方トレーサビリティは,広い意味で,要求事項がライフサイクルの後の段階で適切に適応され
ているかをチェックすることである。前方トレーサビリティは,安全ライフサイクルの次の幾つか
の時点で役に立つ。
− システム安全要求事項から,ソフトウェア安全要求事項まで。
− ソフトウェア安全要求仕様から,ソフトウェアアーキテクチャまで。
− ソフトウェア安全要求仕様から,ソフトウェア設計まで。
− ソフトウェア設計仕様から,モジュール統合テスト仕様まで。
− ハードウェア又はソフトウェア統合に関するシステム及びソフトウェア設計要求事項から,ハ
ードウェア又はソフトウェア統合テスト仕様まで。
− ソフトウェア安全要求仕様から,ソフトウェア安全妥当性確認計画まで。
− ソフトウェア安全要求仕様から,ソフトウェア部分改修計画(再適合確認及び再妥当性確認を
含む。)まで。
− ソフトウェア設計仕様から,ソフトウェア適合確認(データ適合確認を含む。)計画まで。
− JIS C 0508-3の箇条8(機能安全評価)の要求事項から,ソフトウェア機能安全評価計画まで。
後方トレーサビリティは,広い意味で,全ての実装(広い状況で解釈して,コードの実装に限定
しない。)の決定が,相当の要求事項によって明確に根拠を与えていることをチェックすることであ
る。こうした根拠がない場合,実装は,安全関連系をより複雑化させる一方で,必ずしも真の要求
事項を適用していない不要なものが含まれる。後方トレーサビリティは,安全ライフサイクルの次
の幾つかの時点で役に立つ。
− 安全要求事項から,認識した安全ニーズ
− ソフトウェアアーキテクチャから,ソフトウェア安全要求仕様まで
− ソフトウェア詳細設計から,ソフトウェアアーキテクチャまで
− ソフトウェアコードから,ソフトウェア詳細設計まで
――――― [JIS C 0508-7 pdf 71] ―――――
70
C 0508-7 : 2017 (IEC 61508-7 : 2010)
− ソフトウェア安全妥当性確認計画から,ソフトウェア安全要求仕様まで
− ソフトウェア部分改修計画から,ソフトウェア安全要求仕様まで
− ソフトウェア適合確認(データ適合確認を含む。)計画から,ソフトウェア設計仕様まで
参考文献
: Requirements Engineering. E. Hull, K. Jackson, J. Dick. Springer, 2005, ISBN 1852338792, 9781852338794C.2.12 ステートレスソフトウェア設計(又は限定ステート設計)
注記 この技術及び手法は,JIS C 0508-3の表A.2で引用されている。
目的 : ソフトウェアの挙動の複雑さを制限する。
説明 : 一連のトランザクションを処理するソフトウェアプログラムを考える。つまり,これは一連の入力
を受け取り,各入力に応答して出力を生成する。プログラムは,その履歴の一部又は全部を“ステ
ート”の形で記憶し,将来の入力に対する応答方法を計算するときに,このステートを考慮に入れ
る場合がある。
特定の入力に対するプログラムの出力が,完全にこの入力によって決まる場合,プログラムは非
記憶,又はステートレスといわれる。各入力又は出力のトランザクションは,これ以前のトランザ
クションによって影響を受けず,かつ,特定の入力が必ずこれに伴った出力を生成するという意味
で,完成したものである。
これに対して,出力の計算においてプログラムがその特定の入力及び記憶しているステートの両
方を考慮する場合,異なる状況がことによって,同じ入力でも異なる出力を与えることがあるので,
プログラムはより複雑な挙動をする可能性がある。特定の入力に対する応答は,入力を受け取る状
況(すなわち,以前の入力及び出力)によって左右されることがある。一部のアプリケーション(特
に,通信)では,プログラムの挙動がステートの変化に対して非常に影響を受けやすいことがある
ので,これが不注意によるものか悪意をもって意図されたものかに関係なく,特に考慮する必要が
ある。
ステートレス(又は限定ステート)設計は,ソフトウェア設計でステート情報の利用を回避又は
最小限に抑えることでソフトウェア挙動の潜在的複雑さを最小限にしようとする一般的なアプロー
チである。
参考文献
: Introduction to Automata Theory, Languages, and Computation (3rd Edition). J. Hopcroft, R. Motwani, J.Ullman, Addison-Wesley Longman Publishing Co, 2006, ISBN: 0321462254
Stateless connections. T. Aura, P Nikander. In Proc International Conference on Information and
Communications Security (ICICS97), ed Yongfei Han. Springer, 1997, ISBN 354063696X,
9783540636960
C.2.13 オフライン数値解析
注記 この技術及び手法は,JIS C 0508-3の表A.9で引用されている。
目的 : 数値計算の正確さを確実にする。
説明 : 数値の不正確さは,理想的関数及び数値を有限表現した結果,数学的関数の計算の中で発生するこ
とがある。関数をフーリエ系列のような無限系列の有限項目数で近似化した場合,切捨て誤差が生
じる。実際のコンピュータにおいて,実数を有限的な正確さをもって表示した場合,丸め誤差が生
――――― [JIS C 0508-7 pdf 72] ―――――
71
C 0508-7 : 2017 (IEC 61508-7 : 2010)
じる。最も単純な計算以外のことを浮動小数点法で実行しようとする場合,計算の妥当性をチェッ
クして,アプリケーションが要求している正確さを実際に実現できることを確実にする必要がある。
参考文献
: Guide to Scientific Computing. P.R. Turner. CRC Press, 2001, ISBN 0849312426, 9780849312427C.2.14 メッセージシーケンスチャート
注記 この技術及び手法は,JIS C 0508-3の表B.7及び表C.17で引用されている。
目的 : 要求事項及びソフトウェアアーキテクチャ設計を含むソフトウェア開発の早い設計段階で,システ
ム要求事項を把握する支援をする。UML(C.3.12参照)では,この表記に対して,“システムシー
ケンス図”という名称を用いる。
説明 : メッセージシーケンスチャートは,システムのアクター(設計段階に応じて,アクターは,人,コ
ンピュータシステム又はソフトウェア要素若しくはオブジェクトに対するものでもよい。)の間で
起こる通信という点から,システムの挙動を記述する図式的記述である。各アクターについて,垂
直の“ライフライン”を図上に引き,ライフライン間で矢印をメッセージを表すために用いる。メ
ッセージを受領したときのアクションは,ボックスとして,図に任意に示すことができる。一連の
シナリオ(望ましい挙動及び望ましくない挙動の両方を記述したもの)をまとめて,必要なシステ
ム挙動の仕様とする。これらのシナリオは複数の用途をもつ。これらによって,エンドユーザに対
してシステム挙動を実演することができる。これらによって,システムの実行可能な実装に変換す
ることができる。これらによって,テストデータのベースを形成することができる。
UMLは,分岐シナリオ及びループシナリオを可能にし,これによって,表記をよりコンパクトに
するような選択及び反復などの構成要素の形で,メッセージシーケンスチャートの本来のコンセプ
トに対する拡張要素を含んでいる。サブ図式を定義することもでき,複数の上位シーケンス図から
参照できる。タイマ及び外部事象も表現することができる。
参考文献
: “Message Sequence charts”, D. Harel, P. Thiagarajan. In UML for Real: Design of Embedded Real-TimeSystems. ed. L. Lavagno. Springer, 2003, ISBN 1402075014, 9781402075018
JIS X 4170 オープン分散処理−統一モデル化言語(UML)1.4.2版
注記 対応国際規格 : ISO/IEC 19501:2005,Information technology−Open Distributed Processing−
Unified Modeling Language (UML) ersion 1.4.2
C.3 アーキテクチャ設計
C.3.1 フォールト検出
注記 この技術及び手法は,JIS C 0508-3の表A.2で引用されている。
目的 : 故障に至る可能性があるシステムのフォールトを検出し,故障の結果を最小限に抑えるための対策
の基礎を提供する。
説明 : フォールト検出は,あるシステムが[チェックの対象である(サブ)システム内のフォールトによ
って発生する]誤り状態になっていないかどうかを確認する活動である。フォールト検出の主な目
標は,正しくない結果の影響を阻止することである。並列要素と組になって動作し,自己の結果が
正しくないと検出したとき制御を放棄するシステムであるため,セルフチェックと呼ばれる。
――――― [JIS C 0508-7 pdf 73] ―――――
72
C 0508-7 : 2017 (IEC 61508-7 : 2010)
フォールト検出は,冗長性(主として,ハードウェアフォールトを検出する。JIS C 0508-2の附
属書Aを参照。)及び多様性(ソフトウェアフォールト)の原理に基づく。結果の正確さを判定す
るためには,ある種の票決が要求される。適用できる特殊な手法としては,アサーションプログラ
ミング,Nバージョンプログラミング及びダイバースモニタ技術がある。ハードウェア用には,追
加のセンサ,制御ループ,誤り検査コードなどを導入する。
フォールト検出は,異なる段階での値領域又は時間領域,特に,物理的(温度,電圧など),論理
的(誤り検出コード),機能的(アサーション)又は外部的(確からしさ確認),におけるチェック
によって行う。これらの確認の結果は格納しておき,故障追跡を可能とするために,影響を受ける
データと結び付けてもよい。
複雑なシステムは,サブシステムで構成する。フォールト検出,診断及びフォールト補償の効率
は,フォールトの伝ぱ(播)に影響を及ぼすサブシステム間の相互作用の複雑さによって異なる。
サブシステムが小さいほど,詳細なフォールト診断(誤り状態の検出)が可能となるため,フォ
ールト診断は最小サブシステム水準において適用することが望ましい。
企業規模の統合情報システムでは,診断テスト情報を含め,安全システムの状態を,定期的に,
他の管理システムへ送信することができる。異常を検出した場合,これを表示して,危険状態が増
大する前に是正手段を起動するために用いることができる。最後に,このような異常を文書化して
おくことによって,本当に事象が起こった場合に,その後の調査の手助けとすることができる。
参考文献
: Dependability of Critical Computer Systems 1. F. J. Redmill, Elsevier Applied Science, 1988, ISBN1-85166-203-0
C.3.2 エラー検出
注記 この技術及び手法は,JIS C 0508-3の表A.2で引用されている。
目的 : 影響を受けやすい情報のエラーを検出して訂正する。
説明 : nビットの情報に対して,r個のエラーを検出して訂正することを可能とする,kビットのコード化
ブロックを生成する。例として,ハミングコード及び多項コードの二つのタイプがある。
安全関連系において,あらかじめ定められた割合のエラーだけしか正しく訂正されないため,不
良データは,通常,訂正しようと試みるよりも廃棄することが必要になるということに留意するこ
とが望ましい。
参考文献
: Fundamentals of Error-correcting Codes, W. Huffman, V. Pless. Cambridge University Press, 2003, ISBN0521782805, 9780521782807
C.3.3 故障アサーションプログラミング
注記 この技術及び手法は,JIS C 0508-2の表A.17並びにJIS C 0508-3の表A.2及び表C.2で引用さ
れている。
目的 : システムの安全上,重大な故障を防止し,高い信頼性で運用を継続するために,プログラムの実行
中,残留するソフトウェア設計フォールトを検出する。
説明 : アサーションプログラミング手法は,事前条件をチェックし(一連のステートメントが実行される
前に,初期条件の妥当性をチェックする。),さらに,事後条件をチェックする(一連のステートメ
――――― [JIS C 0508-7 pdf 74] ―――――
73
C 0508-7 : 2017 (IEC 61508-7 : 2010)
ントを実行した後,結果をチェックする。)という概念に準拠している。事前条件又は事後条件の
いずれかが満たされない場合,処理はエラーを報告する。
例
アサート<事前条件>;
アクション1;
:
:
アクションx;
アサート<事後条件>;
参考文献
: Exploiting Traces in Program Analysis. A. Groce, R. Joshi. Lecture Notes in Computer Science vol 3920,Springer Berlin / Heidelberg, 2006, ISBN 978-3-540-33056-1
Software Development−A Rigorous Approach. C. B. Jones, Prentice-Hall, 1980
C.3.4 ダイバースモニタ
注記 この技術及び手法は,JIS C 0508-3の表A.2で引用されている。
目的 : 安全性に悪影響を及ぼす,ソフトウェアに残留する仕様上及び実装上のフォールトに対して保護す
る。
説明 : 監視は,次の2種類の手法に分けることができる。
1) 同一コンピュータ内で,監視対象となる機能とこれを監視する機能との間の独立性をある程度
保証している。
2) 監視機能と監視対象となる機能とが,個別のコンピュータにある。
ダイバースモニタは,別の仕様に従って独立したコンピュータ上に実装する外部モニタである。
このダイバースモニタは,主コンピュータに対して必ずしも正しくなくてもよいが,安全な動作を
確実にさせることだけに関心をもつ。ダイバースモニタは,主コンピュータを常時監視する。ダイ
バースモニタは,システムが潜在的に危険な状態になるのを防止する。さらに,モニタは主コンピ
ュータが潜在的に危険な状態になりつつあることを検出した場合には,ダイバースモニタ又は主コ
ンピュータのどちらかによって,システムを安全な状態に戻す必要がある。
ダイバースモニタのハードウェア及びソフトウェアは,適切なSILに従って分類し,認証を受け
ることが望ましい。
参考文献
: Requirements based Monitors for Real-Time Systems, D. Peters, D. Parnas. IEEE Transactions on SoftwareEngineering, vol. 28, no. 2, 2002
C.3.5 ソフトウェア多様性(ダイバースプログラミング)
注記 この技術及び手法は,JIS C 0508-3の表A.2で引用されている。
目的 : システムの安全上,重大な故障を防止し,高い信頼性で運用を継続するために,プログラムの実行
中,残留するソフトウェア設計フォールト及び実装フォールトを検出して,マスクする。
説明 : ダイバースプログラミングにおいては,規定したプログラム仕様を,異なる設計でN個実装する。
同じ入力値をN個のバージョンに与え,N個のバージョンが生成する結果を比較する。結果を妥当
――――― [JIS C 0508-7 pdf 75] ―――――
次のページ PDF 76
JIS C 0508-7:2017の引用国際規格 ISO 一覧
- IEC 61508-7:2010(IDT)
JIS C 0508-7:2017の国際規格 ICS 分類一覧
- 35 : 情報技術.事務機械 > 35.240 : 情報技術(IT)の応用 > 35.240.50 : 産業におけるITの応用
- 25 : 生産工学 > 25.040 : 産業オートメーションシステム > 25.040.40 : 工業計測及び制御
JIS C 0508-7:2017の関連規格と引用規格一覧
- 規格番号
- 規格名称