📚 课程目录第2章工业实时系统基础

2、工业实时系统基础：实时性定义、硬实时与软实时、工业控制中的时间约束

工业AI要真正落地到产线，必须理解其运行的“土壤”——工业实时系统。与办公IT系统追求“快”不同，工业实时系统追求的是“确定性”。本章将厘清实时性的本质定义，区分硬实时与软实时的工程边界，并剖析PLC扫描周期、任务执行窗口等核心时间约束，为后续设计AI推理延迟提供量化依据。

2.1 实时性的本质：不是“快”，而是“可预期”

在工业控制语境下，实时性（Real-Time）并不等同于“高速处理”。一个系统是实时的，意味着它能够在确定的时间界限内对外部事件做出响应，且这个时间界限是可证明、可验证的。换句话说，实时性的核心指标是响应时间的确定性（Determinism），而非吞吐量或平均延迟。

以PLC控制伺服电机为例：当编码器反馈位置偏差超过阈值时，PLC必须在下一个扫描周期内输出修正指令。如果系统平均响应时间为1ms，但最坏情况下需要50ms，那么这个系统就不是实时的——因为最坏情况无法满足运动控制对时间窗口的要求。工业实时系统设计的第一原则是：关注最坏情况执行时间（WCET, Worst-Case Execution Time），而非平均执行时间。

  关键概念：实时性 = 逻辑正确性 + 时间正确性。一个控制指令即使计算逻辑完全正确，如果到达执行器的时间超出了动作窗口，其效果等同于错误指令。在工业AI场景中，这意味着AI推理结果不仅要“算得对”，还要“来得及”。

2.2 硬实时与软实时：工程语义的严格分野

根据错过截止期（Deadline）的后果严重程度，实时系统分为硬实时和软实时两类。这种分类直接决定了系统架构、操作系统选型、通信协议和AI推理的部署策略。

对比维度	硬实时（Hard RT）	软实时（Soft RT）
截止期违反后果	灾难性：设备损坏、人身安全、产品报废	非灾难性：质量下降、效率降低、需要重试
典型应用	安全联锁、急停、伺服闭环、电力保护	视觉检测、AI预测、数据采集、报表
响应时间要求	微秒级~毫秒级，抖动极小（<1μs）	毫秒级~秒级，允许偶发超时
操作系统	RTOS（VxWorks、RT-Linux）、裸机	通用Linux、Windows + 实时补丁
验证方法	形式化证明、WCET分析、硬件在环测试	统计测试、压力测试、P95/P99延迟
AI部署策略	不直接部署AI，AI输出仅作参考	可部署AI模型，需控制推理延迟上界

需要特别指出的是，硬实时与软实时之间并非隔离。在实际产线中，一个AI视觉检测系统（软实时）的判定结果，可能会触发一个硬实时的安全动作（如不合格品剔除）。此时，AI系统的时间行为会间接影响硬实时链路的可用性。因此，工业AI设计者必须明确：AI推理处于软实时域，但其输出可能成为硬实时决策的输入，这种跨域耦合是延迟设计的核心难点。

2.3 工业控制中的核心时间约束：PLC扫描周期与动作窗口

PLC（可编程逻辑控制器）是工业控制的中枢，其运行机制基于循环扫描模型。理解扫描周期是设计AI推理延迟预算的前提。

2.3.1 PLC扫描周期的构成

一个完整的PLC扫描周期（Scan Cycle）通常包含以下阶段：

输入采样（Input Scan）：读取所有数字量/模拟量输入模块的状态，并存入输入映像区。
程序执行（Program Execution）：CPU逐条执行用户程序（梯形图、ST、FBD等），基于输入映像区计算输出。
输出刷新（Output Scan）：将输出映像区的值写入物理输出模块，驱动执行器。
系统服务（System Service）：通信处理、自诊断、系统时间更新等。

扫描周期的典型范围为1ms~100ms，取决于PLC型号、程序复杂度和I/O点数。对于运动控制或高速逻辑，扫描周期通常设定在1ms~4ms；对于过程控制（如温度、液位），扫描周期可放宽至50ms~100ms。

工程经验：PLC扫描周期不是固定不变的。程序分支、通信负载、中断处理都会导致扫描周期抖动。设计AI系统时，应使用最大扫描周期（而非平均扫描周期）作为时间预算基准。

2.3.2 动作窗口（Action Window）

