HAD 102／10-2021 标准规范下载简介

HAD 102／10-2021 核动力厂仪表和控制系统设计.pdf

核动力厂仪表和控制系统设计

7.6.4应对使用软件工具的好处和风险，以及不使用软件工 具的好处和风险进行权衡。 7.6.5应选择软件工具来限制出错和弓入故障的机会，同时 最大限度地提供避免或检测故障的机会。软件工具的使用也可能 对系统开发造成不利影响。例如，设计软件工具可能会通过生成 有缺陷的输出来引入故障，验证工具可能无法揭示某些故障或故 障类型。 7.6.6选择的软件工具应在整个系统使用寿期内保持可用状 态，并且应与系统开发期间使用的其他软件工具兼容。 7.6.7应确定和记录所有软件工具的功能和适用范围。 7.6.8如果没有事先论证，软件工具及其输出不应在其声明 的功能或应用范围之外使用。 7.6.9软件工具不能完全取代人的判断。在某些情况下，通 过软件工具提供支持比完全的自动化过程更为合适。 7.6.10应根据对软件工具的可靠性要求、软件工具的类型 件工具引入故障或无法使用户发现已有故障的可能性，以及软 牛工具对系统亢余部分或多样化系统的影响程度，对软件工具进 行验证和评估。下面列举了影响验证和评估必要性程度的儿种情 况： （1）与被证明不具备引入故障能力的软件工具相比，应对 具有这种能力的软件进行更严格的验证。 （2）与能够使用户发现故障的软件工具相比，应对无法使

JTG／T 3222-2020 公路工程物探规程.pdf核动力厂仪表和控制系统设计

用户发现已有故障的软件工具进行更严格的验证。 （3）如果软件工具的输出经过系统和独立的验证，则软件 工具无须验证。 （4）如果已经采取了措施缓解任何潜在软件工具故障所产 生的后果（例如通过过程多样性或系统设计），那么对软件工具 的验证的严格程度可以降低。 7.6.11软件工具的验证和评估应考虑到以前使用的经验，包 括开发人员的经验和使用软件工具的过程中获得的经验。 7.6.12软件工具的选择、验证和评估应经过论证并形成文档 7.6.13所有的软件工具应置于适当的配置管理之下。 7.6.14在对基线设备、软件和基于硬件描述语言的器件进行 开发、验证或确认期间所使用的软件工具，其设置应在开发记录 中形成文档。这样的文档不仅有助于确保最终软件的一致性，它 还有助于对故障源头进行评估，这些故障可能出现在源代码、软 牛工具或软件工具设置中。在评估由于软件工具导致的潜在共因 故障时，相关工具设置的信息可能是至关重要的

7.7对安全应用中使用的限定功能工业数字化装置的鉴定

核动力厂仪表和控制系统设计

（2）该装置是自治的，只执行一个简单的基本功能，该基 本功能由制造商规定，不能由用户修改； （3）不可重新编程； （4）如果是可重新配置的，则仅限于可以配置与被监视或 被控制过程的匹配性相关的参数，或与所连接设备的接口。 7.7.3所有其他装置都不是“限定功能的工业数字化装置” 它们具有下列一项或多项特征： （1）使用商用计算机（例如个人计算机、工业计算机或可 编程逻辑控制器）； （2）为仪控平台开发的； （3）专门为核行业开发的。 7.7.4确认限定功能的工业数字化装置对于其预期功能的适 用性和正确性，应提供如下证据： （1）装置的主要功能符合应用的功能需求。 （2）主要功能之外的其他功能的运行或故障都不会导致主 要功能的不安全运行。主要功能之外的其他功能包括用于维护或 配置该装置的功能以及预期应用不需要的功能等。 （3）该装置不存在此类系统故障，即这种故障可能会导致 安装在仪控系统几余或多样化部分的相似装置儿乎同时发生共 因失效。 （4）有系统性的升发过程，并遵循本导则第2章的一般原 则。

核动力厂仪表和控制系统设计

