JISX0134:1999 システム及びソフトウェアに課せられたリスク抑制の完全性水準

X 0134 : 1999 (ISO/IEC 15026 : 1998)

(1)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ページ

序文 ··································································································································· 1

1. 適用範囲 ························································································································ 1

2. 引用規格 ························································································································ 2

3. 定義 ······························································································································ 2

4. 記号及び略語 ·················································································································· 3

5. ソフトウェアに課せられたリスク抑制の完全性水準 ······························································· 4

5.1 この規格の利用法 ·········································································································· 4

5.2 概要 ···························································································································· 4

6. システム完全性水準の決定 ································································································ 7

6.1 リスク分析 ··················································································································· 7

6.1.1 危険な兆候の識別 ········································································································ 8

6.1.2 頻度分析 ···················································································································· 8

6.1.3 影響分析 ···················································································································· 8

6.1.4 リスク計算 ················································································································· 8

6.2 リスク評価 ··················································································································· 9

6.3 システム完全性水準の決定······························································································· 9

7. ソフトウェア完全性水準の決定 ·························································································· 9

7.1 ソフトウェア完全性水準の決定における前提条件 ································································ 10

7.2 ソフトウェア完全性水準の低減 ························································································ 10

7.3 危険な兆候となる可能性のある故障を発生するソフトウェア完全性水準の低減 ························· 11

7.4 自己の故障によって緩和機能を提供できなくなるソフトウェアの完全性水準の低減 ··················· 11

8. ソフトウェア完全性要求事項の決定 ··················································································· 11

8.1 信頼等級 ····················································································································· 11

8.2 ソフトウェアの信頼等級を達成する手法 ············································································ 12

8.3 ソフトウェアの信頼等級及び完全性水準の関連 ··································································· 12

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

日本工業規格 JIS

X 0134 : 1999

(ISO/IEC 15026 : 1998)

システム及びソフトウェアに

課せられたリスク抑制の完全性水準

Information technology−System and software integrity levels

序文この規格は1998年に発行されたISO/IEC 15026，Information technology − System and software

integrity levelsについて，技術的内容及び規格票の様式を変更することなく作成した日本工業規格である。

この規格に記載したIEC規格番号は，1997年1月1日から実施のIEC規格新番号体系によるものである。

これによって前に発行された規格については，規格票に記載された規格番号に60000を加えた番号に切り

替える。これは番号だけの切替えであり，内容は同一である。

1. 適用範囲

この規格では，ソフトウェアに課せられたリスク抑制の完全性水準の諸概念及びその要求事項を規定す

る。ここでは，リスク抑制の完全性水準に関係する諸概念を定義し，その完全性水準及びソフトウェアに

課せられたリスク抑制の完全性要求事項を決定するための該当プロセスを定義し，そして，各々のプロセ

スに各要求事項を配分する。この規格では，リスク抑制の完全性水準又はソフトウェアに課せられたその

完全性要求事項の特定のセットを規定していない。これらは，各プロジェクトごとか，特定の応用分野及

び／又は国ごとかのどちらか一方で確定されなければならない。この規格は，ソフトウェアだけに適用さ

れる。システムに課せられたリスク抑制の完全性水準及び非ソフトウェア構成部品に課せられたリスク抑

制の完全性水準は，この規格では，ソフトウェア構成部品に課せられたリスク抑制の完全性水準を決定す

るためにだけに必要とする。

この規格は，ソフトウェア製品又はソフトウェアを含むシステムの開発者，利用者，調達者及び評価者

が，これらの製品及びシステムを管理及び技術支援を行う際に，利用されることを意図している。

ソフトウェアに課せられたリスク抑制の完全性水準は，システムリスクを受入れ可能な範囲内に維持す

るために必要とするソフトウェアがもつ性質の値の範囲（値域）を表示する。緩和機能を実行するソフト

ウェアの場合には，その性質は，当該ソフトウェアが緩和機能を実行する際に満たさなければならない信

頼度とする。自己の故障がシステムに危険な兆候をもたらす可能性のあるソフトウェアの場合には，その

性質は，その故障の発生頻度又は生起確率の上限値とする。

参考発生頻度及び生起確率の推定に，ゆう（尤）度が用いられる。

ソフトウェア完全性要求事項は，そのソフトウェアをそれ自身がもつべきリスク抑制の完全性水準にふ

さわしい信頼等級に値するようにするために必要となる諸要求事項であり，そのソフトウェアを開発する

際に採用されるソフトウェア工学プロセスが満たさなければならない要求事項，そのソフトウェア工学製

品が満たさなければならない要求事項及び／又はそのソフトウェアの常に満たさなければならない遂行能

