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

64
C 0508-7 : 2017 (IEC 61508-7 : 2010)
C.2.6.4 動的変数又は動的オブジェクト作成中のオンラインチェック
注記1 この技術及び手法は,JIS C 0508-3の表B.1で引用されている。
目的 : 動的変数及びオブジェクトに割り当てるメモリが,割当ての実行時に空きメモリであることを確認
し,実行時間中の動的変数及び動的オブジェクトの割当てが,既存の変数,データ又はコードに影
響を及ぼさないことをチェックする。
説明 : この手法の場合,動的変数は,実行時にメモリに割り当てられ,絶対アドレスが決まる変数である
(この意味での変数は,オブジェクトインスタンスの属性でもある。)。
動的変数又は動的オブジェクトをメモリに割り当てる前に,(例えば,スタックあふれを回避する
ため,)メモリが確実に空きメモリであることをハードウェア又はソフトウェアによってチェックす
る。割当てができない場合(例えば,割り当てるアドレスにおけるメモリが十分でない場合),適切
な処置が必要である。一つの動的変数又は動的オブジェクトを用いた後(例えば,サブルーチンを
出た後),その動的変数又は動的オブジェクトに割り当てた全てのメモリを開放する必要がある。
注記2 代替手法は,メモリが全ての場合において十分であることを統計的に実証することであ
る。
C.2.6.5 割込の制限使用
注記 この技術及び手法は,JIS C 0508-3の表B.1で引用されている。
目的 : ソフトウェアを適合確認可能及びテスト可能に維持する。
説明 : 割込の使用を,制限することが望ましい。割込は,システムを簡略化する場合に用いてもよい。ソ
フトウェアによる割込処理は,実行中の関数の重要な部分(例えば,タイムクリティカル,データ
変更にとってクリティカル)の間,禁止することが望ましい。割込を用いる場合は,割込を禁止す
る最大時間を計算できるように,割込可能でない部分の最大演算時間を規定することが望ましい。
割込の使用及びマスキングは,完全に文書化することが望ましい。
C.2.6.6 ポインタの制限使用
注記 この技術及び手法は,JIS C 0508-3の表B.1で引用されている。
目的 : ポインタの範囲及び型を最初にチェックせずに,データにアクセスすることによって起こる問題を
回避する。ソフトウェアのモジュラーテスト及び適合確認を支援し,故障の影響を制限する。
説明 : アプリケーションソフトウェアにおいて,ポインタ演算は,ポインタデータの型及び値の範囲が(ポ
インタ基準が正しいアドレス空間内にあることを確実にするために)アクセス前にチェックする場
合に限り,ソースコード水準において用いてもよい。アプリケーションソフトウェアのタスク間通
信は,タスク間の直接参照によって実施しないことが望ましい。データ交換は,オペレーティング
システムを経て実施することが望ましい。
C.2.6.7 再帰の制限使用
注記 この技術及び手法は,JIS C 0508-3の表B.1で引用されている。
目的 : サブルーチン呼出しの適合確認不可能かつテスト不可能な使用を避ける。
説明 : 再帰を用いる場合,再帰の深さを予測可能にする明確な基準が必要である。

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

                                                                                             65
C 0508-7 : 2017 (IEC 61508-7 : 2010)
C.2.7 構造化プログラミング
注記 この技術及び手法は,JIS C 0508-3の表A.4で引用されている。
目的 : 実用上,プログラムを実行せずに解析することが可能であるように,プログラムを設計及び実装す
る。プログラムは,統計的にテスト不可能な挙動を,絶対最小量だけ含んでもよい。
説明 : 構造上の複雑さを最小限に抑えるために,次の原則を適用することが望ましい。
− プログラムを適切に小さいソフトウェアモジュールに分割し,これらのモジュールはできるだ
け連結を断ち,全ての相互作用が明白であることを確実にする。
− 構造化構成体,すなわち,シーケンス,反復及び選択を用いてソフトウェアモジュール制御フ
ローを構成する。
− ソフトウェアモジュールを通過すると考えられる経路の数を小さく保ち,入力及び出力のパラ
メータの関係をできるだけ単純に保つ。
− 複雑な分岐を避け,特に,高水準言語における無条件ジャンプ(goto)は避ける。
− 可能な場合は,ループ制約及び分岐を入力パラメータに関係付ける。
− 分岐及びループ決定の基礎として複雑な計算を用いることを避ける。
上記のアプローチを支援するプログラミング言語の特徴は,効率が絶対優先である場合(例えば,
安全クリティカルシステム)を除き,更に効率的である(と主張できる)他の特徴に対して優先し
て用いることが望ましい。

