欧洲铁路标准前言(中文版EN50128)

该欧洲标准应和EN50126——2：“铁路应用——引导运输系统可信性——第二部分：安全性”，以及EN50129：“铁路应用——安全电子铁路控制和防护系统”一起阅读。

欧洲标准的关键概念是软件完善度等级。软件完善度等级越高，由软件规格说明或由设计缺陷所引起的系统危险失效和可能性就越小。

欧洲标准建立了为软件完善度的5个相应的技术和措施，其中0等级最低，4等级最高。等级1到4标征安全软件，而等级0标征非安全软件。将0等级也包括在其中的目的是为了实现非安全性软件开发和安全软件开发之间的平稳过渡，表中列出了完善度等级所要求的技术和措施。在这一版中，等级1和等级2相同，等级3和等级4所要求的技术相同，对于某一给定的危险哪一软件完善度用于它，欧洲标准没有加以指明。这将取决于多种原因，包括应用特征、其它系统实现安全性功能的限度、以及社会和经济因素。

EN50126——2：“铁路应用——引导运输系统可信性——第二部分：安全性”，以及EN50129：“铁路应用——安全电子铁路控制和防护系统”的作用就是详细说明分配给软件的安全性功能以及软件所要求的完善度等级。欧洲标准详细解释了要达到这些要求所必需的措施。

EN50126——2：“铁路应用——引导运输系统可信性——第二部分：安全性”和EN50129：“铁路应用——安全电子铁路控制和防护系统”要求将系统化的方法用于：

i) 确定危险、风险和风险准则； ii) 确定为满足风险准则所必须进行的风险缩减； iii) 为满足风险准则必需的安全监护定义整个系统的安全性需求规格说明； iv) 选择一个合适的系统结构； v) 规划、监督和控制那些把系统安全性要求规格说明转换为具有确认的安全性（或安全性完善度）

的安全系统所需的技术方面和管理方面的活动。

在EN50126——2：“铁路应用——安全电子电路控制和防护系统”中，为满足所要求的风险准则必须进行的风险缩减将被指定为上述五个软件完善度等级之一，并示于图1中。风险率是在对危害事件的后果（或严重程度）和频率进行评估的基础上而获得的。图1也指明了如何将规格说明分解为一个构造安全系统的设计，以及元器件如何实现安全性完善度等级的进一步分配。最后就导出了所要求的软件完善度等级，它同功能要求一起作为本标准所述活动的出发点。

从表面上看，一个运行的可靠系统可以被自动地假定为是一个安全系统，但详细分析后表明，必要的时候，仅仅有高可靠性还不足保证安全性。

可靠性是面向系统目标、预期作用（服务），以及系统所希望执行的特定任务范围的。可靠性要求研究服务的连续提供能力。

安全性研究可能事件的起因、后果，以及导致产生非所希望输出的顺序关系。安全性要求研究如何制作一个不会引发事故的系统。安全性要求将确保系统不会进入危险或不安全的状态，而在该状态，某一事件可能会引发事故。

从安全性角度看，系统是否按要求去工作不是十分紧要的，只要它不违背安全性要求就行。从另一方面讲，非常可靠的系统也有可能是不安全的。

考虑一个用两台计算机按动态冗余方式构成的故障安全系统。两台计算机的输出相互比较以检测其中之一可能出现的失效。这一失效出现之后……。

i) 如果要求高安全性，两台计算机都需停机，并且进程也要求被导入一个安全的停止返回状态。

由于没有什么办法能确定是哪台计算机出错，所以系统不能提供进一步的服务。即使有很高的概率识别出出错的计算机，但要检测进一步的错误输出没有冗余是不可能做到的。

ii) 如果要达到很高的可靠性，那么就有可能在出错计算机被识别出来后，让（可能）无故障的计

算机在没有任何冗余的情况下连续工作。

上例表明在安全性和可能性之间可能进行权衡。实际上，在设计过程中还要考虑其它的一些权衡，同时还要考虑成本对其它系统性能的影响，如可用性、可维护性及保险性。本欧洲标准的范围不包括对这些

1

权衡的指导。

注意：IEC TC56 WGI中已建议将这一系统性能集合：可靠性、可用性、可维护性、安全性和保险性统一用一个术语来概括“可信性”。

软件本身有可靠性，即在给定输入后得到预期结果的能力。而对软件安全性，则有必要统观整个系统，必须要注意软件在特殊运用中的上下联系。如果对一个错误的排序算法不存在引起危险的可能性，那么谈论排序用安全软件是毫无意义的。

在现行技术条件下，无论是质量保证方法（所谓预防措施）的应用还是软件冗错方法的应用均不能保证系统的绝对安全性。现有方法无法证明在适当复杂的安全性软件中不存在错误，尤其是规格说明和设计中的错误。

开发高完善度软件等级软件的原则包括，但并不局限于以下几点： ——自上而下的设计方式； ——模块化；

——开发生命周期的每一阶段的验证； ——验证模块和模块库。 ……

本标准中不同的软件完善度等级要求有不同的保证等级，以使这些原则及其相关的其它原则被正确地运用。

1 欧洲标准的应用

在确定分配给软件的所有安全性功能及决定完善度等级的系统安全性要求规格说明生成之后，这一欧洲标准应用的功能步骤如图2所示，它们是：

i) 在定义软件要求规格说明的同时考虑软件体系结构。软件体系结构是用于开发软件基本安全

策略的。（第9条和第10条）

ii) 根据软件质量保证方案、软件完善度等级和软件生命周期来设计、开发和测试软件。（第11

条）

iii) 集成软件和目标硬件。（第13条） iv) 确认软件。（第14条） v) 将被确认软件和软件确认报告移交给系统工程师以便进一步集成进整个系统。（第14条） vi) 如果在运行过程中要求维护软件，那么可再适当运用在欧洲标准进行处理。（第17条） 许多活动都是同软件开发交叉进行的。其中包括验证（第12条），评估（第15条）和质量保证（第16条）。

对从事软件开发人员的能力要求也有相应的要求。（第7条）

本标准不硬性要求使用特殊的软件开发生命周期，但是给出了一个推荐的生命周期及相应文档。 表格对照五个软件完善度等级系统地排列出各种技术措施。所有表格均放在附件A中。对该表的交叉引证可得一个文献目录，它对每一技术措施均作出了简要描述，并附有进一步参考的信息资源。文献目录在在附件B中。

附件A是规范的，附件B供参考用。 …… 2. 范围

2.1 欧洲技术标准指定了用于铁路控制和防护设备的可编程电子系统的开发所需的规程和技术要求。它适用于任何有无安全性隐含项的这样的领域，从非常关键的，如安全性信号，到关键的，如管理信息系统。这些系统可由专用的微处理器，可编程的逻辑控制器。多处理器分布式系统，大规模处理机系统以及 其它体系结构来实现。

2.2 欧洲标准可专门应用于软件以及软件和“宽系统”之间的相互作用。

2.3 软件完善度等级是为了在失效可引起包括失去生命在内的后果的系统中使用。使用较高的软件完

2

善度完整型等级为好。

2.4 欧洲标准适用于铁路控制和防护系统开发和实现的所有软件包括：应用程序设计、操作系统、支持工具、固件。

应用程序设计包括高级程序设计，低级程序设计和专用目的的程序设计（如：可编程，逻辑控制器梯形逻辑和计算机数控部分的程序设计）。

2.5 欧洲标准对标准，商用软件和工具提出了建设的使用。 2.6 欧洲标准还对由应用数据配置的系统提出了要求。

2.7 欧洲标准并不想涉及商务问题，这些问题应为合同的基本部分被提出。但欧洲标准中的所有条款在任何商务活动中应被仔细考虑。

2.8 欧洲标准为避免追溯，所以主要应用于新的开发和全面适用于那些主要修改的现存系统。对于软件完善度3或4，在开始变动之前，合同的全面型将决定是否将维护行为考虑为主要的还是次要的。对软件完善度等级0，1，2由供应商来作出相同的决定。对于主要修改，欧洲标准将被全面使用。对于次要修改，欧洲标准仅适用小量部分。 3 参考文献

3.1 标准参考文献

以参考文献的方式欧洲标准包含了下列标准条款。以出版时的版本号为准。所有标准都可能被被修订，所以以本欧洲标准为基础的合同双方应注意引用了下列标准。可能性，IEC和ISO的成员都保留着目前最新国际标准为记录。

EN29001：1987质量统一设计、开发、生产、安装和服务过程中的质量保证模块。

EN29000-3：1993质量管理和质量保证标准，第三部分——将EN29001应用于软件开发、销售和维护的指南。

EN50126-2：铁路应用——引用运输系统可信型——第二部分：安全性。 EN50129：铁路应用——安全电子铁路控制与防护系统。 3.2供参考的文献

ISO/IEC9126：1991信息技术——软件产品评估——质量特性及其使用方针。 IEC50（191）：1990国际电子技术词汇（191章，服务的可信性和质量） 4 定义

本欧洲标准应用如下定义。 评估员

指由安全性权威机构认定的人员和制定代理。安全性权威机构对设计机构和评估员的工作进行评价。目的是对系统的目标和安全性完善度的适应性进行评估。 设计机构

负责对安全性需求规格设计结果的说明和监督，在预定环境下的系统的开发和开展工作。 设计者

由设计机构认定的一个或多个个人，他（们）分析将特定的需求转变为具有所要求的安全性完善度的可接受的设计结果。 差错

由于系统错误而引起的失效：差错即为易于导致失效的系统状态部分。简单地讲，差错也就是距被认可的需求规格说明书的测量偏差。（与IEV不同）。 失效

当已交付的服务偏离规格说明的服务时，系统发生了失效，这里规格说明书是一分期望的，已被认可的详细说明。简言之，失效即为系统或软件差错的表现。（与IEV定义不同） 故障避让在系统设计和构造过程中为避免故障的引入而使用的设计技术。 容错

3

保障连续正确运行的系统内在能力，即在出现有限个硬件或软件故障时提供的特殊服务。 一般软件

一般软件，即用于安装特殊数据的软件。 执行者

由设计机构认定的一个或多个个人，他们将特定的设计转变为物理实体。 可维护性

在给定条件下保持或恢复到执行需求功能状态的能力。 可编程逻辑控制器（PLC）

一种固态控制系统，它具有一个存储执行特殊功能代码的用户可编程存储器。 可靠性

在一定时间内系统在规定条件下执行需求规格说明中所描述功能的可能性。 风险

频度或概率与特定危害性事件后果的组合。风险的概念通常包括两个元素：危害发生的频度或概率，以及危害性事件的后果。 安全性机构

负责证明安全性系统能胜任服务并遵守所有法规要求的团体。 安全性

系统在规定条件下不导致出现人类生命、躯体完整、健康或环境遭受危险的状态的期望值。 安全软件

证明系统不危及人类生命、躯体完整、健康、大家经济损失、重要设备的环境和控制软件。 软件

由程序、规程、规则和所有与数据处理的操作有关的文档组成的智力性创造。（参见ISO规则ISO/23821/1；第二版；1984-10-1） 注：软件于传递媒体。 软件生存周期

从设想软件开始到软件失效为止的一段时间。典型的软件生存周期包括需求阶段、开发阶段、测试阶段、集成阶段安装阶段和维护阶段。 软件完善度等级

在规定的时间和条件下，可编程电子系统完成其安全性功能的似然。 测试人员

由设计机构认定的一个或多个个人。他们指定并执行确保设计的物理实体是正确的，并且是满足所有规定的测试和验收准则所必需的测试。 确认

确保符合安全性、功能、性能和接口要求的整分软件系统的测试。 确认人员

由安全人员认定的人或任何生命的代理人，以确保安全系统在开发过程中要求遵守的所有标准和规程已被遵守以及规定的功能和安全性完善度已被满足。 验证

决定软件生存周期开发过程的每一个阶段的产品是否完成前面阶段指定的所有要求的过程。验证包括测试、检查和审计。 验证人员

由设计机构认定的一个或多个个人，以确保在每个阶段呈现的系统被较好地设计，被合理构造，没有不可接受的差错或缺陷，符合所有指定的要求和规程，具有可接受的质量和可靠性。 5 目标一致性

4

5.1 在以下每个条款中，将详细地描述其目的和要求。

5.2位与欧洲标准一致，必须指出，每一项要求已满足规定的等级，因而他们也满足条款的目标/ 5.3 如果一个要求附有“在软件完善度等级要求的范围内”的词句，则表示可用技术措施来满足条款的目标。

5.4 在条款5.3适用的地方，应使用本欧洲标准详细给出的表格来帮助选择与软件完善度等级相对应的技术和措施。

5.5 如果某一技术或措施在表格中被列为优先推荐，那么不使用该技术的理由应在软件质量保证计划或软件体系结构说明书中作详细说明并作相应纪录。

5.6 如果一项不包括在表格中的技术或措施被建议使用，那么应对其有效期及能满足特殊要求和条款整个目标的性能作证明，并在软件质量保证计划或软件体系结构说明书中作相应的纪录。

5.7 通过检查本标准所要求的和测试证据所要求的文档来评估是否符合特殊条款的要求和表格中详细列出的他们各自得技术和措施。

5.8本欧洲标准需要使用一组技术及他们的正确应用。这些技术是表格中所要求的，并在文献目录中详细列出。但是，本欧洲标准推荐的技术措施并不能保证要求的软件完善度等级能被达到。 6 软件完善度等级

6.1.1 该条款的目的是给软件分软件完善度等级。 6.2 要求

6.2.1 应产生一个系统安全性需求规格说明书，其中包括： 安全性功能；

系统的配置或体系结构； 硬件可靠性要求； 安全性完善度要求； 容量和向对应时间性能； 设备和操纵者接口； 任何其它功能及其属性；

系统安全性需求规格说明书的开发应按EN50126的要求来完成。软件完善度等级应按EN50126的要求来指定。

6.2.2应在与系统中使软件有关的风险等级的基础上决定所要求的软件完善度等级。 6.2.3 被考虑的风险是指与下列危后果有关的风险 失去人的生命； 使人受伤； 环境的污染； 财产损失或损坏；

6.2.4 风险可被指定为一个定量的可能性或一组定量的可能性，但是不能以同样的方式指定软件的完善度，因此，对于本欧洲标准，软件完善度等级将被指定为下列五个等之一： 软件完善度的软件完善度等级描述： 4 极高 3 高 2 中等 1 低

0 非安全性

6.2.5 在软件需求规格说明书中应指定软件的完善度等级（条款9）

7 人员与职责 7.1 目标

5

7.1.1 该条款的目标是保证所有对软件负有责任的人员有能力履行那些职责。 7.2 要求

7.2.1 作为最低限度，供应者或开发者，以及购买者都应执行EN29001的相关部分，这与EN29000-3：1993中的方针是一致的，两者都是强制性的。 7.2.2 除软件完善度等级0以外，安全性过程应当在一个适当的安全性组织的控制下完成。该组织应依从EN50129“安全管理的依据”条款的“安全性机构”子条款。以及EN50126——2“安全性过程”条款的“安全性机构”子条款。

7.2.3 所有设计、开发、评估、安装、维护或管理软件的人员应具有适当的培训、经验和资格。

7.2.4对于除软件完善度等级0以外的特殊情况应用，极力建议对设计、开发、评估、安装、维护或管理的所有人员的培训、经验、资格进行证明。

7.2.5 上面条款中包含证明应被纪录在软件质量保证计划中，并相应地包括能胜任下列领域工作的证据：

i) 适合应用领域的工程； ii） 软件工程；

iii） 计算机系统工程； iv） 安全性工程； v） 法规框架。

7.2..6 指定软件评估员。

7.2.7 应赋予评估人员足够的权力来实现对软件的评估。

7.3.8 根据图5，无论是开发还是维护，所包含的各部分是的。 8 生存周期专辑和文档 8.1 目标

8.1.1 该条款的一个目标是将软件的开发构造成特定的阶段和活动。

8.1.2 该条款的另一个目标是纪录贯穿于整个软件生存周期的软件相关的所有信息。 8.2 要求

8.2.1 选择软件开发的生存周期模型，根据欧洲标准条款16，它将在软件质量保证计划中加以详细说明。图3和图4示出了生存周期模型的例子。

8.2.2 质量保证规程将与生存周期活动一起运行。

8.2.3 所有在某一阶段中要被执行的活动应在该阶段开始之前被定义好。软件生存周期的一阶段应被分为具有非常确定的输入、输出及其基本活动的基本任务。

8.2.4软件质量保证计划应当描述出那些验证步骤和报告是要求的。 8.2.5 所有文档应构造能随着设计过程一起不断扩展。

8.2.6 每一文档具有一个唯一的参考和一个确定的、与其它文档之间的文档关系，这种文档提供了文档的跟踪能力。

此外，每一个文档应按下列规则书写：

a） 应包括或执行所有前续文档的可应用条件和要求，使文档具有层次关系； b） 不能与前续文档有抵触；

c） 在每一个文档中，每一个术语，首字母缩略词或缩写应具有相同的意义； d） 在每一个文档中，每一项目或概念应该用相同的名称或描述。 8.2.7所有文档内容应以适合于操作、处理和存储的形式来计录。 8.2.8 根据软件完善度等级的要求，应产生下列文档：

阶段 文档 系统开发的初始阶段 系统需求书

系统安全性需求规格说明书

6

系统体系结构描述 软件规则 软件安全性计划 软件配置

管理计划 软件开发计划 软件质量保证计划 软件确认计划 软件验证计划 软件维护计划

软件/硬件集成计划

软件要求 软件需求规格说明书 软件需求测试规格说明书 软件需求验证报告

软件设计 软件体系结构规格说明书 软件集成计划

