5.3. 1.2 系统配置

应在评估规范中规定被评估系统的配置。由于系统的可配置性本身就可以作为一个被评估的系统 寺性，因此宜谨慎规定用于评定被评估项的系统配置 如果评估目的是评估用于某个特定使命的某个特定系统，评估应在特定的系统配置上进行，并应将 比配置在评估规范中写明。 如果评估目的是评估某个系统满足某个特定工业领域的宽范围的典型要求的灵活性，评估应在可 通过多种方式配置的已确定的模块范围内进行。模块范围和不同配置方式应在评估规范中写明

有时系统过于复杂，以致于对所有系统特性的综合评定不够经济，甚至不可行。通过谨慎考虑评估 目的、系统配置和影响因素，评定可缩减到仅包括对系统使命最敏感的评估项

水利常用表格5.3.2系统特性和影响

应规定评估所需的评估项，并应规定每个系统特性和影响因素所需的值和值的范围。 此外，宜尽可能地包括GB/T38852.1一2020中描述的适用的影响因素。 宜对每个评估项做审查，以确定其是否影响系统或使系统性能降级以致阻碍其他评估项的正确 买施。 上述考虑应在评估规范中写明，以对评估活动的顺序施加约束。 记录系统特性和影响因素的一种便捷方法是使用矩阵的形式。矩阵的单元格对应评估项。 用于汇总评估的通用矩阵的例子见表2

应选择评估需包含的评估项，并应确定各评估项的优先级。可借助此矩阵作为考虑各系统特性、各 影响因素和评估目的的一种方式，以完成上述工作， 通过如特性组或特性子组等方式逐步细化评估项，此时通用矩阵的表头进一步扩展为更详细的系 统特性和影响因素 宜对与特定评估无关的评估项进行识别以备后用.并记录排除这些项的原因

5.3.3文档化信息整理

整理是该阶段的一个步骤，用于提取确定备选评估项所需的信息。该过程提供的信息用于评不 和规划。 依据整理的目的，应从SRD和SSD中提取必要的信息。 应仔细审查SRD和SSD，以编制对主题的简练精确的表达。主题的例子包括： 系统边界； 系统要求和系统规范的不一致之处； 要求的和将来可能的任务列表； 用于执行要求的和将来可能的任务的功能列表； 连接支持所需任务的功能的可选数据路径列表； 模块和组件的功能分配； 这些模块和组件的数目： 这些模块和组件满足所需任务的程度； 对应上述功能的系统特性； 对应上述模块/组件的影响因素， 应由这些主题创建备选评估项列表。应在特定系统配置下，针对评估目的对评估项做出规定。 为获得所需的置信度的提升，应分析每个备选评估项以确定对其评定的程度。 对表达的描述宜包括定性和定量的形式，如果适用，包括其值的范围。 注：整理文档的例子参见附录C。 宜按照其输人、输出和工作的方式对每个被评估任务进行描述。 对每个输人，宜做下列说明： 一允许的输人状态，以及对应允许的输出状态； 不允许的输入状态，以及对应要求的动作。 对每个输出，宜做下列说明： 允许的输出状态； 不充许的输出状态，以及对应要求的动作

对每个任务，宜清晰说明下列任务信息： 影响每个任务的失效类型； 每种失效允许的发生率； 对每种失效采取的措施； 模块恢复之前任务可停止的最大时长

对每个任务，宜清晰说明下列任务信息： 影响每个任务的失效类型； 每种失效允许的发生频率； 对每种失效采取的措施； 模块恢复之前任务可停止的最大时长

5.3.4整理信息建档

程控制的形式文档化， 如果整理的信息缺失或不完整，宜从SRD和SSD的来源获取进一步的信息。这些进一步或者额 外信息宜被正确记录在评估规范中

完整的评估项列表可以考虑如下因素进行简化： 任务对使命的重要性； 基于先验知识的已有置信度； 一不同功能、接口数目、不同任务中相同功能复用的相互依赖程度； 一可获取的全局先验知识以及将其应用于评估项的程度。 相对重要性的评估宜考虑任务在系统寿命中特定阶段内的重要性，以及该阶段的持续时间。因为 重要性可能随阶段变化。 已有的置信度可基于之前相同或相似使命中系统的成功案例、制造商经验、相同类型或者可比系统 的用户经验

