CN103339612A - 可靠性维持装置、可靠性维持系统、障碍处理系统、可靠性维持装置的控制方法、控制程序以及记录该程序用的电脑可读取记录介质 - Google Patents

Abstract

本发明所述的工作区电脑（101）和/或运行时电脑（102）基于描述了对象系统可靠性的相关要求和规格的可靠性描述数据，求出定量地表示对象系统可靠性价值的D值。

Description

可靠性维持装置、可靠性维持系统、障碍处理系统、可靠性维持装置的控制方法、控制程序以及记录该程序用的电脑可读取记录介质

技术领域

本发明涉及一种能够计测和评价对象系统的可靠性价值，所述对象系统具有与时间轴上可变化的可靠性要求对应地表现出某一时刻的该要求的可靠性描述数据，该对象系统的可靠性维持装置等。

背景技术

最近，银行在线系统发生停止、便携式电话或IP电话通信出现障碍、各种商用服务发生安全性障碍等承担重要社会基础设施的系统或服务停止等问题不断涌现出来，对我们的生活造成了很大影响。其原因可归纳为，仅仅在利用这些组装型电脑系统的商品或服务中，其规模和复杂度不断剧烈增大。试着进一步挖掘调清其原因时，存在有人为相当多错误为起因的事例。

以往，关于电脑系统的可靠性、可用性、维护性、安全性、完备性以及机密性，对于可靠性作为电脑系统应具有的性质来探讨（非专利文献3）。在组装系统的开发中，最初制定开发计划，将对象系统或服务的功能要件以及非功能要件作为规格准确地写出，并长期进行验证和测试，获得了调配的方法。但是，如上所述，障碍发生数量日益增多。在以CMMI、ISO26262为首的规格中，也试图减少人为错误。但是，在这些已有的技术和规格中，对于开放环境中的系统特性欠考虑。

以往的方法是，基于假定开发时的规格作为电脑程序而可靠地安装起来，并且其规格在商品或服务调配后也不变。但是，在开放环境中，在开发时点和调配时点下环境发生着变化。进而，调配后环境也发生变化。其结果为，要求适应这些的变化。

因此，日本科学技术振兴机构在CREST程序中着手DEOS DEOS（Dependable Embedded Operating Systems／Dependability Engineering for Open Systems：可靠的嵌入式作业系统/开放系统可靠性工程）项目（http://www.crest-os.jst.go.jp/），进行嵌入式系统用可靠性操作系统的研发。在DEOS项目中，将开放环境中的可靠性如下那样定义为开放系统可靠性。“现代的大规模软件系统其功能、结构和系统边界随着时间发生变化，无法完全排除会以此为起因造成不完备性和不可靠性，本质上认定其就是未来成为障碍的主要原因（开放系障碍的主要原因）。所谓开放系统可靠性是指，将这些主要原因显现前尽量消除，而且在主因显现后迅速且适当应对，进行管理以使影响变为最小，尽量安全且继续地提供用户所期待的裨益，实现向社会说明的责任以及继续进行这些处理的能力。”（参考非专利文献1）

另外，以往，在嵌入式系统开发中（该开发中不受限定），制定利益相关方的要求以及该要求的相关说明书，基于此进行系统开发。具体而言，按照对象系统的功能要求以及汇总了非功能要求的说明书组开发系统。并且，在运用中变更了系统一部分的情况下，将说明书组与该系统的安装不相互矛盾地更新。

作为需要将该说明书与该系统安装不相互矛盾地进行更新的理由之一，例如该系统的可靠性（参照非专利文献1或非专利文献3等）无论环境如何变化也必须维持。因此，开发并追加了与该说明书相对应的可靠性描述数据的更新和监测用于实现该更新的系统的模块，必须保证始终与该说明书组不相互矛盾进行更新。

另外，在非专利文献2中，记载有在系统的生命周期（概念、开发、运用、维护、更新和废弃等）中需要对应于系统变更来更新记述了作为Safety Case的系统的安全性的文档的必要性。

Safety Case正在英国等推广，直到在开发和运用原子力发电站等要求高安全性的系统时以致尽到提交认证机关的义务，其作为用于表示系统的安全性依据（证据）的结构化的文档。作为汽车的功能安全规格的ISO26262也正在全世界推广以履行提出认证的义务等。

在先公布的文献如下：

专利文献：

专利文献1：美国专利第7756735号说明书（2010年7月13日）

非专利文献：

非专利文献1：马里奥常吕：“挑战开放系统问题” 2010年9月29日。 http://www.stanford.edu/class/ee380/Abstracts/100929.html （2011年7月7日检索）

非专利文献2：彼得·毕晓普和罗宾·布卢姆菲尔德：“安全案例管理的方法论”安全关键系统研讨会1998。 http://www.adelard.com/papers/sss98web.pdf （2011年7月7日检索）

非专利文献3：阿尔吉尔达·阿维滋恩斯，让-克洛德·拉普利，布赖恩兰德尔，以及卡尔·兰伟尔：“可靠和安全计算的基本概念和分类，” IEEE出版可信与安全计算汇刊vol.1，no.1，pp.11-33，2004年，1-3月。Doi：0.1109/TDSC.2004.2。

非专利文献4：所真理雄，以JST-CREST“用化作为目标的嵌入式系统用可靠性操作系统-DEOS项目-白皮书版本2.0（WhitePaperVersion2.0）”，DEOS-FY201-WP-02J，2010/12/01

非专利文献5：锦泽，松野丰，以及秀行德田：“在保证半结构化的情况下评估系统的可靠性程度” 第13届欧洲可信计算研讨会（EWDC2011），2011。

发明内容

本发明所需解决的问题在于：

系统规模膨大和复杂度增大导致该系统及其提供的服务的相关要求和规格也变复杂。因此，不可能在系统开发前完全提取出所有的要求，或者在系统开发前完全描述出所有规格是不可能的（规格的不完备性）。规格的不完备性所对应的安装也不完备（安装的不完备性），也无法完全把握该系统所提供的服务行动。其结果为，也不确定“将达到什么程度”以及“能够保证达到什么程度”。另外，这些不完备性导致对利益相关方之间的系统和服务的要求理解不同（误解）或者诱发人为错误。

进而，重新产生了用于适应先前叙述的环境变化的要求。另外，也需要对开发时的要求进行修正。事先不可预料“环境将如何变化”，因此，也无法预料“当前系统的运行状态能否可靠地适应环境变化”。对应于这样变化的不可靠性会导致难以预测系统运行状态，牵扯到系统障碍。

当这些不完备性或不可靠性导致发生系统障碍时，调查其原因需要时间，而且其难以适当应对，利益相关方也难以履行责任。

在这样的状况下，以往，在非专利文献2中，将系统开发时假定的障碍处理作为Safety Case（安全方案）而加以描述，通过利益相关方之间的协定，由此能够责成利益相关方在障碍发生时承担责任。但是，以环境的变化为起因造成Safety Case（安全方案）变更无法应对。

另外，非专利文献3抑制了在发生Faults-Errors-Failures（故障-错误-故障）的变化下捕捉到障碍而导致障碍的发生。但是，无法处理所述不完备性或不可靠性。

另外，在非专利文献5中，记载了用于处理所述不完备性和不可靠性的方法。然而，其描述与施行环境分开、描述的模型化及可靠性值的计测和评估只有在设计中才能实现。

另一方面，专利文献1记述了企业级架构（Enterprise Architecture）数学控制中的复杂性的方法。如果复杂性能够控制，则能够期待涉及可靠性的提高，但无法处理到所述不完备性、不可靠性。

另外，在现有的系统开发方法中，来自多个利益相关方的要求无法汇总到已协定的说明书中，或者在除了不容易汇总到说明书中而且运用后系统一部分发生了变更的情况下，无法不相互矛盾维持说明书与系统安装的变更。

例如，即使是所述的Safety Case（安全方案），也不存在Safety Case中所记载的维持利益相关方在Safety Case上协定的障碍处理内容与实际对象系统的障碍处理或系统监测部的开发追加等不相互矛盾的实用系统。如果这样的Safety Case与对象系统相互间的不矛盾性大致必须使用人手实施，则要使系统更新与Safety Case更新不相互矛盾进行会导致时间上的偏差，如此会出现众多的问题。一般，如Safety Case那样可保证以能够理解的形式描述包括认证机关等在内的广大范围的利益相关方的文档与系统实际动作之间的不相互矛盾性的实用系统并不在发明人知晓的范围中。

本发明是鉴于上述问题而作出，其目的在于实现了如下的可靠性维持装置，即，在潜在地存在不完备性和不可靠性的开放环境中，能够支持对象系统可靠性的维持，并且容易无冲突地维持对象系统的说明书组和该系统的安装等。此外，在本发明中，在非专利文献3等的定义中将系统的可靠性扩展到包括多个利益相关方间的协定。

为解决上述技术问题，本发明采用的技术方案是：

本发明提供一种可靠性维持装置用于维持对象系统的可靠性，其特征在于，具有：描述数据获取单元，其用于获取描述了对象系统可靠性相关要求和规格的可靠性描述数据；可靠性值确定单元，其基于所述描述数据获取单元所获得的可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值。

另外，本发明的可靠性维持装置的控制方法用于维持对象系统的可靠性，其特征在于，包括：获取描述了对象系统可靠性相关要求和规格的可靠性描述数据的描述数据获取步骤；基于经所述描述数据获取步骤获得的可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值的可靠性值确定步骤。

根据所述结构，能够基于描述了对象系统可靠性的相关要求和规格的可靠性描述数据，求出定量地表示对象系统的可靠性价值的评价值。此外，需要所述要求和规格经利益相关方协定达成一致意见（优选为至少达成协定）。

这样，能够定量地表现对象系统和可靠性价值，因此，例如，在随着要求的变更而变更可靠性描述数据时，或者在运用对象系统时确认对象系统的状态时，能够易于知晓且客观地提示对象系统的可靠性价值。

因此，起到能够顺利进行对象系统可靠性的维持和效果。即，在潜在存在不完备性和不可靠性的开放环境中，起到能够支持维持对象系统可靠性的效果。

另外，本发明的可靠性维持系统用于维持对象系统的可靠性，其特征在于，包括：工作区装置，其在所述对象系统开发时或更新时，施行与要求和规格的变更相对应地变更所述可靠性描述数据的变化应对循环；以及运行时间装置，其在运用所述对象系统时，检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，施行避免所述对象系统停止的障碍处理循环；所述工作区装置和所述运行时间装置至少其中一者基于所述可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值。

此外，所述可靠性维持装置能够通过电脑来实现，在该情况下，使电脑作为所述各种单元来动作而经电脑实现所述可靠性维持装置的可靠性维持装置的程序，以及记录有所述程序的电脑可读取记录介质也纳入本发明的范畴中。

另外，本发明的可靠性维持装置监视着监控对象系统（以下，在本发明中，特别是对象系统为监视对象的情况下，也将该对象系统称为监控对象系统）的状态，在必要情况下生成对用于施行对策的障碍监控部动作控制的障碍监测用数据，并供给至所述障碍监控部，其特征在于，所述可靠性维持装置具有可靠性描述变换部，所述可靠性描述变换部从可靠性描述存储部读取描述了所述监控对象系统可靠性的相关要求和规格的可靠性描述数据，并从读出的可靠性描述数据中生成所述障碍监测用数据。

再有，本发明的可靠性维持装置的控制方法在于，对着监控对象系统的状态进行监视，生成用于控制在必要情况下施行对策的障碍监控部动作的障碍监测用数据，并将所述数据提供给所述障碍监控部，其特征在于，包括：从可靠性描述存储部中读取用于描述读取所述监控对象系统可靠性的相关要求和规格的可靠性描述数据的步骤；以及从读出的可靠性描述数据生成所述障碍监测用数据的变换步骤。

根据所述结构，可靠性维持装置从经可靠性描述存储部读取的可靠性描述数据中生成障碍监测用数据。并且，据此障碍监控部进行动作，由此障碍监控部能够监视监控对象系统的状态，在必要情况下施行对策。

在此，可靠性描述数据描述了监控对象系统的可靠性的相关要求和规格。并且，在监控对象系统的各利益相关方对监控对象系统的可靠性达到一致意见时，其结果为，作为可靠性描述数据来描述，并存储在可靠性描述存储部中。

这样，障碍监控部所使用的障碍监测用数据是由可靠性维持装置从存储于可靠性描述存储部中的可靠性描述数据生成的，由此能够始终不相互矛盾维持可靠性描述数据与障碍监控部的动作。

另外，本发明的障碍处理系统也能够构成为，包括：所述可靠性维持装置、所述可靠性描述存储部以及所述障碍监控部，所述可靠性维持装置基于从经所述可靠性描述存储部读取的可靠性描述数据中生成的障碍监测用数据，所述障碍监控部进行动作，由此监视所述监控对象系统的状态，在必要情况下施行对策。

此外，所述可靠性维持装置以及障碍处理系统也能够通过电脑来实现，在该情况下，将电脑作为所述可靠性描述变换部来进行动作而经电脑使所述可靠性维持装置实现的可靠性维持装置的程序，以及存储所述程序的电脑可读取记录介质也进入本发明的范畴中。

与现有技术相比，本发明的有益效果是：

如上所述，本发明的可靠性维持装置构成为，具有：描述数据获取单元，其用于获取描述了对象系统可靠性相关要求和规格的可靠性描述数据；以及可靠性值确定单元，其基于所述描述数据获取单元所获得的可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值。

另外，本发明的可靠性维持装置的控制方法包括：用于获取描述了对象系统可靠性相关要求和规格的可靠性描述数据的描述数据获取步骤；基于经所述描述数据获取步骤获得的可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值的可靠性值确定步骤。

由此，能够定量表现对象系统可靠性价值。因此，起到了能够顺利维持对象系统可靠性的效果。即，在潜在性地存在不完备性和不可靠性的开放环境中，起到了能够支持维持对象系统可靠性的效果。

另外，本发明的可靠性维持装置构成为具有可靠性描述变换部，所述可靠性描述变换部从描述了经可靠性描述存储部读取的监控对象系统可靠性相关要求和规格的可靠性描述数据，并从所读取的可靠性描述数据生成障碍监测用数据。

另外，本发明的可靠性维持装置的控制方法包括：从可靠性描述存储部中读取描述了监控对象系统可靠性相关要求和规格的可靠性描述数据的读取步骤；从所读取的可靠性描述数据生成障碍监测用数据的变换步骤。

因此，障碍监控部所使用的障碍监测用数据是，由可靠性维持装置从存储于可靠性描述存储部中的可靠性描述数据中生成，由此起到能够始终不相互矛盾地维持可靠性描述数据与障碍监控部的动作效果。

本发明的再一目的在于，通过以下所示的记载可充分认识其特征以及优异点。另外，本发明的优点可通过参照了附图的以下说明来阐明。

附图说明

图1是表示本发明一实施方式的可靠性维持系统构成概略的功能框图。

图2是表示图1所示的可靠性维持系统的工作区电脑以及运行时电脑的硬件构成的框图。

图3是表示图1所示的可靠性维持系统中使用的软件的结构例子的框图。

图4是表示通过图1所示的可靠性维持系统处理的应用程序一个例子的说明图，其中，（a）表示应用程序为3层结构模型，（b）表示安装有3层结构模型时的一构成例子。

图5是表示经图1所示的可靠性维持系统处理的应用程序的可靠性描述数据一个例子（正常运行统）的说明图。

图6是表示经图1所示的可靠性维持系统处理的应用程序的可靠性描述数据一个例子（风险基础）的说明图。

图7是表示图6所示的可靠性描述数据与随着利益相关方要求变更而发生了变化的可靠性描述数据之间的差值的可靠性描述数据的描述例子的说明图。

图8是表示在图1所示的可靠性维持系统以及图42所示的障碍处理系统中，用作可靠性描述数据的D-Case的基本构成的说明图。

图9是表示利用图5所示的作为可靠性描述数据一部分的D-Case描述后的表现的说明图。

图10是表示在图1所示的可靠性维持系统中，用于计测和评价可靠性描述数据所体现的系统可靠性价值的方法的说明图，其中，（a）表示将各边沿（Edge）为要素的多维矢量值设为D值的方法，（b）表示将有效证据（Evidence）/总证据设为D值的方法，（c）表示将监测节点组的曲线图结构其本身设为D值方法。

图11是表示非专利文献5中所述的方法的说明图。

图12是表示图1所示的可靠性维持系统的D值计算部的结构例子的说明图。

图13是表示由图1所示的可靠性维持系统处理而将电子签名附加到经利益相关方协定的D-Case描述中的例子的说明图。

图14是表示由图1所示的可靠性维持系统处理且具有层次结构的监测节点例子的说明图。

图15是表示图1所示的可靠性维持系统所具有的变化应对循环和障碍处理循环概略的说明图。

图16是表示用于实现图15所示的可靠性维持系统所具有的迭代工序（process）的体系结构（Architecture）的框图。

图17是表示图1所示的可靠性维持系统具有的变化应对循环以及障碍处理循环的一系列步骤的流程图。

图18是表示图17所示的变化应对循环中的三个处理的流程图。

图19是表示图17所示的障碍处理循环中检测障碍发生时的两个处理的流程图。

图20是表示图19所示的障碍发生检测处理一个例子的图，其中，（a）表示可靠性描述数据的一部分，（b）表示使用监测节点用于障碍检测的可靠性维持系统结构例子的框图。

图21是表示图20所示的障碍发生检测处理中使用的、用于定义监测节点与监视模块的对应关系的表格一个例子的说明图。

图22是表示图19所示的障碍发生检测处理中使用的脚本的结构概要的说明图。

图23是表示图17所示的障碍处理循环中的，障碍预兆检测时的两个处理的流程图。

图24是表示图19所示的障碍发生检测处理中使用脚本的一个例子的说明图。

图25是表示图1所示的可靠性维持系统的运行时电脑的软件层次一个例子的说明图。

图26是表示汇总了由图1所示的可靠性维持系统的运行时电脑的隔离部实现的各隔离项目的相关功能要件一个例子的表格。

图27是表示图1所示的可靠性维持系统中的可靠性描述数据的变更提取处理的步骤的流程图。

图28是表示图1所示的可靠性维持系统中利用了可靠性描述数据的工作区电脑与运行时电脑间协作关系 的功能框图。

图29是表示将图5所示的可靠性描述数据作为计算机表现的一个例子而通过XML描述的列表一部分。

图30是图1所示的可靠性维持系统的结构例子，并表示可靠性描述数据数据库与工作区电脑以及运行时电脑之间的关系的说明图。

图31是表示图1所示的可靠性维持系统的运行时电脑中的命令施行的处理步骤的流程图。

图32是表示图1所示的可靠性维持系统中的可靠性描述数据相关联程序的处理内容的一个例子的流程图。

图33是表示图1所示的可靠性维持系统中的可靠性描述数据相关联程序的处理内容的其他例的流程图。

图34是表示图1所示的可靠性维持系统的工作区电脑所具有的工具组的各功能与可靠性描述数据之间关系的说明图。

图35是表示图1所示的可靠性维持系统中基准标记功能与D-Case Editor之间相互协作的说明图。

图36是表示图1所示的可靠性维持系统两个连接结构例子的框图。

图37是表示图36所示的两个可靠性维持系统相互连接的构成中，独立的两个可靠性维持系统间相互协作的一个例子的说明图。

图38是将表示图1所示的两个可靠性维持系统作为主体侧以及部件侧来统管的结构例子的框图。

图39是表示将图38所示的两个可靠性维持系统作为主体侧以及部件侧来统管的构成中，独立的两个可靠性维持系统间相互协作的一个例子的说明图。

图40是表示图38所示的两个可靠性维持系统作为主体侧以及部件侧来统管的构成中，将部件统合到主体中的处理步骤的流程图。

图41是表示利用了图1所示的可靠性维持系统的工作区电脑的可靠性描述数据表示例的说明图。

图42是本发明的其他实施方式的障碍处理系统的构成概略的功能框图。

图43是表示图42所示的障碍处理系统中，用作可靠性描述数据的D-Case具体例子的说明图。

图44是表示图42所示的障碍处理系统的处理的流程图。

图45是表示图42所示的障碍处理系统所使用的包含D-Case模式在内的D-Case具体例子的说明图。

图46是表示图42所示的障碍处理系统所使用的D-Case模式<=>模块对应表的一个例子，（a）表示监测模块的相关对应表，（b）表示执行模块的相关对应表。

图47是表示图42所示的障碍处理系统所使用的包含D-Case模式的D-Case具体例子的说明图。

图48是表示图42所示的障碍处理系统所使用的D-Case模式<=>模块对应表的一个例子，其中，（a）表示监测模块的相关对应表，（b）表示执行模块（Action module）的相关对应表。

图49是表示图42所示的障碍处理系统所使用的D-Case模式<=>模块对应表的一个例子，并示出监测模块的相关对应表。

图50是表示在图42所示的障碍处理系统中，用作可靠性描述数据D-Case另一具体例子的说明图（左半方）。