软件设计规格说明书 软件设计测试说明书 软件设计验证报告

软件模块设计 软件模块设计规格说明书 软件模块测试规格说明书 软件模块验证报告

编码 软件源代码和支持文档 软件源代码验证报告

模块测试 软件模块测试报告

软件集成 软件集成报告

软件/硬件集成 软件/硬件集成报告

软件确认 软件确认报告

软件评估 软件评估报告

软件维护 软件维护报告

8.2.9 根据开发软件的规模，复杂性和生存周期，要求产生的各类文件数目有所不同。对于规模较小的项目，一些文件可以组合在一起（在这一过程中应不丢失所有的细节）。而对于大规模的项目，必须将文档（以分类名排列）分成一些便管理的子文件。由的组成或有全体统一产生的文档不能被组合成一个单

7

一的文档。

９ 软件需求规格说明书 9.1 目标

9.1.1 该条款的目标是描述一个文件，该文件定义了一整套满足所有系统得软件需求。它是一个适用于每一个软件工程师的综合性文档。它便于软件工程师了解任何其它文件中的需求。

9.2 输入文档

1） 系统需求规格说明书

2） 系统安全性需求规格说明书 3） 系统体系结构描述 4） 软件质量保证计划 9.3 输出文档

1） 软件需求规格说明书 2） 软件需求测试规格说明书 9.4 要求

9.4.1 在产生软件需求规格说明书时，应考虑如下文档： ——系统需求规格说明书

——系统安全性需求规格说明书 ——系统体系结构描述 ——软件质量保证计划

9.4.2 软件需求规格说明书应能描述出开发软件的需求特性，而不是开发软件的规程。这些特征应包括： ——功能（包括容量和影响时间性能） ——可靠性（在ISO/IEC 9126中定义） ——可维护性 ——可用性

——安全性（包括安全性功能及其与软件完善度等级同的关系）

软件完善度等级将派生出条款６中的定义，并纪录在软件需求规格说明书中。

9.4.3 根据软件完善度等级的要求，软件要求规格说明书应以如下方式来描述和构造： 清楚，精确、不含糊、可验证，可测试的，可维护的和可行的方式。

9.4.4 软件需求规格说明书应使用让整个系统的生存周期中负有责任的人员都能理解的表达和描述方法。

9.4.5软件需求规格说明书应识别和描述出所有任何与其它系统间，以及控制设备的内部或外部间的接口，包括对操作员的接口，以及已存在或计划中的直接连接接口。

9.4.6 软件需求规格说明书应详细描述所有相关的操作方式。

9.4.7 软件需求规格说明书中应详述可编程电子器件所有相关的行为方式，尤其是失效行为。 9.4.8 软件需求规格说明书中应识别并描述出软件和硬件之间的任何约束。

9.4.9 软件需求规格说明书中应表示出软件自检的程度以及由软件检测硬件的程度。软件之间程度包括软件自身失效和差错的检测和报告。

9.4.11 软件需求规格说明书所包括的要求在系统需求规格说需要规定的在整个系统运作过程中可测试的所有安全性功能的需求。

9.4.12 当要求软件来完成那些与实现所要求的系统完善度等级有关的功能时，软件需求规格说明书应对其加以说明。

9.4.13 当要求软件完成非安全性功能时，软件需求规格说明书应对其加以清楚地说明。

9.4.14 软件需求测试规格说明书应与软件需求规格说明书同时开发，软件测试规格说明书被用来验证软件需求规格说明书中所描述的功能要求，同时也作为对已完成软件进行测试的描述。

8

9.4.15 对需求的可追溯性，在安全系统得确认过程中应作为一个重要内容加以考虑。 在本标准中，对应特定的软件完善度等级，可追溯性特指： i） 对设计完成需求而进行的其他目标的需求的可追溯性。 ii） 对使设计目标实例化的执行目标的设计目标的可追溯性。

需求可追溯性的目标是证实所有的需求已被满足，并已说明没有那些对系统的安全或完善度有影响的不可追溯的材料。可追溯性过程的输出属于正式配置管理的问题。 10 软件体系结构 10.1 目标

10.1.1 该条款的另一个目标之一是开发一个软件体系结构，它完成与要求的软件完善度等级相对应的软件需求规格说明书的需求。

10.1.2 该条款的另一个目标是检查有系统结构安排在软件中的需求。

10.1.3 该条款的第三个目标是识别和评估以安全性为目的的硬件/软件协调的有效性。 10.1.4 该条款的第四个目标是为完善度测试做准备。 10.2 输入文档

1）软件需求规格说明书

2）软件安全性需求规格说明书 3）软件质量保证计划 10.3 输出文档

1）软件体系结构规格说明书 2）软件集成计划 10.4 要求

10.4.1 由软件提供者和/或开发者来建立建议性的软件体系结构，并在软件体系结构规格说明书中作详述。

10.4.2 软件体系结构规格说明书应考虑实现以要求的软件完善度等级为前提的软件需求规格说明书的可行性。

10.4.3 软件体系结构规格说明书应能识别、评估和评述所有硬件/软件协调的有效性。 10.4.4 软件体系结构规格说明书应能识别所有软件的成分，并对这些成分进行识别： i） 这些成分是否是新的，现存的或专用的；

ii） 这些成分以前是否已被确认。如果是，它们的确认条件是什么； iii） 每一成分是否是安全的或是非安全的。 ,,,,,,

10.4.5 使用标准软件应服从以下：

i） 对于软件完善度等级0，不需要进一步的预防措施即可使用标准软件； ii） 如果标准软件使用于软件完善度等级1或2，则它应经历软件确认过程； iv） 如果标准软件使用于软件完善度等级3或4，则应采取以下预防措施： a) 标准软件应经历软件确认过程； b) 应进行可能性失效分析； c) 应确定一个策略来检测标准软件的失效并保护系统避让这些失效； d) 保护策略应经过确认测试； e) 应评估提供者的差错纪录； f) 就实用性而言，仅使用标准软件的简单功能。

10.4.6 如果以前开发的软件将作为设计部分被使用，那么应有清楚的标识。应产生一个证明软件的适应性已满足软件需求规格说明书和软件完善度等级要求的单独报告。合适的软件是根据本标准开发的软件。必须特别注意任何软件变化对系统剩余部分的影响，它将决定是否需要再审查和再评估。例如，

9

如不再对所有模块进行在检验，再确认和再评估，则必须具有性证明。 10.4.7 在设计过程中可使用已有的、已验证过的，按本标准开发的软件模块； 10.4.8 软件体系结构应间少应用的安全性部分；

10.4.9 如果软件要实现不同软件完善度等级的功能，那么该软件的所有部分都应按最高软件完善度等级的要求处理； ……

10.4.10软件体系结构规格说明书应能识别按软件完善度等级要求进行软件开发、集成、验证、确认和维护的策略。软件体系结构规格说明书应按下列方式来表达和构造： i）清楚、精确、不含混，可验证、可测试、可维护以及可行； ii）对以下属性有清楚、精确的表达： ——功能性；

——各成分间的信息流向； ——排序和与时间有关的信息； ——并发；

——数据结构和特征； iii）人工智能； iv）验证和确认；

10.4.12 选择的设计方法应具有便于软件维护的特征。这些特征包括模块化、信息隐藏和压缩。 10.4.13 软件体系结构说明书应包括容错和避错软件设计策略，包括适当的冗余度和相异性。

10.4.14 软件体系结构说明书应证明在避错和容错软件设计策略的选择中所采取的平衡措施是正确的。 10.4.15 软件体系结构规格说明书应识别在软件生存周期的个阶段，为完成以所要求的软件完善度等级为前提的软件需求规格说明书所必须采取的技术措施。

10.4.16 软件体系结构规格说明书应证明所选的技术措施形成了一个集合，该集合满足以所要求的软件完善度等级为前提的软件需求规格说明书。 10.4.17 在设计过程中创建软件集成计划，以正确地指导集成活动和适合地把提供特殊设计或其它集成需求。在开发过程中，根据系统规模，可将软件集成计划再分成一系列子文件，并自然地加入使集成更清楚的详细需求。 11 软件设计和开发 11.1 目标

11.1.1该条款的目标是产生由软件需求规格说明书和软件体系结构说明书所确定的软件完善度的软件。

11.1.2 子目标：设计：该条款的一个子目标是设计、准备测试和完成实现需求的软件完善度等级的软件。该软件是可分析、可验证和可维护的。由于验证和测试在确认过程中起关键，所以在设计和开发的整个过程中应特殊考虑验证和测试要求，以确保一开始就使结果系统及其软件易于测试。

11.1.3 子目标：软件工程环境：该条款的另一个子目标是对应整个软件生存周期，为所要求的软件完善度等级选择一套包括语言和编译器的合适工具，它有助于验证、确认、评估和维护。 11.2 输入文档

1） 软件需求规格说明书 2） 软件体系结构规格说明书 3） 软件基层计划 4） 软件质量保证计划 11.3 输出文档

1） 软件设计规格说明

2） 软件设计测试规格说明书

10

3） 软件模块设计规格说明书 4） 软件模块测试规格说明书 5） 软件基层计划

6） 软件源代码和支持文档 7） 软件模块测试报告 8） 软件集成报告 11.4 要求

11.4.1 软件需求规格说明和软件体系结构规格说明应在涉及过程开始之前生效。

11.4.2 如果软件需求规格说明书包括安全性功能和非安全性功能，或者包括不同软件完善度等级的安全性功能，那么软件设计规格说明书应表明这些功能之间的性将怎样实现。在软件设计测试规格说明书和软件模块测试规格说明书。

11.4.5 每一软件模块都应是可读的、可理解的和可测试的。

11.4.6 在整个软件生存周期中，为了所要求的软件完善度等级，应选择一套适合的包括语言和编译的工具。

11.4.7 在实际应用中应使用自动测试工具和基层开发工具。

11.4.8 根据软件完善度等级的要求，所选程序设计语言应具有翻译器/编译器，而且该翻译器/编译器应有已经承认的国家/国际标准的“确认证书”或一个详细说明它能满足要求的评估报告。 11.4.9 所选语言应满足如下要求：

i） 所选语言应具有便于识别编成出错的特征； ii） 所选语言应支持与设计方法相适应的特征。 11.4.10 如果11.4.9条款不能满足，那么在软件体系结构规格说明中应记录对任何详述其自身能满足要求的语言的证明。

11.4.11 开发编码标准，并将其应用于所有软件的开发。编码标准应包含在软件质量保证计划中（参见条款16.4.5（vii））。

11.4.12 编码标准应指定好的编程惯例，排斥非安全语言特征并描述源代码文档的规程。源代码应含如下指定的信息……。 ——作者 ——配置情况 ——简要描述

——详述执行的功能

——调用信息：调用/被调用模块，运行时机，重入，递归，等等。 ——输入和输出

——数据字典：寄存器，变量，栈，堆，链表，等等。 ——中断，禁止，相互作用，副作用等。 ——出错处理

这里介绍了一种为包含指定信息而使用的标准形式。该标准形式应使用于同一程序的所有模块。为了生成一些功能上等价的软件，上述数据对于一名工程项目之外的专业程序员来讲是充分的。

11.4.13 软件集成是一个逐渐将个人和以前测试过的软件模块组合成一个合成整体（或一些合成子系统）的过程。其目的是在系统集成和测试之前能充分地证明模块接口和装配的软件。软件模块测试结果应记录在软件模块测试报告中。 11.4.14 软件集成和测试可在主体机、仿真目标机上进行补充的附加测试或者其它测试来建立软件集成和测试活动的有效性。

11.4.15 软件集成计划中应确定集成软件模块的方式。 11.4.16 软件集成计划应写明：

11

i） 集成等级的软件分割； ii） 测试案例和测试数据； iii） 要执行的测试类型；

iv） 测试环境、工具、配置和程序； v） 判断测试是否完成测试准则。

11.14.17 产生的软件集成报告应声明测试结果，以及是否满足软件集成设计的目标和准则。如果有失效，则要记录失效的原因。

11.14.18 软件基层报告应是一种可审查的形式。

11.14.19 记录测试案例及其结果。为了后续的分析，最好以机器可读的形式记录它们。 11.14.20 如果可行，测试应是可重复的和可自动完成的。

11.14.21 在软件集成期间，对软件的任何修改或变动都要进行影响研究。该研究应涉及所有被影响的模块，并作必要的重新验证活动。 12 软件验证 12.1 目标

该条款的目标是按照软件完善度等级的要求并评价某一给定阶段的产品，以确保在进入该阶段时所提供的产品和标准的正确性和相容性。 12.2 输入文档

1） 系统需求规格说明书

2） 系统安全性需求规格说明书 3） 软件需求规格说明书 4） 系统需求测试规格说明书 5） 系统体系结构规格说明书 6） 系统设计规格说明书 7） 系统设计测试规格说明书 8） 系统模块设计规格说明书 9） 系统模块测试规格说明书 10） 软件源码和支持文档 11） 软件质量保证计划 12.3 输出文档

1） 软件验证计划 2） 软件需求验证报告 3） 软件设计验证报告 4） 软件模块验证报告 5） 软件源码验证报告 6） 软件模块测试报告 7） 软件集成报告

8） 软件/硬件基层报告 12.4 要求

12.4.1 为了对验证活动作正确的指导并提供相应的特殊设计和其它验证需要，应建立软件验证计划。在开发阶段（根据系统的规模），计划可被分成一系列子文件。而且，为了使验证说明变得清晰，子文件数可相应增加。

12.4.2 软件验证计划应用文件证明……。

12.4.3 软件验证计划应描述所要执行的活动，以确保当进入到那个阶段时所提供的产品和标准的正确性和相容性。

12

12.4.4软件验证计划应提供：

i） 验证策略和技术的选择。为避免对验证和测试活动的评估过分复杂化，应优先考虑对测试案例和方法等选择， 这些案例和方法自身是可分析的。如：大量的小（易分析的）测试案例显然比少量非常/比较复杂的测试实例要好。

ii） 软件测试设备的选择和使用； iii） 验证活动的选择和文档； iv） 队获得的验证结果的评估； v） 可靠性要求的评估； vi） 测试过程所涉及的人的职责和要求达到的测试覆盖度。

12.4.5 每一开发阶段都应表示出满足功能要求、可靠性要求、性能要求和安全性要求。 12.4.6 验证应由软件完善度等级所要求的团体来执行。

12.4.7 正式验证之前由设计者进行的非正式验证不应作为正式验证。

12.4.8 验证的每一结果应以软件验证计划中规定的或建议的形式来保存，以便审计。 12.4.9 在每一验证活动之后应产生一份说明软件已通过验证或失败原因的验证报告。验证报告应指出： i） 不符合软件需求规格说明书，软件设计规格说明书或软件模块规格说明书的条款。 ii） 不符合软件质量保证计划的条款。 12.4.10 软件需求验证：一旦建立了软件需求规格说明书，在下一阶段——软件设计开始之前该验证应表明：

i） 软件需求规格说明书在安全性、功能性、可靠性、性能和其它要求方面充分满足系统需求规格说明书和系统安全性需求规格说明书中列出的各项要求，并且在安全性方面充分满足软件质量保证计划书中列出的各项要求，并且在安全性方面充分满足软件质量保证计划书中列出的要求。 ii） 软件需求测试规格说明书作为对软件需求规格说明书的测试是充分的。 还应检查以下的不可兼容性：

iii） 软件需求规格说明书和系统安全性需求规格说明书； iv） 软件需求规格说明书和软件需求测试规格说明书； 结果纪录在软件需求报告中。

12.4.11 软件体系结构和设计验证：在建立软件体系结构规格说明书和软件设计规格说明书之后，并在下一阶段——软件模块设计开始之前，该验证应表明：

i） 软件体系结构规格说明书和软件设计规格说明书充分满足软件需求规格说明书； ii） 软件设计规格说明书作为软件设计测试规格说明书的一组测试案例是充分的； iii） 在相容性和完成性递减方面，软件设计规格说明书充分满足软件需求规格说明书，这一满足性

包括模块级。

还应检查以下的不可兼容性：

iv） 软件体系结构规格说明书，软件设计规格说明书和软件需求规格说明书； v） 软件设计规格说明书和软件设计测试规格说明书； vi） 软件测试规格说明书和软件需求测试规格说明书。 结果纪录在软件设计验证报告中。

12.4.12 软件模块验证：在建立各软件模块设计规格说明书后，并在编码之前，该验证应表明： i） 软件模块设计规格说明书充分满足软件设计规格说明书；

ii） 软件模块测试规格说明书作为软件模块设计规格说明书的一组测试案例是充分的； iii） 软件设计规格说明书将如下内容分解到软件模块和软件模块设计规格说明书中： ——要求性能的可行性； ——进一步验证的可测试性；

——对于开发和验证群体的可读性；

13

——对允许进一步改进的可维护性。 此外还应检查如下的不可兼容性：

iv） 模块设计规格说明书和软件设计规格说明书； v） 软件设计规格说明书和软件模块测试规格说明书； vi） 软件模块测试说明书和软件设计测试规格说明书； 结果记录在软件模块验证报告中。 12.4.13 代码验证：按照软件完善度等级的要求应验证软件园代码已确保软件模块设计规格说明书和软件质量保证计划的一致性。 12.4.14 软件模块测试：每一模块都应有一份测试该模块的软件模块测试规格说明书。这些测试应表明每一模块将完成其预定的功能。 结果记录在软件代码验证报告中。 12.4.15 软件基层测试：作为将所有模块集成为软件系统的一个部分，软件将按软件设计测试规格说明书来进行测试。这些测试应表明每一模块将完成其预定的功能。 结果记录在软件集成报告中。 12.4.16 软件需求测试：在软件系统已满足软件大设计测试规格说明书之后，应依据软件需求测试规格说明书对其进行测试。这些测试应表明所有软件需求规格说明书中的需求已被正确完成。 12.4.17 测试案例及其结果应作纪录，为了后续分析，最好用机器可读形式。 13 软件/硬件集成 13.1 目标