动作窗口是指从事件发生到执行器必须完成动作的最大允许时间。它由物理过程决定，而非由控制器决定。例如：

安全急停：从按下急停按钮到伺服电机抱闸闭合，动作窗口通常为50ms~200ms（取决于安全标准）。
注塑机合模保护：从检测到异物到模具停止，动作窗口为30ms~80ms。
高速贴标机：从传感器检测到产品到位到贴标头下压，动作窗口为10ms~20ms。

动作窗口决定了控制链路中所有环节的延迟预算分配：传感器响应时间 + 输入滤波时间 + PLC扫描延迟 + 输出响应时间 + 执行器动作时间 ≤ 动作窗口。

2.4 案例拆解：AI视觉检测与PLC剔除的延迟协同

下面通过一个完整的案例，展示如何将AI推理延迟嵌入PLC扫描周期的时间约束中。

场景背景：某电池模组产线，需要在每个电芯表面贴装绝缘片后，通过AI视觉检测绝缘片是否歪斜（偏差>0.5mm即判不合格）。检测工位位于贴装工位之后2米处，传送带速度0.5m/s。检测到不合格品后，PLC控制一个气动剔除阀在检测工位下游1米处将电芯吹离产线。

时间约束计算：

传送带从检测工位到剔除阀的时间 = 1m ÷ 0.5m/s = 2000ms（这是动作窗口的上限）。
但实际动作窗口必须扣除安全余量，设定为1500ms。
气动阀响应时间（从PLC输出到阀完全打开）：30ms。
PLC输出刷新延迟（最坏情况）：1个扫描周期 = 10ms。
传感器检测到电芯到位信号延迟：5ms。

AI推理延迟预算：

动作窗口总预算：1500ms
减去固定开销：
  传感器延迟：5ms
  PLC扫描延迟：10ms
  气动阀响应：30ms
  安全余量（20%）：300ms
剩余可用于AI推理的延迟预算：1500 - 5 - 10 - 30 - 300 = 1155ms

实际部署：选用边缘AI盒子（GPU/NPU），运行轻量化YOLOv5s模型，输入图像分辨率640×640。实测推理延迟：平均85ms，P99延迟120ms。加上图像采集（曝光+传输）约40ms，总AI链路延迟约160ms，远小于1155ms预算。

结果与复盘：系统稳定运行，剔除准确率99.7%。但工程师发现，当产线提速至0.8m/s时，动作窗口缩短至937ms，AI链路延迟占比升至17%。此时需要优化模型（如TensorRT加速）或将AI推理移至PLC内部（若PLC支持AI加速模块）。这个案例说明：AI延迟设计必须与产线节拍联动，而非孤立优化模型精度。

2.5 常见误区与设计复盘

误区一：认为“实时性=高性能CPU”。实际上，工业实时性更依赖中断响应机制、任务调度策略和通信确定性。一颗1GHz的通用CPU跑Linux，其最坏响应时间可能不如一颗200MHz的MCU跑RTOS。AI推理硬件选型时，不能只看算力（TOPS），还要看I/O延迟和驱动栈的实时性。

误区二：忽略PLC扫描周期与AI异步交互的相位差。AI推理结果通过以太网或OPC UA异步写回PLC，PLC在下一个扫描周期才能读取。这意味着AI结果的有效性取决于“结果生成时刻”与“PLC读取时刻”之间的数据时效性。设计时应采用时间戳同步机制，确保AI输出的时间戳与PLC的扫描周期对齐。

误区三：将软实时系统的平均延迟当作设计依据。工业现场存在电磁干扰、网络拥塞、CPU缓存未命中、GPU频率波动等不可控因素。AI推理的P99或P99.9延迟才是设计基准。建议在产线实际环境（而非实验室）进行7×24小时延迟压测，统计最坏情况延迟。

设计复盘清单：

明确每个AI决策对应的动作窗口，并分解为传感器、通信、计算、执行四段延迟预算。
确认PLC扫描周期是否固定，若存在中断或通信任务，需测量最大扫描周期。
AI推理节点与PLC之间采用确定性通信（如EtherCAT、PROFINET IRT），避免使用TCP/IP的不可控重传。
为AI推理设置看门狗超时：若推理结果未在预算时间内返回，PLC应执行默认安全动作（如停机或放行）。
在产线提速或工艺变更时，重新验证时间预算，而非仅关注AI模型精度。