力にも当てはめるべき要求事項からなる。

X 0134 : 1999 (ISO/IEC 15026 : 1998)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

この規格は，リスク抑制の完全性水準決定を包括的なシステム工学ライフサイクルプロセスに統合する

やり方に関しては規定していない。

2. 引用規格

次に掲げる規格は，この規格に引用されることによって，この規格の規定の一部を構成する。これらの

引用規格は，その最新版（追補を含む。）を適用する。

・JIS X 0001 情報処理用語基本用語

備考 ISO/IEC 2382-1 : 1993, Information Technology−Vocabulary − Part 1 : Fumdamental termsが，

この規格と対応している。

・JIS X0020 情報処理用語（システム開発）

備考 ISO/IEC 2382-20 : 1995, Information Technology − Vocabulary−Part 20 : System developmemt

が，この規格と対応している。

・ISO 8402 : 1994, Quality management and quality assurance−Vocabulary

・IEC 60050 (191) : 1990, International Electrotechnical Vocabulary, Chapter 191 : Dependability and quality of

service

・IEC 60300-3-9 : 1995, Dependability management − Part 3 : Application guide − Section 9 : Risk

analysis of technological systems

・JIS X 0160 ソフトウエアライフサイクルプロセス

備考 ISO/IEC 12207 : 1995, Information Technology − Software life cycle processesが，この規格と対

応している。

3. 定義

この規格の目的上，次に示す定義によって，修正又は補遺されている場合を除いて，JIS X 0001，JIS X

0020，ISO 8402及びIEC 60050 (191) の定義を適用する。

3.1

構成部品 (component) 分析の特定水準で考慮されるシステム中のアセンブリモジュール又はソ

フトウェアモジュールのような離散構造をもつ実体。

3.2

信頼等級，信頼の度合い (degree of confidence) この規格では，この“信頼等級”という用語は，

ソフトウェアがその要求事項に適合していることを意味するときにだけ使用される。

3.3

設計責任機関 (design authority) システムの設計記述を作成する責任をもつ個人又は組織。

3.4

故障 (failure) 前もって指定された限界内で，要求された機能を遂行する品目の能力の停止，又は

遂行の能力がなくなること。

3.5

障害隔離 (fault isolation) 自サブシステム中で発生した障害が原因で，その結果として，別のサブ

システム中で障害が発生することがないようにするサブシステムの能力。

3.6

機能 (function) 当該システムの意図された振舞いの側面。

3.7

引き金事象 (initiating event) 危険な兆候に至らしめる可能性のある事象。

3.8

リスク抑制の完全性保証機関 (integrity assurance authority) リスク抑制の完全性要求事項に対す

る準拠性の総合評価をする責任をもつ独立の個人又は組織。

参考文脈から明らかな場合，完全性保証機関と略す。

X 0134 : 1999 (ISO/IEC 15026 : 1998)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

3.9

リスク抑制の完全性水準 (integrity level) システムリスクを受入れ可能な範囲内に維持するため

に必要な品目がもつ性質の値の範囲（値域）を表す表示記号。緩和機能を実行する品目の場合には，その

性質は，当該品目が緩和機能を実行する際に満たさなければならない信頼度とする。自己の故障が危険な

兆候をもたらす可能性のある品目の場合には，その性質は，その故障の発生頻度の上限値とする。

参考文脈上明らかな場合には，完全性水準と略す。

3.10 品目 (item) 個別に考慮可能な部品，構成部品，サブシステム，装置，システムなどのような実体。

品目は，ハードウェア，ソフトウェア又はその両者からなっていてもよい。

3.11 緩和機能 (mitigating function) 正しく提供されれば，引き金事象が指定された危険な兆候になる

のを防止しうる機能。

3.12 リスク (risk) 想定された危険な兆候の生起確率と，その生起によって起こりうる不利な結末との

関数。

3.13 リスク次元 (risk dimension) システムに対してリスク総合評価をする際の着眼点（例えば，安全

性，経済性，セキュリティ）。

参考

リスク総合評価＝リスク分析＋リスク評価

リスク管理＝リスク総合評価＋リスク軽減と制御

3.14 安全性 (safety) システムが，規定された条件のもとで，人の生命，健康，財産又はその環境を危

険にさらす状態に移行しない期待度合い。

3.15 セキュリティ，安全保護 (security) 偶然又は悪意によるアクセス，使用，変更，破壊又は漏えい

（洩）から，システム品目を保護すること。

参考情報資源に対する安全保護という意味でセキュリティを用いる。

3.16 ソフトウェアに課せられたリスク抑制の完全性水準 (software integrity level) ソフトウェア品目