评估规范是描述评定内容的文件。评估规范宜至少规定如下要点： 评估目的，见5.2； 系统边界，见5.3.1.1； 系统配置，见5.3.1.2； 评估矩阵，见5.3.2； 评估项列表，见5.3.2； 任务列表，见5.3.3； 评估项简化准则，见5.3.5； 每个评估项参考标准

在本阶段，评估程序应基于上一阶段准备的评估规范进行制定 评估程序设计的目的是提高系统对系统使命的适应性判断的置信度 评估活动应最大化提升置信度，同时满足成本和时间限制。 评估程序应以使评估可控的形式规范评估活动及其时间顺序， 评估程序应包含一系列的评估活动，每个活动可以是： 一在系统级的观测；或 一组成系统级推理的较低级观测，如果必要可以延伸到组件级。 依据所考虑系统的特性设计单个评估活动。 评估程序宜规定每个评估活动的细节，包括：

评定技术类型；和 所需工具和设施。 选择采用的评定技术，其结果宜可以定性和/或定量与要求进行比较。 要求访问评定系统的所选评定技术可以仅使用系统文档分析或者基于经验分析。实际选择的技术 是对使用系统文档和限制的模块组合进行分析和经验测试的结合。 应按遵守（评估规范指定的)评估项的所有限制的逻辑顺序，计划评估活动。为了选择评估程序中 的评估活动，宜通过决定如下方面，分析潜在评估活动： 评定技术和工具； 实施成本和时间； 重要性。 宜重复制定评估程序.直到评估各相关方达成一致

5.4.2设计评估活动

评估活动列表宜基于以下条件制定： 支持评估所需的分析类型和/或评定类型； 特定系统特性对总使命的重要性； 系统特性和影响因素对使命的重要性： 实施分析和/或测试所需的知识和技能； 性能和其他系统特性测试导致的永久影响对评估计划造成的药束；： 尺寸、重量、设施可用性、测试环境控制的技术限制； 所选人员是否可用； 执行观察可操作性任务的一组所选的操作人员是否可用； 执行分析和测试的工具和设施； 评估活动工具的可用性； 每个分析和测试的成本和时间估计； 评估活动的成本和时间估计； 每个评估活动的优先等级； 基于先验知识的置信度。 有必要考虑几种互补的评定技术。 所有的评估活动应纳人系统评估程序

评估程序宜至少规定以下几点： 所选评定技术见5.4.1； 所考虑的条件见5.4.2； 评估活动见5.4.2； 要求的置信度提升； 考虑测试可能造成的永久影响的评估计划： 分析和（或)评价失效模式以及由此产生的预期影响； 系统提供的物理完整性和信息安全机制

评估活动应根据5.4中规定的评估程序 如果评估过程或评估协议存在必要变化时，宜在评估报告中对该变化进行记录。除非可采取提

达成一致的预案，否则该变化应得到评估权威机构的批准 应在进行所有观测、测量、计算时记录在评估报告中

评估实施和评估结果应形成评估报告文档。 评估报告宜准确、清晰、无歧义，并且客观地提供目的、结果等所有相关评估信息。 评估报告应至少包含以下信息： 评估报告标题； 报告唯一标识（UID）； 发布日期； 评估机构名称； 评估规范参考，见5.3.6； 评估程序参考，见5.4.3； 系统配置，如输人输出的类型和数量，需要的扫描率、系统使命、任务和功能； 使命特征，比如评估特定使命时的过程类型： 被评估系统的描述和标识，包括显示带有模块号的硬件和发布日期的软件的列表； 评估中要点的总结及其得到的结论； 统计程序、方法、规范和测试（最好以矩阵为形式，并提供补充参考文件）； 选择特定评估项进行评定的原因，及不选择其他项的原因； 评估程序的变化（增加/删减）； 有合适的表、图、照片支持的测量、测试和得出的结果； 观测到的失效； 测量的不确定性声明； 系统是否符合评估要求的声明，包括所有不一致性的声明。 评估报告的格式宜标准化，以便于比较不同系统的评估。宜采用如列表、矩阵和图形等合适 持评估结果。 评估报告发布后的修正和补充应仅通过补充报告进行，补充报告应引用原报告的标题和编 可行，补充报告应达到和原报告相同的要求，

