GBT 13629-2023 核电厂安全系统中可编程数字设备的适用准则

核电厂安全系统中可编程数字设备的适用准则2023-12-28发布I前言 l2规范性引用文件 13术语和定义、缩略语 13.1术语和定义 13.2缩略语 24安全系统设计基准 35安全系统准则 35.1单一故障准则 35.2保护动作的完成 35.3质量 35.4设备鉴定 75.5系统的完整性 75.6独立性 95.7试验和校准能力 5.8信息显示 5.9访问控制 5.10维修 5.11标识 5.12辅助设施 5.13多机组核电厂 5.14人因工程考虑 5.15可靠性 5.16共因失效准则 5.17商品级数字设备的使用 5.18简单性 6监测指令设备的功能和设计要求 7执行装置的功能和设计要求 8对动力源的要求 附录A(资料性)危害的识别和控制 A.1背景 A.2危害分析的目的 A.3危害分析实施指导 Ⅱ附录B(资料性)通信独立性 附录C(资料性)多样性需求的确定 C.1多样性和纵深防御分析 C.2充分多样性以消除共因失效 C.3增加多样性以应对共因失效薄弱环节 C.4多样性的手动控制和显示 C.5多样性的自动控制 附录D(资料性)商品级物项适用性确认 D.1总体原则 D.2商品级物项适用性确认的准备 41D.3商品级物项适用性确认的开展 D.4商品级物项适用性确认的维护 参考文献 Ⅲ本文件按照GB/T1.1—2020《标准化工作导则第1部分：标准化文件的结构和起草规则》的规定起草。本文件代替GB/T13629—2008《核电厂安全系统中数字计算机的适用准则》,与GB/T13629—2008相比，除结构调整和编辑性改动外，主要技术变化如下：——更改了文件的适用范围，将“数字计算机”更改为“可编程数字设备”(见第1章，2008年版的第1章);构”“设计”“文件""文档""差错""执行""失效""故障""功能""功能单元""硬件""实现""接口”2008年版的第3章);——增加了术语和定义“安全状态”“功能状态”"关键特性""基本部件""可编程数字设备""数字安全系统”(见第3章);——增加了缩略语(见3.2);——增加了针对单一故障的相关准则要求(见5.1);——更改了应用于数字装置、软硬件开发、固件和可编程逻辑设备开发所用到的软件工具内容(见5.3.3,2008年版的5.3.2);——增加了功能优先级的相关要求(见5.5.5);——增加了安全系统内部各冗余部分以及安全系统和其他系统之间独立性方面的详细规定(见——增加了3项试验和校准准则(见5.7);——增加了多序列控制和显示的相关要求(见5.8);——增加了安全系统在计算机安全防范方面的要求，特别给出了安全开发和运行环境的相关准则(见5.9);——增加了安全系统中与计算机相关的共因失效(CCF)的要求(见5.16);——增加了可编程设备和软件的商品级适用性确认要求(见5.17);——增加了安全系统简单性方面的要求(见5.18)。请注意本文件的某些内容可能涉及专利。本文件的发布机构不承担识别专利的责任。本文件由全国核仪器仪表标准化技术委员会(SAC/TC30)提出并归口。本文件起草单位：核工业标准化研究所、北京广利核系统工程有限公司、生态环境部核与辐射安全中心、国核自仪系统工程有限公司、中核控制系统工程有限公司。本文件主要起草人：焦丽玲、程建明、张亚栋、杜乔瑞、王晓燕、杜建、邓瑞源、吴飞飞、裴红伟、本文件及其所代替文件的历次版本发布情况为：——1998年首次发布为GB/T13629—1998,2008年第一次修订；——本次为第二次修订。1核电厂安全系统中可编程数字设备的适用准则本文件规定了可编程数字设备用于核电厂安全系统的设计准则，包括安全系统准则、监测指令设备本文件适用于核电厂安全系统中的可编程数字设备。2规范性引用文件下列文件中的内容通过文中的规范性引用而构成本文件必不可少的条款。其中，注日期的引用文件，仅该日期对应的版本适用于本文件；不注日期的引用文件，其最新版本(包括所有的修改单)适用于本文件。GB/T12727—2017核电厂安全级电气设备鉴定GB/T13284.1—2008核电厂安全系统第1部分：设计准则GB/T13625—2018核电厂安全级电气设备抗震鉴定GB/T22032—2021系统与软件工程系统生存周期过程NB/T20448—2017核电厂系统和软件的验证和确认下列术语和定义适用于本文件。在其应用场景中被认为是安全的系统状态或符合核电厂安全分析的系统工况。由可编程数字设备(PDD)设计规定的部件或系统的运行状态。硬件设备和驻留在此设备上的作为只读软件的计算机指令和数据的组合。关键特性criticalcharacterist为了保证商品级物项可执行其预定安全功能，需验证物项重要的设计、材料和性能(包括设计过程)2的属性。基本部件basiccomponent影响核电厂安全功能所必需的系统、设备及其零件。任何依赖计算机软件指令或可编程逻辑完成其功能的设备。注：包括计算机、可编程硬件设备，或带有固件的设备。商品级物项commercialgradeitem不是为核电厂专门设计或不以核电厂特有的技术要求为条件，用于非核电厂，按制造厂产品(例如样本)说明中规定的技术条件从制造厂或供货商处采购的系统、设备及其零件。商品级物项适用性确认commercialgradededication为了充分确信商品级物项适合于核安全应用，对商品级物项进行评价和验收的过程。数字安全系统digitalsafetysystem用以执行安全功能的可编程数字设备的集合。危害hazard系统中不良行为的先决条件，包括外部事件以及硬件和软件的内在条件。检查系统以识别内在危害，以及运用适当的需求、设计和其他约束条件来消除、预防或控制所识别的危害的过程。3.2缩略语下列缩略语适用于本文件。ATWS:未能紧急停堆的预期瞬态(AnticipatedTransientWithoutScram)CDR:关键数字评审(CriticalDigitalReview)DPRAM:双端口随机存储器(Dual-portedRandomAccessMemory)D3:多样性和纵深防御(DiversityandDefenseinDepth)FMEA:失效模式和影响分析(FailureModesandEffectsAnalysis)FTA:故障树分析(FaultTreeAnalysis)MTE:测量和试验设备(MeasurementandTestEquipment)PHA:初步危害分析(PreliminaryHazardsAnalysis)SDOE:安全开发和运行环境(SecureDevelopmentandOperationalEnvironment)V&.V:验证和确认(VerificationandValidation)34安全系统设计基准核电厂安全系统的设计基准应按照GB/T13284.1—2008中第4章给出的要求执行。5安全系统准则5.1单一故障准则除GB/T13284.1—2008中5.1给出的要求外，下列准则也适用于安全系统中的可编程数字设备。a)单个可编程数字设备(PDD)失效不应影响核电厂安全分析中假定会独立地发生功能异常的功能。b)功能配置(如功能分布)应使得单个PDD的功能异常或软件错误不应导致电厂发生未包含在设计基准、事故分析、未能紧急停堆的预期瞬态(ATWS)的处理措施误动作或其他异常工况的处理措施误动作。这里所指的误动作包括单个PDD功能异常或软件错误导致的一个以上电厂设备或系统的误动作。对相同的软件错误导致的多个PDD故障的可能性及其后果应满足5.16的要求。5.2保护动作的完成保护动作的完成应按照GB/T13284.1—2008中5.2给出的要求执行。安全系统质量总体要求按照GB/T13284.1—2008中5.3执行。软件质量要求应满足ISO/IEC12207:2017及其支持性标准的要求。系统质量应满足GB/T22032—2021的要求。PDD的开发活动应包括硬件和软件的开发。在开发过程中应处理硬件与软件的集成以及PDD在安全系统中的集成。典型的安全系统开发过程宜由下列生命周期的过程组成：a)建立系统的概念设计；b)将概念设计转化为具体的系统需求；c)使用这些需求进行详细的系统设计；d)硬件和软件功能的设计的实现；e)功能试验以确定需求的正确实现；f)系统安装并进行现场调试；g)系统运行和维护；h)系统退役。为了符合质量准则，除了GB/T13284.1—2008的要求之外，还应满足下列活动的附加要求：a)软件开发；b)现有商品级PDD的适用性确认(见5.17);c)软件工具的使用；d)验证和确认；e)配置管理；f)风险管理。4软件应按经批准的软件质量保证大纲进行开发、修改或验收，质量保证大纲的要求应符合ISO/IEC12207:2017的规定。软件质量保证大纲应涉及运行时PDD的所有常驻软件(包括应用软件、网络服务软件、接口处理软件、操作系统软件以及诊断软件等)。编制软件质量保证大纲的指导见NB/T20054—2011的5.5。软件质量保证大纲同时应包含5.3.3中用于系统开发和维护的软件工具的要求。在整个软件生命周期内，宜考虑使用软件质量度量以评价其是否满足软件质量要求并改善性能，宜基于下面的生命周期阶段特性考虑度量：a)正确性/完整性(需求阶段);b)与需求的一致性(设计阶段);c)与设计的一致性(实现阶段);d)功能与需求的一致性(试验和集成阶段);e)现场功能与需求的一致性(安装和调试阶段);f)性能历史记录(运行和维护阶段)。在软件开发文档中应包括为评价软件质量特性而选择的度量依据。GB/T25000第10部分、第22部分和第23部分提供了软件质量度量的应用方法。在数字安全系统开发生命周期的不同阶段中，一般要用到多种类型的软件工具。有些工具被集成到基本软件开发过程中，而另一些则被间接地使用。因此，以工具类型及所执行的任务作为依据有助于对这些工具进行分类。此外，识别工具输出，也是确定软件工具的鉴定等级的重要因素。一旦确定了软件工具的分类，即能确定工具的限制、用途及鉴定要求，以确定工具被恰当地使用。下面提供一种软件分类方案，分类方案中采用识别工具用途和输出以使其能适用后续准则。I类：软件开发工具——开发方用以产生软件、定义系统架构或生成拟载入到PDD的配置数据的工具。开发人员通过软件开发工具与某类编程接口语言(如C、C++),或通过图形界面(如绘制功能框图)直接交互。开发工具随后将该用户的输入转换为可直接载入到PDD的数据(目标代码或编程数据)。I类工具输出是可在目标系统硬件中执行的目标代码或编程数据。Ⅱ类：监视和维护工具——用于监视试验、修改配置数据，和/或为安全系统载入软件的工具。Ⅱ类工具的输出可包含安全系统对工具的响应和/或对安全系统配置的修改。Ⅲ类：开发过程支持工具——在离线状态下使用，用于支持不同开发活动。此类工具一般不会对系统和软件造成直接影响，也不会与系统或软件开发过程发生直接交互。因此，Ⅲ类工具本身不会向安全PDD引入错误。相反，Ⅲ类工具可用于开发过程所需的文档和配置创建或维护管理。Ⅲ类工具的输出是安全系统的记录或具体文件/数据集。Ⅲ类工具还可用于维护I类、Ⅱ类、IN类和V类工具的配置控制。IV类：在线V&.V工具——接收I类工具输出。IN类工具用于开展或协助开展V&.V活动。通常，IV类工具设计用于纠正安全系统(通过自动操作，或工具用户按照预设规则集发出的指令手动操作完成)。IV类工具的输出为经过调整或修改后的软件/系统，这些软件/系统按照工具本身已预设的要求已得到纠正。5V类：离线V&.V工具——接收I类工具输出。V类工具与IV类工具类似，都用于支持V&.V活动，与IV类工具差别在于：V类工具不能修改或控制被测试软件/系统从而向安全系统引入错误，而是以测试结果的形式输出，为操作员提供相关信息，用于确认系统正按照设计功能运行。如果需要对系统进行纠正，则该信息将作为反馈发送给开发人员。开发人员随后使用I类工具做必要的纠正，随后以迭代的形式重复V&.V流程，直至所有要求均已验证和确认。若在安全系统PDD生命周期过程内使用软件工具，应采用下列方法中的一种或两种方法确保软件工具的输出与工具在安全系统中的使用相匹配：a)软件工具未能检出的缺陷应能通过V&.V活动发现；b)工具应使用与最终产品所执行的安全功能的关键程度相称的生命周期过程进行开发。所有软件工具的预期功能和应用限制应识别并记录。除非预先经过合理性证明，否则对工具及其输出的使用不应超出已书面化的功能或应用限制。应按照软件工具分类进行软件工具评价，并评价工具在安全系统PDD中引入故障的可能性。软件工具的评价过程宜考虑既往的使用经验。相关经验宜包含开发方的经验以及工具使用过程中获取的经验。用以支持安全系统PDD软件生命周期过程的软件工具应纳入到安全开发和运行环境(SDOE)中，并置于配置管理控制之下。只有经过批准和记录的软件工具才可用于支持安全系统PDD的开发。软件工具应在其设计能力范围内使用。5.3.4验证和确认验证和确认(V&.V)是过程管理和系统工程团队活动的延伸。在整个系统生命周期中，V&.V用于确定有关数字系统质量、性能和整个生命周期开发过程的目标数据和结论(即主动反馈)。反馈包括与系统及其接口的预期运行条件有关的不符合项报告、性能改进及质量提高。V&.V过程应被用于确保某一活动的开发产出满足该活动的要求，以及系统按照其预期的用途和用户的需求执行。对这些匹配性的确定应包括对产品和过程进行的评价、分析、评审、检查和测试。本文件采用NB/T20448—2017规定的过程、活动和任务的定义，其中V&.V过程被分解为多项活动，活动又被进一步分解为多项任务。V&.V过程应关注影响软件和系统的硬件、数字系统部件的集成以及PDD与核电厂的相互作用。V&.V活动和任务还应包括对最终集成后的硬件、软件、接口的系统测试。应依据NB/T20448—2017中针对软件V&.V规定的任务进行软件V&.V工作。NB/T20448—2017建立了完整性等级划分方案，但申明其他完整性方案是可接受的。对于任何已选定的完整性方案，应建立所选方案的完整性等级与NB/T20448—2017中的四个等级的对应关系，以证明最低V&.V要求得到满足。安全系统V&.V计划应定义和判定系统的完整性等级以及所需书面化输出。对于完整性等级的定义可参考NB/T20448—2017。5.3.5验证和确认独立性要求安全系统执行验证和确认有独立性要求。为了具备独立验证和确认，要求实现下面不同类别的独a)验证和确认人员应向具有足够权限和组织自由度的独立组织报告，包括如NB/T20448—2017附录B定义，在费用和进度方面拥有足够的独立性；b)应由具有适当技术能力且并未参加原设计的人员或小组独立完成对开发活动和测试的审核和确认；c)设计人员、参与设计的人员、参与设计和开发项目的管理人员，以及负责监督设计方的人员不应参与安全系统独立验证和确认的监督工作。6全生命周期过程内的测试可由V&.V组织或设计组织(或两者兼有)完成。不论测试规程由哪一组织实际编写、测试由哪一组织主导，测试规程和报告的检验应独立进行。NB/T20448—2017的附录B给出了V&.V独立性的更多指导。应进行软件配置管理。编制配置管理计划的指导参考NB/T20335—2015。至少应进行下列软件配置管理活动：a)所有软件设计和执行代码的标识和控制；b)所有软件设计功能数据(数据模板和数据库)的标识和控制；c)所有软件设计接口的标识和控制；d)所有软件设计变更的控制；e)软件文档(用户文件、运行和维护文件)的控制；f)对提供安全系统软件的供应商开发活动的控制；g)与软件设计和执行代码有关的鉴定信息的控制和获取；h)软件配置审查；i)状态统计。对硬件和系统应执行类似的配置管理活动。其中某些功能或文件可由其他的质量保证活动来完成或进行控制。在这种情况下，软件配置管理计划应说明责任的划分。应在开发生命周期过程中适当的点建立系统的过程基线，以使工程和文档活动相同步。基线建立后产生并经批准的变更应添加到基线中。对实施配置管理的系统的标签应包括每个配置项的唯一性的标识，以及每个配置项的修订版本号和(或)日期时间标志。应按照系统配置管理计划，对系统的变更正式书面化并得到批准(配置控制标准参考NB/T20335—2015,回归分析和测试标准参考NB/T20448—2017)。该文档修订应包括变更的原因，受影响的配置项的标识，以及变更对系统的影响(包括危害分析和风险分析)。此外，变更控制文档应包括变更在系统中实施的计划(立即实施变更，或未来版本变更的时间表),同时还包括对危害分析、风险分析和诸如V&.V的其他生命周期活动的文件升版。5.3.7项目风险管理项目风险管理是一种用于问题预防的工具，识别可能出现的问题、评价这些问题的影响，并确定为确保达到质量目标应涉及的潜在问题。在数字系统项目的各个层次应进行风险管理以充分覆盖每个可能的问题领域。项目风险应包括与技术、进度、成本和资源有关的风险，这些风险可能损害质量目标，从而影响数字系统或计算机执行安全功能的能力(见附录A),项目风险管理与危害分析的不同之处在于在危害分析中只关注系统失效机理及其对电厂安全影响中技术方面的因素，而不是项目执行方面的风险。当某项要素属于项目风险和危害风险共有时，项目风险和危害风险可能重叠。应按项目风险以及通过危害分析过程评价这些重叠部分。风险管理应包括下列步骤：a)确定PDD风险管理的范围；b)规定和实施适当的风险管理策略；c)在项目风险管理策略中识别项目风险，以及它们在项目实施过程中的演变；d)分析风险以确定缓解风险的优先次序；e)对可能显著影响质量目标的风险编制风险缓解计划，并采用适当的度量来跟踪问题的解决过7程(这些风险可包括可能损害安全PDD执行安全功能能力的，与技术、进度或与资源有关的风险);f)当未达到预期的质量时，采取纠正措施；g)为解决软件项目风险，建立一个在个人之间及团队之间能够进行有效交流的工作环境。ISO/IEC12207:2017和GB/T22032—2021提供了有关风险管理的附加指南。5.4设备鉴定在GB/T12727—2017和GB/T13625—2018要求的基础上，除GB/T13284.1—2008中5.4给出的设备鉴定准则外，设备鉴定还应满足以下要求。设备鉴定试验应在系统处于运行状态，并且系统使用其实际操作中拟使用的代表性软件和诊断程序的情况下进行。对于PDD执行安全功能所必需的所有功能，以及其运行或失效可能对安全功能有损害的功能，都应在鉴定过程中进行试验。在适当且可行的情况下，这包括对存储器、逻辑、输入和输出、显示功能、诊断、相关部件、通信路径和接口的试验和监测。试验应证明，在规定的环境应力和输入输出应力下，与安全功能有关的性能要求已得到满足。与核质保大纲下制造的设备一样，商品级物项也应进行设备鉴定。5.5系统的完整性5.5.1通则要求为了达到安全系统中数字设备应用的系统完整性，除了GB/T13284.1—2008中5.5的要求之外，还应满足以下要求：a)PDD完整性设计；b)试验和校准设计；c)故障探测和自诊断；d)功能优先级。5.5.2可编程数字设备完整性设计PDD应设计成在所有可能造成安全功能失效的内部或外部危害下均能完成其安全功能，这些危害包括输入和输出处理失效、精度或舍入问题、不适当的恢复动作、供电电源电压或频率波动、信号同时改变的最大可信数量，以及环境应力。如果系统要求已规定安全系统的优先失效模式，则PDD失效不应妨碍安全系统处于该失效模式。PDD的重启操作不应阻止安全系统完成其功能，不应造成安全系统误动作。应开展危害分析(见附录A)以识别和处理系统的潜在危害。5.5.3试验和校准设计试验和校准功能不应对系统完成其安全功能的能力造成不利的影响。在试验和校准情形下，有条件地旁通某一冗余通道，不认为对系统安全功能执行造成不利影响。试验和校准功能不应影响与校准变更(例如变更整定值)无关的其他系统功能。当试验和校准功能由另外的PDD(例如，试验和校准计算机)完成并由该试验和校准功能提供试验和校准数据的唯一验证时，则应要求对这些功能进行V&.V、配置管理和质量保证。当试验和校准功能由安全系统中的PDD来完成时，也应要求对这些由PDD完成的试验和校准功能进行V&.V、配置管理和质量保证。校准应满足相关国家标准的要求。当驻留在另外PDD中的试验和校准功能不是为安全系统的PDD提供试验和校准数据的唯一验证8时，则不要求对这些功能进行V&.V、配置管理和质量保证。5.5.4故障探测和自诊断自诊断是及时探测失效的手段。在可由其他方法及时探测失效的系统中，不要求自诊断功能。如果自诊断功能已集成到安全系统中，则这些功能应经过与安全功能相同的验证和确认过程。如果自诊断作为可靠性的必要条件，则PDD软件应包含及时探测和报告PDD系统故障和失效的功能。自诊断功能不应影响PDD系统执行其安全功能的能力，或引起安全功能的误动作。典型的自诊断功能包括：a)存储器功能性和完整性试验，例如可编程只读存储器(PROM)校验和随机访问存储器(RAM)测试；b)计算机指令集测试，例如运算测试；c)PDD外部设备硬件试验，例如监视定时器和键盘试验；d)PDD架构支持硬件试验，例如地址线和共享存储器接口；e)通信链路诊断，例如循环冗余(CRC)校验；f)内部信号监视，如通过联合测试工作组(JTAG)协议监视。应识别那些不会导致系统失效或系统功能缺失的通信链路失效，给核持证单位”或供应商做决定，并宜在应用角度上评价这类失效。当自诊断功能应用时，系统设计应包括下列自诊断特性：a)PDD系统启动期间的自诊断；b)当PDD系统运行时定期的自诊断；c)自诊断测试失效报告。本条给出功能优先级的应用准则。优先级功能接收来自安全侧设备和非安全侧设备的动作命令，并将具有最高优先级的命令发送给一个或多个安全级驱动设备。驱动设备属于安全级部件，如电动阀、泵电机、电磁阀等。非安全侧信号源可包括操作或维护显示单元、控制系统(如给水控制系统)、多样性驱动系统等在内的任何非安全级部件。优先级功能采用以下准则。a)优先级功能应是安全功能。b)用于多样性驱动信号的优先级功能应独立于任何数字系统其他部分中假定可能发生的共因失效(CCF),并且，不管数字系统处于何种状态或条件，均应正确地完成其功能。c)当源自安全系统的信号与多样性的驱动信号或非安全控制信号汇合时，更高的优先级应赋予使受控设备进入预先确定的安全状态的信号，以使得即使安全系统出现CCF而未发出正确命令时，受控设备仍然能达到安全状态。对于存在一个以上安全状态的设备(如辅助给水控制阀),要求选择首选安全状态。确定设备的安全状态或首选安全状态是电厂系统的任务，不在本文件中规定。d)优先级功能可控制一个或多个部件。若优先级功能控制多个部件时，本条中的规定应适用于每一个受驱动部件。e)各优先级功能之间的通信隔离应符合5.6.5.2的规定。f)用于优先级功能设计、测试、维护等的软件工具的要求应符合5.3.3的规定。g)在役期间，无论通过设计措施移除或替换存储设备，或是通过符合5.6.5.2规定的物理限制(即物理断开电缆的连接),也或是通过键盘锁开关(该开关采用硬件逻辑方式打开数据传输电路9或中断连接),优先级功能涉及的非易失存储器(如烧录门阵列、可重复编程门阵列或者随机存取存储器)都应是不可修改的。h)应通过人工定期试验或通过自动化自诊断方式测试优先级功能。对于实现优先级功能的模块内的自动测试，无论其是由模块内部发起的还是从外部触发的(包括由于自动测试功能失效而触发的),都不应妨碍安全功能。执行优先级功能应使得GB/T13284.1—2008中要求的安全动作不被优先级功能所在安全序列之外的指令、工况或失效所中断。为了满足独立性准则，除了GB/T13284.1—2008中5.6的要求之外，安全序列之间或安全系统与非安全系统之间的数据通信不应妨碍安全功能的执行。GB/T13284.1—2008要求安全功能应与非安全功能相隔离，以使非安全功能不能阻止安全系统执行其预期的功能。在PDD中，执行安全功能的软件和执行非安全功能的软件可能驻留在相同的PDD中并使用相同的PDD资源。非安全软件的功能应依照本文件中与安全相关的要求进行开发。各个安全通道的安全功能应给予保护，防止其受到通道所在序列外部的不利影响。序列外部发出的信息和信号不应妨碍或延误该序列安全功能的执行。这种保护应在受影响的序列内完成(不是在序列以外的资源中完成),且这种保护自身不应受到受影响序列以外的条件或信息的影响。这种保护应持续有效，不受序列外存在或发出的任何操作、功能异常、设计错误、通信错误、软件错误或崩溃的影响。对于旧有的、仅设置有两个序列(每个序列内包含若干冗余通道)的反应堆保护和专设安全设施系统，则要求不论其他通道是否做出判定，每个通道能够产生单独保护动作信号。这些冗余通道之间的通信，应采用与本文件中针对序列间通信相同的方法。安全系统的设计应使其安全功能的实现不依赖于来自非安全系统的输入。仅在非安全系统接受与安全系统相同的质量活动(如独立审查和配置控制)的前提下，可接受在安全系统中使用来自非安全系统的数据输入(如整定值和标定值)(数据独立性的详细准则见5.6.5.3)。5.6.2安全系统内部各冗余部分之间详细准则按照5.6.5要求执行。5.6.3安全系统与设计基准事件影响之间安全系统与设计基准事件影响之间应按照GB/T13284.1—2008中5.6.2给出的要求执行。5.6.4安全系统与其他系统之间详细准则按照5.6.5要求执行。邻近的设备应按照GB/T13284.1—2008中5.6.3.2给出的要求执行。5.6.4.3单一随机故障的影响单一随机故障的影响应按照GB/T13284.1—2008中5.6.3.3给出的要求执行。缓冲功能为通信链路与安全功能之间提供接口，其主要作用为：防止安全序列之外的通信上发生的故障和失效扩散到安全序列内的安全功能当中，维持安全功能的完整性。符合本准则的通信功能/缓冲区的指导，可参考附录B。缓冲功能适用以下准则。a)缓冲功能应包含两部分不同的电路，其中一部分执行安全功能，另一部分执行数据通信功能。执行安全功能的PDD应能访问缓冲电路。b)缓冲功能可由单独的通信处理器或PDD内单独的逻辑提供。缓冲功能可设置在同一印制电路板上，或设置在单独的印制电路板上。c)安全功能处理器应与通信处理器异步运行。无处理器的PDD的安全功能和通信功能应各自具有单独的逻辑电路。安全功能需求中应明确规定来自于通信功能的数据故障(如向缓冲发送的通信速率增大、数据不可用或过期、数据损坏)时的处理。d)安全功能和通信功能之间的通信应使用专用的缓冲功能(如双端口存储器)以实现信息交换。安全功能、通信功能以及缓冲功能，与所有支持的软硬件均被视为安全级的，应按相应要求进e)安全功能应具有访问缓冲功能的优先权，以使安全功能按照确定的方式完成。缓冲功能故障不应妨碍安全功能在确定的时间范围内执行。f)安全功能处理器周期时间的确定，宜考虑访问共享存储器可能的最长时间。最长可能完成时间应包含存储器本身及其相关电路的响应时间，还应包含假定从通信处理器到功能处理器的访问切换的最坏条件下，功能处理器访问存储器时的最长可能延迟时间。系统运行时间超出限制的周期时间时，应被检测到并报警。g)如果缓冲功能提供了在安全功能中使用的数据，则应对缓冲功能引入相同的用于安全功能的V&.V。否则，根据需要的完整性等级，可使用在NB/T20448—2017定义的对应等级的V&.V方法。h)GB/T13284.1—2008明确适用于安全系统和非安全系统间的通信链路，以及安全系统内各序列间的通信链路的电气隔离、分隔和单一故障的要求。除非通信是用于支持安全功能的实现，否则安全通道不应接收来自所在安全序列之外的任何通信。接收不用于安全功能的信息可能会引入与安全功能不直接相关的其他功能。下列准则适用于冗余安全序列之间、安全系统与非安全系统之间的数字通信。a)执行安全功能的处理器应执行无握手通信或无中断方式的通信。如有需要，应使用单独的通信处理器实现握手和中断功能。非基于处理器的设备应具备单独的逻辑电路来执行通信和安全功能。b)应只有预定义的数据集被接收端安全系统处理(即预先定义的消息的格式和协议，也即，每条消息中的各段含有相同定义的信息)。接收端安全系统应根据已定义的设计要求识别和处理不可辨认(即不符合预先定义)的数据。c)在执行安全功能的PDD系统内部，接收和发送的数据均存储在单独的、预定义的位置。预定义的内存位置仅用于数据接收和发送。d)所有外部信号均应作为数据，并按照运行中的安全逻辑的正常顺序加以处理。不准许出现可能会改变安全逻辑或逻辑顺序的命令。e)安全序列软件应加以保护，防止在安全序列运行期间发生改变。控制安全系统软件变更的首选方法是对来自维护/监视装置的输入数据采用硬接线联锁或物理断开的方式。f)对于可寻址常量、整定值、参数及其他与安全功能相关的设置，应只在通道处于旁通或通道未运行时可更改。g)为防止同一时刻修改一个以上的安全序列，应在物理上对部署用于这类修改的工具进行限制h)当工具连接上其他处于旁通或非在役状态的通道以进行参数修改时，安全系统的设计应对仍在运行的通道提供防护以防止被修改。此类防护应是安全的。i)可信通信故障不应妨碍所必要的安全功能的运行。应假设非安全系统具有多个和连续的失效。宜考虑下面最简清单中列出的可信故障(见GB/T34040—2017):1)消息可能因通信处理器错误、缓冲区接口引入的错误及传输媒介引入的错误，或来自干扰的错误而损坏；2)消息可能在错误的时间点重复；3)消息的发送顺序可能不正确；4)消息可能丢失，包括未能接收到未损坏的消息，以及未能确认接收到消息；5)消息可能因为多种原因而产生延迟超出允许的时间窗口，这些原因包括传输介质错误、传输线路拥塞、传输线路干扰或被发送缓冲区排队的消息延误等等；6)来自非预期或未知来源的消息可能被插入到通信介质中；7)消息可能伪装成来自预期来源的有效消息，包括故意的事件(见5.9中针对此类情况的预防措施);8)消息可能发送到了错误的地址，而该目的地可将其视为有效消息；9)消息长度可能超出接收缓冲区大小，导致缓冲区溢出和内存损坏；10)消息可能包含有预期范围以外的数据；11)消息可能表现为有效，但消息中的数据位置可能发生错误；12)消息发送频率过高，可能导致系统降级或引发系统失效(如广播风暴);13)消息头或地址可能已经损坏；14)安全系统未处于处理被接收消息的正确模式。j)对安全功能提供支持的通信(如为实现符合逻辑而共享各通道的触发判别结果)应包含确保所接收消息是正确且可被正确理解的相关措施。此类通信应采用检错码，并配有相应的对损坏、无效、超时或其他可疑数据的处理方式。宜在相关代码的设计和相关代码验证性测试中证明错误检测的有效性，一旦有效性得到证明，则不需要在定期试验中再次证明有效性。k)为安全功能提供支持的通信应采用专用的媒介，以点对点的方式传输。此外，如果其他通信策略具有同等可靠性且有书面化的证明，也可采用。1)用于安全功能的通信应按照一定的时间间隔发送固定的数据包，不论该数据包中数据是否发生了变化。m)设计通信协议时，应将消息数据的有效性和时效性纳入到协议当中，同时设计接收端对消息数据进行校验并做适当处理。n)宜对通信规则进行分析，以便查找因非必要功能或复杂性引入的危害和性能缺陷。o)安全功能不应因通信过载和失效受到不利影响。p)确定响应时间时，宜考虑数据错误率。在冗余安全序列之间，或者从非安全系统到安全序列的数据交换，应保证序列间的独立性，防止接收序列的安全功能受到使用交换数据的不利影响。应对数据的故障或失效进行识别，并将适当的逻辑纳入到系统设计当中，以便处理可信的数据故障和失效，如因输入源降级导致格式有效的数据不正确。在非安全系统与安全系统之间开展数据交换时，采用以下准则。a)安全系统中安全功能的执行不应依赖于非安全系统的通信链路，或来自非安全系统的数据。应假定当安全系统发生单一故障的同时，非安全数据也失效，这种情况下安全系统仍能执行其预期的功能。b)如果安全序列使用了来自冗余序列的数据，或使用了来自非安全系统的数据(如用于调整整定值或校准数据),则这些数据(使用前已经过验证)应在安全序列内手动允许，或使用安全序列内的安全逻辑自动允许。c)用于多个安全序列内的数据应视为同一失效来源，因为这种失效的共同来源可能会给多个序列带来不利影响。建立通信独立性的指导见附录B。5.7试验和校准能力除GB/T13284.1—2008中5.7给出的要求外，应遵守以下准则。a)应通过定期自动或手动监视以确定安全系统配置。b)不应以支持定期自动或手动监视试验的目的，要求改变或修正安全系统配置。c)用于安全系统的测量和试验设备(MTE)不应对安全系统功能造成不利影响。这里的安全系统功能包含安全系统所有部分的功能，且不排除处于试验状态的通道或序列。应确保MTE临时连接到安全级设备之前，MTE上的无线接收器/转发器处于禁用状态。5.8信息显示安全级控制和显示可通过安全级的操作员站实现，或者通过硬接线设备(如开关、继电器、指示器和模拟信号处理电路)实现。在这两个情况的任何一种情况下，应确定安全控制和指示可应用于特定的安全序列。针对此类用于同一安全序列的安全控制和指示要求按照GB/T13284.1—2008中5.8给出的要求执行。此外，5.8.2和5.8.3提供了针对另一类操作员站的额外指导，这类操作员站用于控制一个以上的安全序列中的电厂设备，显示来自一个以上安全序列的信息。5.8.2和5.8.3还适用于对不在同一安全序列中的安全系统进行编程、修改、监视或维护的工作站。本文件所涉及的多序列控制和显示站本身可是安全级的，也可是非安全级的。如果这些站包含对多个安全序列中的设备的控制和显示，或者这些站包含的控制和显示是非安全级的但与某安全序列之间有接口，则这些站应符合5.8.2和5.8.3给出的条件。5.8.2多序列控制和显示站的独立性和隔离要求多序列控制和显示站的独立性和隔离符合下列要求。a)使用非安全级控制和显示站对安全级设备的运行进行控制时，遵守下列限制。1)非安全级控制和显示站应通过与设备相关的优先级功能访问安全级电厂设备。优先级功能宜按照5.5.5中的要求进行设计和应用。2)当安全级设备执行其安全功能时，非安全级控制和显示站不应影响安全级设备的运行。本规定应在安全系统实现，且不应受到非安全级设备的任何操作、功能异常、设计错误、软件错误或通信错误的影响。3)仅当受影响的安全序列自身判定可接受非安全级控制和显示站旁通某安全功能时，非安全级控制和显示站才能旁通该安全功能。4)非安全级控制和显示站不应禁止任何安全功能的执行，除非安全系统自身判定安全功能的结果已得到保证，该安全功能的终止才被允许。应证明安全系统具有做出对应判定所必须的所有信息和逻辑。5)非安全级控制和显示站不应复位某安全功能，除非受影响的安全序列自身判定可接受安全功能的复位。6)非安全级控制和显示站不应取消某安全功能的旁通状态，除非受影响的安全序列自身判定可接受非安全级控制和显示站取消该安全功能的旁通状态。b)与上述a)项中非安全级控制和显示站控制安全级设备运行情况下应遵循的限制类似，控制其他安全序列中的设备运行的安全级控制和显示站遵循以下限制。1)安全级控制和显示站应通过与设备相关的优先级功能访问其所在序列以外的安全级电厂设备。优先级功能的设计和应用应参考关于优先级功能的指导(见5.5.5)。2)当安全级控制和显示站所在序列以外的设备执行其安全功能时，安全级控制和显示站不应影响该安全级设备的运行。执行安全功能时，安全序列应提供防止外部影响(包括本序列以外的任何操作、功能异常、设计错误、软件错误或通信错误)的措施。3)仅当受影响的序列自身判定可接受本序列外的安全级控制和显示站旁通某安全功能时，本序列外的安全级控制和显示站才能旁通该安全功能。4)安全功能所在序列外的安全级控制和显示站不应禁止任何安全功能的执行，除非安全系统自身判定安全功能的结果已得到保证，该安全功能的终止才被允许。应证明安全系统具有做出对应判定所必须的所有信息和逻辑。5)序列外的安全级控制和显示站不应复位该安全功能，除非受影响的安全序列自身判定可接受安全功能的复位。6)序列外的安全级控制和显示站不应取消某安全功能的旁通状态，除非受影响的安全序列自身判定可接受序列外的安全级控制和显示站将该安全功能取消旁通状态。5.8.3功能异常和误动作与安全系统相连的信息显示功能异常和误动作方面符合下列要求。a)功能异常的结果应与针对电厂设计和审查准则的安全分析中的假定一致。b)安全分析中假定会独立地发生功能异常的功能不应受到多序列控制和显示站失效的影响。c)单一控制动作(例如：鼠标点击或屏幕触控)不应向电厂设备发出命令。命令的产生宜至少需要两个肯定的操作员动作。d)安全级控制和显示站应按照GB/T13284.1—2008中5.4的要求鉴定。应对能够控制安全级设备的非安全级控制和显示站进行鉴定，以证明当发生诸如地震、电磁干扰(EMI)/射频干扰(RFI)、电源浪涌，以及适用于同一场址内安全级设备的所有其他设计基准工况下的不利环境时，不论是在工况期间还是在工况发生之后，该非安全级控制和显示站不会发生误动，且不应因设计基准工况导致对任何安全级设备或装置产生不利影响。该鉴定活动不需要证明这些非安全级控制和显示站在适用的设计基准工况期间或之后保持自身的完整功能。如果不能满足该要求，则电厂安全分析应包含这些非安全级控制和显示站对安全级设备或装置可能产生的不利影响而导致的工况。推荐该鉴定通过试验来证明，而不是仅通过分析来证明。e)电源丧失、电源浪涌、电源中断、重启，以及任何其他在操作员站或控制器上发生的可信事件不应导致任何电厂装置或系统的误启动或误停止，除非相应的误启动或误停止已经包含在电厂安全分析当中。f)设计中应包含有能够通过物理手段禁用5.8.2中涉及的安全级和非安全级控制和显示站的措施，使其在主控室弃用后仍然能够防止安全级设备可能因导致主控室弃用的工况(如控制室火灾或水淹)而发生误动。禁用主控室控制和显示站的方法宜能够不受短路、控制室内环境条件等的影响，这些影响可能会恢复控制室操作员站功能，导致安全级设备误动。g)任何5.8.2中涉及的安全级和非安全级控制和显示站失效或功能异常及其恢复的过程不应导致电厂处于其设计基准、事故分析和未能紧急停堆的预期瞬态(ATWS)规定范围以外的任何工况(包括多种同时发生的工况),或其他预料之外的电厂异常工况。5.9访问控制5.9.1实体安全防范所有安全级数字部件和网络电缆应安装在电厂内设有设备实体安全防范措施的位置。将部件放置于核电厂要害区域提供了符合本要求的实体安全防范。要害区的实物保护见HAD501/02—2018。对于与安全级设备通过数字接口相连的便携式工程师站²)、MTE,应在有实体安全防范的位置进行维护、控制和访问。工程师站以及MTE的固定连接点，应设置在厂内带有实体安全防范的区域。对固定式或便携式工程师站的访问以及对MTE的访问应受到限制，仅允许对该设备有访问需求且已有预授权的员工进行该访问。5.9.2数字设备安全防范对安全系统和工程师站的访问应限制在一组指定专门的权限的人员来执行所需的操作。物理和逻辑上的访问控制宜基于系统安全开发和运行环境³(SDOE)评估结果。评估结果可要求对多种复杂的访问控制加以组合，如知识类(如密码)、资产类(如钥匙、智能卡)和人员特征类(如指纹)的不同组合。5.9.4.2.2和5.9.4.2.3给出了针对这种评估的更多细节。对配置参数的更改(如整定值、逻辑块组态和梯形图逻辑)以及对软件的变更应满足5.6.5.2h)项的要求。应给予足够的访问控制，避免不适当的访问。供应商默认密码应在系统执行安全功能前予以更改，同时，应禁止一切远程访问。远程访问规定见中对安全系统的安全开发环境和安全运行环境的评估。应禁用工作站的所有无线功能。MTE上的无线功能应在连接到安全级设备之前被禁用。5.9.3安全防范措施与安全功能的相互作用安全防范措施(如入侵检测软件、病毒防护软件、访问控制软件)的实现不应反过来对安全功能的性2)在核电厂安全系统中，工程师站指用于执行安全系统工程设计和维护功能的基于计算机的工具。工程设计功能通常包括创建新的控制功能、添加各种输入/输出点、修改顺序和连续控制逻辑、离线状态下的逻辑仿真、支持数据库工程设计、准备诸如I/O列表和设备信息等的工程设计文档。维护功能通常提供某种手段用以监视和故障定位系统运行的各个方面，包括诊断、安装和更新程序元素、故障恢复、执行系统权限管理等。3)安全开发和运行环境指为了防止在数字安全系统开发过程中引入未书面化的、不需要的(即非需求驱动的)以及非预期的修改所采取的措施和控制，以及为了防止可能在运行过程中对数字化安全系统的完整性、可靠性或功能带来不利影响的一系列非预期动作(如操作员非有意动作或关联系统非期望行为)所采取的保护性活动。这些活动可包括：在数字化安全系统中采用保护性设计，以阻止对系统无意识的访问和/或对数字化安全系统的关联系统的非期望行为的保护。安全开发环境和安全运行环境可以独立存在，其中，安全开发环境用于系统开发各阶段(即概念、要求、设计、执行、测试),可以是实体的、逻辑的和程序上的控制措施；安全运行环境设置于核电厂内部，用于支持数字安全系统可靠运行，可以是实体的、逻辑的和管理上的控制措施。能、有效性、可靠性和运行造成不利影响。安全防范措施，如入侵检测系统等，宜在安全系统外围实现。宜避免直接在安全系统内部实现安全防范措施。当必须在数字化仪控安全系统内实现安全防范措施时，应采用适当的方式证明该安全防范措施不会反过来影响系统安全功能的执行能力。当实现安全防范措施时，至少达到以下要求：a)应证明增加的安全防范措施是合理的；b)应处理安全防范措施的失效模式和失效对系统安全功能的影响，安全防范措施的错误不应反过来影响安全功能；c)可采用非侵入式安全防范措施(如报告自诊断数据供分析);d)侵入式安全防范措施(如病毒扫描)应仅在系统安全退出运行后执行；e)如果安全防范措施运行在安全系统显示和控制设备，其不宜反过来对操纵员维持电厂安全的能力造成不利影响；f)对于包含在安全系统内的安全防范措施，其开发和鉴定应保持与安全系统的开发和鉴定水平一致；g)除非有屏障能在安全系统在线运行期间阻止可移动存储介质的安装，或者设计屏障阻止在线运行期间数据从可移动存储介质写入安全系统，否则安全系统不应含有任何可移动存储介质设备。5.9.3.2非安全级工程师站在出现下列任意情况时，非安全级工程师站在连接到安全系统前，应及时、定期地更新病毒防护软件的运行包和安全补丁，包括：a)非安全级工程师站能够安装可移动的外部存储介质；b)非安全级工程师站能够与不属于安全系统的网络相连。用于数据存储或传送的任何存储介质(磁盘、磁带、闪存驱动器等)应在接入工程师站使用前经过病毒扫描，或应加以控制并存放在有物理防范的区域，以避免病毒侵入存储介质。5.9.4生命周期方法数字安全系统/设备开发过程中应应对数字安全系统生命周期(见5.3.1)内各个阶段的可能潜在薄弱环节，这些环节可能会导致SDOE降级，或使系统安全功能降级。5.9.4.2～5.9.4.9给出了针对SDOE需开展的额外活动。这些活动可根据生命周期模型调整；但当采用不同于瀑布式的生命周期模型时，应提供用以应对薄弱环节的等同水平的防护。在概念阶段，持证单位和开发方应识别建立系统安全运行环境所需的数字安全系统的措施。持证单位和开发方应对连接系统的非有意访问和非预期行为可能导致安全系统功能退化的潜在敏感源进行评估。该评估应识别对保持数字安全系统安全运行环境、开发生命周期各阶段的安全开发环境的潜在挑战。评估结果应用于建立针对软硬件要求，建立安全运行环境和保持该环境的防护措施。为建立安全开发环境，在开发生命周期各个阶段内评估开发环境时，应至少要处理并记录下列各项：a)将未经批准的安全系统需求插入需求文件或数据库的情形；b)未经批准的个人访问主需求文档或数据库的情形；c)将非需求驱动的设计特性插入到设计文档的情形；d)个人将非预期的、不需要的或未记录在案的软件插入PDD内的情形；e)未经批准的个人窜改试验数据或更改试验配置(软件或硬件)的情形。持证单位和开发方应评审安全开发环境评估结果，增加必要的控制措施以应对薄弱环节。薄弱环节的控制和处理方法示例如下。a)对需求和设计文档的严格控制。b)对需求到设计的向前和向后追溯的过程。c)对实现代码的严格控制，包括：1)对开发设备的安全防范；2)对开发环境的访问和网络连接的控制；3)使用软件管理工具跟踪所有软件变更和修订；4)执行对软件设计到软件实现进行向前和向后追溯的过程；5)用于检测、删除或评估软件中非必要特性所带来的潜在不利影响的过程。d)对测试环境的控制，包括：1)对测试硬件和软件配置的控制，包括对物理访问、逻辑访问和网络连接的控制；2)对测试产品、数据和文档的控制。为建立安全运行环境，对安全系统概念设计进行评估时，应至少识别并记录下列各项。a)相连系统非预期或非故意的行为可能给安全系统执行其要求的安全功能带来不利影响或使其降级(见5.6.5.2)。b)未经批准访问安全系统的情形。示例可包括：1)可能包含在系统上开放的通信端口，使得任何个人非故意地尝试接入系统的物理访问点；2)可能包含在系统上的人机接口点，连接到安全系统内同一网络上的逻辑访问点。核电厂运行时的许可证持证单位和开发方应评审安全开发和运行环境的评估结果，增加必要的控制措施以应对运行环境的薄弱环节。可用与相连系统的薄弱环节控制示例包括：a)消除与外部系统的连通性；b)物理上避免向安全系统传输数据的装置；c)使用消息过滤器，仅放行严格遵守书面化消息格式要求的特定消息；d)对数据字段使用“超数据有效性范围”的校验；e)使用循环冗余校验(CRC)过滤已损坏的消息。除5.9.1和5.9.2外，防止未经批准访问安全系统的控制示例可能还包括：a)对安装有安全系统的机柜上锁并设置报警器；b)禁用不再使用的外部通信端口，如那些能用于重启、重新配置系统或更改操作模式的端口。本阶段将确立安全运行环境相关的需求。进入系统需求阶段前，已经建立的安全开发环境需求的控制措施应已就位并启用。在需求阶段，使用方和开发方应定义并记录针对系统全生命周期的安全防范要求。宜考虑安全防范要求的领域示例包括：a)安全运行环境的系统配置；b)系统外部的接口；c)设备鉴定；d)人因；e)数据定义；f)软硬件的文档；g)安装与调试；h)运行；i)维护。预期用于维持安全运行环境的安全防范要求应作为系统需求的一部分。因此，对需求的验证应证明其正确性、完整性、准确性、可测试性以及与系统安全运行环境措施的一致性。规定使用预开发软件和系统(如重用软件和商品级系统)的需求应有助于处理安全系统的安全防范性(如使用平台安全防范能力或避免平台薄弱环节)。如果用于安全系统的数字化平台为通用设计，持证单位和安全系统开发方应执行对那些未使用措施的评估，并证明保留那些未使用措施不会对系统安全功能造成不利影响，否则应禁用或删除那些功能。持证单位及开发方应将商品级平台内的措施如何不妨碍安全开发环境要求的设计措施内容书面化。任何妨碍安全运行环境执行功能的措施均应作为注意事项和限制书面化。如果在本阶段中需求引入了新的薄弱环节，需进行评价。评价还宜确保识别到的薄弱环节已得到适当处理。如有必要，应相应地更新已有评价。在系统需求阶段识别出安全运行环境的安全系统设计措施，应转化为系统设计中的具体设计配置项。进入系统设计阶段前，针对设计而建立的安全开发环境的控制措施应已就位并启用。针对安全运行环境的安全系统设计配置项应用于处理：a)对系统功能的物理和逻辑访问；b)系统服务的使用(如自诊断);c)与其他系统的数据通信。对用于把预开发的软件组合到安全系统中的设计配置项，应确保该预开发软件不对安全系统的安全运行环境造成不利影响。物理和逻辑的访问控制应基于生命周期内概念阶段开展的安全开发和运行环境评估。开发方应记录符合安全防范政策的标准和规程，用于证明系统设计输出(硬件和软件)中不包含：a)未书面化的代码(如后门代码);b)恶意代码(如入侵、病毒、蠕虫、木马或炸弹代码);c)其他非预期的或未书面化的功能或应用程序。开发过程应系统地组织，从而将上述各项从安全系统中排除。如果在本阶段中设计配置项引入了新的薄弱环节，应进行评价。评价还宜确保识别到的薄弱环节已得到适当处理。如有必要，应相应地更新已有评价。在系统(集成的硬件和软件)实现阶段，软件设计将转化为代码、数据库结构以及相关的机器可执行代码。进入系统实现阶段前，针对实现而建立的安全开发环境的控制措施应已就位并启用。实现活动用于处理硬件配置和安装、软件编码和测试、通信配置和设定(包括与重用软件和商品级物项联调)。持证单位和开发方应证明，将设计转化为实现配置项是正确、准确且完整的。实现应与商品级物项规定的注意事项及限制保持一致。如果在本阶段中实现配置项引入了新的薄弱环节，应进行评价。评价还宜确保识别到的薄弱环节已得到适当处理。如有必要，应相应地更新已有评价。在集成测试、系统测试和验收测试执行过程中，对由安全运行环境设计措施的测试应附加系统可靠性需求测试。进入系统测试阶段前，针对测试而建立的安全开发环境的控制措施应已就位并启用。测试包括系统硬件配置测试(包括所有与其他包括外部系统在内系统的连接)、软件集成测试、系统集成测试、系统设备鉴定测试，以及系统出厂验收测试。持证单位和开发方应正确配置并启用支持安全运行环境的系统措施。持证单位和开发方还应对系统硬件架构、外部通信设备以及未授权通道和系统完整性配置开展测试。宜重点关注内置于原有设备中由制造商赋予的措施。应确认各个安全运行环境的系统设计配置项，以确保采取的措施达到其预期功能，以防止恶意访问或相连系统的非预期行为产生不利影响、保障安全系统的可靠性不降低。应核实和确认设计与商品级物项规定的注意事项及限制的一致性。测试计划应确认针对任何已识别的薄弱环节的缓解措施已正确实现。如果测试计划识别出了其他薄弱环节，应更新对安全开发环境的评价，并在必要时对系统做出更改，以消除或缓解这些薄弱环节。5.9.4.7安装和调试阶段持证单位应就安全运行环境评价要求设置相应控制措施，包括相关的缓解策略。在本阶段安全系统已在核电厂内安装并确认完成，以确保所交付系统的完整性。5.9.4.8运行和维护阶段在运行和维护阶段，持证单位应维持安全系统的安全运行环境。持证单位应评价拟采用的电厂变更对安全运行环境上的影响，以及评价拟采用的运行规程对安全运行环境的影响。当持证单位修改系统及相关的文档时，对安全系统的修改应按照上文中开发过程定义的方式加以处理。在运行和维护阶段，持证单位应专门处理安全系统的安全运行环境措施。应依照安全系统配置管理计划对安全运行环境进行维护。退出服务时，持证单位应确定并开展所需的活动，以保护已退役的安全系统的相关信息。5.9.5维护系统生命周期、软件生命周期以及验证和确认的相关要求见GB/T22032—2021、ISO/IEC12207:2017以及NB/T20448—2017。在安全系统的安全序列执行安全功能期间，不应更改安全系统硬件和软件配置。更改执行过程严格程度应与原系统开发过程严格程度一致。这一要求并不妨碍基于电厂工况(如反应堆运行模式改变)而进行的对整定值和逻辑的自动修改。对用于修改安全系统软件配置的终端，应具有访问权限(如键锁)及密码保护。对安全运行环境措施的维护和定期测试应仅在不会影响电厂运行环境的期间内执行。5.10维修维修应按照GB/T13284.1—2008中5.10给出的要求执行。除GB/T13284.1—2008中5.11给出的要求外，还应满足以下针对数字安全系统的特别要求：a)应提供并使用包含版本控制在内的软硬件标识，以确保在正确的硬件部件上安装了正确的软件；b)在软件中应包含相关的手段，以便使用软件维护工具从软件中重新得到标识。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的要求以外，当规定了可靠性目标时，满足该目标的证明应包含软件。确定可靠性的方法可包括分析与现场经验或试验的组合。软件错误记录及其趋势分析可同分析、现场经验或试验结合使用。5.16共因失效准则在安全系统中应用PDD的经验表明，PDD的使用已经引发软件设计错误可能导致CCF的顾虑，这类CCF可继而造成安全系统中一个或多个冗余序列的安全功能丧失。良好的软件设计实践对减少软件设计错误大有帮助，但不能完全消除CCF。然而，在某些极简系统中，或者在使用了稳定成熟并在特定环境和应用中具有广泛运行经验的代码的系统中，仍然可将CCF降低到合理且满足要求的水平。潜在软件故障属于设计错误，该错误在受到触发机制激发前，可保持在未被检测的状态。除非被触发，潜在故障本身没有危害，也不会自发地造成危害。如果该故障是系统化故障(即存在于多个序列中)且导致不安全状态，这才变成问题。对于致使安全系统进入分析时已确定的安全状态的CCF,本质上仍然是安全的。发生多个失效时，若检测到多个失效的时刻之间的间隔过短，而无法采取维修或恢复措施，则认定为同时发生失效(因此是共因失效)。应将重点放在CCF的预防和限制上，而不是放在CCF的缓解策略上面。对CCF的防御是多方面a)预防软件缺陷和共同触发(如系统分割);b)故障检测(如看门狗定时器);c)限制CCF的影响(如通过系统设计强制进入到已经过分析的安全状态);d)通过多样性和纵深防御缓解可信CCF。如果潜在CCF后果无法接受，应对电厂仪控系统(包括支持电厂安全功能的PDD)进行多样性和纵深防御(D3)分析(对于证明达到要求的D3的可接受方法见附录C)。如果PDD在性能上被证明是确定性的，所有功能状态及功能状态之间的转换均有文档记录并且基于以下准则是可测试的，则认为PDD不易受CCF影响：a)测试每一个可能的输入组合；b)对于包含模拟量输入的PDD,所有输入组合的测试应包含模拟输入的全部运行范围；c)测试所有可能的可执行逻辑路径(包含非时序逻辑路径);d)测试每个功能状态的转换；e)测试监控每种情况下所有输出的正确性。此项测试应在集成了可代表目标硬件的PDD上执行。PDD可能包含不使用的输入。如果通过模块电路强制那些不使用的输入到特定的已知状态，那些5.17商品级数字设备的使用由于商品级物项未按照核质保大纲设计和制造，应使用一种替代方法证实拟使用部件是否适用于安全级应用。这一替代方法即商品级适用性确认，其目的是证实通过适用性确认的物项在执行预期安全功能方面等效于按照核质保大纲开发的基本部件，并进而能为商品级物项将执行预期的安全功能提供合理的保证。关于商品级物项适用性确认的指导见附录D。5.17.2商品级物项适用性确认的准备宜评估风险和危害，确定商品级物项执行的安全功能，还宜关注商品级物项的故障和失效对电厂系统的其他安全功能或与对电厂其他系统的潜在影响，商品级物项适用性确认纳入配置管理。5.17.3商品级物项适用性确认的执行宜采用技术评价识别商品级物项的关键特性，关键特性分为三类关键特性：物理特性、性能特性和开发过程特性。每个关键特性都应是可检验的，可采用试验、源地检查和监查、测试等一种或多种组合进行验收。商品级物项能否通过适用性确认取决于该商品级物项的生命周期过程等是否满足核质保相关要求，或取决于适用性确认组织按照核质保大纲采取的补偿活动。5.17.4商品级物项适用性确认的维护如果商品级物项已经通过适用性确认并已采购，则应通过书面化文件对商品级物项进行跟踪。如果商品级物项发生变更，对商品级物项的变更应进行评价，评价过程中宜考虑变更对软件或固件的潜在影响。当已经通过适用性确认的商品级物项在特定安全系统中应用超出适用性确认的范围时，应针对新的应用进行附加评价。5.18简单性普遍认为，安全系统的简单性不是一个可度量的特性。因此，无法给这些系统确立简单性的可接受程度，但是仍然能采取措施避免不必要的复杂性。为了非直接与安全功能相关联的功能执行而增加复杂性，可能引入设计错误或产生系统危害。例如，能提高安全和可靠性的自测试和自诊断会导致复杂度增加。需对增加的功能带来的危害和益处采取平衡措施。对所有分配到安全系统的功能应给予合理性判断、书面化并加以分析，以确定是否在安全系统中引入了危害。任何已识别的危害应书面化，应依据5.5.2和5.3.6予以处理。6监测指令设备的功能和设计要求监测指令设备的功能和设计应按照GB/T13284.1—2008中第6章给出的要求执行。7执行装置的功能和设计要求执行装置的功能和设计应按照GB/T13284.1—2008中第7章给出的要求执行。8对动力源的要求动力源应按照GB/T13284.1—2008中第8章给出的要求执行。(资料性)危害的识别和控制A.1背景本附录为GB/T13284.1—2008的4.8以及本文件5.5.2提供支持。不同等级的系统之间，以及跨越冗余序列的相互联系和依赖性的增加可能扩大危害分析的范围。因此，本附录侧重于可编程数字设备的引入及相互联系和依赖性增加相关的新问题。本附录为危害的识别和控制提供指导。有一些技术在行业内公认用于识别和控制危害的，危害和可操作性分析4(HAZOPS)便是其中之一。经验表明，使用单一技术是不够充分的(见A.3.3.3)。为达到示例说明的目的，本附录着重介绍了故障树分析(FTA)和失效模式和影响分析(FMEA)技术。本附录并不担保任何用于危害分析的方法、技术或工具。FTA和FMEA等类似技术可用来支持电厂系统危害分析。已识别出的危害宜作为适当的V&.V活动的输入信息(见5.3.4)。A.2危害分析的目的危害分析的目的是识别并控制造成或促成危害的条件。在开展硬件和软件设计活动时，可能会将危害引入系统。危害可不是设计本身的一部分，但可能由系统设计的外部因素所造成，如有限的资源。由于对硬件危害分析已有广泛认识(如FMEA和FTA),本附录侧重于开展工程设计活动期间引入的危害，特别是软件危害。已有的设备鉴定大纲用于解决诸如地震、温度、相对湿度、辐射和电磁兼容性(EMC)等设计要求相关的危害。因此，设备鉴定证明只要这些环境应力源维持在已鉴定的限值范围内，这些环境应力源便不会引起系统内部的危害。在数字安全系统设计和集成的每个阶段均需开展危害分析。危害分析范围包括安全系统外部边界，边界与电厂其他部分(包括非仪控单元)相互接触和相互作用。本附录宜用来满足5.3、5.5、5.6、5.9、5.16中所述危害、故障和失效的分析要求。A.3危害分析实施指导A.3.1原则进行危害分析时考虑下列指导原则。a)宜尽可能避免或消除危害。b)未能避免危害时，宜对危害进行识别和控制。c)宜在整个系统开发生命周期内进行危害识别。d)在系统运行前，已识别出的所有危害宜得到消除或至少得到控制。e)还宜考虑对先前已开发系统中的危害进行评价和控制。f)对系统的危害分析计划、责任和结果宜书面化。所有危害分析文档均宜在配置控制下进行维护。危害分析过程包含三个基本步骤，各步骤均需要编制用于支持分析目标的文档。三个基本步骤a)危害识别(见A.3.3);b)危害评价(见A.3.4);c)危害控制(见A.3.5)。危害分析过程(不含过程迭代)见图A.1。危害分析计划/危害分析计划/初步危害分析危害列表危害评价危害评价系统运行和维护过程生命周期阶段方法危害控制危害识别图A.1危害分析过程图实现图A.1所示过程需要开展