2. 自动化实验系统架构与异常面
自动化实验系统并不是“一台仪器加一段脚本”的简单组合,而是一个由多层模块协同工作的闭环系统。要谈异常恢复,第一步不是急着写重试逻辑,而是先把系统拆开,看清每一层负责什么、层与层之间靠什么交互、异常会从哪里冒出来、又会沿着哪条路径扩散。只有把“异常面”画清楚,恢复策略才有落点。
从工程视角看,一个典型的自动化实验系统可以划分为五个核心模块:实验编排层、设备控制层、数据采集层、样本管理层和计算调度层。它们不是并列的五个盒子,而是存在明确的依赖与数据流方向:编排层下发实验任务,设备控制层驱动硬件执行,数据采集层从设备与传感器获取原始信号,样本管理层跟踪物理样本的位置与状态,计算调度层则对采集结果进行分析、建模并反馈决策。异常一旦在某层发生,往往会顺着这条链路向上或向下传播。
上图展示了五层模块之间的正常数据流与异常传播路径。可以看到,异常并不是孤立事件:设备控制层的通信超时,会导致数据采集层拿不到有效信号,进而使计算调度层缺少输入,最终编排层收到一个“任务失败”但原因不明的结果。如果系统没有在每一层设置明确的异常边界和恢复点,故障就会被层层放大,变成难以定位的“黑盒问题”。
各层异常类型与典型触发条件
要建立异常恢复能力,必须先把每层的异常类型说清楚。下面按模块逐一拆解,并给出可观察的触发条件与判断依据。
实验编排层的异常主要集中在任务调度与状态管理上。常见类型包括:任务超时(某一步骤超过预设的最大执行时间,例如“加热至80℃”设定超时阈值为600秒,实际等待超过600秒仍未达到目标温度);分支条件误判(基于上一步返回值选择路径时,返回值格式或范围不符合预期,导致走错分支);资源冲突(两个实验任务同时申请同一台设备或同一个样本位);状态机死锁(任务在“等待设备就绪”和“等待样本到位”之间循环等待)。这些异常的判断依据通常来自编排日志中的状态迁移记录和时间戳差值。
设备控制层的异常更贴近硬件与通信。典型包括:通信超时(向PLC或运动控制器发送指令后,在设定时间内未收到应答,例如Modbus TCP超时设为2000ms);指令拒绝(设备返回错误码,如“轴未使能”“温度未达到安全范围”);执行偏差(指令要求移动到位置A,但编码器反馈位置与目标位置偏差超过允许公差,例如±0.05mm);安全联锁触发(急停、限位、过温保护等硬件信号被激活)。这一层的异常往往有明确的错误码和硬件状态字,是恢复策略中最容易做“条件判断”的一层。
数据采集层的异常表现为数据质量与完整性问题。采样丢帧(在固定采样周期下,连续两个数据点的时间间隔超过理论周期的1.5倍);时间戳漂移(采集卡时钟与系统时钟不同步,导致后续计算无法对齐多通道数据);量程溢出(传感器输出超过AD转换量程,例如4-20mA信号对应0-100℃,但实际电流达到22mA);缓存写失败(磁盘满、权限不足或文件被占用)。这一层的异常如果未被及时发现,会直接污染计算结果,且往往在事后分析时才暴露。
样本管理层的异常涉及物理对象与信息记录的对应关系。样本错位(机械臂抓取位置与样本实际位置偏差,导致抓空或碰撞);识别失败(条码磨损、RFID读取距离不足或标签损坏);温控失效(存储模块温度超出允许范围,例如要求2-8℃但实际升至12℃);样本耗尽(计划使用96孔板,但实际可用孔位不足);记录不一致(数据库记录样本在A位,但物理位置在B位)。样本层的异常具有“不可逆”风险,一旦样本损坏或污染,恢复策略必须优先考虑止损而非重试。
计算调度层的异常集中在资源与算法执行上。队列积压(任务提交速率超过计算节点处理能力,等待队列长度持续增长);节点失联(计算节点心跳超时,例如30秒未上报状态);算法超时(单次计算超过预设时限,例如图像处理任务超过120秒);内存溢出(处理大尺寸数据时超出容器内存限制);结果不一致(同一输入多次计算结果差异超过允许范围,可能由随机种子、浮点精度或数据竞争引起)。这一层的异常会直接影响实验结论的可信度,恢复时需要考虑重算、降级或标记不可信。
异常传播路径与隔离策略
识别异常类型只是第一步,更重要的是理解异常如何传播。传播路径通常有三种模式:纵向传播(下层异常向上层扩散,如设备通信失败导致编排任务失败)、横向传播(同层模块间相互影响,如样本管理异常导致设备控制层执行空抓)、跨层耦合传播(多个层同时受同一根因影响,如网络中断同时导致设备控制、数据采集和计算调度异常)。
隔离策略的核心思想是“在异常传播路径上设置断点”。具体做法包括:在编排层为每个步骤设置独立的超时与重试策略,避免单步失败拖垮整个实验流程;在设备控制层与数据采集层之间增加“数据有效性检查”,只有通过检查的数据才允许进入计算调度层;在样本管理层维护“物理位置—逻辑记录”的双向校验,任何不一致都触发暂停而非继续执行;在计算调度层为每个任务设置资源配额与超时上限,防止单个任务耗尽集群资源。
需要特别注意的是,异常传播并不总是坏事。有些异常在早期被下层捕获并处理,反而避免了上层做出错误决策。例如,数据采集层发现某个通道量程溢出后,主动将该通道标记为“无效”并通知编排层,编排层可以选择跳过该通道相关的分析步骤,而不是让计算调度层基于错误数据得出错误结论。因此,异常恢复工程的目标不是“消灭所有异常”,而是“让异常在正确的层级被正确的人以正确的方式处理”。
最后,各层的异常处理必须与系统的可观测性建设同步。没有日志、指标和追踪,异常传播路径就只能靠猜测。建议在每一层的关键接口处记录结构化日志,至少包含:时间戳、层标识、模块名、操作类型、输入摘要、输出摘要、异常码、耗时。这样在复盘时,才能沿着数据流和控制流还原出完整的异常传播链,为后续的恢复策略优化提供依据。