13.1.1 该系统的目标是证明软件和硬件间相作用，正确地完成它们的预定功能。

13.1.2 该系统的另一个目标是组合软件与硬件，确保它们的相容性，以满足安全性系统的要求规格说明书和预期的软件完善度等级要求。 13.2 输入文档

1） 系统要求规格说明书； 2） 系统安全性要求规格说明书 3） 系统体系结构描述 4） 软件需求规格说明书 5） 软件需求测试规格说明书 6） 软件体系结构规格说明书 7） 软件设计规格说明书 8） 软件设计测试规格说明书 9） 软件模块设计规格说明书 10） 软件模块测试规格说明书 11） 软件源代码和支持文档 12） 硬件文档 13.3 输出文档

1） 软件/硬件集成计划 2） 软件/硬件集成报告 13.4 要求

13.4.1 为了正确地指导集成活动和适合地提供特殊设计或其它集成需求，当在开发生存周期的早期建立软件/硬件集成计划中，可将计划分解成许多子文件。而且为了使软件和硬件的设计衍生以集成的详细细节需要变得清楚，子文件数可以相应增加。

13.4.2 软件/硬件集成计划应对如下内容作文字说明： i） 将系统分割成集成等级；

14

ii） 测试案例和测试数据； iii）…… iv） 测试环境，包括工具、支持软件和配置描述； v） 测试准则，依此来判断测试完成。

13.4.3 软件/硬件集成计划应能区分开发者以自己为前提进行的活动和按用户要求进行的活动。 13.4.4 软件/硬件集成计划应区分以下活动： i） 合并软件系统之目标硬件； ii） 系统集成；

13.4.5 应在可使用的第一时间获得软件/硬件集成计划指定的工具和设施。

13.4.6 在软件/硬件集成过程中，对已集成系统的任何修改或变更均应服从一个影响研究，该影响研究应涉及所有受影响的模块并作必要的验证活动。

13.4.7 纪录测试实例及其结果，为了后续分析，最好用机器可读形式记录。

13.4.8 建立软件/硬件集成报告，说明测试结果以及是否满足软件/硬件集成计划的目的和准则。如果失效，记录失效的原因。

13.4.9 软件/硬件集成报告应以软件/硬件集成计划规定或建议的形式编写，以便审计。 14 软件确认 14.1 目标

14.1.1 确认的目的是证明按软件完善度等级，系统在功能和安全性等诸方面均是可接受。根据软件完善度等级，该证明应提供给安全性权利机构。 14.2 输入文档

1） 系统需求规格说明书 2） 所有硬件和软件文档 14.3 输出文档

1） 软件确认计划 2） 软件确认报告 14.4 要求

14.4.1 测试是主要的确认活动

14.4.2 可用仿真和建模来支持确认过程。

14.4.3 在适当的文件中建立并详述软件确认计划。

14.4.4 根据软件完善度等级，应有部门来开发、执行和结果评估。

14.4.5 如果软件完善度等级有要求，软件确认计划的范围和内容可与评估人员或代理评估人员的团体达成协议。但协议中应声明测试过程中评估人员因在场。

14.4.6 软件确认计划应对每一项所测试案例要求的功能加入说明 i） 在顺序和电平值上要求的输入信号； ii） 在顺序和电平值上有期望的输出信号； iii） 验收准则，包括完成和质量等方面。

14.4.7 软件确认计划应包括一个证明所选确认策略正确的概率说明，根据所要求的软件完善度等级，证明应考虑：

i） 人为的、自动的、或两者均有的技术； ii） ……

14.4.10 用可审查的形式，将确认结果记录在软件确认报告中。 14.4.11 软件确认报告应声明软件已通过确认或失败的原因。 14.4.12 软件确认报告应说明： i） 使用的硬件和软件；

15

ii） 使用的设备； iii） 设备的校准； iv） 使用的仿真模型； v） 发现的分歧； vi） 执行的矫正操作。

14.4.13 软件提供者和/或开发者应使软件确认报告和所有相关文件对系统开发是有用的，从而使系统开发者能满足EN50129的要求。 15 软件评估 15.1 目标

15.1.1 该条款的目标是评估生存周期过程和结果产品是具有规定软件完善度等级和适用于预期应用的软件。

15.2 输入文档

1） 系统安全性需求规格说明书 2） 软件确认计划

3） 所有的软件和硬件文档 15.3 输出文档

1） 软件评估报告 15.4 要求

15.4.1 对软件完善度等级0，评估员只要证实这是一响应的软件完善度等级。

15.4.2 对所有出自另一评估员的软件评估报告的软件不必作新的评估，但第二位评估员要检查软件具有要求的软件完善度等级并且适合预期的应用。

15.4.3 评估员将评估设计和开发组以及所有与文档有关的工程项目。

15.4.4 按照软件完善度等级的要求，软件评估应由于设计组的评估员来完成。

15.4.5 评估员将评估系统软件符合预期的目的，并服从系统安全性需求规格说明书的安全性要求。 15.4.6 按照软件完善度等级的要求，评估员将决定是否选择了合适的方法并将其运用于软件生存周期的各个阶段。

15.4.7 如果软件完善度等级有要求，评估员将决定是否选择了合适的方法并将其运用于软件生存周期的各个阶段。

15.4.8 评估员可以要求进行附加的验证和确认工作，如果它这样选择的话。 15.4.9 评估员将对每一个被审查的……产生一份报告。 15.4.10 按评估员的观点，如果软件能适合预期的应用，最终的软件评估报告应包括一个关于软件所达到的软件完善度等级的声明。

15.4.11 若软件不适合预期的或未达到要求的软件完善度等级，那么评估员应在软件评估报告中给出一个关于失败原因及其要求矫正操作的见解。 16 软件质量保证 16.1 目标

16.1.1 该条款的目标之一是识别、监视和控制所有保证软件达到要求质量性能所必须采取的技术和管理活动。

16.1.2 该条款的另一目的标是提供证据来证明以上活动已被完成。 16.2 输入文档

1） 软件质量保证计划 2） 软件开发计划 3） 软件安全性计划 4） 软件配置管理计划

16

5） 软件维护计划

所有这些计划均在项目开始时公布，并在生存周期过程中修改。 16.4 要求

16.4.1 提供者和开发者应拥有和使用至少一个顺应EN29000系列的质量保证系统，以支持该欧洲标准的要求，建立最好用EN29001认定的系统。 16.4.2 根据EN29000——31993的方针，提供者和/或开发者为软件开发至少应执行EN29001的相关部分，这一要求是强制执行的。 16.4.3 当项目一个接一个时，提供者和/或开发者应准备并用文档说明软件质量保证计划以完成本欧洲标准条款16.4.1和16.4.2的要求，并在适当的地方以可测量形式表达出来。

16.4.4 软件质量保证计划应有一段文字来叙述在整个工程项目中，其自身修改的细节：频度、责任、方法。

16.4.5 EN29000——3：1993和本欧洲标准（包括附件A）的所有章节中所要求的活动，操作和文件等均应在软件质量保证计划中说明或标识，并编制成具体的开发。EN29000——3：1993中没有一张表格被认为是穷举的。

除软件完善度等级0外，在软件质量保证计划中（现在的表格没被认为是穷举的）至少应说明或标识以下条款：

i） 软件安全性计划； ii） 生存周期模式定义 各阶段的定义包括： ——活动和基本任务； ——进入和退出准则；

——各阶段的输入和输出； ——各阶段的主要质量活动；

——对每一活动和基本任务负有责任的组织部门 iii） 要求跟踪能力；

iv） 文档结构跟踪能力； v） 与软件开发、验证、确认、操作和维护有关的文档。 vi） 系统集成规程； vii） 使用的编码标准；

viii） 对预前确认测试的评估；

ix） 用于产品和过程度量（定义测量）的定义。为了实现软件产品度量，应参照ISO/IEC9126定义

的质量特征和评估方针。

16.4.6 根据EN29000——3：1993中的方针。至少应实行配置管理，这一要求是强制执行的。

在第一个认可版本发布之前，各软件文档应配置控制的支配。在文档模块测试开始之前，软件源代码应受配置控制的支配。

……配置管理不应局限于严格的产品开发和维护，它因应覆盖整个声明周期中使用的环境。这一对开发的在现维护活动所必须的扩充应包括汇编器，编评器，调试器以及所有其它所用到的工具。 16.4.7 应检查软件验证计划的充分性和结果。

16.4.8 提供者和、或开发者应建立书写和维护有关提供员控制的规程，其中包括：

——确保外部提供者提供的软件遵守已建立的需求的方法。以前开发的软件应保证符合的软件完善度等级和可信性。新的软件应按自己的软件质量保证计划或根据前续的软件质量保证计划有外部提供者提供的。特殊的软件质量保证计划来开发和维护。

——确保软件提供者提供的需求是充分的而且完备的方法。

16.4.9 提供者和或开发者应建立，书写并维护有关问题报告及修正行为的规程。这些规程作为质量保

17

证系统的一部分，应完成EN29001的相关部分，特别少量应覆盖以下几个方面： ——为了反馈给响应管理，规定问题报告和或修正行为所需的文档。 ——规定对收集在问题报告中的信息所作的分析，以判断出其原因。

——规程报告、跟踪和解决在开发阶段记过软件维护中判定的问题的实施，

——规定为达到与所要求的软件完善度等级相对应的等级而处理问题的预防性行为。 ——规定有关开发和与所要求的特殊组织的责职。 ……

——规定怎样实施控制，以确信修正行为已被采取并有效。 ——规定将使用的形式。

在紧接软件集成之后，在正式的软件确认开始之前的软件生存周期中。至少应实施问题报告和修正行为管理。 17 软件维护 17.1 目标

该条款的目标是保证软件按要求执行，并在对软件自身作修正，功能增强和适应性工作时软件完善性等级和可信性。 17.2 输入文档

1） 软件维护计划 2） 所有其它文件 17.3 输出文档

1） 软件维护记录 2） 软件维护日志 17.4 要求

17.4.1 根据EN29000-3：1993中的方针，至少应进行维护工作，这是强制性的。 告警：EN29000-3：1993定义为“维护记录”，在本欧洲标准中定义为“日志”。EN对“维护记录”有不同的定义，这些定义与EN29000-3：1993中的无关。 此外，还应该满足以下软件维护的需求。

17.4.2 应建立软件维护规程，并记录在软件维护记录中。这些规程应包括： i） 对差错报告，差错日志，维护日志，更改特权和软件、系统配置的控制； ii） 验证、确认和评估。 iii）

规定可认可可更改软件的权威机构。

17.4.3.应对每一维护活动建立软件维护记录，该记录包括： i） 修改或变更要求；

ii） 维护活动对整个系统影响的分析。包括软件，硬件，人为作用以及环境和可能的作用。除软件完善度等级0以外，按照“安全性过程概述”和安全性过程条款“系统转换”中的EN50126——所预见的维护规程进行的分析。 iii） iv）

详细的修改或变更的规格说明；

按所要求的软件完善度等级要求对修改或变更的再确认和回归测试。再确认的职责可根据软件完善度等级，随项目的不同而不同。修改或变更对再确认过程的影响也可在不同的系统等级（仅作变更的模块，所有标识出受影响的模块，整个系统）。因此，软件确认计划应根据软件完善度等级说明这两方面的问题。再确认的性程度应与确认时的性程度一样。

17.4.4 使用与系统初始开发时相同的专门技术水平，工具，文档，计划和管理进行维护。这同样适用于配置管理变更控制，文件控制和有关部门的性。

17.4.5 可维护性尤其要按本欧洲标准的第11条款的要求设计到软件系统中。为了要求和校验可维护性的最低等级还可使用ISO、IEC9126。

18

17.4.6 按软件质量保证计划中规定的时间间隔，定期按软件维护计划审查维护活动。

17.4.7 在软件条款首次发表之前对每一条条款建立软件维护日志并进行维护。除EN29000——3：1993 关于“维护记录和报告”的5.10.6节的要求外，该记录还应包括： i） 为那项软件条款查阅所有的软件维护记录 ii） 更改结论信息…… iii）

……

17.4.8 提供者控制，问题报告和修正行为应按软件质量保证条款中的有关段落指定的同一准则来管理。 18 由应用数据配置的系统 18.1 目标

18.1.1 铁路控制和防护系统的一个显著特征这需将每一装置都设计得能满足特殊应用的独特需要。由应用数据配置的系统应允许使用认可类型的通用软件，这类软件对于每个被定义为数据的装置都具有独特的要求。这数据一般采取列表信形式或采用由通用软件解释的应用性特殊语言。

18.1.2 对于一个安全性关键系统为使系统能实现所要求的软件完善度需要高级的资源，进而，可采用应用数据配置的系统，因为他允许通用软件的复使用。但是体统夫人安全运行可能要依赖于数据的正确性，因而用于开发数据的这些规程也必须具有相同的系统完善的等级。

18.1.3 以下部分描述了该欧洲标准有关由应用数据配置的系统的通用软件的初始开发和各组具体装置数据的后续开发的需求。 18.2 输入文档

1） 软件需求规格说明书 2） 软件体系结构规格说明 18.3 输出文档 1） 装置需求定义 2） 数据准备计划 3） 数据测试计划 4） 数据测试报告 18.4 要求

18.4.1 数据准备生存周期

图6描述了使用硬件、通用软件和具体装置生存周期。生存周期的各阶段如下所述： 18.4.1.1 装置需求定义

对装置的要求加以定义。需求应包括单个装置的具体要求（如股道布局、信号位置，速度）和装置必须遵守的标准（如信号发送原则，系统完善度等级）。 18.4.1.2 整体装置设计

对系统体系结构加以定义，对使用的通用元件的数量和类型加以说明。这些元件，包括软件在内，应是根据本欧洲标准开发的。需求中指定的功能应分配到各元件，并对各元件位置加以表识。 18.4.1.3 数据准备

数据准备活动应于硬件的设计、采购、制造、装配同时进行。数据准备过程包括产生规格说明质量（如控制）产生数据源代码及其编译、检查、其它验证活动以及应用数据的测试。 18.4.1.4 集成和验收

对有些系统，在现地安装之前应用数据将同通用硬件、软件集成在一起在厂内试验。若通过其它方法可获得足够的可信度的话，可不进行该项试验。随后现地安装设备，并对新设备进行集成测试和验收测试。最后系统作为整体运行系统进行交工试运转，并对整个装置进行最后的一系列测试。 18.4.1.5 确认和评估

确认和评估活动是对生存周期各阶段的执行情况进行审查。 18.4.2 数据准备规程和工具

19

对于由应用数据装配的各种新型系统，应开发具体的数据准备规程和工具，以便允许将18.4.1中指定的数据准备生存周期运用于新系统的装置中。这些规程和工具的开发应于系统通用软件和硬件同时进行。

18.4.2.1 在由应用数据配置的系统软件开发的整个系统设计阶段，应产生一个数据准备计划，以便为数据准备过程定义一个文档结构。这些文档结构与18.4.1中描述的数据准备生存周期计划模型有关计划中要定为满足要求的系统完善度等级而使用的数据准备规程和工具。

18.4.2.2数据准备计划应给数据准备生存周期中使用的任何硬件或软件工具分配——完善度等级。该完善度等级应来源于对数据所要求的完善度等级，以及由认为或自动规程来检查每种工具的输出程度。这些工具应按本欧洲标准开发，并与通用软件同时开发。验证、确认和评估活动是保证数据准备工具与通用软件兼容。

18.4.2.3 数据准备计划应在可能的地方要求标记指定的需求和设计，这些要求和设计应用工程师们所熟悉的如标准信号计划和控制表。在引入新标记的地方，必须提供必要的用户文档。

18.4.2.4 用来证明数据准备已按计划完成所需的验证、测试、确认和评估报告可标准化成检验表形式，以便减少为各装置生产文档的工作量。

18.4.2.5 所有数据和有关文档应服从本标准第16节中的配置管理要求。配置管理纪录要列出将数据设计或运行所依赖的通用软件的版过程的工具版本的工具版本号。 18.4.3 软件开发

用于由应用数据配置的系统的通用软件的开发，应遵循本标准1——17部分的要求。同时还应遵守以下附加的要求。

18.4.3.1 在软件要求规格说明阶段，应说明在每个系统和子系统中利用数据的哪些功能。……

18.4.3.2 在软件体系结构阶段应说明通用软件和应用软件数据之间的详细接口，除非这已在本生存周期的前一阶段中说过，例如要求使用一种现存应用的具体语言的结果。

18.4.3.3 在软件设计和开发阶段，程序源代码和数据存储区域之间必须实行严格的分离，即除非已对软件和数据之间的接口作了变动，否则可能需要重新编辑和修改通用软件或数据而不必修改它。

18.4.3.4 在软件维护阶段，变更控制必须确保只有在确定被修订的软件与原来的数据兼容或对作必要的修订后，才能对通用软件作任何修改。

18.4.3.5 在软件验证和软件确认阶段，以确保对所有的数据相关结合的考虑。

20

危险事件频率 增 加 频 率 危险时间序列 增 加 序 列 受控的设备 风险水平： 无保护特性 要求的风险减小 系统的 单独 系统中的 总体结 系统 总体软件 构 4 4 4 3 3 3 2 2 2 1 1 1 0 0 0 安全性完善度等级 4——很高 3——高 2——中等 1——低 0——非安全性

