Y3.10.4Management of change for safety limits设计
边界值调整需要走变更管理而非随意修改
别名: 边界变更管理 · safety limit change
概念解释
调整一个边界值不是单纯改一个数字,而是同时改变了报警什么时候响、联锁什么时候动作、整个操作包络画在哪里,所以它应该走正式的变更管理（management of change）流程——记录技术依据、影响范围、授权人、测试结果和回退方案。它和调整界面上的字体大小或个人偏好设置完全不是同一个量级的操作,不能用同一套随意程度对待。
机制
同一个边界值往往不止存在于一个地方——界面上有一份,控制器逻辑里有一份,操作规程文档里也写了一份,如果只在界面上改了这个数字,而没有同步到控制器和规程,就会出现三处不一致：界面显示的极限和实际起作用的联锁逻辑对不上,操作者依据界面判断安全,联锁却按另一个数字动作,或者反过来。更深一层的问题是,边界值本身编码了这套系统的风险分级判断——挪动边界不只是挪动一条线,还隐含地改变了报警的响应时间窗口、操作者能容忍多大偏差、以及某个偏差应该被归入哪个严重程度,这些连锁影响如果不做评估就直接改数字,相当于在不知情的情况下重新定义了风险等级。
边界
不是所有界面上能调的参数都需要同等重量级的流程——纯粹的显示缩放范围（比如趋势图的Y轴上下限）只影响可读性,不改变任何真实的安全边界,不应该被塞进和真正的安全限值调整同一条审批流程里,那样会拖慢真正需要走流程的变更,也会让操作者对"变更管理"本身产生繁琐、多此一举的负面印象。另一方面,确属紧急情况下的临时调整,即便走了加急流程,事后也仍然需要补做正式的回顾评审,不能因为情况紧急就永久跳过评估这一步。
怎么落地
建立一份权威的边界值来源清单,标注每个边界值在界面、控制器逻辑、规程文档中分别存放的位置,以及它们之间的依赖关系。
- 任何调整前先做危害评估,再经过独立于提出变更者的第二人审核,在离线环境和现场分别测试后再上线,并保留可回退的旧版本;
- 临时性的应急调整必须带自动到期时间和醒目标识,不能因为一次异常处置顺利就悄悄变成事实上的永久配置;
- 验证办法：变更上线后,实际触发一次报警和一次联锁动作,核对触发点是否精确对应新边界值,而不是仅凭配置界面显示的数字就默认变更已经生效。