3. 复杂设备控制需求建模

复杂设备控制软件的失败，很少是“代码写错了”，更多是“需求没被正确翻译成架构”。设备工艺描述的是物理过程，动作序列描述的是执行顺序，安全约束描述的是不可逾越的边界，产能目标描述的是时间与节拍。这四类信息如果只停留在工艺文档或口头描述中，软件架构就会在后期被反复推翻。本节的核心任务，是把这四类输入转化为可落地的软件架构需求。

一、四类输入的本质差异

设备工艺回答“这台设备靠什么原理完成加工”，例如热压、灌装、分拣、绕线。它决定了必须采集哪些物理量、必须控制哪些执行器，以及哪些过程量之间存在耦合。动作序列回答“设备按什么顺序动作”，它决定了状态机的层级、步与步之间的转移条件，以及哪些动作可以并行。安全约束回答“什么情况下必须停、必须锁、必须限速”，它决定了安全逻辑是否独立于普通控制逻辑、是否需要独立的安全PLC或安全模块。产能目标回答“每小时做多少件、单件节拍多少毫秒”，它决定了控制周期、任务优先级、通信刷新率和运动规划方式。

这四类输入不是并列关系，而是约束关系：工艺决定动作的物理可行性，动作序列决定状态迁移，安全约束对动作序列施加禁止条件，产能目标对整条链路施加时间预算。软件架构需求正是从这些约束的交集中提取出来的。

二、从工艺到过程映像

以一台典型的热压封装设备为例。工艺要求是：工件送入后加热至设定温度并保温，然后加压，保压一段时间后冷却，最后出料。这里首先提取出的架构需求是过程映像：温度、压力、位置、时间四类物理量必须映射为PLC变量，并明确量程、单位、采样周期和滤波方式。例如温度传感器4–20 mA对应0–300 ℃，采样周期100 ms，一阶滤波时间常数500 ms；压力传感器0–10 V对应0–16 MPa，采样周期50 ms。这些参数不是“配置细节”，而是架构需求的一部分，因为它们决定了过程数据任务的周期和I/O模块的选型。

工艺还决定了耦合关系：温度与压力不能同时无限制上升，否则可能损坏工件。这种耦合关系在软件架构中应体现为过程监控层的约束检查，而不是散落在各个动作步中。

三、从动作序列到状态机层级

动作序列通常可以整理为“主状态 + 子步”的两级结构。主状态包括：待机、回零、自动运行、暂停、报警、维护。自动运行下再细分：送料、加热、加压、保压、冷却、出料。每个子步必须明确进入条件、执行动作、完成条件和超时时间。例如“加热”子步的完成条件是温度进入设定值±2 ℃并稳定200 ms，超时时间为30 s；超时后进入报警状态并触发“加热超时”故障码。

这里提取出的架构需求是：状态机必须支持层级嵌套、超时监控和故障分支。如果动作序列中存在并行分支，例如“加热”与“送料”可同时进行，则状态机还需要支持并行区域，或者由多个独立任务协同完成。这直接决定了软件架构中状态机引擎的设计方式。

四、从安全约束到安全分区

安全约束必须与普通控制逻辑分离。典型的安全约束包括：急停按钮按下后所有运动轴在200 ms内进入安全扭矩关断（STO）；安全门打开时禁止加压和加热；光幕遮挡时禁止送料机构运动。这些约束的响应时间、诊断覆盖率和实现方式（安全PLC、安全继电器、驱动内置安全功能）必须在架构需求中明确。

在TwinCAT架构中，通常将安全逻辑放在独立的安全任务中，通过FSoE（Fail-Safe over EtherCAT）与安全I/O通信，普通控制任务通过标准EtherCAT与安全任务交换状态信息。安全任务周期通常为4–10 ms，独立于普通控制周期。架构需求应写明：安全功能响应时间≤200 ms，安全任务周期≤10 ms，安全与非安全数据交换必须通过明确的接口变量，禁止直接访问。

五、从产能目标到任务与通信预算

产能目标通常以“件/小时”或“秒/件”给出。假设目标为900件/小时，则单件节拍为4 s。将4 s分解到各子步：送料0.8 s、加热1.2 s、加压0.5 s、保压1.0 s、冷却0.3 s、出料0.2 s，合计4.0 s。这个分解结果直接决定了控制任务的周期预算：运动控制任务周期应≤1 ms，过程控制任务周期≤50 ms，HMI刷新周期≤200 ms。

通信预算同样重要。如果采用EtherCAT，总线周期应≤1 ms，抖动≤100 μs；如果采用Modbus TCP与上位机通信，刷新率可能只有50–100 ms，不能用于安全或高动态控制。架构需求应明确：哪些数据走实时总线，哪些数据走非实时通道，以及数据一致性如何保证。

六、冲突消解与需求冻结

四类输入之间必然存在冲突。例如产能要求节拍3.5 s，但安全约束要求急停后200 ms内停止，而当前驱动配置的减速时间需要300 ms。此时不能简单“折中”，而应优先满足安全约束，通过更换驱动、增加制动电阻或降低节拍来解决。架构需求文档中应记录冲突项、取舍依据和最终决策，作为后续设计和验证的基线。

需求冻结不是“不再修改”，而是“修改必须走变更流程”。在TwinCAT项目中，可以将这些架构需求映射为具体的任务配置、I/O映射表、状态机接口和安全接口定义，使需求与代码结构保持可追溯。这样，当工艺或产能目标变化时，能够快速判断影响范围，而不是重新推翻整个架构。