1 范围

      本文件规定了核电厂基于计算机的安全重要系统硬件设计要求，包括硬件需求、设计和开发、验证和确认、鉴定、制造、安装和调试、运行、维护等相关内容。

      本文件适用于核电厂基于计算机的安全重要系统硬件的设计，及对预开发硬件（包括固件）的评估；也适用于可编程逻辑器件的设计过程和设计验证。

      本文件不适用于用于软件下载和检查的计算机硬件设施。

2 规范性引用文件

      下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。

      GB/T 12727 核电厂安全级电气设备鉴定

      GB/T 13626 单一故障准则应用于核电厂安全系统

      GB/T 36044 核电厂安全重要电气设备鉴定规程

      NB/T 20026-2014 核电厂安全重要仪表和控制系统总体要求（IEC 61513：2011，MOD）

      NB/T 20054 核电厂安全重要仪表和控制系统执行A类功能的计算机软件（NB/T 20054-2011，IEC 60880:2006,MOD)

      NB/T 20055 核电厂安全重要仪表和控制系统执行B类和C类功能的计算机软件（NB/T 20055-2011,IEC 62138:2004,MOD)

3 术语和定义

      下列术语和定义适用于本文件。

3.1

      基于计算机的系统 computer-based system

      其功能主要依靠或完全由使用微处理器、可编程电子设备或计算机来实现的仪表和控制（1＆C）系统。

      注：基于计算机的系统等同于数字系统、基于软件的系统、可编程系统。

      ［来源：NB/T 20026-2014,3.11］

3.2

      基于计算机的安全重要系统 computer-based system important to safety

      系统安全功能通过内置计算机系统实现的核动力厂安全重要系统。

      ［来源：HAD 102/16-2004，名词解释］

3.3

      固件 firmware

      硬件装置和以只读软件方式驻留在该装置中的计算机指令和数据的组合。

      注：固件的表现形式通常对硬件部件的用户是“透明的”，由此可认为是硬件设计的一个有效组成部分（这类软件很好的一个例子如处理器微代码）。总之，固件可以只通过用户更换硬件部件（例如，处理器芯片、卡件、EPROM）来修改，这里所指的硬件部件包括了与部件一起的软件，即更换后部件包括了修改的软件（固件）。在这种情况下，设备用户对硬件部件的配置控制可有效用于对固件的配置控制。本文件所指的固件实际上是嵌入硬件中的软件。

      ［来源：GB/T 13629-2008,3.26］

3.4

      预开发 pre-developed

      现有的、作为商品或专有产品可得到的，用于基于计算机的系统的物项。

3.5

      鉴定寿命 qualified life

      一个系统或部件通过试验、分析和（或）运行经验已证明其能够在特定运行工况下在验收标准范围内运行，同时保持在设计基准事故或地震条件下能够实施其安全功能的时间。

3.6

      显性硬件故障 revealed hardware failure

      可自动探测并告知的硬件故障。

3.7

      单一故障 single failure

      导致某一系统或部件不能执行其预定安全功能的一种故障，以及由此引起的各种继发故障。

      ［来源：HAF 102-2016，名词解释］

3.8

      单一故障准则 single failure criterion

      要求系统或设备组合在其任何部位发生可信的单一随机故障时仍能执行其正常功能的设计准则。

      ［来源：NB/T 20063-2012,2.41］

3.9

      安全重要系统 system important to safety

      属于某一安全组的一部分和（或）其失效或故障可能导致对厂区人员或公众的辐射照射的系统。

      ［来源：HAD 102/16-2004，名词解释］

3.10

      系统确认 system validation

      通过检查和提供其他证据，证实该系统完全满足预期的需求规格书（功能、响应时间、容错、鲁棒性）。

      ［来源：NB/T 20054-2011,3.37］

3.11

      隐性硬件故障 unrevealed hardware failure

      不能被系统自动探测，并且只有在试图使用依赖该故障硬件的某一功能时才能显现的硬件故障。这类故障可通过功能测试或对该系统有运行请求时发现。

3.12

      验证 verification

      通过检查和提供客观证据，证实该过程某种活动的结果是否符合为此活动规定的目标和需求。

      ［来源：NB/T 20054-2011,3.38］

4 项目开发组织

4.1 总体要求

      基于计算机的安全重要系统的开发项目宜分为若干阶段。每个阶段宜在一定程度上是独立的但要依赖其他阶段提供输入，同样也要提供输出作为其他阶段的输入。项目的各个阶段共同构成整个安全生命周期（见NB/T 20026-2014第5章）。NB/T 20026-2014允许在不影响开发过程完整性的前提下，项目的各个阶段可并行开展。

      质量保证大纲应应用于硬件生产过程。

4.2 项目分解

      下列总体要求规定了本文件范围内基于计算机的系统的硬件开发生命周期要求：

      a）硬件开发生命周期应与整个系统生命周期一致；

      b）硬件开发生命周期的每个分阶段应由明确规定和文档记录的活动构成；

      c）设计所包括的现有硬件产品［如COTS（商品级的）］在使用前应进行相应的核对、验证和测试；

      d) 应提供足够的手段（如备件、测试和维护设备等）和场所（如实验室、车间、场地等）来执行与每个开发阶段相关的任务；

      e) 每个开发阶段应形成适当的文档；

      f) 每个开发阶段应进行总结性验证（见第7章）；

      g) 每个验证活动的结果应形成可审计的文件，记录所达成结论和执行验证而导致的任何设计变更；

      h) 应制定所有工作活动的进度计划以保证下列活动的足够时间：

      1）解决软件和硬件开发阶段之间的任何相互影响的问题，以确保系统软硬件的兼容；

      2）形成文件与执行测试、验证和质量保证活动。

4.3 质量保证

4.3.1 设计和开发过程必须满足HAF 003的相关要求。硬件质量保证大纲应作为一个独立文件（或多个文件）或整个质量保证大纲的一部分。计划应关注现有硬件的使用和需要的硬件开发。作为硬件开发过程的一部分，由电厂操纵员、业主、承包商和分包商所执行的所有硬件质量相关活动宜包括在质量保证大纲中。

4.3.2 硬件质量保证大纲宜涉及以下阶段，这些阶段在任何特殊系统或开发中均适用：

      a）设计和开发；

      b）采购；

      c）制造；

      d）建造和调试；

      e）运行和维护。

4.3.3 在设计过程开始前并不要求覆盖上述所列所有阶段，但是在每个阶段启动之前，该阶段要求的计划应准备就绪。

4.3.4 质量保证大纲宜描述质量有关活动的组织、管理和执行，包括：

      a）文档配置控制；

      b）设计过程；

      c）产品和服务的采购过程；

      d）建造指导、建造程序和图纸的配置控制；

      e）用于建造系统硬件的物料和物项的配置控制；

      f) 质量控制活动，诸如正式检查；

      g）测试设备的控制；

      h）硬件搬运、储存、运输的控制；

      i) 测试过程；

以上为标准部分内容，如需看标准全文，请到相关授权网站购买标准正版。