C 5000 编程系统
C 5010 引言
本章确定可实现一个带有其硬件和软件的编程系统23的有关规定。
C 5020 定义 软件
一个编程系统的程序的集合。 软件部件
一个特定微处理器的完整程序，每一个软件部件由两部分（系统软件和应用软件）构成。 软件模块
一个软件部件的组成单元。
C 5100 适用范围——目标 C 5110 适用范围
本章的规定适用于安全级的编程系统。
这些规定按照具体情况也可全部或部分地适用于核电站的其它编程系统。 本章不涉及在实现编程系统时所使用的软件工具的研制。
C 5120 目标
C 5000章中的规则适用于编程系统及其软件的研制周期，适用于原先已有的系统或软 件的使用，并适用于这些系统的鉴定。这些规则补全了RCC-E其它章中确定的规则。
本章特别涉及到： ——表达需求 ——系统规格书 ——系统结构的确定
23 在本章范围内，“编程系统”(或缩写为“系统”)是指包含有软件的所有电气系统(A 2100)。
见C 5210 见C 5220 见C 5230
101
——软件的研制 ——系统的集成 ——系统的确认 ——以前的经验 ——软件工具的使用 ——系统在现场的安装 ——维护和变更 ——质量保证 ——编程系统的鉴定
C 5130 安全等级
见C 5240 见C 5250 见C 5260 见C 5300 见C 5400 见C 5500 见C 5600 见C 5700 见C 5800
对于安全级电气系统，区别两种安全等级：
——1E级系统（实现安全级和1E级的功能），例如反应堆保护系统；
——以及非1E级系统（实现安全级和非1E级的功能，不包括1E级的任何功能）。 以下述方式介绍本章的规定：
——当规定适用于1E级和非1E级系统时，不作特别说明； ——当只对1E级系统要求时，用“对于1E级系统”引入； ——当只对非1E级系统要求时，用“对于非1E级系统”引入。
C 5140 设计要求
标准CEI 61513第6章的要求适用于编程系统。
对于1E级系统，标准CEI 60880（1986）的要求适用于软件。 对于非1E级系统，标准CEI 62138的B类要求适用于软件。
C 5200 编程系统的研制
在实现和维护一个编程系统时所涉及的主要技术活动表示在图5.1中。 对于1E级系统，CEI 60880第3章的要求尤其适用。
102
C 5210 表达需求
这一活动的目的是特别从用户的观点确定可适用于编程系统的所有要求，这一活动表现为由主承包商编写的招标书。招标书由一些特定的文件和一份所要参考的外部文件清单组成，这一招标书按照规定应适时修订。
招标书应使安全重要的编程系统的任务同它的辅助功能（运行、维护、试验„„）区别开来，所有这些任务应同仪表和控制的整体结构相一致。
招标书应编排得便于对编程系统进行鉴定。
C 5211 编程系统的环境
招标书应明确指出编程系统应被使用时所处环境的特性（如在D 2000中描述的环境条件和供给条件，可使用的面积或体积，外部灾害（地震„„））。
招标书应规定编程系统同与之直接相互影响的其它系统的接口，这还包括同为了装载系统用数据而使用的软件工具的接口。
对每一个接口，应确定： ——有关系统的安全等级； ——输入的起始点和输出的终点；
——如果原先有外部限制，相应的交换协议； ——交换信息的数目、格式、类型、容量和流量； ——硬件和软件支持、以及接口的通信标准； ——应考虑的外部风险。
招标书应确定编程系统与使用人员的接口以及有关的信息安全要求。
C 5212 功能、特性和性能
招标书应规定编程系统在其已鉴别的每一种运行方式下要求的功能、特性和性能。 运行方式的鉴别应考虑：
——核电站的主要状态：起动，功率运行，停运状态，故障或事故工况，„„； ——从总体上采用的仪表和控制以及有关设备的主要状态；
——编程系统的主要状态：初始化，额定状态，退化状态，在极限条件下运行，试验(定
期试验„„)和维修。
103
这些功能包括应予实现的应用功能的一部分以及有关系统要求的功能，一项功能的规格书应包括：
——该功能要完成的任务；
——该功能的先决条件，它的输入和输出； ——响应时间要求； ——有关的准确度要求；
同时要考虑规定的特殊条件(所有的运行方式，对输入和输出规定的信息流量，用户数目、配置参数值„„)。
C 5213 分级
应将编程系统的安全等级列入招标书中，根据编程系统要求的功能，可能要区分安全等级。
C 5214 对可靠性、可用性、可维修性和安全所起的作用
a) 确定要求
招标书应确定为执行对核电站安全起作用的仪表和控制功能所必需的要求。
b) 硬件可靠性
招标书应规定与硬件可靠性有关的要求(可能包括某些部件的特殊要求)。
c) 鉴别异常事件
招标书应包括力求鉴别可能引起编程系统故障的异常事件(内部故障或外部灾害)的要 求。还应规定系统容纳这些事件的容量以及为此使用的原则。
对于1E级系统，招标书应包括有即使在发生单一故障的情况下(如果对此要考虑的话， 叠加上不可用)力求保证执行安全级功能的要求。
d) 对系统故障的保护
招标书应包括有当已经对安全功能提出要求时力求确证安全功能已经完成的要求，并 包括有在相反情况下力求确证有关系统故障的适当信息已经在规定时间内提供的要求。
招标书应规定编程系统在故障情况下的运行方式。
104
e) 对低安全级的系统、设备和软件故障的保护
招标书应包括有即使在低安全级的系统、设备或软件发生故障(包括偶然故障)的情况下力求保证执行安全级功能的要求。
f) 独立性、冗余性以及对故障共因的防御
招标书应规定有适合于编程系统的独立性和冗余性24的要求(这些要求是作为对故障 共因的防御而提出的)。
这些要求应力求达到：
——编程系统中的内部冗余，以及冗余部分之间的独立性；
——编程系统与不同安全等级的其它系统、设备和软件之间的独立性； ——多样化功能（功能多样性）之间的独立性。 g) 为保证安全级功能要求的编程系统可用性
招标书应规定为保证安全级功能而提出的关于可编程系统可用性的要求。 招标书应规定关于对这一可用性进行监测的要求（C 3000）。 h) 可维修性和维护
规格书应在考虑编程系统安全等级和运行限制的同时，规定关于可维修性和维护的要 求。
i) 质量保证
招标书应在考虑编程系统安全等级的同时，规定关于质量保证、设计标准、文件及其 归档等的要求。
C 5220 编程系统的规格书
招标书表示需求。建造者、供货商或制造商为了从外部的观点足够详尽和完整地描述系统，应提供规格书文件。
在任何情况下，规格书文件应适时修订。
对于1E级系统，CEI 60880第4章的要求特别适用。 24 这里要求的冗余是由编程系统的外在理由所要求的功能冗余，而部件之间的冗余可以由制造商引入，以便得到要求的可靠性。
105
C 5221 规格书文件的内容和特性
编程系统的规格书文件应规定为评价该系统与其招标书要求的一致性所需的所有特性，因此招标书中论述的各方面要求都应显示在规格书文件中。
规格书文件要求的特性应该与招标书要求的特性相同，遵守标准CEI 60880附件A和C中表示的要求可以获得这些特性。
C 5222 与招标书的一致性分析
应对规格书文件与招标书中表示的要求进行比较分析，分析结果应记录在关键性审查 报告中25。
应阐明与招标书相比的差别，并对安全进行论证。如有必要，应确定补偿措施。
C 5230 确定系统结构
系统结构是系统、系统的所有部件26以及系统运行原则的内部描述。 系统结构的确定按两个阶段进行：
——第1阶段处理系统的内部描述和系统部件的外部描述；
——第2阶段在系统部件已经确定时开始进行，并通过系统部件的内部描述完成第1
阶段。
C 5231 一般要求
编程系统结构的文件应：
——提供系统内部结构和运行的完整描述；
——按照子系统（功能支持）和部件的分层结构描述系统的分解，通过不断的细化直
到基本层次；
——确定系统的功能任务在全部硬件部件和软件部件上的分配； ——鉴别出支持软件部件执行的硬件部件； ——提供硬件部件和软件部件的外部描述； 25 关键性审查：在于核查每一阶段的结果完全满足前一阶段的规定要求和条件的审查活动。 26 在本章中“部件”是指编程系统硬件单元或软件单元中的一个或一组单元，以及从A 2100节
中给定意义上的部件。
106
——包含已鉴别的所有部件的规格书以及对这些部件之间的连接和相互影响的描述，
其详细程度达到可使用每一个部件和对之进行试验； ——描述各部件的内部结构：
对于1E级系统，这些文件应包含所有部件的内部结构； 对于非1E级系统，这些文件应包含未被宣布作为黑盒子构。编程系统内部运行的描述应包括鉴别和描述：
——编程系统及其部件的运行方式（以及这些运行方式之间可能存在的联系）； ——编程系统的内部事件；
——在已鉴别的运行方式下编程系统及其部件的特性； ——在已鉴别的运行方式下编程系统部件之间的相互影响。
编程系统结构的文件应可确定该系统符合招标书和规格书的要求。为此，系统结构的文件中应包含有可对编程系统完成其安全级功能的能力的保证措施有效性进行评价所作的分析，在进行分析时要考虑硬件的可靠性以及下述各项的相关要求：
——独立性；
——可用性，定期试验和自动监测； ——可维修性；
——故障检测、缺陷的定位和消除； ——质量保证； ——鉴定。
对于1E级系统，系统结构的文件应规定和论证为评价和限制软件及系统的复杂性所使用的准则。
编程系统的结构应设计或可对这一编程系统及其部件进行试验和验证。
C 5232 关于系统完成其安全级功能能力的要求
a) 软件的确定性和可预测性
对于1E级系统，通过设计，软件特性应是确定性的。如果通过对其软件的静态分析 有可能以很高的准确度确定软件的特性（检查处理的顺序及资源的利用），则认为该软件是
27 这里“黑盒子”是指未能了解其内部结构的部件，因此，建造者、供货商或制造商不能依据对
其工业产权的保护而拒绝接受审查。
27
的所有部件的内部结
107
确定性的。这对于所有的运行方式而言应是真实的。
对于非1E级系统，通过设计，软件特性应是可预测的。如果基于系统结构及其实现， 通过使用样品或确定性假设有可能用规定的不确定性裕度预言软件的特性，则认为该软件是可预测的。这对于所有的运行方式而言应是真实的。
b) 独立性
冗余的硬件部件（按C 5214 f节的含义）应能在其中一个部件即使发生故障时，使编程系统仍能完成其安全级功能。
对同一编程系统内部具有不同安全级别的子系统应这样地进行安排，使得低一级子系统的故障不损害高一级子系统的功能。
c) 自动监测
编程系统应设计成能自动监测，以便探测到可能发生的故障并采取适当的措施（至少发出信号）。
d) 定期试验
编程系统应设计成可以进行定期试验，如同招标书中要求以及C 3000中规定的那样。
C 5240 软件研制
编程系统的软件由系统结构阶段时（C 5230）确定的全部软件部件构成。 每一个软件部件由两部分组成：
——系统软件，它对支持的硬件部件资源进行管理，并便于应用软件的研制； ——应用软件，它处理应用（功能）方面的问题。
因此，编程系统的软件研制阶段在于规定和产生所有的软件部件，即所有的系统软件和应用软件。
软件部件的研制由若干阶段构成，每一阶段应有一个正式的结论。区分两个主要阶段： ——规格书阶段，这一阶段的目的是：
确定软件部件的全部任务以及这些任务在系统软件和应用软件之间的分配（C 5241）；
确定与这两种软件中每一种软件有关的详细要求（C 5242）。 ——系统软件和应用软件的制作阶段，对每一种软件该阶段包括： 软件的结构阶段（C 5243）；
108
软件的实现阶段（C 5244），它包括软件的详细设计、编制程序、单元试验、集成 以及确认。
利用原先已有软件（例如系统软件）是通常的作法，这些已有软件是按照相同的原则研制的。
对于1E级系统，软件应按照标准CEI 60880进行研制。特别是，CEI 60880第3章的要求适用于初步设计，第4章的要求适用于规格书，第5章的要求适用于实现。
C 5241 软件规格书
本章的内容是关于全部软件部件的规格书。
规格书从总体上或者逐一按部件描述所述软件的全部任务，并描述系统软件与应用软件之间任务处理上的分配。
对于1E级系统，构成编程系统的每一个部件的软件将个别地予以规定。规格书应以在确定系统结构和每一个部件的软件所完成的功能任务时所规定的分配作为依据，应对应用软件与系统软件之间在任务处理上的分配进行描述，应对内部软件接口（系统软件与应用软件之间）和外部软件接口（部件之间）进行描述，这些描述应包括静态方面（数据流量的确定）和动态方面（时间特性、运行方式转换„„）。
对于非1E级系统，软件可以按照编程系统的每一个组成部件个别地予以规定，也可以对整个系统从整体上规定。在后一种情况下，规格书应明确软件功能在各个部件上的分配规则和限制（例如，某些功能在不同部件上的隔离限制，或者为了存储器利用或处理器加载而应遵守的裕度上的限制）。软件功能的实际分配以及产生的软件接口应在软件结构中明确指出。
软件规格书活动的输入资料是： ——编程系统的规格书； ——编程系统结构的确定。
供货商在软件规格书文件中确定应实现的软件功能和软件技术要求。
软件规格书应描述系统软件和应用软件的有关要求，以及所使用的研制工具的有关要求。软件规格书可由两部分来实现：
——一部分（系统软件规格书）规定系统软件并确定以“一般”方式使用的研制工具，
这一部分规格书通常与各种应用无关，尤其是当系统软件和研制工具原已存在的
109
时候；
——另一部分（应用软件规格书）规定应用软件，必要时还规定系统软件的配置，应
用软件规格书通常使用“面向职业的”、易于为运行工程师理解和使用的、可以全部或部分自动地生成程序的语言来实现。
C 5242 系统软件和应用软件的规格书
系统软件和应用软件的规格书应详细地描述： ——需实现的功能处理； ——软件接口；
——运行方式和有关的转换； ——用户接口和用户活动；
——耐用性处理（自动监测、防御性程序设计„„）；
——设计限制（硬件限制、对部件的分配规则和限制、规定的协议、标准„„）； ——对于应用软件规格书，关于系统软件配置的可能限制； ——性能目标（循环时间、响应时间、准确度„„）； ——关于运行安全的特定要求。
C 5243 系统软件和应用软件的结构
这一初步设计阶段应给系统软件和应用软件规格书中表示的需求提供一个信息化解决方案，它应按照模块式结构确定被分析软件的结构。
软件应由一些减小容量的模块连接而构成，每一模块应可独立地进行试验，应确定模块式结构的组织（链接、交换、调用„„）以及每一个模块的接口。
与试验和验证大纲（C 5244-5）相一致的一个临时版本的集成试验程序应由供货商来完成。
C 5244 实现系统软件和应用软件
本章应描述实现系统软件和应用软件的各个阶段，这些阶段应按顺序执行。
110
C 5244-1 详细设计
在详细设计阶段应：
——对于由软件结构确定的软件模块，确定算法的解或者其它解；
——确定按照试验大纲（C 5244-3）制定的试验程序，该程序将在单元试验阶段中
（C5244-4）执行。
C 5244-2 编制程序
以编制程序阶段中，应将详细设计中确定的功能表达为可由硬件执行的指令。 在编制程序时应遵守程序设计的规则，由这些规则确定命名、表达、构造以及所用注释的标准。
对于1E级系统，应确定质量评定准则以保证所产生程序的易续性。
C 5244-3 试验和验证大纲
试验和验证大纲应确定和论证对于试验和验证采取的策略，以及对于单元试验和集成试验采用的执行方式。
对于1E级系统，应由与完成研制的人员或组织相独立的人员和组织进行验证。
C 5244-4 单元试验
在这一阶段中，应对每一个模块执行在详细设计阶段时预定的试验和验证，目的是验证已编程的模块与详细设计阶段中制定的规格书是一致的。
C 5244-5 集成试验
这一阶段就是按照试验和验证大纲中（C 5244-3）已确定的集成大纲把各个软件模块逐渐地连接起来。
在这一阶段中应执行用以记录探测到的差错及其纠正办法的某些特殊程序，并应将结果以可由不直接参与试验的人员检查的方式记录下来。
C 5244-6 确认试验
所有软件部件的系统软件和应用软件应根据它们的规格书（C 5242）进行确认，确认
111
试验是一些“黑盒子”试验。
这些试验可在代表目标硬件的一个平台上进行。在这种情况下，应提供对于所使用平台的代表性程度的论证。
作为对应用软件执行支持的系统软件，可独立于应用软件进行验证。在进行这一验证时所使用的应用软件“塞子”应能对系统软件所有的预期功能进行试验。
对于1E级系统，应用软件的确认应同已确认的系统软件一起进行，并应作为一个特定阶段的目标。
应对部件的所有内部和外部接口进行验证。
对于1E级系统，应验证软件规格书中确定的所有功能要求。
应当安排某些特殊的程序，用以对探测到的差错及其处理办法（问题的分析、采取的解决办法、不退化试验„„）进行跟踪。
应对每一个被试验软件建立一个确认文件，该文件确定和论证所采取的试验策略，并包含有各项试验的确定、各项试验的执行方式、取得的结果以及所探测到差错的记录。
对于1E级系统，应逐一对部件进行这些试验。
对于非1E级系统，这些试验可以按部件、按子系统或在整个系统上进行，它们类似于并有助于系统的确认，但不能替代系统的确认（C 5252）。这特别适合于其规格书采用面向职业语言形式以及由代码生成设备（CAO通道型）自动实现程序设计的系统。
C 5244-7 确认
一个软件模块的确认可能在单元试验（C 5244-4）、集成试验（C 5244-5）以及确认试验（C 5244-6）各阶段结束后宣布。
完整软件的确认需要验证系统的内部接口（部件之间的相互影响）和外部接口（系统与其环境之间的相互影响），这一确认只有在系统的确认试验（C 5260）之后才能宣布。
C 5245 对软件的要求 C 5245-1 程序设计的特有要求
应确定和论证面向编程系统完成其安全级功能能力的程序设计规则，对于与这些规则的偏离应进行鉴别和论证。
对于1E级系统，应避免程序中存在未被使用的部分，除非进行论证。
112
C 5245-2 软件制作的特有要求
为了从软件源程序28和功能模块生成可执行的程序，应确定一些程序，应使这些程序形成文件，并对之进行维护。
这些程序应保证软件制作过程的入口和出口处各个不同单元的一致性。
C 5245-3 配置管理
应对程序、重要文件（C 5720）和软件工具进行配置管理，以便保证： ——重要文件和软件工具不会意外地被修改；
——与一定版本的编程系统或部件相对应的重要文件和软件工具可予以鉴别，并在必
要时可重新找到；
——同一文件不同版本之间的差别可予以鉴别。
配置管理大纲应特别考虑文件资料、构成产品的程序（源程序、可执行程序）、数据文件、制作工具和制作程序（文件编制程序„„）、原先已有的产品（程序库„„）、确认后出现的异常事件、硬件和工具的标识。
C 5246 软件文档 C 5246-1 基本文档
要求按照A 3206建立基本文档。为了更好地考虑软件研制的特殊性，基本文档包括有： ——软件规格书（C 5241和C 5242）； ——软件的制作文档（C 5246-2）；
——源程序、目标程序、可执行程序和派生程序(必要时)； ——试验文件、试验和验证大纲（C 5244-3）以及有关的报告； ——确认文件（确认大纲以及有关的报告（C 5244-6）； ——已影响文档各个部分的修改清单。 C 5246-2 软件的制作文档
这里将软件制作定义为可从源程序开始实现重组软件的全部操作，软件制作应是一个 28 这里与功能模块相对照把程序员直接生成的单元称之为软件的源程序，功能模块是源程序用工
具处理的结果，源程序可以用高级语言（例如图解语言）来编写，为了得到功能模块，必须对源程序进行处理。
113
其中限制进行人为干预的有计划的过程，软件制作文档是指可实现这些操作的全部文件。
软件制作文档的目的是：
——提供技术保证，使得组成或参与组成最终系统的软件单元是协调一致的（例如没
有忘记对修改的源程序进行编译）；
——可独立于制作者进行某些分析，这些分析需要软件的测试手段和变更（例如测量
动态覆盖范围、差错的自行定位）。 软件制作文档应包括： ——软件质量计划（C 5710）； ——程序设计规则；
——程序和数据在源文件中的分布；
——有关的源程序和程序库清单，据此系统可完全进行重组和重新验证； ——研制方法、研制工具、研制平台的描述或参考文件；
——制作工具参考文件和制作程序（编译程序、连接编辑程序、代码生成程序等）； ——制作时使用的控制文件；
——可对控制文件与软件其余部分之间的协调性进行评价用的资料；
——为从源程序开始重组系统和重新验证系统应遵循的运作步骤的详细说明； ——为在硬件上安装软件应遵循的运作步骤的详细说明。
C 5246-3 可追溯性
关于软件研制周期每一项活动的文件应包括有该文件描述的要点与上游活动文件中包含的要点之间的联系。
对于1E级系统，如果供货商不具有其它的等效手段，供货商应在一个文件的每一部分中提及为建立要求的联系必需引用的上游活动文件的章节。
对于非1E级系统，如果供货商不具有其它的等效手段，供货商应在每一个文件中提及为建立要求的联系必需引用的上游活动文件。
C 5250 系统的集成
应进行编程系统集成的试验和验证，以便对于编程系统与其规定结构（C 5230）相比较的一致性给予很高的置信度。
114
这些试验和验证以循序渐进的方式进行，并应形成文件。这一文件应包含有试验和验证大纲、试验和验证报告以及一份综合报告。
对于1E级系统，CEI 60880第6和第7章的要求特别适用。
C 5251 集成大纲
集成大纲应确定和论证对于试验和验证采取的策略，并规定在系统集成时应进行的试验和验证。应当允许由研制工作的外部人员来确定检验方法是否适合。
试验和验证的策略尤其应确定和论证： ——如何逐渐地把各部件集成起来； ——对每一类部件进行的试验和验证的类型；
——可判断规定的试验已足够（功能和结构复盖）所采用的准则； ——适用于每一个部件的试验；
——对每一项试验或验证所使用的环境、方法和工具； ——应产生的报告； ——负责的机构。
试验和验证规格书尤其应包括： ——鉴别要试验的实体； ——鉴别要试验或验证的特性； ——描述要试验的配置所处的环境；
——应进行的试验和验证、应使用的方法、应使用的工具、工具的标定等； ——输入信号和输入数据、参数、条件，以及正式证明的预计值； ——对于结果的校正分析提出的建议。 应对鉴别出的所有部件进行试验和验证。
C 5252 集成报告
应将试验和验证的执行形成报告，而且应编写一份综合报告。 试验和验证报告应至少包括：
——被试验或被验证实体的完整标识； ——被试验或被验证特性的鉴别；
115
——试验条件描述（被试验或被验证部件的配置以及环境的配置、使用的方法、工具、
工具的标定、输入信号、有效的结果、结果的校正分析和偏差分析„„）； ——鉴别所得结果与预计结果之间的偏差，如有必要进行偏差分析； ——如有必要，进行未退化分析；
——试验或验证的结论（用满意或不满意表达）。 综合报告应：
——完整地鉴别有关的实体；
——鉴别关于这一实体的所有试验或验证报告； ——鉴别和论证预定的但没有进行的试验和验证；
——包含有对全部试验和验证的结论：满意或不满意，如果不满意应采取哪些行动？
C 5260 系统的确认
确认的目的是验证编程系统符合它的规格书。应进行编程系统的确认，以便从功能、性能和接口的观点对编程系统与其规格书的一致性给予很高的置信度。这一置信度应同系统的安全级别是一致的。
应将系统确认形成文件，该文件至少应包括确认大纲、确认报告和一份综合报告。 对于1E级系统，CEI 60880第8章的要求特别适用。 这一系统确认工作可在工厂中开始，应在现场结束。
C 5261 确认大纲
确认大纲应规定和论证确认的策略以及应实施的确认行动。 确认的策略尤其应规定和论证： ——已进行的试验和验证的类型；
——可判断规定的试验已足够（功能和结构复盖）所采用的准则； ——对每一项试验或验证所使用的环境、方法和工具； ——应产生的报告。
试验和验证规格书尤其应包括：
——鉴别要试验的实体（代表系统的某些部分或整个系统）； ——鉴别要试验或验证的特性；
116
——描述要试验的配置所处的环境；
——应进行的试验和验证、应使用的方法、应使用的工具（脉冲发生器、环境模拟
器„„）、工具的标定等；
——输入信号和输入数据、条件以及正式证明的预计值； ——对于所得结果的校正分析提出的建议。 确认尤其应包括：
——功能试验；
——在故障情况下以及在重新配置时的特性试验；
——如有必要，对正在运行的系统进行可维修性的验证试验。 功能试验应包括在正常条件下以及在各种极限运行条件下的系统模拟。
应突出在规格书与应进行的试验和验证之间的联系（记载）
对于1E级系统，应保证由与原来实现和修改编程系统的小组相独立的小组来制定和执行确认大纲。
对于非1E级系统，应保证由原来未参加实现和修改编程系统的人员组成的小组来制定确认大纲。
C 5262 确认报告
应使全部的确认活动形成文件，而且应提供一份综合报告，这些文件的内容应该与 C 5252中描述的类似的集成文件的内容相同。
C 5300 以前的经验
建造者、供货商或制造商可以利用以前的经验，这些经验： ——可论证由于服务代理商参与编程系统的供货将能得到的可信度； ——在部分或全部地再次使用原先已有的产品时可提高可信度。
C 5310 以前的实践经验
编程系统制造的评价程序应遵守B 1200中说明的要求。对建造者、供货商或制造商能力的论证取决于它们的实际工作的质量（特别是在他们对软件研制的控制方面），条件是这些实际工作符合核电站所需要的类似要求。
117
建造者、供货商或制造商应证明存在有一个机构，对于各个有关方在编程系统的研制、使用和维护方面的信息，负责进行收集。
对于1E级系统，要求实施这一信息收集工作。
对于非1E级系统，预先存在有这一机构可以提高在已有产品的选择及其使用方面的可信度。
C5320 原先已有部件29的经验反馈
对于可用来提高原先已有部件在质量和可靠性方面可信度的经验反馈信息，应进行收集，使之形成文件，并按照明确制定的程序进行分析。
这些信息应包括：
——对经验反馈适用的部件及类型的正确标识，对全部版本应进行配置管理； ——部件的使用条件（环境、使用方式、使用的供给条件、配置、数据特性等），通过
对这些条件的描述应能判断使用条件与预计条件的相似性； ——经验反馈的数量（系统数、使用周期等）；
——探测到的异常（“故障”）以及为确定这些异常是否影响该类型中的部件和预计条
件所需要的全部信息。
这些程序应保证对原先已有部件的故障进行探测、分析和纠正，并保证把这些故障写入适当的报告中。
应对经验反馈信息进行管理，以便保证对它们的鉴别、存档和存取使用。
C 5330 原先已有部件的使用30 C 5331 软件部件
部分或全部地使用原先已有的部件是可能的，条件是要满足本节中的要求以及C 5830节的鉴定要求。
对于1E级系统，原先已有的部件在原则上应符合特殊研制部件的相同要求。 在结构文件中应鉴别出原先已有的部件，并应对之进行配置管理。
29 在本章中“部件”是指编程系统硬件单元或软件单元中的一个或一组单元，以及从A 2100节
中给定意义上的部件。
30 为安全级系统特殊研制的各个部件应遵守C 5000的要求，C 5330节唯一地适用于没有必须按
照C 5000节要求研制的原先已有的部件。
118
原先已有的部件应附有一个可对之进行试验和正确使用（特别是C 5232的a）节）的文件，它们应当按照该文件来使用，应明确指出使用的限制。
原先已有的部件应具有对其质量和可靠性的保证，这些保证可取决于产品研制的质量保证以及针对实现、试验、验证、确认和经验反馈（C 5320）所取得的信息。尤其应通过对系统结构和这些部件使用情况的考虑，判断这些保证的充分性。
当应用经验反馈来改善在质量和可靠性方面的可信度时，应当： ——如果不相同时，证明与应使用部件的相似性； ——证明使用条件的相似性；
——证明已知的异常情况不会影响该类型的产品和预期的使用。
C 5332 硬件部件
如果微处理器的质量和可靠性保证是充分的话，允许使用微处理器。
对于1E级系统，从外部看到的微处理器的运行不应当影响软件的确定性特性。如果某些装置可较好地控制已有微处理器的特性，应当使用这些装置。
C 5333 编程的电气部件 C 5333-1 特点
允许使用编程的电气部件（CEP），条件是这些部件遵守本节后面说明的条件。 编程的电气部件具有下述特点： ——包含有编程的电子线路；
——保证设计时确定的主要的专用功能； ——是一种功能上独立的部件； ——用户可设定参数但不可编程。
作为对其主要功能的补充，编程的电气部件具有某些次要功能（例如标定、信息查 询、自动测试或参数修改）。
作为举例，被认为是编程电气部件的有下述部件（当它们包含有编程电子线路时）：继电器、传感器、记录仪、调节器、定位器、驱动设备、电气机柜的单元。
作为举例，不认为是编程电气部件的有：分散的自动装置、信息网络、接地母线。
119
C 5333-2 要求
编程电气部件应具有对质量和可靠性的充分保证。 编程电气部件的特殊使用要求针对下述几点： ——它们的研制周期；
——对它们的硬件部件和软件部件进行的监督； ——可由它们利用的经验反馈； ——它们的鉴定。
应逐一按情况确定关于编程电气部件的特性、它们的研制周期、部件的监督以及经验反馈等的选择准则。
对于编程电气部件研制周期的每一个阶段，供货商应提交为验证这一部件以及过渡到下一阶段所需要的文件。供货商还应指出对软件采取的策略和进行的试验，以及为保证其运行安全所采取的预防措施。最后，供货商应提交该产品的技术文件和功能文件以及有关产品维护的文件，这些文件应产生于产品的研制周期。
为了监督硬件部件和软件部件，供货商应指出所建立的组织（见C 5246-1、A 3206、B 1400和E 2000）。对于软件和编程电路的每一项修改都应表现为一种新型的部件。
对于经验反馈，编程电气部件的供货商应提供在某些类似的使用情况下可以使用的信息(例如这些部件的使用数量、软件的版次、纠正的差错„„）。对于已实施修改进行的鉴别和分析应由供货商完成。
对于鉴定来说，供货商应指出使用的标准，以便证明应该在安全级系统中使用的编程电气部件的研制质量和能力。鉴定应按照C 5800节来完成，鉴定的目的是确证编程电气部件在其所有的运行方式下主要功能的良好运行。补充试验应针对编程电气部件的次要功能，以确认次要功能的使用不干扰主要功能。这些试验尤其应确证次要功能使用的错误控制或错误参数不影响主要的功能。
这些试验可确证编程电气部件与规格书相比的一致性（处在正常运行范围内的一些输入意味着编程电气部件的正常运行，超出正常运行范围的一些输入意味着编程电气部件的特殊状态）。
编程电气部件次要功能的使用应在现场的运行中确定，但是应当提及的一件事是，联锁功能是在编程电气部件设计时预定的。如果存在这些联锁功能，则应予以使用。
120
C 5333-3 编程电气部件与编程系统的接口
一个编程电气部件的连接的分级是与该部件的使用功能的分级相同的。
C 5333-4 补充功能鉴定的文件
作为编程电气部件鉴定（见C 5800）的补充，应构成一个补充功能鉴定的文件。该文件阐明对以前的要求给出的技术答案，应包括：
1. 技术描述
这涉及到鉴别编程电气部件中使用的基本部件，例如： ——微控制器或微处理器；
——其它的编程电路：ASIC、FPGA„„； ——存储器；
——模/数(A/N)转换器； ——主要的软件部件。 2. 功能描述
这涉及到鉴别编程电气部件的功能，例如： ——主要功能； ——次要功能； ——与外部的接口；
——各种运行方式（正常的和降级的）； ——性能（响应时间、准确度、通频带）； ——故障情况下的退防状态；
——应遵守的使用限制（特别是设备之间的相容性）。 3. 实施的质量保证描述
这涉及到鉴别软件研制质量的代表性文件： ——供货商的质量保证； ——软件研制的各个阶段； ——阶段结束审查。 4. 关于软件可靠性的信息
这涉及到汇集关于软件的信息：
121
——供货商进行的分析或研究；
——对现行标准而言的使用证明，同时完整地鉴别已证明的产品、证明条件、证
明方法和证明结果以及证明的机构。
5. 补充试验描述
这涉及到通过加强的功能确认对软件进行的补充试验，这些试验应具有功能复盖以便确认：
——在各种运行方式下编程电气部件的主要功能；
——主要功能不受次要功能的干扰，特别是联锁装置的有效性（如果存在的话）。 6. 关于经验反馈的信息
这涉及到鉴别：
——供货商为管理经验反馈设置的组织； ——供货商经验反馈的数量； ——编程电气部件的类似使用情况； ——由供货商实施的经验反馈利用。 7. 变更管理过程描述
这涉及到鉴别：
——供货商为变更管理设置的组织；
——供货商为管理硬件部件和软件部件设置的组织。
该文件应根据供货商提供的信息适应编程电气部件的复杂性和分级。
通过编程电气部件的选择准则和允许的使用方式将按照具体情况区别1E级和非1E级的编程电气部件。
C 5400 软件工具的使用
对于为研制和变更软件形成的软件工具和使用，应进行鉴别并形成文件，软件工具的使用规则在文件中确定。
对于软件部件的每一个部件或部件组，该文件鉴别出用来对软件进行制作、试验或验证的所有软件工具的版次，该文件还可以评价共模故障的影响。尤其是每一个部件的生产历史可以鉴别出所用的一个版本软件工具的运行异常对于全部软件部件的影响。
122
C 5500 系统在现场的安装
安装文件应规定编程系统如何进行安装，以及为验证编程系统已被正确地安装和配置所应采取的措施。
安装报告应说明编程系统实际被安装所采取的方式。 在现场在充分长的期限内对编程系统的运行情况进行观察。
C 5600 维护——变更
“变更”一词在这里包含了系统（硬件、软件、结构、实现）与原始设计相比所作的所有修改。在可配置的编程系统情况下，这一术语还包括除了可由操作员修改的参数以外配置参数的修改。
对于1E级系统，CEI 60880第9章的要求特别适用。
C 5610 一般要求
为现场的硬件维护和新版软件安装所必需的程序和文件应考虑它们可能对核电站安全产生的影响，并应进行审查和适时修订，以便考虑如经验反馈数据和审查结果等新资料。
C 5620 硬件维护
应将硬件的维护程序形成文件。
C 5630 变更
应完整地将变更形成文件，编程系统及其部件的文件应适时地进行修订。 每项变更无论其起因如何，都应构成一个文件。该文件包括： ——变更申请； ——影响和可行性分析；
——变更的详细描述（为实现所需的操作范围以及应进行的验证范围）； ——引导作出决定的程序。
实施变更应遵守为初始研制表达的要求。在将变更引进现场之前应进行不退化试验和验证，以便证明该变更不损害编程系统完成其安全级功能的能力。在变更的范围内应证明所进行的试验和验证的恰当性和充分性。应遵守试验和验证的策略准则（C 5244-3和C
123
5251）以及确认的策略准则（C 5244-6和C 5261）。
对变更涉及到的所有文件都应进行修改并参考变更申请。变更报告概述所有采取的行动。所有这些文件都应标上日期、进行标识和存档，以便构成一个已经过标识的软件版本，基本文档应适时修订（对于硬件的基本文档，见A 3206）。
如果在研制过程中出现了变更，只有影响到已经过认可的单元的那些变更才需要新的认可。
经确认后发生的每一项变更意味着要把新确认的详细描述纳入到变更文件中。
C 5700 质量保证
质量保证规则应符合A 5000的要求，这通过下面的要求来明确表达。
C 5710 质量计划
质量计划应描述编程系统的研制和变更过程，其中包括软件方面。 质量计划尤其应明确指出： ——研制周期的说明；
——与各个研制阶段有关的关键性审查（C 5222）的方式； ——在该项活动过程中所使用的原先已有的单元；
——工作组在使用的技术和软件工具方面培训的证明资料； ——对于全部软件或只对安全级软件的适用规则； ——配置管理系统；
——对软件复制和软件保护应使用的方法。
C 5720 文件
重要文件31应当由其能力覆盖有关技术领域和所用技术的、没有参与文件编制的专家组进行审查。
对于负责进行文件的验证和确认、文件使用和文件保管的人员，文件应当是容易理解的。
31 重要文件在这里是指作为本章中要求目标的所有文件。
124
C 5730 存档
为了可使系统的鉴定（C 5800）得以维护、变更和保持，一个存档大纲应描述和论证： ——文件和有关支持手段（特别是工具和信息平台）的类型； ——存档期限（至少，最新有效版本的寿期为5年以上）； ——以及存档方式。
C 5800 编程系统的鉴定
本章通过软件的确认，确证遵守C 5000节描述的软件设计、软件研制和软件实现的要求，从而补全了编程系统从B卷意义上的鉴定。
本章还补全了为硬件特有的B卷中的要求，以便确证支持软件执行的硬件在规定的所有条件下是有效的。因此，鉴定大纲使用由系统软件和动态验证软件补全的硬件平台。
编程系统的鉴定：
——在功能方面，基于软件部件的确认（C 5244-6）和系统的确认（C 5260）； ——在软件研制周期方面，基于对遵守C 5000的设计、研制和实现等要求所进行的验
证；
——在执行的硬件支持方面，基于C 5820中规定的鉴定试验。 编程系统的鉴定包括下述几个阶段： ——建立鉴定的参考基准； ——确定鉴定大纲； ——实施鉴定大纲； ——编制鉴定报告。
C 5810 鉴定的参考基准
应当建立鉴定的参考基准，这一参考基准应鉴别C 5100、C 5200、C 5300和C 5700节中应当证明予以满足的要求。
在软件变更情况下，C 5600节的要求应予以满足。
C 5820 鉴定大纲
鉴定大纲应确定所采取的策略、鉴别已有的单元、并确定为完成鉴定所必需的手段。
125
鉴定大纲应对参考基准的每一个要求确定： ——鉴定行动（分析、试验„„）；
——这些论证适用于哪些版本、什么样的配置、哪些部件或部件组合件，并论证它们
的代表性；
——应使用的手段，或者当证明已经存在时，说明这些证明的由来； ——预计的结果。
鉴定试验用动态验证软件来进行，该软件可验证硬件平台的良好运行。这些试验按照具体情况来确定，并可覆盖系统的硬件。
C 5830 鉴定大纲的实施
对于鉴定大纲中鉴别的每一项行动，鉴定大纲（C 5820）的实施在于： ——或者验证已经存在的信息； ——或者完成行动。
对这些已经存在的信息（在确认时由供货商或由独立实验室完成的试验、在研制期间完成的审查、在获得原先已有部件时进行研究得到的信息、来自经验反馈的信息等）应进行验证。
尤其是，使用来自经验反馈的信息应满足C 5300中表达的要求。
对于系统软件，确认基于对供货商文件进行的分析。在供货商提供的文件并不充分的情况下，按照具体情况确定一些补充试验和分析，并在平台上予以完成。
对于应用软件和对于整个系统，鉴定大纲利用软件部件研制所产生的文件以及软件研制时已经完成的试验（在工厂中以及在现场的功能试验），以便确证与规格书的一致性。
C 5840 鉴定报告
鉴定报告应符合B 2400，并明确和补充下述要求：
——应予鉴别的要点是鉴定行动所针对的目标（系统、配置、版次、部件）； ——对鉴定行动（进行的分析和试验）和实施鉴定的条件应明确地进行描述； ——各项鉴定行动的记录应明确地指出所获得的结果，并应鉴别与预计结果相比的偏
差；
——应提供可以检验原先已有证明可信性的资料。
126
来自核电站设计和仪表控制 总体设计的数据 表达需求 — C 5210 系统规格书 — C 5220 确定系统结构 — C 5230 软件规格书 —C 5241 质量保证 硬件规格书 -C 5700 应用软件规格书 系统软件规格书 —C 5242 —C 5242 确定硬件结构 确定应用软件 确定系统软件 结构—C 5243 结构—C 5243 软件工具 使用— -C 5400 实现应用软件 实现系统软件 实现硬件 —C 5244 —C 5244 系统集成 — C 5250 系统确认 — C 5260 系统安装 — C 5500 维护、变更 — C 5600 由C 5000包括 在C 5000之外
图5-1 在研制编程系统时所涉及的主要技术活动
127
以前经验 -C 5300 鉴定 -C 5800
因篇幅问题不能全部显示，请点此查看更多更全内容