がもつリスク抑制の完全性水準。

参考文脈から明らかな場合には，ソフトウェア完全性水準と略す。

3.17 サブシステム (subsystem) より大きいシステムの一部を構成するシステム。

3.18 システム (system) 一つ以上のプロセス，ハードウェア，ソフトウェア，設備及び人を統合化して，

規定のニーズ又は目的を満たす能力を提供するまとまり。

3.19 系統的故障 (systematic failure) ある特定の原因に決定論的に関係する故障。系統的故障は，その

原因を設計記述の修正，又は，製造プロセス，運用手順，文書，その他の関連する因子の修正によってだ

け排除することができる。

3.20 システムに課せられたリスク抑制の完全性水準 (system integrity level) システムがもつリスク抑

制の完全性水準。

参考文脈から明らかな場合には，システム完全性水準と略す。

3.21 危険な兆候 (threat) 一つ以上の想定されたリスク次元面での不利な結果をもたらす可能性のある

システム又はシステム環境の状態。

参考この規格では，安全関連分野以外のリスク，例えば商業活動における損失などにも対応できる

ように用語を定義している。そのため，安全関連分野で用いられている危険 (hazard) を一般化

して危険な兆候 (threat) と呼ぶ。詳しくは6.1リスク分析のIEC 60300-3-9との対応を参照のこ

と。

4. 記号及び略語

X 0134 : 1999 (ISO/IEC 15026 : 1998)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

この規格では，記号を使用していない。略語に関しては，適切な場合に限って，初出の際に，その箇所

にその全綴りを示す。

5. ソフトウェアに課せられたリスク抑制の完全性水準

5.1

この規格の利用法

独立したリスク抑制の完全性保証機関という概念は，この規格の適切な利用のための基本となる。完全

性保証機関は，完全性要求事項の準拠性を認定する責任をもつ人，又は組織とする。設計責任機関と完全

性保証機関との間の折衝でなされた意思決定は，文書化される。折衝でなされる意思決定には，関連する

リスク次元，使用される特定の完全性水準，各水準を割り当てるための特定の基準，及び設計記述中にあ

る特定の構成方式機構に対して認められる効用度合い，及び特定の完全性水準を割り当てた結果として生

ずるソフトウェアへの要求事項の決定が含まれる。

この規格では，包括的なシステム工学プロセスとして区別してプロセスが示されているが，しかし，こ

の規格では，これらのプロセスをシステム工学プロセスに統合することを妨げるものではない。これらの

プロセスをどのように実現するかに関係なく，この規格の遵守は，その中の要求事項のすべてを満たすこ

とを要求する。

5.2は，リスク抑制の完全性水準，及びソフトウェア完全性要求事項を決定するプロセスの概要について

述べる。

6.，7.及び8.は，このプロセスをさらに詳しく定義し，このプロセスに課せられた要求事項を規定する。

5.2

概要

図1は，システム完全性水準，ソフトウェア完全性水準，及びその要求事項の決定に必要なプロセスの

概要を示す。表1は，システム完全性水準の決定，ソフトウェア完全性水準の決定，及びその要求事項の

決定，という三つの主なプロセスのそれぞれの入力及び出力を示す。

X 0134 : 1999 (ISO/IEC 15026 : 1998)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

表1 入力及び出力

プロセス

入力

出力

システム
完全性水準の決
定

− 関連する各リスク次元
− システムに関する情報
− 環境に関する情報
− システムの構成方式（入手可能な場合）

− リスクのリスト
− 危険な兆候のリスト
− 危険な兆候の許容発生頻度又は生起確

率

− 引き金事象のリスト
− 引き金事象の発生頻度又は生起確率
− システム完全性水準

ソフトウェア
完全性水準の決
定

− システム完全性水準
− サブシステム・ソフトウェアの構成方式
− 危険な兆候のリストと，各々の危険な兆候ごと

に：

− 危険な兆候の許容発生頻度又は生起確率
− 危険な兆候を生じるかもしれない引き金事

象

− 各引き金事象の推定発生頻度又は生起確率

− サブシステム・ソフトウェアの完全性

水準

− 完全性水準の低減を認めるのに信用に

値する構成方式機構

ソフトウェア
完全性要求事項
の決定

− サブシステム・ソフトウェアの完全性水準

− ソフトウェア完全性要求事項

この規格では，完全性水準決定に対するリスクに基づく取組みを用いる。したがって，対応するシステ

ム完全性水準を決定する最初の段階は，リスク分析の実施を含む。IEC 60300-3-9 “Risk Analysis of

Technological Systems” （工業的システムのリスク分析）は，リスク分析実施の手引きを提供する。リスク