图1 安全性系统得完善度等级

21

获得系统需求规格说明书、系统安全性需求规格说明书和关于系统的安全性分析文档 识别所有标定在软件中的安全性功能 检查所有标定在软件中的安全性功能，并决定该软件的整体水平 产生软件需求和软件结构规格说明书 根据软件质量保证计划、软件整体水平和软件生存周期设计、开发、验证/测试软件 完成软件审批并移交给系统工程师 系统运行 软件维护 图2 软件安全性流程图 22

设计文档 验证 周期

系统需求规格说明书 系统安全性需求规格说明书 系统结构描述 系统验证 软件需求测试规格说明软件需求规格说明书 系统开发阶段 软件需求阶段 软件结构规格说明书 软件结构验证 软件测试规格说明书 软件设计规格说明书 软件设计验证 软件模块测试说明书 软件模块设计说明书 软件模块设计阶段 软件设计阶段 软件模块验证 软件源代码及支持文档 编码阶段 编码验证 软件模块测试报告 软件拼装报告 软件测试阶段 软件/硬件拼装报告 软件审批 系统拼装及测试文档 系统审批 系统安装文档 软/硬件拼装阶段 软件审批阶段 系统拼装阶段 系统审批阶段 系统维护文档 工地支持阶段

23

系统需求规格说明书 图3 开发生存周期 r

系统安全性需求规格说明书 系统结构说明 软件需求规格说明书阶段 软件需求规格说明书 软件需求测试规格说明书 软件需求验证报告 软件维护阶段 软件修改纪录 软件维护纪录 软件评估阶段 软件评估报告 软件规格阶段 软件开发阶段 软件质量保证计划 软件结构管理计划 软件验证计划 软件拼装计划 软/硬件拼装计划 软件审批计划 软件维护计划 u

软件审批阶段 软件审批报告 软/硬件拼装阶段 软件爱女设计阶段 软/硬件拼装报告 软件结构规格说明书 软件设计规格说明书 软件设计测试规格说明书 软件测试阶段 软件拼装规格说明书 软件设计验证报告 软件拼装报告 软件模块设计阶段 软件模块设计规格说明书 软件模块设计规格说明书 软件模块验证报告 软件模块测试报告 编码阶段 软件源代码和支持文档 软件源代码验证报告 图4 开发生存周期 24

等级0 DL，VER，VAL ASS’R 等级1和2 DI VER，VAL ASS’R PRJ MGR 等级3和4 ASS’R DI VER，VAL 或 PRJ MGR 等级3和4 DI VER VAL 注： = 可以是同一人 = 可以是同一公司 DI = 设计者/实现者 VER = 验证者 VAL = 审批者 ASS’R = 评估者 PRJMGR = 项目管理者

图5 于软件完善度等级

25

一般系统设计和开发 需求规格说明书 验证 系统设计 系 工 统 厂 审 验证 审 批 批 和 实现 和 证 证 书 验证 书 系统拼装 验证 系统认可

图6 一般系统开发和应用开发间的相互关系

工厂应用工程 工厂规格说明书 安装设计 生产 安装测试 验收和经费使用 26

附件A （标准的） 选择技术措施的准则

本欧洲标准的条款8至条款17都有一个说明实现性能方法的相应条款表，在那里有一些低等级的表，即用来需哦名条款表中某些人口的详细说明数据。如条款9表中的半正式在详细说明表D.8中说明。

对于表中的各项技术或措施，针对每一软件完善度等级（IL），从1到4以及非安全性等级0都有一个需求。在本文件版本中，对于等级1和2在每项技术需求上是相同的，相似的，对于等级3和4，在每项技术上具有同样的需求。这些需求可以是：

“M” 该符号表示强制使用的技术

“HR” 该符号表示对于本安全性完善度等级是优先技术或措施。如果不采用该项技术或措施，那么后面不用到它的那些基本原理应在软件质量保证计划中详述。

“R” 该符号表示对于本安全性完善度等级而推荐的技术或措施。这是比“HR”等级低的推荐，这些技术可以合作在一起，以形成一个包。

“-” 该符号表示不推荐使用的技术或措施。

“NR” 该符号表示对于本安全性完善度等级明确不予推荐的技术或措施。如果使用了该项技术或措施，那么后面不用到它的基本原理应在软件质量保证计划中详述。 “F” 该符号表示禁止使用该项技术。

在软件质量保证计划中应对技术或措施组中被选定的一项或多项技术或措施加以说明，除非附在表上的注释作了其它要求。这些注解可包括参考认可的技术或认可的技术组。如果使用了这样的技术或技术组，评估者应在确认时认可它们。……

27

条款表

对于各种完善度等级，以条款的方式对各项技术或措施进行比较 条款8：生存周期专辑和文档 文档 1.软件规划文件 2.软件需求文件 3.软件设计文件 4.软件模块文件 5.源代码和文档 6.软件测试报告 7.软件和硬件测试报告 8.软件确认报告 9.软件评估报告 10.软件维护报告 注：

1. 针对所要求的完善度等级而产生的所有文档 条款9：软件需求说明书 技术措施 1. 正规方法，包括如CCS，CSP，HOL， LOTOS，OBJ，时序逻辑，VDM和Z 2．半正规方法 3．结构化的方法学包括如JSD，MASCOT， SADT，SDL，SSADM和Yourdon 注：

1． 软件需求规格说明书通常要求用自然语言和任何与应用相对的必要的数学表示法对问题进行描述。 2． 这表与清楚地和精确地定义该规格说明书的附加需求有关。为满足正在使用的完善度登记应选择这些技术

之中的一项或多项。

28

IL0 R R - - R - - R - R IL1 HR HR HR R HR HR HR HR HR HR IL2 HR HR HR R HR HR HR HR HR HR IL3 HR HR HR HR HR HR HR HR HR HR IL4 HR HR HR HR HR HR HR HR HR HR 参考 B．30 B．8 B．60 IL0 - R R IL1 R R HR IL2 R R HR IL3 HR HR HR IL4 HR HR HR 条款10：软件体系结构

技术/措施 参考 IL0 IL1 IL2 IL3 IL4 1．防御性的结构设计 B．15 - R R M M 2．故障检测和诊断 B．27 - R R HR HR 3．纠错码 B．20 - NR NR HR HR 4．检错码 B．20 - R R HR HR 5．失效断言程序设计 B．25 - R R HR HR 6．安全袋技术 B． - R R R R 7．不同版本的程序设计 B．17 - R R HR HR 8．恢复块 B．50 - R R R R 9．逆向恢复 B．5 - NR NR NR NR 10．前向恢复 B．32 - NR NR NR NR 11．重试故障恢复机器 B．53 - R R R R 12．存储运行情况 B．39 - R R HR HR 13．人工智能——纠错 B．1 - NR NR NR NR 14．动态重构 B．18 - NR NR NR NR 注：

1． 完善度等级3和4认可的技术组合如下：

a） 1，7和4，5或12三者之一； b） 1，4和5； c） 1，4和12；

2． 除3，9，10，13和14项外，选择上述这些技术中的一项获多项以满足完善度等级2的需求。 3． 本专辑中的一部分内容可在系统级定义。

29

条款11：软件设计和开发 技术/措施 1． 正规方法，包括如CCS，CSP，HOL， LOTOS，OBJ，时序逻辑，VDM和Z 2．半正规方法 3．结构化的方法学包括如JSD，MASCOT， SADT，SDL，SSADM，和Yourdon 4．模块化方法 5．设计和编码标准 6．可分析程序 7．强类型程序设计语言 8．结构化程序设计 9．程序设计语言 10．语言子集 11．已确认的翻译器 12．在使用中验证的翻译器 13．可信/已验证的模块和元件库 14．功能和黑箱测试 15．性能测试 16．借口测试 17．数据记录和分析 18．模糊逻辑 19．面向对象的程序设计 注：

1． 按照软件完善度等级选择一组合适的技术。

2． 对于完善度等级3或4，一套认可的技术应包括技术1，2或3中之一和技术11或12中之一。余下的技术

按其推荐来对待。

条款12：验证 技术/措施 1．正式证据 2．可能性检测 3．静态分析 4．动态分析和测试 5．度量 6．跟踪能力矩阵 注：

1． 对完善度等级3或4的软件，其认可的技术组合是： a）1和4 b）3和4

2．对完善度等级1或2的软件，其认可的技术是1或4。

Ref B.31 B.47 D.9 D.2 B.42 B.69 IL0 - - R R R R IL1 R R HR HR R R IL2 R R HR HR R R IL3 HR HR HR HR R HR IL4 HR HR HR HR R HR D.10 D.1 B.2 B.57 B.61 D.5 B.38 B.7 B.65 B.40 D.3 D.7 B.37 B.13 B.67 HR R R R R R - R HR R HR - - HR R R M HR HR HR HR HR - HR HR R HR HR HR HR R M HR HR HR HR HR - HR HR R HR HR HR HR R M M HR HR HR HR HR HR HR R HR HR HR M R M M HR HR HR HR HR HR HR R HR HR HR M R D.8 B.60 R R HR HR HR HR HR HR HR HR Ref. B.30 IL0 - IL1 R IL2 R IL3 HR IL4 HR 30

条款 13：软件/硬件集成

技术/措施 Ref IL0 IL1 IL2 IL3 IL4 1．功能和黑箱测试 D．3 HR HR HR HR HR 2．性能测试 D．7 - R R HR HR 注：

1． 对完善度等级0的软件，技术1是认可的。

2． 对完善度等级1，2，3或4的软件，许可的技术组合是1和2。 条款14：软件确认 技术/措施 Ref IL0 IL1 IL2 IL3 IL4 1．可能性测试 B．47 - R R HR HR 2．性能测试 D．7 - R R HR HR 3．功能和黑箱测试 D．3 HR HR HR HR HR 注：

1． 对完善度等级1，2，3或4的软件，认可的技术组合是2和3。 条款15：软件评估

第1部分——被评估的条款 被评估的条款 条款 IL0 IL1 IL2 IL3 IL4 1．软件安全性完善度等级 6 HR HR HR HR HR 2．职员和责任 7 - R R HR HR 3．生存周期和文档 8 - HR HR HR HR 4．软件需求规格说明 9 R HR HR HR HR 5．软件体系结构 10 - R R HR HR 6．软件和开发 11 - R R HR HR 7．验证 12 - HR HR HR HR 8．软件/硬件集成 13 - R R HR HR 9．软件确认 14 - HR HR HR HR 10．质量保证 16 - R R HR HR 11．维护 17 - HR HR HR HR

31

第2部分——评估技术

评估技术 1．校验表 2．静态软件分析 Ref B.8 B.14 B.42 D.9 3．动态软件分析 4．因果树 5．事件树分析 6．故障树分析 7．软件出错影响分析 8．普通原因失效分析 9．马尔可夫模型 10．可靠性框图 11．试运转前的场地使用 注：

1． 为满足正在使用的完善度等级，选择这些技术中的一项或多项。 条款16：软件质量保证 技术/措施 1．对EN29001的鉴定 2．顺应ISO9000-3 3．伴随质量系统 4．软件配置管理 条款或Ref 16 16 B.56 IL0 R M M M IL1 HR M M M IL2 HR M M M IL3 HR M M M IL4 HR M M M D2 D3 B.6 B.23 B.28 B.26 B.10 B.41 B.51 - R - R - - - - R R R R R R R R HR R R R R R R R HR R R HR HR HR R R HR R R HR HR HR R R HR - R R HR HR IL0 R R IL1 R HR IL2 R HR IL3 R HR IL4 R HR 注：对于要求的安全性完善度等级应使用所有的措施。 条款17：软件维护 技术/措施 1．影响分析 2．记录数据分析 注：

1． 对于要求的安全性完善度等级应使用所有的措施。

32

Ref B.35 B.13 IL0 R HR IL1 HR HR IL2 HR HR IL3 M M IL4 M M 详细表格

D．1 设计和编码标准 供条款11参考 技术/措施 1．编码标准存在 2．编码风格指示 3．无动态对象 4．无动态变量 5．指针的使用 6．递归的使用 7．无条件转移 注：

1． 关于这些技术的信息参看“设计和编码标准”目录，B16条目。 2． 可将技术3和4作为认可的编译器的一部分。 D．2动态分析和测试 供条款12参考 技术/措施 1．按边界值分析运行的测试案例 2．按出错猜测运行的测试案例 3．按出错查找运行的测试案例 4．性能建模 5．等价分类和输入分割测试 6．基于结构的测试 注：

1． 作为测试案例的分析是属于系统等级的，并且是建立在规格说明书基础上和/或规格说明书及代码基础上的。 2． 根据软件完善度等级选择一组合适的技术。 D．3功能/黑箱测试 供条款11、13和14参考 技术/措施 1．按因果图运行的测试案例 2．样机制作/运行 3．边界值分析 4．等价分类和输入分类 5．过程仿真 注：

1． 测试案例分析属软件系统级，且仅以规格说明书为基础。 2． 仿真的完备性依赖于完善度等级的程度，复杂性和应用。 3． 按软件完善度等级选择一组合适的技术。

33

Ref B.16 B.16 B.16 B.16 B.16 B.16 B.16 IL0 HR HR - - - - - IL1 HR HR R R R R HR IL2 HR HR R R R R HR IL3 HR HR HR HR R HR HR IL4 HR HR HR HR R HR HR Ref B.4 B.21 B.22 B.45 B.19 B.58 IL0 R R -- -- R R IL1 HR R R R R R IL2 HR R R R R R IL3 HR R R HR HR HR IL4 HR R R HR HR HR Ref B.5 B.49 B.4 B.19 B.48 IL0 NR NR R R R IL1 - - HR HR R IL2 - - HR HR R IL3 R R HR HR R IL4 R R HR HR R D．5程序设计语言 供条款11参考 技术/措施 1．ADA 2．MODULA-2 3．PASCAL 4．Fortren77 5．“C” 6．PL/M 7．BASIC 8．汇编 9．梯形图 10．功能程序块 11．描述表 12．具有编码标准的C子集 注：

1． 对完善度等级3和4，在使用语言1，2，3，4的子集时推荐改为HR。

2． 对某些特定的应用，仅有语句5，6，7，8，9，10，11有效，对于完善度等级3和4，在优先推荐选择无效

的地方，为把推荐上升至“R”，强烈建议应配备这些语言的一个子集和一组精确的棉麻标准。 3． 关于评估编程语言适合性的信息，请参看“合适的程序设计语言”目录，B.62题目中的条目。 4． 如果某一具体语言在这表中没有，那么不能自动地将其排除在外，它应符合B,62。 D．6建模 供条款14参考 技术/措施 1．数据流图 2．有限状态机 3．正规方法 4．性能建模 5．时间Petri网 6．样机制作 7．结构图 注：

1． 按软件完善度等级选择一组合适的技术。 D．7性能测试 供条款 11和13参考 技术/措施 1．雪崩/加强测试 2．响应时序和存储约束 3．性能需求

Ref B．3 B．32 B．46 IL0 - HR HR IL1 R HR HR IL2 R HR HR IL3 HR HR HR IL4 HR HR HR Ref B.12 B.29 B.30 B.45 B. B.49 B.59 IL0 R - - - - R R IL1 R HR R R HR R R IL2 R HR R R HR R R IL3 R HR HR HR HR R HR IL4 R HR HR HR HR R HR Ref B.62 B.62 B.62 B.62 B.62 B.62 B.62 B.62 B.62 B.62 B.62 B.62 IL0 R R R R R R R R R R R R IL1 HR HR HR R - R NR R R R R R IL2 HR HR HR R - R NR R R R R R IL3 R R R R NR NR NR - R R R R IL4 R R R R NR NR NR - R R R R 34

D．8半正规方法

供条款9和11参考 技术/措施 1．逻辑/功能框图 2．顺序图 3．数据流图 4．有限状态/状态转换图 5．时间Petri网 6．判定/真值表 D.9静态分析 供条款12参考 技术/措施 1．边界值分析 2．检验表 3．控制流分析 4．数据流分析 5．出错猜测 6．Fagan观察 7．潜在电路分析 8．符号执行 9．走查/设计复审 注：

1． 按软件完善度等级选择一组合适的技术。 D．10模块研究 供条款11参考 技术/措施 1．模块规模 2．信息隐藏/密封 3．参数量 4．子进程和函数的单个入口/单个出口点 5．全局定义的接口 注：

1． 关于这些技术的信息请参看“模块方法”目录中，B.43条目。另外信息隐藏请参看B.36条目。

35

Ref 3 3 B.12 B.29 B. B.14 IL0 R R R - - R IL1 R R R R R R IL2 R R R R R R IL3 HR HR R HR HR HR IL4 HR HR R HR HR HR Ref B.4 B.8 B.9 B.11 B.21 B.24 B.55 B.63 B.66 IL0 R R R R R - - R HR IL1 R R HR HR R R - R HR IL2 R R HR HR R R - R HR IL3 HR R HR HR R HR R HR HR IL4 HR R HR HR R HR R HR HR Ref B.43 B.36 B.43 B.43 B.43 IL0 HR R R R HR IL1 HR HR R HR HR IL2 HR HR R HR HR IL3 HR HR R HR M IL4 HR HR R HR M 附件B （供参考） 技术目录

B．1．AI故障纠正（AI Fault Correction）（供C.10参考）

目的：引出一组由方法、过程模型、以及一些在线安全性和可靠性分析组成的混合体（组合），以便能对可能出现的危害做出灵活反应。

