DEOS White Paper Version 3：KLでWEB公開
JST-CREST†
DEOS-FY2011-WP-03J © 2011 科学技術振興機構
研究領域
「実用化を目指した組込みシステム用ディペンダブル・オペレーティングシステム」
DEOSプロジェクト White Paper Version 3.0（2011/11/15）
研究総括
所 眞理雄（株式会社ソニーコンピュータサイエンス研究所）
DEOS-FY2011-WP-03J © 2011 科学技術振興機構
研究領域
「実用化を目指した組込みシステム用ディペンダブル・オペレーティングシステム」
DEOSプロジェクト White Paper Version 3.0（2011/11/15）
研究総括
所 眞理雄（株式会社ソニーコンピュータサイエンス研究所）
変更遍歴
２０１１年１１月１５日
２０１０年１２月に領域White Paper Version 2.0を発行して早くも一年が経過した。プロジェクトはVersion 2.0に従って順調に進められており、より具体的な技術あるいはソフトウェアの開発が始まっている。このたび、最新の進捗状況を網羅的に記述し、Version 3.0として発行するに至った事はプロジェクト総括として嬉しい限りである。
執筆貢献者（所属・氏名 あいうえお順）：
科学技術振興機構・・・小野 清志、髙村 博紀、松原 茂、宮平 知博、屋代 眞
慶應義塾大学・・・・・河野 健二、徳田 英幸、中澤 仁、山田 浩史
産業技術総合研究所・・石綿 陽一、加賀美 聡、木下 佳樹、高井 利憲、武山 誠、田口 研治
ソニーコンピュータサイエンス研究所・・・・・所 眞理雄
筑波大学・・・・・・・追川 修一、佐藤 三久、塙 敏博、朴 泰祐
東京大学・・・・・・・石川 裕、藤田 肇、前田 俊行、松野 裕、横手 靖彦
名古屋大学・・・・・・山本 修一郎
横浜国立大学・・・・・倉光 君郎、菅谷 みどり
早稲田大学・・・・・・中島 達夫
「実用化を目指した組込みシステム用ディペンダブル・オペレーティングシステム」（DEOSプロジェクト）は科学技術振興機構の戦略的創造研究推進事業CREST†の研究領域のひとつです。
科学技術振興機構・・・小野 清志、髙村 博紀、松原 茂、宮平 知博、屋代 眞
慶應義塾大学・・・・・河野 健二、徳田 英幸、中澤 仁、山田 浩史
産業技術総合研究所・・石綿 陽一、加賀美 聡、木下 佳樹、高井 利憲、武山 誠、田口 研治
ソニーコンピュータサイエンス研究所・・・・・所 眞理雄
筑波大学・・・・・・・追川 修一、佐藤 三久、塙 敏博、朴 泰祐
東京大学・・・・・・・石川 裕、藤田 肇、前田 俊行、松野 裕、横手 靖彦
名古屋大学・・・・・・山本 修一郎
横浜国立大学・・・・・倉光 君郎、菅谷 みどり
早稲田大学・・・・・・中島 達夫
「実用化を目指した組込みシステム用ディペンダブル・オペレーティングシステム」（DEOSプロジェクト）は科学技術振興機構の戦略的創造研究推進事業CREST†の研究領域のひとつです。
1. はじめに
1.1. 背景と目標
近年、情報システムは我々の日々の生活に深くかかわるようになってきている。携帯電話、ウェブ上の数多くのサービスはもとより、天気予報、交通制御などの行政サービス、列車や航空機の自動改札システム、座席予約システム、運行管理システムや、物流システム、金融システムなどの業務用システムなど、ありとあらゆる場面で我々は情報システムの計り知れない恩恵を受けている。さらに、それらの情報システム同士が直接、間接に接続されて巨大な情報システム群を形成し、我々の生活の基本的なインフラストラクチャーを構成するに至っている。我々の生活における情報システムへの依存度が大きくなればなるほど、情報システムの信頼性や強靭性がますます重要になってきている。本稿では以下、信頼性や安全性など、システムの提供するサービスを安心して継続的に利用できる性質を総合してディペンダビリティ（Dependability）と呼ぶ事にする。
現代の典型的な情報システムは、情報端末機器がネットワークを介してサーバ群に接続され、情報機器端末が、サーバサーバ上のサービスを利用するように構成されている。これまで、多くの情報システムの開発では、事前にしっかりとした開発計画を立て、対象製品・システムの仕様を詳細に書き上げ、十分な†設計・実装・テストを行った後にユーザによる利用を開始する、と言う方法がとられてきた。この方法は、仕様が開発開始時に十分見極められるような製品やサービスの開発には有効であった。しかしながら上に述べたような大規模システムの開発においては、開発開始時に将来に起こるであろうすべてを見通したシステムの仕様を記述することはほとんど不可能である。加えて、開発においては、自社内の既存ソフトウェアの再利用、他社ソフトウェア製品の利用、ネットワーク上のサービスの利用など、仕様が完全であることを仮定できないソフトウェア部品の使用も一般的に行われるようになってきた。
通常このような大規模システムは長期にわたって利用される。したがって、そのようなシステムは時とともに変わる利用者のニーズに対応し、サービスを継続しつつ、システムを変更して行く必要がある。また、技術の進歩や経営上の理由、利用者数の増加・減少などに対し、サービスを継続して提供しつつ、ハードウェアやネットワークの変更に適切に対応しなければならない。このような理由によりシステムのディペンダビリティの確保はますます困難な状況になっている。さらには、ウイルスによるシステム破壊、不正アクセスによる情報漏洩などの脅威に対しても適切に対応し、利用者が安心してサービスを利用できるようにする必要がある。しかしながら、残念なことに、世界のあちらこちらで重要な情報システム障害が発生している。情報システムの障害は個々の利用者に重大な不利益を与えるだけでなく、サービス提供者にとっては本来得られる収益を無にし、時には莫大な補償金の支払いを要求され、企業のブランド価値の毀損につながり、事業の継続が困難になる可能性も出てくる。したがって、サービス提供者には最大限事故を起こさないようにする事に加え、事故が起こった際の説明責任が当初より課されていると考えるべきであろう。
システム障害の原因を見ると、システム構築の際にすべての構成要素を理解することが不可能であったために発生したもの、利用の量や利用の仕方が当初の設計値を超えたことによるもの、利用者の要求変化に応えるためにシステムを変更した際に発生したシステム動作の不整合によるもの、などが顕著である。これらの障害原因を見ると、現代のシステムは作られ方の観点でも、使われ方の観点でも、もはやシステムの機能や構造、境界が定義可能な固定的なシステムとして取り扱うことは困難であり、当初より時間の経過とともにそれらが変化しつづけるシステムとして取り扱うことが妥当であると思われる。
本プロジェクトは、変化しつづける目的や環境の中でシステムを適切に対応させ、継続的にユーザが求めるサービスを提供することができるシステムの構築法を開発することを目標としている。そのためには、これまで機能、構造、境界が固定的なシステムを対象に考えられてきたディペンダビリティ技術だけでは不十分であることを示し、新たな構築法の基礎となる概念として、「オープンシステムディペンダビリティ」の考え方を提案し、これをもとにした新たな構築法として、DEOSプロセスと呼ばれる反復的プロセス、これを実現するアーキテクチャ、そしてそれらに必要な要素技術群について述べる。
現代の典型的な情報システムは、情報端末機器がネットワークを介してサーバ群に接続され、情報機器端末が、サーバサーバ上のサービスを利用するように構成されている。これまで、多くの情報システムの開発では、事前にしっかりとした開発計画を立て、対象製品・システムの仕様を詳細に書き上げ、十分な†設計・実装・テストを行った後にユーザによる利用を開始する、と言う方法がとられてきた。この方法は、仕様が開発開始時に十分見極められるような製品やサービスの開発には有効であった。しかしながら上に述べたような大規模システムの開発においては、開発開始時に将来に起こるであろうすべてを見通したシステムの仕様を記述することはほとんど不可能である。加えて、開発においては、自社内の既存ソフトウェアの再利用、他社ソフトウェア製品の利用、ネットワーク上のサービスの利用など、仕様が完全であることを仮定できないソフトウェア部品の使用も一般的に行われるようになってきた。
通常このような大規模システムは長期にわたって利用される。したがって、そのようなシステムは時とともに変わる利用者のニーズに対応し、サービスを継続しつつ、システムを変更して行く必要がある。また、技術の進歩や経営上の理由、利用者数の増加・減少などに対し、サービスを継続して提供しつつ、ハードウェアやネットワークの変更に適切に対応しなければならない。このような理由によりシステムのディペンダビリティの確保はますます困難な状況になっている。さらには、ウイルスによるシステム破壊、不正アクセスによる情報漏洩などの脅威に対しても適切に対応し、利用者が安心してサービスを利用できるようにする必要がある。しかしながら、残念なことに、世界のあちらこちらで重要な情報システム障害が発生している。情報システムの障害は個々の利用者に重大な不利益を与えるだけでなく、サービス提供者にとっては本来得られる収益を無にし、時には莫大な補償金の支払いを要求され、企業のブランド価値の毀損につながり、事業の継続が困難になる可能性も出てくる。したがって、サービス提供者には最大限事故を起こさないようにする事に加え、事故が起こった際の説明責任が当初より課されていると考えるべきであろう。
システム障害の原因を見ると、システム構築の際にすべての構成要素を理解することが不可能であったために発生したもの、利用の量や利用の仕方が当初の設計値を超えたことによるもの、利用者の要求変化に応えるためにシステムを変更した際に発生したシステム動作の不整合によるもの、などが顕著である。これらの障害原因を見ると、現代のシステムは作られ方の観点でも、使われ方の観点でも、もはやシステムの機能や構造、境界が定義可能な固定的なシステムとして取り扱うことは困難であり、当初より時間の経過とともにそれらが変化しつづけるシステムとして取り扱うことが妥当であると思われる。
本プロジェクトは、変化しつづける目的や環境の中でシステムを適切に対応させ、継続的にユーザが求めるサービスを提供することができるシステムの構築法を開発することを目標としている。そのためには、これまで機能、構造、境界が固定的なシステムを対象に考えられてきたディペンダビリティ技術だけでは不十分であることを示し、新たな構築法の基礎となる概念として、「オープンシステムディペンダビリティ」の考え方を提案し、これをもとにした新たな構築法として、DEOSプロセスと呼ばれる反復的プロセス、これを実現するアーキテクチャ、そしてそれらに必要な要素技術群について述べる。
1.2. DEOSプロジェクトの経緯、目的、予定される成果
「実用化を目指した組込みシステム用ディペンダブル・オペレーティングシステム」（DEOSプロジェクト）は、JST/CREST†の研究領域のひとつとして、２００６年１０月に開始された。今日ではほとんどの組込みシステムがネットワークを介してサーバ群と接続され、全体としてサービスを提供する形をとっていることから、本プロジェクトでは組込みシステムを広くとらえ、（汎用システムに対する）専用システムのためのディペンダブルなオペレーティングシステムを開発することとした。また、「オペレーティングシステム」については、これも広くとらえ、オペレーティングシステムを含む「システムソフトウェア」とし、これを構築するために必要なツール群も含めることとした。
さらに、プロジェクトメンバーによるディペンダビリティに関する深い議論の結果、巨大で複雑、かつ変化しつづける目的や環境に対応しなければならない近年の情報システムは閉鎖型システム（Closed Systems）として捉えることは難しく、開放型システム（Open Systems）として捉えることが適切であり、オープンシステムに対するディペンダビリティは、反復的なアプローチとして達成すべきものであるとの結論に至った。そして、我々の開発の基本概念として後述する「オープンシステムディペンダビリティ（Open Systems Dependability）」を提案し、本プロジェクトの目的を以下のように再定義した。
********************************************************************************************************************************************
変化しつづける目的や環境の中で、システムを適切に対応させ、ユーザが求めるサービスを継続的に提供することができるディペンダブルなシステムソフトウェアの方法論ならびに構築法を開発すること。 この方法論はオープンシステムディペンダビリティ（OSD）を基本概念とし、ディペンダブルシステムの構築法は、反復的なプロセス（DEOSプロセス）、これを実現するためのアーキテクチャ（DEOSアーキテクチャ）、そしてアーキテクチャを構成する要素技術などからなる。
********************************************************************************************************************************************
実際のところ、オープンシステムディペンダビリティ（OSD）の概念やDEOSプロセスはディペンダブルなシステムソフトウェアの構築に応用できるだけでなく、大規模かつ複雑で変化を許容しなければならない多くのシステムをディペンダブルに構築するための方法論になる。すなわちDEOSプロセスは広範なオープンシステムに適用できる。この意味で議論を進める時は「DEOS」を「オープンシステムのためのディペンダビリティ工学（Dependability Engineering for Open Systems）」の略記とする。一方、このWhite Paperに記したDEOSアーキテクチャは組込みシステムを含む現代の大規模で複雑なソフトウェアシステムのためのものである。この意味で議論を進める時は「DEOS」を「ディペンダブルな組込み用オペレーティングシステム（Dependable Embedded Operating Systems）」の略記とする。
本プロジェクトの成果としては以下のものを計画している。
・オープンシステムディペンダビリティ概念（OSD Concept）
➢ DEOSプロセス (DEOS Process）
➢ DEOSアーキテクチャ (DEOS Architecture)
・要求マネジメントプロセス
➢ プロセス仕様
- 要求抽出・リスク分析
- ステークホルダ合意
➢ プロセス支援ツール
- 合意形成†支援ツール（D-Case† Editor、D-Case† Viewer）
- 合意記述言語（D-Case†、D-Case† Pattern）
- 実行手続き記述言語（D-Script）
・DEOS 実行環境（DEOS Runtime Environment：D-RE）
➢ D-RE 仕様
➢ D-RE リファレンスコード
・DEOS 開発支援ツール（DEOS Development Support Tools：D-DST）
➢ DS-Bench/Test-Env
➢ Model/Type Checker
・各種要素技術（各要素技術仕様書、API定義書、コード、実装ガイドライン等）
・規格・標準・ガイドライン
・DEOSコンソーシアムの設立
さらに、プロジェクトメンバーによるディペンダビリティに関する深い議論の結果、巨大で複雑、かつ変化しつづける目的や環境に対応しなければならない近年の情報システムは閉鎖型システム（Closed Systems）として捉えることは難しく、開放型システム（Open Systems）として捉えることが適切であり、オープンシステムに対するディペンダビリティは、反復的なアプローチとして達成すべきものであるとの結論に至った。そして、我々の開発の基本概念として後述する「オープンシステムディペンダビリティ（Open Systems Dependability）」を提案し、本プロジェクトの目的を以下のように再定義した。
********************************************************************************************************************************************
変化しつづける目的や環境の中で、システムを適切に対応させ、ユーザが求めるサービスを継続的に提供することができるディペンダブルなシステムソフトウェアの方法論ならびに構築法を開発すること。 この方法論はオープンシステムディペンダビリティ（OSD）を基本概念とし、ディペンダブルシステムの構築法は、反復的なプロセス（DEOSプロセス）、これを実現するためのアーキテクチャ（DEOSアーキテクチャ）、そしてアーキテクチャを構成する要素技術などからなる。
********************************************************************************************************************************************
実際のところ、オープンシステムディペンダビリティ（OSD）の概念やDEOSプロセスはディペンダブルなシステムソフトウェアの構築に応用できるだけでなく、大規模かつ複雑で変化を許容しなければならない多くのシステムをディペンダブルに構築するための方法論になる。すなわちDEOSプロセスは広範なオープンシステムに適用できる。この意味で議論を進める時は「DEOS」を「オープンシステムのためのディペンダビリティ工学（Dependability Engineering for Open Systems）」の略記とする。一方、このWhite Paperに記したDEOSアーキテクチャは組込みシステムを含む現代の大規模で複雑なソフトウェアシステムのためのものである。この意味で議論を進める時は「DEOS」を「ディペンダブルな組込み用オペレーティングシステム（Dependable Embedded Operating Systems）」の略記とする。
本プロジェクトの成果としては以下のものを計画している。
・オープンシステムディペンダビリティ概念（OSD Concept）
➢ DEOSプロセス (DEOS Process）
➢ DEOSアーキテクチャ (DEOS Architecture)
・要求マネジメントプロセス
➢ プロセス仕様
- 要求抽出・リスク分析
- ステークホルダ合意
➢ プロセス支援ツール
- 合意形成†支援ツール（D-Case† Editor、D-Case† Viewer）
- 合意記述言語（D-Case†、D-Case† Pattern）
- 実行手続き記述言語（D-Script）
・DEOS 実行環境（DEOS Runtime Environment：D-RE）
➢ D-RE 仕様
➢ D-RE リファレンスコード
・DEOS 開発支援ツール（DEOS Development Support Tools：D-DST）
➢ DS-Bench/Test-Env
➢ Model/Type Checker
・各種要素技術（各要素技術仕様書、API定義書、コード、実装ガイドライン等）
・規格・標準・ガイドライン
・DEOSコンソーシアムの設立
2. ディペンダビリティ
2.1. 考え方の変遷
1960年代になると、コンピュータの実時間かつミッションクリティカルな利用に対応するためにフォルトトレラント計算機（Fault Tolerant Computer）が提唱され、活発な議論がなされるようになった［15、19］。その後、ハードウェアならびにソフトウェア規模の増大やオンラインサービスの普及に伴い、故障しにくい性質（信頼性 Reliability）、高い稼働率を維持する性質（可用性 Availability）、障害が発生した場合に迅速に復旧できる性質（保守性 ServiceabilityあるいはMaintainability）と言った３つの性質を一体化したRAS（ラス）という概念が出され、システムのエラー検出と回復に重点を置いて発展していった［8、14］。1970年代後半にはこれにデータ†が矛盾を起こさずに一貫性を保つ性質（保全性 Integrity）、機密性が高く不正にアクセスされにくい性質（安全性 Security） を加え、RASを拡張したRASIS（レイシス）という概念でシステムを評価するようになってきた。2000年代に入ると、ネットワークで結合された複雑なシステムを想定し、自律神経系を模したシステム構成によりできる限り自律的にディペンダビリティを確保しようとする自律型コンピューティング （Autonomic Computing）の考え方が提案された［9、10、11、16、51］。
情報システムのディペンダビリティの実現に欠かすことができないソフトウェア開発手法についても変遷が見られる。構造化プログラミング（Dijkstra [29]）やオブジェクト指向プログラミング（SIMULA [30]、Smalltalk [54]）のようなプログラミング手法から始まったソフトウェア開発手法は、その後、ソフトウェア開発プロジェクトのマネジメント手法へと発展し、さらにはソフトウェアの開発プロセス（CMM [31,32]、CMMI [33]）へと視点が移った。また、複雑な大規模システムの開発手法に関するプロジェクト（System of Systems、Ultra-Large-Scale Systems [34]）もスタートしている。また、CoBITやITILでは、企業・自治体といった組織におけるITガバナンスやITサービスマネジメントのベストプラクティスをまとめている。
信頼性や安全性に対する考え方の変化は国際標準においても表れている。信頼性に関する国際標準としては、IEC60300シリーズがディペンダビリティマネジメントの規格として知られている。これらの規格を策定しているIEC TC56はもともと電子部品の信頼性に関するテクニカルコミッティであったことから、IEC 60300シリーズの核となるIEC 60300-1（2003年版）の規格はソフトウェアを含む形で十分議論されていない。そのため現在の改訂作業ではディペンダビリティマネジメントの対象を製品・システム・サービス・プロセスに拡大して展開している。国際安全規格ISO 13849-1 （EN954-1） や電気安全規格IEC 60204-1は単純な部品や機器などに関するもので、ソフトウェアを含むシステムに対応していなかった。ソフトウェアを含むシステムの安全規格の必要性から2000年に機能安全規格IEC 61508が制定された。IEC 61508では機器の障害を「不規則なハードウェア故障」と「系統的障害」に分ける。前者は部品の劣化による故障から故障確率を算出し、後者はシステムの設計・開発・製造、保守・運用に起因する障害を安全ライフサイクルに基づいた手順と文書化およびV字モデルなどによるソフトウェア検証により許容目標値以下にする。また、このようにして設計・開発・製造されたシステムに対し、運転モードを低需要運転モードと高需要/連続運転モードに分け、それぞれのモード毎に目標故障限度を定め、安全完全性レベルSafety Integrity Level （SIL）として管理する。SIL1からSIL4までの４段階で要求レベルが規定されている（SIL4が最も高い安全完全性を要求する）。IEC 61508をもとに、機械類関連のIEC 62061、プロセス関連IEC 61511、原子力関連IEC 61513、鉄道関連IEC 62278、などが規定され、自動車関連ではISO 26262の国際規格原案（DIS）が2009年6月に発行され、2011年に制定される予定である。
また、多くの考え方をまとめてディペンダビリティに関する定義を統一化しようとする試みも続けられ、1980年にIFIP WG10.4 on "Dependable Computing and Fault Tolerance”とIEEE TC on Fault Tolerant Computingは合同で「ディペンダビリティの基本概念と用語法」に関する検討が開始された。その検討の経緯と結果をまとめた論文が2004年に出版された［2、3］。
しかしながら、ディペンダビリティの研究やそれに基づいた技術の開発にもかかわらず、近年においても大規模ソフトウェアシステムの障害が発生している。それらのいくつかの例を付録A.4 に挙げた。障害原因を分析すると、システム構築の際に全ての構成要素を理解しないまま開発を進めたことによるもの、利用者数やトランザクション数、さらにはデータ†量や処理範囲が当初の設計値を越えたことによるもの、利用者の要求変化に応えるために機能を追加・変更した際に発生したシステムの動作の不整合によるもの、などが顕著である。加えて、プログラマーやオペレータによる不用意なミスが連鎖的にシステム全体のダウンを引き起こした例もある。
ディペンダビリティに関する考え方は時代の要求にこたえるようにこれまでも大きく変化してきている。しかしながら、これまでの考え方は、今我々が対象とするようなシステム、すなわち、変化しつづける目的や環境の中でシステムを適切に対応させ、継続的にユーザが求めるサービスを提供することを可能とする大規模システムを対象としたとき、必ずしも十分ではない。なぜなら、現代のシステムは、作られ方の観点でも、使われ方の観点でも、もはやシステムの機能や構造、システムの境界が定義可能な固定的なシステムとして取り扱う事は困難であり、当初より時間の経過とともにそれらが変化するシステムとして取り扱う事が妥当であると思われる。以下に現代のシステムの特徴と障害要因を整理したあと、現代のシステムのための新しいディペンダビリティの考え方を提案する。
情報システムのディペンダビリティの実現に欠かすことができないソフトウェア開発手法についても変遷が見られる。構造化プログラミング（Dijkstra [29]）やオブジェクト指向プログラミング（SIMULA [30]、Smalltalk [54]）のようなプログラミング手法から始まったソフトウェア開発手法は、その後、ソフトウェア開発プロジェクトのマネジメント手法へと発展し、さらにはソフトウェアの開発プロセス（CMM [31,32]、CMMI [33]）へと視点が移った。また、複雑な大規模システムの開発手法に関するプロジェクト（System of Systems、Ultra-Large-Scale Systems [34]）もスタートしている。また、CoBITやITILでは、企業・自治体といった組織におけるITガバナンスやITサービスマネジメントのベストプラクティスをまとめている。
信頼性や安全性に対する考え方の変化は国際標準においても表れている。信頼性に関する国際標準としては、IEC60300シリーズがディペンダビリティマネジメントの規格として知られている。これらの規格を策定しているIEC TC56はもともと電子部品の信頼性に関するテクニカルコミッティであったことから、IEC 60300シリーズの核となるIEC 60300-1（2003年版）の規格はソフトウェアを含む形で十分議論されていない。そのため現在の改訂作業ではディペンダビリティマネジメントの対象を製品・システム・サービス・プロセスに拡大して展開している。国際安全規格ISO 13849-1 （EN954-1） や電気安全規格IEC 60204-1は単純な部品や機器などに関するもので、ソフトウェアを含むシステムに対応していなかった。ソフトウェアを含むシステムの安全規格の必要性から2000年に機能安全規格IEC 61508が制定された。IEC 61508では機器の障害を「不規則なハードウェア故障」と「系統的障害」に分ける。前者は部品の劣化による故障から故障確率を算出し、後者はシステムの設計・開発・製造、保守・運用に起因する障害を安全ライフサイクルに基づいた手順と文書化およびV字モデルなどによるソフトウェア検証により許容目標値以下にする。また、このようにして設計・開発・製造されたシステムに対し、運転モードを低需要運転モードと高需要/連続運転モードに分け、それぞれのモード毎に目標故障限度を定め、安全完全性レベルSafety Integrity Level （SIL）として管理する。SIL1からSIL4までの４段階で要求レベルが規定されている（SIL4が最も高い安全完全性を要求する）。IEC 61508をもとに、機械類関連のIEC 62061、プロセス関連IEC 61511、原子力関連IEC 61513、鉄道関連IEC 62278、などが規定され、自動車関連ではISO 26262の国際規格原案（DIS）が2009年6月に発行され、2011年に制定される予定である。
また、多くの考え方をまとめてディペンダビリティに関する定義を統一化しようとする試みも続けられ、1980年にIFIP WG10.4 on "Dependable Computing and Fault Tolerance”とIEEE TC on Fault Tolerant Computingは合同で「ディペンダビリティの基本概念と用語法」に関する検討が開始された。その検討の経緯と結果をまとめた論文が2004年に出版された［2、3］。
しかしながら、ディペンダビリティの研究やそれに基づいた技術の開発にもかかわらず、近年においても大規模ソフトウェアシステムの障害が発生している。それらのいくつかの例を付録A.4 に挙げた。障害原因を分析すると、システム構築の際に全ての構成要素を理解しないまま開発を進めたことによるもの、利用者数やトランザクション数、さらにはデータ†量や処理範囲が当初の設計値を越えたことによるもの、利用者の要求変化に応えるために機能を追加・変更した際に発生したシステムの動作の不整合によるもの、などが顕著である。加えて、プログラマーやオペレータによる不用意なミスが連鎖的にシステム全体のダウンを引き起こした例もある。
ディペンダビリティに関する考え方は時代の要求にこたえるようにこれまでも大きく変化してきている。しかしながら、これまでの考え方は、今我々が対象とするようなシステム、すなわち、変化しつづける目的や環境の中でシステムを適切に対応させ、継続的にユーザが求めるサービスを提供することを可能とする大規模システムを対象としたとき、必ずしも十分ではない。なぜなら、現代のシステムは、作られ方の観点でも、使われ方の観点でも、もはやシステムの機能や構造、システムの境界が定義可能な固定的なシステムとして取り扱う事は困難であり、当初より時間の経過とともにそれらが変化するシステムとして取り扱う事が妥当であると思われる。以下に現代のシステムの特徴と障害要因を整理したあと、現代のシステムのための新しいディペンダビリティの考え方を提案する。
2.2. 現代のシステムの特徴と障害要因
現代の大規模ソフトウェアシステムは利用者の多種多様なニーズに対応するために高度化、巨大化、複雑化の一途をたどっている。このようなシステムの開発においては、開発期間を短縮し、開発コストを下げるため、既存のソフトウェアを再利用し、あるいは他社から供給されるソフトウェア部品をブラックボックスとして使うケースが増えて来ている。また、システム運用中にサービスの向上や変更のための仕様変更が行われ、システムのサービスを中断することなく、ネットワークを介して修正がダウンロードされることも一般的である。そのため、開発からサービス終了に至るすべての時点に対して、設計者・開発者や運用者がシステムの隅々まで完全に理解することが極めて難しくなって来ている（図１参照）。
現代のソフトウェアシステムの多くは、ネットワークを介して他のシステムと接続された形でサービスを提供している。利用者は直接的には一つのサービスドメインが提供するサービスを利用するが、間接的に他のサービスドメインが提供するサービスを利用していることがある。そしてそれらのサービスドメインは異なる所有者によって所有され、運用されていることが多い。その場合、サービスの項目や内容、処理性能、インタフェース仕様などが十分に告知されないまま変更される可能性があり、未知のサービスが適用されたり、時にはサービスが終了される場合もある。ネットワーク自体のサービス項目や内容、処理性能、インタフェース仕様も変更されたり、一時的にサービスが停止することもある。このように、利用者から見たとき、あるいはシステム開発者から見たときに、システムあるいはサービスドメインの境界も不明確となる。これに加えて、あるいは悪意を持った攻撃者が意図的に攻撃してくる恐れもある。このように、ネットワーク化に伴う予測不能性が増えている（図２参照）。
（１）不完全さ
要求に対して仕様が完全でなく、また、仕様に対して実装が完全でなく、出荷時や運用時のシステムの振る舞いを完全に把握することが困難であること。この障害要因の例として以下のものがあげられる：
・システムが多くのソフトウェアの組合せから作られており、巨大化、複雑化に伴い網羅的な仕様記述やテストが不可能
・要求・仕様・設計・実装・テストなどの各開発フェーズにおける理解の違い、文書の誤りなどによる仕様ミスや漏れ、設計ミスや漏れ、実装ミスや漏れ、テストミスや漏れ
・管理、運用、保守における変更や修正の失敗やライセンスの期限切れ
・ブラックボックスソフトウェアやレガシーコードの動作と仕様の不一致
（２）不確実さ
事業者や利用者の要求やシステム環境がライフサイクルを通して変化し、設計時や運用時に機能や挙動を完全に予測できない事。この障害要因の例として以下が挙げられる：
・事業者の事業目的の変化によるシステムへの要求の変化
・利用者の要求の変化、システムへの期待値の変化、操作能力や習熟度の変化、など
・出荷数・使用者数の増加、稼働経済性の変化による使われ方の変容
・上記変容に対応するため現場で（人手を介して、ネットワークを介して）構成要素の機能修正やサービス変更、システムの再構成を行う事（複雑性の増加）
・ネットワークを介した環境による想定外の接続・インタラクションの増加、外部からの意図的な攻撃を受ける事
すなわち、現代の大規模ソフトウェアシステムは不完全さと不確実さを完全に排除することが極めて困難である。このため、全ての障害を完全に回避することは極めて難しい状況にある。
現代の大規模ソフトウェアシステムの状況を我々と同様に理解して、これまでにもディペンダビリティを定義するためにいろいろな表現が試みられてきた。たとえば、「故障や障害がまったく起こらない状態が望ましいが、異常が発生した時には直ちに状況が把握でき、先の状況が予測可能であり、社会的なパニックやカタストロフィックな破綻を引き起こさない事が保障できる状態を、適正なコストで維持し続けること」［7］や「様々なアクシデントがあったとしても、システムが提供するサービスを、利用者が許容できるレベルで維持すること」［17］がある。
われわれは全ての障害を完全に回避することが困難であるとしても、致命的な障害の発生をできる限り減らし、万が一障害が発生した場合には被害を最小にし、同様な障害の再発を防止し、説明責任を果たし、事業を継続可能とするための方法や技術を開発することはできると考えている。我々はこのことを目標とし、以下にディペンダビリティを再定義し、そのための方法ならびに技術を開発する。
要求に対して仕様が完全でなく、また、仕様に対して実装が完全でなく、出荷時や運用時のシステムの振る舞いを完全に把握することが困難であること。この障害要因の例として以下のものがあげられる：
・システムが多くのソフトウェアの組合せから作られており、巨大化、複雑化に伴い網羅的な仕様記述やテストが不可能
・要求・仕様・設計・実装・テストなどの各開発フェーズにおける理解の違い、文書の誤りなどによる仕様ミスや漏れ、設計ミスや漏れ、実装ミスや漏れ、テストミスや漏れ
・管理、運用、保守における変更や修正の失敗やライセンスの期限切れ
・ブラックボックスソフトウェアやレガシーコードの動作と仕様の不一致
（２）不確実さ
事業者や利用者の要求やシステム環境がライフサイクルを通して変化し、設計時や運用時に機能や挙動を完全に予測できない事。この障害要因の例として以下が挙げられる：
・事業者の事業目的の変化によるシステムへの要求の変化
・利用者の要求の変化、システムへの期待値の変化、操作能力や習熟度の変化、など
・出荷数・使用者数の増加、稼働経済性の変化による使われ方の変容
・上記変容に対応するため現場で（人手を介して、ネットワークを介して）構成要素の機能修正やサービス変更、システムの再構成を行う事（複雑性の増加）
・ネットワークを介した環境による想定外の接続・インタラクションの増加、外部からの意図的な攻撃を受ける事
すなわち、現代の大規模ソフトウェアシステムは不完全さと不確実さを完全に排除することが極めて困難である。このため、全ての障害を完全に回避することは極めて難しい状況にある。
現代の大規模ソフトウェアシステムの状況を我々と同様に理解して、これまでにもディペンダビリティを定義するためにいろいろな表現が試みられてきた。たとえば、「故障や障害がまったく起こらない状態が望ましいが、異常が発生した時には直ちに状況が把握でき、先の状況が予測可能であり、社会的なパニックやカタストロフィックな破綻を引き起こさない事が保障できる状態を、適正なコストで維持し続けること」［7］や「様々なアクシデントがあったとしても、システムが提供するサービスを、利用者が許容できるレベルで維持すること」［17］がある。
われわれは全ての障害を完全に回避することが困難であるとしても、致命的な障害の発生をできる限り減らし、万が一障害が発生した場合には被害を最小にし、同様な障害の再発を防止し、説明責任を果たし、事業を継続可能とするための方法や技術を開発することはできると考えている。我々はこのことを目標とし、以下にディペンダビリティを再定義し、そのための方法ならびに技術を開発する。
2.3. オープンシステムディペンダビリティ
これまでに述べてきたように、我々が対象とするシステムは、仕様や実装の不完全性と利用者の要求や使用環境の変化に起因する不確実性を完全に排除できない。そのような性質を持つシステムはオープンシステム（開放型システム、Open Systems）であるということができる。オープンシステムを説明するために、その対極をなすクローズドシステム（閉鎖型システム、Closed Systems）と対比させてそれぞれの特徴を列挙する。
クローズドシステムの一般的な特徴は以下のとおりである（図３参照）。
・システムの境界が定義できる。
・外部との相互作用が限定的で、システムの機能が一定である。
・システムの構造（構成要素）が固定的で、構成要素間の関係が一定である。
・外部観測者視点がとれる。
・要素還元主義が成り立つ。
一方、オープンシステムの一般的な特徴は以下のとおりである（図３参照）。
・システムの境界が時間とともに変化する。
・外部との相互作用がある。システムの機能が時間とともに変化する
・システムの構造（構成要素）ならびに構成要素間の関係が時間とともに変化する。
・観測者自身がシステムに含まれるため、内部観測者視点しか取りえない。
・要素還元主義が成り立たない。
我々が対象とするシステムは機能、構造、境界が時間の経過とともに変化する、と言うオープンシステムの一般的な特徴を備えている。そして常に変化するために要素還元主義が成り立たないことがあることや、システムの所有者、設計者、開発者、運用者、利用者など、システムの開発や運用にかかわるすべての人がシステムに影響を与えるという意味で内部観測者であるということも納得できる。
対象システムを時点時点でクローズドシステム、すなわち時間的な変化がないシステムとしてとらえ、その継続としてディペンダビリティを考えてゆくことも一見可能のように思われる。これまでのディペンダブルシステムの開発は、主にこの視点で行われてきたと考えられる。この場合には、それぞれの時点でシステムの境界を定義し、システムの機能を確定し、仕様を策定し、これに基づいてシステムの設計を行い、検証、テストを行い、これを繰り返すことになる。しかしながら、通常はいくつかの変更と対応が同時並行的に進む中でサービスを継続することが行われるため、実際にはシステムを固定期間と変更期間に区別することが極めて困難である。
それであれば、我々の視点を「変化するシステム」に移し、システムの継続的変化に対するサービスや事業の継続性維持を主眼としたディペンダビリティの概念を確立すべきであろう。すなわち、我々は対象システムをオープンシステムとしてとらえ、時間の流れの中でいかにディペンダビリティを高めてゆくか、と言う視点を取ることにする。そして、現代の多くのソフトウェアシステムに特質的な問題点を捉えて、これからのディペンダビリティを「オープンシステムディペンダビリティ（OSD：Open Systems Dependability）」として次のように定義する。
********************************************************************************************************************************************
現代の大規模ソフトウェアシステムは機能、構造、システム境界が時間的に変化し、これに起因する不完全さと不確実さを完全に排除することができず、未来に障害となりうる要因（開放系障害要因）を本質的に抱えている。オープンシステムディペンダビリティとは、それらの要因を顕在化する前にできる限り取り除き、また、顕在化した後に迅速かつ適切に対応し、影響を最小とするようにマネージし、利用者が期待する便益をできる限り安全にかつ継続的に提供し、社会への説明責任を全うし、およびそれらを継続的に行う能力を言う。
********************************************************************************************************************************************
OSDはこれまで多くの研究者が研究し、議論し、整理して来たディペンダビリティの概念を否定するものではない。これまでは、システムを時点時点でとらえ、主に偶発的フォルトや意図的フォルトに焦点を当て、システムの安心安全を高めるための技術が研究され議論され開発されて来た。これに対して我々は対象を時間的に変化するシステムとしてとらえ、不完全さと不確実さに起因する開放系障害に焦点を当て、開放系障害を起こす要因の最小化と、開放系障害による影響の最小化によりシステムのディペンダビリティを向上させようと考えた。すなわちOSDはこれまでのディペンダビリティを強化するものである。
・システムの境界が定義できる。
・外部との相互作用が限定的で、システムの機能が一定である。
・システムの構造（構成要素）が固定的で、構成要素間の関係が一定である。
・外部観測者視点がとれる。
・要素還元主義が成り立つ。
一方、オープンシステムの一般的な特徴は以下のとおりである（図３参照）。
・システムの境界が時間とともに変化する。
・外部との相互作用がある。システムの機能が時間とともに変化する
・システムの構造（構成要素）ならびに構成要素間の関係が時間とともに変化する。
・観測者自身がシステムに含まれるため、内部観測者視点しか取りえない。
・要素還元主義が成り立たない。
我々が対象とするシステムは機能、構造、境界が時間の経過とともに変化する、と言うオープンシステムの一般的な特徴を備えている。そして常に変化するために要素還元主義が成り立たないことがあることや、システムの所有者、設計者、開発者、運用者、利用者など、システムの開発や運用にかかわるすべての人がシステムに影響を与えるという意味で内部観測者であるということも納得できる。
対象システムを時点時点でクローズドシステム、すなわち時間的な変化がないシステムとしてとらえ、その継続としてディペンダビリティを考えてゆくことも一見可能のように思われる。これまでのディペンダブルシステムの開発は、主にこの視点で行われてきたと考えられる。この場合には、それぞれの時点でシステムの境界を定義し、システムの機能を確定し、仕様を策定し、これに基づいてシステムの設計を行い、検証、テストを行い、これを繰り返すことになる。しかしながら、通常はいくつかの変更と対応が同時並行的に進む中でサービスを継続することが行われるため、実際にはシステムを固定期間と変更期間に区別することが極めて困難である。
それであれば、我々の視点を「変化するシステム」に移し、システムの継続的変化に対するサービスや事業の継続性維持を主眼としたディペンダビリティの概念を確立すべきであろう。すなわち、我々は対象システムをオープンシステムとしてとらえ、時間の流れの中でいかにディペンダビリティを高めてゆくか、と言う視点を取ることにする。そして、現代の多くのソフトウェアシステムに特質的な問題点を捉えて、これからのディペンダビリティを「オープンシステムディペンダビリティ（OSD：Open Systems Dependability）」として次のように定義する。
********************************************************************************************************************************************
現代の大規模ソフトウェアシステムは機能、構造、システム境界が時間的に変化し、これに起因する不完全さと不確実さを完全に排除することができず、未来に障害となりうる要因（開放系障害要因）を本質的に抱えている。オープンシステムディペンダビリティとは、それらの要因を顕在化する前にできる限り取り除き、また、顕在化した後に迅速かつ適切に対応し、影響を最小とするようにマネージし、利用者が期待する便益をできる限り安全にかつ継続的に提供し、社会への説明責任を全うし、およびそれらを継続的に行う能力を言う。
********************************************************************************************************************************************
OSDはこれまで多くの研究者が研究し、議論し、整理して来たディペンダビリティの概念を否定するものではない。これまでは、システムを時点時点でとらえ、主に偶発的フォルトや意図的フォルトに焦点を当て、システムの安心安全を高めるための技術が研究され議論され開発されて来た。これに対して我々は対象を時間的に変化するシステムとしてとらえ、不完全さと不確実さに起因する開放系障害に焦点を当て、開放系障害を起こす要因の最小化と、開放系障害による影響の最小化によりシステムのディペンダビリティを向上させようと考えた。すなわちOSDはこれまでのディペンダビリティを強化するものである。
3. オープンシステムディペンダビリティの実現
前章で定義したように、オープンシステムディペンダビリティは「変化しつづけるシステム」に対するディペンダビリティである。オープンシステムディペンダビリティの実現のためには、反復的プロセスとしてのアプローチが必須であり、そのようなプロセスは、目的や環境の変化に対してシステムを継続的に変更して行くためのサイクルと、障害に対して迅速に対応するためのサイクル、を備えていなければならないと考える。そして、それらのサイクルからなるプロセスは、構成要素として要求マネジメントプロセス、開発プロセス、通常運用プロセス、障害対応プロセス、説明責任遂行プロセスなどを含む「プロセスのプロセス（Process of Processes）」であり、それらの構成要素プロセスは相互に有機的に結びつけられていなければならないと考える。我々はそのような統合的反復プロセスとしてDEOSプロセスを提案する。
DEOSプロセスの実施にはそれを支援するためのアーキテクチャが必須である。アーキテクチャは要求マネジメントプロセスを支援するためのツール群、合意内容を収納し維持するための合意記述データ†ベース、ディペンダブルなソフトウェアを開発するためのプログラム検証やベンチマーキング、フォールトインジェクションテストなどのツール群、システムの状態を常にモニターし、記録・報告し、障害発生時に動的に対応して障害の影響を最小限にとどめるためのプログラム実行環境、などをそなえていなければならないと考える。我々はそのようなアーキテクチャとしてDEOSアーキテクチャを提案する。
DEOSプロセスの実施にはそれを支援するためのアーキテクチャが必須である。アーキテクチャは要求マネジメントプロセスを支援するためのツール群、合意内容を収納し維持するための合意記述データ†ベース、ディペンダブルなソフトウェアを開発するためのプログラム検証やベンチマーキング、フォールトインジェクションテストなどのツール群、システムの状態を常にモニターし、記録・報告し、障害発生時に動的に対応して障害の影響を最小限にとどめるためのプログラム実行環境、などをそなえていなければならないと考える。我々はそのようなアーキテクチャとしてDEOSアーキテクチャを提案する。
3.1. DEOSプロセス
対象システムのディペンダビリティに関する利害関係者をDEOSプロセスにおいては「ステークホルダ」と呼ぶ。ステークホルダとして我々は以下を想定している。
・サービス・製品の利用者（顧客、社会的インフラの場合は社会全体）
・サービス・製品の提供者（事業主）
・システム提供者
➢ 設計開発者
➢ 保守運用者
➢ ハードウェア供給者
・サービス・製品認可者（規制監督官庁）
ステークホルダは時間の経過や環境の変化によってそれぞれの目的を変化させ、機能やサービスに対する要求を変化させる可能性がある。これらの変化をここでは「目的・環境変化」と呼ぶ事とする。これらの変化に対し、ステークホルダは熟慮し、相互に合意したうえで、適切な時期にシステムの変更を要求する。DEOSプロセスはこのような要求に対するサイクルとして、「変化対応サイクル」を備える。
対象システムは不完全さと不確実さに起因する障害を完全に回避することがきわめて困難である。障害の予兆を検出した場合には障害を未然に回避し、不幸にも障害が発生してしまった場合には迅速に対応して被害を最小化し、原因を究明し、説明責任を遂行する必要がある。DEOSプロセスではそのような状況に対応するために「障害対応サイクル」を備える。
新規にシステムを開発したり、目的・環境の変化に対応してシステムの変更を行う場合、その理由やステークホルダ間で行われた議論の過程、合意内容などを詳細に記録するための合意記述データ†ベースを備えていることが効果的な反復的プロセスを実現し、説明責任を遂行するために必須である。このデータ†ベースにはディペンダビリティを達成するための議論や根拠を記述したD-Case†、障害に対してサービスを継続するためのシナリオを基に障害予兆の検出や障害発生に迅速に対応するための実行手続きを記述したD-Scriptが含まれていなければならない。そして、これらの合意記述を基に開発プロセス、障害対応プロセス、通常運用プロセスが実行され、また、説明責任遂行プロセスを支援することができる。合意記述データ†ベースは構成要素プロセスを有機的に繋ぐ重要な役割を果たす。
DEOSプロセスの特徴をまとめると、以下のとおりである（図４参照）。
・サービス・製品の利用者（顧客、社会的インフラの場合は社会全体）
・サービス・製品の提供者（事業主）
・システム提供者
➢ 設計開発者
➢ 保守運用者
➢ ハードウェア供給者
・サービス・製品認可者（規制監督官庁）
ステークホルダは時間の経過や環境の変化によってそれぞれの目的を変化させ、機能やサービスに対する要求を変化させる可能性がある。これらの変化をここでは「目的・環境変化」と呼ぶ事とする。これらの変化に対し、ステークホルダは熟慮し、相互に合意したうえで、適切な時期にシステムの変更を要求する。DEOSプロセスはこのような要求に対するサイクルとして、「変化対応サイクル」を備える。
対象システムは不完全さと不確実さに起因する障害を完全に回避することがきわめて困難である。障害の予兆を検出した場合には障害を未然に回避し、不幸にも障害が発生してしまった場合には迅速に対応して被害を最小化し、原因を究明し、説明責任を遂行する必要がある。DEOSプロセスではそのような状況に対応するために「障害対応サイクル」を備える。
新規にシステムを開発したり、目的・環境の変化に対応してシステムの変更を行う場合、その理由やステークホルダ間で行われた議論の過程、合意内容などを詳細に記録するための合意記述データ†ベースを備えていることが効果的な反復的プロセスを実現し、説明責任を遂行するために必須である。このデータ†ベースにはディペンダビリティを達成するための議論や根拠を記述したD-Case†、障害に対してサービスを継続するためのシナリオを基に障害予兆の検出や障害発生に迅速に対応するための実行手続きを記述したD-Scriptが含まれていなければならない。そして、これらの合意記述を基に開発プロセス、障害対応プロセス、通常運用プロセスが実行され、また、説明責任遂行プロセスを支援することができる。合意記述データ†ベースは構成要素プロセスを有機的に繋ぐ重要な役割を果たす。
DEOSプロセスの特徴をまとめると、以下のとおりである（図４参照）。
①「通常運用」から開始される「変化対応サイクル（青い外側ループ）」と「障害対応サイクル（赤い内側ループ）」の２つのサイクルから成り立っていること
②システム変更要求のための「ステークホルダ合意」と、システム変更や障害対応の「説明責任遂行」の２つのフェーズ（黄色いボックス）が組み入れられていること
③ステークホルダ間で利害関係を調整し、ディペンダビリティを達成するために議論した過程、論拠、結果等を記述した「D-Case†」と障害に迅速に対応するための実行手続きを記述した「D-Script」を含む合意記述データ†ベースを備え、構成要素プロセスを有機的に結合すること。
以下にDEOSプロセスを詳しく説明する。
3.1.1. 通常運用プロセス
通常運用はシステムがステークホルダ間で合意されたサービスレベル変動許容範囲（In-Operation Range）から大幅な逸脱がなく、ユーザに対してサービス提供を継続している状態である。変化対応サイクルは通常運用と並行して実行され、サービスの提供を継続しつつシステムの変更が行われることが望ましい。同様に、障害対応サイクルも通常運用を継続しながら実行されることが望ましい。実際、システムが異常の予兆を検知しても、D-Scriptに記されたサービス・機能レベル変動許容範囲内で自動的に回避処理が働いてサービスが継続される場合がある。あるいは一部の機能を縮退してサービスを継続している場合もある。しかしながらサービスの提供が完全に停止されてしまう場合もある。
運用状態において実行されるプロセスとしては、日常的な動作記録の点検、プロセスの定期的な見直し・改善、要員の訓練・しつけ・教育など、継続的なディペンダビリティ向上活動が行われる。システムの稼働状況を記録し、日々点検する事により保守担当者や運用担当者が、何かの兆候をそこから見出す事ができる可能性がある。また、システムのメモリー資源を常にクリーンな状態にすることも、非常に有効な日常保守・改善活動である。あるいは、積極的に予行を行う事も有効である。障害はある時間が経過してある状態に達した時発生する。であれば、時間を先に経過させると障害の発生を事前に知る事ができる。いわゆるリハーサルである。情報システムの提供するサービスの運用時において、どの程度適切なリハーサルができるのかは場合による。
3.1.2. 障害対応サイクル
障害対応サイクルは障害に対して迅速に対応して障害による被害を最小化するためのサイクルである。DEOSプロセスでは「障害」をステークホルダ間で合意されたサービス・機能レベル変動許容範囲から逸脱する事象と定義する。
障害対応サイクルにおける主要なフェーズは、「未然回避」、「迅速対応」、「原因究明」であり、障害が発生した場合は「説明責任遂行」が必須である。「未然回避」、「迅速対応」、「原因究明」はそれぞれ別個に、かつ順番に行われるとは限らない。多くの場合、これらはお互いが関連しあい、渾然一体となった事象・活動となる。
未然回避フェーズは、システムのオペレーション中に障害が発生する前に障害発生を予知したり、あるいは障害が起きる可能性の増大を検出すると、障害を回避するように対応・動作するフェーズである。障害の予知が障害の発生予想時刻の充分に前であれば効果的な対策が打てる。例えばシステムの資源を制限してスループットを下げてシステムダウンを回避したりシステムダウンまでの時間を稼いだりすることが行われる。直前に予知した場合には障害の影響の最小化に努力することになる。また、原因解析に有効な、障害に至るまでのシステムの内部情報を記録することができる。予知のための具体的な方法としては、過去の障害パターンから類似の障害を判別する事などがある。未然回避シナリオはD-Scriptに事前に記述され、オペレータやシステム管理者と協調して未然回避動作が実行される。
迅速対応フェーズは、障害が起きた時にその影響を最小化するためのフェーズである。障害に対する迅速対応のシナリオはD-Scriptに事前に記述されおり、自動的に行われるのが望ましい。しかしながら、想定しない障害にも対応しなければならない場面もある。対応分野や領域ごとの目的に応じたサービス継続のための緊急対応計画（責任者や対応組織、手順、エスカレーションパスなどが記されている）を事前に立てて、ステークホルダ間で合意しておく事が求められる。その計画の指示に基づきオペレータやシステム管理者と協調して迅速に障害による影響を最小化することになる。すなわち、障害を分離して影響の局所化を行い、サービス全体のダウンを回避する。そのために障害が発生したアプリケーションやシステムの一部分のオペレーションを中断し、リセットし、その後にオペレータやシステム管理者による復帰活動が行われる。
原因究明フェーズは、障害対応サイクルと変化対応サイクルに関連したフェーズである。サイクルにより深さの違う判断がなされる。障害対応サイクルでは、どのような迅速対応が可能であるかを見極めることを目的とした原因究明がおこなわれる。その結果によっては変化対応サイクルが開始される。
説明責任遂行フェーズでは、サービス提供者、特に社会インフラサービス提供者や社会に広く使われる製品提供者が、障害発生時にサービス利用者、製品使用者、社会に対し、障害状況、迅速対応、今後の見通しなど説明する。これは利用者や社会からの信頼を維持し、インフラサービス提供上のコンセンサスを醸成し、ひいてはサービス提供者のビジネス遂行上の便益を守るという大変重要な役目を持つ。合意記述データ†ベース特にD-Case†記述と、システム監視記録が説明責任遂行に大いに役立つ。
3.1.3. 変化対応サイクル
変化対応サイクルはステークホルダの目的の変化や、各種外部環境の変化に対応するためのサイクルである。このサイクルにおける主要なフェーズは、システム変更のための「要求抽出・リスク分析」、「ステークホルダ合意」、「設計・実装・検証・テスト」である。大きな変化に対応する場合は「説明責任遂行」が必須となる。障害対応サイクルにおける原因究明フェーズの実行の結果、システムの根本的な改良の要求が発生した場合も、変化対応サイクルが開始される。
要求抽出・リスク分析フェーズは目的や環境の変化によりステークホルダからの要求が変化（新規の要求も含む）した場合、あるいは障害発生に迅速に対応した後、原因究明を行った結果、システムを変更が必要である場合始まる。いずれの場合も、事業主のサービス目的をベースにユーザの要求、システム環境、関連する法律や国際標準を勘案し、システムの機能要件を抽出する。また同時に、サービス目的からシステムのサービス継続シナリオを作成してリスク分析を行い、ディペンダビリティ要件を含む非機能要件を抽出する。
ステークホルダ合意フェーズでは、何をどのように変更するのかを、すべてのステークホルダに分かりやすく、誤解のないように記述し、ステークホルダ間の議論を経て、合意をD-Case†として記述する。またサービス継続シナリオを作成し、その実行手続きであるD-Scriptを作成する。要求抽出・リスク分析フェーズとステークホルダ合意フェーズが「要求マネジメントプロセス」を構成する。
設計・実証・検証・テストフェーズは、いわゆる設計開発のプロセスである。ここでは、これまで多くの研究がなされ、多くの手法やツールが出されている。優れた手法やツールは積極的に活用すべきだと考える。我々のプロジェクトではDEOSプロセスの強化のために必要なソフトウェア検証やベンチマーキング、フォールトインジェクションテストなどのツール群を開発している。
説明責任遂行フェーズでは、目的や環境変化によるステークホルダの要求変化を満たすためにシステムを変更した場合、その経緯と、いつからどのようにサービスや機能がよくなるのか（変化するのか）を説明する。また、日常のサービス遂行状況や設計開発・保守運用プロセスに関する説明が必要なときもこれに対応する。これは利用者や社会からの信頼を維持し、インフラサービス提供上のコンセンサスを醸成し、ひいてはサービス提供者のビジネス遂行上の便益を守るという大変重要な役目を持つ。合意記述データ†ベース特にD-Case†記述が説明責任遂行に大いに役立つ。
②システム変更要求のための「ステークホルダ合意」と、システム変更や障害対応の「説明責任遂行」の２つのフェーズ（黄色いボックス）が組み入れられていること
③ステークホルダ間で利害関係を調整し、ディペンダビリティを達成するために議論した過程、論拠、結果等を記述した「D-Case†」と障害に迅速に対応するための実行手続きを記述した「D-Script」を含む合意記述データ†ベースを備え、構成要素プロセスを有機的に結合すること。
以下にDEOSプロセスを詳しく説明する。
3.1.1. 通常運用プロセス
通常運用はシステムがステークホルダ間で合意されたサービスレベル変動許容範囲（In-Operation Range）から大幅な逸脱がなく、ユーザに対してサービス提供を継続している状態である。変化対応サイクルは通常運用と並行して実行され、サービスの提供を継続しつつシステムの変更が行われることが望ましい。同様に、障害対応サイクルも通常運用を継続しながら実行されることが望ましい。実際、システムが異常の予兆を検知しても、D-Scriptに記されたサービス・機能レベル変動許容範囲内で自動的に回避処理が働いてサービスが継続される場合がある。あるいは一部の機能を縮退してサービスを継続している場合もある。しかしながらサービスの提供が完全に停止されてしまう場合もある。
運用状態において実行されるプロセスとしては、日常的な動作記録の点検、プロセスの定期的な見直し・改善、要員の訓練・しつけ・教育など、継続的なディペンダビリティ向上活動が行われる。システムの稼働状況を記録し、日々点検する事により保守担当者や運用担当者が、何かの兆候をそこから見出す事ができる可能性がある。また、システムのメモリー資源を常にクリーンな状態にすることも、非常に有効な日常保守・改善活動である。あるいは、積極的に予行を行う事も有効である。障害はある時間が経過してある状態に達した時発生する。であれば、時間を先に経過させると障害の発生を事前に知る事ができる。いわゆるリハーサルである。情報システムの提供するサービスの運用時において、どの程度適切なリハーサルができるのかは場合による。
3.1.2. 障害対応サイクル
障害対応サイクルは障害に対して迅速に対応して障害による被害を最小化するためのサイクルである。DEOSプロセスでは「障害」をステークホルダ間で合意されたサービス・機能レベル変動許容範囲から逸脱する事象と定義する。
障害対応サイクルにおける主要なフェーズは、「未然回避」、「迅速対応」、「原因究明」であり、障害が発生した場合は「説明責任遂行」が必須である。「未然回避」、「迅速対応」、「原因究明」はそれぞれ別個に、かつ順番に行われるとは限らない。多くの場合、これらはお互いが関連しあい、渾然一体となった事象・活動となる。
未然回避フェーズは、システムのオペレーション中に障害が発生する前に障害発生を予知したり、あるいは障害が起きる可能性の増大を検出すると、障害を回避するように対応・動作するフェーズである。障害の予知が障害の発生予想時刻の充分に前であれば効果的な対策が打てる。例えばシステムの資源を制限してスループットを下げてシステムダウンを回避したりシステムダウンまでの時間を稼いだりすることが行われる。直前に予知した場合には障害の影響の最小化に努力することになる。また、原因解析に有効な、障害に至るまでのシステムの内部情報を記録することができる。予知のための具体的な方法としては、過去の障害パターンから類似の障害を判別する事などがある。未然回避シナリオはD-Scriptに事前に記述され、オペレータやシステム管理者と協調して未然回避動作が実行される。
迅速対応フェーズは、障害が起きた時にその影響を最小化するためのフェーズである。障害に対する迅速対応のシナリオはD-Scriptに事前に記述されおり、自動的に行われるのが望ましい。しかしながら、想定しない障害にも対応しなければならない場面もある。対応分野や領域ごとの目的に応じたサービス継続のための緊急対応計画（責任者や対応組織、手順、エスカレーションパスなどが記されている）を事前に立てて、ステークホルダ間で合意しておく事が求められる。その計画の指示に基づきオペレータやシステム管理者と協調して迅速に障害による影響を最小化することになる。すなわち、障害を分離して影響の局所化を行い、サービス全体のダウンを回避する。そのために障害が発生したアプリケーションやシステムの一部分のオペレーションを中断し、リセットし、その後にオペレータやシステム管理者による復帰活動が行われる。
原因究明フェーズは、障害対応サイクルと変化対応サイクルに関連したフェーズである。サイクルにより深さの違う判断がなされる。障害対応サイクルでは、どのような迅速対応が可能であるかを見極めることを目的とした原因究明がおこなわれる。その結果によっては変化対応サイクルが開始される。
説明責任遂行フェーズでは、サービス提供者、特に社会インフラサービス提供者や社会に広く使われる製品提供者が、障害発生時にサービス利用者、製品使用者、社会に対し、障害状況、迅速対応、今後の見通しなど説明する。これは利用者や社会からの信頼を維持し、インフラサービス提供上のコンセンサスを醸成し、ひいてはサービス提供者のビジネス遂行上の便益を守るという大変重要な役目を持つ。合意記述データ†ベース特にD-Case†記述と、システム監視記録が説明責任遂行に大いに役立つ。
3.1.3. 変化対応サイクル
変化対応サイクルはステークホルダの目的の変化や、各種外部環境の変化に対応するためのサイクルである。このサイクルにおける主要なフェーズは、システム変更のための「要求抽出・リスク分析」、「ステークホルダ合意」、「設計・実装・検証・テスト」である。大きな変化に対応する場合は「説明責任遂行」が必須となる。障害対応サイクルにおける原因究明フェーズの実行の結果、システムの根本的な改良の要求が発生した場合も、変化対応サイクルが開始される。
要求抽出・リスク分析フェーズは目的や環境の変化によりステークホルダからの要求が変化（新規の要求も含む）した場合、あるいは障害発生に迅速に対応した後、原因究明を行った結果、システムを変更が必要である場合始まる。いずれの場合も、事業主のサービス目的をベースにユーザの要求、システム環境、関連する法律や国際標準を勘案し、システムの機能要件を抽出する。また同時に、サービス目的からシステムのサービス継続シナリオを作成してリスク分析を行い、ディペンダビリティ要件を含む非機能要件を抽出する。
ステークホルダ合意フェーズでは、何をどのように変更するのかを、すべてのステークホルダに分かりやすく、誤解のないように記述し、ステークホルダ間の議論を経て、合意をD-Case†として記述する。またサービス継続シナリオを作成し、その実行手続きであるD-Scriptを作成する。要求抽出・リスク分析フェーズとステークホルダ合意フェーズが「要求マネジメントプロセス」を構成する。
設計・実証・検証・テストフェーズは、いわゆる設計開発のプロセスである。ここでは、これまで多くの研究がなされ、多くの手法やツールが出されている。優れた手法やツールは積極的に活用すべきだと考える。我々のプロジェクトではDEOSプロセスの強化のために必要なソフトウェア検証やベンチマーキング、フォールトインジェクションテストなどのツール群を開発している。
説明責任遂行フェーズでは、目的や環境変化によるステークホルダの要求変化を満たすためにシステムを変更した場合、その経緯と、いつからどのようにサービスや機能がよくなるのか（変化するのか）を説明する。また、日常のサービス遂行状況や設計開発・保守運用プロセスに関する説明が必要なときもこれに対応する。これは利用者や社会からの信頼を維持し、インフラサービス提供上のコンセンサスを醸成し、ひいてはサービス提供者のビジネス遂行上の便益を守るという大変重要な役目を持つ。合意記述データ†ベース特にD-Case†記述が説明責任遂行に大いに役立つ。
3.2. DEOSアーキテクチャ
DEOSプロセスは広範なオープンシステムに対するディペンダビリティを実現するための反復的プロセスを提供している。このプロセスをより具体的に対象とするシステムに適用した場合、対象のカテゴリー毎にプロセス実行のためのアーキテクチャを考える必要がある。ここでは、組込みシステムを含む現代の大規模かつ複雑なソフトウェアシステムへの適応を念頭に考案されたDEOSアーキテクチャについて述べる。DEOSプロセスとDEOSアーキテクチャを並べて眺めるとDEOSプロセスが実際のシステムでどのように実行されるかが理解しやすい。
DEOSアーキテクチャは以下の構成要素からなる（図５参照）。
DEOSアーキテクチャは以下の構成要素からなる（図５参照）。
・要求抽出・リスク分析フェーズを支援するためのツール群
・ステークホルダ合意フェーズを支援する合意形成†支援ツールD-Case† Editorと D-Case† Viewer
・合意の記述であるD-Case†とサービス継続シナリオの実行手続きであるD-Scriptを含む合意記述データ†ベース（Agreement Description Database：ADD）
・DEOS実行環境（DEOS Runtime Environment：D-RE）
・プログラム検証ツールとベンチマーキングならびにフォールトインジェクションテストのためのツール群を含むDEOS開発支援ツール（DEOS Development Support Tools：D-DST）
要求抽出・リスク分析フェーズは事業主のサービス目的を基にユーザの要求、システム環境、関連する法律や国際標準を勘案し、システムの機能要件を抽出し、想定される障害に対するサービス継続シナリオを作成してリスク分析を行い、ディペンダビリティ要件を含む非機能要件を抽出する。現在そのためのツール群を開発中である。
ステークホルダ合意フェーズは合意を形成するための方法と合意記述の記法に基づいて合意内容をD-Case†として記述する。そのためのツールがD-Case† EditorならびにD-Case† Viewerである。また、サービス継続シナリオに基づいた実行手続きD-Scriptも作成される。
D-ScriptはDEOSアーキテクチャにおいてD-Case†記述とアプリケーションプログラムの実行を動的に結合する重要な役割を果たしている。D-ScriptにはD-Script Engineが実行するシナリオが書かれている。そのシナリオはD-REに対して、１）いつ、どのようなログ情報を収集するかを指示し、また、２）故障発生時においては故障に対してどのように対処するかを指示している。この時、エスカレーションルールに従ってオペレータの介入を指示する場合もある。このように、D-Scriptは動的かつ双方向に情報を交換することによりアプリケーションプログラムの実行を柔軟に制御し、オープンシステムディペンダビリティの達成に寄与している。
DEOS実行環境（D-RE）はステークホルダ合意に基づくディペンダビリティを実現するサービスを提供するための実行環境であり、次のサブシステムから構成される。D-Visorは対象システムの再構成のため、システムの構成要素の各々の独立性を担保する仕組み（System Container）を提供する。あるSystem Container内における異常や障害が他のSystem Containerに波及することを抑える働きを担っている。D-Application Managerは複数のアプリケーションの独立性を担保する仕組み（Application Container）を提供し、各アプリケーションのライフサイクル（起動、更新、停止）を管理し制御する。D-Application Monitorはアプリケーションの動作監視機能を提供し、D-Case†モニタノードの記載に従ってエビデンスを収集し、D-Boxに蓄積する。D-System Monitorはシステムの動作監視機能を提供する。D-Application Monitor同様にD-Case†モニタノードの記載に従ってエビデンスを収集し、D-Boxに蓄積する。D-Boxはエビデンスを始め、OSD実現に有益な情報を安全・確実に記録する。D-Script EngineはD-Scriptを安全・確実に実行する役割を担い、D-Application Manager、D-Application Monitor、D-System Monitorを制御する。
DEOS 開発支援ツール（D-DST）は事業目的や事業継続シナリオに基づいて決められた機能仕様、テスト仕様、ベンチマーキングシナリオ、さらにはログ仕様に基づいてプログラムを設計し、開発し、検証し、ベンチマーキングを行い、テストを行うための開発支援ツール群である。我々のプロジェクトでは現在、型理論ならびにモデル検証に基づいたソフトウェア検証ツール、ベンチマーキング並びにフォルトインジェクション機能を備えたディペンダビリティテスト支援ツールが開発されている。
・ステークホルダ合意フェーズを支援する合意形成†支援ツールD-Case† Editorと D-Case† Viewer
・合意の記述であるD-Case†とサービス継続シナリオの実行手続きであるD-Scriptを含む合意記述データ†ベース（Agreement Description Database：ADD）
・DEOS実行環境（DEOS Runtime Environment：D-RE）
・プログラム検証ツールとベンチマーキングならびにフォールトインジェクションテストのためのツール群を含むDEOS開発支援ツール（DEOS Development Support Tools：D-DST）
要求抽出・リスク分析フェーズは事業主のサービス目的を基にユーザの要求、システム環境、関連する法律や国際標準を勘案し、システムの機能要件を抽出し、想定される障害に対するサービス継続シナリオを作成してリスク分析を行い、ディペンダビリティ要件を含む非機能要件を抽出する。現在そのためのツール群を開発中である。
ステークホルダ合意フェーズは合意を形成するための方法と合意記述の記法に基づいて合意内容をD-Case†として記述する。そのためのツールがD-Case† EditorならびにD-Case† Viewerである。また、サービス継続シナリオに基づいた実行手続きD-Scriptも作成される。
D-ScriptはDEOSアーキテクチャにおいてD-Case†記述とアプリケーションプログラムの実行を動的に結合する重要な役割を果たしている。D-ScriptにはD-Script Engineが実行するシナリオが書かれている。そのシナリオはD-REに対して、１）いつ、どのようなログ情報を収集するかを指示し、また、２）故障発生時においては故障に対してどのように対処するかを指示している。この時、エスカレーションルールに従ってオペレータの介入を指示する場合もある。このように、D-Scriptは動的かつ双方向に情報を交換することによりアプリケーションプログラムの実行を柔軟に制御し、オープンシステムディペンダビリティの達成に寄与している。
DEOS実行環境（D-RE）はステークホルダ合意に基づくディペンダビリティを実現するサービスを提供するための実行環境であり、次のサブシステムから構成される。D-Visorは対象システムの再構成のため、システムの構成要素の各々の独立性を担保する仕組み（System Container）を提供する。あるSystem Container内における異常や障害が他のSystem Containerに波及することを抑える働きを担っている。D-Application Managerは複数のアプリケーションの独立性を担保する仕組み（Application Container）を提供し、各アプリケーションのライフサイクル（起動、更新、停止）を管理し制御する。D-Application Monitorはアプリケーションの動作監視機能を提供し、D-Case†モニタノードの記載に従ってエビデンスを収集し、D-Boxに蓄積する。D-System Monitorはシステムの動作監視機能を提供する。D-Application Monitor同様にD-Case†モニタノードの記載に従ってエビデンスを収集し、D-Boxに蓄積する。D-Boxはエビデンスを始め、OSD実現に有益な情報を安全・確実に記録する。D-Script EngineはD-Scriptを安全・確実に実行する役割を担い、D-Application Manager、D-Application Monitor、D-System Monitorを制御する。
DEOS 開発支援ツール（D-DST）は事業目的や事業継続シナリオに基づいて決められた機能仕様、テスト仕様、ベンチマーキングシナリオ、さらにはログ仕様に基づいてプログラムを設計し、開発し、検証し、ベンチマーキングを行い、テストを行うための開発支援ツール群である。我々のプロジェクトでは現在、型理論ならびにモデル検証に基づいたソフトウェア検証ツール、ベンチマーキング並びにフォルトインジェクション機能を備えたディペンダビリティテスト支援ツールが開発されている。
3.3. DEOSの利点
DEOSプロセスを適用する事により享受できる最大の利点は、ステークホルダ間で要求の変化に対する合意議論を充分に行う事ができ、合意結果や、その結論に至った理由や、議論の経緯をD-Case†に記録する事ができる点である。システム開発時にD-Case†記述を用いることにより、DEOSアーキテクチャと連携して、障害時に適切かつ迅速な対応を取ることが可能なシステムを設計することができる。またD-Case†記述がある事により、障害の原因究明や説明責任を果たす事がより容易になる。
DEOSプロセスのもう一つの利点は、要求が適切に抽出されリスクが充分検討されたのちに、システムの変更が実行される点である。それぞれのステークホルダはシステムの状態をどんな時点でも、それぞれの観点で知る事ができる。これによりシステムを簡潔かつ強力に管理運用する事ができる。一方、要求の数は膨大である。D-Case† EditorやD-Case† Viewerなどのツールが要求マネジメントにおける作業を軽減する。
DEOSアーキテクチャを具現化したD-REは、モニタリング機能を備え、（D-Case†を基に）解析に必要なシステムやアプリケーションの実行状態の監視と記録を実行する。 D-REはこの監視記録とD-Scriptに従って障害時の迅速対応を実行する。またD-Case†記述や監視記録から得られた情報をエビデンスとして原因分析や説明責任を遂行する。D-ScriptとD-Script EngineはD-Case†とD-REの橋渡しを果たしており、この仕組みにより、システムの自動的、あるいは必要であればオペレ―タを介した（D-Case†記述に基づく）柔軟な対応を可能にする。
またDEOS アーキテクチャは、あるモジュールにおける障害が他のモジュールに伝搬することを隔離する機能を提供する。同様にシステムのセキュリティを守るために外部からの侵入を検知する機能も提供する。またディペンダビリティ達成のための、実行前にプログラムを検証するツール、パフォーマンスを測定するツール、フォルトを埋め込んで異常時の振舞いをテストする開発ツール等も提供する。
上記の仕組みや機能を利用する事により、DEOSプロセスとDEOSアーキテクチャは、継続的な障害回避のための能力を備え、障害時には適切かつ迅速な対応をして、その影響を最小限とする。またサービスを継続し、説明責任を遂行する事ができる。DEOSプロセスとDEOSアーキテクチャはオープンシステムディペンダビリティを達成するための初めての取り組みである。
DEOSプロセスのもう一つの利点は、要求が適切に抽出されリスクが充分検討されたのちに、システムの変更が実行される点である。それぞれのステークホルダはシステムの状態をどんな時点でも、それぞれの観点で知る事ができる。これによりシステムを簡潔かつ強力に管理運用する事ができる。一方、要求の数は膨大である。D-Case† EditorやD-Case† Viewerなどのツールが要求マネジメントにおける作業を軽減する。
DEOSアーキテクチャを具現化したD-REは、モニタリング機能を備え、（D-Case†を基に）解析に必要なシステムやアプリケーションの実行状態の監視と記録を実行する。 D-REはこの監視記録とD-Scriptに従って障害時の迅速対応を実行する。またD-Case†記述や監視記録から得られた情報をエビデンスとして原因分析や説明責任を遂行する。D-ScriptとD-Script EngineはD-Case†とD-REの橋渡しを果たしており、この仕組みにより、システムの自動的、あるいは必要であればオペレ―タを介した（D-Case†記述に基づく）柔軟な対応を可能にする。
またDEOS アーキテクチャは、あるモジュールにおける障害が他のモジュールに伝搬することを隔離する機能を提供する。同様にシステムのセキュリティを守るために外部からの侵入を検知する機能も提供する。またディペンダビリティ達成のための、実行前にプログラムを検証するツール、パフォーマンスを測定するツール、フォルトを埋め込んで異常時の振舞いをテストする開発ツール等も提供する。
上記の仕組みや機能を利用する事により、DEOSプロセスとDEOSアーキテクチャは、継続的な障害回避のための能力を備え、障害時には適切かつ迅速な対応をして、その影響を最小限とする。またサービスを継続し、説明責任を遂行する事ができる。DEOSプロセスとDEOSアーキテクチャはオープンシステムディペンダビリティを達成するための初めての取り組みである。
4. DEOSプロセスにおける要求マネジメント
要求は、DEOSプロセスにおいて変化をマネジメントする上で最も基本的な要素である。本章では、要求マネジメントの観点からDEOSプロセスを説明する。
要求マネジメントは、①要求抽出・リスク分析、②要求に対するステークホルダ合意の形成、③合意された要求の実現確認と説明責任遂行、④要求変化と合意の更新という４つのフェーズからなる。合意形成†の過程で、抽出された要求は見直される事もある（図６参照）。
図６では合意された要求はプログラムとして実装されるものと、D-Scriptに変換されるものがあることを示す。D-REではD-Scriptの実行をログで記録することで説明責任を遂行する。
要求マネジメントは、①要求抽出・リスク分析、②要求に対するステークホルダ合意の形成、③合意された要求の実現確認と説明責任遂行、④要求変化と合意の更新という４つのフェーズからなる。合意形成†の過程で、抽出された要求は見直される事もある（図６参照）。
図６では合意された要求はプログラムとして実装されるものと、D-Scriptに変換されるものがあることを示す。D-REではD-Scriptの実行をログで記録することで説明責任を遂行する。
4.1. 要求の抽出とリスクの分析
要求抽出はサービス目的をもとにして始まる。サービス目的にもとづいて、ステークホルダが定義される。要求は、ステークホルダそれぞれの目的から生じる。要求にはサービス要求とサービス継続のためのディペンダビリティ要求などがあり、監督官庁が定める規制なども要求の一種として取り扱うことが可能である。要求抽出における活動は、要求をマネージするために、様々なレベルの要求識別を含まなければならない。
要求工学では、様々な要求抽出手法（1．対象世界の情報を得るための技術として：エスノメソドロジ、ボレーレ法でおこなわれるトローリング、ビジネスモデリングなど、2．要求獲得段階における技術として：ゴール指向分析、ユースケース分析、シナリオ分析、プロトタイピングなど、3．要求の取捨選択や新要求獲得技術として：ミスユースケース、トリアージなど）が提案され実践されてきた [52]。
DEOSプロセスでは要求として特にディペンダビリティ要求の抽出と分析に焦点をあてる。はじめにニーズがあいまいな形でステークホルダより引き出され、それらから、ディペンダビリティ・ニーズが得られる。次にそれらのニーズに対して分析を通じて、ディペンダビリティ要求が同定される。さらにリスク分析およびサービス要求からサービス継続シナリオが得られる。サービス継続シナリオは、サービス継続を妨げる逸脱要因に対する対策を考えることにより作成される。われわれは逸脱要因ごとにサービス継続シナリオを作成し、それに基づいてステークホルダ間の合意形成†をおこないD-Case†やD-Scriptを作成する。
DEOSプロジェクトでは、変化する要求のライフサイクル管理の視点から、抽出された要求に対して、次の３条件を満たすような要求マネジメントをおこなう。
（条件１）変化する要求に対してサービス継続性を保証できること （後述4.2節）
（条件２）変化する要求に対して逐次、合意形成†できること（後述4.2節）
（条件３）変化する要求に対して常に説明責任を遂行できること (後述 4.3節)
要求工学では、様々な要求抽出手法（1．対象世界の情報を得るための技術として：エスノメソドロジ、ボレーレ法でおこなわれるトローリング、ビジネスモデリングなど、2．要求獲得段階における技術として：ゴール指向分析、ユースケース分析、シナリオ分析、プロトタイピングなど、3．要求の取捨選択や新要求獲得技術として：ミスユースケース、トリアージなど）が提案され実践されてきた [52]。
DEOSプロセスでは要求として特にディペンダビリティ要求の抽出と分析に焦点をあてる。はじめにニーズがあいまいな形でステークホルダより引き出され、それらから、ディペンダビリティ・ニーズが得られる。次にそれらのニーズに対して分析を通じて、ディペンダビリティ要求が同定される。さらにリスク分析およびサービス要求からサービス継続シナリオが得られる。サービス継続シナリオは、サービス継続を妨げる逸脱要因に対する対策を考えることにより作成される。われわれは逸脱要因ごとにサービス継続シナリオを作成し、それに基づいてステークホルダ間の合意形成†をおこないD-Case†やD-Scriptを作成する。
DEOSプロジェクトでは、変化する要求のライフサイクル管理の視点から、抽出された要求に対して、次の３条件を満たすような要求マネジメントをおこなう。
（条件１）変化する要求に対してサービス継続性を保証できること （後述4.2節）
（条件２）変化する要求に対して逐次、合意形成†できること（後述4.2節）
（条件３）変化する要求に対して常に説明責任を遂行できること (後述 4.3節)
4.2. 要求に対するステークホルダ合意の形成
合意形成†は、ステークホルダから抽出された様々な要求を合意する過程である。D-Case†は合意形成†に用いられる。D-Case†の特徴は以下である。
(a) 議論とエビデンスに基づく合意のための、構造化された表記法
(b) ステークホルダ間合意のマネジメントサポート
(c) 通常運用時におけるステークホルダ間合意のモニタリングサポート(モニタノード)
(d) 合意内容記述の整合性検査サポート
構造化された表記は、Goal Structuring Notation (GSN†) [37, 38]を元にしている(a)。セーフティクリティカル分野では、システムの安全性を保証するために用いられる「Safety Case」がすでに広く用いられている[39,40,41,42]。現時点のD-Case†は、GSN†のノードに加えて、ステークホルダと、ステークホルダ間の合意内容の関係を表すノード(b)などを持っている。我々は、合意形成†を可視化するD-Case†ツールを開発中である。
さらに、運用時の説明責任を支援するために、D-System MonitorもしくはD-Application Monitorにログ取得を指示するモニタノードを導入する（c）。
合意文書の作成は時間がかかる。作成を容易にするために様々な適用分野におけるD-Case†パターンを用意する。またD-Case†における合意内容の整合性を確かめることは面倒である。定理証明支援器をバックエンドとした整合性自動検査機能を開発中である（d）。
D-Case†の主な部分は、以下のノードを含む構造化された文書である。ステークホルダ間で議論する主張、命題を表すゴールノード、ゴールノードをサブゴールに分割するときの説明を表すストラテ†ジノード、ゴールが満たされることを保証するエビデンスを表すエビデンスノード、システムの環境などに関する情報をあらわすコンテキストノード、そして上述のモニタリングノードがある
(a) 議論とエビデンスに基づく合意のための、構造化された表記法
(b) ステークホルダ間合意のマネジメントサポート
(c) 通常運用時におけるステークホルダ間合意のモニタリングサポート(モニタノード)
(d) 合意内容記述の整合性検査サポート
構造化された表記は、Goal Structuring Notation (GSN†) [37, 38]を元にしている(a)。セーフティクリティカル分野では、システムの安全性を保証するために用いられる「Safety Case」がすでに広く用いられている[39,40,41,42]。現時点のD-Case†は、GSN†のノードに加えて、ステークホルダと、ステークホルダ間の合意内容の関係を表すノード(b)などを持っている。我々は、合意形成†を可視化するD-Case†ツールを開発中である。
さらに、運用時の説明責任を支援するために、D-System MonitorもしくはD-Application Monitorにログ取得を指示するモニタノードを導入する（c）。
合意文書の作成は時間がかかる。作成を容易にするために様々な適用分野におけるD-Case†パターンを用意する。またD-Case†における合意内容の整合性を確かめることは面倒である。定理証明支援器をバックエンドとした整合性自動検査機能を開発中である（d）。
D-Case†の主な部分は、以下のノードを含む構造化された文書である。ステークホルダ間で議論する主張、命題を表すゴールノード、ゴールノードをサブゴールに分割するときの説明を表すストラテ†ジノード、ゴールが満たされることを保証するエビデンスを表すエビデンスノード、システムの環境などに関する情報をあらわすコンテキストノード、そして上述のモニタリングノードがある
4.3. 合意された要求の実現確認と説明責任遂行
要求が確立されるためには、ステークホルダ間で、十分な†合意がなされる必要がある。しかしながらD-Case†で合意された要求は、必ずしも実際のシステムに実装され、運用時に保守されるとは限らない。合意された要求の真の達成は、適切な実装と保守によってなされる。このことは、ステークホルダ、さらには外部評価が必要な場合は第３者機関によって確認されなければならない。
合意された要求は、実装されたシステムがその合意レベルに達するまで、開発プロセスにおいてテストされ検証されなければいけない。通常時においてステークホルダ合意からの逸脱が起こった場合は、合意内容を維持するために、D-Scriptの実行および人間の介入を含む復旧作業を行わなければならない。そのような復旧作業はD-Case†において、あらかじめ合意されておく必要がある。
合意された要求の実現の記録は、説明責任を果たすために必須である。合意が実現がされていない場合、合意形成†時のエビデンスなど、すべての情報がステークホルダに開示される。DEOSプロセスはそのような説明責任要求を満たすために、自動的にエビデンスを収集できるよう設計されている。
合意された要求は、実装されたシステムがその合意レベルに達するまで、開発プロセスにおいてテストされ検証されなければいけない。通常時においてステークホルダ合意からの逸脱が起こった場合は、合意内容を維持するために、D-Scriptの実行および人間の介入を含む復旧作業を行わなければならない。そのような復旧作業はD-Case†において、あらかじめ合意されておく必要がある。
合意された要求の実現の記録は、説明責任を果たすために必須である。合意が実現がされていない場合、合意形成†時のエビデンスなど、すべての情報がステークホルダに開示される。DEOSプロセスはそのような説明責任要求を満たすために、自動的にエビデンスを収集できるよう設計されている。
4.4. 要求の変化と合意の更新
要求マネジメントでは、上述したように、要求の状態を管理する。要求状態には、抽出、合意、通常運用、通常運用範囲からの逸脱という4種類の状態がある(図８参照)。 まず、要求がステークホルダから抽出される。 抽出された要求が互いに矛盾する可能性がある。合意形成†によって要求がステークホルダ間で合意される。合意された要求は実装されると通常運用される。 目的や環境が変化すると、通常運用されていた要求が陳腐化して新しい要求が抽出されることになる。これは変化対応サイクルである。
対応する通常運用範囲からの逸脱が発生すると、要求が逸脱状態に遷移する。迅速対応が可能なら、通常運用状態に復帰する。これは障害対応サイクルである。もし逸脱状態の要求に対してサービス継続シナリオが有効に機能しない場合、これらの要求を変更して新たな要求を抽出する必要がある。また逸脱の原因が要求ではなく、実装に問題があった場合には、実装をやり直すために、要求の合意状態に遷移する。抽出状態と合意状態の要求は開発時に管理される。これに対して通常運用状態と逸脱状態の要求は、運用時に管理される。システム状態は要求状態の集合で表現される。
4.5. DEOSプロセス適合性の評価に向けて
特定の分野やアプリケーション領域におけるDEOSプロセスとDEOSアーキテクチャに基づいて、具体的にシステムが開発された際、その対象システムに対するDEOSプロセスへの適合性評価を行わなくてはならない。そこで、本プロジェクトでは、適合性評価のための評価基準を作成している。評価は、開発中に生成されたD-Case†を通じて行われる。図９に、適合性を評価するための基準の例を挙げる。ディペンダビリティの評価は通常運用状態、障害対応サイクル、変化対応サイクルの３つに対して行われる。さらに、それぞれ、計画、実装、実行の３つの段階にさらに分けて評価する。
例として、障害対応サイクルの計画の項を考える。対象システムのD-Case†文書における障害対応サイクルの記述部分に、Service Level Agreement (SLA)に関するサブゴールがある場合を考える。SLAはWebサービス開発の契約のために広く用いられている。この項では、(1) 障害発生時に、SLAを逸脱したかについて、適切にかつ迅速に判定できるか、(2) SLAを保つことが困難になった場合、上位組織に意思決定をエスカレーションする規則がよく定義されているか、などが評価基準の例になる。
より詳細な評価基準を検討中であり、付録A.7に示す。DEOSプロセス適合性の評価は、DEOSプロセスの国際標準化においてさらに検討する予定である。
より詳細な評価基準を検討中であり、付録A.7に示す。DEOSプロセス適合性の評価は、DEOSプロセスの国際標準化においてさらに検討する予定である。
4.6. ステークホルダ合意形成支援ツール
ステークホルダ合意形成†を支援するための記述ツールD-Case† Editor [43]、および、運用時においてD-Case†から、合意実現度などをステークホルダごとに適切な形式で提示するためのツールD-Case† Viewerを開発している。図１０に、開発中のD-Case† Editorのスナップショットを示す。D-Case† Editor は、定理証明支援器Agdaとの連携による整合性の検査、DS-Bench/Test-Env やD-REやD-ScriptなどDEOSで提供する他のツールや環境との連携をサポートする。さらに、Redmineなどの開発ツールやUML†モデリングツールなど他の開発ツールとも連携し、ツールチェーンの構築を目指す。
D-Case† Editor の開発にあたっては、Safety Case記述支援ツールを開発しているイギリスAdelard社や、UML†などの標準化を行っているOMG、エンタープライズアーキテクチャの標準化団体であるOpen Groupなどと標準化活動などを通じて連携している。
D-Case† Editor の開発にあたっては、Safety Case記述支援ツールを開発しているイギリスAdelard社や、UML†などの標準化を行っているOMG、エンタープライズアーキテクチャの標準化団体であるOpen Groupなどと標準化活動などを通じて連携している。
5. システムの動作監視と柔軟な制御のための実行環境
DEOSプロセスの要諦は（1）変化対応サイクルと障害対応サイクルの同時存在であり、（2）変化対応サイクルにおけるステークホルダ間のディペンダビリティに関する合意された要求をD-Case†に記述している点であり、（3）障害対応サイクルにおける障害発生時の迅速対応や障害発生の未然回避をD-Case†に基づいて遂行できる点である。D-Case†を設計図とするなら、その実現形態が実行環境であり、そこにはステークホルダの合意された要求が反映されている。しかし、ステークホルダの要求は各種環境の変化を要因として変化するので、ある時点で合意されたD-Case†は別の時点では変化していることになる。このD-Case†の変化に実行環境は対応する必要がある。以下、実行環境が備えるべき機能を述べる。
動作監視：D-Case†に記述された対象システムがステークホルダによる合意通りに（即ち変動許容範囲で）運用され稼働しているかを監視する。その際に「合意通り」を裏付けるデータ†を収集する必要がある。ステークホルダはD-Case†モニタノードとして監視ポイントを記載している。本稿ではモニタノードで収集されたデータ†をエビデンスと呼び、ステークホルダの説明責任遂行の際のデータ†とする。
再構成：D-Case†の変化に対応するために実行環境を再構成する。その為には、システム構成要素を隔離する機能が必要である。障害発生時には障害部位を隔離し、他の部位に影響を与えないようにする。隔離の仕方や再構成の仕方は対象部位により、また実行状況により異なり、実行時の柔軟性が要求されるので、次に述べるスクリプトが必要になる。
スクリプト：システム再構成時には対象毎に異なる再構成手順を実行し、動作監視時にはモニタノードに対応して監視手順とエビデンス収集手順を実行する。これらの実行手順を記述したプログラムをスクリプトと呼ぶ。実行環境はこのスクリプトを安全・確実に実行する必要がある。
記録：動的監視により得られたエビデンス、再構成の記録、スクリプトの実行記録を始め、OSD実現に有益な情報を記録する。これらの記録は、アクセス管理、暗号化†、改竄検出を行い、情報の整合性を守る必要がある。
セキュリティ機能：動作監視、再構成、スクリプト、そして記録機能を安全に実行するためにセキュリティ機能が必要となる。
前記機能群は次のサブシステムから構成される実行環境として提供され、本セッションではこれらを総称してDEOS実行環境（D-RE：DEOS Runtime Environment）と呼ぶ（図１１参照）。以下、本節ではDEOSアーキテクチャの2構成要素であるDEOS実行環境（D-RE）とDEOS動的対応スクリプト（D-Script）に関して述べる。D-REに関しては特に動作監視とエビデンスの収集の観点から、及びアプリケーションライフサイクル管理と、セキュリティ対応の観点から述べる。D-Scriptに関しては特にD-Scriptを用いることによりOSD実現の為にシステム制御を如何に柔軟に実行するか、という観点から述べる。
動作監視：D-Case†に記述された対象システムがステークホルダによる合意通りに（即ち変動許容範囲で）運用され稼働しているかを監視する。その際に「合意通り」を裏付けるデータ†を収集する必要がある。ステークホルダはD-Case†モニタノードとして監視ポイントを記載している。本稿ではモニタノードで収集されたデータ†をエビデンスと呼び、ステークホルダの説明責任遂行の際のデータ†とする。
再構成：D-Case†の変化に対応するために実行環境を再構成する。その為には、システム構成要素を隔離する機能が必要である。障害発生時には障害部位を隔離し、他の部位に影響を与えないようにする。隔離の仕方や再構成の仕方は対象部位により、また実行状況により異なり、実行時の柔軟性が要求されるので、次に述べるスクリプトが必要になる。
スクリプト：システム再構成時には対象毎に異なる再構成手順を実行し、動作監視時にはモニタノードに対応して監視手順とエビデンス収集手順を実行する。これらの実行手順を記述したプログラムをスクリプトと呼ぶ。実行環境はこのスクリプトを安全・確実に実行する必要がある。
記録：動的監視により得られたエビデンス、再構成の記録、スクリプトの実行記録を始め、OSD実現に有益な情報を記録する。これらの記録は、アクセス管理、暗号化†、改竄検出を行い、情報の整合性を守る必要がある。
セキュリティ機能：動作監視、再構成、スクリプト、そして記録機能を安全に実行するためにセキュリティ機能が必要となる。
前記機能群は次のサブシステムから構成される実行環境として提供され、本セッションではこれらを総称してDEOS実行環境（D-RE：DEOS Runtime Environment）と呼ぶ（図１１参照）。以下、本節ではDEOSアーキテクチャの2構成要素であるDEOS実行環境（D-RE）とDEOS動的対応スクリプト（D-Script）に関して述べる。D-REに関しては特に動作監視とエビデンスの収集の観点から、及びアプリケーションライフサイクル管理と、セキュリティ対応の観点から述べる。D-Scriptに関しては特にD-Scriptを用いることによりOSD実現の為にシステム制御を如何に柔軟に実行するか、という観点から述べる。
5.1. 動作監視・記録
システムは、常に変化をともないながら運用され、いくつかの変化は想定外の状況の要因となる。動作監視（モニタリング）やログ分析は、システムの運用状況を把握し、正しく合意が履行されているか判断する基盤技術となる。
ログの内容、つまり何をモニタリングしてどの値をログとして出力するかは、D-Case†記述により決定される。さらに、D-Case†記述にはログの値の正常値、あるいは異常値を定義し、異常値に対しては複数レベルの深刻度を定義することで、変動許容範囲が記述されている。障害対策はD-Case†記述における変動許容範囲からの逸脱がおきたときにD-Scriptにより実行される。
D-REの動作監視機構は、D-Case† 記述からモニタリングパラメータを読み出し、システムの監視を始める。深刻度と変化対応サイクル／障害対応サイクルの関係は、静的に決まるものではない。モニタリングから得られた深刻度は、D-Script により適応的に実行される。たとえば、すぐに影響のない値であっても、長期的にシステムを改善する有益な情報となる。
D-REは、通信システム、D-System Monitor、OSカーネル、D-Script Engine、D-Application Monitorなど、様々なレベルで動作監視を行い、その結果はログとして記録される。D-RE は、これらのモニタリング内容とログ出力を制御するためのAPI を提供し、D-Script から制御することができる。ログは、次の３タイプに分類される。
・イベントログ：システムの境界において観測されるイベント（事象）の記録
・サンプルログ：ある一定期間ごとに利用されたリソースの利用の記録
・トレースログ：イベント事象の関連性を追跡するための記録
ログの内容、つまり何をモニタリングしてどの値をログとして出力するかは、D-Case†記述により決定される。さらに、D-Case†記述にはログの値の正常値、あるいは異常値を定義し、異常値に対しては複数レベルの深刻度を定義することで、変動許容範囲が記述されている。障害対策はD-Case†記述における変動許容範囲からの逸脱がおきたときにD-Scriptにより実行される。
D-REの動作監視機構は、D-Case† 記述からモニタリングパラメータを読み出し、システムの監視を始める。深刻度と変化対応サイクル／障害対応サイクルの関係は、静的に決まるものではない。モニタリングから得られた深刻度は、D-Script により適応的に実行される。たとえば、すぐに影響のない値であっても、長期的にシステムを改善する有益な情報となる。
D-REは、通信システム、D-System Monitor、OSカーネル、D-Script Engine、D-Application Monitorなど、様々なレベルで動作監視を行い、その結果はログとして記録される。D-RE は、これらのモニタリング内容とログ出力を制御するためのAPI を提供し、D-Script から制御することができる。ログは、次の３タイプに分類される。
・イベントログ：システムの境界において観測されるイベント（事象）の記録
・サンプルログ：ある一定期間ごとに利用されたリソースの利用の記録
・トレースログ：イベント事象の関連性を追跡するための記録
5.2. 柔軟なシステム制御
今日、スクリプト技術は、様々なサブシステム（コンポーネント）を柔軟に結びつけ、システムの機能を拡張し、実行時に動作を変更する手法として広く採用されている。 D-Scriptは、スクリプトの接続能力と実行時の変更能力を活かして、システム障害の予兆検出から回復まで記述し、ディペンダビリティ制御を実施する技術である。
D-Scriptは複数のD-Scriptシナリオで構成される。D-Scriptシナリオはサービス継続シナリオから導かれる。サービス継続シナリオはBPMN（Business Process Management Notation）[53]あるいはそれに類する記法で記述されている。D-ScriptシナリオはD-Taskと呼ばれる基本動作と、D-Controlと呼ばれる制御ノードからなる。D-Controlは逐次実行や条件分岐や並行処理を指示する。D-Scriptは新たに開発されるKonoha言語[44]によって記述される。図１２にD-Task、D-Control、D-Scriptシナリオの例を載せる。
システムの変更時にはD-Scriptシナリオも変更される。D-Scriptシナリオは想定外の障害が起きた場合には変更されなくてはいけなくなる。このような変更はD-Case†に記されているエスカレーションルールに従って実施されなくてはいけない。
D-Script はD-Script Engine 上で実行され、D-System MonitorとD-Application Monitorにシステムやアプリケーションの状態に関する情報を集めるための指示を出す。これらの情報が合意された変動許容範囲を逸脱した場合、D-Script Engine は対応するD-Scriptシナリオを実行する。D-Script Engine は、静的な型検査可能コンパイラを搭載し、実行前にスクリプトの型安全性と最適化された実行コードに変換され、TCB（Trusted Computing Base）などのハードウェア支援セキュリティ防御機構と共に動作する。加えて、D-Script Engineは、D-Task モニタリング、 サンプリングによるリソースモニタリング、境界面におけるイベントモニタリングやロギングを提供する。これらが、障害対応の状況を分析するのを助け、説明責任の遂行を向上する。
D-Scriptは複数のD-Scriptシナリオで構成される。D-Scriptシナリオはサービス継続シナリオから導かれる。サービス継続シナリオはBPMN（Business Process Management Notation）[53]あるいはそれに類する記法で記述されている。D-ScriptシナリオはD-Taskと呼ばれる基本動作と、D-Controlと呼ばれる制御ノードからなる。D-Controlは逐次実行や条件分岐や並行処理を指示する。D-Scriptは新たに開発されるKonoha言語[44]によって記述される。図１２にD-Task、D-Control、D-Scriptシナリオの例を載せる。
システムの変更時にはD-Scriptシナリオも変更される。D-Scriptシナリオは想定外の障害が起きた場合には変更されなくてはいけなくなる。このような変更はD-Case†に記されているエスカレーションルールに従って実施されなくてはいけない。
D-Script はD-Script Engine 上で実行され、D-System MonitorとD-Application Monitorにシステムやアプリケーションの状態に関する情報を集めるための指示を出す。これらの情報が合意された変動許容範囲を逸脱した場合、D-Script Engine は対応するD-Scriptシナリオを実行する。D-Script Engine は、静的な型検査可能コンパイラを搭載し、実行前にスクリプトの型安全性と最適化された実行コードに変換され、TCB（Trusted Computing Base）などのハードウェア支援セキュリティ防御機構と共に動作する。加えて、D-Script Engineは、D-Task モニタリング、 サンプリングによるリソースモニタリング、境界面におけるイベントモニタリングやロギングを提供する。これらが、障害対応の状況を分析するのを助け、説明責任の遂行を向上する。
5.3. アプリケーションライフサイクル管理
OSD実現のためには、DEOSプロセスに従ってD-REがアプリケーションを管理する必要がある。D-Application Monitorはアプリケーションの動作を監視し、D-Application Managerはアプリケーションを管理する。D-REはこのような機能のためのAPIを提供する。このAPIを使ったアプリケーションをD-Aware Applicationと呼ぶ。以下にアプリケーションライフサイクルの状態とD-Application Managerの役割を記す。
生成：アプリケーションはD-Application Managerの提供するAPIを用いて安全にシステムに登録される。D-Case†にはアプリケーションに関して必要な計算資源量の見積もり、監視点リストと基準データ†、構成情報、等が記載されており、D-Application Managerはそれらの情報をもとに実行環境を構成する。
実行：他のシステムから、あるいは管理者から、D-Application Managerによりアプリケーションは起動される。その際にD-Application Managerはアプリケーションの実行を監視するために必要な準備も整える。例えば、監視点から取得されるデータ†をD-Boxに記録するためのパスを確立したり、アプリケーションの実行中状態を記録するためのスナップショット機能を初期化したり、再構成に備えたスクリプト実行環境を初期化したりする。
変更：現在実行中のアプリケーションに対応したD-Case†が変更されたときには、アプリケーションの実行環境を再構成する。その手順はアプリケーション毎に異なるのでD-Scriptで記述する。
終了：アプリケーションを終了するときにはD-Application Managerの提供するAPIを用いる。その結果、アプリケーションが占有していた計算資源の開放が行われ、その終了がD-Boxに記録される。
D-Application Managerは既存のアプリケーション（Legacy Application）にも基本的な監視サービスを提供するが、それはApplication Containerで実行されるアプリケーションに限られる。
生成：アプリケーションはD-Application Managerの提供するAPIを用いて安全にシステムに登録される。D-Case†にはアプリケーションに関して必要な計算資源量の見積もり、監視点リストと基準データ†、構成情報、等が記載されており、D-Application Managerはそれらの情報をもとに実行環境を構成する。
実行：他のシステムから、あるいは管理者から、D-Application Managerによりアプリケーションは起動される。その際にD-Application Managerはアプリケーションの実行を監視するために必要な準備も整える。例えば、監視点から取得されるデータ†をD-Boxに記録するためのパスを確立したり、アプリケーションの実行中状態を記録するためのスナップショット機能を初期化したり、再構成に備えたスクリプト実行環境を初期化したりする。
変更：現在実行中のアプリケーションに対応したD-Case†が変更されたときには、アプリケーションの実行環境を再構成する。その手順はアプリケーション毎に異なるのでD-Scriptで記述する。
終了：アプリケーションを終了するときにはD-Application Managerの提供するAPIを用いる。その結果、アプリケーションが占有していた計算資源の開放が行われ、その終了がD-Boxに記録される。
D-Application Managerは既存のアプリケーション（Legacy Application）にも基本的な監視サービスを提供するが、それはApplication Containerで実行されるアプリケーションに限られる。
5.4. セキュリティ対応
OSDを高めるためには、システムのセキュリティ機構はさまざまな脅威に対処可能な仕組みを備えていなければならない。近年のセキュリティへの意識の高まりとともに、認証 (Authentication) や認可(Authorization)、アクセス制御 (Access Control) などの OS に組み込まれるセキュリティ機構も充実してきている。本節では、OS の備えるセキュリティ機構を監視し、その正当な動作を保証する仕組みを概説する。
このような仕組みを提供することで、OS を乗っ取り、そのセキュリティ機構を無効化するという攻撃が難しくなる。OS の乗っ取りは極めて深刻な脅威である。なぜなら、セキュリティ実現のための要である OS が乗っ取られれば、あらゆるセキュリティ機構が信頼できなくなり、どんなに強固なセキュリティ機構であっても信頼することができなくなってしまうからである。そのような攻撃を防御することで、OS の備えるセキュリティ機構そのものを頑健にする。
攻撃は常に進化し続けるため、新たなマルウェアの検体が見つかった場合や新しい攻撃手法の発見に対して、常に柔軟に対応しなければならない。本プロジェクトでは、一度の対策でより多くの攻撃を検知して障害対応サイクルを円滑に回す技術、ならびに未知の攻撃への対策を支援して変化対応サイクルを円滑に回すための技術を提供する。
このような仕組みを提供することで、OS を乗っ取り、そのセキュリティ機構を無効化するという攻撃が難しくなる。OS の乗っ取りは極めて深刻な脅威である。なぜなら、セキュリティ実現のための要である OS が乗っ取られれば、あらゆるセキュリティ機構が信頼できなくなり、どんなに強固なセキュリティ機構であっても信頼することができなくなってしまうからである。そのような攻撃を防御することで、OS の備えるセキュリティ機構そのものを頑健にする。
攻撃は常に進化し続けるため、新たなマルウェアの検体が見つかった場合や新しい攻撃手法の発見に対して、常に柔軟に対応しなければならない。本プロジェクトでは、一度の対策でより多くの攻撃を検知して障害対応サイクルを円滑に回す技術、ならびに未知の攻撃への対策を支援して変化対応サイクルを円滑に回すための技術を提供する。
OSDを高めるためには、システムのセキュリティ機構はさまざまな脅威に対処可能な仕組みを備えていなければならない。近年のセキュリティへの意識の高まりとともに、認証 (Authentication) や認可(Authorization)、アクセス制御 (Access Control) などの OS に組み込まれるセキュリティ機構も充実してきている。本節では、OS の備えるセキュリティ機構を監視し、その正当な動作を保証する仕組みを概説する。
このような仕組みを提供することで、OS を乗っ取り、そのセキュリティ機構を無効化するという攻撃が難しくなる。OS の乗っ取りは極めて深刻な脅威である。なぜなら、セキュリティ実現のための要である OS が乗っ取られれば、あらゆるセキュリティ機構が信頼できなくなり、どんなに強固なセキュリティ機構であっても信頼することができなくなってしまうからである。そのような攻撃を防御することで、OS の備えるセキュリティ機構そのものを頑健にする。
攻撃は常に進化し続けるため、新たなマルウェアの検体が見つかった場合や新しい攻撃手法の発見に対して、常に柔軟に対応しなければならない。本プロジェクトでは、一度の対策でより多くの攻撃を検知して障害対応サイクルを円滑に回す技術、ならびに未知の攻撃への対策を支援して変化対応サイクルを円滑に回すための技術を提供する。
このような仕組みを提供することで、OS を乗っ取り、そのセキュリティ機構を無効化するという攻撃が難しくなる。OS の乗っ取りは極めて深刻な脅威である。なぜなら、セキュリティ実現のための要である OS が乗っ取られれば、あらゆるセキュリティ機構が信頼できなくなり、どんなに強固なセキュリティ機構であっても信頼することができなくなってしまうからである。そのような攻撃を防御することで、OS の備えるセキュリティ機構そのものを頑健にする。
攻撃は常に進化し続けるため、新たなマルウェアの検体が見つかった場合や新しい攻撃手法の発見に対して、常に柔軟に対応しなければならない。本プロジェクトでは、一度の対策でより多くの攻撃を検知して障害対応サイクルを円滑に回す技術、ならびに未知の攻撃への対策を支援して変化対応サイクルを円滑に回すための技術を提供する。
6. DEOS開発支援ツール群
DEOSプロジェクトでは、利用可能なソフトウェア開発支援ツールは出来るだけ利用していく方針である。一方でDEOSに固有のツールは独自に開発する。そのようなツールとして、ソフトウェア検証ツール、ディペンダビリティテスト支援ツールの開発を行っている。
6.1. ソフトウェア検証ツール
オープンシステムの特性上、システムの完成・運用開始後であっても、新たな機能や修正を追加する可能性が存在する。なぜならば、オープンシステムにおいては、事前にシステムに関するあらゆる仕様を定義することは不可能と考えるべきであり、また要求や環境の変化により、ステークホルダ間の合意に基づいて仕様は追加・修正されて行くからである。このように新たな機能や修正をシステムに加える際には、追加・変更される箇所が新たなバグを生じないよう注意しなければならない。そこで、本プロジェクトではシステムソフトウェアの欠陥を形式的手法によって検出するソフトウェア検証ツールの開発を行い[45, 46]、オープンシステムディペンダビリティの向上、特にDEOSプロセスの変化対応サイクルにおける「設計・実装・検証・テスト」フェーズにおいて、ステークホルダ間の合意に基づいて作成・修正された D-Case† に対してエビデンス（の一部）を提供することを目指している。
上述の目的を達成するために本プロジェクトでは、「設計・実装・検証・テスト」フェーズにおいて、システムソフトウェアの記述に広く用いられているC言語プログラムの形式的検証を行うため、モデル検査および型検査の2種類の形式的手法の研究開発を行う（図１４、図１５参照）。
上述の目的を達成するために本プロジェクトでは、「設計・実装・検証・テスト」フェーズにおいて、システムソフトウェアの記述に広く用いられているC言語プログラムの形式的検証を行うため、モデル検査および型検査の2種類の形式的手法の研究開発を行う（図１４、図１５参照）。
オープンシステムディペンダビリティ向上の観点からは、2つの検証手法はそれぞれ利点と欠点を持つ。モデル検査は比較的複雑な安全性を検証できるが、検査に時間を要する、型検査は短時間で検査を完了できるが、検証できる安全性は比較的単純なものである。このため、DEOSプロジェクトでは2つの手法を組み合わせて用いる。
モデル検査はC言語で書かれたプログラムを読み取り、プログラムのすべての実行パスを網羅的に探索し、開発者によって指定された性質（条件）が満たされるかどうかを調べる。検査する性質は仕様記述言語を用いて、プログラム中に出現する変数等に対する条件として記述される。なお、検査する性質は後から修正・追加等を行うことが可能なため、外部環境や利用者の要望の変化によって、事前に想定していなかったような障害が生じる可能性が生じたとしても、新たにその可能性を検査する性質として追加することによって、モデル検査の対象とすることができる。
型検査はプログラムが不正なメモリー操作を行わないことを検査し保証する。たとえば、配列境界をはみ出してのアクセスや、不正なアドレスを関数とみなしてジャンプするといったことをしないと保証する。C言語で書かれたプログラムは、まず、型安全な型付アセンブリ言語（TAL: Typed Assembly Language）という、プログラムの型情報を保持したアセンブリ言語にコンパイルされる。型安全性が静的に保証しきれない箇所には、実行時に検査するためのコードが自動的に挿入される。これをTAL用のアセンブラにかけると機械実行可能なバイナリコードができるが、このバイナリも型情報を持つ。これによって、コンパイルされた後の実行可能コードに対しても型安全性の検査を行うことができる。このため、外部環境や利用者の要望の変化等によってシステムの修正が必要になっても、最低限のシンプルな安全性を型検査によって継続的に保証し続けることができる。
モデル検査はC言語で書かれたプログラムを読み取り、プログラムのすべての実行パスを網羅的に探索し、開発者によって指定された性質（条件）が満たされるかどうかを調べる。検査する性質は仕様記述言語を用いて、プログラム中に出現する変数等に対する条件として記述される。なお、検査する性質は後から修正・追加等を行うことが可能なため、外部環境や利用者の要望の変化によって、事前に想定していなかったような障害が生じる可能性が生じたとしても、新たにその可能性を検査する性質として追加することによって、モデル検査の対象とすることができる。
型検査はプログラムが不正なメモリー操作を行わないことを検査し保証する。たとえば、配列境界をはみ出してのアクセスや、不正なアドレスを関数とみなしてジャンプするといったことをしないと保証する。C言語で書かれたプログラムは、まず、型安全な型付アセンブリ言語（TAL: Typed Assembly Language）という、プログラムの型情報を保持したアセンブリ言語にコンパイルされる。型安全性が静的に保証しきれない箇所には、実行時に検査するためのコードが自動的に挿入される。これをTAL用のアセンブラにかけると機械実行可能なバイナリコードができるが、このバイナリも型情報を持つ。これによって、コンパイルされた後の実行可能コードに対しても型安全性の検査を行うことができる。このため、外部環境や利用者の要望の変化等によってシステムの修正が必要になっても、最低限のシンプルな安全性を型検査によって継続的に保証し続けることができる。
6.2. ディペンダビリティテスト支援ツール
D-Case†を用いてシステムに対するディペンダビリティ要求を議論していく中で、想定するコンポーネントを用いてシステムが必要とする性能を満たすことができるか、さらに想定される異常状態下においてもシステムの要求事項が満たされているかどうかのエビデンスを取得し記録することが必要となる。そのため、ディペンダビリティを阻害する列挙可能な異常状態に対して、システムが要求通りの振る舞いをしているかを、あらかじめ定量的に計測することで、未然にシステムの限界を検証しなければならない。一方で、システムの更新時には事前にシステムの動作テストを行い、問題がないことを検証する必要がある。実環境運用で起きた異常の原因を解析し、説明責任も果たさなくてはならない。そこで、DEOSプロジェクトではD-Case†の中に出現する各種の定量的なディペンダビリティ指標のシステマティックな計測を支援することを目的に、ディペンダビリティ計測ツール DS-Benchおよびシステムテストを迅速に行うテスト環境 Test-Envを開発している[47, 48, 49, 50]。加えて、異常には、ハードウェア異常、ソフトウェアバグ、過負荷、人的ミスなどがあり、これらを系統立てて扱う実行環境を実現する必要がある。これらの異常状態の観測やシステムの動作検証のために、テスト工程を自動化し、計算資源を適切に管理することによって、大規模なシステムテストを実現し、多くのテストパターンを用いた複雑なテストを加速することが求められる。
DS-Bench/Test-Envの成果イメージを図１６に示す。DS-Bench/Test-Envは、何らかのディペンダビリティ指標(たとえば、速度、ダウンタイム)を計測するベンチマークプログラムを走らせて結果を計測しながら、同時に故障、過負荷といった異常状態を模擬するAnomaly Loadを実行することができる。DS-Bench/Test-Envは1990年代後半から2000年代前半にかけて行われたDBenchプロジェクト[26]の成果を踏襲しているが、DBenchとは異なり、ベンチマークの再利用化を念頭におき、ベンチマークプログラムのデータ†ベース化、故障シナリオやベンチマーク実行手順のスクリプト化、さらにベンチマーク結果のデータ†ベース化が可能となるツール環境として設計している。
DS-Benchは、ベンチマーク実行および異常状態生成の手順を記述したシナリオを作成するためのWebユーザインタフェース、代表的なベンチマークプログラム、異常状態を模擬するAnomaly Loadを提供する。ベンチマークやAnomaly Loadはユーザが必要なものを追加することが可能である。DS-Benchは各計測対象のマシンを制御し、作成したシナリオに従ってプログラムの実行やAnomaly Loadの注入を制御する。シナリオに基づいた実行結果はXMLフォーマットで生成され、シナリオを記したXMLとともにデータ†ベース化される。これにより、システムが過負荷状態や故障に対して、どのような振る舞いをするかのエビデンスをデータ†ベース化できる。
DS-Bench/Test-Envでは、ベンチマークの実行環境として実機と仮想マシンの2種類を想定している。実機を用いるのは、性能測定が重要になるベンチマークを行う場合である。ソフトウェアバグ、過負荷状態などのソフトウェアの振る舞い異常や電源断やネットワーク断など、計算機外部のハードウェア機器を制御することにより発生できる障害に対するシステムのディペンダビリティ評価は実機上で行われる。一方仮想マシンは、評価対象となる計算機数が多く、そのために多数の実機を準備することが出来ない場合、もしくは計算機内部のデバイスの障害（ディスク、メモリーなど）を模擬する場合に用いる。
Test-Envの役割はベンチマークやテストの実行環境となるハードウェア資源の管理と制御である。ベンチマーク実行環境に存在する計算機、ネットワークスイッチ、電源スイッチといった機器はTest-Envによって管理され、ベンチマーク実行時にはDS-Benchの要求に応じて計算機資源が割り当てられる。またTest-Envはプライベートクラウドの形で仮想マシン群を管理しており、必要に応じて仮想マシンを生成し起動する。ハードウェアの異常を模擬するAnomaly LoadはTest-Envによって注入される。Test-Envは、DS-Benchから指示されたシナリオに基づき、必要なタイミングで故障を発生させる。
DS-Bench/Test-Envの成果イメージを図１６に示す。DS-Bench/Test-Envは、何らかのディペンダビリティ指標(たとえば、速度、ダウンタイム)を計測するベンチマークプログラムを走らせて結果を計測しながら、同時に故障、過負荷といった異常状態を模擬するAnomaly Loadを実行することができる。DS-Bench/Test-Envは1990年代後半から2000年代前半にかけて行われたDBenchプロジェクト[26]の成果を踏襲しているが、DBenchとは異なり、ベンチマークの再利用化を念頭におき、ベンチマークプログラムのデータ†ベース化、故障シナリオやベンチマーク実行手順のスクリプト化、さらにベンチマーク結果のデータ†ベース化が可能となるツール環境として設計している。
DS-Benchは、ベンチマーク実行および異常状態生成の手順を記述したシナリオを作成するためのWebユーザインタフェース、代表的なベンチマークプログラム、異常状態を模擬するAnomaly Loadを提供する。ベンチマークやAnomaly Loadはユーザが必要なものを追加することが可能である。DS-Benchは各計測対象のマシンを制御し、作成したシナリオに従ってプログラムの実行やAnomaly Loadの注入を制御する。シナリオに基づいた実行結果はXMLフォーマットで生成され、シナリオを記したXMLとともにデータ†ベース化される。これにより、システムが過負荷状態や故障に対して、どのような振る舞いをするかのエビデンスをデータ†ベース化できる。
DS-Bench/Test-Envでは、ベンチマークの実行環境として実機と仮想マシンの2種類を想定している。実機を用いるのは、性能測定が重要になるベンチマークを行う場合である。ソフトウェアバグ、過負荷状態などのソフトウェアの振る舞い異常や電源断やネットワーク断など、計算機外部のハードウェア機器を制御することにより発生できる障害に対するシステムのディペンダビリティ評価は実機上で行われる。一方仮想マシンは、評価対象となる計算機数が多く、そのために多数の実機を準備することが出来ない場合、もしくは計算機内部のデバイスの障害（ディスク、メモリーなど）を模擬する場合に用いる。
Test-Envの役割はベンチマークやテストの実行環境となるハードウェア資源の管理と制御である。ベンチマーク実行環境に存在する計算機、ネットワークスイッチ、電源スイッチといった機器はTest-Envによって管理され、ベンチマーク実行時にはDS-Benchの要求に応じて計算機資源が割り当てられる。またTest-Envはプライベートクラウドの形で仮想マシン群を管理しており、必要に応じて仮想マシンを生成し起動する。ハードウェアの異常を模擬するAnomaly LoadはTest-Envによって注入される。Test-Envは、DS-Benchから指示されたシナリオに基づき、必要なタイミングで故障を発生させる。
7. DEOS適用の効果：想定事例
本章では、DEOSプロセス/アーキテクチャを適用することによりシステムが開放系障害に対してどれだけ対処できるようになるかを説明する。そのために、これまでに発生したいくつかの障害事例、あるいは、大規模ソフトウェアシステムで今後想定されるシステム障害事例を引用する。
１）ソフトウェアの欠陥が障害を引き起こすケース
現代社会では鉄道の自動改札システムにICカードが広く使われている。ある朝自動改札システムは立ち上がらなかった。何が原因だったのかまったく分からず、すぐには直せなかった。このため、サービス開始から数時間、自動改札システムは稼働せず、しかたなく鉄道会社は全ての駅の自動改札システムを開放して、乗車を無料とした。真の原因を見つけ出す作業に手間取り、復旧は数時間後であった。
DEOSが適用されていれば、障害対応サイクルのD-Case†に迅速対応方法が合意されている。例えば、ダウンする前の状態に戻すという対処である。もちろん無条件に戻せるとは限らない。このケースでは、昨夜まで運用されていたシステムがダウンしたので、夜のサービス停止中にシステムに加えた変更が引き金になった可能性は高いので、昨夜の変更は何があったかを調べた。その結果プログラムの更新はなかったが、自動改札機で不審なICカード使用をチェックする不審カード情報がダウンロードされた事が分かった。そのため不審カード情報を使う事を諦めれば、すなわち昨日までの不審カード情報でオペレーションを再開する事がステークホルダ間で決定されれば、ダウンする前の状態にシステムを戻し、運用を再開することが可能となる。新しい情報に基づく昨日中に発見された新しい不正使用者を見逃す事になるが、昨日と同等のサービスは継続できる。
別の対処としては、個々の自動改札機をサーバから切り離して動作させる方法があったであろう。個々の自動改札機は最大数日分のトランザクションデータ†をローカルに保存できる仕様だったので、これを利用すれば、当面の運用は継続することが可能である。このように、D-Case† に事前のステークホルダ合意が記述され、そこから生成されたD-Script が実行されることにより、迅速対応ができる。
システムの根本的改修は、DEOSが適用されていれば、変化対応サイクルで行う。障害対応サイクルで、昨夜不審カード情報がダウンロードされた事でシステムがダウンした事が分かっているので、その関連を、障害発生までに出力された動作状況ログ等を分析して、原因を包含しそうなソフトウェアの範囲あるいはモジュールまで絞る。この先は地道なプログラムのデバッグ作業となるだろうが、範囲が絞られ、モジュールが特定できれば、原因究明の時間は短縮できる。またD-Case†記述に基づき、説明責任遂行を果たすことができる。サービスの継続のためには、エンドユーザである鉄道利用者には、ダウンした状況や、緊急の処理の推移、原因究明の状況を説明し、説明責任を遂行する。
２）システム性能バランスが崩れて障害となるケース
インターネットのサービスを提供するシステムは規模により様々な構成があるが、大量のアクセス数あるいはトランザクション数を支えるシステムの多くは３層構造のシステム（エンドユーザとのインタラクションを担うWeb Server、アプリケーションを実行するApplication Server、データ†の管理を行うDB Server等）により構成されている。このようなITシステムでは、運用時に環境変化が起こることがままある。例えば、ビジネスを拡張するためにアクセス数の増加に対応したいと考える。この際に、Web Server の増強や、アプリケーションの拡張、サービス要求への対応のために運用時の変更要求が発生する。こうした増強や拡張を全体のシステムとの依存関係を考慮せずに行うと予期せぬ障害が発生する。例えば、Web サーバのみを増強し多くのアクセスを受け付けるようになると、その結果、それが次の層のApplication Serverには過負荷となる。あるいは新サービスがApplication Serverに導入されると、高負荷によるダウンが発生する。システム構成の変更はシステム全体のキャパシティやパフォーマンスなどの性能バランスを考慮して注意深く行われなくてはいけない。
DEOSが適用されていれば、システム変更を実行する前にDS-Bench/Test-Envで検証する事ができる。もちろんDEOSプロセスにおけるすべての変更要求はD-Case†に記述され、必要な迅速対応のためのD-Scriptが作られる。DEOSプロセスを順守し、すべての起こりうるケースを想定していても、障害は避けえない。そのような場合でも、適切な障害対応が取られ、変化対応サイクルがケース１）と同様に実施される。
３）インテグレーション問題で障害となるケース
現代のシステムは、多くの市販ソフトウェアや、過去のシステムの遺産であるレガシーコードを駆使して組み上げられている。サービスのカットオーバー前、あるいは組み込み製品の出荷前には大変な労力をかけてテストが行われている。それでも、あらゆる可能性を全てテストする事は難しい。特に、ダイナミックにソフトウェアモジュールが脱着されるような高度なシステムでは、事前にすべての場合をテストするのは不可能に近く、予期せぬ動作を引き起こす。次善の策として、予期せぬ動作が起きた時の、リカバリー手順を準備しておく事が重要である。
DEOSが適用されていれば、障害対応サイクルのD-Case†に手順がある。もし、ソフトウェアモジュールが追加された直後に障害が発生する場合には、ダウンする前で、かつモジュールが追加される前の状態に戻す処理が望ましい。D-REには、アプリケーションのみならず、システムのチェックポイントリスタート機能があるので、処理をさかのぼってシステムを再スタートする事が出来る。D-REは階層的に、チェックポイントの機能を提供するためのAPIも提供しているため、障害の程度によって、使い分けることができる。また、D-RE ではシステムと連携し、安全にアプリケーションを開始、終了したり、チェックポイントを実行するためのAPI を利用するアプリケーションをD-Aware Applicationとしている。D-Aware Application 向けAPIを利用することで、システムと連動した安全な操作が可能である。また、D-Aware Application ではない場合も、D-REには、短時間で再起動が行える機能があるため、システムレベルあるいはアプリケーションレベルでの再起動を実行することができる。これにより再現性が低い一時的な障害は回復できる場合が多い。説明責任遂行においては、エンドユーザには、ダウンした状況や、緊急対処の内容を説明し、説明責任を遂行する。
４）システム老化が障害を引き起こすケース
コーディングミスによるメモリーリークなどは機能の誤動作を引き起こす。メモリーリークを検出する事は難しい。また、全ての言語においてGC（Garbage Collection）を利用することができるとは限らない。メモリーリークを放置すると、アプリケーションの稼働メモリー領域が狭められて、やがてはシステム全体の性能の低下や、応答不能といった状態も引き起こす。
DEOSが適用されていれば、D-REがメモリー領域の減少をモニターしており、自動的に若化機能を動作させ、システムの状況の悪化を回避する。
５）ライセンス切れが障害を引き起こすケース
現代のシステムの多くは市販のソフトウェアを使っている。ソフトウェア契約は期限ごとにライセンス料を支払って使用期間を更新するものが多い。したがって、普通、そう言った市販ソフトウェアはライセンス期限が切れると、動作を止めるように作ってある。使っているシステムとしては、個々のライセンス期限を管理して、期限が切れる前に更新するのが望ましい。しかし、何十本、何百本も市販ソフトウェアを組み合わせているシステムでは、全てのソフトの管理が統一的、一元的に行われているとは限らず、管理から漏れるソフトウェアもある。ソフトウェアライセンス切れによるシステム動作の停止は、重要であるが見過ごされがちである。
DEOSが適用されていれば、運用状態で日常点検を実行することにより回避することができる。D-REはシステムコンテナごとにシステムクロックをセットする機能がある。つまり、システムを未来時間で動かし、その未来時間にライセンス期限が来るようなソフトウェアをリストして、更新を促すことができる。実際のトランザクションが処理されなければ、動かないシステムもあるだろう。２４時間稼動していて、未来時間にセット事ができないシステムもある。そう言ったシステムでは、先に述べたように厳密なライセンス管理が求められるが、そうでないシステムであれば、毎日、終業後に明日の営業時間に時間をセットして事前に動作を確認する日常点検が有効である。
１）ソフトウェアの欠陥が障害を引き起こすケース
現代社会では鉄道の自動改札システムにICカードが広く使われている。ある朝自動改札システムは立ち上がらなかった。何が原因だったのかまったく分からず、すぐには直せなかった。このため、サービス開始から数時間、自動改札システムは稼働せず、しかたなく鉄道会社は全ての駅の自動改札システムを開放して、乗車を無料とした。真の原因を見つけ出す作業に手間取り、復旧は数時間後であった。
DEOSが適用されていれば、障害対応サイクルのD-Case†に迅速対応方法が合意されている。例えば、ダウンする前の状態に戻すという対処である。もちろん無条件に戻せるとは限らない。このケースでは、昨夜まで運用されていたシステムがダウンしたので、夜のサービス停止中にシステムに加えた変更が引き金になった可能性は高いので、昨夜の変更は何があったかを調べた。その結果プログラムの更新はなかったが、自動改札機で不審なICカード使用をチェックする不審カード情報がダウンロードされた事が分かった。そのため不審カード情報を使う事を諦めれば、すなわち昨日までの不審カード情報でオペレーションを再開する事がステークホルダ間で決定されれば、ダウンする前の状態にシステムを戻し、運用を再開することが可能となる。新しい情報に基づく昨日中に発見された新しい不正使用者を見逃す事になるが、昨日と同等のサービスは継続できる。
別の対処としては、個々の自動改札機をサーバから切り離して動作させる方法があったであろう。個々の自動改札機は最大数日分のトランザクションデータ†をローカルに保存できる仕様だったので、これを利用すれば、当面の運用は継続することが可能である。このように、D-Case† に事前のステークホルダ合意が記述され、そこから生成されたD-Script が実行されることにより、迅速対応ができる。
システムの根本的改修は、DEOSが適用されていれば、変化対応サイクルで行う。障害対応サイクルで、昨夜不審カード情報がダウンロードされた事でシステムがダウンした事が分かっているので、その関連を、障害発生までに出力された動作状況ログ等を分析して、原因を包含しそうなソフトウェアの範囲あるいはモジュールまで絞る。この先は地道なプログラムのデバッグ作業となるだろうが、範囲が絞られ、モジュールが特定できれば、原因究明の時間は短縮できる。またD-Case†記述に基づき、説明責任遂行を果たすことができる。サービスの継続のためには、エンドユーザである鉄道利用者には、ダウンした状況や、緊急の処理の推移、原因究明の状況を説明し、説明責任を遂行する。
２）システム性能バランスが崩れて障害となるケース
インターネットのサービスを提供するシステムは規模により様々な構成があるが、大量のアクセス数あるいはトランザクション数を支えるシステムの多くは３層構造のシステム（エンドユーザとのインタラクションを担うWeb Server、アプリケーションを実行するApplication Server、データ†の管理を行うDB Server等）により構成されている。このようなITシステムでは、運用時に環境変化が起こることがままある。例えば、ビジネスを拡張するためにアクセス数の増加に対応したいと考える。この際に、Web Server の増強や、アプリケーションの拡張、サービス要求への対応のために運用時の変更要求が発生する。こうした増強や拡張を全体のシステムとの依存関係を考慮せずに行うと予期せぬ障害が発生する。例えば、Web サーバのみを増強し多くのアクセスを受け付けるようになると、その結果、それが次の層のApplication Serverには過負荷となる。あるいは新サービスがApplication Serverに導入されると、高負荷によるダウンが発生する。システム構成の変更はシステム全体のキャパシティやパフォーマンスなどの性能バランスを考慮して注意深く行われなくてはいけない。
DEOSが適用されていれば、システム変更を実行する前にDS-Bench/Test-Envで検証する事ができる。もちろんDEOSプロセスにおけるすべての変更要求はD-Case†に記述され、必要な迅速対応のためのD-Scriptが作られる。DEOSプロセスを順守し、すべての起こりうるケースを想定していても、障害は避けえない。そのような場合でも、適切な障害対応が取られ、変化対応サイクルがケース１）と同様に実施される。
３）インテグレーション問題で障害となるケース
現代のシステムは、多くの市販ソフトウェアや、過去のシステムの遺産であるレガシーコードを駆使して組み上げられている。サービスのカットオーバー前、あるいは組み込み製品の出荷前には大変な労力をかけてテストが行われている。それでも、あらゆる可能性を全てテストする事は難しい。特に、ダイナミックにソフトウェアモジュールが脱着されるような高度なシステムでは、事前にすべての場合をテストするのは不可能に近く、予期せぬ動作を引き起こす。次善の策として、予期せぬ動作が起きた時の、リカバリー手順を準備しておく事が重要である。
DEOSが適用されていれば、障害対応サイクルのD-Case†に手順がある。もし、ソフトウェアモジュールが追加された直後に障害が発生する場合には、ダウンする前で、かつモジュールが追加される前の状態に戻す処理が望ましい。D-REには、アプリケーションのみならず、システムのチェックポイントリスタート機能があるので、処理をさかのぼってシステムを再スタートする事が出来る。D-REは階層的に、チェックポイントの機能を提供するためのAPIも提供しているため、障害の程度によって、使い分けることができる。また、D-RE ではシステムと連携し、安全にアプリケーションを開始、終了したり、チェックポイントを実行するためのAPI を利用するアプリケーションをD-Aware Applicationとしている。D-Aware Application 向けAPIを利用することで、システムと連動した安全な操作が可能である。また、D-Aware Application ではない場合も、D-REには、短時間で再起動が行える機能があるため、システムレベルあるいはアプリケーションレベルでの再起動を実行することができる。これにより再現性が低い一時的な障害は回復できる場合が多い。説明責任遂行においては、エンドユーザには、ダウンした状況や、緊急対処の内容を説明し、説明責任を遂行する。
４）システム老化が障害を引き起こすケース
コーディングミスによるメモリーリークなどは機能の誤動作を引き起こす。メモリーリークを検出する事は難しい。また、全ての言語においてGC（Garbage Collection）を利用することができるとは限らない。メモリーリークを放置すると、アプリケーションの稼働メモリー領域が狭められて、やがてはシステム全体の性能の低下や、応答不能といった状態も引き起こす。
DEOSが適用されていれば、D-REがメモリー領域の減少をモニターしており、自動的に若化機能を動作させ、システムの状況の悪化を回避する。
５）ライセンス切れが障害を引き起こすケース
現代のシステムの多くは市販のソフトウェアを使っている。ソフトウェア契約は期限ごとにライセンス料を支払って使用期間を更新するものが多い。したがって、普通、そう言った市販ソフトウェアはライセンス期限が切れると、動作を止めるように作ってある。使っているシステムとしては、個々のライセンス期限を管理して、期限が切れる前に更新するのが望ましい。しかし、何十本、何百本も市販ソフトウェアを組み合わせているシステムでは、全てのソフトの管理が統一的、一元的に行われているとは限らず、管理から漏れるソフトウェアもある。ソフトウェアライセンス切れによるシステム動作の停止は、重要であるが見過ごされがちである。
DEOSが適用されていれば、運用状態で日常点検を実行することにより回避することができる。D-REはシステムコンテナごとにシステムクロックをセットする機能がある。つまり、システムを未来時間で動かし、その未来時間にライセンス期限が来るようなソフトウェアをリストして、更新を促すことができる。実際のトランザクションが処理されなければ、動かないシステムもあるだろう。２４時間稼動していて、未来時間にセット事ができないシステムもある。そう言ったシステムでは、先に述べたように厳密なライセンス管理が求められるが、そうでないシステムであれば、毎日、終業後に明日の営業時間に時間をセットして事前に動作を確認する日常点検が有効である。
8. 実用化に向けて
8.1. 国際規格化
8.1.1 国際標準規格の重要性
DEOS の実用化に向けた手段として、以下の理由により国際標準規格を重視する。
１）オープンシステムディペンダビリティ概念の共有
2.1節で言及したように、既に存在する規格の中にもオープンシステムの考え方が明示的でないにせよいくつか表れてきている。IEC 61508やISO 26262などの機能安全の考え方は、絶対安全がもはや期待できない複雑なシステムに対して、いかにコストに対して相応な安全性を確保するか、または評価するかを規定する規格といえる。さらに、ITサービスマネジメント規格ISO/IEC 20000やセキュリティマネジメント規格ISO/IEC 27000は、変化し続けるシステムに対するサービスレベルやセキュリティの継続的な確保のための規格といえる。しかし、それらは各分野の近年の状況を反映し、必要に迫られて策定されたものであり、それらに共通する背景であるオープンシステムという考え方は表れておらず、分野をまたがった問題意識の共有はできていないのが現状である。そこで、様々な分野を包含するような上位規格としてのオープンシステムディペンダビリティの概念を規定する規格が必要である。
２）社会的な仕組みの構築
本プロジェクトを通じて、オープンシステムディペンダビリティを確保するためには、関係するステークホルダ間での合意形成†や関係者に対する説明責任の遂行、それらを支援するためのDEOSプロセスやDEOSアーキテクチャなどが有効であるとの結論を得た。これらの考え方の実用化のためには、合意形成†のための共通のルールや標準的なアシュアランスケースのデータ†ベース、さらには、一般消費者も一定の合意形成†プロセスに加われるような仕組みなどが必要になる。これらは、デジュールとしての国際規格に基づくライフサイクルプロセスや合意形成†プロセス、各種の認証の仕組みを構築することが必要になる。認証は、広い意味で社会との合意形成†ということができ、オープンシステムディペンダビリティにとっても重要な役割を担う。
３）ツールの普及
技術の普及のためには、ツールの普及が欠かせず、また、オープンシステムディペンダビリティにとって重要な社会的な仕組みの一つである。従って、ツールに関しても何らかの認証規格やガイドライン規格が必要である。
8.1.2 策定を目指す規格の構成
以下、策定を目指す規格の概要を現在の活動とともに記す。
１）オープンシステムディペンダビリティ概念規格
既存の国際標準規格のなかでディペンダビリティの概念を規定しているものは、ディペンダビリティマネジメントの規格であるIEC 60300シリーズである。 改訂作業にはDEOSプロジェクトからも参加し、オープンシステムディペンダビリティの考え方の反映を目指している。ただし、全面的にオープンシステムディペンダビリティの考え方に基づいて改訂している訳ではないので、本プロジェクトとして、新しい規格案（new work item proposal、NWIP）をIEC TC56あるいは他の適当な規格団体において提案する計画である。また、オープンシステムディペンダビリティの評価基準として、4.5節で説明したDEOSプロセスメトリクスの考えをもとにした国際標準化の策定を目指す。
２）合意形成†と説明責任の方法論、プロセス規格
もともと、安全性水準（Safety Integrity Level、SIL）などの上位概念であるリスク抑制のための完全性水準（Integrity Level）のための規格であったISO/IEC 15026が、現在、システムとソフトウェアのアシュアランス（System and Software Assurance）の規格として改訂作業中であり、この作業に、DEOSプロジェクトから２名が編集委員（Editor）として参加している。「Assurance」とは、確信や請け合いといった意味をもつ単語であるが、「System Assurance」と言った場合には、高信頼性とほぼ同義で用いられる。本規格は、本プロジェクトにおいて、合意形成†と説明責任のために導入したD-Case†の一般概念であるアシュアランスケース（Assurance Case）の概念規定を含むものであり、ISO/IEC 15026 Part 2として既に発行済みである。
また、IEC TC 56においても、ディペンダビリティに対するアシュアランスケースであるディペンダビリティケース（Dependability Case）の新規規格案が英国から提案されており、本プロジェクトからの委員も積極的にコメントしているところであり、本プロジェクトで得られた知見も反映していく予定である。さらに、UML†などを策定している標準化団体であるOMGにおいて、消費者機械に関する新しい規格の立ち上げにも本プロジェクトからメンバーが参加し、ディペンダビリティケースを中心的な概念として位置づけることに貢献した。今後は、D-Case†だけでなく、DEOSプロセスの考え方も反映したいと考えている。
改訂版のISO/IEC 15026では、アシュアランスを実現するためのライフサイクルプロセスも含める計画であり（ISO/IEC 15026 Part 4）、本プロジェクトで策定しているDEOSプロセスに対して、実装依存の部分を除いたものとフォーカスが重なると考える。この部分は現在改訂作業中であり、DEOSプロセスの考え方の反映を目指している。
DEOSプロセスに関しては、エンタープライズアーキテクチャの標準的なフレームワークの一つであるTOGAF†（The Open Group Architecture Framework）を策定している団体であるThe Open Groupとも連携を始めている。具体的には、TOGAF†においてD-Case†を活用するプロセスを共同での開発すること目指す。
３）実装 / ツール
UML†などを策定している標準化団体であるOMGにおいて、アシュアランスケースに関して、より実装に近い部分について規格の策定を進めている。ここでも、本プロジェクトから複数参加し、規格策定作業に従事している。具体的には、D-Case†パターンなど、4.3節で紹介したD-Case†ツール群のいくつかの考え方の反映を目指している。
DEOS の実用化に向けた手段として、以下の理由により国際標準規格を重視する。
１）オープンシステムディペンダビリティ概念の共有
2.1節で言及したように、既に存在する規格の中にもオープンシステムの考え方が明示的でないにせよいくつか表れてきている。IEC 61508やISO 26262などの機能安全の考え方は、絶対安全がもはや期待できない複雑なシステムに対して、いかにコストに対して相応な安全性を確保するか、または評価するかを規定する規格といえる。さらに、ITサービスマネジメント規格ISO/IEC 20000やセキュリティマネジメント規格ISO/IEC 27000は、変化し続けるシステムに対するサービスレベルやセキュリティの継続的な確保のための規格といえる。しかし、それらは各分野の近年の状況を反映し、必要に迫られて策定されたものであり、それらに共通する背景であるオープンシステムという考え方は表れておらず、分野をまたがった問題意識の共有はできていないのが現状である。そこで、様々な分野を包含するような上位規格としてのオープンシステムディペンダビリティの概念を規定する規格が必要である。
２）社会的な仕組みの構築
本プロジェクトを通じて、オープンシステムディペンダビリティを確保するためには、関係するステークホルダ間での合意形成†や関係者に対する説明責任の遂行、それらを支援するためのDEOSプロセスやDEOSアーキテクチャなどが有効であるとの結論を得た。これらの考え方の実用化のためには、合意形成†のための共通のルールや標準的なアシュアランスケースのデータ†ベース、さらには、一般消費者も一定の合意形成†プロセスに加われるような仕組みなどが必要になる。これらは、デジュールとしての国際規格に基づくライフサイクルプロセスや合意形成†プロセス、各種の認証の仕組みを構築することが必要になる。認証は、広い意味で社会との合意形成†ということができ、オープンシステムディペンダビリティにとっても重要な役割を担う。
３）ツールの普及
技術の普及のためには、ツールの普及が欠かせず、また、オープンシステムディペンダビリティにとって重要な社会的な仕組みの一つである。従って、ツールに関しても何らかの認証規格やガイドライン規格が必要である。
8.1.2 策定を目指す規格の構成
以下、策定を目指す規格の概要を現在の活動とともに記す。
１）オープンシステムディペンダビリティ概念規格
既存の国際標準規格のなかでディペンダビリティの概念を規定しているものは、ディペンダビリティマネジメントの規格であるIEC 60300シリーズである。 改訂作業にはDEOSプロジェクトからも参加し、オープンシステムディペンダビリティの考え方の反映を目指している。ただし、全面的にオープンシステムディペンダビリティの考え方に基づいて改訂している訳ではないので、本プロジェクトとして、新しい規格案（new work item proposal、NWIP）をIEC TC56あるいは他の適当な規格団体において提案する計画である。また、オープンシステムディペンダビリティの評価基準として、4.5節で説明したDEOSプロセスメトリクスの考えをもとにした国際標準化の策定を目指す。
２）合意形成†と説明責任の方法論、プロセス規格
もともと、安全性水準（Safety Integrity Level、SIL）などの上位概念であるリスク抑制のための完全性水準（Integrity Level）のための規格であったISO/IEC 15026が、現在、システムとソフトウェアのアシュアランス（System and Software Assurance）の規格として改訂作業中であり、この作業に、DEOSプロジェクトから２名が編集委員（Editor）として参加している。「Assurance」とは、確信や請け合いといった意味をもつ単語であるが、「System Assurance」と言った場合には、高信頼性とほぼ同義で用いられる。本規格は、本プロジェクトにおいて、合意形成†と説明責任のために導入したD-Case†の一般概念であるアシュアランスケース（Assurance Case）の概念規定を含むものであり、ISO/IEC 15026 Part 2として既に発行済みである。
また、IEC TC 56においても、ディペンダビリティに対するアシュアランスケースであるディペンダビリティケース（Dependability Case）の新規規格案が英国から提案されており、本プロジェクトからの委員も積極的にコメントしているところであり、本プロジェクトで得られた知見も反映していく予定である。さらに、UML†などを策定している標準化団体であるOMGにおいて、消費者機械に関する新しい規格の立ち上げにも本プロジェクトからメンバーが参加し、ディペンダビリティケースを中心的な概念として位置づけることに貢献した。今後は、D-Case†だけでなく、DEOSプロセスの考え方も反映したいと考えている。
改訂版のISO/IEC 15026では、アシュアランスを実現するためのライフサイクルプロセスも含める計画であり（ISO/IEC 15026 Part 4）、本プロジェクトで策定しているDEOSプロセスに対して、実装依存の部分を除いたものとフォーカスが重なると考える。この部分は現在改訂作業中であり、DEOSプロセスの考え方の反映を目指している。
DEOSプロセスに関しては、エンタープライズアーキテクチャの標準的なフレームワークの一つであるTOGAF†（The Open Group Architecture Framework）を策定している団体であるThe Open Groupとも連携を始めている。具体的には、TOGAF†においてD-Case†を活用するプロセスを共同での開発すること目指す。
３）実装 / ツール
UML†などを策定している標準化団体であるOMGにおいて、アシュアランスケースに関して、より実装に近い部分について規格の策定を進めている。ここでも、本プロジェクトから複数参加し、規格策定作業に従事している。具体的には、D-Case†パターンなど、4.3節で紹介したD-Case†ツール群のいくつかの考え方の反映を目指している。
8.2. DEOSコンソーシアム
当プロジェクトの研究成果として、オープンシステムディペンダビリティ（OSD）の概念、DEOSプロセス、DEOSアーキテクチャ、DEOS実行環境、ツール群がある。成果の実用化と言うプロジェクトの目的を真に達成するためには成果物が多くのユーザに使われ、継続的に保守され、改善されなくてはいけない。当プロジェクトでは以上の目的を達成するために、プロジェクト期間中にコンソーシアムを発足させ、企業や関連機関との連携を進める事を目指す。コンソーシアムの目的は以下である。
１）オープンシステムディペンダビリティの重要性の理解・世論形成の推進
２）業界あるいは社会にまたがる標準作成
３）業界あるいは適用分野別のDEOSプロセスおよびアーキテクチャ適用支援
４）オープンシステムディペンダビリティに関連した産業の育成
５）DEOSに関連した成果物の開発・維持
１）オープンシステムディペンダビリティの重要性の理解・世論形成の推進
２）業界あるいは社会にまたがる標準作成
３）業界あるいは適用分野別のDEOSプロセスおよびアーキテクチャ適用支援
４）オープンシステムディペンダビリティに関連した産業の育成
５）DEOSに関連した成果物の開発・維持
8.3. 知的資産・著作権の扱い
知的資産・著作権は一次的には各研究機関に所属するため、本プロジェクトの成果を普及するためにはどのような方法が良いかという観点で検討して方針を決め、各研究機関からの権利の譲渡などを含めた協力を仰いでいく。最終的にはRAND（Reasonable and Non Discriminatory Licensing）運用するなど、オープンシステムディペンダビリティ関連の成果物の普及促進を図るとともに、貢献した企業・団体のインセンティブを高める形態を考えて行く。
9. 参照・参考資料
1. H. Yasuura, “On Dependability”, T. Nanya, “Concept and Issues on Dependability”, K. Iwano, “Dependability in Social Services”, in Dependability Workshop Report （in Japanese）, CRDS-FY2006-WR-07, CRDS, JST, March 2007
2. http://www.dependability.org/wg10.4/
3. A. Avizienis, J.-C. Laprie, B. Randell, C. E. Landwehr, “Basic Concepts and Taxonomy of Dependable and Secure Computing”, IEEE Trans. On Dependable and Secure Computing, Vol.1, No. 1, Jan.-March 2004
4. T. Kikuno, “Requirements for Dependability in the 21th Century”, Speech at the Kickoff Symposium of JST/CREST† Dependable Embedded OS Project, December 2006
5. M. Tokoro, “On Designing Dependable Operating Systems for Social Infrastructures”, Keynote Speech at MPSoC, Awaji Island, Japan, June 25, 2007.
6. 安浦 寛人、「社会システムを支えるディペンダブルコンピューティング」、電子情報通信学会誌、Vol.90, No.5, pages 399-405, May. 2007
7. 加納 敏行、菊池 芳秀、「ディペンダブルIT・ネットワークとは」、NEC技法、Vol.59, No.3, 2006, pages 6-10
8. M. Y. Hsiao, W. C. Carter, J. W. Thomas, and W. R. Stringfellow, “Reliability, Availability, and Serviceability of IBM Computer Systems: A Quarter Century of Progress”, IBM J. Res. Develop., Vol. 25, No. 5, 1981, pages 453-465
9. A. G. Ganek and T. A. Corbi, “The dawning of the autonomic computing era”, IBM Systems Journal, Vol 42, No. 1, 2003, pages 5-18
10. “An architectural blueprint for autonomic computing, 4th edition”, IBM Autonomic Computing White Paper, June 2006
11. http://www-03.ibm.com/autonomic/
12. 所 眞理雄、「技術成熟期における研究開発」、電子情報通信学会誌、Vol.90, No.9, 2007, pages 742-744
13. 所 眞理雄、他、「オープン システム サイエンス」、NTT出版
14. H. B. Diab, A. Y. Zomaya, “Dependable Computing Systems”, Wiley-Interscience
15. G. M. Koob, C. G. Lau, “Foundations of Dependable Computing”, Kluwer Academic Publishers
16. M. C. Huebscher, J. A. McCann, “A survey of Autonomic Computing”, ACM Computing Surveys, Vol. 40, No.3, Article 7, August 2008, pages 7:1-7:28
17. 松田 晃一、巻頭言、IPA SEC journal No.16，第５巻第１号（通巻１６号）2009, page 1
18. T. Forbath, interview「日本企業は２０世紀型の開発プロセスから脱却すべき」NIKKEI ELECTRONICS 2009.2.23, page 29
19. A.Avizienis, ” Design of fault-tolerant computers”, In Proc. 1967 Fall Joint Computer Conf., AF†IPS Conf. Proc.Vol.31, pages 733-743, 1967
20. ナシームNタレブ、「ブラックスワン」、ダイヤモンド社.
21. ナンシーGレブソン、「セーフウェア」、翔泳社
22. 不具合連鎖「プリウス」リコールからの警鐘、日経BP社/
23. 大和田 尚孝、他、「システムはなぜダウンするのか」、日経BP社
24. H. B. Diab, A. Y. Zomaya, “DEPENDA†BLE COMPUTING SYSTEMS”, WILEY-INTERSCIENCE
25. G. M. Koob, C. G. Lau, “FOUNDA†TIONS OF DEPENDA†BLE COMPUTING”, KLUWER ACADEMIC PUBLISHERS
26. K.Kanoun, L.Spainhower, “Dependability Benchmarking for Computer Systems”, IEEE COMPUTER SOCIETY
27. B.Kirwan,"A Guide to PRACTICAL HUMAN RELIABILITY ASSESSMENT”,CRC PRESS
28. 「安全・安心を実現する情報社会基盤の普及に向けて」(http://www.scj.go.jp/ja/info/kohyo/pdf/kohyo-20-t58-4.pdf ）、日本学術会議 情報学委員会セキュリティ・ディペンダビリティ分科会 （委員長 今井 秀樹）、２００８年６月２６日
29. O.-J. Dahl, E. W. Dijkstra, C. A. R. Hoare, Structured Programming, Academic Press, London, 1972 ISBN 0-12-200550-3
30. Birtwistle, G.M. (Graham M.) 1973. SIMULA begin. Philadelphia, Auerbach.
31. Humphrey, Watts (March 1988). "Characterizing the software process: a maturity framework". IEEE Software 5 (2): 73–79. doi:10.1109/52.2014. http://www.sei.cmu.edu/reports/87tr011.pdf.
32. Humphrey, Watts (1989). Managing the Software Process. Addison Wesley. ISBN 0201180952.
33. http://www.sei.cmu.edu/cmmi/
34. Ultra-Large-Scale Systems: The Software Challenge of the Future, http://www.sei.cmu.edu/library/assets/ULS_Book20062.pdf
35. Dependable Operating Systems for Embedded Systems Aiming at Practical Applications Research Area (DEOS Project) White Paper Version1.0, DEOS-FY2009-WP-01, JST, Sep. 1, 2009
36. Dependable Operating Systems for Embedded Systems Aiming at Practical Applications Research Area (DEOS Project) White Paper Version2.0, DEOS-FY2010-WP-02, JST, Dec. 1, 2010
37. T P Kelly, R A Weaver, “The Goal Structuring Notation - A Safety Argument Notation”,
In proceedings of the Dependable Systems and Networks 2004 Workshop on Assurance Cases, July 2004
38. Workshop on Assurance Cases: Best Practices, Possible, Obstacles, and Future Opportunities, DSN 2004, 2004
39. European Organisation for the Safety of Air Navigation. Safety case development manual. European Air Traffic Management, 2006
40. Railtrack. Yellow Book 3. Engineering Safety Management Issue3, Vol. 1, Vol. 2, 2000.
41. Guidance for Industry and FDA Staff - Total Product Life Cycle: Infusion Pump - Premarket Notification [510(k)] Submissions http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm206153.htm#6
42. City University London Centre for Software Reliability http://www.city.ac.uk/informatics/school-organisation/centre-for-software-reliability/research
43. D-Case† Editor http://www.il.is.s.u-tokyo.ac.jp/deos/dcase/
44. Kimio Kuramitsu. Konoha: implementing a static scripting language with dynamic behaviors. In Proceeding S3 '10 Workshop on Self-Sustaining Systems, ACM Press, 2010.
45. Takahiro Kosakai, Toshiyuki Maeda and Akinori Yonezawa, “Compiling C Programs into a Strongly Typed Assembly Language”, In proceedings of the 12th Asian Computing Science Conference (ASIAN 2007). pp. 17-32. Doha, Qatar, Dec. 2007.
46. Motohiko Matsuda, Toshiyuki Maeda, and Akinori Yonezawa, “Towards Design and Implementation of Model Checker for System Software” , In proceedings of the 12th Asian Computing Science Conference (ASIAN 2007). pp. 17-32. Doha, Qatar, Dec. 2007.7). pp. Systems (STFSSD 2009), Tokyo, Japan, January 2009.
47. 加藤 真平、他、「ディペンダブルシステム向けベンチマークフレームワークの提案」 第7回ディペンダブルシステムワークショップ DSW2009、 pp. 171-178、 2009年7月
48. Toshihiro Hanawa, Hitoshi Koizumi, Takayuki Banzai, Mitsuhisa Sato, and Shin’ichi Miura, “Customizing Virtual Machine with Fault Injector by Integrating with SpecC Device Model for a software testing environment D-Cloud”, the 16th IEEE Pacific Rim International Symposium on Dependable Computing (PRDC '10), pp. 47-54, Dec. 2010. doi: 10.1109/PRDC.2010.37
49. Takayuki Banzai, Hitoshi Koizumi, Ryo Kanbayashi, Takayuki Imada, Toshihiro Hanawa, and Mitsuhisa Sato, “D-Cloud: Design of a Software Testing Environment for Reliable Distributed Systems Using Cloud Computing Technology”, the 2nd International Symposium on Cloud Computing (Cloud 2010) in conjunction with the 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing (CCGrid 2010), pp. 631-636, May 2010. doi: 10.1109/CCGRID.2010.72
50. Toshihiro Hanawa, Takayuki Banzai, Hitoshi Koizumi, Ryo Kanbayashi, Takayuki Imada, and Mitsuhisa Sato, “Large-Scale Software Testing Environment Using Cloud Computing Technology for Dependable Parallel and Distributed Systems”, the 2nd International Workshop on Software Testing in the Cloud (STITC 2010), co-located with the 3rd IEEE International Conference on Software Testing, Verification, and Validation (ICST 2010), pp. 428-433, Apr. 2010. doi: 10.1109/ICSTW.2010.59
51. Daniel P. Siewiorek, Robert S. Swarz, “Reliable Computer Systems: Design and Evaluation”, Third Edition. A K Peters/CRC Press. 1998.
52. A.M. Davis, Just Enough Requirements Management: Where Software Development Meets Marketing, Dorset House. 2005.
53. Object Management Group/Business Process Management Initiative: http://www.bpmn.org/
54. Smalltalk: http://www.smalltalk.org/main/
55. Nancy Leveson: “A new accident model for engineering safer systems”, Safety Science, Volume 42, Issue 4, Pages 237-270, April 2004.
2. http://www.dependability.org/wg10.4/
3. A. Avizienis, J.-C. Laprie, B. Randell, C. E. Landwehr, “Basic Concepts and Taxonomy of Dependable and Secure Computing”, IEEE Trans. On Dependable and Secure Computing, Vol.1, No. 1, Jan.-March 2004
4. T. Kikuno, “Requirements for Dependability in the 21th Century”, Speech at the Kickoff Symposium of JST/CREST† Dependable Embedded OS Project, December 2006
5. M. Tokoro, “On Designing Dependable Operating Systems for Social Infrastructures”, Keynote Speech at MPSoC, Awaji Island, Japan, June 25, 2007.
6. 安浦 寛人、「社会システムを支えるディペンダブルコンピューティング」、電子情報通信学会誌、Vol.90, No.5, pages 399-405, May. 2007
7. 加納 敏行、菊池 芳秀、「ディペンダブルIT・ネットワークとは」、NEC技法、Vol.59, No.3, 2006, pages 6-10
8. M. Y. Hsiao, W. C. Carter, J. W. Thomas, and W. R. Stringfellow, “Reliability, Availability, and Serviceability of IBM Computer Systems: A Quarter Century of Progress”, IBM J. Res. Develop., Vol. 25, No. 5, 1981, pages 453-465
9. A. G. Ganek and T. A. Corbi, “The dawning of the autonomic computing era”, IBM Systems Journal, Vol 42, No. 1, 2003, pages 5-18
10. “An architectural blueprint for autonomic computing, 4th edition”, IBM Autonomic Computing White Paper, June 2006
11. http://www-03.ibm.com/autonomic/
12. 所 眞理雄、「技術成熟期における研究開発」、電子情報通信学会誌、Vol.90, No.9, 2007, pages 742-744
13. 所 眞理雄、他、「オープン システム サイエンス」、NTT出版
14. H. B. Diab, A. Y. Zomaya, “Dependable Computing Systems”, Wiley-Interscience
15. G. M. Koob, C. G. Lau, “Foundations of Dependable Computing”, Kluwer Academic Publishers
16. M. C. Huebscher, J. A. McCann, “A survey of Autonomic Computing”, ACM Computing Surveys, Vol. 40, No.3, Article 7, August 2008, pages 7:1-7:28
17. 松田 晃一、巻頭言、IPA SEC journal No.16，第５巻第１号（通巻１６号）2009, page 1
18. T. Forbath, interview「日本企業は２０世紀型の開発プロセスから脱却すべき」NIKKEI ELECTRONICS 2009.2.23, page 29
19. A.Avizienis, ” Design of fault-tolerant computers”, In Proc. 1967 Fall Joint Computer Conf., AF†IPS Conf. Proc.Vol.31, pages 733-743, 1967
20. ナシームNタレブ、「ブラックスワン」、ダイヤモンド社.
21. ナンシーGレブソン、「セーフウェア」、翔泳社
22. 不具合連鎖「プリウス」リコールからの警鐘、日経BP社/
23. 大和田 尚孝、他、「システムはなぜダウンするのか」、日経BP社
24. H. B. Diab, A. Y. Zomaya, “DEPENDA†BLE COMPUTING SYSTEMS”, WILEY-INTERSCIENCE
25. G. M. Koob, C. G. Lau, “FOUNDA†TIONS OF DEPENDA†BLE COMPUTING”, KLUWER ACADEMIC PUBLISHERS
26. K.Kanoun, L.Spainhower, “Dependability Benchmarking for Computer Systems”, IEEE COMPUTER SOCIETY
27. B.Kirwan,"A Guide to PRACTICAL HUMAN RELIABILITY ASSESSMENT”,CRC PRESS
28. 「安全・安心を実現する情報社会基盤の普及に向けて」(http://www.scj.go.jp/ja/info/kohyo/pdf/kohyo-20-t58-4.pdf ）、日本学術会議 情報学委員会セキュリティ・ディペンダビリティ分科会 （委員長 今井 秀樹）、２００８年６月２６日
29. O.-J. Dahl, E. W. Dijkstra, C. A. R. Hoare, Structured Programming, Academic Press, London, 1972 ISBN 0-12-200550-3
30. Birtwistle, G.M. (Graham M.) 1973. SIMULA begin. Philadelphia, Auerbach.
31. Humphrey, Watts (March 1988). "Characterizing the software process: a maturity framework". IEEE Software 5 (2): 73–79. doi:10.1109/52.2014. http://www.sei.cmu.edu/reports/87tr011.pdf.
32. Humphrey, Watts (1989). Managing the Software Process. Addison Wesley. ISBN 0201180952.
33. http://www.sei.cmu.edu/cmmi/
34. Ultra-Large-Scale Systems: The Software Challenge of the Future, http://www.sei.cmu.edu/library/assets/ULS_Book20062.pdf
35. Dependable Operating Systems for Embedded Systems Aiming at Practical Applications Research Area (DEOS Project) White Paper Version1.0, DEOS-FY2009-WP-01, JST, Sep. 1, 2009
36. Dependable Operating Systems for Embedded Systems Aiming at Practical Applications Research Area (DEOS Project) White Paper Version2.0, DEOS-FY2010-WP-02, JST, Dec. 1, 2010
37. T P Kelly, R A Weaver, “The Goal Structuring Notation - A Safety Argument Notation”,
In proceedings of the Dependable Systems and Networks 2004 Workshop on Assurance Cases, July 2004
38. Workshop on Assurance Cases: Best Practices, Possible, Obstacles, and Future Opportunities, DSN 2004, 2004
39. European Organisation for the Safety of Air Navigation. Safety case development manual. European Air Traffic Management, 2006
40. Railtrack. Yellow Book 3. Engineering Safety Management Issue3, Vol. 1, Vol. 2, 2000.
41. Guidance for Industry and FDA Staff - Total Product Life Cycle: Infusion Pump - Premarket Notification [510(k)] Submissions http://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/GuidanceDocuments/ucm206153.htm#6
42. City University London Centre for Software Reliability http://www.city.ac.uk/informatics/school-organisation/centre-for-software-reliability/research
43. D-Case† Editor http://www.il.is.s.u-tokyo.ac.jp/deos/dcase/
44. Kimio Kuramitsu. Konoha: implementing a static scripting language with dynamic behaviors. In Proceeding S3 '10 Workshop on Self-Sustaining Systems, ACM Press, 2010.
45. Takahiro Kosakai, Toshiyuki Maeda and Akinori Yonezawa, “Compiling C Programs into a Strongly Typed Assembly Language”, In proceedings of the 12th Asian Computing Science Conference (ASIAN 2007). pp. 17-32. Doha, Qatar, Dec. 2007.
46. Motohiko Matsuda, Toshiyuki Maeda, and Akinori Yonezawa, “Towards Design and Implementation of Model Checker for System Software” , In proceedings of the 12th Asian Computing Science Conference (ASIAN 2007). pp. 17-32. Doha, Qatar, Dec. 2007.7). pp. Systems (STFSSD 2009), Tokyo, Japan, January 2009.
47. 加藤 真平、他、「ディペンダブルシステム向けベンチマークフレームワークの提案」 第7回ディペンダブルシステムワークショップ DSW2009、 pp. 171-178、 2009年7月
48. Toshihiro Hanawa, Hitoshi Koizumi, Takayuki Banzai, Mitsuhisa Sato, and Shin’ichi Miura, “Customizing Virtual Machine with Fault Injector by Integrating with SpecC Device Model for a software testing environment D-Cloud”, the 16th IEEE Pacific Rim International Symposium on Dependable Computing (PRDC '10), pp. 47-54, Dec. 2010. doi: 10.1109/PRDC.2010.37
49. Takayuki Banzai, Hitoshi Koizumi, Ryo Kanbayashi, Takayuki Imada, Toshihiro Hanawa, and Mitsuhisa Sato, “D-Cloud: Design of a Software Testing Environment for Reliable Distributed Systems Using Cloud Computing Technology”, the 2nd International Symposium on Cloud Computing (Cloud 2010) in conjunction with the 10th IEEE/ACM International Conference on Cluster, Cloud and Grid Computing (CCGrid 2010), pp. 631-636, May 2010. doi: 10.1109/CCGRID.2010.72
50. Toshihiro Hanawa, Takayuki Banzai, Hitoshi Koizumi, Ryo Kanbayashi, Takayuki Imada, and Mitsuhisa Sato, “Large-Scale Software Testing Environment Using Cloud Computing Technology for Dependable Parallel and Distributed Systems”, the 2nd International Workshop on Software Testing in the Cloud (STITC 2010), co-located with the 3rd IEEE International Conference on Software Testing, Verification, and Validation (ICST 2010), pp. 428-433, Apr. 2010. doi: 10.1109/ICSTW.2010.59
51. Daniel P. Siewiorek, Robert S. Swarz, “Reliable Computer Systems: Design and Evaluation”, Third Edition. A K Peters/CRC Press. 1998.
52. A.M. Davis, Just Enough Requirements Management: Where Software Development Meets Marketing, Dorset House. 2005.
53. Object Management Group/Business Process Management Initiative: http://www.bpmn.org/
54. Smalltalk: http://www.smalltalk.org/main/
55. Nancy Leveson: “A new accident model for engineering safer systems”, Safety Science, Volume 42, Issue 4, Pages 237-270, April 2004.
A. 付録
A.1. DEOSプロジェクト研究開発体制
本研究領域は研究総括・副研究総括のもとに領域アドバイザーを置き、研究領域の方向性や内容に関するアドバイス及び研究チームの進捗評価を行っている。領域運営アドバイザーは実用化に向けての指針などをアドバイスしている。また、研究推進委員として企業の技術者等がプロジェクトに協力して、本研究成果を実利用する立場からアドバイスを行うなど研究チームとの交流を行っている。
本研究領域は2006年に採択された５研究チームによって開始され、2008年に新たに４研究チームがこれに加わった。2006年度採択チームはバーチャルマシン、サーバ群の仮想化、プログラム検証、ベンチマーキング、フォルトシミュレーション、リアルタイム・低消費電力化など、主に要素技術からの研究開発を開始するとともに、対象とするべきシステムの検討やディペンダビリティの概念の議論を行った。2008年採択チームは2006年度採択チームに加わって、DEOSプロセス、DEOSアーキテクチャを構築し、また、要求分析手法、合意形成†とその記述方法、セキュリティ、などの研究開発に加え、国際標準化活動を行っている。2006年度採択研究チームは2012年3月、2008年度採択チームは2014年3月まで研究開発を継続する。
採択された研究チームの活動と並行して、2008年より各研究チームからメンバーを集めてコアチームを形成し、研究全体を俯瞰し、その方向ならびに具体的な研究開発テーマを再定義するプロジェクト活動を行ってきた（DEOSプロジェクト）。そして2010年度より具体的な研究テーマを担当するサブコアチームを構成し、クロスチームでの研究開発を行っている。DEOSプロセス及びアーキテクチャの主な構成要素の研究・開発を担当し、これまでに、D-Case† & Metrics、D-Script & Monitor、VM & Multi-OS、System Software Verification、DS-Bench & Test-Envなどのサブコアチームが構成され、成果を上げている。サブコアチームは目的によって動的に再編成され、本プロジェクトの成果を最大限にもたらすように活動を続けている。
研究チームやサブコアチームの成果はディペンダブル組込みOS研究開発センター（DEOS研究開発センター）において、実用のための統合、知的資産や保守を考慮した再構成、テスト、実用のための評価やパッケージングなどを行い、企業との共同の評価や実際の製品での活用などにつなげていく（図１７参照）。
本研究領域は2006年に採択された５研究チームによって開始され、2008年に新たに４研究チームがこれに加わった。2006年度採択チームはバーチャルマシン、サーバ群の仮想化、プログラム検証、ベンチマーキング、フォルトシミュレーション、リアルタイム・低消費電力化など、主に要素技術からの研究開発を開始するとともに、対象とするべきシステムの検討やディペンダビリティの概念の議論を行った。2008年採択チームは2006年度採択チームに加わって、DEOSプロセス、DEOSアーキテクチャを構築し、また、要求分析手法、合意形成†とその記述方法、セキュリティ、などの研究開発に加え、国際標準化活動を行っている。2006年度採択研究チームは2012年3月、2008年度採択チームは2014年3月まで研究開発を継続する。
採択された研究チームの活動と並行して、2008年より各研究チームからメンバーを集めてコアチームを形成し、研究全体を俯瞰し、その方向ならびに具体的な研究開発テーマを再定義するプロジェクト活動を行ってきた（DEOSプロジェクト）。そして2010年度より具体的な研究テーマを担当するサブコアチームを構成し、クロスチームでの研究開発を行っている。DEOSプロセス及びアーキテクチャの主な構成要素の研究・開発を担当し、これまでに、D-Case† & Metrics、D-Script & Monitor、VM & Multi-OS、System Software Verification、DS-Bench & Test-Envなどのサブコアチームが構成され、成果を上げている。サブコアチームは目的によって動的に再編成され、本プロジェクトの成果を最大限にもたらすように活動を続けている。
研究チームやサブコアチームの成果はディペンダブル組込みOS研究開発センター（DEOS研究開発センター）において、実用のための統合、知的資産や保守を考慮した再構成、テスト、実用のための評価やパッケージングなどを行い、企業との共同の評価や実際の製品での活用などにつなげていく（図１７参照）。
A.2. DEOSプロジェクト・ロードマップ
以下のフェーズを主なマイルストーンとして全体の研究を進めて行く（図１８参照）。
・フェーズ１
（2006/10-2009/9）： ディペンダビリティのコンセプトの確立、それを支える開発・運用プロセスや重要な評価指標を含むシステムアーキテクチャの提示、および2006年度採択研究チームの要素技術のいくつかをインテグレーションしたデモシステムによるデモ。（以上を2009年9月に2006年度採択究チーム中間成果報告会として公開した）
・フェーズ２
（2009/10-2011/9）： システムアーキテクチャと2006年度採択研究チームの要素技術を取り込んだD-REとツール類の実装。企業や研究機関などを含むコンソーシアム/成果使用団体の立ち上げ準備の開始。必要な事項の国際標準化活動。2008年度採択研究チームの要素技術のいくつかをD-REとツール群にインテグレーションしてデモ。（以上を2011年に2006年度採択研究チーム最終成果報告会および2008年度採択研究チーム中間成果報告会として公開する）
・フェーズ３
（2011/10-2014/3）：コンソーシアム設立幹事会の立ち上げ、コンソーシアムメンバーによるD-REとツール群の試用、およびその評価のフィードバックの継続と実際の開発や実用化への移行。必要な事項の国際標準化。
・フェーズ４
（2014/4- ）：コンソーシアムによる成果の活用と維持・発展。業界別標準化などの策定推進。
（2006/10-2009/9）： ディペンダビリティのコンセプトの確立、それを支える開発・運用プロセスや重要な評価指標を含むシステムアーキテクチャの提示、および2006年度採択研究チームの要素技術のいくつかをインテグレーションしたデモシステムによるデモ。（以上を2009年9月に2006年度採択究チーム中間成果報告会として公開した）
・フェーズ２
（2009/10-2011/9）： システムアーキテクチャと2006年度採択研究チームの要素技術を取り込んだD-REとツール類の実装。企業や研究機関などを含むコンソーシアム/成果使用団体の立ち上げ準備の開始。必要な事項の国際標準化活動。2008年度採択研究チームの要素技術のいくつかをD-REとツール群にインテグレーションしてデモ。（以上を2011年に2006年度採択研究チーム最終成果報告会および2008年度採択研究チーム中間成果報告会として公開する）
・フェーズ３
（2011/10-2014/3）：コンソーシアム設立幹事会の立ち上げ、コンソーシアムメンバーによるD-REとツール群の試用、およびその評価のフィードバックの継続と実際の開発や実用化への移行。必要な事項の国際標準化。
・フェーズ４
（2014/4- ）：コンソーシアムによる成果の活用と維持・発展。業界別標準化などの策定推進。
A.3. DEOSプロジェクト主要メンバー
A.4. 近年の障害事例
A.5. 要求管理項目表
A.6. 開放系障害要因表
A.7. DEOSプロセスメトリクス（案）
A.8. DEOSプロジェクト用語集
【あ行】
安全性（Security）システムが外部から意図的に攻撃されても防御できる事
逸脱した要求 (Deviated Requirements)ステークホルダ合意から逸脱した要求の状態
運用状態（In-Operation）ステークホルダ合意（サービスレベル変動許容範囲）内でシステムを運用し
サービスを継続している状態
エビデンス（Evidence）議論において主張を支える情報
オープンシステム（Open Systems）開放系。外部との相互作用があり、機能、構造、境界
およびそれらの関係が時と共に変化する系
オープンシステムディペンダビリティ（Open Systems Dependability）開放系に対するディペンダビリティ
詳しくは２章参照。
【か行】
開放系障害（Open Systems Failure）不完全さと不確実さに起因するオープンシステムの障害
仮想化技術（Virtualization Technology）計算機資源を抽象化し、論理的に分割する技術
型検査（Type Checking）プログラム中の値や式を型で分類し、プログラムの性質を検証する手法
型付アセンブリ言語（TAL: Typed Assembly Language）型検査が可能なアセンブリ言語
可用性（Availability）システムが稼働し続ける事
クローズドシステム（Closed Systems）閉鎖系。外部との相互作用が限定的で、構成要素やそれらの
関係が変化しない系
形式的検証 （Formal Verification）数理的技法に基づいてプログラムの性質を厳密に証明すること
原因究明（Cause Analysis）エビデンスを基に障害原因、あるいは原因のありそうな範囲を
特定すること
合意された要求（Agreed Requirements）ステークホルダにより合意された要求の状態
コンソーシアム（Consortium）利害関係者が集まって活動をする事により目的を達しようとする団体
【さ行】
システムアーキテクチャ（System Architecture）システムの設計思想、基本機能ならびに基本構造
実現された要求（Realized Requirements）実システムに組み入れられ実装されたシステム要求
仕様記述言語 （Specification Description Language）プログラムの満たすべき性質を記述するための
言語
障害（Failure）運用においてサービスレベルに関するステークホルダ合意からの逸脱
障害対応サイクル（Failure Response Cycle）障害に対応するサイクル
迅速対応（Responsive Action）障害や異常状態に迅速かつ適切に対応する事
信頼性（Reliability）システムが期待期間、期待された機能を実行しつづける事
ステークホルダ（Stakeholders）システムやサービスに権利・義務・関心を持つ個人あるいは組織
利害関係者。詳しくは３章参照。
ステークホルダ合意（Stakeholders’ Agreement）ステークホルダ間のサービスレベル変動許容範囲と
障害対応方法についての利害関係合意
説明責任遂行（Accountability Achievement）障害発生時には現状、原因、回復見込みなど、
サービス変更時にはサービス開始時期や条件を明らかにして利用者に説明する事
【た行】
抽出された要求(Elicited Requirements) ステークホルダのニーズから抽出され同定された要求の状態
通常運用（Ordinary Operation）適切な定期点検、予防保守、継続的な改善活動による不具合再発防止
などを含む日常運用
通常運用時要求（Ordinarily Operated Requirements）運用時における要求の状態
ディペンダビリティ（Dependability）信頼性や安全性など、システムの提供するサービスを安心して
継続的に利用できる性質、その能力
DEOSアーキテクチャ（DEOS Architecture）分野・アプリケーション別にDEOSプロセスを支援する。
合意記述データ†ベース、開発支援ツール群、DR-Eからなる
DEOSプロセス（DEOS Process）OSDを実現するための「変化対応サイクル」と「障害対応サイクル」
からなる反復的プロセス
Dアウェアアプリケーション（D-Aware Application）D-RE のAPIによりマネージされるアプリケーションプログラム
Dケース（D-Case†）DEOSにおける合意形成†のための方法並びにツール
Dスクリプト（D-Script）DEOSにおける動的対応スクリプト
【は行】
不確実さ（Uncertainty）システムが変容し、振る舞いが事前に予測できない事
不完全さ（Incompleteness）システムが完全に要求を実現しない状態
不具合（Incident）不都合な事象
ブラックボックス（Black Box）内部構造を見ることができず、外部仕様のみから機能が活用される製品
プロセス（Process）システムやサービスを開発し運用するためのステップ（フェーズ）の連続体
変化対応サイクル（Change Accommodation Cycle）ステークホルダの目的変化あるいは環境変化に
対応するサイクル
変動許容範囲（In-Operation Range）ステークホルダ間で合意されたサービスレベルの変動許容範囲
保守性（Serviceability、Maintainability）システム保守のやりやすさ
保全性（Integrity）処理されるデータ†の整合性が保たれる事
【ま行】
マネージ（Manage）問題を努力して解決し、システムの状態をより好ましい方向に持って行くこと
未然回避（Failure Prevention）システム異常や障害の予兆を検知して、障害発生を回避する事
メトリクス（Metrics）定性的、定量的に対象を評価する指標
モデル検査（Model Checking）プログラムの取り得る実行状態を探索することでプログラムの性質を
検証する手法
【や行】
要求状態管理モデル（Requirements States Management Model）要求状態を管理するモデル
要求抽出（Requirements Elicitation）ステークホルダ間の目的や要望を合意形成†を経て要求として
特定する事
要求マネジメント（Requirements Management）ステークホルダの合意に従って要求を管理する方法
要素技術（Elemental Technology）個々の要求された機能を実現する技術
【ら行】
レガシーソフト（Legacy Software）製作者・保守者がいなくなっても使われ続けているソフトウェア
安全性（Security）システムが外部から意図的に攻撃されても防御できる事
逸脱した要求 (Deviated Requirements)ステークホルダ合意から逸脱した要求の状態
運用状態（In-Operation）ステークホルダ合意（サービスレベル変動許容範囲）内でシステムを運用し
サービスを継続している状態
エビデンス（Evidence）議論において主張を支える情報
オープンシステム（Open Systems）開放系。外部との相互作用があり、機能、構造、境界
およびそれらの関係が時と共に変化する系
オープンシステムディペンダビリティ（Open Systems Dependability）開放系に対するディペンダビリティ
詳しくは２章参照。
【か行】
開放系障害（Open Systems Failure）不完全さと不確実さに起因するオープンシステムの障害
仮想化技術（Virtualization Technology）計算機資源を抽象化し、論理的に分割する技術
型検査（Type Checking）プログラム中の値や式を型で分類し、プログラムの性質を検証する手法
型付アセンブリ言語（TAL: Typed Assembly Language）型検査が可能なアセンブリ言語
可用性（Availability）システムが稼働し続ける事
クローズドシステム（Closed Systems）閉鎖系。外部との相互作用が限定的で、構成要素やそれらの
関係が変化しない系
形式的検証 （Formal Verification）数理的技法に基づいてプログラムの性質を厳密に証明すること
原因究明（Cause Analysis）エビデンスを基に障害原因、あるいは原因のありそうな範囲を
特定すること
合意された要求（Agreed Requirements）ステークホルダにより合意された要求の状態
コンソーシアム（Consortium）利害関係者が集まって活動をする事により目的を達しようとする団体
【さ行】
システムアーキテクチャ（System Architecture）システムの設計思想、基本機能ならびに基本構造
実現された要求（Realized Requirements）実システムに組み入れられ実装されたシステム要求
仕様記述言語 （Specification Description Language）プログラムの満たすべき性質を記述するための
言語
障害（Failure）運用においてサービスレベルに関するステークホルダ合意からの逸脱
障害対応サイクル（Failure Response Cycle）障害に対応するサイクル
迅速対応（Responsive Action）障害や異常状態に迅速かつ適切に対応する事
信頼性（Reliability）システムが期待期間、期待された機能を実行しつづける事
ステークホルダ（Stakeholders）システムやサービスに権利・義務・関心を持つ個人あるいは組織
利害関係者。詳しくは３章参照。
ステークホルダ合意（Stakeholders’ Agreement）ステークホルダ間のサービスレベル変動許容範囲と
障害対応方法についての利害関係合意
説明責任遂行（Accountability Achievement）障害発生時には現状、原因、回復見込みなど、
サービス変更時にはサービス開始時期や条件を明らかにして利用者に説明する事
【た行】
抽出された要求(Elicited Requirements) ステークホルダのニーズから抽出され同定された要求の状態
通常運用（Ordinary Operation）適切な定期点検、予防保守、継続的な改善活動による不具合再発防止
などを含む日常運用
通常運用時要求（Ordinarily Operated Requirements）運用時における要求の状態
ディペンダビリティ（Dependability）信頼性や安全性など、システムの提供するサービスを安心して
継続的に利用できる性質、その能力
DEOSアーキテクチャ（DEOS Architecture）分野・アプリケーション別にDEOSプロセスを支援する。
合意記述データ†ベース、開発支援ツール群、DR-Eからなる
DEOSプロセス（DEOS Process）OSDを実現するための「変化対応サイクル」と「障害対応サイクル」
からなる反復的プロセス
Dアウェアアプリケーション（D-Aware Application）D-RE のAPIによりマネージされるアプリケーションプログラム
Dケース（D-Case†）DEOSにおける合意形成†のための方法並びにツール
Dスクリプト（D-Script）DEOSにおける動的対応スクリプト
【は行】
不確実さ（Uncertainty）システムが変容し、振る舞いが事前に予測できない事
不完全さ（Incompleteness）システムが完全に要求を実現しない状態
不具合（Incident）不都合な事象
ブラックボックス（Black Box）内部構造を見ることができず、外部仕様のみから機能が活用される製品
プロセス（Process）システムやサービスを開発し運用するためのステップ（フェーズ）の連続体
変化対応サイクル（Change Accommodation Cycle）ステークホルダの目的変化あるいは環境変化に
対応するサイクル
変動許容範囲（In-Operation Range）ステークホルダ間で合意されたサービスレベルの変動許容範囲
保守性（Serviceability、Maintainability）システム保守のやりやすさ
保全性（Integrity）処理されるデータ†の整合性が保たれる事
【ま行】
マネージ（Manage）問題を努力して解決し、システムの状態をより好ましい方向に持って行くこと
未然回避（Failure Prevention）システム異常や障害の予兆を検知して、障害発生を回避する事
メトリクス（Metrics）定性的、定量的に対象を評価する指標
モデル検査（Model Checking）プログラムの取り得る実行状態を探索することでプログラムの性質を
検証する手法
【や行】
要求状態管理モデル（Requirements States Management Model）要求状態を管理するモデル
要求抽出（Requirements Elicitation）ステークホルダ間の目的や要望を合意形成†を経て要求として
特定する事
要求マネジメント（Requirements Management）ステークホルダの合意に従って要求を管理する方法
要素技術（Elemental Technology）個々の要求された機能を実現する技術
【ら行】
レガシーソフト（Legacy Software）製作者・保守者がいなくなっても使われ続けているソフトウェア
A.9. DEOSプロジェクト略語集
ADD（Agreement Description Database）
DEOS（Dependable Embedded Operating Systems / Dependability Engineering for Open Systems）
D-DST（DEOS Development Support Tools）
D-RE（DEOS Runtime Environment）
OSD（Open Systems Dependability）
DEOS（Dependable Embedded Operating Systems / Dependability Engineering for Open Systems）
D-DST（DEOS Development Support Tools）
D-RE（DEOS Runtime Environment）
OSD（Open Systems Dependability）
A.10. 世界の関連標準、関連活動団体
標準
【参照 URL（外部サイトへリンクします）】
-
http://www.iec.ch/zone/fsafety/fsafety_entry.htm
IEC 61508: Functional Safety -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=sea22.p&search=text&searchfor=IEC+60300-1&submit=OK
IEC 60300-1: Dependability Management -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=sea22.p&search=text&searchfor=IEC+60300-2&submit=OK
IEC 60300-2: Dependability Program Elements and Tasks -
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=21208
ISO/IEC 12207: Software Life Cycle Processes -
http://www.iso.org/iso/iso_catalogue/catalogue_tc/catalogue_detail.htm?csnumber=43564
ISO/IEC 15288: System Life Cycle Processes
プロセスガイド・フレームワーク
【参照 URL（外部サイトへリンクします）】
-
http://www.sei.cmu.edu/cmmi/
CMMI: Capability Maturity Model® Integration -
http://www.rtca.org/
DO-178B: Software Considerations in Airborne Systems and Equipment Certification -
http://www.misra-c.com/
MISRA-C -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=sea22.p&search=text&searchfor=IEC+61713&submit=OK
IEC 61713: Software dependability through the software life-cycle processes- Application guide -
http://www.iec.ch/cgi-bin/procgi.pl/www/iecwww.p?wwwlang=E&wwwprog=sea22.p&search=text&searchfor=IEC+62347&submit=OK
IEC 62347: Guidance on system dependability specifications -
http://www.opengroup.org/togaf/
TOGAF:The Open Group Architecture Framework
ソフトウェア
【参照 URL（外部サイトへリンクします）】
-
http://www.nsa.gov/research/selinux/index.shtml
SELinux: Security-Enhanced Linux -
http://www.nsa.gov/research/selinux/index.shtml
SELinux: Security-Enhanced Linux -
http://www.xen.org/
Xen® hypervisor: the powerful open source industry standard for virtualization
関連団体・プロジェクト
【参照 URL（外部サイトへリンクします）】
-
http://www.iso.org/iso/home.htm
ISO: International Organization for Standardization -
http://www.iec.ch/
IEC: International Electrotechnical Commission -
http://www.iso.org/iso/standards_development/technical_committees/list_of_iso_technical_committees/iso_technical_committee.htm?commid=45020
ISO/IEC JTC1: Joint ISO/IEC Technical Committee 1 -
http://tc56.iec.ch/index-tc56.html
IEC/TC56: Technical Committee 56: IEC Technical Committee for International Standards in the field of Dependability -
http://www.opentc.net/
OpenTC Consortium: Open Trusted Computing Consortium -
http://linux-ha.org/
Linux-HA Project: High Availability Linux Project -
http://www.linuxfoundation.org/en/Carrier_Grade_Linux
Carrier Grade Linux Workgroup： -
http://www.trustedcomputinggroup.org/home
TCG: Trusted Computing Group -
http://ertos.nicta.com.au/
ERTOS Group: Embedded Real-Time Operating-Systems Group -
http://www.artemis.eu/
ARTEMIS: Advanced Research & Technology for EMbedded Intelligence and Systems -
http://www.nsf.gov/pubs/2008/nsf08611/nsf08611.htm
CPS Program: Cyber-Physical Systems Program -
http://www.misra.org.uk/
MISRA: Motor Industry Software Reliability Association -
http://www.autosar.org/
AUTOSAR: AUTomotive Open System ARchitecture -
http://www.jaspar.jp/
JasPar: Japan Automotive Software Platform and Architecture -
http://www.flexray.com/
FlexRay Consortium: Consortium for the communications system for advanced automotive control applications -
http://www.notaworld.org/
NoTA: Network on Terminal Architecture -
http://www.limofoundation.org/
LIMO Foundation: Industry Consortium dedicated to Linux-based operating system for mobile devices -
http://www3.opengroup.org/
The Open Group -
http://www.isaca.org/Knowledge-Center/COBIT/Pages/Overview.aspx
CoBIT: Control Objectives for Information and related Technology -
http://www.itil.org/en/vomkennen/itil/index.php
ITIL: Information Technology Infrastructure Library