3. 改造需求定义与范围界定

在能源化工装置的自动化改造中，最容易被低估、却最容易导致项目返工的环节，不是选型，也不是组态，而是需求定义与范围界定。很多改造项目在开工后才发现：DCS 点数不够、SIS 安全等级定低了、老阀门定位器不支持 HART、历史数据无法满足先进控制建模要求。这些问题的根源，往往不是技术能力不足，而是需求没有被翻译成可执行、可验证、可验收的技术规格。

本节要解决的核心问题是：如何把工艺目标、产能瓶颈、安全合规和投资回报这四类"业务语言"，逐层转化为自动化专业可以直接落地的"技术语言"——即 I/O 清单、控制回路清单、安全完整性等级、通信接口、性能指标和验收判据。

一、四类需求来源及其转化逻辑

改造需求通常来自四个方向，它们的语言不同、优先级不同，但最终都要收敛到同一套技术规格上。

工艺目标回答"装置要变成什么样"。例如：某常减压装置希望将常压塔顶石脑油干点波动从 ±8℃ 收窄到 ±4℃，以提高高附加值产品收率。这句话本身不是技术规格，需要翻译为：关键被控变量（塔顶温度、回流比、塔压）的测量精度要求、控制回路数量、控制周期、是否需要引入前馈或软测量。工艺目标通常决定控制性能指标。

产能瓶颈回答"哪里卡住了"。例如：某加氢裂化装置反应进料泵为定速泵，靠出口调节阀节流控制流量，高负荷时阀门长期开度 85% 以上，调节余量不足，成为提负荷瓶颈。这一条要翻译为：是否需要变频改造、调节阀流通能力 Cv 值核算、泵特性曲线与管路特性交点、以及改造后流量控制回路的响应时间要求。产能瓶颈通常决定执行机构与设备级改造范围。

安全合规回答"哪些是必须做的"。例如：依据 GB/T 21109 与装置 HAZOP 结论，某反应器存在超压风险，要求独立于 BPCS 设置安全仪表功能，目标 SIL 等级为 SIL 2。这一条要翻译为：SIS 逻辑 solver 选型、传感器冗余结构（1oo2 或 2oo3）、最终元件（切断阀）的 PFDavg 要求、SIL 验证计算与定期测试周期。安全合规通常决定系统架构与不可妥协的边界。

投资回报回答"值不值得做、做到什么程度"。例如：改造预算 800 万元，要求投资回收期不超过 3 年。这一条要翻译为：改造范围的分期划分、哪些回路优先上先进控制、哪些仅做基础控制升级、以及效益测算的基准（收率提升、能耗下降、非计划停车减少）。投资回报通常决定范围取舍与实施优先级。

二、从需求到规格的关键翻译动作

上图展示了四类需求向技术规格收敛的整体关系。真正落地时，需要完成几个关键翻译动作。

第一，把工艺目标翻译为控制性能指标。以塔顶干点控制为例，干点波动要从 ±8℃ 收窄到 ±4℃，意味着塔顶温度控制回路的稳态误差和超调量都要相应收紧。若原回路为单回路 PID，测量滞后约 8 分钟，仅靠整定参数难以达标，就需要引入进料温度前馈或塔压补偿。技术规格中应写明：控制周期 ≤1s、温度变送器精度 ±0.2℃、前馈通道数量、以及投用后 72 小时温度标准偏差 ≤1.2℃ 的验收指标。

第二，把产能瓶颈翻译为设备级改造范围。前述进料泵调节阀开度长期 85% 以上，需要核算两个量：一是阀门实际 Cv 与所需 Cv 的比值，若可调比不足，则考虑扩大阀芯或改变频；二是泵的扬程-流量曲线与管路特性曲线的交点，判断变频后能否覆盖 60%~110% 负荷区间。技术规格中应写明：变频器容量、调速范围、最低频率限制、以及流量控制回路的阶跃响应时间（如 ≤30s 达到设定值 90%）。

第三，把安全合规翻译为不可妥协的架构边界。HAZOP 给出 SIL 2 要求后，技术规格必须明确：SIS 与 BPCS 独立、传感器冗余结构（如 2oo3）、最终元件冗余方式（如 1oo2）、PFDavg 目标值、以及定期功能测试周期。这些内容一旦确定，就不再是"可选项"，而是改造范围的硬边界。任何为节省投资而削减 SIS 冗余的做法，都必须在 SIL 验证中重新核算，不能凭经验拍板。

第四，把投资回报翻译为范围取舍与分期。预算和回收期决定了哪些回路先做、哪些后做。通常优先改造"高效益、低风险、短周期"的回路，例如关键产品质量控制、高能耗机组优化；而涉及大范围管道动改、停车窗口长的内容，可放入二期。技术规格中应给出分期清单和每期的效益测算基准，避免后期因范围蔓延导致投资失控。

三、范围界定中的常见边界问题

范围界定最容易出问题的地方，往往不是"要做什么"，而是"不做什么"没有写清楚。以下几类边界必须在规格中明确：

• 与既有系统的接口边界：新 DCS 与老 DCS 是并行运行还是整体替换？老系统哪些信号需要保留、哪些需要迁移？迁移期间如何保证装置不停车？
• 与第三方设备的通信边界：机组控制系统、包装线、罐区计量系统是否纳入本次改造？若纳入，通信协议、数据点表、责任分界在哪里？
• 与电气、仪表专业的施工边界：电缆桥架、接线箱、气源管路由谁负责？改造期间哪些区域需要停车、哪些可以在线施工？
• 与安全管理的边界：SIS 改造是否需要重新进行 HAZOP 和 SIL 验证？改造后的联锁逻辑由谁审批、谁测试、谁签字？

四、需求规格的可验证性

技术规格写得好不好，一个简单判据是：每一条需求是否都能被测试或验证。例如"提高控制品质"无法验证，而"塔顶温度控制偏差 ≤±1.5℃、连续 72 小时标准偏差 ≤1.2℃"可以验证；"保证安全"无法验证，而"SIL 2 回路 PFDavg ≤1.0×10⁻³、功能测试周期 12 个月"可以验证。

在需求定义阶段，建议同步建立需求追溯矩阵：每一类需求（工艺、产能、安全、投资）对应到具体技术规格条目，再对应到验收测试方法。这样在项目后期出现争议时，可以快速回溯"这条规格是从哪条需求来的、当初为什么这么定"。

需求定义与范围界定的最终成果，不是一份漂亮的报告，而是一套可执行、可验证、可追溯的技术规格。它向上承接工艺目标和安全要求，向下约束详细设计、采购、施工和验收。只有把这一步做扎实，后续的 DCS 组态、SIS 验证、先进控制投用才有稳定的基础，改造项目才能真正从"业务需求"走到"工程落地"。