NB/T 20298-2014.Nuclear power plants-instrumentation and control important to safety-Hardware design requirements for digital systems.
1范围
NB/T 20298规定了核电厂1级和2级(见NB/T 20026中的定义)计算机系统硬件设计要求，包括硬件需求、验证和确认、鉴定、制造、安装和调试、维护、运行等相关内容。
NB/T 20298适用于核电厂1级和2级计算机系统新硬件的设计，及对预开发硬件(包括固件)的评估:也适用于可编程逻辑器件的设计过程和设计验证。
NB/T 20298不适用于用于软件下载和检查的计算机硬件设施。
注1:木标准不关注3级计算机系统硬件，此类系统宜采用商用级标准开发。
注2:支持可编程逻辑设备设计过程的基于软件的工具宜总体上服从相应软件标准中所提供的指导，见NB/T 20054
(1级系统)或NB/T 20055 (2级系统)。
注3:对于预开发硬件的开发见附录B,对于可编程逻辑器件的开发见附泳C
2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件,仪所注H期的版本适用于本文件。凡是不注日8期的引用文件，其最新版本(包括所有的修改单)适用于本文件。
GB/T 7826-2012 系统可靠性 分析技术失效模式和影响分析(FMEA)程序(IEC 60812:2006,IDT)
GB/T 12727-2002 核电厂 安全系统电气设备质量鉴定(IEC 60780:1998, MOD)
NB/T 20026-2010 核电厂 安全重要仪表和控制系统总体要求(IEC 61513: 2001, IDT)
NB/T 20054-2011核电厂安全重要仪表和控制系统执行A类功能的计算机软件(IEC 60880:2006,MOD)