图51是表示在图42所示的障碍处理系统中，用作可靠性描述数据的D-Case另一具体例子的说明图（右半方）。

图52是表示以XML形式描述了图50、图51所示的D-Case的例子的说明图，并将来自一个样品的选取以图52～图55分解示出。

图53是表示以XML形式描述了图50、图51所示的D-Case的例子的说明图，并将来自一个样品的选取以图52～图55分解示出。

图54是表示以XML形式描述了图50、图51所示的D-Case的例子的说明图，并将来自一个样品的选取以图52～图55分解示出。

图55是表示以XML形式描述了图50、图51所示的D-Case的例子的说明图，一并将来自一个样品的选取以图52～图55分解示出。

图56是表示从图50、图51以及图52～图55所示的D-Case变换成的监测数据（障碍处理脚本）例子的说明图。

附图标记说明：

100（100U、100S、100B、100P） 可靠性维持系统

101 工作区电脑（可靠性维持装置、工作区装置）

101-05 D值计算部（可靠性值确定单元）

102 运行时电脑（可靠性维持装置、运行时间装置）

102-04 再构建部（再构建单元）

102-06 D值计算部（可靠性值确定单元）

102-07 脚本处理部（脚本处理单元）

901-01 可靠性描述数据输入部（描述数据获取单元）

902-01 软件输入部（描述数据获取单元）

902-02 变更送出部（变更要求发送单元）

P300 变化应对循环

P301 障碍处理循环

1 障碍处理系统

2 监控对象系统

10 D-Case存储部（可靠性描述存储部）

20 可靠性维持装置

21 D-Case变换部（可靠性描述变换部）

22 D-Case模式<=>模块对应表

30 障碍监控部

40 监测管理部

50 监测模块组（模块）

60 行动管理部

70 执行模块组（模块）

S2 读取步骤

S3 变换步骤

具体实施方式

〔第一实施方式〕

在潜在性地存在不完备性和不可靠性的开放环境中，本实施方式的工作区电脑101和/或运行时电脑102支持对象系统可靠性的维持。因此，如下所述，本实施方式的工作区电脑101和/或运行时电脑102，基于描述了对象系统可靠性相关规格的可靠性描述数据（也能够是通过在时间轴上模型可变的基础上将对象系统的结构作为可计算模型表现出来的之间的差值结构模型所描述的数据），求出对象系统可靠性价值为定量地表示的D值。

以下，基于图1至图41，详细说明本发明一实施方式。

〔1．硬件构成〕

图1是本实施方式的可靠性维持系统100的构成概略的功能框图。

如图1所示，可靠性维持系统100构成为，包括：作为可靠性维持装置的工作区（Work space）用电脑（可靠性维持装置、工作区装置）101；以及运行时间（Runtime）用电脑（可靠性维持装置、运行时间装置）102，这些电脑通过网络103相互连接起来。经工作区电脑101处理的软件SW在运行时电脑102中开展处理。另外，对象系统或应用程序系统及其施行所需的资料库、中间件和系统服务等支持系统包含在运行时电脑102中。软件SW具有能够通过二进制施行部110（110W、110R；在要将工作区电脑101的二进制施行部110W与运行时电脑102的二进制施行部110R区分开的情况下，以W、R标注来记述。）处理的表现形式。软件SW包括通过对象系统运行的应用程序及其施行所需的资料库、中间件和系统服务等施行环境。

工作区电脑101构成为，具有：验证工具部101-01、编辑工具部101-02、分析工具部101-03、开发工具部101-04、协定形成支持工具部101-05、二进制施行部110W。此外，功能块并不局限于上述这些功能块，在此也简单说明了这些代表性功能。

验证工具部101-01对软件SW进行验证。编辑工具部101-02对软件SW进行编辑。分析工具部101-03对软件SW进行分析。此时，也能够使用来自运行时电脑102的信息。开发工具部101-04用于软件SW的开发。

另外，运行时电脑102构成为，具有：更新部102-01、记录部102-02、监视部102-03、再构建部（再构建单元）102-04、隔离部102-05、脚本处理部（脚本处理单元）102-07、二进制施行部110R。此外，功能块并不局限于上述这些功能块，在此也简单说明了这些代表性功能。

更新部102-01更新了在运行时电脑102中处理的软件SW。记录部102-02记录了运行时电脑102内部的状态。当记录时，也能够依照软件SW的指示，还能够按照预先确定的预定设定进行记录。监视部102-03提取出运行时电脑102的内部状态参数的同时，算出后述D值。状态的获取也能够依照软件SW的指示，还能够按照预先确定的预定设定来获取。再构建部102-04变更了运行时电脑102的内部结构。在构成的变更时，能够依照软件SW的指示，也能够按照预先确定的预定设定来变更，还能够依照脚本的指示。隔离部102-05使运行时电脑102内部的一部分结构分割开独立。脚本处理部102-07施行从后述可靠性描述数据导出的脚本。

在此，如图1所示，可靠性维持系统100也能够是由个别二台的电脑构成的系统，也能够由1台电脑构成的系统，也能够由各个2台或2台以上的台数的电脑构成系统。在由2台或以上电脑构成时，只要各电脑经网络103连接即可。

图2示出工作区电脑101以及运行时电脑102的硬件构成。作为最基本的构成，工作区电脑101以及运行时电脑102为电子计算机，并分别具有：以数据用总线与命令用总线连接的运算装置151；控制装置152；存储器装置153；输出入装置154。基于自输出入装置154输入的比特数据信息，在运算装置151中，施行算术运算、逻辑运算、比较运算和移位运算等。所施行的数据根据需要而存储于存储器装置153中，从输出入装置154输出。这些一系列处理通过存储于存储器装置153中的软件程序，由控制装置152控制。在本实施方式中的工作区电脑101以及运行时电脑102是具有所述电脑所具备的基本功能的硬件，由操作系统、设备驱动器、中间件、应用程序软件等程序组控制。

图3示出了本实施方式的软件SW结构例子。版本管理信息104-01为该软件SW的相关版本管理相关信息，也能够包括时间标记。可靠性描述数据104-02为该软件SW相关的后述可靠性描述数据相关信息。二进制代码104-03是，以二进制施行部110能够解释施行的表现形式来描述该软件SW处理的信息。外部参照信息104-04是该软件SW需要或依存的外部软件的相关信息。

〔2．可靠性描述数据〕

图4是表示作为一个例子的应用程序的说明图。在此，以WEB应用程序为例进行说明。

图4（a）表示该应用程序构建了3层结构模型。表示层（Presentation）200-01担当该应用程序的表示（与输入）。数据存取层（Data access）200-03存储并管理该应用程序开始施行时所需的数据。应用程序逻辑层（Application logic）200-02通过用户的输入来施行该应用程序所需的计算处理，并将其结果传送给数据存取层200-02。或者，从数据存取层200-02获得该应用程序所需的数据，处理后，传送给表示层200-01以提示用户。

图4（b）表示安装所述3层结构模型时的一个结构例子。WEB Server（WEB服务器）201-02相当于所述表示层200-01。Client（用户）201-01为该应用程序的用户，其通过网络201-05来利用WEB Server201-02。也能够考虑包括Client201-01、网络201-05以及WEB Server201-02在内，以相当于表示层200-01。App Logic201-03相当于所述应用程序逻辑层200-02。App Logic（应用程序逻辑）201-03经由通信路201-06与WEB Server201-02进行信息交换，经由通信路201-07与DBS201-04进行信息交换。DBS201-04为数据库，用于进行App Logic201-03的处理或处理所需数据的存储和获取等管理。WEB Server201-02、App Logic201-03以及DBS201-04由运行时电脑102来施行，但是，这些管理能够在1台的电脑上施行，也能够分别各自在多台电脑上施行。

图5是所述应用程序的可靠性描述数据一个例子，从继续服务观点上描述了可靠性描述数据。所谓可靠性描述数据是指描述了经应用程序可靠性的相关利益相关方间协定的要求的模型。

以下，对图5所述的一个例子的内容进行说明。“WEB服务继续”（202-01）是一种所述应用程序可靠性的相关目标（goal），意味着WEB服务能够继续。为了实现该目标（202-01），需要在该可靠性描述数据中，满足“Client继续动作”（202-02），“WEB Server继续动作”（202-03），“App Logic继续动作”（202-04），“DBS继续动作”（202-05）这个四个特性。并且，分别与图4（b）的client201-001、WEB Server201-02、App Logic201-03以及DBS201-04相对应。

这些四个特性能够如下所述那样进一步细分（Breakdown）来描述。为了“Client继续动作”（202-02），需要“设备适当动作”（202-06）和“WEB Server适当反应”（202-10）两个特性的充分性。为了“WEB Server继续动作”（202-03），充分需要“请求的适当收发”（202-07）和“App Logic的适当反应”（202-11）两个特性的充分性。为了“App Logic继续动作”（202-04），需要“正常的业务处理”（202-08）“DBS的适当反应”（202-12）两个特性的充分性。为了“DBS继续动作”（202-05），需要“DB的一贯性”（202-09）和“数据的有效性”（202-13）两个特性的充分性。

所述多个特性的充分性能够根据图5中开始椭圆形节点所示的各种验证且施行时的监测结果来把握和判断。例如，“设备的适当动作”（202-06）能够经综合测试的“设备检查合格与否”（202-20）来判断该特性是否充分。开始“WEB Server的适当反应”（202-10）、“请求的适当收发”（202-07）时，在该服务器上附加存取基准标记，能够根据经施行时日志验证的“反应检查的合格与否”（202-21）、“迟延检查的合格与否”（202-22）来判断该特性是否充足。“App Logic的适当反应”（202-11）、“正常业务处理”（202-08）也同样能够根据经综合测试的“测试事例合格与否”（202-23、202-24）来判断该特性的充分性。“DBS的适当反应”（202-12）、“DB的一贯性”（202-09）以及“数据的有效性”（202-13）这些特性也能够基于经基准标记、应力测试（超负荷试验）、异常性测试（耐异常试验），或者基于经施行时数据库存取日志验证的各个“基准标记合格与否”（202-25）、“应力测试合格与否”（202-26）、“异常性测试合格与否”（202-27）来判断该特性是否充足。在本实施方式中，将这些椭圆形节点描述的验证作为对应节点特性是否充足的根据（证据）处理。此外，这些证据也利用后述监测节点的计测值。

图6是相对于图5表示系统正常运行相关的可靠性描述数据，而表示考虑了风险的基于场景的可靠性描述数据例子。即，通过考虑“如果×××发生，可获得×××对策？”脚本（Scenario），描述了可靠性描述数据。例如，在图6的例子中，节点的顶端描述了“如果DB的HDD的容量为临界值（如果构成数据库系统的硬盘容量未清空则可获得怎样对策？）”（203-01）的风险。在以下级别的节点中描述了用于该风险实际未被发现时的四个对策。“HDD容量扩展”（203-02）描述了利用硬盘的追加或更大容量磁盘驱动器上的置换等单元能够扩展容量。“利用备份DBS继续动作”（203-03）在数据库系统中准备了备份系统，使用该系统描述了数据库功能够继续作用。“利用缓存使App Logic继续”（203-04）描述了数据库无法利用的状况下也能够使用一部分缓存后的数据继续应用程序。“将细小错误返回给用户”（203-05）描述了不继续施行应用程序也能够将任何说明通知给用户。

这些节点（203-02～203-05）以这些副节点描述了其证实可能性的功能。例如，“HDD容量扩展”（203-02）利用“HDD设备热插拔（热插拔操作，即不停止运行能够更换磁盘驱动器）”（203-06）功能，或者“逻辑容量逻辑磁碟区的OS支持（磁碟区容量不受限于磁盘驱动器容量的系统功能）”（203-07）功能能够实现。“利用备份DBS而继续”（203-03），能够利用“备用机重启（预先准备多个数据库系统，当一个系统停止时使待机的系统启动而替换功能作用）”（203-08）功能，或者“仅仅双系统中的一系统继续运行（其一系统停止也能够继续发挥以两系统的数据库系统实现的功能）”（203-09）功能来实现。“利用缓存而使App Logic继续”（203-04），能够利用“向DB写入变更迟延（向数据库的存取发生迟延直到其复原）”（203-10）功能，或者“数据的时间标记（通过参照时间标记而原有数据也能够继续App Logic）”（203-11）功能来实现。最后的“将细小错误返回给用户”（203-05）能够利用“网络能够到达（网络通信能够到达至用户）”（203-12）来实现。

此外，这些边沿节点（203-06～203-12）利用图5中的椭圆形节点（证据）描述了这些特性的充分性，但在图6中被省略。

所述图5所述的可靠性描述数据和图6所述的可靠性记载数据，也能够用作经利益相关方间协定哪种数据后的可靠性描述数据。另外，作为更上位显示器（Scope）的可靠性描述数据的一部分，图5表示正常运行、图6表示风险系统，两者均能够用作经利益相关方间协定的可靠性描述数据。

图7是表示将随着利益相关方的要求变更而变化的可靠性描述数据与图6所示的可靠性描述数据之间的差值示出的可靠性描述数据描述例的说明图。

在图6中，“HDD容量扩展”（203-02）的可能性对该应用程序继续很重要。与此相对，在图7中，在任何环境的变化下，例如，在商务景气的好转下，确定了利益相关方增加和强化对数据库系统投资额的情况下，描述了与图6不同时刻的可靠性描述数据。即，确定代替图6中的“利用备份DBS来继续”（203-03）功能而采用“利用多重系统而不停止DBS”（204-01）功能的情况描述。使数据库不停止，由此不需要图6中的“利用缓存使App Logic继续”（203-04）。其结果为，图7中加有阴影的节点为与图6的节日间的差值。

图5至图7所示的可靠性描述数据也能够使用Safety Case表现（非专利文献2）来描述，如图8、图9所示，也能够使用D-Case表现来描述。

在此，使用图8，对D-Case表现的基本结构进行说明。将来自对象系统可靠性的相关利益相关方的要求作为最高目标210-01来描述。所谓最高目标是表示利益相关方要对对象系统协定的命题。例如，“对象系统满足按功能安全规格IEC61508定义的Safety Integrity Level 3”等。该最高目标的满足更详细化为树形结构，对详细化的次级目标210-05也同样更详细化为树形结构。次级目标是指为示出最高目标而将其表示事项分割细化的命题。次级目标分割为更小的次级目标。在本实施方式中，将最高目标和次级目标总称为目标。将该详细化的工序称为“争论结构”210-02。

将该目标分割为次级目标时，也能够描述表示该分割的辅助说明（理由/推理）的策略（strategy）。例如，图5所述的可靠性描述数据的一部分以D-Case描述来表现时，示于图9中。目标为“WEB服务继续”（202-01），作为与该目标链接的4项目的“Client继续动作”（202-02）、“WEB Server继续动作”（202-03），“App Logic继续动作”（202-04）、“DBS继续动作”（202-05）是各个次级目标，这些4项目为次级目标理由是策略“以副系统继续性观点而分割”（211-01）。

另外，上下文（Context）也能够链接到目标或策略。上下文是用于补充目标、策略内容的信息。例如，在图9中，相对于目标202-01而言成为上下文，在该目标“WEB服务继续”中，追加了作为对“继续”的补充说明的“在服务停止的情况下也能在1分钟以内进行复原”。

在目标中，存在表明其较为妥当的证据210-03、210-04。证据最终保证了被详细化分割的目标。证据的稳妥性基于利益相关方间的协定。证据不存在的目标不存在任何问题。

另外，在图5至图9中，将可靠性描述数据以树形结构表现出来。但是，也能够表现出节点间的依存关系，并以普通的曲线图结构来表现，或者也能够以表形式表现。以下，在本实施方式中，使用所述D-Case的表现作为可靠性描述数据来说明。

在本实施方式中，使用基于可靠性描述数据计算出的D值来计测和评价可靠性的价值。D值的计算是在工作区电脑101中由验证工具部101-01的D值计算部（可靠性值确定单元）101-05进行的，并且在运行时电脑102中由监视部102-03的D值计算部（可靠性值确定单元）102-06进行。在工作区电脑101中，D值例如用于可靠性描述数据的验证，每次变更可靠性描述数据时进行计算。另外，在运行时电脑102中，例如，用于监视基于可靠性描述数据进行动作的对象系统，在对象系统的动作中实时地计算。

图10中示出了计测和评价由可靠性描述数据表现出的系统可靠性价值的方法。在可靠性维持系统100中存在多个可靠性描述数据。顶级节点能够定义为对特定特性的可靠性价值。例如，考虑到失去图5中的“WEB服务继续”（202-01）时陷入困窘的资产（asset），因此，在本实施方式中定义为“可靠性的价值”，称为D值（评价值）”。

顶级节点分解为多个副节点，因此，能够构成各边沿（链接）为要素多维矢量（图10（a））。此时，也能够在边沿附加分量。如果以图5为例，例如，使节点202-05比节点202-04更为重要的情况下，也能够使202-01与202-05的边沿间重叠大于202-01202-04的边沿。另外，也能够将某一节点的副节点数作为分量。也可知认为副节点多时充分研讨对策。这样能够将所加权的边沿的多维矢量值设为D值。当维数多时，难以处理多维矢量，因此，也能够使用主成分析法、费舍尔判别分析法等来进行维数削减。另外，将设计时的证据作为教师数据来学习，也能够将基于后述监测节点的变化作为偏离值，通过例如马哈拉诺比斯（马氏）距离计算来检测，由此用于异常发生检测。

这样一来，获得了对曲线图结构加权边沿重要性后的评价值。在此获得的D值作为多维矢量值，但是，不用说也能够利用基于目的任意变换方法将所述D值变换为标量值。

另外，图10（b）是在该特性中将有效证据/总证据作为D值的例子。在图5中总证据数为8，例如，其中有效数为4时D值是4/8=0.5。

另外，图10（c）是将监测节点组中的监测节点的监视点获得的数据按色彩分为处于变动容许范围内的节点和该变动容许范围外的节点，并将该曲线图结构其本身作为D值的例子。此外，关于其详情见后述。

这样一来，获得了基于证据状态的评价值。证据随着要求变更而发生变化，因此，在此获得的D值也随着要求变更而发生变化。即，通过确认D值，能够评价要求变更对可靠性的影响。

另外，也能够使用非专利文献5的方法。在该文献中，在图11记载的项目中再构建D-Case描述。如图11所示，通过在“阶段（Phase）”、“目的”、“靶”、“异常”种类的4层中再配置D-Case节点，能够将边沿的分量在各层作为具有一贯性的值来处理，也能够在各层比较D值。

在此，系统中求出的可靠性要件基于其系统的目的而不同。另外，在系统生命周期的各阶段下，需要使用于利益相关方间相互协定的作业顺利实施，因此，需要定量地表现可靠性要件、其实现进展。因此，如上述那样，将可靠性作为D值而定量表现，由此实现能够用于讨论的指标（可靠性度量）。

如上述那样，通过使用D值，系统开发者考虑了其系统中支持特定可靠性的相关分量，能够使要求其本身参数或要求的实现程度定量化。另外，在运用系统时，在其系统发生故障的情况下，能够实时地将此时点可满足的可靠性定量化。即，将基于基准标记及验证获得的证据组合为D值，能够评价可靠性描述数据。另外，从动作中系统实时地获得D值，能够判断出系统的状况。

在此，使用图12，对运行时电脑102中的监视部102-03的D值计算部102-06的一实施例进行说明。为了在该运行时电脑102中将D值基于利益相关方协定来施行时进行计算，在利益相关方间相互协定的基础上将描述了何时如何监视对象系统内部的任一功能的D-Case监测节点导入到图8所示的D-Case中（图12）。能够将表明该目标满足的证据的节点与表现D-Case描述中目标的节点相关联。能够构成为，在相当于此时证据的节点中收集来自对象系统内部监视点的数据，判断该数据是否纳入变动容许范围内。

所谓变动容许范围是表示将从监视点获得的数据作为基准值并基于该基准值的范围。例如，在网络带域的情况下，能够定义为若处于1Mbps～2Mbps范围内则可视为通常动作的范围。如果是应用程序的存储器消耗，则能够定义为若是100MB以内的消耗则可视为通常动作的范围。此外，该变动容许范围是基于利益相关方的协定来设定。

在图12中，监测节点220-03对目标220-01进行链接，监测节点220-04对目标220-02进行链接。意味着监测节点220-04获取来自施行环境220-07中的监视点1（220-05）的数据，该数据处于变动容许范围某一时满足目标220-02。另外，意味着监测节点220-03获取从施行环境220-07中的监视点2（220-06）传来的数据，在该数据处于变动容许范围内的某一时刻满足了目标220-03。

在此，监视点1（220-05）获得的数据从应用程序220-10内部的监视对象传感器220-08获取数据。例如，在该传感器中，作为该应用程序消耗的存储量，或者该应用程序与外部通信的迟延或带域宽度。另一方面，监视点2（220-06）获得的数据从应用程序220-10内部的开始对象日志220-09来获取。一般，为了对象系统的监视对象从日志开始进入变动容许范围内，判断需要详查日志内部。因此，在本实施例中作为一个例子，构成为判断导入脚本，详查日志，监视点对象处于变动容许范围。此外，该脚本也基于利益相关方的协定。