评估实施和评估结果应形成评估报告文档。 评估报告宜准确、清晰、无歧义，并且客观地提供目的、结果等所有相关评估信息。 评估报告应至少包含以下信息： 评估报告标题； 报告唯一标识（UID）； 发布日期； 评估机构名称； 评估规范参考，见5.3.6； 评估程序参考，见5.4.3； 系统配置，如输人输出的类型和数量，需要的扫描率、系统使命、任务和功能； 使命特征，比如评估特定使命时的过程类型： 被评估系统的描述和标识，包括显示带有模块号的硬件和发布日期的软件的列表； 评估中要点的总结及其得到的结论； 统计程序、方法、规范和测试（最好以矩阵为形式，并提供补充参考文件）； 选择特定评估项进行评定的原因，及不选择其他项的原因； 评估程序的变化（增加/删减）； 有合适的表、图、照片支持的测量、测试和得出的结果； 观测到的失效； 测量的不确定性声明； 系统是否符合评估要求的声明，包括所有不一致性的声明。 评估报告的格式宜标准化，以便于比较不同系统的评估。宜采用如列表、矩阵和图形等 寺评估结果。 评估报告发布后的修正和补充应仅通过补充报告进行，补充报告应引用原报告的标题 可行，补充报告应达到和原报告相同的要求

选择使用的评定技术，其结果应以评定要求的置信度、定性和（或）定量地与系统要求文档中规定的 要求进行比较， 被选择的要求访问评价系统的评定技术是可以仅采用系统文件、当前证据或数据的分析性技术，或 者在一些案例中也可以是分析技术和经验技术的结合。 实际选择的技术是对使用系统文档和限制的模块组合进行分析和经验测试的结合。 为此，系统模型宜由一系列系统功能组成，这些功能足够一致地表示执行的任务，并详细图示人机 界面提供的交互方式。 注，模型例子的描述参见IEC6 2016的雕录D

选择使用的评定技术，其结果应以评定要求的置信度、定性和（或）定量地与系统要求文档中规定的 要求进行比较， 被选择的要求访问评价系统的评定技术是可以仅采用系统文件、当前证据或数据的分析性技术，或 首在一些案例中也可以是分析技术和经验技术的结合。 实际选择的技术是对使用系统文档和限制的模块组合进行分析和经验测试的结合。 为此，系统模型宜由一系列系统功能组成，这些功能足够一致地表示执行的任务，并详细图示人机 早面提供的交互方式。 注，模型例子的描述参见IEC6 2016的附录D

描述了制定和评审SRD的方法，包括每个系统

为评估BCS，需要建立系统使命。 系统使命只有考虑系统背景时才能正确定义，即人员、相关过程、其他相关系统，以及系统本身的 不境。 A.2.2～A.2.5中提到的活动产生系统要求文件（SRD)

A.2.2系统使命规划

本阶段的目标是定义BCS的使命，而不是BCS执行的角色。 使命描述宜声明要达成的目标，而不是为什么和如何达到目标。 系统使命宜详细描述各个阶段，可包括： 初始配置和调试整个设施，包括人员、工厂、BCS以及其他可能被用来完成使命的系统； 特定生产运行的配置或设置； 包含稳定连续操作或子操作的编程的序列的生产： 生产运行间的切换； 紧急停车或者紧急切换到安全保持状态； 正常停车； 为纳人新的任务和功能而升级和更改系统： 运行阶段后的系统停用。

A.2.3系统使命分解为

为了完成使命，BCS需要执行特定任务，和/或识别上述每一个使命阶段相关的特定系统特性。检 查这些阶段，以定义系统要求执行的任务。 阶段内的任务可能是，比如： 监视并集中显示被监视的值，可包含被测变量的处理以推导出使命变量的值： 根据手动输入或自动命令激活过程中的特定阶段； 自动过程控制，比如单个过程变量的自动控制； 过程变量间的互锁； 阶段的自动初始化和执行。 可能会要求BCS执行任何特定任务或特定任务的一部分，即和其他系统或人员共享的任务