分析を実施するシステムに関連するシステム，その環境及びリスク次元についての十分な情報は，あらか

じめ収集しておかなければならない。分析されるリスクは，設計責任機関及び完全性保証機関の合意のも

とに，安全性，経済性，セキュリティなどの，すべての関連するリスク次元を網羅するのがよい。

リスク分析で識別されたすべてのリスクは，そのリスクが許容できるかどうかを決定するために，評価

されなければならない。一度，システムの設計記述が許容できるリスクを保持しているかについて分析さ

れ評価された後，システム完全性水準が割り当てられる。システム完全性水準は，システムに関連する最

悪ケースのリスクを反映する。

当該システムに含まれるソフトウェア完全性水準は，最初の段階では，システム完全性水準と同じもの

が割り当てられる。システムの設計記述は，構成方式機構がシステムの設計記述の中にあるかどうかを分

析し，システム完全性水準より低い水準をソフトウェアに割り当てることの妥当性を決定するとよい。

システムは，一つ以上の構成部品からなる統合された複合物とする。構成部品は，単独のソフトウェア

でも，単独のハードウェアでもよいし，また，さらに分解した構成部品からなるサブシステムでもよい。

最初，システムのすべてのソフトウェア構成部品に，そのシステム完全性水準が割り当てられる。ソフト

ウェア完全性水準の決定には，システム完全性水準より低い水準をサブシステムに割り当てられるかどう

かを決定するための，システムの構成方式の分析が含まれる。このプロセスは，各サブシステム中にある

すべてのソフトウェア構成部品に完全性水準を割り当てるために，ソフトウェアだけしか含まないサブシ

ステム完全性水準が決まるまで，又は，ソフトウェアを含んでいるサブシステム完全性水準が，設計責任

機関及び完全性保証機関によって認められるまで，再帰的に適用可能である。

構成方式を分析している間に，以前に行ったリスク分析の期間では決定できなかった新たな危険な兆候

やリスクが識別されることもありうる。これには，新たなリスク情報を考慮に入れたリスク分析の反復が

要求されるだろう。

X 0134 : 1999 (ISO/IEC 15026 : 1998)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

ソフトウェア完全性水準は，緩和機能の提供の信頼度，又は危険な兆候をもたらすかもしれない故障の

発生頻度に対して要求された上限値のいずれかを指示する。ソフトウェアの故障は厳密には系統的故障で

あるので，ソフトウェア完全性水準は，緩和機能が高信頼に提供されるか，又は危険な兆候を引き起こす

ような故障は生じないかのいずれかの要求された信頼等級を表示する。

ソフトウェア完全性水準の決定及び適用は，リスク管理の包括的なプロセスの一部である。リスク管理

は，システム又はソフトウェア製品の全プロセスを通して実施され，種々の詳細水準の設計記述が意思決

定されたときに，すなわち設計記述の進行に応じて繰り返し実施されてもよい。図1に，包括的なシステ

ム工学プロセスと，リスク分析，リスク評価及びリスク制御からなるリスク管理との関係を示す。

システムの設計記述がリスク排除・軽減 (reduce) 可能な能力を組み込むために修正された場合，システ

ム又はソフトウェア完全性水準を割り当てる際に新たな危険な兆候が識別された場合，又は，システムの

設計記述が許容できるリスクを満たせない場合に，リスク管理を反復することができる。

ソフトウェア完全性水準は，ソフトウェアに対してシステムリスクに関連する役割にふさわしい信頼等

級を獲得して保持させるために，ソフトウェア及びそのソフトウェア工学プロセスに当てはめるべき要求

事項が何であるかを識別することによって，ソフトウェア構成部品に関連するリスクをどの程度制御する

かを決定するのに使用する。これらの要求事項は，ソフトウェア完全性要求事項と呼ばれている。

6. システム完全性水準の決定

システム完全性水準は，そのシステムに関係するリスクの許容水準に対応する。システムの故障が危険

な兆候を引き起こすということ，又は危険な兆候を引き起こす状況下において引き金事象の影響を緩和す

る機能をシステム機能中に備えるために，システムはリスクと関連づけられる。システム完全性水準は，

次の手順で決定しなければならない。

a) リスク分析によってそのシステムに関係するリスク水準を決定する。リスク分析は，入手可能な情報

を用いて，危険な兆候の識別又はそれら危険な兆候に関連するリスク見積りを行うプロセスである。

b) リスク評価は，各リスクの許容度合いを判定 (judgment) するプロセスである。リスク分析及びリスク

評価の出力によっては，リスクの排除又は軽減のためにシステムの設計記述の変更が行われる可能性

がある。