说明：在特定的故障预报中（趋向于计算），由于规则可直接从规格说明中派生出来并依此对其进行检查，所以基于AI的系统可通过不同渠道有效地支持故障纠正、维护和监督行为。通过这种方法，特别是在使用函数或描述方式的模型和方法组合时，可以有效地避免某些常见故障。这些故障是通过脑中已形成的一些设计和实现规划而隐性地引入规格说明。

为满足所要求的安全性和可靠性，选择的这些方法可纠正故障和见效失效影响。 B．2可分析程序（Analysable Programs）（供C.11参考）

目的：用一种易实现程序分析的方法设计程序。程序运行的可测性完全建立在程序可分析的基础上。 说明：其目的是产生易用静态分析方法分析的程序。为达到这个目的，应遵守结构化程序设计规则，如： 模块控制流应由结构化的构造，即顺序、迭代和选择。 ——模块应小。

——通过模块的可能路径数目要少。

——单个程序部分应尽可能地设计得与其它模块无联系。 ……

——分支和循环判定只与模块输入参数有关。 ——各种类型映射（mapping）之间的界限要简单。 参考文献：

Verication-The Practical problems. B.J.T.Webb and D.J Mannering, SARSS 87, Nov. 1987, Altricham, England, Elsevier Applied Science, ISBN 1-85166-167-0,1987.

An Experience in Design and Validation of Software for a Reactor Protection System. S.Bologna, E. de Agostino et. al. , IFAC Workshop,SAFECOMP 1979,Stuttgart,16-18 May 1979, Pergamon Press 1979. B.3 崩溃/加压测试（Avalanche/Stress Testing）（供D.7参考）

目的：对测试对象加载异常高的工作负荷，以表明测试对象能容易地承受正常工作负荷。 说明：有许多测试条件可用于崩溃/加压测试。一些测试条件列表如下：

——如果工作在登陆方式，那么测试对象在单位时间内将获得比正常条件下多的输入变化。 ——如果工作在需要方式，那么加大单位时间内测试对象的需要数使其超过正常条件。 ——如果数据库的大小担任着重要角色，那么加大数据库尺寸使其超过正常条件。 ——分别调节影响设备只它们的最大速度和最低速度。

——对于极端情况，所有影响因素尽可能快地在同时放置于边界条件。

在这些测试状况下，可以评估测试对象的时间行为，可以观察负荷变化的影响，可以监测内部缓冲区域动态变量、堆栈等的纠正度。

B．4边界值分析（Boundary Value Analysis）（供D.2、D.3、和D.9参考） 目的：消除出现在参量极限或边界的软件差错。

说明：将程序输入域分成许多输入类，测试应覆盖这些类的边界和极值。这种测试是检查程序中的输入预边界相符。0值的使用，在直接和间接翻译中通常容易出错，要特别注意： ——0（除数） ——空白ASCII字符 ——空堆栈或空表元素 ——零（NULL）矩阵 ——零表格入口

36

正常情况下输入边界与输入域直接对应。编写的测试案例应迫使输出为其极限值。同时还要考虑是否可能指定一个输出超过规格说明边界值的测试案例。

如果输出为一数据序列，如打印表，需特别注意第一个和最后一个元素，和包含0个、1个、2个元素的列表。 参考文献：

The Art of Software Testing. G.Myers, Wiley&Sons, New York, USA, 1979. B.5 逆向恢复（Backword Recovery）（供Ｃ.１０参考） 目的：在出现一个或多个故障时提供正确的功能操作。

说明：当检测到一个故障，系统就复位到故障前的内部状态，其一致性（Consistency）在前面已证明过。这种方法暗示保存了经常在所谓清晰检测点的内部状态。这种方法可以整体地（对全部的数据库）或递增方式地（只在检查点之间变化）进行。……

B．6因果图（Cause Consequence Diagrams）（供C.15、D.3和D.4参考）

目的：以图表方式塑造事件序列。该序列可在一个系统中演变出一组基本事件的结果。

说明：可看作为故障树和事件树分析的一个组合。从一危险事件开始正向和反向追溯因果表。反向追溯则等价于将危险事件作为顶事件的故障树，正方向追溯则能识别出事件可能引起的后果。因果图中包含有顶点符号，该符号从描述从顶点沿不同分支传递的条件，以及时间延迟。这些条件也可用故障树来描述。为使因果图进一步压缩。传递线可与逻辑符号组合。定义一组用于因果图的标准符号。因果图也可用于计算某些危险结果发生的可能性。 参考文献：

The Cause Consequence Diagram Method as a Basis for Quantitative Accident Analysis. D.S. Nielsen Riso-M-1374, 1971.

B．7鉴定了的工具和鉴定了的翻译器（Certified Tools and Certified Translator）（供C.11参考）

目的：在软件开发的不同阶段，用工具帮助开发者是必须的。无论在哪个阶段，可能的工具应该被鉴定，以便某些可信度等级可确信输出的正确性。

说明：一个鉴定了工具是指已被确定具有某种日、特殊属性的工具。工具证书一般由一个组织，通常是全国性的，单独参照一组准则和典型的国内或国际标准来完成。理想情况下，用于所有开发阶段（定义、设计、编码、测试和确认）的工具和用于配置管理的工具均应服从证书。至今通常只有翻译器（编译器）服从证书规程。…… 参考文献：

Pascal Validation Suite. UK distributor: BSI Quality Assurance, PO Box 375, Million Keynes, MK 14 6LL. Ada Validation Suite. UK distributor: National Computing Centre ( NCC),Oxford Road, Manchester England. B.8 检查表（Checklists）（供C.15和D.9参考）

目的：对系统各个方面的关键估计提供一个激励，而不是建立特殊需求。

说明：由执行检查表的人完成一组问题。许多问题都有一个一般性特征（a general nature），评估员必须将它们翻译成最适合于被评估的特殊系统得形式。

为适应被确认软件和系统得广泛变化性（wide variatious），大部分检查表都包括能适用于多种系统类型的问题。因此在使用的检查表中很可能有与正在处理的系统无关和应被忽略的问题。同样地，对于一个特殊系统有可能需要用问题来添补标准的检查表，尤其是正在处理的系统。

无论如何，我们应该清楚检查表的使用关键要依赖于选择和应用该检查表的工程师专业知识和判断。因此工程师对所选检查表以及任何附加的或多余的问题所作的决定，都应充分说明并证明是正确的。其目的是确保能复查检查表的应用和达到同样的结果，除非使用了不同的准则。

完成检查表的目标要尽可能简洁（concise）。当有必要进行更大范围的证明时，应参照附加文档。应使用通过、失败和不确定，或一些相似的约束性标记来记录每个问题的结果。简洁性极大地简化了达到关于检查表评估结果的综合结论的过程。 参考文献： ……

The Art of Software Testing. G..Myers, Wiley &Sons, New York, USA 1979.

37

Software for Computers in the Safety Systems of Nuclear Power Stations. IEC 880, 1986. B．9控制流分析（Control-Flow Analysis）（供D.9参考） 目的：检测劣质和潜在错误的程序结构。

说明：控制流分析识别不按良好编程习惯编写的编码的可疑区域。分析程序，得到一个可分析如下问题的有向图（Directed graph）。

——到达不了的编码，如到达不能到达的代码区的无条件转移。

——纽结的编码（knotted code）缩减到一个单一节点。纽结编码是良好的结构化编码，其控制图可用连续图（successive graph）缩减。 几个节点组成的纽结点。 参考文献：

RXVP80-The Verification and Validation System for FORTRAN. Users Manual. General Research Corporation, California, USA.

Information Flow and Data Flow of While Programs. J.F.Bergeretti and B.A. Carre, ACMTrans. On Prog. Lang. and Syst., 1985.

B.10共因失效分析（Common Cause Failure Analysis）（供C.15参考）

目的：识别冗余系统或冗余子系统中的潜在失效，这些失效将逐渐消弱冗余带来的益处，因为在冗余部件中同时刻出了同样的失效。

说明：计算机系统趋向于在硬件和参数表决（majority voting）中采用冗余，以顾及工厂的安全性。这一技术被用来避免随机的元件失效，……

……同样计算机系统的其它外部影响也是真的，如：火灾，洪水，电磁干扰，坠机和地震。计算机系统还可能受与操作和维护有关的事件的影响。因此必须为操作和维护提供的充分和良好的证明过程。对操作和维护人员进行扩充训练（extensive training）也是必须的。

内部影响对共因失效（CCF）也起主要作用。这些影响可来自于共同或统一元件以及这些元件接口的设计错误和元件老化。CCF分析必须研究这些潜在共同失效的系统。CCF分析的方法是一般的质量控制、设计复查、由组进行的验证和测试、用来自于相似系统经验的反馈方法进行的真实事件分析。但分析范围不局限于硬件。即使在冗余计算机系统困难链中使用的“多版软件（diverse software）”也可能在可上升为CCF的软件方法上有某些通用性，如通用规格说明书中的错误。

当CCF不是精确地在同一时刻发生时，可通过冗余链间比较的方法进行预防。这种预防将导致在所有链共同的失效之前检查出这个失效。CCF分析应考虑这一技术。 参考文献：

Review of Common Cause Failures. I.A.Watson, UKAEA, Centre for Systems Reliability, Wigshaw Lane, WA3 4NE , England, NCSR R 27, July 1981.

Common-Mode Failure in Redundancy Systems. I.A. Watson and G.T.Edwards. Nuclear Technology Vol,46, De,1979. Programmable Electronic Systems in Safety Related Applications. Health and Safety Executive, Her Majesty’s Stationary Office.

B.11数据流分析（Data Flow Analysis）（供D.9参考） 目的：检测劣质和潜在错误的程序结构。 说明：……

——写之前读取的变量。这非常可能是一个错误，并肯定是一种劣质编成方法。 ——不读却多次写入的变量，这可能表示省略代码。 ——写了之后从来未读过的变量，这可能表示冗余码。

有一种被称为信息系统分析的扩展数据流分析，它将实际的数据流（在规程之内或之间）与设计意图进行比较。这种分析方法一般由一种计算机化的工具来实现，该工具用可通过工具阅读的结构划注释。定义意向的（intended）数据流。

38

参考文献：

RXVP80-The Verification and Validation System for FORTRAN. Users Manual. General Research Corporation, Santa Barbara, California, USA.

Information Flow and Data Flow of While Programs. J.F.Bergeretti. and B.A,Carre, ACMtrans. on Prog. Lang. and Syst. 1985.

B.12数据流图（Data Flow Diagrams）（供D.6和D.8参考） 目的：用图解方式通过一个流程描述数据流。

说明：数据流图说明怎样将数据的输入转变为输出。图中的每一阶段代表了一种特殊的转变。 数据流图由三部分组成：

1． 带注释的箭头——代表数据流入和流出的转变，在中间有说明数据是什么的注释。 2． 带注释的气泡（Bubbles）——代表转变，在中心有说明转变的注释。 3． 运算符（AND, OR）——用于连结带注释的箭头。

数据流图描述了怎样将一个输入转变为一个输出的。他们没有，也不应该包含控制信息……

数据流图的准备工作最好考虑系统输入和面向系统得输出。每个气泡必须代表一种特殊的转换——其输出在某程度上与其输入不同。不存在规定数据流图整体结构的规则，构造数据流图是一项创造性的系统设计工作。象所有设计一样，产生最终的数据流图是一个重复精炼各阶段的早期尝试（attempts）的过程。 参考文献：

Software Engineering. I.Sommeriville, Addison- Wesley 1982. ISBN 0-201-13795-X B.13数据记录和分析（Data Recording and Analysis）（供C.11和C.17参考）

目的：记录软件项目中所有的数据、决定和基本原理以认可先前的验证、确认、评估和维护。

说明：在项目中维护详细记录既要以项目为基础又要以个人为基础。例如：要求工程师保持的记录可包括： ——对单个模块扩展的工作； ——对各模块进行的测试； ——判定及基本原理； ——项目阶段性成果； ——问题及其解决方法。

在项目进行及结果时，可分析这些记录以建立各种信息。特殊的数据记录对计算机系统的维护至关重要。由于在开发过程中形成的某些判定的基本原理，维护工程师是不知道的。 ……

B.14 判定表（真值表）（Decision Tables (Truth Tabkes)）（供C.15和C.18参考） 目的：为复杂逻辑组合和关系提供一种清楚而相关的规格说明和分析。

说明：这些有关方法使用二维表格以简洁描述布尔型程序变量之间的逻辑关系。

两种方法的简洁和列表特性使它们成为一种适合于分析以代码方式表达的复杂逻辑组合的方法。 两种方法潜在地可应用于规格说明。

B.15防御性程序设计（Defensive Programming）（供C.10参考）

目的：生产出能检测执行过程中出现的异常控制流、数据流或数据值，并按预定方式和可接受方式对它们作出反应的程序。

说明：在编程中可使用多种技术来检查控制或数据异常。这些技术可系统地应用于系统程序设计的整个过程，以便减少错误数据的可能性（likelihood）。

可识别出两个防御性技术的重叠作用区。设计内蕴出错——安全软件以调和其自身的设计缺陷（shortcomings）。这些缺陷可能是由于简单的设计错误或编码错误，或是由于错误的要求。下面列出一些防御性技术： ——区域检查变量。

——尽可能检查值的似然性（Plausibility）。

——在进程（procedure）入口，对进程参数进行分类，对维数和范围进行检查。

39

以上三个推荐技术有助于确保就依据程序功能和变量的物理意义而进行程序运算（manipulated）的数字都是合乎情理的。 ……

容错软件的设计考虑了在其自身环境中或在使用外部正常或预期条件下，并按预定方式工作的预期（except）失效。容错技术包括：

——检查具有物理意义的输入变量和中间变量的似然真性。

——最好通过直接观察有关系统状态变化的方法来检查出变量的影响。

——软件应检查自身的配置，包括期望硬件的存在性（existence）和可检查性（accessibility）以及软件自己是否完善。在维护过程之后维护的完整性（integrity）尤其重要。 有些防御性程序设计技术，如控制流序列检查，还能处理外部失效。 参考文献：

Dependability of Critical Computer Systems – Part 1. E.F.Redmil（ed）Elsevier Applied Science 1988. Dependability of Critical computer Systems- Part2.E.F.Redmil（ed）Elsevier Applier Science 1988.

Software Engineering Aspects of Real-time Programming Concepts. E.Shoitsch, Computer Physics Communications 41 （1986）North Holland, Amsterdam.

B.16 设计和编码标准（Design and coding Standards）（供D.参考）

目的：确保统一的设计文档和产生代码的形式（layout），实施无私的（egoless）程序设计和标准设计方法。 说明：在项目开始时各参与者之间所遵守的规则是一样的。这些规则至少应包括： ——遵守的开发方法和有关的编码标准，如JSP、MASCOT、Petri-Nets等； ——模块化细节，如：接口…… ……

——某些语言结构的使用或避免，如GOTO、EQUIVALENCE、动态目标、动态数据、递归、指针、出口等； ——注释内容地方以及怎样注释。

这些规则的制定是为了易于开发、验证、评估和维护。为此，他们应指明可用的工具，特别是分析器和逆向（reverse）工程工具。

B.17多版程序设计（Diverse Programming）（C.10参考）

目的：为防止系统得安全性关键失效和高可靠地连续运行，在程序执行过程中检测和屏蔽（mask）残留的软件设计错误。

说明：在多版程序设计中，一些给定的程序规格说明按不同方式执行N次。相同的输入值给N版，比较由N版产生的结果。如果结果被认为是有效的，则将其传送至计算机输出。

N个版本可在不同的计算机上并行运行，也可将N个版本交替地在同一台计算机上运行，但其结果需经内部表决。根据应用需要对N个版本可使用不同的表决策略。

——如果系统有一安全状态，则可以要求完全一致（所有N个都同意），否则使用——故障保险的输出值。对单一行程（single trip）系统，表决偏向于安全方向。在这种情况下，如果每一版本需要一个行程，那么安全动作将是关闭（trip）。这种方法仅典型地使用于双版（N=2）。

——如果系统无安全状态，则可使用多数表决策略。对于没有汇集一致的情况，为了增大选择正确值的机会，可使用概率方法。例如：当处于中间值状态时，可暂时冻结出直到一致后返回，等等。 本技术不消除残留的软件设计错误，但在它们影响安全性之前提供一种检测和屏蔽措施。 参考文献： ……

A Theoretical Basic for the Analysis of Multi-version Software subject to Co-incident Failures. D.E.Eckhardt and D.D.Lee, IEEE Trans. SE-11,No 12,1985.

40

D.18动态重新配置（Dynamic Reconfiguration）（供C.10参考） 目的：在有内部故障的情况下维护系统的功能性。

说明：系统逻辑体系结构必须能映像到系统有效资源的子设备上。体系结构要能检测到物理设备的失效，之后再将逻辑体系结构再映射回保留功能的限定设备上。虽然这一概念通常用于故障硬件单元的恢复，但如果有足够的“运行时间冗余”来允许软件再次尝试或有足够的冗余数据使一个单一的和被隔离的故障成为一个小小的输入，那么这一概念也可以应用于故障的软件单元。

尽管传统上该技术应用于硬件，但正在开发使其能应用于软件，这样可用于整个系统。在系统设计的第一个阶段必须要考虑到这一点。 参考文献：

Critica Issues in the Design of a Reconfigurable Control Computer. H. Shmid, J.Lam, R.Naro and K.Weir, FTCS 14 June 1984 IEEE 1984.

Assigning Process to Processors: A Fault-tolerant Approach. June 1984 G.kar and C.N.Nikolaou, Waston Research Centre, Yorktown.

B.19 等价类划分和输入分区测试（Equivalence Classes and Input Partition Testing）（供D.3参考）

目的：应用最小的测试数据来充分地测试软件。通过选择运行软件所必须的输入域的分区获得测试数据。 说明：测试策略是以输入的等价关系为基础的，这些关系决定了输入域分区。 ……