详细定义每个任务，阐明分配给BCS的任务范围。每个任务的需求宜以功能、性能、可靠性、可操 作性、系统安全性及其他特性，比如质量保证、售后服务等术语进行定义。 宜注意到此阶段的目标是定义系统的任务，而不是系统的功能

A.2.4分配任务的相对重要性

本阶段考虑使命对每个任务的依赖性。任务宜至少可以按照对使命的重要程度分类为： 关键的：对完成使命很关键的任务： 重要的：任务并非关键，但对使命的成本效益产生重要影响； 可取的：任务是可取的，但对使命只产生微小影响

A.2.5确定影响因素

为完成系统使命，系统要按要求执行每一项任务，执行任务的正确性可能受到影响因素的损害， 在此阶段，有必要考虑可能影响每一项任务的要求准则的因素

A.3系统要求文件（SRD)的审核

在附录A中每类特性的相关部分，提供了系统要求文件中对应于该类特性的检查点的指导。 评估的有效性取决于要求的综合声明

录B给出了制定和评审SSD的方法，包括每一个

B.2制定系统规范文件

附录B （资料性附录） 系统规范文件（SSD

制定SSD的出发点是SRD已分解为被分配了相对重要性的任务。 从这一点出发，把每项任务映射在功能模型上（见5.1.1和GB/T38852.1一2020的图4），就能得到 执行系统要求的系统实施。 在评估阶段，由SSD提出的系统将与系统要求文件中记载的关于使命的详细说明进行比较。 为了能有效地分析与系统要求的一致性，由提出系统的规范来识别各个关键点是十分重要的 3.2.2~B.2.7对此做了详细说明。 B.2.2B.2.7中提到的活动.将形成系统规范文件

概述的目的正如SRD中所反映的那样，是将系统实施与系统使命进行有机结合。 正如使命可以接层次分解为任务，被评估系统同样可以按层次分解为模块和组件。 可以预计，通过分解可产生概况图和补充描述， 概况图和补充描述至少宜包含以下内容： 与过程、操作人员、外部系统等交互的所有模块； 通信模块； 一应用处理模块； 一模块之间的相互作用； 各模块的相对距离、绝对距离和位置， 就分解而言，重要的是要了解，绝大多数现代BCS都是基于混合结构的，由独立的测量和控制装置 及相关软件联合组成。

B.2.3定义系统边界

一个系统有若十个明确的边界，分别是与过程、供电设施、系统所处坏境、连接的其他外部系统以及 系统使用者（操作人员、维护人员）的边界。 通过识别哪些属于、哪些不属于被评估系统，从而仔细地定义系统的边界，同时至少考虑以下同题 与过程的边界可以设置为包含或不包含信号调制器、电气隔离器、连接单元、电缆、输人/输出 装置（如传感器和最终控制元件）等。 与供电设施的边界需考虑采用不同制造商生产的设备，例如不间断电源、电池、滤波器、稳压器 等，这些设备都可以为整个系统或系统的一部分（包括传感器和最终控制元件）供电

与外部设备的边界宜考虑所需的接口、通信功能、电缆等。 与环境的边界宜考虑系统模块和组件的物理分布，这些模块和组件可能放置在空调房间内、办 公环境内、过程区域内或直接放置在过程装置上等。 在评估系统的可信性时，人机界面的边界尤为重要，因为在完成预定使命的过程中，操作人员 和维护人员将发挥重要作用。在控制层的若干个层次上都可能发生人与系统的相互作用，这 很大程度上取决于所考虑的操作模式，同时还涉及系统的所有硬件和软件模块， 尽管并不明显，但任务本身是在系统边界外。施加、改变和增加任务所造成的影响是评估系统 的“灵活性和可扩展性”特性的重要方面。 当评估目的是“获得对不同系统的比较评估”时，如果这些系统的功能范围各不相同，就可能无法以 完全相同的方法定义每一个被比较系统的边界。在此情况下，宜增加所考虑系统以外的其他装置，从而 使比较工作得以进行。宜特别注明所增加的装置