c) 許容可能なリスクをもつシステムの設計記述が識別されると，システム完全性水準の割当てが行われ

る。実際に選択を行う完全性水準の正確な等級の数又は水準間の評価基準は，設計責任機関と完全性

保証機関との間で折衝がなされなければならない。

6.1

リスク分析

リスク分析は，次の三つの基本的な質問に答えるように行われなければならない。

（危険な兆候の識別によって）悪くなる可能性のあるものは何か。

（頻度分析によって）それがどの程度発生するのか。

（影響分析によって）その影響はどの程度なのか。

これらの分析によって，各リスクが計算できる。それぞれ識別されたリスクに対するリスク分析の出力

は，次のすべてとする：

a) 適切な用語を用いたリスクの記述

b) そのリスクに関連した危険な兆候

c) それぞれの危険な兆候に関連した引き金事象

d) 引き金事象の推定発生頻度

X 0134 : 1999 (ISO/IEC 15026 : 1998)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

リスク分析から得られるリスクの記述は，リスクが許容可能かどうかを決定するリスク評価プロセスに

用いられる。リスク分析から得られるすべての出力は，システムに課せられたリスク抑制の完全性水準決

定プロセス，及びそのシステムのソフトウェア部品に要求きれる完全性水準を決めるソフトウェア完全性

水準決定プロセスに用いられる。

リスク分析に有用な指針としてIEC 60300-3-9 “Risk Analysis of Technological Systems” がある。IEC

60300-3-9の中で安全に関する術語として用いられている“hazard（危険）”及び“harm（危害）”という用

語は，それぞれ，“threat（危険な兆候）”及び“adverse effect（不利な結末）”に置き換える。

リスク分析は，安全性，経済性，セキュリティなどの多様なリスクの次元を網羅することができる。網

羅される対象のリスク次元は，設計責任機関及び完全性保証機関によって決定されなければならない。

6.1.1

危険な兆候の識別

システムに関連した危険な兆候は，その危険な兆候につながり得る引き金事象とともに識別するのがよ

い。危険な兆候は次に示すようにシステムと関連して存在する。システムの故障が危険な兆候に結びつく

場合，指定されたとおりのシステム運用が危険な兆候になる場合，又は危険な兆候になるような環境下で

引き金事象の緩和機能をシステムが遂行する場合。明確には認識されない危険な兆候を識別するため，特

別の状況を網羅する手法を用い，そして文書化するのがよい（IEC 60300-3-9参照）。システムの中で用い

られているそれぞれの技術に固有の故障モードを確実に考慮に入れるために，危険な兆候の識別作業は，

（入手可能ならば）システムの構成方式を考慮しなければならない。

6.1.2

頻度分析

頻度分析は，危険な兆候の識別によって決定された各引き金事象のゆう(尤)度(likelihood)を見積もるため

に用いる。システムの故障が引き金事象となる場合には，頻度分析は，故障発生のゆう(尤)度を見積もる

のではなく，代わりに故障の発生頻度の上限値を決定する。それは，許容されるリスク目標と矛盾せず，

かつ，実用上実現可能なものである。

事象の発生頻度は，FTA（障害の木分析）又はETA（イベントツリー分析）（IEC 60300-3-9参照）のよ

うな技法によって積み上げた適切な過去のデータ，又は，専門家の判定を用いて見積もられなければなら

ない。

システム完全性水準決定プロセスの間になされる頻度分析は，システムをブラックボックスとして扱う

ものとし，システムの構成方式を考慮に入れてはならない。システムの構成方式は，ソフトウェア完全性

水準決定プロセスにおいて考慮されるものである。頻度分析によって決定された事象発生頻度は，量的尺

度，又は，頻繁 (Frequent)，可能性大 (Probable)，時折 (Occasional)，希有 (Remote)，可能性極小 (Improbable)，

皆無 (Incredible) などの発生頻度の等級を示す質的尺度によって表現してもよい。

頻度分析では，他の事象と組み合わさったり，事象の時系列の一部となったときにだけ危険な兆候とな

る引き金事象もあるということを考慮に入れておかなければならない。

6.1.3

影響分析

影響分析は，万一，引き金事象が発生した場合の危険な兆候の厳しさ度合い (severity) を見積もるため

に用いられる。引き金事象の影響を緩和するすべての手段を識別するのがよい。それぞれの危険な兆候は，

例えば，破局的 (Catastrophic)，重大 (Major)，厳しい (Severe)，及び軽微 (Minor) といった種々の影響の

厳しさ度合いを示す一連の分類の中から一つの影響分類に結びつけられなければならない。

6.1.4

リスク計算

