2. 工业数字孪生系统集成的需求分析与对象建模

在上一节中我们已经明确，工业数字孪生系统集成不是把若干软件堆叠在一起，而是围绕真实工业对象建立可计算、可追溯、可演进的数字映射。进入实施阶段后，第一个真正决定成败的动作不是选平台，而是把“要集成的对象”说清楚。需求分析与对象建模，本质上就是回答四个问题：物理世界里有什么、工艺过程怎么走、数据从哪里来又流向哪里、业务上到底要解决什么问题。这四个问题回答得越具体，后续的接口设计、数据建模和系统边界划分就越不容易返工。

一、从物理实体出发，而不是从软件功能出发

很多集成项目一开始就讨论“要不要上 MES”“要不要接 SCADA”，这是从软件出发的思维。正确的起点是物理实体清单。以一条典型的离散制造装配线为例，物理实体至少包括：上料工位的振动盘与料仓、装配工位的六轴机器人、拧紧工位的伺服拧紧轴、检测工位的视觉相机、下料工位的输送带，以及为它们供电供气的配电柜与气源处理单元。每个实体需要记录的不是名称，而是可集成的属性：唯一标识（如 AST-LINE01-ST03-RB01）、所属工位、关键参数（机器人重复定位精度 ±0.02 mm、拧紧轴额定扭矩 12 N·m）、通信能力（是否支持 OPC UA、Modbus TCP 或仅提供干接点）以及可采集的信号点。

这一步的产出通常是一张物理实体—信号点对照表。例如拧紧轴需要采集“目标扭矩、实际扭矩、角度、拧紧结果 OK/NOK、程序号”五个信号，其中前三个是过程量，后两个是状态量。把信号点写清楚，后面才知道哪些数据要进孪生模型、哪些只做报警。

二、工艺过程建模：把动作序列变成可计算的状态链

物理实体是静态的，工艺过程是动态的。工艺过程建模的目标是把“人看得懂的操作顺序”翻译成“系统能判断的状态迁移”。仍以装配线为例，一个工位的完整循环可以抽象为：等待来料 → 定位夹紧 → 机器人取件 → 拧紧执行 → 视觉检测 → 结果判定 → 放行/剔除。每个状态都要绑定三个要素：进入条件、持续信号、退出条件。

以拧紧为例，进入条件是“夹紧到位信号 = 1 且程序号已下发”，持续信号是“实际扭矩随角度上升”，退出条件是“实际扭矩达到目标值 ±5% 或超时 3 s”。这样建模之后，孪生体就能在虚拟侧复现真实节拍，并在扭矩曲线异常时提前给出偏差提示，而不是等成品检测才发现问题。

三、数据流梳理：分清控制流、状态流与业务流

工业现场的数据不是一条流，而是三条并行的流。控制流是 PLC 与设备之间的实时指令，周期通常在 1～10 ms，要求确定性；状态流是设备向 SCADA/边缘网关上报的运行状态，周期在 100 ms～1 s；业务流是工单、物料批次、质量结果向 MES/ERP 的传递，属于事件驱动，秒级甚至分钟级即可。三条流的时间尺度不同，集成方式也必须不同：控制流走现场总线，状态流走 OPC UA 或 MQTT，业务流走 REST/消息队列。

如果把它们混在一条通道里，就会出现“为了传工单把实时控制周期拖慢”的典型故障。因此需求分析阶段必须为每条流标注：数据源、目标系统、协议、周期、数据量级、是否允许丢失。下面这张图把本节的核心对象关系集中呈现出来，可作为建模讨论时的对照底图。

四、业务目标与系统边界：把“不做什么”写清楚

业务目标是需求的最终裁判。它必须可度量，例如“装配线节拍达成率 ≥ 98%”“每颗螺栓的拧紧扭矩可追溯到工单与批次”“拧紧异常在发生前 3 s 给出预警”。这些目标决定了孪生体需要多高的数据保真度：如果只做节拍统计，状态流 1 s 一次足够；如果要做扭矩曲线预警，就必须采集拧紧过程的完整曲线，采样率可能要到 100 Hz 以上。

系统边界定义则是需求分析中最容易被忽略、却最容易引发争议的部分。边界要明确三件事：纳入范围（本线体、本线 PLC、边缘网关、孪生模型服务）、排除范围（厂级 ERP、其他产线、供应商云端）、接口责任（谁提供数据、谁负责协议转换、谁保证时间同步）。例如可以约定：边缘网关负责将 Modbus TCP 转为 MQTT 并打上 UTC 时间戳，孪生平台只消费 MQTT 主题，不直接访问 PLC。这样边界清晰，后续任何一方变更都不会牵动全局。

五、集成需求规格说明的落地形式

把上述内容整理成一份可评审的集成需求规格说明（IRS），建议至少包含以下字段，每条需求一行，便于逐条验证：

六、常见偏差与判断依据

在对象建模阶段，最常见的三类偏差是：信号点漏采（例如只采了拧紧结果，没采角度曲线，导致无法做过程预警）、时间基准不统一（PLC 本地时钟与网关 UTC 相差数秒，曲线对不齐）、边界蔓延（原本只做本线孪生，后来不断接入其他系统，导致接口责任不清）。判断是否建模到位，可以用一个简单标准：拿一份真实工单，能否在孪生体里完整复现这颗螺栓从取件到放行的全过程，并且每个状态都能对应到具体信号和时间戳。 如果能，说明物理实体、工艺状态、数据流和业务目标已经对齐；如果不能，缺的那一环就是下一步要补的需求。

需求分析与对象建模的产出，最终会直接决定系统集成的接口清单、数据模型和验收标准。把对象说清楚、把边界划清楚、把目标写清楚，后面的平台选型和接口开发才有稳定的依据。