作为本发明一实施例也能够构成为，通过电子签名表现利益相关方间的该协定，施行时进行确认。图13中示出其一个例子。如图13所示可记述图12中的D-Case描述的概略，在此，表示三个电子签名的有效范围。范围211-01是针对整体的电子签名，范围221-02是对一组目标和监测节点的电子签名，范围221-03是对一组目标、监测节点和脚本的电子签名。

所述电子签名能够构成为确定其有效期限。例如，只是在开发时将有效电子签名附加到D-Case描述中，也能够在依据状况的期间将有效电子签名附加到D-Case描述中。由此，能够提高利用监测节点的数据获得的可靠性，并更可靠地进行作为证据的利用。

另外，在有电子签名的D-Case描述与无电子签名的D-Case描述混杂着的环境中，能够构成为在处理无电子签名的D-Case描述的情况下确定默认动作。通常，默认动作应进行与电子签名无效情况同样的驳回处理。但是，也能够构成为，根据状况向操作员或用户的要求来确认。

在所述D-Case监测节点上获得的数据也能够用于D值计算。图10（c）示出了一个例子。在本实施例中能够构成为D-Case描述存在于每个模块中。该D-Case描述其本身为本结构，作为其一部分的D-Case监测节点也构成树形结构，整个对象系统的D-Case监测节点结构能够使用图10（c）的那样的一般化曲线图结构来构成。在此，也能够构成为评价节点间的距离。各节点组间的直接链接与节点间有多个链接的结构相比，能够使前者的评价值更大。另外，也能够将该监测节点组中的监测节点上的监视点所获得的数据按色彩分为变动容许范围内的节点与该变动容许范围外的节点，并将该曲线图结构其本身参数构成为D值。在该按色彩分类时，也能够在变动容许范围内定义深刻度（Sevirity）。例如，在硬盘残存容量的相关变动容许范围内的情况下，优选为残存容量50%和残存容量10%赋予不同的深刻度。在该曲线图结构中反映了模块间的依存关系，因此，能够将曲线图结构设为D值，并将考虑到该依存关系的D值作为可靠性价值来处理。

进而，如图14所示，除了边沿的目标组（220-04至222-07）以外，在中途的目标组（222-01至222-03）中也能够链接所述监测节点（223-01至223-03）。与某一目标链接的监测节点与链接于该目标副节点组上的监测节点组之间的关系相当于所对应的监视点组的关系。例如，能够构成为，目标2（222-02）为“商品购置站点的服务继续”的情况下，将其次级目标分割为二个，目标4（222-04）为“电子决算系统继续”，目标5（222-05）为“商品DB继续”。对该目标组链接了以下的各个监测节点。监测节点2（223-02）目标2（222-02）链接，例如，通过由脚本施行整体的服务继续脚本，确认满足了该目标2。监测节点4（223-04）与目标4（222-04）相链接，例如，确认脚本电子决算系统无异常，而确认满足了该目标4。监测节点5（223-05）与目标5（222-05）相链接，例如，从商品DB中所具备的活力传感器中接收数据，确认是否已满足了该目标5。

另外，也能够如下那样地构成。例如，也能够构成为，在目标3（222-03）为“商品候选显示系统继续”的情况下，将其次级目标分割为二个，目标5（222-05）为“在规定值存取数以下时的正常动作”，目标6（222-06）为“在规定值迟延以内的正常动作”。将各个次的监测节点链接到该目标组上。监测节点6（223-06）与目标6（222-06）相链接，例如，通过确认利用脚本以规定值存取数以下进行正常动作，可确认满足该目标6。监测节点7（223-07）与目标7（222-07）相链接，例如，通过确认获取安装于对象系统的WEB服务器中的传感器的数据经规定值以下的迟延进行正常动作，可确认满足了目标7。在该情况下，与目标3（222-03）链接的监测节点3（223-03）能够构成为，通过确认同时满足作为次级目标的该目标6和该目标7，可确认满足该目标3。如上所述，通过由曲线图结构构成监测节点组，计算曲线图结构获取所述D值，能够判断系统的状况。

此外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101、运行时电脑102），在潜在性地存在不完备性和不可靠性的开放环境中的系统开发以及系统运用中，进而以持续地维持系统所提供的服务中的可靠性为目的，并且以解决因利益相关方间对要求的误解、因环境变化所产生的无法应对、障碍处理失败这三个问题为目的，在具有有关可靠性的时间轴上可变化的某一时刻的可靠性描述数据（作为数据结构，例如树形结构模型）系统中，能够计算该可靠性描述数据，也能够由此计测和评价该可靠性描述数据所表现出的系统可靠性价值。

这样，所述可靠性维持装置在具有与可靠性相关且时间轴上可变化的某一时刻的可靠性描述数据的系统中，能够计测和评价可靠性的价值。因此，起到了能够解决利益相关方间对要求的误解、因环境变化造成的无法应对、障碍处理失败这三个问题来维持可靠性的效果。

另外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101、运行时电脑102）是用于维持对象系统可靠性的可靠性维持装置，也能够构成为具有：用于获取描述了对象系统可靠性相关规格的可靠性描述数据的描述数据获取单元（可靠性描述数据输入部901-01、软件输入部902-01）；以及基于所述描述数据获取单元所获得的可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值（D值）的可靠性值确定单元（D值计算部101-05、D值计算部102-06）。

由此，能够定量地表现出对象系统可靠性价值。因此，例如，在随着要求的变更来变更可靠性描述数据时，或者在运用对象系统时确认对象系统的状态时，能够易于了解对象系统可靠性价值，并将其客观性提示。因此，能够顺利进行对象系统的可靠性的维持。

进而，本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101、运行时电脑102）也能够构成为，所述可靠性描述数据是具有能够加权到节点间边沿上的树形结构或曲线图结构的数据，所述可靠性值确定单元（D值计算部101-05、D值计算部102-06）将以加权到所述边沿上的分量作为要素的多维矢量值作为所述评价值（D值）。

由此，在树形结构或曲线图结构中，获得了加上边沿重要性的评价值。因此，通过确认评价值，能够评价加权于边沿上的分量变更对可靠性的影响。此外，在此获得的评价值为多维矢量值，但这也不过是能够利用基于目的任何变换方法变换到标量值。

进而，本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101、运行时电脑102）构成为，所述可靠性值确定单元（D值计算部101-05、D值计算部102-06）也能够，将与包含所述可靠性描述数据中的作为证据总数的总证据数相比的，以监测所述对象系统而获得的监测值作为对变动容许范围良好的证据数即有效证据数之间的比值作为所述评价值（D值）来进行计算。

由此，获得了基于证据状态的评价值。证据基于要求变更而变化，在此获得的评价值也随着要求变更而变化。即，通过确认评价值，能够评价要求变更对可靠性造成的影响。

进而，本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101、运行时电脑102）也能够将所述可靠性描述数据作为曲线图结构来评价，所述可靠性值确定单元（D值计算部101-05、D值计算部102-06）计算出该曲线图结构，例如，将节点间距离或深刻度代入计算式中算出评价值（D值）。

由此，获得了基于通过监测节点组获得的数据的评价值。监测节点组基于对象系统施行时的状况而发生变化，因此，在此获得的评价值也基于该施行状况而变化。即，通过确认该评价值，能够评价施行状况对可靠性造成的影响。

另外，也能够构成为，本发明的可靠性维持系统100是用于维持对象系统可靠性的可靠性维持系统，其包括：工作区装置（工作区电脑101），其在所述对象系统开发时或更新时，施行使所述可靠性描述数据对应于规格变更而变更的变化应对循环P300；运行时间装置（运行时电脑102），在运用所述对象系统的情况下，在检测了障碍发生或障碍预兆时，基于所述可靠性描述数据，施行避免所述对象系统停止运行的障碍处理循环P301，所述工作区装置和所述运行时间装置中至少任一者基于所述可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值（D值）。

进而，本发明的可靠性维持系统100也能够经由网络与其他可靠性维持系统100连接起来。即，本发明的可靠性维持系统100也能够为多个，并经由网络连接起来。

〔3．二个工序〕

使用图15，说明可靠性维持系统100具有迭代工序，而且，使用图16，说明用于实现该迭代工序的体系结构。

开放系统可靠性、即，为了实现针对功能、结构、系统边界与时间一同连续变化的系统的可靠性，必须进行作为迭代工序的接近。该迭代工序需要包括：用于对应于目的（Objectives）、环境的变化而继续变更系统的循环（变化应对循环P300）；以及用于迅速应对障碍的循环（障碍处理循环P301）。该迭代工序是，作为构成要素包括管理工序250-01、开发工序250-02、通常运用工序S302、障碍处理循环250-04、履行说明责任工序250-05等的“工序流程（Process of Processes）”。该构成要素工序需要相互有机地结合起来。在本实施方式中，将该迭代工序称为DEOS工序。

在DEOS工序中，将对象系统可靠性的相关利害相关者称为“利益相关方”。作为利益相关方，假定有以下的各方。1）服务和产品的用户（用户；在社会基础架构的场合指整个社会），2）服务和产品的提供者（企业主），3）系统提供者（设计开发者、维护运用者、硬件供给者），4）服务和产品认可者（限制监督官厅）。

也存在着利益相关方随着时间经过或环境变化而改变各个目的，且改变对功能、服务的要求的可能性。这些变化在此称为“目的和环境变化”呼。对于这些变化，该利益相关方经深思熟虑而相互协定后，在适当时期要求系统变更。DEOS工序具有作为针对这样要求的循环的“变化应对循环”（P300）。

对象系统极其难以完全避免因不完备性和不可靠性为起因造成的障碍。在检测出障碍预兆的情况下能将障碍防范于未然，在不幸发生了障碍的情况下需要迅速处理使被害最小化，并究查其原因，履行说明责任。为了在DEOS工序中适应那样的状况而具有“障碍处理循环”（P301）。

在重新开发系统，并适应目的和环境的变化而进行系统变更的情况下，其用于详细记录其理由或利益相关方间的讨论工序、协定内容等的协定描述数据库250-06，由此实现了有效的所述迭代工序，为了履行说明责任这些都是必须的。在该数据库中包括：用于达到可靠性的讨论或描述了依据的所述D-Case；用于对障碍继续服务的脚本为基础而用于描述了检测障碍预兆或迅速应对障碍发生的施行手续的脚本（其详情见后述且在图中记载为D-Script）。并且，基于这些协定描述，施行了开发工序250-02、障碍处理循环250-04、通常运用工序S302，而且能够支持履行说明责任工序50-05。协定描述数据库250-06起到有机联系所述构成要素工序的重要作用。

汇总了所述DEOS工序的特征：1）由从“通常运用”（S302）开始的“变化应对循环（P300）”和“障碍处理循环（P301）”两个循环组成。2）将用于系统变更要求的“利益相关方协定”（250-07）和系统变更或障碍处理的“履行说明责任”（250-05）两个阶段编入。3）经利益相关方间调整利害关系，具有协定描述数据库250-06，所述描述数据库250-06包含而描述了用于达到可靠性而进行讨论的工序、论据和结果等的所述“D-Case”与障碍迅速与相对应的用于的施行手续描述“脚本”在内，并将构成要素工序有机地结合起来。

在图15中，通常运用S302表示可靠性维持系统100处于通常运用状态。在该通常运用S302中，系统不会与经利益相关方间协定的服务水平变动容许范围（In-Operation Range）大幅度地背离，处于继续向用户提供服务的状态下。优选为变化应对循环P300与通常运用并行施行，继续提供服务的同时进行系统变更。同样，优选为障碍处理循环P301也一边继续通常运用而一边施行。实际上，即使系统检测出异常预兆，也存在着记载于该脚本中的服务和功能水平变动容许范围内自动开始避免处理并继续服务的情况。或者还存在着简并一部分功能而继续服务的情况。但是，也有完全停止提供服务的情况。

在经通常运用状态S302施行的工序中，包括：日常的动作记录检查；工序的定期更正、改善；要员的训练、培养、教育等；以及可靠性持续提高活动。记录了系统的运转状况，通过日常检查，维护担当者或运用担当者有可能从哪儿观察出何种征候。另外，系统的存储器资源始终处于清理状态，这也是非始终有效的日常维护和改善活动。或者，积极进行预运行也是有效。障碍是经过某一时间到达某一状态时发生的。这样一来，事先能够知晓最先经过一段时间时将会发生障碍。这就是所谓试运行（Rehearsal），在信息系统所提供的服务运用时，能够进行怎样程序的适当试运行是基于当时的状况。

以下，对障碍处理循环P301进行概述。障碍处理循环P301是用于对障碍迅速进行处理以将障碍造成的损害程度控制在最小的循环。在DEOS工序中，将“障碍”定义为发生了超出了经利益相关方间协定的服务和功能水平变动容许范围的事件。障碍处理循环中的主要阶段（Phase）为“防范未然”（250-10），“迅速应对”（250-09）、“查明原因”（250-08），在发生了障碍的情况下，必须“履行说明责任”。该三个阶段并不限定个别施行与否以及顺序。在多阶段的情况下，这些阶段相互关联且成为浑然一体的事件和活动。

在防范未然阶段250-10中，在系统运用中发生障碍前预知障碍的发生时，或者检测出障碍发生可能性增大时，实施应对动作以避免障碍发生的阶段。如果障碍的预知是充分在障碍发生预想时刻之前，则可制定出有效的对策。例如，限制系统资源，降低处理能力，避免系统停机，或者系统停机之前赢得时间。在障碍发生前已经预知的情况下努力使障碍影响最小化。另外，能够存储对原因分析有效且发生障碍前的系统内部信息。作为用于预知的具体方法，有从过去的障碍模式中判别类似的障碍等。事先将防范未然脚本作为脚本来描述，在与操作员或系统管理者协调下施行防范未然动作。

迅速应对阶段250-09是发生了障碍时用于使其影响最小化的阶段。事先将对障碍迅速应对的脚本作为脚本来描述，优选为自动实施。但是，也存在必须应对未假定的障碍的场面。要求事先制定了用于使基于每个对应领域或区域的目的服务继续的紧急应对计划（记载了负责人、应对组织、步骤和上报路径等），且利益相关方间预先协定好。基于该计划的指示，与操作员或系统管理者协调好，迅速使障碍造成的影响最小化。即，将障碍分离开以进行影响的本地化，避免整个服务瘫痪。为此，中断了障碍发生后的应用程序或系统的一部分操作，进行重置，其后由操作员或系统管理者进行复原活动。

查明原因阶段250-08是有关障碍处理循环P301及变化应对循环P300的阶段。通过循环，进行深度的不同判断。在障碍处理循环P301中，查明原因以达到能够搞清如何迅速地应对的目的。根据其结果，开始变化应对循环P300。

在履行说明责任阶段250-05中，服务提供者、特别是社会基础架构服务提供者或供社会上广泛使用的产品提供者，发生障碍时，对服务用户、产品使用者以及社会，说明了障碍状况、迅速应对以及今后的打算等。这样维持了来自用户或社会的信赖，在提供基础架构服务方面达成共识，甚至具有维护着服务提供者开展业务上的便利的非常重要作用。协定的描述数据库特别是D-Case描述和系统的监视记录对履行说明责任起到很大的作用。

以下，对变化应对循环P300进行概述。变化应对循环P300是用于适应利益相关方目标变化、各种外部环境变化的循环。该循环中的主要阶段分别为用于系统变更的 “要求提取和风险分析”（250-11）、“利益相关方协定”（250-07）以及“设计、安装、验证和测试”（250-02）。在适应大变化的情况下必须“履行说明责任”（250-05）。障碍处理循环P301中的查明原因阶段250-08施行的结果为，在产生对系统的根本性改良的要求的情况下，也开始了变化应对循环P300。

要求提取和风险分析阶段250-11在隔着目的或环境的变化而来自利益相关方的要求发生了变化（也包含新增要求）的情况下，或者在迅速处置障碍的发生之后，进行原因的查明，结果为开始出现需要变更系统的情况。在任何情况下，也以企业老板的服务目的为基础，考虑到用户要求系统环境和相关的法律及国际标准，提取出系统的功能要件。另外，同时，根据服务目的制作系统的服务继续脚本，进行风险分析，提取包括可靠性要件在内的非功能要件。

在利益相关方协定阶段250-07中，描述了将什么如何变更等令所有利益相关方易于理解不会误解的事项，经过利益相关方间的讨论，将协定描述为D-Case。另外，制作服务继续脚本，并制作作为其施行手续的脚本。要求提取和风险分析阶段250-11该利益相关方协定阶段250-07构成了“要求管理工序”（250-01）。

设计、实证、验证和测试阶段250-02是所谓设计开发的工序。在此，至今出现了多种研究、多种方法和工具。

在履行说明责任阶段250-05中，在为了满足基于目的或环境变化的利益相关方要求变化来变更系统的情况下，说明了其原由以及怎样服务或功能何时开始变好（变化与否）。另外，需要对日常的服务履行状况或设计开发和维护运用工序进行相关说明时也与此相适应。这样维持了来自用户或社会的信赖，在提供基础架构服务方面达成共识，甚至具有维护着服务提供者开展业务上的便利的非常重要作用。协定描述数据库250-06中所存储的特别是D-Case描述对履行说明责任起到很大的作用。

〔4．DEOS体系结构〕

所述DEOS工序提供了用于实现针对广范开放系统的可靠性的迭代工序。在将该工序更具体地应用程序到作为对象的系统的情况下，需要考虑用于对每个对象范畴进行工序施行的体系结构。在本实施例中，叙述了考虑到对包括嵌入式系统在内的现代大规模且复杂的软件系统的适应而创建的体系结构（称为DEOS体系结构）。当并列观察所述DEOS工序与该DEOS体系结构时，能够理解DEOS工序以实际系统进行如何施行。

使用图16，对该DEOS体系结构进行说明。该体系结构由以下的结构要素构成。1）用于支持要求提取和风险分析阶段的工具组260-01（101-05）；2）用于支持利益相关方协定阶段的协定形成支持工具组260-02（101-05）；3）包括作为协定描述的D-Case和作为服务继续脚本施行手续的脚本（在图中记载为D-Script）在内的协定描述数据库250-06；4）DEOS施行环境260-03；5）程序验证工具和用于基准标记以及故障注入（Fault injection）测试的工具组包括DEOS开发支持工具260-04。

要求提取和风险分析阶段250-11基于企业老板的服务目的260-05来考虑到用户的要求，系统环境以及相关的法律和国际标准，提取系统的功能要件，制作对所假定的障碍继续服务的脚本，并进行风险分析，提取包括可靠性要件在内的非功能要件。

利益相关方协定阶段250-07基于用于形成协定的方法和协定描述的记法将协定内容描述为D-Case。如此运用的工具为D-CaseEditor（260-06）和D-CaseViewer（260-07）。另外，也制作了基于服务继续脚本的施行手续脚本260-08。该脚本在DEOS体系结构中起到将D-Case描述与应用程序施行动态地结合起来的作用。在该脚本中写入有由后述脚本引擎（在图中记载为D-Script Engine）施行的脚本。其脚本对DEOS施行环境260-03，1）指示其何时收集怎样的日志信息，而且，2）指示在障碍发生时如何处置障碍。此时，也存在按照逐步升级规则指示操作员介入的情况。这样，通过该脚本动态且双向地更换信息来灵活地控制应用程序的施行，有助于开放实现系统的可靠性。

DEOS施行环境260-03是用于提供基于利益相关方协定实现可靠性的服务的施行环境，其由如下的副系统构成。D-Visor为了对象系统的再构建，而提供保证系统结构要素的各自独立性的构架（System Container）。担负起对某一System Container内的异常或障碍造成其他System Container影响的抑制作用。D-Application Manager提供了用于保证多个应用程序的独立性的构架（Application Container），并管理控制各应用程序的生命周期（生成、启动、更新、停止和删除）。D-ApplicationMonitor提供了应用程序动作监视功能，按照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开发支持工具260-04是一种开发支持工具组，其根据基于事业目的或事业继续脚本而确定的功能规格、测试规格、基准标记脚本乃至日志规格，用于设计、开发和验证程序，进行基准标记，并进行测试。例如，存在有基于模型理论和模型验证的软件验证工具；以及具有基准标记以及故障注入功能的可靠性测试支持工具等。

通过运用所述DEOS工序可享受的最大优点在于，能够对利益相关方间要求的变化进行充分协定讨论，能够将协定结果乃至其结论的理由以及讨论原由存储于D-Case中。在系统开发时，通过使用D-Case描述，而与所述DEOS体系结构协作，能够设计出在发生障碍时可获得适当和迅速的应处置理的系统。另外，利用D-Case描述的具有，更容易查明障碍原因和履行说明责任。

所述DEOS工序的另一个优点在于，适当提取要求，对风险充分研讨，随后施行系统变更。各自利益相关方在任何时候也能够以各自观点来了解系统的状态。由此能够简洁且强力地管理运用系统。另一方面，要求数量膨大起来。D-Case Editor（260-06）或D-Case Viewer（260-07）等工具减轻了要求管理方面作业。