それぞれの危険な兆候に関連したリスクは，引き金事象の発生頻度と引き金事象の影響の厳しさ度合い

とを関連づけるリスクマトリックスを使って計算される。リスクマトリックスは，発生頻度と影響の厳し

X 0134 : 1999 (ISO/IEC 15026 : 1998)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

さ度合いとの組合せの交点に，例えば，高いリスク，中程度のリスク，低いリスク，又は，微かな (Trivial)

リスクといったリスク階級を割り当てる。

表2 リスクマトリックスの例

発生頻度

発生頻度の指標

（件／年）

影響の厳しさ度合い

破局的

(Catastrophic)

重大

(Major)

厳しい

(Severe)

軽微

(Minor)

頻度 (Frequent)

高い

中程度

可能性大 (Probable)

1−10-1

高い

中程度

低い

時折 (Occasional)

10-1−10-2

高い

低い

希有 (Remote)

10-2−10-4

高い

低い

可能性極小 (Improbable)

10-4−10-6

高い

中程度

低い

微かな

皆無 (Incredible)

<10-6

中程度

微かな

表2にIEC 60300-3-9からとったリスクマトリックスの例を示す。

設計責任機関及び完全性保証機関は，リスク計算に使われるすべてのリスクマトリックスに合意しなけ

ればならない。リスクマトリックスの合意書としては，引き金事象発生頻度の適切な範囲（値域）の合意

書，影響分類及びそれらの定義の合意書，並びに発生頻度範囲と影響分類との各組合せに関連したリスク

階級の合意書が必要とする。

6.2

リスク評価

リスク分析プロセスよって計算された各リスクの許容度合いに対する判定は，設計責任機関及び完全性

保証機関によってなされなければならない。この判定は，分野別の監督機関によって制定された規制値を

考慮に入れて行われている分野もある。

6.3

システム完全性水準の決定

最初に割り当てられたシステム完全性水準は，そのシステムに関する危険な兆候のすべてに割り当てら

れた中で最も高いリスク階級に対応する。完全性水準の値は識別されたリスク階級の等級値に対応する。

表3は，システム完全性水準とリスク階級の対応の例を示す。

表3 システム完全性水準とリスク階級の対応

リスク階級

システム完全性水準

高い

中程度

低い

微かな

この規格では，完全性水準の等級の数も，表示記号も規定しない。

7. ソフトウェア完全性水準の決定

ソフトウェア完全性水準は，構成部品としてソフトウェアを含むサブシステム，又は，ソフトウェア単

独で構成されているサブシステムに対してシステム完全性水準を配分 (allocation) したものである。サブ

システムに対するソフトウェア完全性水準は，最初，システムに課せられたリスク抑制の完全性水準と同

一とする。

この条件は，次に示す点を考慮に入れ，ソフトウェア完全性水準が下げられなければ，そのままとする。

a) システムの危険な兆候となるサブシステム故障の影響を緩和するシステムの構成方式機構

b) 緩和機能をもつ複数個のサブシステムの単一故障又は多重故障において，引き金事象を緩和する機能

をもつ冗長性を備えたシステムの構成方式機構

X 0134 : 1999 (ISO/IEC 15026 : 1998)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

c) 識別された引き金事象又はその緩和機能に関与するか否かに関する当該サブシステムの役割

7.1

ソフトウェア完全性水準の決定における前提条件

a) システムに課せられたリスク抑制の完全性水準がシステムに割り当てられていること。

b) サブシステムの役割及びそれらのインタフェースが識別できるように，システムの構成方式機構が十

分詳細に定義されていること。

c) 入力として次を含むこと。

− システム完全性水準

− 危険な兆候のリスト及びそれぞれの兆候に対する次の情報

− 危険な兆候に至る引き金事象

− 各引き金事象の同時発生頻度又は同時生起確率

各サブシステムの役割の決定，及びすべての緩和特性を識別するのに十分なシステム構成方式機構

の定義

d) 出力は，ソフトウェア完全性水準とすること。

7.2

ソフトウェア完全性水準の低減

ソフトウェア完全性水準の可能な低減を決定するために，次の段階が実施されなければならない。

a) システム全体を構成するサブシステムの集合を識別する。

b) サブシステムの故障が独自に，又は他のサブシステムの状態との組合せによって危険な兆候となるか

どうかを決定する。サブシステムの故障が単独で危険な兆候となる場合には，そのサブシステムに課

せられたリスク抑制の完全性水準は，システムと同じ水準に割り当てられる。サブシステムの故障が

他のサブシステムの状態と組み合わさったときだけ危険な兆候となる場合には，そのサブシステム完

全性水準は，7.3で規定される総合評価の結果しだいで低減されうる。7.3で規定される総合評価は必