参考文献

: Concepts in Programming Languages. J. C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985,
9780521780988
A Discipline of Programming. E. W. Dijkstra. Englewood Cliffs NJ, Prentice-Hall, 1976
C.2.8 情報隠蔽及びカプセル化
注記 この技術及び手法は,JIS C 0508-3の表B.9(モジュラーアプローチ)で引用されている。
目的 : データ又は手順への意図しないアクセスを防止し,これによって,良好なプログラム構造を支援す
る。
説明 : 全てのソフトウェア構成要素からの大域的なアクセスが可能なデータは,これらの要素のいずれか
が,不本意な又は不正な改変をする可能性がある。これらのデータ構造が変化した場合は,コード
の詳細な調査及び広範囲な部分改修が必要になる場合がある。
情報隠蔽は,このような困難を最小限に抑えるための一般的なアプローチである。重要なデータ
構造は“隠して”,定義済みの一連のアクセス手順によってだけ操作を可能とする。こうすることに
よって,残りのソフトウェアの機能的挙動に影響を及ぼすことなく,内部構造を部分改修すること
ができ,又は手順を更に追加することが許される。例えば,名前ディレクトリが,“挿入”,“削除”
及び“検索”というアクセス手順をもつとする。この場合,これらの手順を用いて,残っているソ
フトウェアの論理的挙動に影響を及ぼすことなく,(例えば,異なるルックアップ方法を用いるため
又はハードディスクに名前を格納するために)アクセス手順及び内部データ構造のプログラムを書
き換えることができる。
この関係においては,抽象データタイプの概念を用いることが望ましい。この概念の直接的支援
がない場合は,抽象化が不注意によって壊されていないことをチェックする必要があるかもしれな
い。

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

66
C 0508-7 : 2017 (IEC 61508-7 : 2010)

参考文献

: Concepts in Programming Languages. J. C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985,
9780521780988
On the Design and Development of Program Families. D. L. Parnas. IEEE Trans SE-2, March 1976
C.2.9 モジュラーアプローチ
注記 この技術及び手法は,JIS C 0508-3の表A.4及び表B.9で引用されている。
目的 : ソフトウェアシステムを,システムの複雑さを制限するために小さな理解できる部分に分解する。
説明 : モジュラーアプローチ又はモジュール化は,ソフトウェアプロジェクトの設計,コーディング及び
保全の各フェーズについての幾つかの規則を含む。これらの規則は,設計時に採用する設計方法に
よって異なる。ほとんどの方法は,次の規則を含む。
− 一つのソフトウェアモジュール(又は,同様に,サブプログラム)は,明確に定義した実行す
るタスク又は関数を一つだけもつことが望ましい。
− ソフトウェアモジュール間の接続は,制限し厳密に定義することが望ましく,一つのソフトウ
ェアモジュールの一貫性は強力でなければならない。
− サブプログラムの集合を作成し,この集合は幾つかの水準のソフトウェアモジュールを備える
ことが望ましい。
− サブプログラムのサイズは,ある規定値,典型的な値としては24スクリーンサイズに制限す
ることが望ましい。
− サブプログラムは,唯一の入口点及び唯一の出口点をもつことが望ましい。
− ソフトウェアモジュールは,インタフェースを介して他のソフトウェアモジュールと通信する
ことが望ましい。大域変数又は共通変数を用いる場合,これらを十分に構造化し,アクセスを
制御し,各インスタンスにおいて正当化して用いることが望ましい。
− ソフトウェアモジュールの全てのインタフェースは,完全に文書化することが望ましい。
− ソフトウェアモジュールのインタフェースは,この関数に必要なパラメータだけを含むことが
望ましい。ただし,この推奨事項は,プログラミング言語がデフォルトのパラメータをもつか,
又はオブジェクト指向アプローチを採用する可能性があるため,複雑になることがある。