用于使所述DEOS体系结构具体化的DEOS施行环境260-03具有监测功能，以D-Case为基础，对分析所需的系统和应用程序的施行状态实行监视和记录。该施行环境按照该监视记录和脚本来施行发生障碍时的迅速应对。另外，将从D-Case描述和监视记录中获得的信息作为证据来履行原因分析和说明的责任。脚本和脚本引擎起到D-Case与该施行环境之间的桥渡作用，利用该构架，系统能够自动或者根据需要经由操作员进行（基于D-Case描述）灵活处理。

另外，所述DEOS-体系结构，提供了用于隔离某一模块中的障碍向其他模块传导的功能。同样，为了维护系统安全性而也提供了检测来自外部的侵入的功能。另外，为了达到可靠性的目的，也提供了用于在施行前验证程序的工具、用于计测性能的工具、以及用于测试在嵌入故障而发生异常时的举动的开发工具等。

利用所述的构架和功能，所述DEOS工序和所述DEOS体系结构具有用避免继续发生障碍的能力，障碍时适当且迅速进行应对，将其影响控制在最小限度度。另外，能够继续服务，履行说明责任。所述DEOS工序与所述DEOS体系结构进行最初的配合，以便达到开放系统的可靠性。

〔5．施行（运行时间）环境〕

以下，使用图17，说明本发明中的一实施例中的构成所述DEOS工序的变化应对循环P300和障碍处理循环P301的一系列步骤。该两循环通常均处于通常运用S302的状态。

在变化应对循环P300中，当发生了随着商务环境变化等环境的变化而变更利益相关方要求、变更开发中途的要求和/或变更运用系统时的要求时，变化应对循环P300转移到环境变化S300-01的状态。

首先，要求变更S300-02使用了工作区电脑101（参照图1）的分析工具部101-03来进行。在此，提取来自利益相关方的要求后，分析该要求变更对运行时电脑102造成的影响，或是分析具体的变更单元，或是分析变更处。

接着，可靠性描述数据的变更S300-03是使用了编辑工具部101-02和/或开发工具部101-04，基于要求变更S300-02中的分析结果来进行。在此，将其结果反映给软件SW。

接着，在证据计测S300-04中，使用验证工具部101-01确认是否按要求进行了变更。

最后，利用调配S300-05将软件SW导入到运行时电脑102中。其后，变化应对循环P300变为通常运用S302。

另外，在障碍处理循环P301中，在运行时电脑102（参照图1）中发生了障碍的情况下，转移到障碍发生S301-01的状态。首先，在对策提取S301-03中不停止运行时电脑102，提取了应对该障碍的处置对策。

接着，通过经紧急对策S301-04施行该对策，继续进行基于运行时电脑102中的模型的处理。

接着，在记录S301-05中由记录部102-02记录该紧急对策。在此，也由记录部102-02记录了与该障碍相关的信息。优选为在此时使运行时电脑102继续运行，也存在因障碍而导致该对策也无法继续施行的情况。在可继续或无法继续运行的情况下也进行原因查明S301-06。由此，查明该障碍的原因，以及在运行时电脑102不继续进行基于模型的处理的情况下，查明其原因。根据其结果，使不伴随着要求变更的变化应对循环P300转移到环境变化S300-01的状态。

另一方面，在障碍处理循环P301中发现了故障（或故障预兆）的情况下，或者发现了障碍预兆的情况下，转移到障碍预兆S301-02的状态。故障（或故障预兆）的发现由运行时电脑102的监视部102-03来实施。障碍预兆的发现也由该监视部102-03来实施。具体而言，能够查清运行时电脑102的二进制施行部110中的各种计算资源的消耗经历工序。例如，存储器的残存量在一定时间内连续减少的情况下，可知不久的将来会造成存储器不足而停止计算。

首先，在对策提取S301-03中，不停止运行时电脑102中的处理，提取了用于应对所述故障（或故障的预兆）发生或者障碍预兆的对策。

接着，经紧急对策S301-04施行该对策，由此使运行时电脑102继续动作。

其次，在记录S301-05中由记录部102-02记录了该紧急对策。在此，与该障碍相关的信息也由记录部102-02记录。优选此时继续进行基于运行时电脑102中的模型的处理，但是，也存在因障碍造成无法继续施行该对策的情况。在继续施行或不继续施行任一种情况下，也进行原因查明S301-06。由此，查明所述障碍的原因，以及在不继续实施基于运行时电脑102中的模型的处理的情况下查明其原因。根据其结果，使不伴随要求变更变化应对循环P300转移到环境变化S300-01的状态。

此外，如上所述，同时存在所述变化应对循环P300和障碍处理循环P301。

此外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（可靠性维持系统100），在具有所述可靠性描述数据的系统中，也能够同时具有以下的两种手段：用于分别应对以环境变化为起因造成利益相关方的要求变更、系统开发中途的要求变更和/或系统运用时的要求变更的工序（process）；以及在障碍发生时也继续处理运用系统时的系统所提供的服务，和/或为了使系统运用时的系统所提供的服务不停止，检测障碍预兆以将障碍发生防范于未然的工序。

这样，所述可靠性维持装置，在潜在性地具有不完备性和不可靠性的开放环境中，具有以下的两种手段：用于分别应对以环境变化为起因造成利益相关方的要求变更、系统开发中途的要求变更和/或系统运用时的要求变更的工序；以及在障碍发生时也继续处理运用系统时的系统所提供的服务，和/或为了使系统运用时的系统所提供的服务不停止，检测障碍预兆以将障碍发生防范于未然的工序，由此，没有现有的开发阶段和运用阶段的壁障，能够实现利益相关方的问责（Accountability），并且起到能够持可靠性维的效果。

另外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101、运行时电脑102）能够构成为施行以下两种处理循环中任一者，即，在所述对象系统开发时或更新时，实行与规格变更对应地变更所述可靠性描述数据的变化应对循环P300；以及，在运用所述对象系统时，检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，实行避免所述对象系统停止的障碍处理循环P301。

在障碍处理循环P301中，基于转移到障碍发生S300-01状态的一系列步骤相当于控制工学中的反馈处理，基于转移到障碍预兆S300-02的状态的一系列步骤相当于控制工学中的进给前进处理。因此，也能够构成为通过学习该反馈处理的结果，构建应对模型，有益于该进给前进处理。另外，也能够构成为可将此时的该模型记录为对可靠性描述数据的变更。另外，也能够构成为在该进给前进处理中，将其他系统中的应对模型描述到所述可靠性描述数据中，在经利益相关方协定的状态下，对与该模型相对应的障碍预兆实行主动避免处理。

为了在开放环境中继续维持对象系统的可靠性，需要同时实施以下的两个处理循环，即，与要求变化或环境变化相对应地进行充分研讨处置的变化应对循环P300；以及迅速应对运用中障碍发生的障碍处理循环P301。

因此，通过如上所述地构成为，在变化应对循环P300和障碍处理循环P301至少任一者中，能够求出表示对象系统可靠性价值的评价值。因此，例如，在变化应对循环P300中，随着要求的变更而变更可靠性描述数据时，基于评价值，能够判断出可靠性描述数据的变更方案是否合适。另外，例如，在障碍处理循环P301中，能够在运用对象系统时基于评价值来判断对象系统的状态。因此，能够顺利进行对象系统可靠性的维持。

〔6．变化应对循环〕

图18图示出了在图17所示的工作区电脑101中作业的变化应对循环P300中的、经利益相关方间协定的形成处理S400、要求变更的安装处理S401、问责处理S402这三个步骤。

利益相关方间的协定形成处理S400与要求变更S300-02和可靠性描述数据变更S300-03有关系。利益相关方间的协定形成处理S400从理解要求变更内容的步骤（要求变更的理解S400-01）开始。这样，例如，分析了以“IEEE Std 830-1998 IEEE Recommended Practice for Software Requirements Specification”为准据的SRS（软件内部说明书）。

接着，在影响分析S400-02列举了对已有的可靠性描述数据相的变更点。

最后，在可靠性描述数据的变更S400-03中将该变更点作为该可靠性描述数据的变更来反映。

重复这些步骤，直到利益相关方间达成协定S400-04。

另外，要求变更的安装处理S401与可靠性描述数据变更S300-03和证据计测S300-04有关系。要求变更的安装处理S401从设计S401-01步骤开始。在设计S401-01中，用于利用开发工具部101-04将要求变更变换为实际代码的软件设计，按照例如能力成熟度模型集成（Capability Maturity Model Integration，CMMI）进行。

接着，在安装S401-02中，利用开发工具部101-04将设计S401-01中的设计变换为软件SW。

其次，在测试S401-03中，使用验证工具部101-01测试和验证所有步骤中的软件SW。

重复这些步骤直到测试S401-03中的验证全部OK。当验证完全OK时，以导入S401-04将该软件SW导入到运行时电脑102中。

另外，问责处理S402与证据计测S300-04和调配S300-05有关系。问责S402，=从基准标记等收集S402-01的步骤开始。基准标记也能够由运行时电脑102施行和计测，还能够在模拟运行时电脑102的环境上进行施行和计测。

接着，验证所收集的基准标记数据是否满足要求（证据验证S402-02）。

最后，利益相关方根据需要将该验证的数据作为证据而进行信息公开（信息公开S402-03）。此外，通过信息公开S402-03，利益相关方能够达成问责（S402-04）。

此外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（工作区电脑101），用于分别应对因所述环境变化为起因造成利益相关方的要求变更、系统开发中途的要求变更和/或系统运用时的要求变更的工序（process）中，以及在将这些要求作为输入，而形成了由并将发生该要求变更作为起点的一系列步骤构成的循环操作的该工序中，也能够施行如下的三个步骤：为了可靠地加入该要求变更，进行系统运用，并能够提供服务，而在利益相关方间形成要求变更协定的步骤；加入该要求变更，并进行验证以及系统运用的步骤；以及通过基于该要求变更的系统运用和服务提供，实现利益相关方问责的步骤。

〔7．障碍处理循环（迅速应对）〕

图19是表示障碍处理循环P301中检测障碍发生时的两个处理的流程图。此外，图19中的障碍处理循环P301是图17的再次组合。

障碍发生S301-01由监视部（障碍发生检测单元）102-03检测到障碍发生时，转移到该状态。监视部102-03例如在D值比预定的变动容许范围更恶化时，检测障碍的发生。检测障碍发生时的障碍处理循环P301与两个功能有关系，即，系统再构建处理S502和问责处理S503。

系统再构建处理S502与对策提取S301-03和紧急对策S301-04有关系。系统再构建处理S502从服务继续判断S502-01开始。在此，提取了适于障碍的一部分可靠性描述数据。在能够从该可靠性描述数据中提取系统再构建脚本的情况下（S502-01YES），进入如下的步骤。此外，在无法从可靠性描述数据中提取系统再构建脚本的情况下（S502-01NO），判断为无法继续，并施行可靠性描述数据的变更提取处理S800（图27）。

系统再构建脚本也能够在系统设计时预先编入典型的事例。例如，用于重启后述应用程序容器（container）或系统容器脚本为其一个例子。另外，也能够将该再构建脚本同样如下所述在可靠性描述数据中的节点中与能够施行的程序相关联起来。即使在任意方法中，也在该再构建脚本无法提取的情况下，为了变更可靠性描述数据，准备施行变化应对循环P300。另外，也能够将该再构建脚本作为后述的脚本来描述，与可靠性描述数据相关联起来。

接着，在障碍部位隔离S502-02中，依照该提取的脚本来隔离障碍部位，将可靠性描述数据的不同反映给运行时电脑102，进入到下一个步骤。

接着，在服务继续S502-03中，基于该脚本而隔离的部位处的代替功能由该脚本来启动，继续服务（S502-04）。

另一方面，问责处理S503与记录S301-05和原因查明S301-06关系。从问责处理S503记录了与障碍有关的日志（S503-01）开始着手。

接着，依据所述脚本收集再构建的运行时电脑102的证据（S503-02）。在此所谓证据是指利用系统的再构建由运行时电脑102依据可靠性描述数据而 适当动作的相关记录。

接着，进入障碍原因检测S503-03。在此，汇总了与障碍有关的所述日志（S503-01）、所述证据（S503-02）以及与所述障碍有关的可靠性描述数据。在本实施方式中，将该汇总数据用作实现对利益相关方的问责。此外。也能够并行处理这些步骤（S503-01以及S503-02）。

在图20中示出了监视部102-03施行障碍发生检测处理的一个例子。

图20（a）示出了可靠性描述数据的一部分（510）。在制作可靠性描述数据时，预先对施行时状况有变化的数据标明利用监测节点施行时需要监测。

节点（510-01）涉及“正常DBS的HDD存取”。该节点分支为二个、即，数据库系统将向HDD装置正常存取的状态按二个节点分开（Breakdown），并描述了其条件。具体而言，节点（510-02）涉及“HDD的残存容量”。另外，节点（510-03）涉及“HDD的传送量”。

在此，在本例子中，导入所述监测节点以作为这些二个节点的证据。在图20（a）中，节点（510-04）和节点（510-05）均为监测节点。节点（510-04）用于监测HDD的残存容量。节点（510-05）监测HDD的传送速度。

可靠性描述数据中的监测节点在能够从外部监控对象系统的情况下，利用具有监视部102-03的监视模块组（后述）来监测对象系统。另一方面，在不能够从外部监控对象系统的情况下，按照将后述程序导入到对象系统中的步骤来送入监视模块，由此进行监测。

并且，将施行时的监测结果与可靠性描述数据的描述比较，在存在超过变动容许范围的差值的情况下，将与设计时的基准不同的动作界定为异常。另外，通过参照可靠性描述数据的上位节点，能够把握因发生综合性异常而无法满足上位节点的可靠性的状况。进而，核查各个系统内部或多个系统间的障碍部位，能够锁定障碍发生部位。

在图20（b）中示出了使用监测节点用于障碍检测的可靠性维持系统100的结构例子。监测节点能够按模式（pattern）来分类。例如，图20（a）的二个监测节点（510-04、510-05）能够采取监测“HDD“＄1”的“＄2”为“＄3””的形式。预先与该监测节点的模式相对应地准备监视模块组，使监测节点的模式与监视模块的对应关系表格化，由此能够监测施行时的状态。

例如，关于图20（a）的二个监测节点（510-04、510-05），能够如图21那样示出对应的关系。在此，图21示出了在“监测了HDD“＄1”的“＄2”为“＄3””这样模式的监测节点的场合，如果＄2为“盘容量”，则利用HDD监视模块作为监视模块，只要指定＄1（=HDD识别号）和＄3（=变动容许范围）作为参数即可。

工作区电脑101的编辑工具部101-02描述了可靠性描述数据M1，进而，变换为作为运行时电脑102中内部表现的可靠性描述数据内部表现M2。详细地说，在工作区电脑101的编辑工具部101-02中，可靠性描述数据描述和显示工具511-01描述了可靠性描述数据M1后，将该数据M1由可靠性描述数据变换部511-03变换为可靠性描述数据内部表现M2。

在运行时电脑102中，更新部102-01将从工作区电脑101获得的可靠性描述数据内部表现M2记录到可靠性描述数据存储部511-05中。另外，更新部102-01基于可靠性描述数据内部表现M2，将监测节点与监视部102-03中的各种监视模块（监视模块组511-m）之间的对应关系记录到监测节点/模块对应表511-06中。此外，在图20（b）记载了CPU监视模块511-08、HDD监视模块511-09和工序监视模块511-10作为监视模块组511-m的各监视模块，但也能够具有其他监视模块511-11。

监视部102-03中的所述监视模块所获得的数据（监测值）由收集部510-13收集，并由施行状况验证部510-12基于监测节点/模块对应表511-06，记录为所述可靠性描述数据中的监测节点的值。例如，将所述监测值的变动容许范围关联地记载到可靠性描述数据的各监测节点，将监测值背离其变动容许范围的节点作为障碍发生节点来检测。另外，在D值计算部102-06中将来自所述监视模块组511-m的监测值应用到相对于节点的D值计算中。因此，例如，在图20（a）的可靠性描述数据的一部分510中，将从二个监测节点（510-04、510-05）获得的监测值与变动容许范围作比较，并且基于此算出D值。

另外，预先准备CPU利用率、存储器使用量和工作程序（process）活力等作为OS功能，能够从外部进行监测，但是，有时也难以从外部监测“系统A内的某一处理X已经正常结束了”。这些主要作为应用程序固有的信息，作为监视模块511-14装入运行时电脑102中。即，在内部没有用于对监控对象监测的监视模块的情况下，如监视模块511-14那样，能够在外部设置有监视模块。该安装也能够在系统构建时进行，还能够在运行时电脑102施行时进行。由此，在施行时的监测结果超过变动容许范围的情况下，能够以可靠性描述数据的节点单位来界定异常。

另外，通过在施行时从各个监视模块收集监测结果（510-04、510-05），能够判断在可靠性描述数据中的哪个监测节点超过变动容许范围。也就是说，能够从可靠性的观点把握问题的发生。即，通过从可靠性描述数据该监测节点到上位侧进行研讨，能够判断在哪个范围内无法维持可靠性。例如，在节点（510-04）和节点（510-05）的监测值均超过变动容许范围那样的状况中，无法维持可靠性的原因存在HDD以外，查清可靠性描述数据的更上位部位。进而，在多个系统相互作用的状况中，如果不仅描述了各个系统相关的可靠性描述数据，而且，还描述了相互作用相关的可靠性描述数据，则能够利用适当监测节点来锁定或界定系统相互间超过变动容许范围的动作部位。

所述监视模块组511-m为预先装于系统中的监视模块组，但是，在运用中安装新的监视模块的情况下，或者在变动容许范围的判断必须考虑来自多个传感器的数据，或者必须分析来自日志的数据的情况下，能够由脚本构成。

以下，使用图22，对脚本的结构概要进行说明。脚本由1以上的基本动作550-01（图中记载为D-Task）和1以上的控制动作550-02（图中记载为D-Control）构成。控制动作550-02施行了适于以深刻度区分变动容许范围的深刻度基本动作（D-Task）。例如，在硬盘存在残存容量的情况下，将50%的残存容量的深刻度设定为“低”，将75%的残存容量的深刻度设定为“中”，并将90%的残存容量的深刻度设定为“高”，能够构成控制动作550-02（D-Control）。在该情况下，在深刻度“高”的情况下施行D-Task1（550-03），在深刻度“中”的情况下施行D-Task2（550-04），在深刻度“低”的情况下施行D-Task3（550-05）。

此外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（运行时电脑102），在具有所述系统运用时的所述可靠性描述数据的系统所提供的服务发生障碍时也进行处置使其继续下去的工序中，在具有检测障碍发生的单元（监测功能）、用于隔离发生障碍的部分的单元（隔离功能）、用于以被隔离后的残余部分继续服务的单元、检测障碍原因的单元（原因追及功能）、以及用于判断所述系统运用时系统所提供服务有否继续性的单元（继续性判断功能）的工序中，在形成由以该障碍发生为起点的一系列步骤构成的闭合循环的该工序中，也能够施行以下的两个处理：为了在该障碍发生时将服务停止时段控制在最小限度，再构建具有所述可靠性描述数据的对象系统的步骤；以及利用经该再构建的系统运用和提供服务能够由利益相关方实现问责的步骤。

另外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（运行时电脑102）也能够构成为，在以下的两种情况下至少实施所述障碍处理循环P301，即，在所述对象系统开发时或更新时，实施将所述可靠性描述数据对应于规格变更而变更的变化应对循环P300；以及在运用所述对象系统时，检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，施行用于避免所述对象系统停止的障碍处理循环P301；并且，所述可靠性维持装置还具有再构建单元（再构建部102-04），所述再构建单元在检测出发生了所述障碍时，基于所述可靠性描述数据，再构建该对象系统。

由此，在用于施行障碍处理循环P301的运行时电脑102中，检测出对象系统发生障碍时，基于可靠性描述数据，再构建该对象系统，能够使运用对象系统继续运行。

并且，运行时电脑102也能够基于D值检测对象系统障碍的发生。例如，当D值发生恶化超出预定的变动容许范围时，也能够检测出障碍的发生。

〔8．障碍处理循环（障碍防范未然）〕

图23是表示障碍处理循环P301中检测障碍预兆时的两个处理的流程图。此外，图23中的障碍处理循环P301是图17的重新组合。

障碍预兆S301-02由监视部（障碍预兆检测单元）102-03检测障碍预兆或者故障（或故障预兆）时转移到该状态中。此外，关于障碍的预兆，能够通过各种方法的组合来实现。例如，硬磁盘驱动器装置通过使用S.M.A.R.T.的构架能够检测出障碍的预兆。另外，例如，当D值时间变化的趋势对照预定基准发生恶化时，监视部102-03检测障碍预兆。另外，在以所述监测节点监测的数据时间变化趋势超过变动容许范围的情况下，该监视部102-03将其检测为障碍预兆。在障碍预兆检测时的障碍处理循环P301中，两个功能有关系，即系统再构建处理S602和问责处理S603。