す（須）ではなく，より低いサブシステム完全性水準が要望されるときにだけ実施するとよい。

c) サブシステムの故障が独自に，又は他のサブシステムの状態との組合せによって緩和機能が提供でき

るかどうかを決定する。サブシステムの故障が単独で緩和機能を提供できなくなる場合には，そのサ

ブシステム完全性水準は，システムと同じ水準に割り当てられる。サブシステムの故障が他のサブシ

ステムの状態と組み合わさったときだけ緩和機能が提供できなくなる場合には，そのサブシステム完

全性水準は，7.4で規定される総合評価の結果しだいで低減されうる。7.4で規定される総合評価は必

すではなく，より低いサブシステム完全性水準が要望されるときにだけ実施するとよい。

d) ソフトウェア構成部品をもつサブシステムで，その故障が危険な兆候に至らず，かつ，その機能があ

らゆるシステム事象に対する緩和に関連しないかどうかを決定する。そのようなソフトウェアには最

も低い完全性水準が割り当てられる。障害隔離は，ソフトウェアの故障が危険な兆候に至らないよう

にするために必要である。設計責任機関及び完全性保証機関は，十分な障害隔離を確実に行うために

構成方式機構の十分性に関して合意しなければならない。障害隔離が故障処理機構によってなされる

ならば，その仕組みに対してはシステムと同等なソフトウェアの完全性水準を割り当てる。

割り当てられたシステム完全性水準からソフトウェア完全性水準を低減するための構成方式機構がもた

らす効用度合いは，完全性保証機関及び設計責任機関によって規定され，合意されなければならない。

段階a)からd)に規定した手順は，ソフトウェアだけしか含まないすべてのサブシステムに対するリスク

抑制の完全性水準が決まるまで，又は，これらのサブシステム中にあるすべてのソフトウェア構成部品に

完全性水準を割り当てるためにソフトウェアを含んでいるサブシステム完全性水準が設計責任機関及び保

証機関によって認められるまで，再帰的に適用される。

X 0134 : 1999 (ISO/IEC 15026 : 1998)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

7.3

危険な兆候となる可能性のある故障を発生するソフトウェア完全性水準の低減

故障が危険な兆候になりうるシステムに対するシステム完全性水準は，許容リスク目標と矛盾しないシ

ステム故障発生頻度の上限値だけに基づいている。他のサブシステムの状態との組合せによってソフトウ

ェアの故障が危険な兆候となる場合，ソフトウェア故障発生頻度に対して，システムで使われているもの

より厳しくない値を割り当ててもよい。

頻度分析を用いてソフトウェア故障発生頻度に対し，許容リスク目標を満足する最も厳しくない上限値

を決定してもよいが，その際には，サブシステム間の依存関係を考慮に入れなければならない。より高い

ソフトウェア故障頻度の上限値が決定したら，リスク計算を繰り返し，リスク階級に対して変更があるか

どうか，又は，これに関連して低いソフトウェア完全性水準に対応するかを決定してもよい。

故障処理機構は，ソフトウェア故障を検出したり，それらが引き金事象になることを防ぐために使用す

る。これらのケースでは，故障が起こり，故障処理機構が有効に働かない場合に限って，ソフトウェア故

障が引き金事象となる。故障処理機構の例としては，次のものがある。

・データの一貫性検査（ソフトウェア手段）

・ハードウェアによる時限監視（ハードウェア手段）

・手動による回復（人手による手段）

冗長性は，冗長なサブシステムの間での共通モード故障が避けられているならば，故障が危険な兆候に

至るのを防止するために使用してもよい。冗長性をソフトウェア構成品の間で採用する場合は，ソフトウ

ェア多様性のような戦略が共通モード故障を避けるのに使われなければならない。ソフトウェアの多様性

がソフトウェア故障の発生頻度に対する上限値の厳しさ (stringency) を低減するために用いるときには，

ソフトウェアの多様性によって提供される効用度合い及び十分な多様性を何が組成するかの定義が，設計

責任機関及び完全性保証機関によって合意されなければならない。

7.4

自己の故障によって緩和機能を提供できなくなるソフトウェアの完全性水準の低減

サブシステムの故障が他のサブシステムの状態との組合せによって緩和機能を提供できなくなるなら，

そのソフトウェアの信頼度は，システムの緩和機能に要求されている信頼度よりも低くすることができる。

7.3で定義したのと同様に，頻度分析に使われる技法は，システムに要求されている緩和機能の信頼度から

そのソフトウェアに割り当てるべき低減の度合いを決定するのに使用することができる。

8. ソフトウェア完全性要求事項の決定