参考文献

: 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
Software Engineering for Real-time Systems. J. E. Cooling, Pearson Education, 2003, ISBN 0201596202,
9780201596205
Concepts in Programming Languages. J. C. Mitchell. Cambridge University Press, 2003, ISBN 0521780985,
9780521780988
C.2.10 信頼性確認及び検証済みソフトウェア要素の使用
注記 この技術及び手法は,JIS C 0508-3の表A.2,表C.2,表A.4及び表C.4で引用されている。
目的 : ソフトウェア設計及び要素の,新しいアプリケーションごとの大幅な妥当性確認又は設計し直しが
必要になることを避ける。形式的又は厳格に検証されていないが,かなりの運用履歴がある設計を
活用する。別のアプリケーションで検証済みであり,多数の適合確認証拠がある既存のソフトウェ

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

                                                                                             67
C 0508-7 : 2017 (IEC 61508-7 : 2010)
ア要素を活用する。
説明 : この手法は,ソフトウェア要素が決定論的設計フォールト及び/又は運用上の故障がほとんどない
ことを検証するものである。
最も初歩的な部分から複雑なシステムを構築することは,一般に不可能である。一般には,既に
開発されて相当程度有用な機能を提供していて,更に新システムの相当部品の実装に再利用できる
ような主要サブアセンブリ(“要素”,JIS C 0508-4の3.4.5及び3.2.8参照)を利用することが必要
となる。
良好に設計され,構成されたPE系は,明確に区別ができて,明確に規定された方法で相互に作
用し合う幾つかのソフトウェア要素でできあがっている。このような,複数のアプリケーション内
で再利用することができる一般的に応用可能なソフトウェア要素のライブラリを構築することで,
複数のアプリケーションで共有できる設計の妥当性を確認するために必要な,多くの資源とするこ
とができる。ただし,安全関連アプリケーションの場合,これら既存の要素を組み込んだ新システ
ムが要求される安全度をもち,既存の要素の不正な挙動によって安全性が損なわれないという十分
な信頼性があることが重要である。
次の二つの観点によって,既存の要素の挙動が正確に分かっているという信頼性を得ることがで
きる。
− 要素の包括的な運用履歴を解析して,この要素が“実績による使用”をもつことを実証する。
− 要素の挙動について収集した多数の適合確認証拠を評価して,要素が,この規格の要求事項を
満たすかどうかを判断する。
C.2.10.1 実績による使用
“実績による使用”(JIS C 0508-4の3.8.18参照)が,信頼性確認済みのソフトウェア要素が必要な安全
度を実現していることの十分な根拠となることは非常にまれである。多くの実行可能な機能をもつ複雑な
要素(例えば,オペレーティングシステム)の場合,要素のどの機能が実際に十分な使用実績をもつか確
定することは不可欠である。例えば,フォールトを検出するための自己テストルーチンを備えている場合,
運用期間中に故障が全く起こらなかった場合,フォールト検出のための自己テストルーチンに使用実績が
あると考えることはできない。
ソフトウェア要素は,次の判定基準を満たしている場合,使用実績があると判断できる。
− 仕様を変更していない。
− 種々のアプリケーションにおけるシステムがある。
− 1年以上の使用履歴がある。
− 運用時間は,安全度水準又は適切な作動要求数に従っている。非安全関連故障率が次の値を下回って
いることを実証することができる。
・ 信頼水準95 %で作動要求(年間)当たり10−2未満であることの実証には,300回の運用(年間)を
必要とする。
・ 信頼水準99.9 %で作動要求(年間)当たり10−5未満であることの実証には,690 000回の運用(年
間)を必要とする。
注記1 上記の推定値の根拠となる数学的側面は,附属書Dを参照。類似の手法及び統計的アプロ
ーチは,B.5.4も参照。
− 運用経験を積むことによって作動要求プロフィールに対するソフトウェア要素の挙動についての知識

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