系统再构建处理S602涉及到对策提取S301-03和紧急对策S301-04。系统再构建处理S602从障碍部位和其影响范围的界定S602-01开始。在此，在说明方面上将障碍的预兆与障碍其本身的检测同样视为障碍来进行处理。首先，将可靠性描述数据的哪个部位界定障碍。并且从该可靠性描述数据中界定其影响范围。影响范围通过探索可靠性描述数据的节点来界定。例如，在与障碍部位相对应的节点为多个的情况下，能够将到这些公共节点之前的节点区间界定为影响范围。另外，在节点中记录有节点间的依存关系的情况下，也能够利用该依存关系。

接着，在服务继续判断S602-02中，判断从该可靠性描述数据中提取的对应脚本是否充分覆盖了该影响范围而能够继续服务。在能够继续的情况下（S602-02YES），进入障碍部位隔离S602-03。此外，在从可靠性描述数据中无法提取对应脚本的情况下（S602-02NO），判断为无法继续，并施行可靠性描述数据的变更提取处理S800（图27）。该变更提取处理S800，即使在由服务继续判断S602-02无法继续的情况下，也存在最好依据该障碍预兆内容施行的状况，因此，也能够构成为作为一实施例施行该变更提取处理。

接着，在障碍部位隔离S602-03中，按照所提取的对应脚本来隔离障碍部位。

接着，进入服务继续S602-04，并结束系统再构建处理S602。在此时使运行时电脑102的服务继续提供（S602-05）。

另一方面，问责处理S603涉及到记录S301-05和原因查明S301-06。问责处理S603从内部状态的记录S603开始。在此，记录了与所述障碍相关的可靠性描述数据以及与该可靠性描述数据相关的运行时电脑102的内部状态。

接着，收集系统再构建处理S602后的证据（S603-02）。在此所谓的证据是指，通过系统再构建，运行时电脑102按照可靠性描述数据进行适当动作的相关记录。此外，在本实施方式中，通过该证据的收集来实现利益相关方的问责（S603-03）。

所述紧急对策S301-04也能够使用所述脚本（D-Script）进行处理。图24示出一个例子。该脚本（D-Script）为用于重启图4（b）所示的WEB服务的脚本例子，由六个基本动作（D-Task）构成。该脚本从所述DEOS工序中的要求提取和风险分析阶段250-11中的服务继续脚本中导出。利益相关方对该脚本进行协定。该服务继续脚本使用支持要求提取和风险分析阶段的工具组260-01来描述，以图24的形式进行描述，对脚本进行变换，由利益相关方协定进行电子签名。

脚本在运行时电脑102内部的后述的脚本引擎部710（102-07）中施行时，验证随附于该脚本上的电子签名。在电子签名无效的情况下脚本不施行。进而，也能够构成为在脚本施行时，确认其权限。即，构成为能够确认谁能施行哪个脚本的操作。在该情况下没有权限的状况下不施行该脚本。进而，也能够构成为使脚本自身密码化而记录到运行时电脑102内部。通过这些安全性相关施策，能够防止该脚本因此违反安全性。

以下，使用图25，对运行时电脑102相关软件的层次结构的一个例子进行说明。

在图25中表示具有三个CPU核心701（701-01～701-03）的多核心结构例子。此外，在图25中省略了周边设备。在CPU核心的上位层具有系统容器提供部702。这样提供了作为隔离部102-05（图1）的一部分，即能够多个OS内核711相对于上位层进行动作的被隔离容器。另外，在图25中，分别将各个系统容器716、718、720分配到各个CPU核心701中，也能够将多个系统容器分配到一个CPU核心701中，也能够将多个CPU核心701…分配到一个系统容器中。

在CPU核心701-01中分配有系统容器716，因此，在OS内核711上，分别配置有系统监测部704、再构建部102-04、系统记录部706和可靠性描述数据处理部707。

一个系统容器716存在于运行时电脑102中。系统监测部704作为监视部102-03（图1）一部分，用于监测运行时电脑102中的系统功能。特别是监测其他系统容器（图25中示出系统容器718、720）的OS内核711。另外，也能够构成为在该系统监测部704具有学习功能。例如，在监控对象系统中的系统功能时，在构成为监测对其数据结构的匹配性的情况下，构成为能够自动生成与该系统功能相对应的说明书，或者从源代码中自动生成用于匹配的条件。通过在施行时学习该条件，即使不监测该数据结构整体或者该数据结构变更也不会改变该监测计划而能够继续监测功能。

再构建部102-04进行其他系统容器的再构建。具体而言，停止和破坏已存在的系统容器，以新的结构作出系统容器，基于该构成配置和启动以OS内核为首的功能。在系统容器受到破坏时，也能够使用系统记录部706来记录该系统容器内部状态。系统记录部706作为记录部102-02（图1）的一部分，记录了运行时电脑102的内部状态。

可靠性描述数据处理部707作为更新部102-01（图1）的一部分，将由工作区电脑101生成且位于软件SW内部中的可靠性描述数据加入到整个运行时电脑102的可靠性描述数据中，提取用于处理可靠性描述数据的脚本，利用再构建部102-04来再构建运行时电脑102。

另一方面，在CPU核心701-02中分配系统容器718，因此，在OS内核711上配置有应用程序监测部708、应用程序记录部709、脚本引擎部710、应用程序容器提供部712、应用程序管理部713～714以及应用程序组。

在此，所谓应用程序容器是指，相对于一个所述系统容器存在一个以上，使一个以上的应用程序集成化，实现了地址空间的独立、名称空间的独立以及CPU调度的独立，并由应用程序容器提供部712提供。在图25中，在系统容器718中配置有二个应用程序容器717、719。

应用程序监测部708作为监视部102-03（图1）的一部分，用于监测应用程序容器内部。应用程序记录部709作为记录部102-02（图1）的一部分，记录了应用程序容器内部状态。

在应用程序容器717中配置有应用程序管理部713，利用了一个以上的应用程序。同样在应用程序容器719内部配置有应用程序管理部714，利用了一个以上的应用程序。

系统容器720内部结构与系统容器718同样，因此，省略了其说明以及图25的显示。

图26汇总了由运行时电脑102的隔离部102-05（图1）实现的各隔离项目的相关功能要件一个例子。也能够从这些隔离项目仅仅选择一部分来实现所需的功能要件。例如，所述系统容器实现了这些全部项目，应用程序容器实现了地址空间、名称空间以及CPU调度三个项目。

此外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（运行时电脑102），在为了使具有所述系统运用时的所述可靠性描述数据的系统所提供服务不停止而检测障碍预兆将障碍发生防范于未然的工序中；在分别具有：用于记录具有所述可靠性描述数据的系统内部状态的单元（录入）、用于从该记录的内部状态检测具有所述可靠性描述数据的系统障碍预兆的单元、用于对与具有所述可靠性描述数据的系统的该检测出的障碍相对应的部分进行界定的单元、以及用于基于该检测出的障碍来判断所述系统运用时的系统所提供的服务继续性的单元的工序中；在形成了由以该障碍发生的检测作为起点的一系列步骤构成的闭合循环的该工序中；也能够施行以下的两个处理，即，在基于该检测出的障碍发生或者障碍预兆来避免服务停止的目的下，再构建具有所述可靠性描述数据的系统的步骤；以及运用经该再构建的系统和提供服务，能够由利益相关方实现问责步骤。

另外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（运行时电脑102）也能够构成为，在以下的两种情况下至少实施所述障碍处理循环P301，即：在所述对象系统开发时或更新时，实施对应于规格的变更来变更所述可靠性描述数据的变化应对循环P300；以及在运用所述对象系统时，检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，实现避免所述对象系统停止的障碍处理循环P301；并且，所述可靠性维持装置还具有再构建单元（再构建部102-04），所述再构建单元在检测出所述障碍预兆时，基于所述可靠性描述数据，再构建该对象系统。

由此，在用于施行障碍处理循环P301的运行时电脑102中，检测出对象系统的障碍预兆时，基于可靠性描述数据，再构建该对象系统，能够使运用对象系统继续运行。

并且，运行时电脑102也能够基于D值检测对象系统的障碍预兆。例如，在D值时间变化趋势与预定基准相比发生恶化时，也能够检测出障碍预兆。

进而，运行时电脑102也能够基于所述监测节点上的监测数据检测出对象系统的障碍预兆。例如，在该监测数据时间变化趋势与预定基准相比发生恶化且超过变动容许范围时，也能够检测出障碍预兆。

〔9．从障碍处理循环开始启动变化应对循环〕

图27是表示可靠性维持系统100中的可靠性描述数据的变更提取处理步骤的流程图。

在上述服务继续判断S502-01（图19）或者服务继续判断602-02（图23）中，当判断为服务继续判断为“NO”即无法继续时，施行可靠性描述数据的变更提取处理S800。

首先，提取障碍部位相关的可靠性描述数据（S800-01）。接着，其在可靠性描述数据中的叶节点中与测试有关的所有节点中，施行S800-03～S800-05的处理（S800-02）。

例如，在图5中，节点组（202-06～202-13）较为适合。因此，施行与该节点组（202-06～202-13）相对应的测试来进行计测（S800-03）。已经存在作为证据的结果，因此，与在此的计测结果相比，判断与证据之间的差异是处于变动容许范围内（S800-04）。在超出变动容许范围外的情况下（NO），当出现异常状态时，记录该节点的识别信息（例如节点号）（S800-05）。

在结束对所有节点的所述处理时，将令记录有所述识别信息的节点变更的指示传送给工作区电脑101（S800-06），然后结束处理（S800-07）。

此外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（运行时电脑102）在所述障碍处理循环P301中，在判断为所述系统运用时具有所述可靠性描述数据的系统所提供的服务无法继续提供的情况下，在所述变化应对循环P300中使具有所述可靠性描述数据的系统所提供的服务继续的目的下，也能够施行以下的步骤，即，从经所述障碍处理循环P301记录或检测的信息中将具有所述可靠性描述数据的系统的可靠性描述数据变更作为要求输入到所述障碍处理循环P301中。

另外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（可靠性维持系统100、运行时电脑102）也能够构成为具有变更要求发送单元（变更送出部902-02），所述变更要求发送单元在所述障碍发生或障碍预兆被检测出，而无法避免所述对象系统停止时，将所述可靠性描述数据变更要求发送到用于施行所述变化应对循环P300的装置（工作区电脑101）中。

本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101）也能够构成为，在以下的两种情况下至少施行下述变化应对循环P300，即，在所述对象系统开发时或更新时，对应于规格的变更来变更所述可靠性描述数据的变化应对循环P300；以及在运用所述对象系统时，检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，实施避免所述对象系统停止的障碍处理循环P301中；并且从用于施行所述障碍处理循环P301的装置（运行时电脑102）中接收所述可靠性描述数据的变更要求时，变更所述可靠性描述数据。

由此，在用于施行障碍处理循环P301的运行时电脑102中，检测对象系统障碍的发生或障碍预兆，当判断为对象系统的停止无法避免时，能够向用于施行变化应对循环P300的工作区电脑101中发送可靠性描述数据的变更要求。此外，运行时电脑102也能够基于D值判断是否会因为障碍发生或障碍预兆，而造成对象系统不可避免停止。

并且，工作区电脑101在从运行时电脑102中接收可靠性描述数据变更要求时，根据该要求，变更所述可靠性描述数据。

因此，运行时电脑102与工作区电脑101协作，检测对象系统障碍的发生或障碍预兆，如果对象系统不可避免地发生停止，则能够顺利地施行变更可靠性描述数据的工序。因此，在开放环境中，能够继续地维持对象系统的可靠性。

此外，在所述结构中构成为，即使在能够避免对象系统停止的情况下，也能够根据障碍预兆内容施行所述可靠性描述数据的变更步骤。

〔10．障碍处理循环与变化应对循环间的协作〕

图28是表示工作区电脑101和运行时电脑102经由可靠性描述数据来更换信息的功能框图。

工作区电脑101中的编辑工具部101-01主要具有三个构成要素。可靠性描述数据编辑部900-01对可靠性描述数据进行描述、编辑和记录。该可靠性描述数据编辑部900-01也能够构成为图16所示的D-CaseEditor（260-06）。此外，作为可靠性描述数据编辑部900-01，也能够使用申请号为特愿2010-263681所述的工具。在该申请号为特愿2010-263681中，当要求基部（base）描述了可靠性描述数据时，着眼节点始终处于显示中心地示出可靠性描述数据，由此使具体化流程简化。

可靠性描述数据编入部900-02将经可靠性描述数据编辑部900-01制成的可靠性描述数据M1变换为内部表现，生成可靠性描述数据M2（准确地说为可靠性描述数据内部表现M2；相当于图3中的可靠性描述数据104-02）。并且，可靠性描述数据编入部900-02将与该软件SW相对应（或相关）的所述可靠性描述数据M2编入于软件SW中。调配部900-03将该软件SW导入到运行时电脑102中。

在此，在可靠性描述数据M2中，由可靠性描述数据编辑部900-01涉及各证据节点，记录了相对于所监测的监测值的变动容许范围。由此，在运行时电脑102的监视部102-03中，能够确认监测值的状态。另一方面，在可靠性描述数据M3中，由记录部102-02涉及各证据节点，记录了受到监测的所有监测值或一部分监测值。由此，在工作区电脑101的分析部901-03中，能够研讨系统产生异常的原因。

另外，工作区电脑101中的分析工具部101-03主要具有三个构成要素。可靠性描述数据输入部（描述数据获取单元）901-01输入了来自运行时电脑102的可靠性描述数据M3。数据库存取部901-02对导入至运行时电脑102中的整个软件相关的多个可靠性描述数据进行存取。数据库也能够设置于工作区电脑101中，还能够设置于运行时电脑102中，也能够设置于能与工作区电脑101通信的其他装置中。在此，从该数据库中提取与所输入的可靠性描述数据M3相关的可靠性描述数据M4。可靠性描述数据M4为原始模型，可靠性描述数据M3为记载变更的模型。从该数据库提取的可靠性描述数据M4以可靠性描述数据M3作为关键字来检索，但也能够提取更宽范围的可靠性描述数据，容易在分析部901-03中进行处理。分析部901-03对该输入的可靠性描述数据M3和经由贝塔（β）基存取部901-02获得的可靠性描述数据M4进行分析，分析障碍原因等，根据需要转移到环境变化S300-01（图17、图18）的状态，施行变化应对循环P300。

另一方面，在运行时电脑102中，更新部102-01具有六个构成要素。软件输入部（描述数据获取单元）902-01输入了来自工作区电脑101中调配部900-03的软件SW。该软件SW由更新部102-01安装于运行时电脑102来运行。可靠性描述数据提取部902-03取出包含于软件SW中的可靠性描述数据M2（准确地说可靠性描述数据内部表现M2，即相当于图3中的可靠性描述数据104-02）。结构验证部902-04对作为该取出的可靠性描述数据M2的计算机表现的稳妥性进行验证。进而，确认在运行时电脑102中是否具备所需功能（资料库等）。施行管理部902-05将该软件SW导入运行时电脑102时进行必要的准备。例如，在该软件SW为新服务应用程序的情况下，对必要的计算资源进行评估和分配，生成应用程序容器（图25的应用程序容器717等），在该应用程序容器内构成应用程序图像。

另外，变更送出部（变更要求发送单元）902-02将安装于运行时电脑102中的可靠性描述数据M2中的变更部分（可靠性描述数据M3）送出至工作区电脑101的可靠性描述数据输入部901-01中。此时，变更送出部902-02也能够与所述变更部分相同，将可靠性描述数据的变更要求送出。变更管理部902-06在运行时电脑102中，对图27所示的可靠性描述数据的变更进行管理。

在上述说明中，工作区电脑101与运行时电脑102借助可靠性描述数据这样的计算机表现参数进行信息交换。从前者至后者将可靠性描述数据M2作为参数手段，从后者至前者将可靠性描述数据M3作为参数手段。可靠性描述数据M2作为与利益相关方协定相对应的模型，在运行时电脑102中，可靠性描述数据M3并不为该利益相关方的协定所满意，表现出有差值，并通知给利益相关方。

此外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101、运行时电脑102）以使具有所述可靠性描述数据的系统所提供服务继续为目的，也能够具有在所述变化应对循环P300与所述障碍处理循环P301之间进行信息交换的单元。

〔11．可靠性描述数据的协作〕

图29作为计算机表现的一个例子表示将图5所示的可靠性描述数据作为经XML描述的列表一部分。此外，能够由该XML标记描述编入于图28中的软件SW中的可靠性描述数据M2或可靠性描述数据M3。

图30是作为可靠性维持系统100的结构例子，表示可靠性描述数据的数据库与工作区电脑以及运行时电脑之间的关系的说明图。

如图30所示，编入于软件SW中的可靠性描述数据M2，记录于工作区电脑101与运行时电脑102分开独立的可靠性描述数据的数据库1000中，也能够从工作区电脑101以及运行时电脑102中得到利用。该数据库也能够构成为图15所示的协定描述数据库250-06。

此外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101、运行时电脑102）具有管理单元，该管理单元由具有该可靠性描述数据的系统对从所述可靠性描述数据变换来且能够以电脑处理的形式数据进行管理；也能够具有用于可靠地在具有该可靠性描述数据的系统中施行所述变化应对循环P300中经利益相关方协定了变更要求的步骤成果的单元。

〔12．运行时电脑的命令处理〕

图31示出了运行时电脑102中的命令施行的处理步骤。所谓本实施方式中的命令也能够是，编入于预先运行时电脑102中，且能够由该运行时电脑102施行的一系列处理，还能够是与后述可靠性描述数据节点相关联且能够由该运行时电脑102施行的程序。

首先，当命令施行处理S1100开始时，记录了开始处理的效果（S1100-01）。接着，将处理分解为一个以上的命令串，并使其构成为链条（S1100-02）。接下来，针对命令链中的所有命令（S1100-03），施行以下的S1100-04、S1100-05的处理。

即，将链中的命令以一条命令进行施行（S1100-04），判断其是正常结束还是异常结束（S1100-05）。并且，在全部命令正常结束的情况下（S1100-05YES），记录结束（S1100-07），并结束该处理（S1100-14）。

另一方面，在命令链中的命令异常结束的情况下（S1100-06NO），构建用于取消所施行的命令效果的复原链（S1100-08）。其后，对于复原链中的全部命令（S1100-09），施行复原命令（S1100-10），判断其正常结束还是异常结束（S1100-11）。在全部复原命令正常结束的情况下（S1100-11YES），记录其效果（S1100-07），并结束该处理（S1100-14）。

另一方面，在复原命令施行异常结束的情况下（S1100-11NO），施行所需的隔离处理（S1100-13），隔离含有该处理的容器（应用程序容器或系统容器），记录其效果（S1100-07），并结束该处理（S1100-14）。其后，施行所述再构建处理。

所述所述的步骤也能够将图24所述基本动作构成为命令链。由此，能够将所述脚本作为微小的操作来可靠地施行。

此外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101、运行时电脑102）以使具有所述可靠性描述数据的系统提供的服务继续为目的，也能够具有用于保证在该单元组具有所述可靠性描述数据的系统中可靠地施行下述〔A〕、〔B〕、〔C〕所述的单元组的装置。下述〔A〕、〔B〕、〔C〕所述的单元组是指：〔A〕在障碍处理循环P301中，在判断为无法所述系统运用时具有所述可靠性描述数据的系统所提供的服务无法继续进行的情况下，在变化应对循环P300中以使具有所述可靠性描述数据的系统提供的服务继续为目的，在所述障碍处理循环P301中从记录或检测的信息中，将具有所述可靠性描述数据的系统的可靠性描述数据变更作为对所述变化应对循环P300的要求，而输入至该变化应对循环P300中的单元；〔B〕以使具有所述可靠性描述数据的系统提供的服务继续为目的，用于使变化应对循环P300与障碍处理循环P301之间进行信息更换的单元；〔C〕通过具备以下的单元，即具备用于由具有该可靠性描述数据的系统管理从可靠性描述数据变换来且能够以电脑处理的形式的数据的单元，而在具有该可靠性描述数据的系统中可靠地实施变化应对循环P300中经利益相关方协定了变更要求的成果的单元。

〔13．可施行程序与节点的关联〕

图32是表示与可靠性描述数据相关联的程序的处理内容一个例子的流程图。

图32所示的节点（203-04）是图6所示的同一节点。该节点涉及到“利用了缓存的App Logic继续”。在本实施方式中，将可靠性描述数据按照编入到运行时电脑102的步骤来导入。此时，也能够将由运行时电脑102的二进制施行部110R施行的程序关联到可靠性描述数据的各节点上。另外，也将可施行的程序关联到监测节点上，并导入到运行时电脑102中。此外，程序与节点的关联能够在外部参照信息104-04中进行描述。另外，关于这些处理，在图32中以流程图表现该程序的处理内容，但也能够使用脚本语言，还能够使用由二进制施行部110R能够直接施行的程序代码。

