2. 数字孪生模型的需求分析与规格定义

数字孪生模型不是“把物理对象三维化”这么简单。它本质上是一个面向特定业务目标的、可计算、可交互、可演化的信息模型。因此，在建模之前，必须先回答三个问题：为谁建、用来做什么、需要多准多快。需求分析与规格定义，就是把这三个问题从模糊的期望转化为可验证、可追踪的工程约束。如果跳过这一步，后续的模型往往会出现“精度过剩但响应太慢”“数据字段缺失导致无法计算”“交付后无人使用”等典型问题。

从三类来源提取需求

需求来源通常有三类：物理实体、业务目标和利益相关者。物理实体决定了模型必须表达哪些结构、材料、运动关系和物理场；业务目标决定了模型要支持哪些决策，例如预测性维护、能耗优化、产能调度或远程运维；利益相关者则决定了模型的交付形态、交互方式和精度容忍度。例如，设备工程师关心振动频谱与轴承温度趋势，生产调度员关心节拍与在制品状态，而管理层关心OEE与停机损失。同一台设备，面向不同角色的孪生模型，其需求规格可能完全不同。

提取需求时，建议采用“场景—问题—指标—数据”的链条。以一个示例场景说明：某注塑车间希望降低非计划停机。由此拆解出的功能需求包括：实时监测锁模力、熔体温度、螺杆转速；性能需求包括：数据刷新周期不超过1秒，异常预警延迟不超过5秒，模型仿真步长不大于10毫秒；数据需求包括：每台注塑机至少采集12路工艺信号，历史数据保留180天，时间戳对齐误差小于50毫秒。这些参数是示例性假设，实际项目中需根据设备手册、工艺窗口和IT/OT能力协商确定。

功能需求、性能需求与数据需求

功能需求描述模型“能做什么”，通常用动词短语表达，例如“支持设备状态实时映射”“支持故障模式识别”“支持工艺参数反向优化”。功能需求应避免笼统，最好绑定到具体业务动作。例如，“支持故障模式识别”应进一步细化为“当锁模力偏差超过设定值±8%且持续3个周期时，输出液压系统异常候选”。

性能需求描述模型“做得多好”，包括精度、实时性、吞吐量、可用性和资源占用。精度又可分为物理精度（如温度场误差≤2℃）、统计精度（如预测准确率≥92%）和几何精度（如装配间隙误差≤0.5mm）。实时性需区分数据采集周期、模型计算周期和界面刷新周期，三者不必相同，但必须满足业务闭环的时序约束。

数据需求描述模型“吃什么”，包括数据源、字段、频率、格式、质量约束和生命周期。常见字段如设备ID、时间戳、工艺参数、环境参数、质量检测结果、维护记录。数据需求必须明确缺失值处理策略、单位统一规则和时钟同步方式，否则后续模型会出现“数据对不齐、算不准”的问题。

编写模型规格说明书

模型规格说明书是需求分析的正式交付物，建议包含以下结构：范围与目标、利益相关者与使用场景、功能需求清单、性能需求清单、数据需求清单、假设与约束、验收标准、变更记录。每条需求应有唯一编号，例如FR-001、PR-003、DR-007，便于追踪。验收标准要可测量，例如“在连续72小时运行中，模型可用率≥99.5%，预警漏报率≤3%”。

规格说明书不是一次性文档。随着物理实体改造、业务目标调整或数据源变化，需求会演化。因此需要建立变更控制机制，记录每次变更的原因、影响范围和验证结果。

需求追踪矩阵与可追溯性

需求追踪矩阵（RTM）是确保可追溯性的核心工具。它把需求与设计、实现、测试用例、验收结果关联起来，形成双向追踪。正向追踪回答“这条需求由谁实现、怎么验证”；反向追踪回答“这个模块为什么存在、对应哪条需求”。当需求变更时，RTM能快速定位受影响的模型组件和测试用例，避免遗漏。

一个简化的RTM示例如下：

RTM的价值在于“可验证”。没有测试用例的需求是空话，没有需求来源的测试是浪费。通过矩阵，团队可以在评审时快速发现：哪些需求没有实现、哪些模块没有需求支撑、哪些测试没有覆盖关键指标。

从需求到规格的实操要点

在实际项目中，需求分析往往不是一次会议就能完成。建议采用迭代方式：第一轮快速识别利益相关者和核心场景，形成需求草案；第二轮针对每条需求补充量化指标和数据字段；第三轮与IT、OT、工艺、运维多方评审，确认可行性和优先级。评审时重点关注三类冲突：精度与实时性的冲突、数据可得性与模型需求的冲突、业务目标与现有系统能力的冲突。

规格说明书中还应明确“不做什么”。例如，本阶段模型不包含刀具磨损的微观机理仿真，只做基于统计特征的剩余寿命预测。明确边界可以防止范围蔓延，也能让验收标准更清晰。

需求分析与规格定义的质量，直接决定数字孪生模型能否真正支撑业务闭环。一个可追溯、可验证、可变更的需求体系，是模型生命周期管理的起点，也是后续设计、开发、部署和运维的共同基准。