1、道雪ICS 27.120.20 F 83 和国国家标准-=f:I工./、中华人民GB/T 13629-2008 代替GB/T13629一1998核电厂安全系统中数字计算机的适用准则Applicable criteria for digital computers in safety systems of nuclear power plants 2009-04-01实施2008-07-02发布发布中华人民共和国国家质量监督检验检菇总局中国国家标准化管理委员会、/伪防码鼓、 GB/T 13629-2008 目次T41i1i1ipO句i哼，。，qu1A14。L。49qh。，。b9。b。bqLqhq
2、臼ndA&FDQd勺nUA啥141A1-A1A唱IA唱EA-A141&141A1141AnLqJqu系关互相u的wm认m确陆咱i-Z+比适出的卫定机决寸确算解岛的计和u性凉G求级别性靠要uu与需品鉴立可计求准性商的独机设要标样有害信算和计本多现危通计能设准成力HHUU功和)件基则完定性能厂虑的能靠录录录录录录眠LA时翩翩阳挫耀栅-r植树酵崎阳阳倒叫四四川叫叫引定统统故动质的性和显控.设组工性令置源料料料料料料U性和系系一护量备统立验息近护识助机因靠指装力喷资资资资资1维标辅多人可围范语全全单保质设系独试信接测行动ABCDEFHU言范规术安安123456789川口uuuu监执对录录录录录录如前1
3、2345旦旦旦旦丘丘丘丘旦旦丘旦旦丘丘678附附附附附附参GB/T 13629一2008前言本标准修改采用美国标准IEEEStd 7-4. 3. 2-2003 (核电厂安全系统中数字计算机的造用准则)(英文版)，技术内容等同，只是将IEEEStd 7-4. 3. 2中引用的美国标准改为相应的我国标准，编写方法和格式符合GB/T1. 1一2000的要求。本标准代替GB/T13629-1998(核电厂安全系统中数字计算机的适用准则。本标准与GB/T13629-1998相比主要变化如下z一一第5章中增加了5.3.6软件工程风险管理和5.5.3故障探测和自诊断;将独立验证与确认的内容放入正文，增加了5
4、.3.4独立验证与确认要求，而删除了附录E验证与确认;将取消的5.3.2现有商品级计算机的质量鉴定修订为5.4.2，并细化了相关的要求;一一取消了附录C抗电磁干扰能力气-一将附录F异常状态和事件的鉴别和解决修订为附录D危害的鉴别和解决，并重新编写了该附录;一二取消了附录1核电厂用软件的质量保证要求气一取消了附录J本标准附录中引用的标准。本标准的附录A、附录B、附录C、附录D、附录E、附录F都是资料性附录。本标准由中国核工业集团公司提出。本标准由全国核仪器仪表标准化技术委员会(SAC/TC30)归口。本标准起草单位z核工业标准化研究所。本标准主要起草人z高丽艳、王忠秋、耿文行。本标准所代替标准的
5、历次版本发布情况为:一一-GB/T13629-1998。I 核电厂安全系统中数字计算机的适用准则GB/T 13629-2008 1 范围本标准规定了计算机用作核电厂安全系统设备时的一般原则。本标准的要求与GB/T13284. 1一2008一起规定了计算机用作安全系统设备时的最低功能要求和设计要求。本标准适用于核电厂安全系统数字计算机。2 规范性引用文件下列文件中的条款通过本标准的引用而成为本标准的条款。凡是注日期的引用文件，其随后所有的修改单(不包括勘误的内容)或修订版均不适用于本标准，然而，鼓励根据本标准达成协议的各方研究是否可使用这些文件的最新版本。凡是不注日期的引用文件，其最新版本适用于
6、本标准。GB/T 9225 核电厂安全系统可靠性分析一般原则(GB/T9225 1999 , eqv ANSI/IEEE Std 352-1987) GB/T 13284. 1-2008核电厂安全系统第1部分z设计准则(lEEEStd 603-1998 , NEQ) GB/T 13286 核电厂安全级电气设备和电路独立性准则(GB/T13286 2001 , eqv ANSI/IEEE Std 384-1992) EJ/T 694 核工业计算机软件质量保证规范EJ/T 743 核工业计算机软件配置管理计划编制指南EJ/T 1058 核电厂安全系统计算机软件HAF 003 核电厂质量保证安全规定
7、IEEE Std 1012-1998 软件验证与确认的IEEE标准IEEE Std 1061-1998 软件质量度量方法的IEEE标准IEEE Std 1042 软件配置管理的IEEE指南IEEE Std 1540 生存周期过程的IEEE标准一风险管理IEEE/EIA 12207.0-1996 信息技术标准一软件生存周期3 术语和定义3. 1 3.2 下列术语和定义适用于本标准。验收试验acceptance testing 1) 为确定系统是否满足验收准则并使客户确定是否接收该系统而进行的正规试验(也可参见鉴定试验、系统试验); 2) 为使用户、客户或其他授权机构确定是否接收一个系统或设备而进
8、行的正规试验。应用软件application software 为满足某一用户特定的需要而设计的软件，例如用于导航、薪金表或过程控制的软件。1 GB/T 13629-2008 构结m以阳阳IE件盯部或构统结系-J 句33.4 商品级物项commercial grade item 满足下述条件的物项z1) 不是为核设施专门设计或不以核设施特有的技术要求为条件;2) 用于非核设施;3) 按制造厂产品说明(例如样本)中规定的技术条件从制造厂或供货商处采购。3.5 商晶纽物项适用性确认commercial grade item dedication 为了充分确信商品级物项造合于核安全应用，对商品级物项
9、进行评价和验收的过程。3.6 复杂性complexity 1) 对一个系统或系统部件的设计或实现难于理解或验证的程度;2) 测量定义1)中属性的任一组基于结构性的度量。3. 7 部件component 组成系统的一个部分。一个部件可以是硬件或软件，并可以再细分成其他的部件。注2术语模块飞部件和单元通常可相互交换使用，或取决于上下文，以不同的方式作为另外一个定义的补充.这些术语的相互关系尚没有标准化。3.8 计算机computer 由一个或多个关联的处理单元和外部设备组成的、由内部贮存的程序控制的、不用人为干预便能执行真实计算(包括大量的算术运算或逻辑运算)的功能可编程装置。3.9 计算机指令c
10、omputer instruction 1) 编程语言中的语句，它规定了计算机执行的操作，以及与操作数有关的地址或数值，例如将A移动到B;2) 简单地说，计算机程序中任何可执行的语句。3. 10 计算机程序computer program 可使计算机硬件执行运算或控制功能的计算机指令和数据定义的组合。3.11 计算机系统computer system 包含一个或多个计算机及相关软件的系统。3. 12 配置configuration 1) 由数字、属性定义的计算机系统或部件的排列，及其各组成部分之间的相互联系;2) 在配置管理中，是指在技术文件中规定的或产品达到的硬件或软件的功能和物理特性。2
11、GB/T 13629-2008 3. 13 配置控制configuration control 配置管理的一个要素，包括在配置项的配置标识正式建立后对配置项变更的评价、协调、批准或不批准，以及实施。3. 14 配置项configuration item 在配置管理过程中指定要进行配置管理并作为一个整体处理的硬件、软件或两者兼有的集合体。3.15 配置管理configuration management 采用技术及行政管理和监督的一种规定，以识别或用文件证明配置项的功能和物理特性、控制对这些特性的变更、记录和报告变更过程和实施状态，并核实与规定要求的一致性。3. 16 3. 17 3. 18 3
12、. 19 3.20 3.21 正确性correctness 1) 在系统或部件的技术规范、设计和实现中无缺陷的程度;2) 软件、文档或其他物项满足技术要求的程度;3) 元论规定与否，软件、文档或其他物项满足用户需求和预期的程度。数据data 1) 以易于交流、理解，或被人员/自动手段处理的方式对事实、概念或指令的一种表达方式;2) 有时用作文挡的同义词。鼓据结构data structure 数据各元素之间的物理或逻辑关系，用于支持特定的数据处理功能。设计d臼ign1) 确定一个系统或部件结构、组成、接口和其他属性的过程;2) 定义1)中过程的结果。文件document 1) 一种介质及其所记录
13、的信息，通常有永久性并可被人或机器读出。例如在软件工程中包括工程计划、规范、试验计划和用户手册z2) 创建在1)中定义的一个文件;3) 向计算机程序中添加注释。文档documentation 1) 某一特定主题的文件集合;2) 对活动、要求、过程或结果进行描述、规定、说明、报告或证明的任何文字的或图表资料53) 文件产生或修订的过程z的文件管理，包括标识、收集、处理、储存和分发。3.22 差错eor 1) 一个计算的、观测的或实测的数值或条件与真实的、规定的或理论的数值或条件之间的差异，例如，计算结果与正确值之间差30m; 3 GB/T 13629-2008 3.23 3.24 3.25 3.
14、26 3.27 3.28 3.29 2) 不正确的步骤、过程或数据定义，例如在计算机程序中不正确的指令;3) 不正确的结果，例如当正确值为10时计算值为12;的产生不正确结果的人的行为。例如在编程器或操作器上的错误动作。注:当4个定义共同使用时，通常将定义1)称为误差，将定义2)称为故障，将定义3)称为失效，将定义的称为失误。执行execution 计算机完成计算机程序中一条或多条指令的过程。失效failure 一个系统或部件不能在规定的性能要求内执行所要求的功能。注2故障容错规则区分人的行为(失误)、其表现形式(硬件或软件故障)、故障的后果失效)，以及其结果为不正确差错的总量，故障fault
15、1) 在硬件或部件中的缺陷，例如短路或断线;2) 在计算机程序中的不正确的步骤、过程或数据定义。注:该定义主要由故障容错理论使用，在通常情况下，差错和隐错用于表达同一含义。固件firmware 硬件装置和以只读软件方式驻留在该装置中的计算机指令和数据的组合。功能function 一个系统或部件规定的目的或作用。例如，一个系统可将总量控制作为其主要的功能。功能单元functional unit 能完成一个规定目的的硬件、软件或两者兼有的实体。硬件hardware 用于处理、贮存或传输计算机程序或数据的物理设备。3.30 危害hazard 事故的一种先决条件。危害包括外部事件以及计算机硬件和软件的
16、内在条件。3.31 危害分析hazard analysis 研究和确定由正常的设计审查和测试过程未鉴别出来的条件的过程。通过对包括异常事件和带有劣化的设备和系统的核电厂运行的分析，使危害分析的范围扩展到核电厂超设计基准事件。危害分析主要关注系统的故障机理而不是验证正确的系统运行。3.32 实现implementation 1) 将设计转化为硬件设备、软件设备，或两者兼有的过程z2) 定义。过程的结果。4 GB/T 13629-2008 3.33 接口interface 3.34 3.35 1) 信息通过的共享边界;2) 用于将信息从一个部件传输到其他部件为目的的，连接两个或多个部件的硬件或软件
17、设备。模块module 1) 就编译、与其他单元的组合及下载而言是分离的和可标识的程序单元。例如向一个汇编程序、编译器、连接编辑器或执行程序的输入，或从其来的输出;2) 一个程序中逻辑上可分离的部分。规程pr创edure1) 为解决问题或为完成给定的任务而采取的动作的过程;2) 定义。中动作过程的书面描述，例如，文件化的试验程序53) 指定的并执行规定动作的计算机程序的一部分。3.36 鉴定试验qualification testing 为向用户证明软件物项或系统满足其规定的要求而进行的试验。3.37 3. 38 需求requirement 1) 用户为解决某一问题或达到某个目标所要求的条件或
18、能力;2) 为满足合同、标准、规范或其他正式规定的文件、系统或系统部件应满足的和具备的条件或能力;3) 在1)和2)中规定的条件或能力的文挡化的陈述。需求规格书requirements specification 规定对系统或部件需求的文件。通常包括功能要求、性能要求、接口要求、设计要求和研制标准。3.39 3.40 3.41 软件software 与计算机系统运行有关的计算机程序、规程，以及相关的文档或数据。软件维护software maintenance 1) 为改正错误、提高性能或其他特性、或者为适应变化的环境，而对交付后的软件产品进行的修改;2) 为确保已安装的软件能按照预期连续运行并
19、实现在系统运行中预期的作用而进行的一系列活动。软件维护包括改进、用户帮助，以及相关的活动。软件质量度量software quality metric 其输入为软件数据，输出为单一数值的一种函数，该数值可以被认为是软件具有影响其质量的特性的程度。3.42 软件工具software tools 一种用来开发、测试、分析或维护其他程序或其文件的计算机程序。例如:比较程序、交叉引用生成程序、反编译程序、驱动程序、编辑程序、流程图程序、监控程序、测试案例生成程序和时序分析程序。5 GB/T 13629-2008 3.43 规格书sp配ification以完整的、准确的和可验证的方式规定了系统的要求、设计
20、、行为或其他属性的文件，以及用于确定是否满足这些规定的程序。3.44 系统system 构成完成特定的功能或功能组的设备集合。3.45 系统软件system software 为了便于计算机系统及其相关程序的运行和维护而设计的软件。例如操作系统、汇编程序和实用程序。3.46 系统试验system testing 为了评价一个完整的已集成的系统与其规定要求之间的一致性，对该系统进行的试验。3.47 试验test 3.48 3.49 1) 在规定的条件下操作一个系统或部件、观察或记录其结果，及对系统或部件的某些方面进行评价的过程$2) 对软件物项进行分析以发现现有状态与要求条件之间的差异(即隐错)
21、，并评价软件物项特性的过程。试验大纲test plan 1) 描述预期试验活动的范围、方法、资源和进度的文件，它规定了试验项目、试验特点、试验任务、每项任务的完成者，以及需要执行应急计划的风险;2) 描述对一个系统或部件进行试验所遵循的技术和管理方法的文件。典型的内容应规定被试验物项、需要执行的试验任务、责任、进度，以及试验活动所需要的资源。确认validation 在研制过程中或完成时评价一个系统或部件以确定其是否满足规定要求的过程。3.50 3.51 验证verification 1) 为确定某一研制阶段的产品是否满足该阶段开始时规定的条件，而对一个系统或部件进行评价的过程;2) 计算机程
22、序正确性的正式证明。验证与确认verification and validationCV &V) 确定对一个系统或部件制定的要求是否完整和正确、每个研制阶段的产品是否满足前一个阶段提出的要求或条件，以及最终的系统或设备是否符合预定要求的过程。4 安全系统设计基准6 关于本标准与GB/T13284. 1-2008的关系参见附录A。见GB/T13284. 1-2008中第4章，参见附录B。GB/T 13629-2008 5 安全系统准则本章按GB/T13284. 1一2008第5章的顺序列出安全系统准则。对有些准则，除了GB/T13284. 1-2008的规定以外没有附加要求。而对另外一些准则，本
23、章给出其附加要求。5. 1 单一故障准则见GB/T13284.1-2008中5.1，参见附录Bo5.2 保护动作的完成见GB/T13284.1一2008中5.205.3 质量硬件质量要求见GB/T13284. 1一2008中5.30软件质量要求见IEEE/EIA12207.0及其支持性标准。计算机的研制活动应包括计算机硬件和软件的研制。在研制过程中应考虑计算机硬件与软件的集成以及计算机与安全系统的集成。典型的计算机系统研制过程由下述生存周期的过程组成:a) 建立系统的概念设计，将概念设计转化为具体的系统需求;b) 使用这些需求进行详细的系统设计;c) 实现硬件和软件功能的设计Fd) 功能试验以
24、保证需求的正确实现;e) 系统安装并进行现场验收试验;f) 系统运行和维护;g) 系统退役。为了符合质量准则，除了GB/T13284. 1-2008的要求之外，还应满足下述活动的附加要求:a) 软件研制;b) 现有商品级计算机的质量鉴定(见5.4.2); c) 软件工具的使用;d) 验证与确认pe) 配置管理;f) 风险管理。5.3.1 软件研制计算机软件应按经批准的软件质量保证大纲进行研制、修改或验收，这一质量保证大纲应与IEEE/EIA 12207.0-1996的要求相一致。软件质量保证大纲应考虑运行时计算机的所有常驻软件(即:应用软件、网络软件、接口程序、操作系统以及诊断程序)。编制软件
25、质量保证大纲的指导见EJ/T1058 和EJ/T694 0 在整个软件寿期内，应考虑使用软件质量度量以评价其是否满足软件质量要求。当使用软件质量度量时，应考虑下述的生存周期阶段特性:a) 正确性/完整性(需求阶段); b) 与需求的一致性(设计阶段hd 与设计的一致性(实现阶段hd) 功能与需求的一致性(试验和集成阶段he) 现场功能与需求的一致性(安装和调试阶段); 0 性能历史记录运行和维护阶段)。在软件研制文档中应包括为评价软件质量特性而选择度量的依据。IEEEStd 1061-1998提供了软件质量度量的应用方法。7 GB/T 13629-2008 5.3.2 软件工具为支持软件研制过
26、程和V&.V过程而使用的软件工具应纳入配置管理。应采用下述一种或两种方法以确认软件工具适合于它的应用:a) 应开发测试工具确认程序以证明软件工具具有所要求的特性zb) 未能被软件工具发现到的缺陷应能通过V&.V活动发现。软件工具的运行经验可提供在工具适宜性方面的附加可信度，特别是当评价未探测缺陆的可能性时。5.3.3 验证与确认(V&V)V&V是程序管理和系统工程组活动的延伸。在整个系统生存周期中，V&.V用于确定有关数字系统质量、性能和研制过程与整个生存周期一致性的目标数据和结论(即主动反馈)。反馈包括与系统及其接口的预期运行条件有关的不符合项报告、性能改进及质量提高。V&.V过程用于确定某
27、一活动的研制产品是否满足该活动的要求，以及系统是否按照其预期的用途和用户的需求在运行。这种适宜性的确定过程包括对产品和过程进行的评价、分析、审查、检查和测试。本标准采用IEEEStd 1012-1998规定的过程、活动和任务的定义，其中软件V&.V过程被分解为多项活动，活动又被进一步分解为多项任务。术语V&.V工作通常用来指V&.V过程、活动和任务的这种构架。V&V过程应专注于计算机硬件和软件、数字系统部件的集成以及计算机系统与核电厂的相互作用。V&.V活动和任务还应包括对最终集成的硬件、软件、固件和接口的系统试验。应依据IEEEStd 1012-1998进行软件V&.V工作。IEEEStd
28、1012-1998对最高完整性等级(第4级)的V&.V要求适用于按照本标准研制的系统。5.3.4 独立验证与确认要求(lV&V)上节论述了应进行的V&.V活动，本节规定了V&.V工作所要求的独立性程度。IV&.V活动由三个方面组成，即技术独立性、管理独立性和财务独立性。在IEEEStd 1012-1998的附录C中对这三个方面进行了说明。研制和测试应由具有适当技术能力的、没有参加原设计的人员或小组进行独立的验证与确认。IV&.V工作的监督应由研制和程序管理组织之外的机构来进行。IV&.V工作应独立地选择za) 需要分析及测试的软件和系统部分;b) V&. V的技术;c) 需对之采取行动的技术问
29、题和难点。应为IV&.V工作分配独立于研制活动的资源。关于IV&.V的附加信息见IEEEStd 1012-1998的附录c.5.3.5 软件配置管理8 应按IEEEStd 1042的要求进行软件配置管理。编制软件配置管理计划的指导见EJ/T743. 至少应进行下述活动za) 所有软件设计和程序代码的标识和控制;b) 所有软件设计功能数据(数据模板和数据库)的标识和控制;c) 所有软件设计接口的标识和控制;d) 所有软件设计变更的控制ze) 软件文档(用户文件、运行和维护文件的控制;f) 对提供安全系统软件的软件供应商研制活动的控制zg) 与软件设计和程序代码有关的鉴定信息的控制和获取;h) 软
30、件配置审查;i) 状态统计。GB/T 13629-2008 其中某些功能或文件可由其他的质量保证活动来完成或进行控制。在这种情况下，软件配置管理大纲应说明责任的分工。应在软件生存周期过程中适当的点建立软件基线，以使工程和文档活动相同步。基线建立后产生并经批准的变更应添加到基线中。对实施配置管理的软件的标签应包括每个配置项的唯一性的标识，以及每个配置项的版本号和(或)日期时间标志。应按照软件配置管理计划，对软件/固件的变更正式形成文件并得到批准。该文档应包括变更的原因、受影响的软件/固件的标识，以及变更对系统的影响。此外，文档还应包括变更在系统中实施的计划(立即实施变更，或未来版本变更的时间表)
31、。5.3.6 软件工程凤险管理软件工程风险管理是一种用于问题预防的工具，鉴别可能出现的问题、评价这些问题的影响，并确定为确保达到软件质量目标应考虑的潜在问题。在数字系统工程的各个层次应进行风险管理以充分覆盖每个可能的问题领域。软件工程风险可包括与技术、进度或资源有关的风险，这些风险可能损害软件的质量目标，从而影响安全系统计算机执行安全相关功能的能力。正如3.31的定义一样，软件工程风险管理与危害分析的不同之处在于在危害分析中仅关注系统失效机理中技术方面的因素。风险管理应包括下述步骤za) 确定数字系统风险管理的范围;b) 规定和实施适当的风险管理策略;c) 在工程风险管理策略中鉴别软件项目的风
32、险，以及它们在项目实施过程中的演变;d) 分析风险以确定缓解风险的优先次序;e) 对可能显著影响软件质量目标的风险编制风险缓解计划，并采用适当的度量来跟踪问题的解决过程(这些风险包括可能损害安全计算机系统执行安全相关功能能力的、与技术、进度或与资源有关的风险h。当未达到预期的质量时采取的纠正措施;g) 为解决软件工程风险，建立一个在工作人员之间及团队间能够进行有效交流的工作环境。IEEE/EIA 12207.0-1996和IEEEStd 1540提供了有关风险管理的附加指南。5.4 设备质量鉴定除满足GB/T13284. 1-2008中5.4要求的设备质量鉴定准则外，对安全系统中使用的数字计算
33、机的鉴定还应满足下述要求。5.4. 1 计算机系统鉴定试验计算机系统鉴定试验应在计算机运行并使用其实际操作中所用的代表性软件和诊断程序时进行。对于计算机完成安全功能所必需的所有部分，或者其运行或故障可能对安全功能有损害的部分，都应在鉴定过程中进行试验。确切地说，这包括存储器、CPU、输入和输出、显示功能、诊断、相关部件、通信路径和接口的试验和监测。试验应证明已满足与安全功能有关的性能要求。5.4.2 现有商品级计算机的质量鉴定关于现有商品级计算机适用性确认的信息参见附录C。应通过使用本标准的准则评价硬件和软件的设计来实现质量鉴定过程。鉴定的接受应基于证据，证明数字系统或部件包括硬件、软件、固件
34、和接口能执行其要求的功能。验收及其依据应形成文件并与鉴定文件一同保存。在那些传统的鉴定过程不适用的情况下，为验证一个设备可用于安全应用的一种替代方法是商品GB/T 13629-2008 级物项的适用性确认。商品级物项适用性确认的目的是验证被确认的物项在质量上与按照HAF003 的设备是相当的。对计算机的适用性确认应鉴别对计算机物理的、性能的及研制过程的要求，以便对拟用的数字系统或设备能够执行安全功能提供足够的可信度。适应性确认过程适用于完成安全功能所需的硬件、软件和固件。只要有可能，对软件和固件的适用性确认过程应包括对设计过程的评价。在某些情况下，不能将设计过程作为适用性确认过程的一部分来进行
35、评价。例如，实施评价的机构可能得不到安全系统中使用的微处理器芯片设计过程的信息。在这种情况下，不可能进行评价以支持适用性确认。由于适用性确认过程涉及到生存周期过程的所有方面及制造质量，因此商品级物项的适用性确认应限于与其预期使用有关的在功能上相对简单的物项。商品级物项的适用性确认包括初步阶段和详细阶段的活动，这些阶段的活动在下面描述。5.4.2. 1 商晶级物项适用性确认过程的初步阶段在初步阶段，应评估风险和危害、确定安全功能、建立配置管理和确定系统的安全类别。5.4.2. 1. 1 评估系统安全功能的凤险和危害应进行分析以确定安全系统的功能和性能要求，该分析应鉴别妨碍完成安全功能的风险和危害
36、。5.4.2. 1.2 商晶纽物项应执行的安全功能一旦确定了系统级功能和评估了风险和危害，适用性确认机构应确定由商品级物项执行的安全功能。这一过程应考虑由商品级物项执行的所有安全功能，以及商品级物项功能对其他安全相关功能或接口的可能影响。5.4.2. 1. 3 建立配置管理控制在安全系统中使用的商品级物项应受配置管理过程所控制，该管理过程提供了商品级物项研制生存周期过程的可追踪性。5.4.2.2 商晶级物项适用性确认过程的详细阶段在商品级物项适用性确认的初步阶段后，应使用详细的验收准则对商品级物项的可接受性进行评价。应通过技术评价确定将对安全系统中使用的商品级物项进行评估用的关键特性，每个关键
37、特性都应是可检验的(例如，通过检查、分析、演示或试验)。本标准使用商品级物项的下述三类关键特性:a) 物理特性:包括几何尺寸、电源要求、部件号、硬件和软件的型号及版本号，以及数据通信要求等sb) 性能特性:包括响应时间、人机功能要求、存储器分配、在异常工况下安全功能的执行、可靠性、差错处理、要求的嵌入功能、以及环境鉴定要求例如地震、温度、湿度和电磁兼容性)等;c) 研制过程特性z包括支持生存周期过程的那些特性(例如验证与确认活动、配置管理过程和危害分析)，以及可追踪性和可维护性。作为确定这些关键特性工作的一部分，应通过分析鉴别可能影响安全功能的危害。参见附录D.用于单独评价或组合评价物理的、性
38、能的和研制过程的关键特性的过程参见附录c.5.4.2.3 商晶级适用性确认的保持如果计算机硬件、软件或固件已按商品级物项采购，并已通过商品级物项适用性确认过程予以接受，则应通过正式的文件对已经适用性确认的计算机硬件、软件或固件的变更进行追踪。应按照形成原始接受依据的过程，对已确认的商品级计算机硬件、软件或固件的变更进行评价。在评价过程中应考虑计算机硬件修改可能对软件或固件造成的潜在影响。如果在计算机硬件、软件或固件的修改过程中省略了审批过程的某些步骤，则需要进行进一步的评价。针对特定的安全系统应用，进行计算机硬件、软件或固件的商品级物项适用性确认。当已经过适用性确认的商品级物项在安全系统中的应
39、用超出了初始适用性确认所包括的范围时，应针对新的应用进行附加的评价。支持商品级物项适用性确认过程的文件应作为配置项保存。10 GB/T 13629-2008 5.5 系统的完整性为了达到安全系统中数字设备应用的系统完整性，除了GB/T13284.1-2008中5.5的要求之外，还应满足下述要求:a) 计算机完整性设计Fb) 试验和校准设计;c) 故障探测和自诊断。5.5.1 计算机完整性设计计算机应设计成在所有可能造成安全功能失效的内部或外部条件下完成其安全功能，这些条件如输入和输出处理故障、精度或舍人问题、不适当的恢复动作、电源电压或频率波动，以及信号同时改变的最大可信数量。如果系统要求已规
40、定安全系统的优选故障模式，则计算机故障不得阻碍安全系统处于该故障模式。计算机完成重启操作不应阻止安全系统完成其功能。5.5.2 试验和校准设计试验和校准功能不得对计算机完成其安全功能的能力产生有害的影响。适当地旁通一个冗余通道并不认为是一种有害影响。应验证，试验和校准功能并不影响与校准变更(例如变更整定值)元关的其他计算机功能。当试验和校准功能由另外的计算机(例如，试验和校准计算机)完成并由该计算机提供试验和校准数据的唯一验证时，则应对这些功能要求进行v&v、配置管理和质量保证。当试验和校准功能由安全系统中的计算机来完成时，也应对这些功能要求进行v&v、配置管理和质量保证。当驻留在另外计算机中
41、的试验和校准功能不是为安全系统的计算机提供试验和校准数据的唯一验证时，则不要求对这些功能进行v&v、配置管理和质量保证。5.5.3 故障探测和自诊断计算机系统能够经受使计算机系统能力降低、但可能不被系统立即探测出来的局部故障，自诊断是一种有助于探测这些故障的手段。在本节中说明对故障探测和自诊断功能的要求。应使用安全系统的可靠性要求来建立自诊断的需求。在其故障可由其他方法及时探测出来的系统中不要求自诊断功能。如果在系统需求中包含自诊断要求，则这些功能应经历与安全系统功能相同的验证与确认过程。如果自诊断作为可靠性的必要条件，则计算机程序应包含及时探测和报告计算机系统故障和失效的功能。而自诊断功能不
42、能影响计算机系统执行其安全功能的能力，或引起安全功能的误动作。典型的自诊断功能包括za) 存储器功能性和完整性试验(例如PROM检查和RAM测试hb) 计算机系统指令集(例如计算测试hc) 计算机外部设备硬件试验(例如监视定时器和键盘hd) 计算机结构支持硬件(例如地址线和共享存储器接口hd 通讯链路诊断(例如循环冗余校验)。不会导致系统故障或系统功能缺失的罕见通讯链路故障不需要报告。当应用自诊断功能时，系统设计应包括下述自诊断特性:a) 计算机系统启动期间的自诊断;b) 当计算机系统运行时定期的自诊断zd 自诊断测试故障报告。5.6 独立性为了满足独立性准则，除了GB/T13284. 1-2
43、008中5.6的要求之外，安全通道之间或安全系统与非安全系统之间的数据通信不得阻碍安全功能的执行。11 GB/T 13629-2008 GB/T 13284. 1-2008要求安全功能应与非安全功能相隔离，以使非安全功能不会阻止安全系统执行其预期的功能。在数字系统中，安全功能和非安全功能软件可能驻留在相同的计算机中并使用相同的计算机资源。下面任何一种都是处理这一问题可接受的方法:a) 确定屏障要求，以便充分确信软件或固件的非安全功能部分不会妨碍其安全功能部分的执行，这些屏障应按本标准要求进行设计，不要求非安全软件满足这些要求:b) 如果安全软件和非安全软件之间不设置屏障，则非安全软件的功能应按
44、照本标准的要求进行研制。关于通信独立性准则的信息参见附录E。5. 7 试验和校准能力见GB/T13284. 1-2008的5.7.5.8 信息显示见GB/T13284. 1-2008的5.8。5.9 接近控制见GB/T13284. 1-2008的5.9.5.10 维护见GB/T13284. 1一2008的5.10。5.11 标识为确保所要求的计算机硬件和软件按照适当的系统配置进行安装，应满足下述对软件系统的标识要求:a) 应使用固件和软件标识以确保在正确的硬件部件上安装了正确的软件;b) 在软件中应包含相关的手段，以便使用软件维护工具可从固件中重新得到标识zd 数字计算机硬件的实体标识要求应符
45、合GB/T13284. 1-2008的标识要求。5. 12 辅助设施见GB/T13284. 1一2008的5.12.5.13 多机组核电厂见GB/T13284. 1-2008的5.13。5. 14 人因工程考虑见GB/T13284. 1-2008的5.14.5.15 可靠性除GB/T13284. 1-2008的5.15的要求以外，当规定了可靠性目标时，应证明软件也满足该目标要求。确定可靠性的方法可以包括分析与现场经验或试验的组合。软件差错记录及其趋势分析可以向分析、现场经验或试验结合使用。6 监测指令设备的功能和设计要求见GB/T13284. 1-2008第6章。7 执行装置的功能和设计要求见
46、GB/T13284.1-2008第7章。8 对动力源的要求见GB/T13284. 1-2008第8章。12 GB/T 13629-2008 附录A(资料性附录)本标准与GB/T13284. 1-2008的相互关系本标准的第4章第8章与GB/T13284. 1-2008的第4章第8章相对应。表A.1 GB/T 13284. 1-2008与本标准的关系GB!T 13284. 1-2008准则本标准补充的要求资料性附录(按标准中出现顺序)4 安全系统设计基准安全系统设计基准B 5 安全系统准则无5.1 单一故障准则元B 5.2 保护动作的完成元软件研制(见5.3.1)软件工具(见5.3.2)验证与确
47、认见5.3.3)5.3 质量D和F独立验证与确认要求(见5.3.4)软件配置管理(见5.3.5)软件工程风险管理(见5.3.6)对软件和诊断程序进行试验见5.4.1)5.4 设备质量鉴定C 现有商品级计算机的质量鉴定(见5.4.2)计算机完整性设计见5.5.1)5.5 系统的完整性试验和校准设计(见5.5.2)B和C故障探测和自诊断(见5.5.3)5.6 独立性独立性见5.6)E 5.7 试验和校准能力无5.8 信息显示无5.9 接近控制元5. 10 维护元5.11 标识标识见5.11)5.12 辅助设施无5.13 多机组核电厂无5.14 人因工程考虑元5.15 可靠性可靠性(见5.15)F
48、6 监测指令设备的功能和设计要求无7 执行装置的功能和设计要求无8 对动力源的要求元13 GB/T 13629-2008 B.1 背景附录B(资料性附录)多样性需求的确定将计算机用作安全系统的组成部分时，对于计算机软件会导致共模故障的可能性已经引起了人们的关注。多样性是处理这一问题的一种方法。本附录提供了确定多样性需求的一种方法。B.2 讨论可能存在某些情况，在这些情况下除了由设计和质量保证(QA)大纲(包括软件QA和v&V)所提供的保证以外，还可能需要某种形式的多样性来提供附加保证。在计算机设计复杂(例如，一项安全功能的所有控制在一台计算机上实现)和运行经验有限的情况下，下面提供了一种方法，
49、用来确定依赖于功能多样性和纵深防御的核电厂其他设计特性的充分性。如果已有适当的多样性或者可将适当的多样性增加到核电厂设计中，则不需要计算机的多样性。对于在设计中可用经验有限且无多样性的复杂系统，应使用计算机的多样性。B.3 确定多样性需求的方法根据核电厂设计基准事件的分析，确定由拟用计算机完成的安全功能，并鉴别出其他安全和非安全的设计措施，这些设计措施能执行相同的或不同的安全功能，对已确定的不可接受结果提供等效的保护(例如，对于未能紧急停堆预期瞬态的缓解系统可为反应堆保护系统完成紧急停堆功能提供功能多样性)。如果有必需的控制器和显示器支持操纵员在可接受的时间内完成适当的操作，则操纵员的手动操作是可以接受的。如果使用的设备不受拟用计算机假想软件差错的影响从而具有功能多样性，则在拟用系统的冗余通道中使用相同的软件是可以接受的。如果不存在功能多样性，则应进行纵深防御