在程序1200中，定义了导入处理S1200-01和废止处理S1200-11这二个处理的步骤。

导入处理S1200-01是在施行权限确认（S1200-02）后，利用应用程序容器提供部712（图25）的功能，生成应用程序容器（S1200-03）。接着，读入与App Logic201-03（图4（b））相对应的应用程序，将该程序代码注册到应用程序管理部714（图25）中。

另一方面，废止处理S1200-11是在施行权限的确认（S1200-12）后，停止与App Logic201-03相对应的应用程序（S1200-13），从应用程序管理部714中删除该程序代码的登记注册，利用应用程序容器提供部712的功能，删除该应用程序容器。

图33是表示与可靠性描述数据相关联程序的处理内容另一例的流程图。

图33所示的节点（203-01）是图7所示的同一节点。该节点涉及到“利用多重型的DBS不停止”。即是使具有备份系统的多台数据库系统同时运转的多重系统的数据库相关的可靠性描述数据的一部分。

在程序1201中，定义了更新处理S1201-01、导入处理S1201-11和废止处理S1201-21这三个处理的步骤。在置换可靠性描述数据中的节点时，在程序与该节点相关联的情况下，施行此处定义的更新处理。

具体而言，在图33中，以节点（204-01）置换节点（203-04），因此，施行了节点的更新处理。更新处理S1201-01的步骤是，在施行权限确认（S1201-01）后，在所置换节点（图33的场合，施行图32的节点（203-04））相关联废止处理S1200-11的步骤。当该步骤施行时，依照图31的命令施行处理S1100的流程图，记录结果（S1201-04）。

接着，导入处理S1201-11的步骤是，在施行权限确认（S1201-12）后，利用系统容器提供部702（图25）的功能，制作系统容器。接着，安装了不停止的DBS（S1201-14），并在应用程序管理部714（图25）中注册该DBS。

另一方面，废止处理S1201-21的步骤是，在施行权限确认（1201-21）后，使不停止的DBS停止（S1201-23），从应用程序管理部714删除该DBS的注册（S1201-24），利用系统容器提供部702的功能，删除了该DBS的系统容器（S1201-25）。

此外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（运行时电脑102），为了使具有所述可靠性描述数据的系统可靠地施行障碍发生检测时和障碍预兆检测时的障碍处理循环P301，也能够具有用于以电脑处理下述单元组〔A〕、〔B〕的表现单元：〔A〕在运用所述系统时具有所述可靠性描述数据的系统所提供的服务即使发生障碍时也能够继续进行的处理工序中，用于检测障碍发生的单元（监测功能）；用于隔离发生障碍部分的单元（隔离功能）；以隔离后残余的部分继续服务的单元；用于检测障碍原因的单元（原因追及功能）；用于判断所述系统运用时系统所提供的服务继续性的单元（继续性判断功能）。〔B〕为了使所述系统运用时的具有所述可靠性描述数据的系统所提供的服务不停止，而检测障碍预兆，以将障碍防范于未然的工序中，用于记录具有所述可靠性描述数据的系统内部状态单元（录入）；用于从该记录的内部状态中检测具有所述可靠性描述数据的系统的障碍预兆的单元；用于对具有所述可靠性描述数据的系统的该检测出的障碍与相对应的部分进行界定的单元；用于根据该检测出的障碍来判断所述系统运用时的系统所提供的服务继续性单元。

另外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（运行时电脑102）也能够构成为，在所述可靠性描述数据中记载有所述再构建的步骤，所述再构建单元（再构建部102-04）按照记载于所述可靠性描述数据中的再构建的所述步骤，再构建该对象系统。

由此，运行时电脑102能够按照记载于可靠性描述数据中的再构建步骤，再构建该对象系统。因此，在可靠性描述数据的设计阶段中，能够将再构建的步骤描述到该可靠性描述数据中，而不需要在再构建时制定步骤。

〔14．与协定形成工具间的协作〕

在图34中示出了可靠性描述数据M1、软件SW中所包含的XML形式可靠性描述数据M2（准确地说是可靠性描述数据内部表现M2，在此，说明了选择利用XML形式的内部表现的情况，因此，记载为“XML形式可靠性描述数据M2”。）与工作区电脑101所具有的工具组的各功能之间的关系。

编辑功能1300-01（图1中的编辑工具部101-02所具有的功能）用于对可靠性描述数据M1进行输入、修正和记录。验证功能1300-02（图1中的验证工具部101-01所具有的功能）用于验证该可靠性描述数据M1的稳妥性。基准标记功能1300-03（图1中的验证工具部101-01所具有的功能）用于确认该可靠性描述数据M1中的证据。变换功能1300-04（图1中的编辑工具部101-02以及开发工具部101-04所具有的功能）将差值验证模型M1变换到作为编入到软件SW中的形式的XML形式的可靠性描述数据M2。在该变换时，从可靠性描述数据中选取出监测节点部分，在维持其构成的同时进行变换，由此能够构成为本实施例。计测功能1300-05（图1中的验证工具部101-01所具有的功能）是对该XML形式可靠性描述数据M2的监测节点进行存取，并对数据进行计测和提取。

另外，在图35中示出了基准标记功能（图中记载为DS-Bench）与图16所示的D-CaseEditor之间的协作。构成为能够在D-Case Editor上指定基准标记，使得施行于监测节点上。基于来自该D-Case Editor的基准标记施行指示来施行实际的基准标记，并反映其施行结果，由此将其记录作为证据。该基准标记结果能够运用到D值的计算上。另外，也能够准备对D值有影响的基准标记，在该情况下，对D值的影响越大则基准标记的有效性也越高。

在该基准标记中，也能够包含有用于验证系统的性能相关特性以外的成为障碍起因那样的特性的基准标记。作为这样的基准标记例子，可列举使CPU负荷变动时的系统动作的相关基准标记；在使网络带域宽度变动时，或者使迟延变动时的系统动作的相关基准标记；使剩余存储器变动时的系统动作的相关基准标记；通过模拟过剩存取而对系统施加综合性负荷时的系统动作的相关基准标记；使系统结构模块特意异常结束时的系统动作的相关基准标记等。

进而，也能够构成为在例如使用图8所示的D-Case描述的情况下，为了验证该描述的匹配性或涵盖性等，可靠性描述数据使用了Agda定理证明器（http：//wiki.portal.chalmers.se/agda/pmwiki.php）。由此，能够自动消除该D-Case描述的描述错误。

此外，本发明也能够如下所示地构成。

本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101）也能够以使具有所述可靠性描述数据的系统提供的服务继续为目的，在所述变化应对循环P300中由利益相关方间形成协定的步骤中，具有以电脑能够处理的表现形式来描述来自利益相关方的要求变更的单元，还具有该表现形式的逻辑的验证单元。

〔15．可靠性维持系统间的相互协作〕

可以说本实施方式的可靠性维持系统100由工作区电脑101、可靠性描述数据M1和运行时电脑102构成。并且，该可靠性维持系统100的可计算的可靠性由该可靠性描述数据M1来表现。

在此，图36是表示将两个可靠性维持系统100连接起来的结构例子的框图。

如图36所示，能够将对用户的可靠性维持系统100U提供基于可靠性描述数据的功能的提供者的可靠性维持系统100S与用户的所述可靠性维持系统100U以网络1400-03连接起来，以构成复合系统。

在此，图37是表示将图36所示的两个可靠性维持系统100U、100S连接起来的结构中，独立的两个可靠性维持系统100U、100S间相互协作的一个例子的说明图。

从提供者的可靠性维持系统100，向用户的可靠性维持系统100U提示包括SLA（ServiceLevelAgre Ement）在内的SLA可靠性描述数据M2-SLA。SLA可靠性描述数据M2-SLA除了包括SLA的信息以外，其他信息与可靠性描述数据内部表现M2相同。

在包含于SLA可靠性描述数据M2-SLA中的SLA中，仅仅描述了可靠性维持系统100S中所公开的接口可靠性的相关信息。这是提供者提示的信息，对于该接口，能够捕捉到提供者对可靠性的许诺。另外，该可靠性描述数据能够计算出D值，用户能够确认计算D值与提供者的公开接口相关的可靠性与用户的基准是否一致。

本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101）以使具有所述可靠性描述数据的系统提供的服务继续为目的，在由二台以上的该系统以网络相互连接起来的环境中，也能够具有在该系统未相互连接的环境中所能够具有的上述各单元。

〔16．供应链〕

图38将图1所示的两个可靠性维持系统100作为主体侧和部件侧来统管的结构例子的框图。

如图38所示，能够为施行功能主体的主体侧的可靠性维持系统100B，由部件侧的可靠性维持系统100P将所述功能一部分作为部件提供。在图38中，示出了作为部件来提供可靠性描述数据M-B中的一个节点（1500-03）的例子。部件侧的可靠性维持系统100P所示的可靠性描述数据M-P是作为部件的节点（1500-03）的可靠性描述数据。

图39是由两个可靠性维持系统100B、100P作为主体侧以及部件侧来统管的构成中，独立的两个可靠性维持系统100B、100P间相互协作的一个例子的说明图。

在主体侧的可靠性维持系统100B中的工作区电脑101中，验证部件1500-03的可靠性描述数据M-P（S1502-01）。在该部件1500-03的可靠性描述数据M-P较为妥当的情况下，在主体侧的可靠性维持系统100B中的运行时电脑102，对该部件1500-03的基准标记进行计测（S1502-02）。如果其结果的证据充分，则主体侧的可靠性维持系统100B中的工作区电脑101将该部件1500-03置入主体的可靠性描述数据M-B中进行统管（S1502-05）。

图40中示出了统管部件的处理步骤详情。首先，该部件1500-03的可靠性描述数据M-P验证（S1502-01）。接着，实施基准标记，计测证据（S1502-02），进而，计算D值（S1502-03）。其结果为，在D值良好的情况下，能够进行统管（S1502-04YES），施行用于统管的再构建（S1502-05）。另一方面，在D值无法满意的情况下（S1502-04NO），向部件提供者要求部件（即，其可靠性描述数据M-P）的更新（S1502-06）。以后，重复同样的步骤。

本发明的可靠性维持装置（可靠性维持系统100、工作区电脑101）以使具有所述可靠性描述数据的系统提供的服务继续为目的，在该系统由第三者的一个或多个硬件或软件部件构成的情况下，各个部件具有所述可靠性描述数据，也能够具有与该系统的可靠性描述数据兼容性的验证单元。

〔17．可靠性描述数据的显示〕

使用图41，示出了在记录于运行时电脑102中的可靠性描述数据中的目标组一部分不满意的状况下，工作区电脑101中如图16所述的D-CaseViewer（260-07）表示该状况的例子。在此，使不满意的目标闪光（1600-01），根据需要提示操作员引起注意（1600-02）。此外，图41是D-Case描述例，但显出内容在本说明中并不重要，仅仅示出了其构成。

最后，可靠性维持系统100的各方框（block）、特别是工作区电脑101以及运行时电脑102的各方框也能够由硬件逻辑构成，还能够如下述那样使用CPU并通过软件来实现。

在后者的场合，可靠性维持系统100、工作区电脑101和运行时电脑102分别具有：用于施行实现各功能的程序命令的CPU（central proces sing unit；中央处理器）、用于记录所述程序的ROM（read only memory；只读存储器）、用于供所述程序展开的RAM（random access memory；随机存取存储器）以及用于存储所述程序和各种数据的存储器等存储装置（记录介质）等。并且，本发明的目的也能够通过以下的动作来达到，将用于以可由电脑读取的方式记录有作为实现上述功能的软件的可靠性维持系统100、工作区电脑101以及运行时电脑102的控制程序的程序代码（施行方式程序、中间代码程序和源程序）的记录介质，供给至所述可靠性维持系统100或工作区电脑101以及运行时电脑102中，其电脑（或CPU或MPU）读取了记录于记录介质中的程序代码后进行施行。

作为所述记录介质，能够使用例如包括磁带、盒式磁带系统、软磁盘（Floppy，注册商标）/硬盘等磁盘或CD-ROM/MO/MD/DVD/CD-R等光盘在内的磁盘系统、IC卡（包括存储器卡）/光卡等卡系统、或者掩模ROM/EPROM/E EPROM/闪存ROM等半导体存储器系统等。

另外，所述可靠性维持系统100、工作区电脑101以及运行时电脑102能够与通信网络连接而构成，也能够经由通信网络供给所述程序代码。作为该通信网络，未作特别限定，例如，能够利用互联网，内联网，外联网，LAN、ISDN、VAN、CATV通信网、虚拟专用网络（virtual private network）、电话线路网、移动体通信网以及卫星通信网等。另外，作为构成通信网络的传送介质，未作特别限定，例如，能够利用IE EE1394、USB、电线输送、电缆TV线、电话线、ADSL线等有线线路，也能够利用IrDA或遥控那样的红外线Bluetooth（蓝牙，注册商标）、802.11无线、HDR、便携式电话网、卫星线路、地面传送波数字网等无线线路。此外，本发明也能够通过以电子传送使所述程序代码具体化的埋入载波中的电脑数据信号的形态来实现。

（1）本发明的可靠性维持装置为一种用于维持对象系统可靠性的可靠性维持装置，其特征在于，具有：对用于描述对象系统可靠性的相关（经利益相关方协定）要求和规格的可靠性描述数据进行获得的描述数据获取单元；可靠性值确定单元，其基于所述描述数据获取单元所获得的可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值。

（12）另外，本发明的可靠性维持装置的控制方法用于维持对象系统的可靠性，其特征在于，包括：获取描述了对象系统可靠性相关（经利益相关方协定）要求和规格的可靠性描述数据的描述数据获取步骤；基于经所述描述数据获取步骤获得的可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值的可靠性值确定步骤。

根据所述的构成，基于描述了对象系统可靠性的相关（经利益相关方协定）要求和规格的可靠性描述数据，能够求出定量地表示对象系统可靠性价值的评价值。

因此，能够定量地表现对象系统可靠性价值。因此，例如，在随着要求的变更而变更可靠性描述数据时，或运用对象系统时确认对象系统状态时，能够易于了解对象系统可靠性价值而进行客观提示。

由此，能够起到顺利进行对象系统可靠性维持的效果。即，不完备性和不可靠性潜在性地存在开放环境中，能够起到支持对象系统可靠性维持的效果。

（2）进而，本发明的可靠性维持装置在所述（1）记载的构成的基础上，其特征在于，在以下的两种情况下施行以下至少一种处理，在所述对象系统开发时或更新时，施行对应于要求和规格的变更来变更所述可靠性描述数据（经利益相关方协定）的变化应对循环；以及在运用所述对象系统时，检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，施行用于避免所述对象系统停止的障碍处理循环。

根据所述结构，进而，在变化应对循环和障碍处理循环其中至少任一个循环中，能够求出表示对象系统可靠性价值的评价值。因此，例如，在变化应对循环中，随着要求的变更来变更可靠性描述数据时，基于评价值，能够判断可靠性描述数据变更方案合适与否。另外，例如，在障碍处理循环中，能够基于评价值来判断运用对象系统时的对象系统状态。因此，起到了能够顺利实施对象系统可靠性维持的效果。

（3）进而，本发明的可靠性维持装置在所述（1）记载的构成的基础上，其特征在于，在以下的两种情况下至少施行下述的障碍处理循环，即，在所述对象系统开发时或更新时，施行对应于要求和规格的变更来变更所述可靠性描述数据（经利益相关方协定）的变化应对循环，以及在运用所述对象系统时，检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，施行避免所述对象系统停止的障碍处理循环中；并且，所述可靠性维持装置具有再构建单元，所述再构建单元在检测出所述障碍发生或障碍预兆时，基于所述可靠性描述数据，再构建该对象系统。

根据上述构成，进而，在施行障碍处理循环的可靠性维持装置中，在检测对象系统障碍的发生或障碍预兆时，基于可靠性描述数据，再构建该对象系统，起到能够使对象系统的运用继续的效果。此外，也能够基于所述评价值来检测对象系统障碍的发生或障碍预兆。例如，当所述评价值相对于预定变动容许范围变得恶化时，或者，在所述评价值时间变化趋势相对于预定基准变得恶化时，也能够检测出障碍的发生。

（4）进而，本发明的可靠性维持装置在所述（3）记载的构成的基础上，其特征在于，在所述可靠性描述数据中记载有所述再构建的步骤，所述再构建单元，按照记载于所述可靠性描述数据中的再构建的所述步骤，再构建该对象系统。

根据上述构成，进而，可靠性维持装置能够按照记载于可靠性描述数据中的再构建步骤，再构建该对象系统。因此，在可靠性描述数据的设计阶段中，能够将再构建步骤预先于该可靠性描述数据中描述出来，因此，起到了在再构建时无需制定步骤的效果。

（5）进而，本发明的可靠性维持装置在所述（3）或（4）记载的构成的基础上，其特征在于，所述可靠性维持装置具有变更要求发送单元，所述变更要求发送单元检测所述障碍发生或障碍预兆，当所述对象系统不可避免地发生停止时，向用于施行所述变化应对循环的装置发送所述可靠性描述数据变更要求。

根据上述构成，进而，在施行障碍处理循环的可靠性维持装置中，检测对象系统障碍的发生或障碍预兆，当判断对象系统不可避免地发生停止时，能够向施行变化应对循环装置发送可靠性描述数据的变更要求。此外，也能够根据障碍的发生或障碍的预兆，基于所述评价值，判断对象系统的停止是否不可避免。

另一方面，所述可靠性维持装置接收到所发送的可靠性描述数据变更的要求时，施行变化应对循环的装置根据该要求，变更所述可靠性描述数据。

因此，用于施行障碍处理循环的可靠性维持装置与用于施行变化应对循环的装置进行协作，在障碍处理循环中，检测对象系统障碍的发生或障碍预兆，如果对象系统不可避免地发生停止，则能够在变化应对循环中，顺利施行变更可靠性描述数据的一系列工序。因此，在开放环境中，起到了能够继续维持对象系统的可靠性的效果。

（6）进而，本发明的可靠性维持装置在所述（1）记载的构成的基础上，其特征在于，在以下的两种情况中至少施行变化应对循环，即：在所述对象系统开发时或更新时，施行对应于要求和规格的变更来变更所述可靠性描述数据（经利益相关方协定）的变化应对循环；以及在运用所述对象系统时，当检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，施行避免所述对象系统停止的障碍处理循环；并且，在从用于施行所述障碍处理循环的装置中接收到所述可靠性描述数据的变更要求时，变更所述可靠性描述数据。

根据上述构成，进而，在用于施行变化应对循环的可靠性维持装置中，从用于施行障碍处理循环的装置中接收到可靠性描述数据的变更的要求时，能够根据该要求来变更所述可靠性描述数据。

因此，用于施行障碍处理循环的装置与用于施行变化应对循环的可靠性维持装置进行协作，在障碍处理循环中，检测对象系统障碍的发生或障碍预兆，如果对象系统不可避免地发生停止，则能够在变化应对循环中顺利地施行变更可靠性描述数据的一系列工序。因此，在开放环境中，起到能够继续地维持对象系统可靠性的效果。

（7）进而，本发明的可靠性维持装置在所述（1）至（6）中任一项记载的构成的基础上，其特征在于，所述可靠性描述数据是用于对由相互关联的目标节点与监测节点构成的组规定的数据，所述目标节点是以目标形式描述（经利益相关方协定）要求和规格的节点，所述监测节点作为表明满足了所述目标节点上描述目标的证据，并且与所述对象系统的监视点关联起来，所述可靠性值确定单元基于自相关联的所述监视点获得的数据相对于变动容许范围而言较为良好的监测节点，计算出所述评价值。

根据上述构成，进而，能够根据用于规定由相互关联的目标节点和监测节点构成的组的数据、例如树形结构或曲线图结构的数据，求出作为多维矢量值的评价值。

另外，本发明的可靠性维持装置在所述（1）至（6）中任一项记载的构成的基础上，其特征在于，

・所述可靠性描述数据是能够将目标节点与监测节点组成一组，且具有该组为一组以上的树形结构或曲线图结构的数据；

・所述目标节点是能够将（经利益相关方协定）要求和规格以目标形式描述的节点；

・所述监测节点是表明在所述目标节点中满足所述目标的证据；

进而，在所述监测节点具有判断单元，所述判断单元在能够获取来自所述对象系统内部所对应的监视点的数据的基础上，判断该监视点数据相对于变动容许范围而言较为良好；

所述可靠性值确定单元通过在所述树形结构或曲线图结构中计算所述证据良好的监测节点，以作为所述评价值。

另外，在所述可靠性维持装置中，所述可靠性描述数据是具有能够加权于节点间边沿上的树形结构或曲线图结构的数据的，所述可靠性值确定单元也能够将以加权于所述边沿上的分量为要素的多维矢量值作为所述评价值。

根据上述构成，进而，能够求出以加权于树形结构或曲线图结构的边沿上的分量为要素的多维矢量值作为评价值。