B．21错误推断（Error Guessing）（供D.2和D.4参考） 目的：消除共同的程序设计错误。

说明：测试经验、直觉、以及对被测试系统得知识和好奇心可以给已设计好的测试案例添加一些没有分类过的（uncategorised）测试案例。特殊值或值的组合可能容易出错。一些有意义的测试案例可从审查检查表获得。还应考虑系统是否足够健壮（robust），是否可在面板上太快或过于经常地按动按钮？如果两个按钮同时按下会出现什么情况？

B.22错误播布（Error Seeding） 目的：确定一组测试案例是否充分。

说明：在程序中嵌入一些已知的错误类型，然后再测试条件下对程序执行测试案例。如果只发现一部分已种下的错误，那么测试案例不充分。发现的所种错误与全部所种错误的比是发现真正错误与全部错误比的一个估计。这就给出了一种估计剩余错误，从而估计剩余测试工作的可能性。 发现的所种错误/全部所种错误=发现的真正错误/全部真正的错误

对全部所种错误的检测可以表明或是测试案例充分或是所种错误太容易发生。这种方法的局限性是为获得任何有用的结果，错误类型和播种位置必须反映真正错误的统计分析。 B.23事件树分析（Event Tree Analysis）（供C.15和D.4参考）

目的：以图表方式建造一个事件序列，该序列可在初始事件后在系统中发展，并进而可发现将会发生多严重的后果。

说明：……对于每个这样的分支，条件按相似的方式一个接着一个。然而并非所有条件对全部分支来讲都有关。条件连接在序列尾端，按这种方式构造的树，每一分支代表一个可能出现的后果。使用事件树可以计算出基于序列中条件的可能性和数目的各种后果的可能性。 参考文献：

Event Trees and their Treatment on PC Computers. N.Limnious and J.P.Jeannete, Reliability Engeering, Vol. 18, No. 3 1987.

B.24 Fagan 审查（Fagan Inspections）（供D.9参考） 目的：揭示程序开发各阶段的错误。

说明关于质量保证文档的“正是”审查，其目的是发现错误和遗漏（omissions）。

审查过程包括5个阶段：计划、准备、审查、修改和继续审查。各阶段都有自己的目标，必须对整个系统开发（规

41

格说明、设计、编码和测试）进行审查。 参考文献：

Design and Code Inspections to Reduce Errors in Program Development. M.E.Fagan, IBM Systems Journal, No. 3,1976. B.25 故障断定程序设计（Failure Assertion Programming）（供C.10参考）

目的：在执行程序过程中检测残留软件设计故障，以避免系统的安全性风险故障和继续高可靠地运行。 说明：断定程序设计方法是遵循检测前置条件（在执行语句序列之前，检查初始条件的有效性）和后续条件（在执行语句序列之后，检查结果）的思想。如果两者中有一个未完成，则处理因错误而停止。 …… 参考文献：

A Discipline of Programming. E.W.Dijkstra, Prentice Hail,1976. The Science of Programming. D.Gries, Springer-Verlag, 1981.

Software Deveopment – A Rigorous Approach. C.B.Jones,Prentice-Hall, 1980. B.26 SEEA- 软件错误影响分析（Software Error Effect Analysis）（供C.15参考）

目的：识别软件模块及它们的风险性；推荐检查软件错误和增强软件健壮性的方法；估价需要确认的各种软件元件的数量。

说明：分析按三个阶段进行； ——关键软件模块识别；

按规格说明书决定对各软件模块进行分析的深度（单条指令级，指令组级，模块级，等）； ——软件错误分析

该阶段的结果实——列出如下信息的表格： ——模块多 ——考虑的错误 ——模块级的错误后果 ——系统级的后果 ——违背安全性准则 ——错误风险度

——推荐的错误检测方法 ——执行检测方法时的违背准则 ——执行检测方法时的残留风险度 ——综合

综合将识别残留的非安全的情况…… 参考文献：

Raulway fixed equipment and rolling stock. Data processing. Software dependability- Adapted methods for software safety analysis, French standards NF F 71-013, December 1990

IRES International Technical Committee Report No.1 *SAFETY SYSTEM VALIDATION with regard to cross acceptance of signaling systems by the railways* P.THIREAU

*Methodologie d’Analyse des Effects des Erreurs Logiciel ( AEEL) appligue a I’etude d’unlogiciel de haute securite.* 5th International Conterence on Reliability and Maintainability. Biarritz-Trance-1986 D.J.REIFER

*Software failures modes and effects analysis* Transaction on reliability IEE-Vol.R28 No.3 August 79-Pges247/249

42

J.R.FRAGOLA and J.F.SPAMM

*The software error effects analysis, a qualitative design tllo* IEEE Symposium Computer on Software Reliability 1973-pages 90/93

B.27 故障检测和诊断（Fault Detection and Diagnosis）（供C.10参考）

目的：检测系统中可能导致失效的故障，为减少失效后果的反向测量奠定基础。

说明：故障检测即为检测系统错误状态（如前所述，错误是由被测（子）系统的故障引起的）的过程。故障检测的基本目标是禁止错误结果影响。提供正确结果或根本无结果的系统叫做“自检测系统（self checking）。

故障检测是建立在冗余（主要检测硬件故障）和多样性（软件故障）原理的基础上的。为判定结果的正确性需要某种表决。可用的具体方法是判定程序设计、N-版本程序设计和安全袋（safety bag）技术，以及引入传感器、控制跳转（control loops）、错误检测编码等的硬件措施。

……这些检测结果可以保存，并附有提供失效轨迹的数据。

复杂系统由子系统组成。故障检测、诊断和故障调整（compensation）的有效性取决于各子系统之间的相互关系和复杂性，它影响着故障的传播（propagation）。

故障诊断分离出最小的可被识别的子系统。较小的子系统要求更详细的故障诊断（错误状态识别）。 B.28故障树分析（Fault Tree Analysis）（供C.15和C.4参考） 目的：有助于对导致危害或严重后果的事件或事件组进行分析。

说明：从一将立刻引起危害或严重后果的事件（“头事件”（the ‘top event’））开始，沿树径进行分析，用逻辑运算符（与、或等）说明一组一组的起因，用同样的方式分析中间起因直至返回到结束分析的基本事件。

这种方法是一种图表方法，它使用了一套标准的符号来描述故障树。这种方法主要应用与硬件系统的分析，但它已尝试运用于软件故障的分析。 参考文献：

System Reliability Engineering Methodology: A Discussion of the State on the Art. J.B Fusel and J.S.Arend, Nuclear Safety 20(5) ,1979.

Fault Tree Handbook W.E.Vesely et.al., NUREG-0942, Division of system Safety Office of Nuclear Reactor Regulation, U.S. Nuclear Regulatory Commission Washington, D.C.20555,1981.

Reliability Technology A.E.Greene and A.J.Bourne, Wiley-Interscience, 1972.

B.29限定状态机/状态转换图（Finite State Mashines/State Transition Diagrams）（供D.6和D.8参考） 目的：定义或实现系统得控制结构。

说明：……系统的结果模型被称为限定状态机，通常将其绘制或所谓的状态转换图，即表明系统怎样从一种状态变换到另一种变换状态的图或绘成的真值表。真值表的维数是状态和输入，其单元内容包括了在给定的状态下的动作和接受到输入后产生的新状态。

当一个系统比较复杂或具有一个自然的结构时，可用一分层的FSM来反映。

用FSM表达的规格说明书或设计可检测其完全性（completeness）（系统的每一个输入在每一状态下都必须具有一种动作和新状态）、兼容性（consistency）（对每一状态/输入组仅定义有一种状态变化）、可达性（reachability）（通过任何输入序列从一种状态转变到另一种状态的可能性）。这些是风险系统的重要特征，它们可以被检测，支持这些检测的工具也容易被列出，还存在用于实现验证FSM执行或激活FSM模块的测试案例的自动生成算法。 参考文献：

Introduction to the theory of Finite State Machines. A.Gill, McGraw-Hill 1962. B.30 正规方法（Formal Methods）（供C.9、C.11和D.6参考） 目的：用基于数学的方法开发软件。包括正规设计和正规编码技术。

说明：正规方法为系统规格说明书、编码设计等某些阶段的开发描述提供了一种开发方法。结果的描述采用了数学方式，从而可用数学分析方法来检测各种类型的不相容性和不正确性。此外，在某些情况下，可以用与编译器检查源程序完全相同的语法，通过机器对规格说明进行分析，或激活对被说明系统行为的各个方面的显示。激活（animation）

43

可产生非常强的可信度，即系统满足实际需求和正规说明的需求。 ……

B.30.1CCS-通信系统的计算方法（Calculus of Communications System） 目的：CCS是描述和推理系统并行通讯过程行为的一种方法。

说明：与CSP相似，CCS是一种关于系统行为的数学计算方法。设计的系统被建模为一种顺序处理或并行处理的过程的网络。过程之间的通信可通过口（ports）进行（与CSP的通信相似），但只有在两个过程都准备就绪方可进行通信。可以建模为无确定新方式（Non-determinism），即从全系统得高层抽象描述开始（称为跟踪），对系统逐步提炼，最后提炼成一组全部行为都是整个系统所需求的通信过程。同样，也可按从底向上的方式工作，即用与合成规则有关的推理规则组合过程并演绎结果系统的特性。 参考文献：

A Calculus of Communicating Systens. R.Milner, Report number ECS-LFCS-86-7, Laboratory for Foundations of Computer Science, University of Edinburgh, U.K.

The Specification of Complex Systems. B.Cohen, W.T.Harwood, M.I.Jackson. Addison Wesley, 1986. B.30.2 CSP-通信序列过程（Communicating Sequential Processes）

目的：CSP是规格说明并行软件系统，即并行处理通信过程的系统的一种技术。

说明：CSP为过程系统提供了一种规格说明语言，和为验证过程的执行是否满足其规格说明（描述为轨迹-许可得事件序列）提供证明。

系统被建模为一个过程的网络。每个过程根据其所有可能的行为进行描述，系统按序列或并行的方式组成过程，过程可通过通道（同步或交换数据）进行通信。 …… 参考文献：

Communicating Sequential Processes. C.A.R.Hoare, Prentince-Hall,1985. B.30.3HOL-高级序列逻辑（Higher Order Logie） 目的：作为硬件规格说明和验证基础的正式语言。

说明：HOL指的是特殊逻辑符号及其机器支持系统，两者都是由剑桥大学计算机实验室（the University of Cambridge Computer Laboratory）开发的。该逻辑符号主要来自丘奇的简单类型理论（Church’s Simple Theory of Types），而计算机支持系统则基于LCF（可计算函数逻辑）系统。 参考文献：

HOL: A Machine Orientated Formulation of Higher Order Logic M.Gordon, Unib\\versity of Cambridge Technical Report, Number-68. B.30.4 LOTOS

目的：LOTOS是描述和推理并行通信过程系统的一种方法。

说明：LOTOS（同时序列说明语言）是以附加有相关代数CSP和CIRCAL（电路计算）特征的CCS为基础的。通过与以抽象数据类型语言ACT ONE为基础的次要元件结合，它可以克服CCS在处理数据结果和值表达式时的缺陷。但是，LOTOS的过程定义元件要用其它形式来描述抽象数据类型。 参考文献： …… B.30.5OBJ

目的：提供一精确的系统规格说明。该说明代有用户反馈和执行前的系统确认。

说明：OBJ是一种代数说明语言。用户按代数等式说明需求，系统的性能和结构方面则按抽象数据类型（ADT）执行的操作来说明。ADT就像ADA程序包一样，虽然执行细节是“隐含”的，但操作者的行为却是可见的（visible）。 OBJ的规格说明和子程序的步进式执行都能经受和其他正规方法相同的正式证明技术的检验。而且由于OBJ规格说明的结构方式是机器可执行的，所以它可以根据自身的规格说明直接实现系统的确认。执行实质上是对函数的评估，它通过连续的等式替换（再写）直至获得特定的输出值。可执行性使设想系统的终端用户在系统规格说明阶段就能获得

44

关于结果系统的“视图（view）”，而不必熟悉下层的正式规格说明技术。

同所有的其它ADT技术一样，OBJ只用于序列系统或并行系统的序列方式。OBJ已广泛用于小型和大型工业应用的规格说明中。 参考文献：

An introduction to OBJ; A language for Writing and Testing Specifications. J.A.Goguen and J.Tardo, Specification of Reliable Software ,IEEE Press 1979, reprinted in software Specification Techniques, N.Gehani, A.McGettrick( eds), Addison- Wesley, 1985.

Algebraic Specification for Practical Software Production. C. Rattray, Cogan Press,1987.

An Algebraic Approach to the Standardizations and Certification of Graphics Software. R.Gnatz, Computer Graphics Freum 2(2/3),1983.

DTI STARTS Guide,1987, NCC, Oxford Road,, Manchester, UK. B.30.6时序逻辑（Temporal Logic）

目的：直接表达安全性、操作需求和正式论证，这些特征在子序列开发阶段得以保持。

说明：标准一阶谓词逻辑（Standard First Order Predicate Logic）不包含时间概念，时序逻辑是对一阶逻辑的扩充，它增加了模态运算符（如“今后（Henceforth）”和“最终（Eventually）”。这些运算符可用来对系统作定量判定，如安全特性和应具有“今后”的要求。而其它要求的系统状态可能要求从某些其它初始状态得到“最终”状态。时序形式对状态（行为）序列进行解释。用什么来过程状态取决于所选的说明等级，它可能是整个系统、一个系统元件或计算机程序。在时序逻辑中不能显示地处理给予定量的时间间隔和约束。绝对定时必须作为状态定义部分，通过创建额外的时间状态方能给予处理。 参考文献：

Temporal Logic of Programs. F.Kroger EATCS Monographs on Computer Science, Vol 8, Springer Verlag,1987. Design for safety using Temporal Logic. J.Gorski. SAFECOMP 86, Darlat France, Pergamon Press, October 1986. B.30.7VDM-维也纳开发方法（Vienna Development Method） 目的：系统化的规格说明和序列的执行。

说明：VDM是一种以数学为基础的规格说明技术，它是一种精炼执行的技术，某种程度上它可以证明规格说明的正确性。

规格说明技术是基于模型的，其中系统状态按常量（谓词）定义的集合论结构进行建模，系统状态的操作通过按系统状态说明其操作的前置和后续条件的方法建模。……

……具体和精炼过程引发了对确定正确性进行证明的义务（obligations），是否要履行这些义务由设计者决定。 VDM原则上是在规格说明阶段使用，但也用于产生源代码的设计和执行阶段。VDM只能用于序列程序或并行系统得序列过程中。 参考文献：

Software Development – A Rigorous Approach. C.B.Jones. Prentice-Hall, 1980.

Formal Specification and Software Development. D Bjorner & ＣＢ Jones, Prentice-Hall, 1982. Systematic Software Development. Using VDM. C B Jones. Prentice-Hall, 1986.

The Specification of Complex Systems. B Cohen, W T Harwood and M I Hackson. Addison-Wesley,1986. B.30.8.Z

目的：Z是序列系统的一种规格说明语言符号，它是一种允许开发者从规格说明过渡到可执行算法的设计技术，某种程度上它可以证明规格说明的正确性。

原则上Z在规格说明阶段使用，但它已被考虑从规格说明延续到设计和执行中。Z最适合于有向数据和序列系统的开发。

说明：象VDM一样，该规格说明技术也是建立在模型基础上的，其中系统状态按常量（谓词）定义的集合论结构建模，系统状态的操作通过按系统状态说明某操作的前置和后续条件的方式建模。可以证明操作能保存系统常量，并证明其一致性（consistency）。规格说明的正式部分被分成了一些通过精炼可使规格说明结构化的概要（schemata）。

45

……

与VDM不同，Z只是一种符号，即不是一个完整的方法。但一种相关方法（称为B）已被开发，它能连同Z一起被使用。B方法是以步进式提炼原理为基础的。 参考文献：

The Z Notation-A Reference Manual. J M Spivey, Prentice-Hall, 1988. Specification Case Studies. Edited B Y I Hayes, Prentice-Hall, 1987.

Specification of the UNIX Filestore. C Morgan and B Sufrin. IEEE Transactions on Software Engineering,, SE-10, 2 March 1984.

B.31正式证明（Formal Proof）（供C.12参考） 目的：当出现一个或多个故障时提供正确的功能操作。 说明：……

B.35影响分析（Impact Analysis）（供C.17参考）

目的：识别软件系统的变化或增强（enhancement）对同一系统中的其它模块和别的系统的影响。

说明：在对软件进行修改性成增强之前，首先进行一次分析，以识别这一软件修改或增强后的影响，同时也标识出受影响的软件和模块。

完成分析之后，要求对软件系统的重新验证作出判定，这一判定取决于受影响的模块数目。受影响模块的重要性和变化的性质。可能作出的判定有： i） ii） iii）

只对变化模块重新验证；

对所有识别出受到影响的模块进行重新验证； 重新验证整个系统。

B.36信息性隐藏/屏蔽（Information Hiding/Encapsulation）（供D.10参考） 目的：增加软件的可靠性和可维护性。

说明：对所有软件元件都可进行全局性存取的数据可能被这些元件中任何一个偶然地或错误地修改。对这些数据结构作任何改动都要求详细检查代码和扩充修改。

……例如，一个名字目录可能有存取过程插入、删除和查找。存取过程和内部数据结构可以被重新写入（如用不同的查找方法或在硬盘上存储名字）而不影响剩余软件使用这些过程的逻辑行为。