8.1

信頼等級

ソフトウェアに課せられたリスク抑制の完全性水準は，緩和機能の提供に対する要求された信頼度，又

は危険な兆候をもたらしうる故障の発生頻度に対する要求された上限値のいずれかとする。ソフトウェア

の故障は，厳密には系統的故障であるので，ソフトウェア完全性水準は，緩和機能が高信頼度で提供され

るか，又は危険な兆候を引き起こすような故障は生じないかのいずれかの，要求された信頼等級を表示す

る。要求事項を満たした場合，必要とする信頼等級をもたらすはずであるソフトウェア及びそのライフサ

イクルプロセスによって満たすべき要求事項は，ソフトウェア完全性要求事項と呼ばれる。

ソフトウェアで確証を得るための戦略として，次に示すものがある：

a) 誤りの混入を最小限にする技法の適用

b) 誤りの検出を最大限にする検証又は妥当性の確認技法の適用

c) ソフトウェアが提供する緩和機能が高信頼度で動作しているか，又は故障が規定された上限値以下の

発生頻度でしか発生しないことを運用履歴によって実証する。

X 0134 : 1999 (ISO/IEC 15026 : 1998)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

8.2

ソフトウェアの信頼等級を達成する手法

表4は，諸特性を達成する際に各種の信頼等級で達成するのに使われる可能性のあるソフトウェア工学

におけるアクティビティ，アクティビティの出力の特性，及び手法の幾つかの例を概要付きで示す。この

規格は，特定のソフトウェアライフサイクルの採用を定めることを意図していない。JIS X 0160で規定さ

れた他のライフサイクルプロセスも等しく適用可能である。

ソフトウェアの確証は，ソフトウェアが一定の期間において運用され，その運用履歴が既に存在するな

らば，運用履歴に対する総合評価によって達成されてもよい。運用履歴によって得られた信頼等級は，そ

のソフトウェアの複雑性，その運用履歴の成功及びシステム中のそのソフトウェアに対する意図された使

い方と実際の運用とが類似していることなどの要因に依存する。

8.3

ソフトウェアの信頼等級及び完全性水準の関連

この規格は，与えられたソフトウェア完全性水準に対して適切な信頼等級を達成するために必要な特定

の要求事項を規定するものではない。

設計責任機関及び完全性保証機関は，それぞれの完全性水準のソフトウェアにおいて必要な信頼等級を

達成するのに満たさなければならない諸要求事項について双方の合意をとらなければならない。

表4 プロセス，アクティビティ，特性，信頼等級

アクティビティ

特性

ソフトウェアにおいて個々の完全性水準 (IL) の

信頼等級を達成する手法

手法

ソフトウェア要求分析

精度

構造化アプローチ

完備性

IL.1＋準形式的記法

正しさ

IL.1＋形式的記法

抽象度

IL.3＋形式的証明

一貫性

検証性

ソフトウェア設計

要求事項への追跡可能性

構造化アプローチ

検証性

IL.1＋準形式的記法

モジュール性

IL.1＋形式的記法

抽象度

IL.3＋形式的証明

ソフトウェア

設計記述への追跡可能性

構造化プログラミング

コーディング

プログラムの構造・構成の非あいまい性

IL.1＋型制約言語

プログラム言語の標準

IL.2＋言語の安全なサブセットに制限

保守性

IL.3＋形式的証明

IL：Integrity Levels完全性水準

X 0134 : 1999 (ISO/IEC 15026 : 1998)

2019年7月1日の法改正により名称が変わりました。まえがきを除き，本規格中の「日本工業規格」を「日本産業規格」に読み替えてください。

国内SC7/WG9小委員会構成表

氏名

所属

主査

松尾谷徹

日本電気株式会社

幹事

鍛治勝三

日本情報処理開発協会

落合利章

三菱電器株式会社

解良和郎

株式会社日立製作所

中村英夫

日本大学

松原友夫

コンサルタント

松本甲太郎

科学技術庁航空宇宙技術研究所

オブザーバ

安保洋子

日本電気株式会社

オブザーバ

志村順

アルシスＫＫ株式会社

原案作成委員会構成表

氏名

所属

(主査)

松尾谷徹

日本電気株式会社

(幹事)

鍛治勝三

日本情報処理開発協会

落合利章

三菱電機株式会社

解良和郎

株式会社日立製作所

中村英夫

日本大学

松原友夫

コンサルタント

松本甲太郎

科学技術庁航空宇宙技術研究所

安保洋子

日本電気株式会社

志村順

アルシスＫＫE株式会社

湯原孝

通商産業省工業技術院

(事務局）

徳岡靖崇

財団法人日本規格協会