由此，获得了在树形结构或曲线图结构上加上边沿重要性的评价值。因此，起到了通过确认评价值能够评价加权于边沿上的变更对可靠性造成的影响的效果。此外，在此获得的评价值为多维矢量值，但也不过是能够利用基于目的任意变换方法变换为标量值。

（8）进而，本发明的可靠性维持装置在所述（1）至（6）中任一项记载的构成的基础上，其特征在于，所述可靠性值确定单元基于监测所述对象系统而获得的监测值相对于变动容许范围而言较为良好的证据，计算出所述评价值。

根据上述构成，进而，能够根据监控对象系统而获得的监测值相对于变动容许范围（基准值）而言较为良好的证据，计算出评价值。作为其计算方法，例如，能够计算出监测值相对于变动容许范围（基准值）而言较为良好的证据数（有效证据数）与包含于可靠性描述数据中的证据总数（总证据数）之间的比例，以作为评价值。

因此，获得了基于证据状态的评价值。由于证据随着要求的变更而变化，在此获得的评价值也随着要求的变更而发生变化。即，起到通过确认评价值能够评价要求变更对可靠性造成的影响的效果。

（9）进而，本发明的可靠性维持装置在所述（1）记载的构成的基础上，其特征在于，在以下的两种情况至少施行障碍处理循环，即：在所述对象系统开发时或更新时，施行对应于要求和规格变更来变更所述可靠性描述数据（经利益相关方协定）的变化应对循环；以及在运用所述对象系统时，检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，施行避免所述对象系统停止的障碍处理循环；并且，所述可靠性维持装置具有脚本处理单元，所述脚本处理单元在检测出所述障碍发生或障碍预兆时，施行包含于所述可靠性描述数据中的脚本，所述脚本包括用于使所述对象系统复原到变动容许范围状态的脚本。

根据上述构成，进而，在检测出障碍发生或障碍预兆时，施行包含于可靠性描述数据中的脚本，由此能够使对象系统复原到变动容许范围状态。

此外，优选所述脚本由利益相关方协定。另外，所述脚本由装于对象系统中的脚本引擎来施行。另外，所述脚本也能够根据从对象系统内部获得的日志，判断对象系统的状态是否处于变动容许范围内。另外，在施行用于使对象系统复原到变动容许范围状态的脚本时，该脚本也能够经由GUI接受操作员的操作。

（10）另外，本发明的可靠性维持系统用于维持对象系统的可靠性，其特征在于，包括：工作区装置，其在所述对象系统开发时或更新时，施行对应于要求和规格的变更来变更所述可靠性描述数据（经利益相关方协定）的变化应对循环；以及运行时装置，其在运用所述对象系统时，当检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，施行避免所述对象系统停止的障碍处理循环；所述工作区装置和所述运行时装置其中至少一者基于所述可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值。

（11）进而，本发明的可靠性维持系统在所述（10）记载的构成的基础上，其特征在于，所述可靠性维持系统经由网络与其他可靠性维持系统连接起来。

此外，所述的可靠性维持装置也能够由电脑来实现，在该情况下，使电脑作为所述各单元来动作，由此使所述可靠性维持装置由电脑来实现的可靠性维持装置的程序以及存储该程序的电脑可读取记录介质也属于本发明的范畴。

〔第二实施方式〕

本实施方式的可靠性维持装置20容易维持其要求和说明书与系统更新之间的无矛盾性。因此，如上所述那样，本实施方式的可靠性维持装置20具有D-Case变换部21，所述D-Case变换部21从描述了监控对象系统2的可靠性相关规格的D-CaseD-Case存储部10中进行读取，对监控对象系统2的状态进行监视，从所述读取D-Case中生成用于对必要时可施行对策的障碍监控部30动作进行控制的监测数据，并将该数据供给至障碍监控部30。

以下，基于图8以及图42至图56，对本发明一实施方式进行详细说明。

图42是表示本实施方式的障碍处理系统1的结构概略的功能框图。

本实施方式的障碍处理系统1监视监控对象系统2的动作，在发生了障碍的情况下，实施所需的对应措施。此外，作为监控对象系统2，能够适用于任意的电脑系统，特别是并非单个系统，而是适于存在多个利益相关方且需要高度复杂的可靠性的系统。具体而言，适于作为社会基础架构系统的基架那样的电脑系统、例如监视系统、电子结算系统、交通和航空管制系统，进而适于包含这些系统在内的云系统。

并且，特别是本实施方式的障碍处理系统1，其特征在于，容易进行经各利益相关方协定的对监控对象系统2的描述，并且在监控对象系统2有一部分更新的情况下，维持用于协定的描述和监测的安装模块间不相互矛盾地更新。即，障碍处理系统1能够将以可靠性描述数据表现的监控对象系统2的可靠性的相关规格与用于监测监控对象系统2的监测模块或执行模块的控制之间不相互矛盾地开发和更新。

因此，障碍处理系统1使用了可靠性描述数据、即具有能够容易进行各利益相关方的协定描述的特征的D-Case，描述了监控对象系统2的可靠性。另外，障碍处理系统1管理着用于对D-Case的模式（D-Case模式）和监控对象系统2进行监测的监测模块和执行模块间的相关性。由此，即使根据监控对象系统2的变更等，追加和变更监测模块或执行模块，也能够维持可靠性描述与监测模块以及执行模块之间的相关性。

（D-Case）

图8是表示D-Case的基本结构的说明图。另外，图43是表示D-Case具体例子的说明图。此外，图43表示将使用了面部识别的监视系统作为监控对象系统2的情况下的D-Case。

如上所述，在本实施方式中，使用了D-Case作为用于描述监控对象系统2可靠性的相关规格的可靠性描述数据。

所谓D-Case是指被称为Safety Case（安全实例），其主要在英国得到应用，并以用于保证系统安全性的结构化的文档为基础。在本说明书中，将以Safety Case为基础的可靠性描述数据称为“D-Case”。根据D-Case，在如图43那样的系统水平的讨论中将可用性等普通的可靠性属性详细化。

D-Case是用于与监控对象系统2有关的各利益相关方协定的结构化文档。如图8所示，详细地说， D-Case以系统的可靠性作为最高目标，使满足该目标的描述呈树形结构而更具体化，具有针对具体化的目标置入证据的树形结构。D-Case能够如下所述地以XML（Extensible Markup Language）来描述。

在此，在图43中，标注“G”的方框为最高目标（Top goal）。所述最高目标是表示需要经利益相关方间协定的有关对象系统的命题。例如，“对象系统满足以安全性规格X定义的Safety Integrity Level 3（安全完整性等级）”等。

标注“SG”的方框为次级目标。所示次级目标（Subgoal）是表示将用于表示最高目标而需要示出的目标分割开的命题。例如，最高目标“既为A且又为B”时，分割为次级目标“为A”、“为B”。次级目标分割为更小的次级目标。总称为最高目标、次级目标，简称为目标。

标注为“St”的方框作为策略。所谓策略是将目标的设立表示为如何按其次级目标组讨论的辅助说明。例如，在目标为“系统应对所考虑的所有障碍”时，例举“讨论所考虑每个障碍”作为策略。在该情况下，次级目标分别是“系统应对与所考虑的障碍1”、…、“系统应对所考虑的障碍N”。

标注“E”的方框作为证据。所谓证据是指将被分割的详细化目标作为最终的保证的叶节点。例如，对于次级目标SG“系统X的子模块Y能够处置障碍Z”这一目标，将“FTA分析结果”证据置于次级目标SG正下方。也考虑将次级目标SG进一步分割为次级目标，但无法无限地分割目标。最终保证已分割的次级目标，置入有证据。证据的稳妥性基于利益相关方间的协定。

另外，如图47所示，标注“C”的方框为上下文（Context）。上下文示出了补充目标或策略内容的信息。例如，策略为“讨论所考虑的每个障碍”的情况下，作为上下文，将“所考虑的障碍列表”附加到其策略中。策略或上下文示出了由阅读D-Case的利益相关方一边追加目标分割一边阅读时用于辅助的辅助信息。

此外，策略、上下文是在树形结构化时为了容易阅读而记入，但其在运行时间时是注释处理。

另外，图50所示的 “Monitor：M_1”等方框为监测。所谓监测表示系统进行障碍处理时需要的运行时间时的系统信息。例如，将运行时间时的“对工序X的CPU使用率的监测”等作为监测节点。监测为证据的子类。在将由障碍处理系统1的监测管理部40获得的信息用作证据的情况下，将其证据作为监测节点来示出。

接下来，参照图42以及图44，详细说明所述障碍处理系统1的结构以及处理流程。

如图42所示，障碍处理系统1构成为具有：D-Case存储部（可靠性描述存储部）10、可靠性维持装置20、障碍监控部30、监测管理部40、监测模块组50、行动（Action）管理部60和执行模块组70。

所述D-Case存储部10记录了用于描述与监控对象系统2有关的经利益相关方间协定可靠性相关的可靠性描述数据作为的D-Case。此外，障碍处理系统1中，各利益相关方协定D-Case输入。

所述可靠性维持装置20，使用表示用于对监控对象系统2监测的安装模块（监测模块、执行模块）的控制与D-Case模式之间的对应性的D-Case模式<=>模块对应表（见后述），从D-Case中生成监测数据（障碍处理脚本）。因此，可靠性维持装置20构成为具有D-Case变换部（可靠性描述变换部）21和对应表存储部22。

所述D-Case变换部21存储于D-Case存储部10中D-Case生成用于控制障碍监控部30动作的监测数据（障碍监测用数据）。

在此，使D-Case其一部分模式化。并且，所述对应表存储部22记录了表示D-Case模式与监测数据之间的对应性的表格（D-Case模式<=>模块对应表）。

D-Case变换部21参照记录于对应表存储部22中的D-Case模式<=>模块对应表，从D-Case中生成监测数据。

所述障碍监控部30监视（监测）监控对象系统2的状态，在必要情况下施行对策（行动）。具体而言，障碍监控部30依据在可靠性维持装置20中由D-Case变换部21生成的监测数据，控制着监测管理部40和行动管理部60。监测数据规定了监测管理部40对监测模块（监测模块组50）的选择和动作控制、以及行动管理部60对执行模块（执行模块组70）的选择和控制。

所述监测管理部40依照监测数据，管理一个以上的监测模块（监测模块组50）。在本实施方式中，作为监测模块例子，列举了CPU监视模块51和存储器监视模块52，但本发明并不局限于此。

所述行动管理部60依据监测数据来管理一个以上的执行模块（执行模块组70）。在本实施方式中，作为执行模块例子，列举了CPU限制模块71、存储器限制模块72和工序活力模块73，本发明并不局限于此。

图44是表示障碍处理系统1的处理的流程图。

首先，D-Case管理者将经利益相关方间协定而制作和变更的D-Case存储于D-Case存储部10中（S1；D-Case记录步骤）。

接着，D-Case变换部21从D-Case存储部10中读取D-Case（S2；D-Case读取步骤），从所读取的D-Case中，参照记录于对应表存储部22中的D-Case模式<=>模块对应表，生成用于控制障碍监控部30动作的监测数据（S3；D-Case变换步骤）。

此外，在随着D-Case的变更生成监测数据的情况下，D-Case变换部21也能够制作，仅仅与已变更的D-Case的差值相对应的监测数据。

接着，障碍监控部30按照所制成的监测数据，监视（监测）监控对象系统2的状态，在必要情况下施行对策（行动）（S4；障碍监视施行步骤）。

在此，对所述障碍监视施行步骤（S4）进行说明。

首先，在监测管理部40中登记有需要管理的监测模块，所述监测模块能够预先进行控制。另外，同样，在行动管理部60登记有需要管理的执行模块，所述执行模块能够预先进行控制。

并且，在障碍监视施行步骤（S4）中，障碍监控部30依据监测数据，指示监测管理部40启动适当的监测模块。并且，在由监测管理部40通知的监测模块的施行结果满足条件的情况下，障碍监控部30进而指示行动管理部60启动适当的执行模块来处置障碍。此时，监测管理部40和行动管理部60分别依据来自障碍监控部30的指示启动模块，传送适当的参数。

（D-Case变换）

接着，参照图45～图49，详细说明从D-Case到监测数据的变换处理。

在障碍处理系统1中，在从D-Case向控制用于对监控对象系统2监测的监测模块和执行模块的动作的监测数据的变换中，使用了D-Case模式<=>模块对应表。

在此，所谓D-Case模式是监控对象系统2的D-Case的一部分，其可用性等是如何以系统水平进行维持。即，所谓系统的可用性是指一种系统的性质，即，在系统处于因障碍等无法服务的状态时（系统停机状态）会尽量及时复原，在用户想享用服务时任何时候都能享用。在发生了障碍的情况下，由维护管理者等人员迅速进行复原，以及由系统自身自动利用障碍修复功能进行复原。一般，系统在OS水平下，使用CPU资源、存储器资源和网络资源等，提供服务。因此，在CPU资源等不足的情况下，会发生服务迟延等，存在降低可用性的可能性。因此，在用于某种服务的CPU资源减少的情况下，系统以OS水平自动处置其他重要度低的服务中占用了所使用的CPU资源等。监控对象系统2的D-Case从所述观点出来，讨论了系统水平下的可用性。

（D-Case模式）

图45是表示包含D-Case模式在内的D-Case具体例子的说明图。

所谓D-Case模式是D-Case的部分树形，包括可变部分。图45表示模式的一个例子，其应用于表现出适当保证工序属性的情况下。次级目标SG22和证据E25、E26的标注“ ”部分是可变（变量）的，其他为被固定的D-Case模式。图45表示已经在“ ”内代入 “图像处理”、“CPU使用率”、“50%以下”的状态。在该D-Case模式用作D-Case一部分的情况下，在“ ”部分内代入基于利益相关方间协定的值，利用其代入的值，能够适当与监测模块或执行模块关联起来。另外，其他是被固定的D-Case。在D-Case模式、即D-Case的“ ”部分中代入基于利益相关方间协定的值。另外，在D-Case的“ ”部分中代入值，由此能够适当地与监测模块执行模块关联起来。

图46是D-Case模式<=>模块对应表的一个例子，其中，（a）表示与监测模块相关的对应表，（b）表示与执行模块相关的对应表。

图46（a）将名为《对工序“$1”的“$2”为“$3”进行监测》的D-Case作为D-Case变换部21进行变换时供参照的表格。在该D-Case中，$1、$2、$3为变量。

例如，在处理图45中的D-Case时，D-Case变换部21从对应表存储部22中，读取能够与证据E25的描述《对工序“图像处理”的“CPU规格率”为“50%以下” 进行监测》相对应的表格（图46（a））。并且，使用自证据E25的描述中提取的变量$1、$2、$3的值，界定D-Case模式与模块间的对应关系，制作监测数据。具体而言，变量$2为“CPU规格率”，因而，确定了模块名“CPU监视”以及参数“$1、$3”，制作出《唤出“CPU监视”模块，将“图像处理”、“50%以下”作为参数来传递》这样内容的监测数据。

同样，D-Case变换部21从对应表存储部22中，读取能够与证据E26的描述《将工序“图像处理”的“CPU规格率”限制在“50%以下”》相适应的表格（图46（b））。并且，变量$2为“CPU规格率”，因而，确定了模块名“CPU限制”以及参数“$1、$3”，并制作出《唤出“CPU限制”模块，将“图像处理”、“50%以下” 作为参数来传递》这样内容的监测数据。

如上述那样，根据证据的描述中的被固定的D-Case的字符串（描述的固定部分），选择了D-Case模式<=>模块对应表。并且，根据部分变量（在所述例子中，指变量$2）值，选择了相应的模块。

这样，在本实施方式中，将证据的描述设为一部分设定有变量的表现形式，将依据其证据的值设定为变量，并描述证据。

接着，参照图47、图48，对图45中的D-Case已变更的情况下的处理进行说明。

图47是表示包含D-Case模式在内的D-Case具体例子的说明图。

在图47中，在图45上追加了上下文C31，并且将证据E26变更为证据E32。由于《C31：即使限制了其他工序“面部识别”也要将CPU充分加到“图像处理”中》，因此通过《E32：将工序“面部识别”予以“kill（删除）”》，表示经过了各利益相关方间的协定。

图48是此时的D-Case模式<=>模块对应表的一个例子。图48（a）表示与监测模块相关的对应表，图48（b）是表示与执行模块的相关的对应表。图48（a）与图46（a）相同。

并且，在处理图47的D-Case时，D-Case变换部21从对应表存储部22中，读取了能够与证据E32的描述《将工序“面部识别”“kill（删除）”》相适应的表格（图48（b））。并且，使用从证据E32的描述提取的变量$1、$2的值，界定D-Case模式与模块之间的对应关系，制作监测数据。具体而言，变量$2为“Kill”，因而，确定了模块名“工序活力”以及参数“$1”，制作了《唤出“工序活力”模块，以“Kill”、“面部识别”作为参数来传递》这样内容的监测数据。

这样，在D-Case模式<=>模块对应表中，也能够设定变量乃至常数值来作为参数。即，在图48（b）中，如果变量$2的值为“Kill”，则传递至工序活力模块73的第一号参数为“Kill”，如果变量$2的值为“Restart”，则所传递的参数为“Restart”。另外，如果变量$2的值为“Migration”，则由Migration模块（未图示）而非工序活力模块73作为行动来施行。

以下，参照图49，对重新追加了监测模块或执行模块的情况下的处理进行说明。

在重新追加监测模块或执行模块的情况下，在监测管理部40或行动管理部60中进行注册之前，D-Case管理者在D-Case模式<=>模块对应表中追加了用于规定对应关系的数据（变换规则）。

图49是D-Case模式<=>模块对应表的一个例子，表示与监测模块相关的对应表。例如，在重新追加了用于监视网络传送量的模块的情况下，如图49所示那样，在图46（a）上追加了一行。

（汇总）

如上所述，在所述障碍处理系统1中，使用了监测管理部40对监测模块的选择和动作控制以及行动管理部60对执行模块的选择和控制与D-Case模式之间的对应关系的D-Case模式<=>模块对应表，从D-Case中生成监测数据。即，一边参照D-Case模式<=>模块对应表，一边将存储于D-Case存储部10中的D-Case变换为障碍监控部30的监测数据。这样，由D-Case变换部21从存储于D-Case部10中的D-Case中生成障碍监控部30所使用的监测数据，由此，将D-Case与障碍监控部30的动作与之间始终不相互矛盾地维持。

另外，在存储于D-Case存储部10中的D-Case变更了的情况下，其变更由D-Case变换部21作为监测数据的变更通知给障碍监控部30。此外，也能够由可靠性维持装置20或D-Case变换部21检测D-Case的变更，将变更后的监测数据自动通知给障碍监控部30。

另外，D-Case管理者在D-Case中重新追加D-Case模式的情况下，在D-Case模式<=>模块对应表中追加用于规定对应关系的数据（变换规则）。

另外，在修正和追加监测模块或执行模块的情况下，障碍处理系统1通知给D-Case管理者。D-Case管理者也一并对与所修正和追加的监测模块或执行模块相对应的D-Case模式<=>模块对应表进行修正。此外，在未对与所修正和追加的监测模块或执行模块相对应的D-Case模式<=>模块对应表进行修正的情况下，监测模块或执行模块无法D-Case相对应，因此，无法使用监测数据。使用已修正的D-Case模式<=>模块对应表来修正监测数据，由此将D-Case障碍监视与之间不相互矛盾性地维持。

另外，将D-Case模式<=>模块对应表预先保存于数据库中，在变更D-Case时，为了参照适当D-Case模式<=>模块对应表，也能够从数据库中将其提取出来运用。由此，在每次D-Case变更时不需要编制D-Case模式<=>模块对应表，能够低成本来处置D-Case的变更。

接下来，参照图50～图56，对其他具体例进行说明。

图50以及图51是表示D-Case的其他具体例子的说明图。图50和图51表示以连结部A连结起来的一个树形结构。另外，图52～图55是表示以图50、图51所示的D-CaseXML形式描述的例子的说明图。此外，在图52～图55中是从图50、图51所示的D-Case中选取一部分而示出。图56是表示从图50、图51以及图52～图55所示的D-Case变换来的监测数据（障碍处理脚本）例子的说明图。

如图52～图55所示，在本具体例中，在D-Case的XML文件中埋入用于控制障碍监控部30的障碍处理脚本。并且，图56表示分别从D-Case的XML文件（图52～图55）的“Monitor：M_1”～“Monitor：M_5”中提取的脚本。此外，图50以及图51是将图52～图55图形化地表示出来，在数据中也含有障碍处理脚本。

这样，障碍处理脚本埋入于D-Case中这一点与参照图45～图49作了说明的D-Case模式<=>模块对应表具体例不同。但是，在表示利益相关方协定的D-Case与监控对象系统的障碍处理脚本之间能够不相互矛盾地更新这一点上两者相同。

本发明也能够如下所示地构成。