ICS27.120.20
备案号：46483-2014
中华人民共和国能源行业标准
NB/T20298-—2014
代替EJ/T529-1990
核电厂安全重要数字仪表和控制系统硬件设计要求
Nuclear power plants - instrumentation and control important to safety -Hardware design requirements for digital systems2014-06-29发布
国家能源局
2014-11-01实施
规范性引用文件
术语和定义、缩略语
项目结构
硬件需求
设计和开发
验证和确认（V&V）
安装和调试
13运行
附录A（资料性附录）
附录B（规范性附录）
附录C（规范性附录）
附录D（资料性附录）
附录E（资料性附录）
附录F（资料性附录）
参考文献
本标准与IEC60987:2007相比的结构变化情况预开发硬件的评估
可编程逻辑器件开发的适用性
系统生命周期总貌，
鉴定示意图
维护程序举例，
NB/T20298—2014
NB/T20298—2014
本标准按照GB/T1.1一2009给出的规则起草。本标准代替EJ/T529-1990《用于核电厂安全重要系统数字计算机》，与EJ/T529-1990相比，主要技术变化如下：
本标准考虑了近些年计算机设计工程技术显著发展的现状（见第1章）：一增加和替换了相关标准要求，特别是NB/T20026、NB/T20054和INB/T20055（见第1章、第2章、3.1、4.1、5.1.1、5.3.5、5.5、6.5、7.1.2、7.9、10.4、10.8、11.2.6、12.2和第13章）：-增加了术语“固件”、“预开发”、“鉴定寿命”、“显性硬件故障”、“单一故障”、“安全重要系统”、“系统确认”、“隐性硬件故障”、“验证”及定义（见3.1.1～3.1.5、3.1.7~～3.1.10）;
一删除了术语“可用性”、“计算机”、“计算机系统”、“部件”、“设计”、“研制”、“多样性”、“综合测试”、“可维修度”、“维修”、“模件”、“合格寿命”、“余”、“可靠性”、“软件”、“子系统”、“系统”、“鉴定”、“检验”及定义（见1990版的3.1~3.14、3.16~3.20）：
修改了术语“单一故障准则”的定义（见3.1.5，1990版的3.15）；-增加了缩略语（见3.2）。
本标准使用重新起草法修改采用IEC60987:2007《核电厂基于计算机安全重要仪表和控制系统的硬件设计要求》。
本标准与IEC60987:2007相比，在结构上有较多调整，附录A列出了本标准与IEC60987:2007章条编号变化对照一览表。
本标准与IEC60987:2007的技术性差异及其原因如下：修改了第1章范围的内容，以满足GB/T1.1—2009的要求；关于规范性引用文件，本标准做了具有技术性差异的调整，以适应我国的技术条件，调整的情况集中反映在第2章“规范性引用文件”中，具体调整如下：●用等同采用国际标准的GB/T7826代替IEC60812（见5.3.4）；。用修改采用国际标准的GB/T12727代替IEC60780（见第8章、11.2.4）；。用等同采用国际标准的NB/T20026代替IEC61513（见第1章、第2章、3.1、4.1、5.1.1、5.3.5、5.5、6.5、7.9、10.4、10.8、11.2.6、12.2、第13章）：?用修改采用国际标准的NB/T20054代替IEC60880（见第2章、3.1.8、3.1.10、7.1.2、7.9、第13章）：
。用修改采用国际标准的NB/T20055代替IEC62138（见第2章、7.1.2、7.9、第13章）；HAF003代替IAEA50-C/SG-Q（见第2章、4.3.1）；。删除ISO9001的引用。
删除了下述在标准中未使用的术语及其定义：3.2商品化的：
。3.3多样性：
。3.7核电厂：
3.11安全有关系统：
3.12安全系统。
增加缩略语（见3.2）
本标准由能源行业核电标准化技术委员会提出。本标准由核工业标准化研究所归口。本标准起草单位：中核控制系统工程有限公司。NB/T20298—2014
本标准参编单位：北京广利核系统工程有限公司、国核自仪系统工程有限公司。本标准主要起草人：王怀敬、刘瑞、梁嘉琳、韦智康、张鑫、孙武、金成日、李灵坡。II
1范围
NB/T20298—2014
核电厂安全重要数字仪表和控制系统硬件设计要求本标准规定了核电厂1级和2级（见NB/T20026中的定义）计算机系统硬件设计要求，包括硬件需求、验证和确认、鉴定、制造、安装和调试、维护、运行等相关内容。本标准适用于核电厂1级和2级计算机系统新硬件的设计，及对预开发硬件（包括固件）的评估：也适用于可编程逻辑器件的设计过程和设计验证。本标准不适用于用于软件下载和检查的计算机硬件设施。注1：本标准不关注3级计算机系统硬件，此类系统宜采用商用级标准开发。注2：支持可编程逻辑设备设计过程的基于软件的工具宜总体上服从相应软件标准中所提供的指导，见NB/T20054（1级系统）或NB/T20055（2级系统）。注3：对于预开发硬件的开发见附录B，对于可编程逻辑器件的开发见附录C。2规范性引用文件
下列文件对于本文件的应用是必不可少的。凡是注日期的引用文件，仅所注H期的版本适用于本文件。凡是不注日期的引用文件，其最新版本（包括所有的修改单）适用于本文件。GB/T7826—2012系统可靠性分析技术失效模式和影响分析（FMEA）程序（IEC60812:2006，IDT)
GB/T12727—2002核电厂安全系统电气设备质量鉴定（IEC60780:1998，MOD）NB/T20026—2010核电厂安全重要仪表和控制系统总体要求（IEC61513：2001,IDT）NB/T20054—2011核电厂安全重要仪表和控制系统执行A类功能的计算机软件（IEC60880:2006，MOD)
NB/T20055—2011
62138:2004,MOD)
核电厂安全重要仪表和控制系统执行B类和C类功能的计算机软件（IECHAF003核电厂质量保证安全规定HAD102/10核电厂保护系统及有关设施IEC61000（所有部分）电磁兼容（electromagneticcompatibility）IEC61025故障树分析（Faulttreeanalysis）3术语和定义、缩略语
3.1术语和定义
NB/T20026一2010界定的以及下列术语和定义适用于本文件。为了便于使用，以下重复列出了NB/T20026——2010中的某些术语和定义。3.1.1
固件firmware
安装于硬件中并与该硬件特性密切耦合的软件。1
NB/T20298—2014
注：固件的表现形式通常对硬件部件的用户是“透明的”，由此可认为是硬件设计的一个有效组成部分（这类软件很好的一个例子如处理器微代码）。总之，固件可以只通过用户更换硬件部件（例如，处理器芯片、卡件、EPROM）来修改，这里所指的硬件部件包括了与部件一起的软件，即更换后部件包括了修改的软件（固件）。在这种情况下，设备用户对硬部件的配置控制可有效用于对固件的配置控制。本标准所指的固件实际上是嵌入硬件中的软件。
预开发pre-developed
现有的、作为商品或专有产品可得到的，用于基于计算机系统的物项。注：这个定义与NB/T20026一2010中“预开发软件”定义是一致的。3.1.3
鉴定寿命qualifiedlife
一个构筑物、系统或部件通过试验、分析和（或）运行经验已证明其能够在特定运行工况下在验收标准范围内运行，同时保持在设计基准事故或地震条件下能够实施其安全功能的时间。[NB/T20063—2012，定义6.1.8]3.1.4
显性硬件故障revealedhardwarefailure可白动探测并告知的硬件故障，例如，一块板卡的故障可通过看门狗电路自动探测并触发报警。3.1.5
单一故障singlefailure
导致某一部件不能执行其预定安全功能的一种故障，以及由此引起的各种继发故障。[NB/T20063—2012，定义2.40]
单一故障准则singlefailurecriterion要求系统或设备组合在其任何部位发生可信的单一随机故障时仍能执行其正常功能的设计准则。[NB/T20063—2012，定义2.41]
安全重要系统systemimportanttosafety属于某一安全组的一部分和（或）其失效或故障可能导致对厂区人员或公众的辐射照射的系统。[1AEASafetyGlossary:2006]
系统确认systemvalidation
通过检查和提供其他证据，证实该系统完全满足预期的需求规格书（功能、响应时间、容错、鲁棒性）。
[NB/T20054—2011，定义3.37]
隐性硬件故障unrevealedhardwarefailure不能被系统自动探测，并且只有在试图使用依赖该故障硬件的某一功能时才能显现的硬件故障。这类故障可通过功能测试或对该系统有运行请求时发现。3.1.10
验证verification
通过检查和提供客观证据，证实该过程某种活动的结果是否符合为此活动规定的目标和需求。[NB/T20054—2011，定义3.38]
3.2缩略语
下列缩略语适用于本文件。
COTS：商品化的（CommercialOffTheShelf)ATE：自动化测试设备（AutomatedTestEquipment）FMEA：故障模式和影响分析（FailureModeandEffectsAnalysis）FTA：故障树分析（FaultTreeAnalysis）4项目结构
4.1综述
NB/T20298—2014
基于计算机的安全重要系统的开发项目宜分为若干阶段。每个阶段宜在一定程度上是完备的但要依赖其他阶段提供输入，同样也要提供输出作为其他阶段的输入。项目的各个阶段共同构成整个安全生命周期（见NB/T200262010第5章）。NB/T20026—2010允许在不影响开发过程完整性的前提下，项目的各个阶段可并行开展，
质量保证大纲应应用于硬件生产过程。4.2项目分解
下列总体要求定义了本标准范围内计算机系统的硬件开发生命周期要求：硬件开发生命周期应与整个系统生命周期一致（参见附录D）：a)
硬件开发生命周期的每个分阶段应由明确定义和文档记录的活动构成；设计所包括的现有硬件产品（如COTS）在使用前应进行相应的核对、验证和测试；应提供足够的手段（如备品备件、测试和维护设备等）和场所（如实验室、车间、场地等）来执行与每个开发阶段相关的任务；每个开发阶段应形成适当的文档：每个开发阶段应进行总结性验证（见第7章）：每个验证活动的结果应形成可审计的文件，记录所达成结论和执行验证而导致的任何设计变更：
应制定所有工作活动的进度计划以保证下列活动的足够时间：解决软件和硬件开发阶段之间的任何相互影响的问题，以确保系统软硬件的兼容：1)
2）形成文件与执行测试、验证和质量保证活动。4.3质量保证
4.3.1设计和开发过程应满足HAF003的相关要求。硬件质量保证大纲应作为一个独立文件（或多个文件）或整个质量保证大纲的一部分。大纲应关注现有硬件的使用和需要的硬件开发。作为硬件开发过程的一部分，由电厂操纵员、业主、承包商和分包商所执行的所有硬件质量相关活动宜包括在质量保证大纲中。
4.3.2硬件质量保证大纲宜涉及以下阶段，这些阶段在任何特殊系统或开发中均适用：设计和开发；
b）采购：
c）制造；
d)建造和调试：
运行和维护。
NB/T20298—2014
4.3.3在设计过程开始前并不要求覆盖上述所列所有阶段，但是在每个阶段启动之前，该阶段要求的大纲应准备就绪。
4.3.4质量保证大纲宜描述质量有关活动的组织、管理和执行，包括：a）文档配置控制；
设计过程；
产品和服务的采购过程；
建造指导、建造程序和图纸的配置控制用于建造系统硬件的物料和物项的配置控制：质量控制活动，诸如正式检查；测试设备的控制：
硬件搬运、储存、运输的控制；测试过程；
监督不符合项的产生和纠正措施的实施；质量保证记录存档流程；
内审程序。
5硬件需求
5.1综述
5.1.1硬件需求应与系统要求一致，并构成计算机系统技术规格书的一部分（见NB/T20026—2010中第6章）。计算机系统技术规格书是对软件和（或）硬件组合系统的描述，规定了系统设计目标和计算机系统所执行的功能（系统既可以是为某一特定应用所开发，也可以是为通用应用所开发，即平台开发。对于后一种情况，系统开发是基于通用的系统要求）。5.1.2硬件需求应在系统硬件需求规格书或其他适宜的文件中予以规定。硬件需求应根据一种技术或方法予以呈现，其格式不应妨碍可读性，即硬件需求宜易于理解。5.1.3
硬件功能需求应是明确的、可测试的和（或）可验证的和可实现的。5.1.4
5.1.5硬件需求规格书宜给出一个总体性的硬件要求，确定核安全重要的硬件功能（但是，如果与系统软件一起提出，则这些要求宜在系统需求规格书中定义），确定硬件设计要求，规定硬件可靠性要求和硬件环境适应性要求。
5.1.6计算机系统的硬件需求可包括硬件通用要求和对计算机系统硬件特殊要求（例如，电缆、外壳的表面处理）。
5.1.7硬件功能需求宜描述应该做什么，而不宜描述应该怎么做。但是，使用现有的部件和（或）平台可导致一定程度的自下而上的硬件设计。在选用这类现有部件前，应进行评估以确认其硬件性能特性（例如，故障模式）与系统要求一致。如果发现任何异常，则通过修改硬件设计或系统设计使其一致（同时保证不降低系统核安全要求）。5.2功能和性能需求
5.2.1硬件功能和性能需求应与安全重要系统的功能和性能要求--致。5.2.2硬件功能和性能需求，结合软件要求（必要时，涉及所有硬件需求）应进行系统要求的一致性验证。
系统直到部件级的所有组成部分（含软件）应按照附录B的范围进行如下评估：硬件功能需求应包括但不限于对下述内容的定义：a)
1）整个计算机系统硬件和每个硬件子系统的用途：2）与计算机系统连接的传感器和执行器的数量和类型；3）人机接口设备（诸如显示器、打印机和键盘）的数量和类型。NB/T20298—2014
供货商所移交的准备集成到系统中的每个部件和子系统宜附有一个规格书，关注其所有与安全b）
有关方面的性能。如果不能提供这样一份规格书，则应进行分析，至确定部件的硬件设计特性达到与其适用性相符所必要的程度：硬件性能要求应包括（适用于任何特殊应用）：c）
要求的数据采集速率；
要求的数据处理能力；
要求的计算容量；
要求的可靠性和（或）可用性
要求的通讯接口（协议、传输速度）；要求的计算和转换精度；
要求的信号抗噪声能力：
要求的响应时间；
物理尺寸限值：
10）布置（位置）要求（例如，数据传输线的长度）；11）要求的备用容量（如果要求）；12）环境适应性鉴定要求；
13）供电要求。
d）应说明系统或软件设计对硬件设计的任何约束。5.3可靠性和（或）可用性要求
5.3.1硬件可靠性和（或）可用性要求应与整个系统的可靠性要求一致。要求应包括任何故障类型的描述，这些故障在没有功能丧失或在已定义的有限功能丧失条件下都必须是被容许的。宜提供硬件可靠性目标。
注：本条所述硬件可靠性涉及随机硬件故障，不包括任何逻辑设计错误引发的故障。5.3.2不论硬件可靠性和（或）可用性如何要求，核电厂整个仪表和控制系统结构应满足HAD102/10中7.5的单一故障准则。
5.3.3硬件要求宜给出硬件可靠性参数的目标值[诸如平均故障间隔时间（MTBF，对显性和隐性的），平均修复时间（MTTR，对显性故障）。由硬件设计详细分析支持的可靠性描述的要求宜予以说明，例如，子组、板卡级或部件级分析。5.3.4可用于分析可靠性和系统硬件故障影响的方法包括：一FTA，其中考虑了引起或促使一个确定不期望事件发生的条件和因素的识别和分析（见IEC61025关于此技术的建议）。
-FMEA，其中确定了对系统性能有重大影响后果的故障，例如，可靠性、安全、可用性（见GB/T7826关于该技术的建议）。如果使用适合于1级利2级硬件系统的任何分析技术，应确保任何潜在的硬件故障没有不可接受的核安全影响。
5.3.5诸如FTA与已知的部件故障数据相结合的技术，可用于系统硬件可靠性特性的数值计算。除有足够的运行经验可提供很高的置信度证明该硬件可靠性日标是可达到之外，这种方法应应用于1级系统硬件分析（见NB/T20026）。这种技术宜同样用于2级系统，或者，尤其在对硬件可靠性要求不过于苛刻5
NB/T20298—2014
的情况下，采用定性化论证（例如，部件质量、硬件元余度、运行经验、显性硬件故障对隐性硬件故障的比例等）来证明其有足够的可靠性。5.3.6应确定保证计算机系统全寿期内可靠性和可用性的策略和规定。这些措施应作为维护要求形成文档，这些文档应包括防止维护活动引入可能导致共因故障的缺陷的要求。对多重序列系统的维护活动，通常被认为最有可能引入这些缺陷，因而，系统设计时应使这类活动减少到适当的程度。当要求的维护活动有可能导致共因故障时，则设计要求应详细说明是如何使这类故障的风险最小化的。5.3.7维护要求宜涉及下述内容（适用任何特殊系统）：a）硬件维护活动期间对系统运行的要求；易耗品更换，例如，空气过滤器：b）
c）子系统、模件和（或）部件常规更换的任何要求：要求硬件维护活动后进行硬件再确认的程度（如测试）。d)
5.3.8在需求规格书宜确定“做什么”而不是“怎么做”的原则下，在一个项目的需求规格书阶段详细确定维护要求可能是不切实际的，因此，这些要求宜在开发过程的稍后阶段予以完全确定。5.4环境适应性要求
5.4.1硬件环境适应性要求应涉及适用的物理限制、气候、地震、化学、电气和辐射条件。宜同样包括安装和调试期间的任何适用的特殊要求。5.4.2应根据运行环境的要求规定抗电磁干扰的程度，并按适用的标准进行试验（如IEC61000）。运行场所的电磁环境有可能受到多种类电气干扰源的影响，例如开关柜、移动电话、继电器、对讲机、静电放电、雷电、接地故障。
5.4.3所规定的电磁鉴定水平宜与运行条件中所有可信的最恶劣情况的实际估算一致。5.4.4硬件要求应明确任何禁用的构材，以及任何待用的特殊材料或特殊生产工艺类型的要求。5.4.5如果要求一个特殊的硬件鉴定过程，则该要求宜体现在硬件需求中。5.5文档要求
硬件文档要求应作为计算机系统文档要求的一部分处理（见NB/T20026）。形成的文档宜包括：设计文件（系统硬件部件、接口硬件设计等）；a)
操作手册；
维护手册。
6设计和开发
6.1综述
6.1.1新硬件的设计和开发过程宜把硬件需求规格书作为一个输入。设计过程宜通过不同设计阶段逐渐深入，最终生产出满足需求规格书要求的硬件。6.1.2较总体层面的设计活动可称为“初步”设计，包括不同设计可选方案的分析，以确定至子系统和模块一级的硬件系统结构。www.bzxz.net
6.1.3初步设计之后一般是一个或更多个层次的详细设计。详细设计活动应把初步设计扩展到子系统、模块和部件一级的详细设计，使整个硬件设计描述充分完备达到可实施的程度。6.1.4可搭建硬件模拟件，不仅用于验证硬件模块间的相互作用是否正确，还可用于检查硬件和软件的兼容性。
NB/T20298—2014
6.1.5预开发（例如COTS）部件可用于所有的系统硬件或硬件部件的子组件。6.26.7主要是考虑要求定制硬件开发的情况，但是，适当情况下，这些小节也提供了定义如何可用于预开发部件使用的指导。6.2设计活动
6.2.1硬件设计应涉及基于硬件性能的系统性能要求，并且论据应可用，通过分析或测试来表明硬件设计满足这些要求。这些要求可包括计算精度、时间响应、环境适应性能力和供电要求（对于现有部件，应进行部件硬件规格书与系统硬件要求的对照验证，确保现有部件满足规定要求，或者通过测试验证硬件性能）。
6.2.2任何与硬件需求的差异应通过修改设计，或者修改需求米解决（任何修改的影响应进行全面评估并形成文档）。
6.2.3硬件设计者应识别出那些表明性能要求已经达到的必要测试。这些测试可以对硬件单独执行，或者在软硬件集成时执行，即作为系统集成测试阶段的一部分。6.2.4硬件设计者应规定任何需要的维护活动，以提供设备全运行寿期内能达到性能和可靠性要求的置信度，可包括运行测试、标定、维修、定期更换和维护程序。宜使此类活动的执行达到这样程度，即为设备正确运行提供充分置信度，又使对系统的人为干扰和介入系统工作的执行最小化，进而降低这些维护活动引入的错误的可能性（诸如潜在的共模故障缺陷）。6.2.5一且规定了一个鉴定的目标寿命，则应论证该目标是现实并可达到的。6.3可靠性
6.3.1宜在硬件需求文档中规定可靠性要求（见5.3）。6.3.2为支持系统级的安全分析，设计期间应进行硬件潜在故障分析。一且执行一个核安全功能要用到一个系统的多个序列或多个系统（每个系统可能有单个或多个序列设备），则分析中应包括潜在硬件共因故障的适当考虑。便件共因故障的可能途径如下：一一对设备的多个序列同时或顺序进行维护活动（特别是可能引入隐性硬件故障的活动）：一定期测试
一影响一个（多个）核安全功能的设备的多个序列同时发生隐性随机硬件故障：一影响多个设备序列的，并且设计过程不能被发现的隐性设计错误。6.3.3可用于分析硬件可靠性和系统硬件故障影响的方法包括FTA和IFMEA（见5.3.4）。6.3.4硬件设计宜使下列对核安全因素的潜在影响最小化：维护活动：
一随机硬件故障导致的系统故障；一环境条件导致的硬件故障。
6.3.5如果认为针对硬件某一特殊用途而评估出的可靠性是不足的，则应采取补救措施，可通过设计改进或运行变更的方式进行（诸如提高运行测试频度）。但是，宜谨慎选择增加运行测试的方式，因为任何引入运行电厂的活动都可能会由于引起或引入缺陷而带来一定程度的风险（即，综合衡量之后的运行测试对安全的最终影响可能是负面的）。理想情况下，所有的测试宜在测试过程中潜在缺陷不会对核安全造成影响时进行，例如，电站停运期间或被测试设备与运行电厂隔离时。6.3.6当使用概率安全评价来支持核电厂的安全案例时，则所评估的硬件可靠性概率值（例如，采用FTA）可引入到核电厂的分析中，并有助于全厂可靠性计算的准确性。6.4维护
硬件设计应涉及硬件需求规格书中所包含的任何维护要求。此外，可行时，设计宜包括降低由丁维护活动所引入的错误风险的措施。例如下列措施：7
NB/T20298--2014
一由于故障可能要求更换的部件宜易于接近一可更换部件宜标识清晰，使维护人员易于检查使用了正确的部件；一宜有足够的端接空间：
一宜提供足够的专用端子用于标定和（或）测试活动（这样不需要断开接线以便于此类活动）：硬件设计宜提供一张标识清晰的结构布置图以减少能的维护错误。6.5接口
防止故障通过系统接口扩展的系统接口要求见NB/T200262010的6.1.1.2.1，。6.6修改
硬件应设计成具有满足硬件需求规格书要求程度的可修改能力（见第12章）。6.7电源故障
计算机系统应设计成满足硬件需求规格书要求程度，对短期电源故障的后果和供电电源的可能波动【电压和（或）频率]是不敏感的。应提供将此类电源波动通知给运行维护人员的系统措施（本功能可能不在硬件中，因此可能超出本标准的范围）。6.8部件选择
一日使用现有部件，则部件设计应与其在系统硬件中的作用兼容。6.9设计文档
6.9.1硬件设计文档应描述硬件设计和已涉及硬件要求的措施。推荐使用标准化的设计文档格式和自动化的硬件设计工具。
6.9.2计算机系统硬件设计文件宜按若干个文档“层次”的结构发布。每个层次的设计文档宜详细规定该与层次设计相关的各方面设计，并定义其下一层次的硬件要求。在设计过程中应发布制造和（或）组装、T\厂测试、安装、调试、维护和运行的文件（如果适用）。6.9.3可发布初步的硬件设计描述对硬件结构进行定义，即系统不同部分间的结构和关系，宜包括硬件的总体布置连同下一层次的子系统和模块的结构图，也宜包括详细设计的硬件要求，例如：一中央处理器单元和其他处理器的数量和类型：一计算机存储器的硬件要求：
接口的数量和类型；
数据链和总线的数量和类型。
6.9.4在硬件设计和开发结束时应形成文档，包括全部利最终的描述，涵盖直到最底层的全部设计细节和硬件的性能、限值以及其他特性。6.9.5最终描述文档应提供下列信息：a)
设计综述：
支持设计文件的参考资料：
硬件子系统中分解硬件的描述：每个子系统的主要模块和部件的描述（例如，结构图、电路图）：子系统硬件接口描述，接口应就逻辑、物理、电气和其他方面进行适当描述：计算机系统硬件接口描述，任何与核电厂内部或外部其他系统的接口应明确表明详细的按口和相关硬件要求：
物理布置一宜提供设备物理布置的图文描述：g）
小提示：此标准内容仅展示完整标准里的部分截取内容，若需要完整标准请到上方自行免费下载完整标准文档。