📚 课程目录第3章数字孪生工程需求分析

3. 数字孪生工程需求分析

需求分析是输送分拣产线数字孪生工程从“想法”走向“可实施”的第一道关口。它要回答的不是“用什么引擎、建多细的模型”，而是“这条产线为什么要做数字孪生、做到什么程度算成功、谁说了算、哪些约束不可突破”。如果需求分析缺位，项目极易演变为“模型很漂亮、现场不认账”的演示系统。本节围绕业务目标、KPI体系、三类关键约束、干系人访谈和需求规格说明书五个抓手展开，并给出可直接套用的工作方法。

一、从业务目标出发，而不是从模型出发

输送分拣产线的数字孪生通常服务于四类业务目标：产能与效率提升（如提升分拣效率、降低堵包率）、运行可靠性保障（如预测关键设备故障、缩短非计划停机）、运营决策支持（如验证新订单结构下的分拣策略）、培训与验证（如新员工操作培训、控制逻辑上线前验证）。业务目标必须写成可被验证的句子，例如“在现有订单结构下，将交叉带分拣机的堵包停机时间从每月 6 小时降到 3 小时以内”，而不是“提升智能化水平”。

目标确定后，要把它翻译成数字孪生能承接的能力。例如“降低堵包停机”对应孪生体需要具备：包裹流实时映射、关键输送段拥堵预警、分拣策略仿真对比三项能力。这一步是后续所有约束和 KPI 的来源。

二、KPI 体系：分层设计，可观测、可归因

KPI 不能只写一个“综合效率”，而应分层：业务层（分拣效率、单位包裹能耗、非计划停机时长）、系统层（孪生体数据延迟、模型更新频率、仿真与实测偏差）、工程层（模型覆盖率、接口可用率、告警准确率）。每项 KPI 都要明确“基线值—目标值—测量方式—数据来源”。

层级	KPI 示例	基线（示例）	目标（示例）	测量方式
业务层	分拣效率	7200 件/小时	≥ 8000 件/小时	WCS 统计报表
业务层	堵包停机时长	6 小时/月	≤ 3 小时/月	设备停机日志
系统层	孪生体数据延迟	—	≤ 500 ms	时间戳比对
系统层	仿真与实测偏差	—	≤ 8%	同工况对比
工程层	关键设备模型覆盖率	—	≥ 90%	模型清单核对

表中数值为教学示例，实际项目须以现场基线测量为准。KPI 一旦确定，就应作为验收依据写入需求规格说明书，避免后期“各说各话”。

三、实时性、精度、覆盖范围三类约束

这三类约束相互制约，是需求分析中最需要“谈清楚”的部分。

实时性：指从现场信号产生到孪生体状态更新完成的时间。分拣机运行状态、包裹位置这类高频信号通常要求 ≤ 500 ms；设备健康趋势、能耗统计可放宽到分钟级。实时性直接决定通信协议（OPC UA、MQTT）、采集频率和边缘计算部署方式。
精度：包含几何精度与行为精度。几何精度决定模型能否用于干涉检查（如输送线间距、转弯半径）；行为精度决定仿真结果是否可信（如分拣小车加速度、包裹滑移）。精度不是越高越好，要与业务目标匹配，否则会造成算力与成本浪费。
覆盖范围：指孪生体覆盖的设备、工位、数据源和业务环节。是覆盖整条分拣主线，还是只覆盖易堵的合流段？是只接 PLC 数据，还是同时接入 WMS、WCS、视频与传感器？覆盖范围直接决定项目工作量和投资规模。

建议用“约束三角”方式与干系人确认：实时性提高往往要求更高采集频率和更强算力；精度提高会增加建模与标定工作量；覆盖范围扩大则三者同时上升。需求分析阶段就要明确哪些指标是硬约束、哪些可折中。

四、干系人访谈：把隐性需求挖出来

数字孪生的干系人通常包括：产线运营主管、设备维护工程师、WCS/WMS 软件工程师、电气与控制工程师、IT/网络管理员、安全与合规负责人、项目投资方。不同角色的关注点差异很大：运营主管关心分拣效率和堵包；维护工程师关心故障预警和备件；软件工程师关心接口和数据格式；IT 关心网络隔离与数据安全。

访谈建议采用半结构化方式，围绕“现状痛点—期望变化—判断标准—约束条件”四问展开，并形成访谈记录表。例如询问维护工程师：“目前交叉带分拣机最常见的故障是什么？您希望在故障发生前多久收到预警？预警以什么形式呈现？”这类问题能直接转化为功能需求和非功能需求。

五、需求规格说明书编写：可追溯、可验收

需求规格说明书（SRS）是需求分析的最终交付物。它不应是访谈记录的堆砌，而应结构化、可追溯、可验收。建议包含以下部分：

项目背景与业务目标：说明产线现状、痛点、孪生体要达成的业务结果。
范围界定：明确覆盖的设备、工位、数据源和业务环节，以及明确不做的部分。
功能需求：如“实时映射分拣主线包裹流”“拥堵预警”“分拣策略仿真对比”，每条需求编号并给出验收标准。
非功能需求：实时性、精度、覆盖范围、可用性、安全性、可维护性。
接口与数据需求：与 PLC、WCS、WMS、视频系统的接口协议、数据格式、频率。
约束与假设：网络条件、算力资源、现场改造限制、数据可得性。
KPI 与验收标准：与第二节 KPI 体系对应，明确测量方法和判定阈值。
变更管理：需求变更的提出、评估、审批和追溯流程。

编写时建议采用“需求条目 + 来源 + 验收标准”的三元组格式。例如：

需求编号：FR-003
需求名称：合流段拥堵预警
需求描述：当合流段包裹密度超过设定阈值时，孪生体应在 2 秒内
          输出预警，并在三维视图中高亮该区段。
来源：运营主管访谈记录 2024-XX-XX
验收标准：在测试工况下连续运行 8 小时，预警漏报率 ≤ 5%，
          误报率 ≤ 10%，预警延迟 ≤ 2 秒。
优先级：高

常见误区：把“实时性”写成“越快越好”，把“精度”写成“越精细越好”，把“覆盖范围”写成“全部都要”。这三类约束必须量化并与业务目标挂钩，否则项目边界无法收敛，验收时必然产生争议。

需求分析完成后，应组织一次干系人评审，逐条确认需求条目、KPI 和验收标准，形成签字版 SRS。这份文件将作为后续建模、接口开发、系统集成和项目验收的共同基准，也是数字孪生工程能否真正落地、被现场接受的关键依据。