本发明的可靠性维持装置20也能够构成为，对监控对象系统2的状态进行监视，在必要情况下生成对用于施行对策障碍监控部30的动作进行控制的障碍监测用数据（监测数据），并将该数据供给至所述障碍监控部30，所述可靠性维持装置20具有靠性描述变换部（D-Case变换部21），所述可靠性描述变换部（D-Case变换部21）从可靠性描述存储部（D-Case存储部10）中读取描述了所述监控对象系统2可靠性的相关规格的可靠性描述数据（D-Case），从所读取的可靠性描述数据中生成所述障碍监测用数据。

另外，本发明的可靠性维持装置20的控制方法也能够是，对监控对象系统2的状态进行监视，生成用于控制在必要情况下施行对策的障碍监控部30的动作的障碍监测用数据，并将该数据供给至所述障碍监控部30，其中，可靠性维持装置20的控制方法包括：从可靠性描述存储部（D-Case存储部10）读取用于描述所述监控对象系统2的可靠性相关规格的可靠性描述数据（D-Case）的读取步骤（S2）；以及从读取出的可靠性描述数据中生成所述障碍监测用数据的变换步骤（S3）。

进而，所述可靠性维持装置20也能够构成为，所述障碍监控部30监视着所述监控对象系统2的状态，从多个模块（监测模块组50、执行模块组70）中选择出用于在必要情况下施行对策的模块，并能够控制所述模块，所述可靠性描述数据的一个描述（证据）是至少含有能够将用于界定所述模块的模块界定信息（变量$2；模式）设定为一值的变量的形式，所述可靠性描述变换部基于预先设定的用于表示所述模块界定信息所述障碍监测用数据的对应关系的信息（D-Case模式<=>模块对应表），将包含于所述可靠性描述数据中的变换对象的描述变换为与包含于该描述中的模块界定信息相对应的障碍监测用数据。

进而，所述可靠性维持装置20也能够构成为，与从所述可靠性描述数据的一个描述中除去变量部分后的固定部分相对应，设定所述对应关系，所述可靠性描述变换部参照与包含于所述可靠性描述数据描述中的所述固定部分相对应的所述对应关系，将该描述变换为相对应的障碍监测用数据。

另外，本发明的障碍处理系统1也能够构成为，包括所述可靠性维持装置20、所述可靠性描述存储部（D-Case存储部10）和所述障碍监控部30，所述可靠性维持装置20依据从自所述可靠性描述存储部中读取的可靠性描述数据生成的障碍监测用数据，使所述障碍监控部30进行动作，由此监视所述监控对象系统2的状态，在必要情况下施行对策。

进而，所述障碍处理系统1也能够构成为，包括：用于监视所述监控对象系统2的状态的一个以上监测模块（监测模块组50）；在必要情况下对所述监控对象系统2施行对策的一个以上执行模块（执行模块组70）；通过所述障碍监控部30的控制，进行所述监测模块的选择以及动作控制的监测管理部40；以及通过所述障碍监控部30的控制，对所述执行模块进行选择和动作控制的行动管理部60。

另外，本发明也能够如下所示地构成。

本发明的电脑系统（障碍处理系统1）具有：用于存储描述了利益相关方间可靠性相关协定的可靠性描述数据（D-Case）的可靠性描述存储部（D-Case存储部10）；用于监视（监测）对象系统（监控对象系统2）内部状态，并在必要情况下施行对策（行动）的障碍监控部（障碍监控部30）；以及从可靠性描述数据中生成用于控制障碍监控部动作的障碍监测用数据（监测数据）的可靠性描述变换部（D-Case变换部21），能够构成为通过始终由可靠性描述变换部从记录于可靠性描述存储部中的可靠性描述数据中生成障碍监测用数据，以将可靠性描述障碍监控部的动作不相互矛盾地维持。

进而，所述电脑系统也能够构成为，可靠性描述其一部分被模式化，使用表示可靠性描述模式与障碍监测用数据间的对应性的表格（D-Case模式<=>模块对应表），从可靠性描述中生成障碍监测用数据。

进而，所述电脑系统也能够构成为，障碍监控部具有监测管理部（监测管理部40）和行动管理部（行动管理部60），监测管理部管理着一个以上的监测模块（监测模块组50），行动管理部管理一个以上的执行模块（执行模块组70），使用了表示对监测管理部对监测模块的选择和动作控制以及行动管理部执行模块的选择和控制与可靠性描述的模式之间的对应性的表格，从可靠性描述中生成障碍监测用数据。

进而，所述电脑系统的控制方法也能够构成为，具有：对描述了利益相关方间可靠性相关协定的可靠性描述数据进行记录的可靠性描述存储步骤（D-Case记录步骤S1）；障碍监控部监视对象系统内部状态，在必要情况下施行对策的障碍监测步骤（障碍监视施行步骤S3）；以及从可靠性描述中生成用于控制障碍监测步骤动作的障碍监测用数据的可靠性描述变换步骤（D-Case读取步骤S2、D-Case变换步骤S3）；通过始终利用可靠性描述变换步骤从经可靠性描述存储步骤记录的可靠性描述数据生成中障碍监测用数据，由此将可靠性描述与障碍监控部动作不相互矛盾地维持。

另外，障碍处理系统1的各程序块、特别是可靠性维持装置20的D-Case变换部21也能够利用硬件逻辑来构成，也能够如下所述那样使用CPU利用软件来实现。

在后者的场合，障碍处理系统1具有：用于施行实现各功能的程序命令的CPU（central processing unit）、用于存储所述程序的ROM（read only memory）以及供所述程序展开的RAM（random access memory），所述程序以及各种数据记录存储器等记录装置（记录介质）等。并且，本发明的目的也能够通过以下方式来达到，即，向所述的障碍处理系统1或可靠性维持装置20，提供记录有能够以电脑读取的、作为实现上述功能的软件的障碍处理系统1或可靠性维持装置20的控制程序的程序代码（施行方式程序、中间代码程序、源程序）的记录介质，其电脑（或CPU或MPU）读取和施行记录于记录介质中的程序代码。

作为所述记录介质，能够使用例如包括磁带、盒式磁带系统、软磁盘（Floppy，注册商标）/硬盘等磁盘或CD-ROM/MO/MD/DVD/CD-R等光盘在内的磁盘系统、IC卡（包括存储器卡）/光卡等卡系统、或者掩模ROM/EPROM/E EPROM/闪存ROM等半导体存储器系统等。

另外，所述的障碍处理系统1或可靠性维持装置20能够与通信网络相连接而构成，也能够经由通信网络供给所述程序代码。作为该通信网络，未作特别限定，例如，够利用互联网，内联网，外联网，LAN、ISDN、VAN、CATV通信网、虚拟专用网络（virtual private network）、电话线路网、移动体通信网以及卫星通信网等。另外，作为构成通信网络的传送介质，未作特别限定，例如，能够利用IE EE1394、USB、电线输送、电缆TV线、电话线、ADSL线等有线线路，也能够利用IrDA或遥控那样的红外线Bluetooth（蓝牙，注册商标）、802.11无线、HDR、便携式电话网、卫星线路、地面传送波数字网等无线线路。此外，本发明也能够利用通过电子传送使所述程序代码具体化的埋入载波中的计算机数据信号的形式来实现。

在所述说明中，图示并参照了功能方框和步骤，但只要功能的分离并合或步骤的移动能够满足所述功能，所述说明便不会限定本发明。

（1）本发明的可靠性维持装置对着监控对象系统的状态进行监视，生成用于控制在必要情况下施行对策的障碍监控部动作的障碍监测用数据，并将数据供给至该所述障碍监控部，其特征在于，所述可靠性维持装置具有可靠性描述变换部，所述可靠性描述变换部从可靠性描述存储部中读取描述了所述监控对象系统可靠性的相关（经利益相关方协定）要求和规格的可靠性描述数据，并从读取出的可靠性描述数据中生成所述障碍监测用数据。

（6）另外，本发明的可靠性维持装置的控制方法是，对着监控对象系统的状态进行监视，生成用于控制在必要情况下施行对策的障碍监控部动作的障碍监测用数据，并将数据供给至该所述障碍监控部，其特征在于，所述可靠性维持装置的控制方法包括：从可靠性描述存储部中读取描述了所述监控对象系统可靠性的相关（经利益相关方协定）要求和规格的可靠性描述数据的读取步骤；以及从读取出的可靠性描述数据中生成所述障碍监测用数据的变换步骤。

根据上述构成，可靠性维持装置从自可靠性描述存储部读取出的可靠性描述数据中生成障碍监测用数据。并且，障碍监控部据此进行动作，由此，障碍监控部能够对着监控对象系统的状态进行监视，在必要情况下施行对策。

在此，可靠性描述数据是对监控对象系统的可靠性的相关规格进行描述。并且，监控对象系统的各利益相关方对监控对象系统的可靠性达成协定时，优选将其结果作为可靠性描述数据来描述，并存储于可靠性描述存储部中。

这样，由可靠性维持装置从存储于可靠性描述存储部中的可靠性描述数据中生成障碍监控部所使用的障碍监测用数据，由此能够将可靠性描述数据与障碍监控部动作始终不相互矛盾地维持。

（2）进而，本发明的可靠性维持装置在所述（1）记载的构成的基础上，其特征在于，所述障碍监控部监视着所述监控对象系统的状态，能够从多个模块中选择并控制用于在必要情况下施行对策的模块，所述可靠性描述数据是一个描述至少含有能够将用于界定所述模块的模块界定信息设定为一值的变量的形式，所述可靠性描述变换部基于预先设定的用于表示所述模块界定信息与所述障碍监测用数据之间的对应关系的信息，将包含于所述可靠性描述数据中的变换对象的描述变换为与包含于该描述中的模块界定信息相对应的障碍监测用数据。

根据上述构成，进而，在将包含于可靠性描述数据中的变换对象描述变换为障碍监测用数据时，在障碍监控部中选择利用包含于该描述中的模块界定信息界定的模块，生成受控制的障碍监测用数据。

由此，即使在障碍监控部能够控制的模块具有多个的情况下，也能够从可靠性描述数据的描述中生成以适当模块为控制对象的障碍监测用数据。

（3）进而，本发明的可靠性维持装置在所述（2）记载的构成的基础上，其特征在于，与从所述可靠性描述数据的一个描述中除去变量部分后的固定部分相对应地设定所述对应关系，所述可靠性描述变换部，参照与包含于所述可靠性描述数据的描述中的所述固定部分相对应的所述对应关系，将该描述变换为所对应的障碍监测用数据。

根据上述构成，进而，在将包含于可靠性描述数据中的变换对象的描述变换为障碍监测用数据时，参照与从该描述中除去所包含的变量部分后的固定部分相对应的对应关系，将该描述对应变换为障碍监测用数据。

由此，能够对包含于可靠性描述数据中的每个描述的固定部分关联上不同的对应关系。因此，即使模块界定信息等的变量相同，如果固定部分不同，也能够使用不同的对应关系，将包含于可靠性描述数据中的描述变换为障碍监测用数据。因此，能够利用简易规则来实现多种的变换。

（4）另外，本发明的障碍处理系统也能够构成为，其包括所述（1）至（3）中任一项所述的可靠性维持装置、所述可靠性描述存储部和所述障碍监控部，所述可靠性维持装置依据从自所述可靠性描述存储部读取出可靠性描述数据中生成的障碍监测用数据，使所述障碍监控部进行动作，由此，监视着所述监控对象系统的状态，在必要情况下施行对策。

（5）进而，本发明的障碍处理系统在所述（4）记载的构成的基础上，其特征在于，也能够构成为包括：用于监视所述监控对象系统状态的一个以上监测模块；在必要情况下对所述监控对象系统施行对策的一个以上执行模块；利用所述障碍监控部的控制，对所述监测模块的选择和动作进行控制的监测管理部；利用所述障碍监控部的控制，对所述执行模块的选择和动作进行控制的行动管理部。

此外，所述的可靠性维持装置以及障碍处理系统也能够通过电脑来实现，在该情况下，将电脑作为所述可靠性描述变换部来进行动作，由此使所述可靠性维持装置利用电脑来实现的可靠性维持装置的程序以及记录该程序的电脑可读取记录介质均纳入本发明的范畴内。

在所述说明中，图示了功能方框以及步骤并加以参照，但只要功能的分离并合或步骤的移动能够满足所述功能，所述说明便不会对本发明造成限定。

发明的详细说明项中所记载的具体实施方式或实施例毕竟使本发明的技术内容更加清楚，但并不会仅仅受限于那样的具体例子也不应是窄义的解释，在本发明的精神和附记的权利要求项的范围内，能够进行各种变更和实施。

产业上的可利用性：

根据本发明的可靠性维持装置，在潜在性地存在不完备性和不可靠性的开放环境中，能够提供对利益相关方间误解要求、对环境变化的无法适应和障碍处理失败这三个问题的解决方案。本发明能够广泛地利用到开放环境中的系统开发以及系统运用中。

另外，根据本发明的障碍处理系统以及可靠性维持装置，使各利益相关方协定的描述变得容易，并且，在监控对象系统有部分更新的情况下，能够维持对协定的描述与模块的安装不相互矛盾的开发和更新。因此，例如，从嵌入式系统到以互联网等相连的多个系统，本发明可维持多种系统的可靠性，因此本发明适于作为装置和方法来提出。

Claims (22)

1.一种可靠性维持装置，其用于维持对象系统的可靠性，其特征在于，具有：

数据获取单元，其用于获取描述了对象系统可靠性相关要求和规格的可靠性描述数据；

可靠性值确定单元，其基于所述描述数据获取单元所获得的可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值。

2.根据权利要求1所述的可靠性维持装置，其特征在于，

在以下的两种情况下至少实施以下任一种应对循环，即，在所述对象系统开发或更新时，实施与要求、规格的变更相对应地变更所述可靠性描述数据的变化应对循环；以及在运用所述对象系统时，检测障碍发生或障碍预兆时，基于所述可靠性描述数据，实施避免所述对象系统停止的障碍处理循环。

3.根据权利要求1所述的可靠性维持装置，其特征在于，

在以下两种情况下至少实施以下的障碍处理循环，即，在开发或更新所述对象系统时，实施与要求、规格的变更相对应地变更所述可靠性描述数据的变化应对循环；以及在运用所述对象系统时，检测障碍发生或障碍预兆时，基于所述可靠性描述数据，实施避免所述对象系统停止的障碍处理循环；

并且，所述可靠性维持装置具有再构建单元，所述再构建单元在检测出所述障碍发生或障碍预兆时，基于所述可靠性描述数据，再构建该对象系统。

4.根据权利要求3所述的可靠性维持装置，其特征在于，

在所述可靠性描述数据中记载有所述再构建步骤，

所述再构建单元按照记载于所述可靠性描述数据中的再构建的所述步骤，再构建该对象系统。

5.根据权利要求3或4所述的可靠性维持装置，其特征在于，

所述可靠性维持装置具有变更要求发送单元，所述变更要求发送单元在检测出所述障碍发生或障碍预兆而不避免停止所述对象系统时，向用于施行所述变化应对循环的装置中发送所述可靠性描述数据的变更要求。

6.根据权利要求1所述的可靠性维持装置，其特征在于，在以下的两种情况中至少施行以下的变化应对循环，即，在所述对象系统开发时或更新时，施行对应于要求和规格的变更来变更所述可靠性描述数据的变化应对循环；以及在运用所述对象系统时，当检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，施行避免所述对象系统停止的障碍处理循环；

并且，在从用于施行所述障碍处理循环的装置中接收到所述可靠性描述数据的变更要求时，变更所述可靠性描述数据。

7.根据权利要求1至6中任一项所述的可靠性维持装置，其特征在于，所述可靠性描述数据是用于对由相互关联的目标节点和监测节点构成的组进行规定的数据，

所述目标节点是以目标形式描述了要求和规格的节点，

所述监测节点作为表明满足了所述目标节点上描述目标的证据，并且与所述对象系统的监视点关联起来，

所述可靠性值确定单元基于自相关联的所述监视点所获得的数据相对于变动容许范围而言较为良好的监测节点，计算出所述评价值。

8.根据权利要求1至6中任一项所述的可靠性维持装置，其特征在于，所述可靠性值确定单元基于经监测所述对象系统而获得的监测值相对于变动容许范围而言较为良好的证据，计算出所述评价值。

9.根据权利要求1所述的可靠性维持装置，其特征在于，在以下的两种情况至少施行以下的障碍处理循环，即：在所述对象系统开发时或更新时，施行对应于要求和规格变更来变更所述可靠性描述数据的变化应对循环；以及在运用所述对象系统时，检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，施行避免所述对象系统停止的障碍处理循环；

并且，所述可靠性维持装置具有脚本处理单元，所述脚本处理单元在检测出所述障碍发生或障碍预兆时，施行包含于所述可靠性描述数据中的脚本，

所述脚本包括用于使所述对象系统复原到变动容许范围状态的脚本。

10.一种可靠性维持系统，其用于维持对象系统的可靠性，其特征在于，包括：

工作区装置，其在所述对象系统开发时或更新时，施行对应于要求和规格的变更来变更所述可靠性描述数据的变化应对循环；以及

运行时间装置，其在运用所述对象系统时，当检测出障碍发生或障碍预兆时，基于所述可靠性描述数据，施行避免所述对象系统停止的障碍处理循环；

所述工作区装置和所述运行时间装置其中至少一者基于所述可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值。

11.根据权利要求10所述的可靠性维持系统，其特征在于，所述的可靠性维持系统经由网络与其他可靠性维持系统相连接。

12.一种可靠性维持装置的控制方法，其用于维持对象系统的可靠性，其特征在于，包括：

获取描述了对象系统可靠性的相关要求和规格的可靠性描述数据的描述数据获取步骤；以及

基于经所述描述数据获取步骤获得的可靠性描述数据，求出定量地表示所述对象系统可靠性价值的评价值的可靠性值确定步骤。

13.一种控制程序，其中，所述控制程序用于使电脑作为如权利要求1至9中任一项所述的可靠性维持装置的所述各单元来发挥功能作用。

14.一种电脑可读取记录介质，其中，所述电脑可读取记录介质记录有如权利要求13所述的控制程序。

15.一种可靠性维持装置，对监控对象系统的状态进行监视，生成用于控制在必要情况下施行对策的障碍监控部的动作的障碍监测用数据，并将所述数据供给至所述障碍监控部，其特征在于，

所述可靠性维持装置具有可靠性描述变换部，所述可靠性描述变换部从可靠性描述存储部中读取描述了所述监控对象系统可靠性的相关要求和规格的可靠性描述数据，从读取出的可靠性描述数据中生成所述障碍监测用数据。

16.根据权利要求15所述的可靠性维持装置，其特征在于，所述障碍监控部能够从多个模块中选择并控制用于对所述监控对象系统的状态进行监视，并在必要情况下施行对策的模块，

所述可靠性描述数据是一个描述至少含有能够将用于界定所述模块的模块界定信息设定为一值的变量的形式，

所述可靠性描述变换部基于预先设定的用于表示所述模块界定信息与所述障碍监测用数据之间的对应关系的信息，将包含于所述可靠性描述数据中的变换对象的描述变换为与包含于该描述中的模块界定信息相对应的障碍监测用数据。

17.根据权利要求16所述的可靠性维持装置，其特征在于，与从所述可靠性描述数据的一个描述中除去变量部分后的固定部分相对应地设定所述对应关系，

所述可靠性描述变换部参照与包含于所述可靠性描述数据描述中的所述固定部分相对应的所述对应关系，将该描述变换为对应的障碍监测用数据。

18.一种障碍处理系统，其特征在于，包括：

如权利要求15到17中任一项所述的可靠性维持装置；

所述可靠性描述存储部；以及

所述障碍监控部；

所述可靠性维持装置依据从自所述可靠性描述存储部读取出的可靠性描述数据中生成的障碍监测用数据，所述障碍监控部进行动作，由此，对所述监控对象系统的状态进行监视，在必要情况下施行对策。

19.根据权利要求18所述的障碍处理系统，其特征在于，包括：

用于监视所述监控对象系统状态的一个以上监测模块；

在必要情况下对所述监控对象系统施行对策的一个以上执行模块；

利用所述障碍监控部的控制，对所述监测模块进行选择和动作控制的监测管理部；以及

利用所述障碍监控部的控制，对所述执行模块进行选择和动作控制的行动管理部。

20.一种可靠性维持装置的控制方法，对监控对象系统状态进行监视，生成用于控制在必要情况下施行对策的障碍监控部的动作的障碍监测用数据，并将所述数据供给至所述障碍监控部，其特征在于，包括：

从可靠性描述存储部中读取描述了所述监控对象系统可靠性的相关要求和规格的可靠性描述数据的读取步骤；

从读取出的可靠性描述数据中生成所述障碍监测用数据的变换步骤。

21.一种控制程序，所述控制程序用于将电脑作为权利要求15至17中任一项所述的可靠性维持装置来发挥功能作用，其中，并用于将电脑作为所述可靠性描述变换部来发挥功能作用。

22.一种电脑可读取记录介质，其中，所述电脑可读取记录介质用于存储有权利要求21所述的控制程序。

Images