（5）制造的质量保证是充分的，足以为后续制造的相同或 相似型号的设备的接受提供基础。 7.7.5在其他行业安全认证过程中的信息可以作为支持该装 置鉴定的证据。但是仅凭认证证书是不够的，认证过程中产生的 信息可能更有价值。 7.7.6如果第7.7.4节的一项或多项要求未得到满足，应提供 补充证据。补充证据应直接针对适用性和止确性证据上的薄弱点 应直接针对需要被证实的要求，并且应可证明适用于相关的装置 提供补充证据的技术方法，例如： （1）为确认装置适用于预期应用的针对性的补充工作，以 及其他正确性证据； （2）适用且可信的运行经验的评估； （3）设计输出的验证； （4）统计测试。 7.7.7用户可以对装置进行配置以使其适用于预期的应用。 比类修改应符合本导则中关于设计止确性和文档化的准则，并且 不应违背鉴定中采信的以往运行经验或测试。 7.7.8应确定该装置在预期应用中安全使用所需遵守的限制 条件。这些限制包括： （1）已鉴定装置的应用限制； （2）启用或禁用的特定选项和未使用的功能的限制； (3）运行环境和运行寿命的限制：

核动力厂仪表和控制系统设计

（4）在运行、测试和维护期间要遵守的措施等

（4）在运行、测试和维护期间要遵守的措施等。

8人机接口所需考虑的因素

核动力厂仪表和控制系统设计

核动力厂仪表和控制系统设计

8.2.1应在核动力厂适当位置（例如主控制室和辅助控制室） 显示与运行人员角色和职责相匹配的事故工况信息。 8.2.2用于事故工况监测的信息显示一般称为“事故监测系 统”或“事故后监测系统”。这些显示可以是其他系统的一部分 或是单个仪表通道的组合。

核动力厂仪表和控制系统设计

8.2.3事故监测系统应提供事故工况下核动力操纵员所需 的变量值，使其可以： （1）通过预先计划的手动动作将核动力厂带入安全状态： （2）确认基本的安全功能是否已经完成； （3）确认防止裂变产物释放的屏障（例如燃料包壳、反应 维冷却剂压力边界和安全壳）是否可能发生破损或者已经破损： （4）确认用于缓解设计基准事故和设计扩展工况后果，并 将核动力厂带入安全状态的系统的状态和性能； （5）确定是否需要启动保护公众免受放射性物质释放影响 的行动； （6）实施核动力厂严重事故管理指南。 8.2.4事故监测系统应根据第5章的指导原则进行功能分类 和设备分级，并遵守第6章中相应的通用设计要求。 8.2.5用于执行第8.2.3节显示功能的相关仪控设备应能在 对应的设计基准事故和（或）设计扩展工况下执行功能，严重事 故监测仪表的设计和鉴定应考虑预期运行环境的整个变化范围。 8.2.6对于严重事故监测仪表，根据其将承受的最恶劣的可 信工况进行型式试验并不总是可行的。这时可以采用其他方法作 为试验的补充，包括但不限于第6.3.1.5节中的方法。 8.2.7支持严重事故管理指南的事故监测功能： （1）不能由于严重事故监测仪表通道外其他仪控设备的运 行、故障或误操作而失效：

核动力厂仪表和控制系统设计

（2）或者不依赖外部电源，或者具备通过核动力厂电源系 统之外的其他电源供电的能力。 8.2.8若执行第8.2.3节申（1）－（3）和（6）项功能仪表的 单个显示通道失效会导致显示上的分歧时，应为操纵员提供消除 这种分歧的手段。单个显示通道的失效可能会导致一对几余显示 存在分歧，解决这种分歧的手段包提供额外的通道或提供程序 将有分歧的仪表读数与和它有已知关系的其他变量读数进行对 比。 8.2.9用于事故监测的仪表应覆盖事故工况下参数值可能达 到的整个量程范围。 8.2.10事故监测变量的显示应清晰可读。 8.2.11应提供电子化的操纵员辅助功能（例如安全参数显示 系统）以帮助操纵员快速确定核动力厂状态、确认事故监测通道 运行、确认它们的读数以及从直接测量确定间接测量变量的值。 8.2.12计算机化的指导可以提高安全性和采取正确动作的 确定性。 8.2.13在新的控制室设计中，安全参数显示系统和事故监测 系统的功能经常集成到用于正常运行的操纵员人机接口系统中。 对于操纵员的辅助或指导功能可以仅用于特定的工况或事故情 境，也可以用于所有的工况，包括启堆和正常功率运行

8.3运行人员通信系统

核动力厂仪表和控制系统设计

8.4仪控系统人因工程相关的总位

核动力厂仪表和控制系统设计

8.4.1必须在核动力）设计过程初期就系统地考虑人因（包 括人机接口），并贯彻于设计全过程。 8.4.2应尽实际可能地促使有类似核动力厂运行经验的运行 人员积极参与设计过程，以保证在设计过程中尽早考虑未来的运 行和设备维护的需求。 8.4.3人机接口的设计必须能按照决策所需时间和行动所需 时间给操纵员提供全面且易于管理的信息。向操纵员提供的用于 决策和行动所需的信息必须简洁明了且无歧义。 8.4.4人机接口设计应保持参考设计的正面特性并应避免其 已经导致不良运行经验的问题。 8.4.5用于安全系统监督控制的人机接口设计应采用纵深防 御原则。 8.4.6仪控系统应为操纵员提供发现系统状态变化、工况诊 断、系统操作（在必要时）及核实手动和自动动作所需要的信息。 8.4.7设计上应考虑操纵员的认知处理能力和过程相关的时 间限制。 8.4.8设计应保证从执行一项控制操作到控制系统确认收到 控制输入所需的最长时间对操纵员是可以接受的。 8.4.9仪控系统设计应保证操纵员任务可以在系统需求所规 定的时间内完成。 8.4.10信息流传输速率和控制执行的过快或过慢都会降低 操纵员效能。

核动力厂仪表和控制系统设计

8.4.11仅控系统应尽量设计成可以防止和发现操纵员的错 误，例如在错误的情境或不适宜的核动力厂配置下采取的动作， 这包括对控制系统、监视系统和保护系统的整定值修改的确认。 8.4.12仅控系统应提供简单易懂的操纵员错误提示，并提供 简单有效的恢复手段。 8.4.13操纵员的单一错误不应导致反应堆失控。 8.4.14人机接口应设计为： （1）尽可能适用于与系统交互的多种类型运行人员的不同 角色和职责； （2）首先要考虑负责设备安全运行的操纵员的角色需求； （3）支持一部分控制室成员获得共同的状况认知，例如利 用墙装全厂状态显示器； （4）提供有效的核动力厂状态总览； （5）尽量使用符合功能和任务需求的最简化设计； （6）对操纵员培训的依赖降至最低： （7）提供的信息能够被操纵员快速识别和理解，以降低操 纵员认知的工作负荷； （8）在模拟和视频显示失效时不会对控制动作产生重大十 扰； （9）考虑人员生理特性、人员运动控制特性和人体测量学 特性。人的生理学特性包视觉、听觉感知和生物力学（触及和 运动）等。

核动力厂仪表和控制系统设计

8.4.15人机接口、规程、培训系统和培训应彼此之间保持 致。 8.4.16信息显示的集成应协调布局，从而有利于操纵员对核 动力厂状态的理解，优化核动力厂控制所必需的活动。 8.4.17人机接口的操作和外观应在不同监控点和平台之间 保持一致并高度标准化。 8.4.18所有描述性标识和标签应考虑使用同一种语言和协 调一致的字体。 8.4.19仪控系统的所有特性（包括控制和显示布置）应与操 纵员心智模型相一致并符合传统习惯。心智模型包含了操纵员对 于系统行为的理解和预期，通过培训、规程的使用和经验获得。 8.4.20设计时应确定各类控制和显示类型的风格，并且在控 制和核动力厂状态显示的标识、布局和布置上遵循。 8.4.21人员和自动动作交互的考虑 8.4.21.1应使用系统化的、一致的方法，确定人和仪控系统 之间适当的功能分配。 8.4.21.2影响人机之间功能分配的因素包括： （1）所有运行模式下潜在的人员负荷； （2）准确度和重复性的需求； (3）时间因素; （4）决策和所需动作逻辑的类型和复杂程度； (5) 环境因素;

核动力厂仪表和控制系统设计

（6）人体生理学和人体测量学。 8.4.21.3必须把对操纵员在短时间内进行干预的需求降至最 低，并必须证明操纵员有足够的时间作出决策和采取行动。 8.4.21.4如果操纵员无法可靠并及时地完成手动动作，或依 靠手动控制将导致操纵员负荷过重，仪控系统应提供自动动作。 8.4.21.5仅控系统应为操纵员提供监视所有自动功能所需 的信息。 8.4.21.6仪控系统应为操纵员提供多种手段来确认自动动 作。 8.4.21.7用于自动功能监视的信息显示的速率和详细程度 （例如用于确定目标或验证）应使得操纵员能够有效实施监视。 8.4.21.8仪控系统应充许操纵员手动启动或控制用于控制 核动力厂和维持安全所需的每个功能。 8.4.22仪控系统中任务设计所需考虑的因素 8.4.22.1操纵员的职能应由有明确目标和意义的任务组成： 使操纵员保持对核动力厂的熟悉并维持合理的工作负荷，从而既 不会影响操纵员效能，又能使其保持充分的警惕性。 8.4.22.2仪控系统应包含任务分析确定的所有必要的特性。 8.4.22.3任务分析应考虑所有核动力厂状态、运行模式和运 行人员，例如反应堆操纵员、汽轮机操纵员、机组长、现场操级 员、安全工程师和运维人员。任务分析应为仪控系统提供设计输 入信息，例如显示信息的准确度和精度要求、系统响应时间、物

核动力厂仪表和控制系统设计

理布局、控制显示和报警类型以及软控制与信息显示的集成。 8.4.22.4人机接口显示单元上的控制和显示信息应按照最 更于任务执行的方式进行配置，从而有利于提高任务效能。 8.4.22.5人机接口的各个方面（格式、术语、排序、分组和 操纵员决策支持辅助）均应体现出基于任务需求或其他合理依据 的清楚的逻辑性。 8.4.22.6所有显示、控制和数据处理与相关功能和任务的关 系应清晰明确。 8.4.22.7人机接口为操纵员提供信息的格式和形式应符合 任务分析结果。 8.4.22.8仪控系统为操纵员提供的控制选择应覆盖任务分 所所确定的各种可能的操纵员动作。 8.4.22.9仪控系统应为操纵员提供执行动作的多种手段。 8.4.22.10仪控系统应充许操纵员执行最少的动作就可以完 成任务。 8.4.23可达性和工作环境所需考虑的因素 8.4.23.1运行人员的工作场所和工作环境的设计必须符合工 效学概念。 8.4.23.2对于预计运行人员执行核动力厂系统监控所处的 区域，应采取必要措施确保合适的工作环境并使其免受危害影响 工作环境通常要考虑照明、温度、湿度、噪声、振动等，当需要 持续监视时还应考虑休息区域和卫生间。要考虑的危害包括辐射

核动力厂仪表和控制系统设计

9.1.1本章的要求适用于仪控系统安全重要设备中使用的所 有软件类型，例如操作系统、已开发软件或固件、针对项目专门 开发的软件以及在现有的已开发系列软硬件模块的基础上开发 的软件。 9.1.2 相对于模拟系统，数字化系统需要采用不同的可靠性

核动力厂仪表和控制系统设计

分析方法。数学化系统的可靠性可从对生产活动质量及验证和确 认结果的评估来推断。软件的固有特点使其比硬件（电气或机械 设备）具有更大的设计空间。如果不加以系统性的约束，将容易 产生缺陷且无法验证。软件实现的复杂度会在设计中产生额外的 故障、增加发现和纠止故障的难度、弓入在简单设计中不存在的 失效模式和影响、降低与安全系统设计准则（例如独立性、可测 试性和可靠性）符合性相关论证的可信度。 9.1.3第2章对质量保证和全生命周期过程的要求与软件特 别相关，因为其所覆盖的活动对于有效的软件开发是不可或缺的 9.1.4基于计算机的安全重要系统必须确定或制定用于开发 和测试/验证计算机软、硬件的适当的标准和规范，并在整个寿 期内执行，特别是在软件开发过程中应执行这些标准和规范。整 个开发过程必须遵循质量保证体系。 9.1.5系统的软件开发应按照预定的生命周期进行，应充分 的规划并形成文档，同时应包括全面的验证和确认（详见第2章）

核动力厂仪表和控制系统设计

9.2.3软件需求的开发者应对第3章中所述的系统设计基准 有看充分的理解。理解系统的设计基准对于确保软件需求能够止 确的满足系统的基本属性来说是必要的。需要考虑的设计基准包 括： （1）潜在的故障状态； (2）运行模式； （3）用于安全目的的监视； (4）自监督; (5）故障探测； （6）在出现可探测但不可恢复的故障时应达到的安全状态； （7）其他故障安全特性； （8）安全相关的输入输出关系。 9.2.4软件需求规格书： （1）应定义每个软件需要做什么及其与系统内其他软件如 何交互； （2）软件需求应来自仪控系统生命周期的相关过程（包括 对在先前分析中识别出的系统危害的考虑），以及与仪控系统生 命周期接口的过程，例如人因工程和网络安全活动（见图1）； （3）应尽量描述所需实现的自标，而不是描述这些自标如 何设计和如何实现； （4）其内容应完整、无歧义、前后一致、便于阅读、易于 使用者（例如该领域的专家、安全工程师和软件设计者）理解，

核动力厂仪表和控制系统设计

和验证阶段均可对软件需求进行主

核动力厂仪表和控制系统设计

9.3.1完整的软件设计应做到能够无歧又的、止确的和完整 的体现软件需求、前后一致、结构合理、便于阅读、易于使用者 （例如该领域的专家、安全工程师和软件设计者）理解、可验证 可确认、可追溯、可维护和文档化。 9.3.2应采用预先确定的、与系统的安全重要程度相匹配的 技术组合来进行软件设计并保持更新。此类技术可包括文学描述 定义了明确语法语义的逻辑图和图形化表达、建模、分析和审查， 9.3.3软件设计应在理解安全需求来源的情况下进行。 9.3.4应充分区分软件设计的各个部分，以便于保持软件需 求的可追溯性。 9.3.5安全系统的软件设计应在各个层次上尽可能地简单， 包括总体结构、外部接口、模块间的内部接口以及详细设计。 9.3.6简单化设计是实现和证明安全性的关键手段，但通常 需要进行折中考虑（例如功能性、灵活性和成本之间的取舍）。 虽然简单化设计要求仅适用于安全系统，但简单化设计对低安全 等级系统也是可取的。对于低安全等级的系统，安全性和复杂性 之间的取舍关系是不同的，更高复杂度的设计也是可以接受的， 9.3.7软件的设计架构应是结构化的，以便于未来的修改、 维护和升级。 9.3.8软件架构应是层次化的，提供抽象化的层次分级

核动力厂仪表和控制系统设计

9.3.9在可行的情况下可使用“信息隐藏”技术（指一个模 块内包含的信息，对于不需要这些信息的其他模块来说是不可访 同的），以便于分段审查和验证并便于修改。 9.3.10软件设计应包含软件与外部环境的接口。 9.3.11软件设计应包含所有软件模块的详细设计。 9.3.12软件模块的描述应完整地定义其功能、与其他模块的 接口以及其功能与整个软件的关系。 9.3.13具有相似功能的软件模块在结构上应一致。 9.3.14模块的接口应一致。 9.3.15模块之间每个接口的两侧应匹配，输入侧和输出侧变 量的命名应一致，同时应尽可能地避免模块的递归调用。安全系 统不应使用递归调用。 9.3.16如果系统包含多个处理器且软件分布在不同的处理 器上执行，软件设计应规定每个进程在哪个处理器上运行，并规 定数据和显示的所在位置。 9.3.17软件设计应支持安全系统的确定性行为和确定性时 限。 9.3.18通信协议应满足第7.5.4节的要求。 9.3.19在设计细化时，应考虑故障探测和自监督特性的附加 功能需求，并包括在软件设计中（见第6.6.3.6节）。 9.3.20在检测到故障时，应采用适当措施满足恢复或停止进 程，错误信息和日志等方面的软件需求，保证系统处于安全状态

核动力厂仪表和控制系统设计

9.4.1软件实现应满足： （1）应正确和完整地体现软件需求，完整地体现软件设计， 结构合理，具备可读性、可验证性、可追溯性、可维护性，适当 地文档化； （2）应采用预先确定的、与系统的安全重要程度相匹配的 技术组合，包括编程语言、软件工具、代码编写规范、分析、审 查、测试等； （3）应可证明已落实所有软件需求和软件设计；

核动力厂仪表和控制系统设计

（4）应简单并易于理解，相对于易于编程，应优先保证可 读性和可维护性； （5）应包括可读形式的源代码和可执行代码、单元接口测 试和模块接口测试的结果及充分的上下文信息，以验证代码相对 于其规格书的正确性。 9.4.2代码应充分的文档化。 9.4.3对于安全系统，所有代码（包括运行时支持代码和故 障监督功能）应有对应的描述文档，以满足本导则中测试相关的 要求。 9.4.4应在开始编写代码前制定代码编写规则，并验证规则 的执行情况。 9.4.5应采用一致的数据结构和命名规则。 9.4.6软件实现应满足下列要求： （1）执行规定的变更控制程序（包括影响分析）； （2）执行配置管理； （3）对于所有变更结果保证适当的测试覆盖率。 9.4.7所用的编程语言（或语言子集）应能满足表达力、避 免不安全表述、抽象层级、对模块化和信息隐藏的支持、编译检 查和运行时检查、错误处理方面的要求。 9.4.8安全系统所用编程语言应支持简明化的软件实现。 9.4.9编程语言的选择和采用的功能定义方式（例如逻辑图 或图形化表达）应基于对功能性和过程完整性需求的系统评估。

核动力厂仪表和控制系统设计

9.4.10对于安全系统，应对编程语言的选择进行合理性论证 并形成文件。 9.4.11对于安全系统，编程语言的语法和语义应完整、有效 并有严格的定义。 9.4.12软件函数是执行特定功能的编程元素。这些函数可能 是编程语言固有的、包含在库文件中的或以其他形式预先开发的 9.4.13软件函数的使用自的是最大程度上提升软件的简单 生，使用的软件函数应是事先确定的，有明确定义的接口，其调 用应遵循相关的使用限制条件。 9.4.14如果使用操作系统，则应对其进行（或已进行过）深 入全面的测试，并论证其对于目标应用的适用性。 9.4.15对于安全系统，所有的操作系统软件应符合本导则的 全部要求。 9.4.16应以错误最小化为目标选用合适的软件实现工具。相 关要求见第7.6节。 9.4.17第9.4节的要求适用于使用代码生成和传统软件开发 方式的所有可能的组合。 9.4.18软件多样性（即采用独立的开发团队和/或不同的方 法、语言、时序、函数或算法顺序）可以作为降低软件共因故障 可能性和影响的手段。然而软件多样性会引入设计限制，这些限 制本身可能会导致新的故障。 9.4.19应采取预防措施以避免因使用相同的软件（例如操作

核动力厂仪表和控制系统设计

系统、网络通信软件或其他运行支持软件）导致各层纵深防御所 需系统之间的独立性被破坏。 9.4.20软件实现团队应接受过安全开发技术培训。

9.5.1软件的需求、设计和实现应根据仪控系统需求规格书 进行验证。 9.5.2可追溯性的验证应是一个持续的活动，以确保尽早发 现不足并进行必要的修改。 9.5.3软件生命周期内每个阶段的成果均应按照上一阶段的 需求进行验证。 9.5.4应生成软件验证计划以记录： （1）所米用的验证技术； （2）每种技术对应的验证程序的细节或参考资料，包括程 序的范围和深度； （3）如何证实非功能需求和限制条件已得到满足； （4）判断验证是否充分的准则，包括对于前一阶段设计输 出的验证完整性目标和功能测试的覆盖率目标，以及如何证实已 经实现了这些目标； （5）验证结果的记录方式； （6）不符合项和缺陷的记录和解决方式； （7）执行验证的团队以及该团队与软件设计者之间的独立 性：

核动力厂仪表和控制系统设计

（8）验证所用的软件工具的功能，预期的使用方法（例如 适用范围、语言和流程）和使用限制； （9）确定上述（1）－（8）项的依据，以及对所实施的软件 验证充分性的论证（相对于软件所属系统的安全等级）。 9.5.5验证应包含以下技术： （1）人工检查，例如审查、走查、检验或审核； （2）对源代码的静态分析； (3）动态分析。 9.5.6静态分析应在软件的最终版本上进行。 9.5.7静态分析所采用的技术因系统的安全重要程度而异。 静态分析技术包括与设计和代码编写标准的符合性验证、控制流 分析、数据和信息流分析、符号执行、形式化代码验证等。 9.5.8应对软件中实现的所有非功能需求进行验证。 9.5.9应根据相关运行经验来识别软件异常，并予以纠正， 以进一步提高对于软件可靠性的置信度。相关运行经验可作为其 也验证技术的补充，但不能代替其他验证技术。 9.5.10第7.6节给出了使用软件验证和分析工具的相关要求 9.5.11应为软件实现的验证和确认确定测试的策略（例如自 下向上的策略或自上向下的策略）。 9.5.12测试用例规格书应确保以下项目得到充分测试： （1）接口（例如模块间的接口、软硬件间的接口、系统边 界接口）：

核动力厂仪表和控制系统设计

（2）数据传输机制和接口协议： (3）异常状态; （4）每个输入变量的全范围（采用等效类别划分和边界值 分析等技术）； （5）系统的所有运行模式。 9.5.13测试计划应确保测试是可重复的且测试结果得到记 录，以便于开展回归测试。 9.5.14应尽量减少重复性测试中所需的人工十预。 9.5.15所有测试工具的选择、标识、使用方法、标定要求和 标定间隔应予以规定。应明确对测试工具进行管控的责任。 9.5.16应审查测试用例规格书及其有效性，对相对于验证计 划目标的任何不足，均应予以解决或进行合理性论证。 9.5.17验证工作应由独立于设计者和开发者的团队、个人或 工作组执行。 9.5.18应审查源代码以检查软件安全漏洞，审查中应使用自 动的软件工具，并辅以关键代码（例如输入输出处理和异常处理， 的人工审查。 9.5.19验证过程中应监视仪控系统的所有输出，同时分析和 记录所有与预期结果的偏差。 9.5.20验证结果相对于验证计划的不足（例如实际达到的测 试覆盖率）应得以解决或论证。 9.5.21对于任何检测到的错误，应分析其原因、按照批准的

核动力厂仪表和控制系统设计

核动力厂仪表和控制系统设计

9.6.1安全系统中使用的已开发软件应和为该应用专1开发 的软件具有相同的鉴定等级。 9.6.2已开发软件的功能应符合第2.4.2节的要求。 9.6.3对于安全系统以外的安全重要系统，已开发软件应具 备用户文档，描述： （1）所提供的功能； （2）接口，包括输入、输出、异常信号、参数和配置数据 的作用、类型、格式、范围和限制； （3）不同的行为模式及其对应的转换条件（如适用）； （4）使用已开发软件需满足的限制条件； （5）对于已开发软件符合用户文档（1）－（4）项的论证； (6）对其功能适用于仪控系统的论证。

第7.6节提供了软件工具的要求。

9.8.1安全系统软件的第三方评定应和软件开发过程同步进 行。 9.8.2第三方评定的目的是提供关于系统及其软件适当性的 评定，该评定独立于系统和（或）软件的供应商和运行机构。这 样的评定可以由监管机构或监管机构认可的组织承担。

核动力厂仪表和控制系统设计

9.8.3与软件开发者进行适当的约定和妥善的安排以便于开 展第三方评定。 9.8.4评定应包含以下内容的检查： （1）开发过程（例如通过质保监查和技术检验，包括检查 生命周期文档，例如计划、软件规格书和全范围测试活动的文档） （2）终版软件（例如通过静态分析、检验、审核和测试） 和后续变更。

溧水游泳馆施工方案核动力厂仪表和控制系统设计

在本导则中下列名词术语的含义为： 部件。组成系统的一个部分。一个部件可以是硬件或软件， 并可以再细分为其他的部件。 非功能需求（也称质量需求）。除功能和行为需求之外，规 定物项的固有属性或特性的需求。例如可分析性、可用性、可维 护性、可靠性、安全性、可验证性、准确性和响应时间，等。 固件。装载到一类存储器（例如只读存储器ROM）、在处 理过程中不能由计算机动态修改的计算机程序和数据。 功能需求。规定物项需具备的功能和行为的要求。 和缓环境。严酷性不超过在核动力厂止常运行和预计运行事 件期间的环境。 校准。在规定的条件下，确定测量仪表或测量系统的指示值 实物量具、参考物质所表示的值与相应标准规定值之间关系的 组操作。 结构。核动力厂安全重要仪控系统的组织架构。 静态分析。基于系统或物项的组成、结构、内容或文档对其 进行分析。 可靠性。在给定状态下和给定时间间隔内某物项（或系统， 完成所要求使命的概率。 可用性。反映某物项（或系统）按命令工作的概率。包括稳 态可用性，即某物项（或系统）长期运行时预期满意工作的时间

核动力厂仪表和控制系统设计

份额；和瞬态可用性，即在某一特定瞬时，某物项（或系统）将 正常工作的概率。 配置基线。在物项生命周期中的特定时间点上正式指定和固 化的一系列物项配置。 确定性时限。系统或部件从激励到响应之间的延时保证在 定范围内的特性。 确定性行为。系统或部件在规格范围内任意输入序列总是产 生相同输出的特性。 确认。通过检查或提供其他证据，证实该系统完全满足预期 的需求规格书要求。 人机接口。运行人员与连接到核动力厂的仪控系统之间的接 口，包括显示、控制以及与操纵员辅助系统之间的接口。 生命周期模型。一个框架，它包括从需求定义到使用终止， 贯穿整个生命期的系统开发、操作和维护中所需实施的过程、活 动和任务。 危害。潜在的损害。 危害分析。对系统全生命周期的检查过程，以识别其固有危 害和危害因素，以及消除、预防、控制危害的要求和限制。 危害因素。导致潜在损害的因素。 现场可编程门阵列（FPGA）。可由仪控制造商进行现场编 程的集成电路，包含了可编程的逻辑模块（组合或顺序使用）、 逻辑模块间可编程的连接关系及可编程的输入输出模块。其功能

核动力厂仪表和控制系统设计

由仪控设计者定义，而不是由电路制造商定义。 型式试验。对代表产品的一个或多个物项进行的符合性试验 序列。构成亢余系统或安全组合的一个亢余度的一系列物项 及其连接。一个序列可以包含多个通道。 需求工程。包含了对一系列需求开发、记录和维护活动的工 程过程。 严酷环境。由反应堆冷却剂丧失、主蒸汽管道破裂和其他高 能管道破裂导致的环境。 验证。通过检查和提供客观证据，证实一项活动的结果符合 为此活动规定的目标和需求。 硬件描述语言（HDL）。为形成文档、仿真或综合，用来 正式描述电子部件的功能和（或）结构的语言。 硬件描述语言可编程器件。使用硬件描述语言及相关软件工 具配置的集成电路器件（对核动力厂I&C系统）。 已开发模块。可用于硬件描述语言的已开发功能模块，包招 库、宏或知识产权核。在开发硬件编程设备之前大观城市花园园林绿化工程施工组织设计方案，可能需要对已 开发模块进行大量的工作。 已开发物项。已存在的可用于仪控系统的商用或专用产品。 已升发物项包括硬件设备、已升发软件、包含硬件和软件的数字 化装置或通过硬件描述语言或已开发模块配置的硬件设备等。 知识产权核。集成电路设计中，功能明确、接口规范、易于 验证、便于重用、具有开发者自主知识产权的电路功能模块。