这一抽象数据类型概念在一些程序设计语言中是直接支持的。但无论什么编程语言都可使用这一基本原理。 参考文献：

Software Engineering: Planning for Change, D A Lamb ,Prentice Hall, 1988.

On the Design and Development of Program Families, D L Parnas, IEEE Trans SE-2, Mar 1976. B.37接口测试（Interface Testing）（供C.11参考）

目的：证明子接口不包含任何错误或任何在软件爱女特殊应用中导致失效的错误，或者检测所有可能相关的错误。 说明：几种测试的详细新或完备性（completeness）（供C.11参考）

目的：证明子接口不包含任何错误或任何在软件特殊应用中导致失效的错误，或者检测所有可能相关的错误。 说明：几种测试的详细性或完备性（completeness）等级是可行的，下面是最重要的测试等级： ——所有接口变量都在极值位置；

——所有接口变量单独迪在极值处，而其它接口变量处在正常值。 ——各接口变量域的所有值，而其它接口变量处在正常值。 ——组合所有变量的所有值。这只对小型接口可行。 ——同每个调用各子进程有关的特殊测试条件。

如果接口不包括检测不正确参数值的断言，这些测试就非重要的。在产生先前存在的子程序的新配置之后，这些测试同样是重要的。

B.38语言子集（Language Subset）（供……参考） 目的：……

46

说明：对语言进行检查，以识别容易出错或难以分析的程序设计结构，如使用静态分析方法。然后定义除这些构造以外的语言子集。

B.39储存执行案例（Memorising Executed Cases）（供C.10参考） 目的：如果软件执行一条未经许可的路径，则迫使其故障——安全。

说明：在执行许可路径时，记录下每一程序执行的所有相关细节。在正常运行期间，将把每一程序运行与许可的执行集合进行比较，如果不同，则采取安全动作。执行记录可以是一序列的判定到判定路径（DD路径），或者是一序列的对数组、记录或体（Volume）的存取，或两者都有。

存储执行路径可能有多种方法。纳什代码（Nash-Coding）方法可用来 将执行序列变换成一个单一的大数字或数字序列。在正常操作过程中，执行路径值必须在任何输出操作发生前对在存储的案例进行检查。

虽然在一个程序中判定到判定路径的组合可能非常庞大，但将程序作为一个整体来处理可能行不通。在这种情况下，可以在模块级应用这种技术。 参考文献：

Fail-Safe Software-Some Principles and a Case Study. W. Ehrenberger, Proc. SARSS 1987. Altringham, Manchester, UK, Elsevier Applied Science,1987.

B.40信任/验证的模块和元件库（Library of Trust/Verified Modules and Components）（供C.11参考） 目的：避免对软件模块和硬件元件设计进行扩充地再确认，或对每一新的应用的重新设计。……

说明：设计和构造精良的PES。由一些硬件及软件元件和模块组成，它们区别明显，但按清晰的定义方式相互作用。 为不同应用而设计的不同的PES，包括了一些相同或非常相似的模块或元件。建立一个通用模块库，供多个应用程序共享大量资源，而这些资源是验证设计所必须的。

另外，在多重应用中使用这样的模块也为成功的运作使用提供了实验证据。这些实验证据进一步增强了用户对模块可能拥有的信任。

B.41马尔可夫模型（Markov Models）（供C.15参考） 目的：评估系统的可靠性、安全性或可用性。

说明：构造一个系统图形，该图形代表系统失效状态（失效状态由图形节点表示）。节点之间的边缘代表失效时间或修复事件，它按照对应的失效率或修改率来权衡。注意可以用获得 系统精确描述的方式来详述失效事件、状态和比率，如已检测到的或未检测到的失效，一个大型失效的表示等等。

马尔可夫技术适合于模块冗余系统，其中冗余等级因元件失效和修复而随时间变化。其它经典方法，如FMEA和FTA，在系统的整个生存周期中不容易摹仿失效影响。因为不存在简单的组合公式来计算相应得可能性。

对于最简单的情况，说明系统可能性的公式已可用于文献或可以进行人工计算。对于比较复杂的情况，存在一些简化方法（吸收状态）。对非常复杂的情况可以通过计算机图形仿真来计算结果。 参考文献：

The Theory of Stochastic Processes. R.S. Cox and H.D. Miller, Methuen and Co. Ltd., London, UK, 1968. Finite MARKOV Chains. J.G.Kermeny and J.L.S nell, D.Van Nostrand Company Inc. Princeton, 1959. Reliability Handbook. B.A. Koslov and L.A.Ushakov, Holt Rinehart and Winston Inc. New York 1970 The Theory and Practice of Reliable system Design. D.P. Siewiorek and R.S. Swarz, Digital Press. 1082. B.42度量（Metrics）（供C.12和C.15参考） 目的：……

说明：……大部分测量评估需要软件工具，下给出了一些可以使用的度量：

——图形理论上的复杂性：该尺度可应用于生存周期早期的评估比较，它是建立在程序控制图的复杂性的基础上的，它用秩数（cyclomatic number）表示。

——激活某一模块的方法数（可存取性）；一个模块被访问得越多，越容易调试。

——软件科学：该尺度通过计算运算符和操作数来计算程序的长度。它提供了一种复杂性的尺度并估计了开发资源。 ——每个模块的出入口：减少入/出口点的数量是结构化设计和编程技术的关键特征。 参考文献：

47

A Complexity Measure T.J. Mccabe, IEEE Trans. On Software Engineering, Vol. SE2, No.4, Dec 1976.

Models and Measurements for Quality Assessments of Software S.N. Mohancy, ACM Computing Surveys, Vol 11, No. 3, Sep 1979.

Elements of software Science, M.H. Halstead, Elsevier, North Holland, New York, 1997. B.43模块化方法（Modular Approach）（供D.10参考）

目的：为系统的复杂性将软件系统分解成一些小的可充分了解的部分。

说明：模块方法或模块化包含了几条用于软件工程项目设计、编码和维护阶段的规则。这些规则随设计中使用的设计方法而变化。大部分方法包含以下规则：

——一个模块应具有单一的清晰定义的任务或要完成的功能； ——并严格定义模块之间的联系，同一模块内的相关性要强； ——建立能提供几种模块等级的子程序集（collections）；

——将子程序规模限定为一些指定值，典型的是2-4幅屏幕尺寸； ——子程序应仅有单一入口和单一出口；

——模块与其它模块之间通过它们的接口来通信。当使用全局变量或公用变量时，模块要结构化。存取要被控制，并在每一实例中证明它们的使用； ——用文件充分说明所有模块接口； ——各模块应从其环境中遮掩某些内容；

——任何模块接口都应包括完成模块功能所必须的最少参数量； ——指明一个合适的参数数目，典型数是5。

B.44蒙特卡罗仿真（Monte-Carlo Simulation）（供C.15和D.14参考） 目的：在软件中使用随机数仿真真实世界的现象。 说明：蒙特卡罗仿真用来解决问题，这些问题分为两类： ——概率性的，使用随机数产生一真实世界随机现象； ——确定性的，可以用数字方法产生一真实世界随机现象；

蒙特卡罗仿真注入一随机数流仿真分析信号噪声或者增加随机偏差或容限。运行蒙特卡罗仿真产生一大型样本，从中可获得统计结果。

当使用蒙特卡罗仿真时，必须注意要保证偏差、容限或噪声值的合理性。

蒙特卡罗仿真的一个通用原理是重新声明和重新组成问题，以致获得的结果尽可能准确，而不是象最初声明的那样解决问题。

B.45性能建模（Performance Modelling）（供D.2和D.5参考） 目的：确信系统得工作能力足以满足指明的需求。

说明：需求规格说明包括对特殊功能需求的吞吐量（throughput）和响应，这也可能同使用整个系统资源的约束（constraints）组合在一起。建议使用的系统设计同声明的需求比较以下方面： ——定义一系统过程的模型和它们的相互作用；

——识别各过程对资源的使用，如处理时间、通信频带宽度、存储设备等。

……对于简单系统，用分析方法解决是可能的。但对于较复杂的系统，为了得到准确的结论，就要求使用一些仿真的方式。

在详细的建立模型之前，可以使用一个较简单的“资源预算”检查，它总结了所有过程的资源需求。如果该需求超出了设计系统的能力，那么这一设计不可行。即使设计通过了该检查性能模型也可以表示出由于资源缺乏（starvation）引起的过分延迟和时间响应。为了避免这种情况，工程师们通常使用整个资源的一些小块（如50%）涉及系统，以便减少资源缺乏的可能性。

B.46性能需求（Performance Requirements）（供D.7参考） 目的：证实已经满足了软件系统的性能需求。

说明：分析系统和软件要求规格说明书，识别所有通用的和特殊的、显示的和隐含的性能需求。

48

检查各性能需求，并作出决定： ——获得的成功准则；

——是否获得成功准则的尺度； ——这种度量的潜在准确度； ——可估计度量的项目阶段； ——能产生该度量的项目阶段；

然后分析个性能需求的可实现性，以便获得一个性能需求、成功准则和潜在度量表。主要目标是： i） ii） …… iv）

只要可能，就应尽可能地对多个性能需求使用一种度量。

B.47 随机测试（Probabilistic Testing）（供C.12和C.14参考）

目的：获得关于被调查软件可靠性性能的定量数字。该数字指出有关的可信度等级和有效性等级，以及： i） ii） iii）

每个要求的失效可能性； 在某一段时间内的失效可能性； 错误封闭（containment）的可能性； 每个性能需求至少要和一种度量相关； 只要可能，准确和有效的度量应选择……

从这些数字可以导出其它参数，如： ——无失效（failure free）执行的可能性； ——生存的可能性； ——可用性； ——MTBF或失效率； ——安全执行的可能性。

说明：随机考虑或以随机测试为基础或以操作经验为基础。通常所观察的操作情况的测试案例数是很大的。 为简便测试，通常采用自动辅助方法。它们关系到测试数据准备和测试输出监督的细节，在具有合适的过程仿真外围的大型主机上运行大型测试，测试数据选择既要考虑系统的观点，又要考虑的随机的观点。 这首先关系到整个测试控制，如：保证一个测试数据剖面，随机方式详细地选择单个测试案例。 单个测试硬度，测试运行和测试监督由以上说明的详细的测试目的决定，其它重要条件通过…… ……在童工相同的条件下，评估测试结果可以运用同样的数学方法。 B.48过程仿真（Process Simulation）（供D.3参考）

目的：对软件系统功能及其与外界接口的测试。不允许以任何方式修改外部真实世界。 说明：这是只为测试而创造的系统，它模拟一个系统的行为，这个系统是由被测系统控制的。 仿真器可能只是软硬件的结合，但它必须： ——当被测系统安装后，它提供全部输入；

——用能代表受控设备的方式响应被测系统的输出；

——具有提要求被测系统能处理所有干扰的操作集输入装置； 当被测软件测试时，仿真可能仅是具有输入输出的目标硬件的仿真。 参考文献：

A Software Simulator – An Aid to Plant Commissioning. S. Nunns, EWICS TC7. Physical Fault Simulation. F. Morillon, EWICS Document number WP460. B.49样机制作/运行（Prototyping/Animation）（供D.3和D.6参考）

目的：按给定约束检查系统实现的可行性，为给误解处定位，由专家对用户作系统的解释。 说明：选择一个关于系统功能、约束和性能需求的子集，用高级工具建立一个样机。…… 参考文献：

Proc. Working Conference on Prototyping. Namur Oct 1983, Budde er al. Springer-verlag, 1984.

49

Using an Executable Specification Language for an Information System S. Urban et. Al, IEEE Trans Software Engineering, Vol. SE-11 No.7 July 1985.

B.50 恢复程序快（recovery block）（供C.10参考） 目的：增加程序实现其目的的功能的可能性。

说明：写几个不同的程序块，它们通常是相互的，每一个目的都是执行同样的要求的功能。最终的程序从这些块中构造。第一块称作第一部分首先执行，其后是它计算出的结果验收测试，如果通过了这一测试，那么接受结果并进行到系统顺序部分。如果失败，则清除第一块的任何副作用，执行第二块，它称作第一块的替代。同样其后也跟着一个验收测试，其处理同第一块实例。如果需要，可以提供第二，第三块甚至更多的替代选择。 参考文献：

System Struction for software fault Tolerance B. Randall, IEEE Trans Software Engineering, Vol SE-1, No.2 1975. B.51可靠性框图（Reliability Block diagram）（供C.15参考）

目的：在一个系统或一次任务的一次成功操作下，用图表形式对的必然事件和必然状况建造模型。

说明：分析的目标表示为一个成功的途径，包括程序块，程序执行和逻辑节点。成功的途径从图的一端开始连续通过程序块和节点。成功的途径从图的一端开始连续通过程序块和节点到达图的另一端。一个程序块代表一个条件或一个事件，如果条件是真实的或事件已发生则路途可以通过这个程序块。 参考文献：

System Reliability engineering Methodology: A division of the State of the Art J.B Fusseland J.S Arend, Nuclear Safety 20(5) , 1979.

Fault Tree Handbook W.E.Vesely et. Al, NUREG-0942, Division of system Safety Office at Nuclear Reactor Washington, D.C 20555, 1981.

B.52响应定时和存储（Response Timing and Memory Constraints）（供D.7参考） 目的：保证系统满足时序和存储要求。

说明：系统和软件的要求规格说明包括特殊功能的存储和响应要求，甚至还有对使用全部系统资源的约束。所进行的分析将区别在普通和最坏实际状况下的分步要求，该分析需要估计出执行每个系统功能所需时间以及资源的利用情况。可以通过多种方式获得这些估计，例如：同一个现存系统比较或同时间临界系统得原型和标准相比较。 B.53 重试故障恢复机制（Re Try Fault Recovery Mechabisms）（供C.10参考） 目的：通过重试机制在已检测到故障的情况下试验功能恢复。

说明：在检测到故障或错误条件的情况下，试验通过重新运行相同代码进行故障恢复。在一个软件超时或一任务一样彻底。重试技术通常在通信故障或错误恢复中，而且再试条件可以从通信协议错误（检测代码和）或从通信接受响应超时中标记出。 参考文献：

The theory and Practice of Reliable System Design. D.P. B.安全袋

目的：防护反面影响安全新的软件需求规格说明和实现中的剩余故障。

说明：安全袋是一种外部监控器，在的计算机上按不同的规格说明来执行。安全袋仅涉及到保证主机运行安全，但不保证正确运行。安全袋连续监控主机。防止系统不得不通过安全袋或主机引入一安全状态。此外如果它检测到主机进入一个潜在的危害状态，系统将不得不通过安全袋或主机引入一安全状态。 参考文献：

Using AI Techniques to Improve Software Safety. Proc. IFAC SAFECOMP88, Sarlat, France, Oct 1986, Pergamon Press 1986.

B.55潜行回路分析（Sneak Circuit Analysis）（供D.9参考）

目的：监测系统内部意外的路径或逻辑流。它们在某些情况下可以启动不需要的功能或禁止所需要的功能。 说明：一条潜行回路路径可以包括硬件，软件，操作员动作，或者以上元素的组合。潜行回路不是硬件失效的结果而是无意设计在系统中的隐藏条件或软件程序编码时留下的，它可以导致系统在一定条件下误操作。或者以上元素的组

50

合，潜行不是硬件失效的结果而是无意设计在系统中的隐藏条件或地留下的，它可以导致系统在一定条件下误操作。 潜行回路的类别有：

——潜行路径，它引起电流，能量或逻辑顺序沿意外的路径或不打算走的方向流动。 ——潜行定时，事件按意外的或冲突的顺序发生。

——潜行显示，它引起操作系统条件模棱两可或错误地显示，因而可以导致操作员不合要求的动作。

——潜行标记，它不正确或不精确地标记系统功能，如系统输入，控制，显示，总线，因而，误导操作员，使其对系统进行不正确的刺激。……

……借助于基本拓补元素之间的关系及使用问题的检测表进行分析。 参考文献：

Sneak Analysis and software Sneak Analysis. S.G Godoy and G.J. Engels, J. Aircraft_vol. 15, No.8,1978. Sneak circuit Analysis J.P Rankin, Nuclear Safety, Vol.14, No.5, 1973.

B.56软件配置管理（Software Configuration Management）（供C.16和C.17参考）

目的：软件配置管理目的是当各开发组传递量变化时保证各开发组传递量之间的一致性，总之配置管理既用于硬件开发又用于软件开发。

说明：软件配置管理是整个开发过程中都使用的一项技术。从本质上讲，它要求记录各重要传递量的各版本的生产以及不同传递量版本之间的关系。结果性记录使开发都能判定一个传递量的发生变化时，尤其自己元件发生变化对其它传递量有何影响。特别是系统和子系统能在一致的元件版本中可靠重建。 参考文献：

Configuration Management Practices for Systems, Equipment, Munitions and Computer Programs.TTL-STD-483. Software Configuration Management. J K B uckle, Macmillan Press,1982. Software Configuration Management. W A Babich, Addison-wesley, 1986.

Configuration Management Requirements for Defence Equipment. UK Ministry of Defense Standard 05-57Issue 1. B.57强类型程序设计语言（Strongly Typed Programming Language）（供C.11参考） 目的：通过使用一种语言减小出现故障的可能性，该语言通过编译器进行高级检测。

说明：这样的语言通常允许用户定义的数据类型由基本语言数据类型如INTEGER，REAL来定义使用这些类型的方式同使用基本类型的方式一样，但是要进行严格检测以保证使用的是正确的类型。即使整个程序是由另外的编译单元建立起来的，如需在整个程序中都必须要进行检测，这些检测同时也保证即使从各自的编译单元参照过程类型也匹配。 强类型语言也支持优质软件工程实践的其它方面，如易分析的控制结构（如IF……THEN……ELSE, DO……WHILE，等）它们产生的是优质化的程序。