系统规范旨在为提出的系统实施提供精确的数值、操作和关系数据。 系统规范通常宜包括 完整的模块和组件清单； 各种模块和组件的产品规范，宜给出基本的功能和技术规范（包括环境规范）； 详细的互连示意图，适用时宜识别并进一步规定各个模块和组件之间（包括几余通路）的相互 连接和相互通信

B.2.5系统操作描述

该系统描述宜逐一说明每一项任务，且一般包括： 一为了执行每项任务而推荐采用的功能列表； 对每项任务，系统模块和组件提供这些功能的方式的说明。 描述任务实施的详细程度，以及细分为模块和组件的程度，宜仅考虑哪些是必须的，但需要充分说 明要求得到了满足

B.2.6系统实施合理性的声明

对于评估目的，系统实施的定义宜由相关合理性的声明来支持。 该声明宜逐一说明与系统使命有关的每一个特性（见5.2），提供更多关于系统实施的合理性及所要 求的系统特性的实现的信息。声明可包含： 在可选方案中选择该方案的理由； 支持数据（例如现场经验）、计算等； 支持测试报告。

B.2.7符合系统要求的声明

出的系统不能满足的每一个系统要求，并定义不

本附录给出了整理文件的例子

C.2锅炉控制文件示例

CB1和CB2为控制块的PID参数

CB2为控制块的PID参

C.2.2.1控制和/或算法

温度控制：OV1=function[MV1,SP1andCB1（parametersPID) 燃气控制：OV2=function[function（MV2，MV3)，SP2/OV1andCB2（parametersPID)] 燃气吞吐量：OV3=function（M2，M3）=constant［squareroot（MV2*MV3)］ 温度警报:OV4=1pourM1

C.2.2.2对使命的重要性

该任务对使命的重要性。

C.2.2.3系统边界

该系统宜包括所描述的任务完成所需的全部模块和组件。控制组件（控制阀）和传感器不在本

指示 MV1,MV2,MV3,SP1,SP2,OV(1...N) 记录 (短） ， 作为指示 (中) ： MV1,MV2,MV3,OV3 (长) ： MV1, OV3 报警 OV4 = MV1

允许操作人员操作的有： 控制设置：控制/仪表工程师 参数设定：控制/仪表工程师； 试运行：仪表工程师/技术员。

允许操作人员操作的有： 控制设置：控制/仪表工程师； 参数设定：控制/仪表工程师； 试运行：仪表工程师/技术员

宜在未来五年内可升级为具有以下功能的系统

C.2.8.2增强功解

增强OV3（function(MV2,MV3)）为： unction(MV2..5)=constant[squareroot(MV2*MV3*MV4/(MV5+variable))]

C.2.8.3添加控制功能

另一个新增的控制块是用来控 和输出值OVx的，它类似于C.2.2中描述的 0V2规定的功能块，并具有与C.2.8.2 相同的增强功能

C.2.8.4添加功解

添加以下逻辑功能： 一手动控制燃油和燃气的输出； 自动控制燃油和燃气的输出； 燃油自动控制，燃气由温度进行主从式控制； 燃油和燃气都是主从式的因此它可以设置燃油和燃气的比率

C.2.8.5添加外部连接

优化和管理信息系统之间的连接，包括数据采集

C.2.9.1覆盖范围

SRD覆盖范围分析见表C.1

表C.1SRD覆盖范围分析

C.2.9.2可配置性

SRD可配置性分析见表C.2

表C.2SRD可配置性分析

SRD灵活性分析见表C.3

SRD灵活性分析见表C.3

过程控制动作： 键盘操作的过程动作： 过程测量指示： 操作值的反馈：

表C.4所示为信息流性能表的例子

硬度标准表C.4信息流的性能

给出了信息翻译的性能表

C.4整理文件例子（来自主从控制任务的

理文件例子（来自主从控制任务的SRD中）

C.4提供了在SRD中主从控制任务可靠性要求描述的例子

图C.3提供了作为控制功能块任务的一个典型

可能状态的输入： 测量值1：高，正常，<低； 测量值2：>高，正常，<低； 设置点：>高，正常，<低。 可能状态的输出： 输出：全面开放，冻结，浮动，全面关闭。 表C.7提供了用简洁的方法来描述任务的边界状态的示例

路桥设计、计算表C.7输入和输出任务的故障状态