2. 产品需求冻结与配置基线

在工业边缘项目中，客户最初给出的往往不是“产品规格”，而是一段场景描述：某条产线要接入 12 台 PLC、3 台工业相机、1 套 MES 网关，要求本地推理延迟不超过 80 ms，现场温度最高 45 ℃，需要 7×24 小时运行，还要满足 CE 与 UL 认证。这些信息本身无法直接下采购单，也无法直接交给工厂生产。需求冻结与配置基线要做的，就是把这类场景语言翻译成可采购、可制造、可测试、可交付的工程规格，并在某一时间点把它“锁死”，后续任何改动都走变更控制。

从场景需求到工程规格的三层翻译

建议把翻译过程分成三层，逐层收敛，避免一次性跳到物料清单。

第一层：场景约束。记录客户现场的真实边界条件，包括环境温度、粉尘/油污等级、供电方式（220 VAC 或 24 VDC）、安装方式（导轨/壁挂）、振动情况、网络拓扑、现有协议（Profinet、EtherCAT、Modbus TCP、OPC UA）、停机窗口和维护方式。这一层不写具体型号，只写“必须满足什么”。

第二层：功能与性能规格。把场景约束转成可测量的指标。例如“本地推理延迟 ≤ 80 ms”要明确是端到端（相机曝光到结果输出）还是仅推理耗时；“7×24 运行”要转成 MTBF 目标与散热方案；“接入 12 台 PLC”要转成具体协议数量、轮询周期和并发连接数。这一层是后续选型和测试的依据。

第三层：配置项与物料。把规格落到 CPU 型号、内存容量、存储介质、网口数量与速率、PoE 供电、扩展槽、操作系统版本、驱动版本、AI 推理框架版本、认证证书编号。到这一层，才形成真正可下单的配置基线。

配置基线的构成与冻结时机

一条可量产的配置基线，至少应包含四类信息：硬件配置、软件版本、认证要求、测试与验收判据。它们不是并列的四张表，而是相互约束的一个整体。

硬件配置要精确到可采购粒度，例如：CPU 为 Intel Core i5-1350PE、内存 16 GB DDR5、存储 256 GB NVMe、4 个 2.5 GbE 网口（其中 2 个支持 PoE+）、工作温度 -20～60 ℃、无风扇被动散热。软件版本要锁定到具体版本号，而不是“最新版”，例如 Ubuntu 22.04 LTS、Intel oneAPI 2024.1、OpenVINO 2024.2、Docker 26.1。认证要求要写明目标市场与标准，例如 CE（EN 61000-6-2/6-4）、UL 62368-1、FCC Part 15 Class A。测试判据要可执行，例如“满载推理 72 小时无降频、无丢包、无重启”。

冻结时机通常选在样机验证通过、小批量试产之前。此时硬件选型已确认可采购，软件版本已通过兼容性测试，认证预测试已无重大不符合项。冻结后形成基线版本号，例如 BL-2024Q3-V1.0，所有后续生产、测试、交付都以该版本为准。

变更控制：让基线“可动但可控”

基线冻结之后，客户仍可能提出新需求，例如增加一台相机、更换 AI 模型、要求补充 CCC 认证。此时不能直接改物料，而要按变更控制流程处理。一个可落地的做法是建立变更影响矩阵，把变更请求映射到三层规格，逐层评估。

以“相机从 3 台增加到 4 台”为例。第一层场景约束变化：相机数量 +1。第二层性能规格受影响：GigE 带宽增加约 33%，若单台相机 1080p@30fps 约占用 200 Mbps，则总带宽从 600 Mbps 升至 800 Mbps，仍在 2.5 GbE 网口余量内；但推理负载增加，需重新评估端到端延迟是否仍 ≤ 80 ms。第三层配置项可能不变，也可能需要把 OpenVINO 模型从 FP32 量化为 INT8 以保住延迟指标。评估结论写入变更单，若通过则发布基线 V1.1，若未通过则反馈客户调整需求或追加预算。

变更控制还要明确“谁有权批准”。建议按影响范围分级：仅涉及软件补丁版本、不影响接口与认证的，由项目工程师批准；涉及硬件物料、认证范围、交付周期的，由项目经理与客户共同批准；涉及安全功能或目标市场准入的，必须重新走认证评估。每次变更都要记录变更前后差异、影响分析、验证结果和生效基线版本，形成可追溯的配置管理记录。

可执行的基线冻结检查清单

在宣布基线冻结前，建议逐项核对以下内容，避免把未收敛的问题带入量产。

把客户场景需求转化为可量产规格，本质上是把模糊的“能用”变成可验证的“合格”。三层翻译负责收敛，基线冻结负责锁定，变更控制负责让后续改动有据可查。三者合在一起，才能让工业边缘产品从样机走向稳定量产。