……强类型语言的典型例子是Pascal Ada 和Modula. 参考文献：

Reverence Manual for the Ada Programming Language,ANSI/MIL-815A 1983.

In search of Effective Diversity: a six language study of Fault-tolerant flight control software, a aviziens, M R Lyu, W Schutz, The Eighteenth International Symposium on Fault Tolerant Computing ,Tokyo, Japan 17-30 June 1988, IEEE computer Society Press ,ISBN 0-8186—0867=6.

B.58结构基础测试（Structure Based Testing）（供D.62参考） 目的：对结构的一定子集进行测试。

说明：在程序分析的基础上选择一套输入数据。这样可以测试所选程序元件中的一大部分；所测试的程序元素可以根据严格要求等级而变化。

——声明：这是最低严格的测试因为它可能执行所有的代码声明而没有练习条件声明的两个分支……

——LCSAT：线性代码序列和转移是代码声明的线性序列，包括以转移结束的条件转移。由于执行较早的代码对输入数据的约束，许多潜在的子路径都是行不通的。

——数据流：在使用数据的基础上选择运行路径，如同一变量既写入又WROTE的路径。 ——调用图：程序由子例程。调用图即为程序中的子例程调用树。设计测试以覆盖树的全部调用。

51

——完全路径：通过代码执行所有可能的路径，由于潜在路径变化数字非常大，完备测试自然行不通。 参考文献：

Reliability of the Path Analysis Testing Strategy. W.Howden, IEEE Trans Software Engineering, Vol SE 3,1976. B.59结构图（Structure Diagrams）（供D.6参考） 目的：表示程序的图解结构。

说明：结构图是完成数据流图的记号。它们描述了程序设计系统得各部分的级次，并以图形显示，就象树一样。它们用文件描述了数据流图的元素怎样能被作为程序分级单元来完成的。

结构图表显示了程序单元之间的关系，但不包括有关这些单元的激活顺序的信息。用以下三种符号描绘图表： i） ii） iii）

用单元名字注释的正方形； 力所能及日这些长方形的箭头；

圆形箭头，用结构图表中进出元素的数据名称注释。一般圆形箭头与图表中连接长方形的箭头平行。……

……结构图表中的每个盒子代表数据流图中的一个气泡，一般更深级可以用同一技术描述。 参考文献：

Software engineering. I. sommerville, Addison-Wesley 1982. ISBN 0-201-13795-X.

Structure Design. L.L Consitane and E.Yourdon, Englewood Cliffs, New Jersey, Pretice_Hall, 1979. Reliable Software Trough Composite Design G..J Mayers, New York, Van Nostrand, 1975. B.60结构方（Structure Methodology）（供C.9和C.11参考）

目的：结构方方法的主要目的是通过重视生命周期早期部分以促进软件开发质量。完成这些目的的方法是用准确而直觉的过程与符号（计算机辅助）以识别需求存在和按逻辑顺序与结构方式排列的运行特点。

说明：存在一些结构方。一些如SSADM.。LBMS，被设计用途传统数据处理和交互处理功能，而其它（MASCOT， JSD，实时Yourdon）比较多偏向于过程控制和实时应用（对安全性比较关键的）。 结构方法本质上是系统化觉察和分割问题或系统思维工具，它们的主要特征是： ——思维的逻辑顺序，将一个大问题分成几个可管理的阶段。 ——识别整个系统，包括环境和要求的系统。 ——将在要求的系统中的数据和功能分解。 ——检验表，例如：需要定义的事情种类表格。 ——低智能开销-简单，自觉…… ……

但是有些方法部分使用（数学地）正式符号（如JSD使用规则表达：Yourdon，SOM和SDL利用有限状态机。）该精度不仅缩小了误解范围，同时也为自动处理提供了范围。

结构符号的另一个好处是其可见度，它能使用用户凭直觉凭直觉根据自己强大的但未声明的知识检测需求规格说明设计。

该目录比较详细地描述了一些结构方法，如控制要求表示，杰克逊系统开发，MASCOT，实时Yourdon和结构分析和设计艺术（SADT）。 参考文献：

Structured Development for real-time System ( 3 Volumes) PT Yourdon Press, 1985. Essential System Analysus, St M McMenamin, F Palmer, Yourdon Inc, 1984.

The use of Structured Methods in the Development of Large Software-Based Avionic Systems D.J Hatley,Proceedings DASC, Baltimore, 1984.

V.60.1控制要求表示（Controlled Requirements Expression( CORE)） 目的：保证识别出和表示出所有的要求。

说明：该方法的目的是在顾客/终端用户和分析员之间架起桥梁。它在数学方面不是严格的而是辅助通信过程。-CORE设计采用要求表达而不是需求规格说明。该方法是一结构化的方法，其表示经过不同等级的提炼。CORE过程使问题看香更广，引入了一系统被使用的环境的知识和不同类型用户的不同观察点。CORE包括识别从主要设计中离开的方

52

针和策略。可以改正或显示地识别以及用文件描述该离开。这样要求规格说明可能不完全，但是可识别出未解决的问题和高危险区，并在子序列中指出。 B.60.2 JSD

目的：覆盖从要求到代码的软件系统开发过程的一种开发方法，尤其强调在实时系统。

说明：JSD是一种阶段性的开发过程，其中开发者将作为系统功能基础的真实世界的过程建模，决定要完成什么功能，将其插入模型中，而且将结果需求规格说明转化为在目标环境中科实现需求规格说明。因而它覆盖了整个传统的定义阶段：设计和执行，但是它同传统方法又有些不同，它不是自顶向下的。

此外它特别强调早期阶段识别真实世界中的实体，它们涉及到系统得建立，怎样建模以及怎样算出它们。一量分析了“真实世界”并且已建立了模型，就要分析系统要求的功能决定它们怎样才能适合于该真实模型。用模型中所有过程的结构化描述来扩增结果系统模型，将整个模型转换成程序并在目标软件和硬件环境中操作。 参考文献：

An Overview of JSD. J R Cameron, IEEE Trans SE-12 no 2 Feb 1986. System Development. M Jackson, Pretice-Hall,1983. B.60.3MASCOT

目的：设计和实现实时系统。

说明：MASCOT（软件构造，操作和测试的模块方法）是一种由变成系统支持的设计方法。它用同目标硬件或实现语言向会议的方式系统地表示实时系统结构。它给产生高度模块结构的设计强加了一种有条理的方法，保证设计中的功能元件和系统集成中构造元件之间密切对应。根据通过个通道进行系统通信的并发进程网络来设计系统，通道可以是固定数据库或队列库……

……MASCOT支持一种难策略，它以测试和单模及功能相关模块的大型集合为检验基础。MASCOT实现是指建立在MASCOT核心-一套高度基本要素之上的，是一实现的基础并且支持评估机制。 参考文献：

MASCOT3 User Guide. MASCOT User Forum, RSRE ,Malvern, England,1987. B.60.4实时Yourdon （Real-time Yourdon）

目的：是一种完善的软件开发方法，包括需求规格说明和面向于实时系统开发的设计技术。

说明：突出该技术的开发方案假定了所开发系统需要经过三个阶段。第一步包括建立一“基本模型”它描述了系统要求的行为。第二步包括建立一实现模型，它描述了实现所要求性能的结构和机制。第三步包括用软件和硬件实际建立系统。这三步大致上与传统的定义，设计和实现阶段相对应，但是更注意实际，在每一阶段开发员都从事建模活动。 基本模型分两部分：环境模型包括定义系统和其环境之间的边界，并描述系统必须响应的外部事件和行为模型。行为模型包括定义系统响应事件而进行的转换模式以及定义系统为做出而必须含有的数据。 实现模型也分为子模型：包括将单个进程分配给处理器以及将进程分解为模块。

为获得这些模型，该技术结合了许多著名的技术：数据流图，结构化英语，状态转换图和Petri图。 参考文献：

Structure Development for Real-time Systems ( 3 Volumes) PT ward and SJ Mellor, Yourdon Press, 1985. B.60.5 SADT-结构化分析和设计技术（SADT- Structured Analysis and Design Technique） 目的：以图表方式作用信息流来建模和识别决策进程及同复杂系统相关联的管理任务。

说明：在SADT中活动-因子图（A/F）的概念相当重要，一个A/F图包括按所谓的“动作框”分组的活动。每个动作框都有唯一的名称，通过因子的关系（如箭头所画）同其它动作框链接起来，它们也都有唯一的名称。各动作框可以按等级分成一些附属的动作框和关系。因子有四种类型：输入、控制、机制和输出：

输入：用左手边进入动作框箭头表示。输入代表重要或不重要的东西，它们适于由动作框中的一个或多个活动来操纵。 控制：它们是典型的指令，过程，选择准则等等。控制指导着活动的执行情况，它们用进入动作框顶部的箭头表示。 机制：是一种资源如职员，组织单元或设备，都是对执行任务的活动所必须的。 输出：可以标志活动产生的任何结果，用从右手边离开动作框的箭头示出。

当活动通过因子关系密切相关时，最好将这些活动作为一个不可分割的整体来考虑，同一个不能再细分的动作框来包

53

含这些活动，将活动分成动作框的分组指导原则只用几个因子将结果框配成对。

A/F图的模型等级一层一层分下去直到对动作框再分无意义时为止。达到该阶段的标志是框内的活动不能再分或者…… 参考文献：

Structure Analysis (SA) : A language for communicating ideas, DT Ross, IEEE Trans. Software Eng. Vol. SE-3,1. Application and Extensions of SADT, DT Ross, Computer, April 1985, 25-34.

Structured Analysis and Design technique-Application on safety Systems W Heins, Risk-Assessment and Control Courseware, Module B1, chapter 11,19, Delft University of Technology, Safety Science Group, PO Box 5050,2600 GB Delt, Netherlands.

B.61结构程序设计（Structured Programming）（C.11）

目的：设计和实现程序，使对程序的分析变为实际。该分析能提示所有重要的程序行为。

说明：该程序的结构复杂性应最小，避免复杂的分支。循环约束和分支只与输入参数有关。将程序分成适当小的模块，这些模块之间的相互作用要明显。优先采用能促进上述方法的程序设计语言特性，除非是考虑绝对优先外，其它声称比较有效的编程语言都少采用（如一些安全性关键系统效率）。 参考文献：

A Discipline of Programming. E.W. Dijkstra, Englewood Cliffs N J, Prentice-Hall ,1976.

Assessing a Class of Software Tools. M A Hennell et al, 7th International conference on Software-Practice and Experience, Vol 13, No 8, August 1983.

B.62合适的程序设计语言（Suitable Programming Language）（供D.5参考）

目的：尽可能支持该国际标准的要求，尤其是防御性程序设计，加强类型，结构地程序设计和可能断言。所采用的程序设计语言必须能导致付出最少的努力而代码却容易验证，此外还要方便程序开发，验证和维护。

说明：完整定义语言并且无歧义。语言是面向用户或问题，而不是面向机器。广泛使用的语言或其子集优先于特殊目的的语言被考虑。

除了已经参考的特征外，语言还提供： ——程序块结构； ——翻译时间的检测；

——运行时间类型和数组上下界检测； ——参数检测。 语言应促进：

——使用小型可管理模块；

——在定义模块时对数据的存取； ——定义可变子域，

——任何其它构造的错误的类型。

要求由一个合适的编译器，合适的预先存在模块的一个调试程序以及版本控制和开发工具来支持语言。 目前，在1994年开发该标准时，尚未搞清楚面向对象语言是否优于常规语言。 使验证困难得特征应避免，它们有： ——无条件转移，除了子例程调用； ——递归；

——指针，堆栈或任何类型的动态变量或目标； ——源代码等级的中断处理；

——循环，程序块或于程序的多重入口和出口； ——隐含可变的初始化或声明； ——易变的记录和等价； ——过程参数。

……

B.66走查、设计复审（Walkthrough/Design Reviews）（供D.9参考） 目的；尽可能迅速和经济地检测开发过程一些声明的错误。

说明：IECTC 56已经出版了一本正式设计复审指南其中包括对设计复审的描述，它们目标，不同设计复审类型的细节，设计复审组的组成以及它们的有关职责。IEC文件还提供了计划复审组内各个专家的特殊细节的指导方针。专家对特殊的例子又处于别人之中，可靠性可维护性和可用性。

IEC建议为所有新产品/过程，新应用影响功能和现有产品和制造过程的修改、执行情况，安全性、可靠性，检查可维护性，可用性的能力，成本核够能力以及其它影响最终产品/过程的特性，用户或旁人进行正式的设计复审。 代码走查包括一个走查组，选择一小套测试案例，几套典型的输入和期望的程序输出，然后通过程序逻辑人工追踪测试数据。 参考文献：

The Art of Software Testing G.Myers. Wiley &Sons, New York, 1979.

Reliability and Maintainability Guide on Formal Design Review( Draft (International Electronically Commission, Technical Committee No 56,January 1988.

B.67模糊逻辑（Fuzzy Logic）( 供C.11参考)

目的：模糊逻辑是一种数学原则，它以考虑真实度和谬误度的模糊集理论为基础，它是广义的二值逻辑，提供近似推理模型。它使人类智能合并自动系统中。 ……

说明：模糊逻辑方法的基本部分是一套语言规则（IF-THEN规则），用于前提和结果都同模糊集有关的地方。 例：如果速度快而且到停止之间的距离是中等的，那么加速器接近而且自动轻微。

在这个例子中“速度”是一个语言变量，用模糊集“快”来表示其特征，可以解释为“速度在约70英里以上”。如果不到60英里，那么“快”的隶属关系值为0。如果速度超过80英里，那么“快”的隶属值是1。如果速度在60英里和80英里之间，那么“快”的隶属值在0和1之间。

这一逻辑判定基于操作符的数学种类：三角形的标准和三角形同等标准。

以模糊逻辑规则为基础的系统在许多方面都不同与其它专家系统，如：（1）规则数少，（2）只使用前向链接，(3) 没有演绎链接（所有规则在一次迭代中并行执行），（4）经统计定义的规则，（5）简化方法的执行速度，（6）决定论。 在前些年，模糊逻辑已大量用于许多诸如财政和地震工程的领域，尤其是模糊窑已出现在控制高非线性系统，或者不知道其数学描述的系统或太复杂而不能分析对待的系统是现有测量质量太差的系统。

模糊逻辑控制的著名应用包括飞行控制，电力系统和核反应堆控制。接下来模糊控制又成功地用在自动列车操作系统。 参考文献：

Fuzzy Sets: Zadeh. Informational and Control, 1965, vol 8,pp338-353.

Fuzzy Logic in Control System Fuzzy Logic Controller, Part I & II, Choen Chien Lee. IEEE Transactions on Systems, man, and dCybernetics, vol. 20, No. 2, March/April 1990. Industrial Applications of Fuzzy Control: M.Sugen Ed, Amsterdam North Holland, 1985. An automatic operation Method for control rods in BW Rplants. ……

B.68面向对象程序设计（Object Oriented Programming）（供C.11参考）

目的：能快速原形开发，能比较容易地重新使用现存的软件组件。能完成信息隐藏，能减小整个寿命周期中的错误可能，能减小整个寿命周期中的错误可能，能减小维护阶段所必须的努力，能将复杂问题分解成易于管理的小问题，能减少软件组件之间的依赖，能产生易于扩充的应用。

说明：面向对象程序设计是从一种新的基本方法来思考软件，它基于存在对现实世界的抽象而不是基于计算抽象。面向对象程序设计将软件组织成将结构和行为合并在一起的对象集合，这与习惯的数据结构和行为只是联系着的程序设计不同。

对象：一个对象包括一个私用数据区和一套对象的操作——所谓的方法。方法可以是公用的也可以是私用的。不允许

55

其它软件组件直接读或改变一个对象的私用数据。其它软件组件必须使用那个对象的公用方法读或写那个对象的私用数据区的数据。

对象类：通过指定一对象类（通常用类型定义的方法），你可将大量对象的示例归为同一类，例如所有本例都有私用数据区和该对象类中规定的方法。

（多样）继承性：一个对象可以继承私用数据区和一个（或多个）超类（更高层的对象类），并允许它增加一些私用数据和一些方法或修改对继承方法的实现。使用继承性可建立多样对象类别树。

多态：同样的操作在不同的对象类中有不同的表现，如终端对象的写操作是将特性写道、到该终端而一个文件对象的写操作却是将特性写到该文件。 参考文献： ……

Learning language, Peter Wegner, Byte ( McGraw-Hill publication) March 19.

All OOPSLA (Object-Oriented Programming Systems, Languages and Applications) and ECOOP( European Conference on Object-Oriented Programming) conference proceedings. B.69可追溯性（Traceability）（C.12）

目的：可追踪性的目标是保证表示出所有需求已得到满足，并且没有引入不可追踪的材料。

说明：在系统确认中要着重考虑追踪需求的能力而且不要提供方法以证明在寿命周期的所有阶段都存在该能力。 可追踪性可考虑用于功能和非功能的需求中，尤其应指出：

a) b) c) d) e)

对设计或其它实现需求的对象需求的可追踪性。 对实现对象的设计对象的可追踪性。

对要求在系统中安全且正确应用操作和维护对象的需求和设计对象的可追踪性/

对验证和测试计划以及决定它们的被接受程序的需求规格说明的需求的设计，实现，操作和维护对象的可追踪性。

对测试或其它记录这些应用结果的验证和测试计划以及需求规则说明珂追踪性。

当把要求，设计或其它对象作为一些分离的文件来条例时，可追踪性将在文件结构内部用分层方式形成。

56