68
C 0508-7 : 2017 (IEC 61508-7 : 2010)
が増すことを確実にするために,運用経験の全てをソフトウェア要素の機能についての既知作動要求
プロフィールに関連付ける必要があるが,これを満足している。
− 安全関連故障がない。
注記2 一つの状況において安全上重大でないかもしれない故障が,他の状況において安全上重大
である場合,又はその逆の場合がある。
ソフトウェア要素が判定基準を満たしていることの適合確認を可能にするために,次の事項を文書化す
る必要がある。
− バージョン番号を含め,各システム及びその要素の正しい識別(ソフトウェア及びハードウェアの両
方について)
− 使用者の特定及び使用時間
− 運用時間
− 使用者利用システム及びアプリケーションの選択のための手順
− 故障を検出し登録するための手順及びフォールトを取り除くための手順
C.2.10.2 多数の適合確認証拠の評価
既存のソフトウェア要素(JIS C 0508-4の3.2.8参照)は,既に存在するものであって,現行のプロジェ
クト又は安全関連系(SRS)を対象として特に開発されたものではない。既存ソフトウェアは市販品かも
しれないし,どこかの組織が旧製品又は旧システムのために開発したかもしれない。既存ソフトウェアは,
この規格の要求事項に従って開発したものでも,そうでないものでもよい。
既存ソフトウェアを組み込んだ新システムの安全度を評価する場合,既存の要素の挙動を判断するため
に多数の適合確認証拠が必要となる。これらの証拠は,(1)要素供給業者自身がもつ,この要素の開発プ
ロセスの文書及び記録,又は(2)新規安全関連系の開発業者若しくは第三者が行った追加認証活動によっ
て作成若しくは補足作成されたものの場合がある。これらの証拠は,ソフトウェア要素の潜在的な再利用
可能性及び限度を定義する,“準拠項目に対する安全マニュアル”である。
いずれの場合も,再利用する要素に全面的又は部分的に左右される特定安全機能の完全性の評価を可能
にする,準拠項目に対する安全マニュアルというものが存在する(存在しない場合は作成する。)必要があ
る。このマニュアルがない場合,要素を安全関連で再利用する根拠がないという,安全側に立った結論が
導かれる可能性がある(これは,この要素が個別の事例で証拠が不十分だったというだけで,どのような
場合にも使用できないということではない。)。
この規格は,準拠項目に対する安全マニュアルの内容について,具体的な要求事項を用意している[JIS
C 0508-2の附属書D(準拠項目に対する安全マニュアル),JIS C 0508-3の附属書D(適合品目の安全マニ
ュアル−ソフトウェア要素の追加要求事項)並びにJIS C 0508-3の7.4.2.12及び7.4.2.13参照]。
準拠項目に対する安全マニュアルは,内容を非常に簡単に示すものとして,次の点を取り上げている。
− 要素の設計が既知であり,文書化している。
− 要素が,文書化したテストによる系統的アプローチを用いて適合確認及び妥当性確認を受けており,
要素の設計及びコードの全ての部分の見直しを行っている。
− 要素の未使用及び不要な機能によって,新システムがその安全要求事項を満たすことを妨げない。
− 新システム中の要素の,全ての信ぴょう(憑)性のある故障メカニズムを特定し,適切な軽減手段を
実装している。
新システムの機能安全評価によって,再利用した要素は,要素の準拠項目の安全マニュアルの証拠及び

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

次のページ PDF 71

JIS C 0508-7:2017の引用国際規格 ISO 一覧

  • IEC 61508-7:2010(IDT)

JIS C 0508-7:2017の国際規格 ICS 分類一覧

JIS C 0508-7:2017の関連規格と引用規格一覧

規格番号
規格名称