光通信产线工业视觉全链路高可用冗余方案

1. 产线的单点故障光通信模块的产线是典型的 24 小时连轴转场景。一根光纤跳线的端面检测、一个光模块的引脚共面度测量、一颗激光器的外观缺陷判定全部依赖工业视觉系统在毫秒级完成拍照—算法—判定—通信的闭环。问题在于这条闭环上任何一个环节的硬件故障都会让整条线瞬间停摆。工控机死机或蓝屏视觉软件无法启动PLC 拿不到 OK/NG 信号产线只能停固态硬盘SSD损坏操作系统和算法模型一起丢失重装加标定动辄数小时网卡、交换机端口、相机链路任意一处中断图像流直接断掉。对客户而言“停机等修是不可接受的。SLA 里写的不是平均修复时间MTTR”而是系统可用性 99.9% 以上——换算下来一年允许的不可用时间不到 9 小时。这意味着架构设计的目标不是修得快而是故障发生时业务不中断。本文围绕三个层面展开工业视觉系统的高可用High AvailabilityHA设计计算层主备工控机如何做到毫秒级故障切换网络层工业相机如何通过双网口、PRP/HSR 环网实现无感热备软件层如何用 Docker 容器化 看门狗机制让检测进程崩溃后秒级自愈。2. 高可用的基本度量在动手之前先把可用性量化否则架构选型没有依据。可用性等级年停机时间典型实现手段99%约 87.6 小时单机 快速维修99.9%约 8.76 小时主备冗余 自动切换99.99%约 52.6 分钟双活 无状态化 快速自愈99.999%约 5.26 分钟全链路冗余 故障注入验证几个关键指标需要区分清楚RTORecovery Time Objective恢复时间目标故障发生后多久能恢复业务。主备切换的毫秒级说的就是 RTO。RPORecovery Point Objective恢复点目标允许丢失多少数据。视觉系统通常不存业务数据RPO 主要针对配置、标定参数和模型文件。MTBF / MTTR平均无故障时间与平均修复时间用于反推冗余是否足够。工业视觉系统的特殊性在于它不是一个独立业务而是产线控制回路中的一环。视觉系统停 3 秒PLC 侧的节拍就乱了可能触发整线急停。因此 RTO 的目标不是分钟级而是检测节拍级——通常要求在一个或几个检测周期内完成切换即几十到几百毫秒。3. 计算层3.1 冗余形态的取舍形态说明RTO成本适用场景冷备备机断电待命人工上电启动分钟~小时低非关键工位温备备机运行但不同步状态切换需重启服务秒级中一般检测工位热备主备备机实时同步状态随时可接管毫秒~秒级高光通信等连续产线双活两台同时处理互为备份毫秒级最高超高 SLA 场景光通信产线一般选择热备备机保持运行、持续同步主节点失联后立即接管。双活虽然切换最快但视觉系统涉及相机独占访问两台机器同时抓图会冲突实现复杂度陡增通常不划算。3.2 心跳与故障检测主备切换的速度首先取决于多快能判定主节点已死。这里有个经典矛盾心跳间隔太长 → 故障发现慢RTO 变大心跳间隔太短 → 网络抖动就误判频繁脑裂split-brain。工程上的常见做法是多级心跳 多通道确认工程上通常并行使用三条心跳通道互为补充应用层心跳主备之间以 TCP/HTTP 短连接互发心跳间隔约 100ms连续 3 次超时即判定异常链路层心跳直接读取网卡 Link 状态与交换机端口状态属于硬件级信号发现最快共享存储/仲裁盘心跳通过仲裁盘确认对方是否真的失联防止网络分区导致双主。判定逻辑建议采用快速失败 延迟确认链路层检测到网卡 down立即进入疑似故障状态暂停主节点对外输出应用层心跳连续 3 次约 300ms未响应判定主节点失效备节点通过仲裁盘确认自己不是被网络隔离的一方然后执行接管。这样既能把切换时间压到几百毫秒又能避免网络抖动引发的误切换。3.3 状态同步切换快不等于切换对。备机接管后如果不知道当前检测到哪一颗产品、当前配方是什么、标定参数是多少那和重启没区别。需要同步的状态分三类静态配置相机参数、标定文件、算法模型、检测配方。这类数据变化少用共享存储或定期 rsync 即可。运行状态当前工单、已检测数量、NG 计数、当前产品位置。这类数据变化频繁需要实时同步。外部会话与 PLC 的通信连接、与 MES 的上报队列。这类最难处理需要设计成可重建。推荐做法是把状态外置视觉服务本身尽量无状态运行状态写入 Redis 或轻量数据库主备共享同一份。这样备机接管时只需重新加载不需要追平。以容器编排为例主备两个节点运行同一份视觉服务镜像通过环境变量区分角色primary / standby并把标定文件、模型目录以只读方式挂载进容器运行状态统一指向同一个 Redis 地址。这样备机接管时无需重新部署只要切换角色标识即可。3.4 切换流程与防脑裂一个完整的切换流程大致如下一个完整的切换流程大致如下主节点正常运行持续对外输出检测结果链路层心跳一旦异常主节点立即暂停输出进入疑似故障状态若应用层心跳连续 3 次超时则判定主节点失效否则回到正常运行备节点向仲裁服务申请仲裁锁仲裁失败则备节点保持待命并告警避免双主仲裁成功则备节点接管加载状态、重建与 PLC 的连接接管完成后对外恢复输出并上报切换事件原主节点恢复后自动降级为备节点重新加入同步。防脑裂是高可用架构里最容易被忽略的一环。如果主备之间的心跳网络断了但两台机器都还活着备机会误以为主节点已死而接管结果两台同时向 PLC 输出信号产线直接乱套。解决办法是引入第三方仲裁仲裁盘、仲裁服务或者直接利用 PLC 的互锁逻辑——PLC 侧只接受一个主标识的连接另一个连接直接拒绝。这一层保护比任何软件逻辑都可靠。4. 网络层计算层做了主备如果相机链路是单点那高可用就是纸面上的。工业相机的冗余主要有两条路线。4.1 双网口方案多数工业相机GigE Vision 接口自带双网口或者可以通过双网卡工控机实现链路冗余。链路聚合LACP两个网口绑定成一个逻辑链路一条断了另一条顶上。优点是配置简单、带宽叠加缺点是依赖交换机支持且切换时间取决于交换机实现通常在几十毫秒到秒级。双网卡独立接入相机两个网口分别接到两台交换机或两台工控机由软件层做主备。这种方式切换更可控但需要相机支持多主机访问或者用一台机器做转发。双网口方案的本质是链路冗余它解决的是网线断了、网口坏了的问题但解决不了交换机挂了的问题。4.2 PRP/HSR 环网要解决交换机单点就要上环网冗余协议。工业领域主流的是 IEC 62439-3 定义的两种协议协议全称拓扑冗余方式切换时间PRPParallel Redundancy Protocol双星型/双网并行报文双发双收接收端去重0无切换HSRHigh-availability Seamless Redundancy环形报文沿环双向传输接收端去重0无切换两者的核心思想一致同一帧报文发两份走两条不同路径接收端根据序列号去重。因为不存在切换动作所以切换时间是 0——这就是无感的含义。PRP适合双网并行的星型结构相机同时接入两个独立网络两个网络各自有交换机互不干扰。HSR适合环形结构设备串成一个环报文顺时针、逆时针各走一圈任意一处断链都不影响通信。对视觉系统来说PRP 更常见因为相机和工控机通常分布在产线两侧星型布线更自然。HSR 则适合设备密集、布线空间受限的场景。需要注意的工程细节PRP/HSR 需要支持该协议的交换机或网卡普通商用交换机不行报文去重依赖序列号网络中的设备必须都支持否则会出现重复帧环网中的冗余盒RedBox用于把普通设备接入 HSR 环选型时要确认兼容性。4.3 相机侧的软件配合网络层做到无感软件层也要配合否则切换瞬间的丢帧仍会导致误判帧序号校验算法侧对连续帧做序号连续性检查发现丢帧时主动丢弃当前产品重新触发一次采集而不是拿残缺图像做判定。采集超时重试设置合理的采集超时如 50ms超时后重试而非直接报错。相机状态监控持续监控相机的心跳、温度、丢包率异常时提前告警把故障消灭在发生之前。5. 软件层硬件冗余解决的是机器坏了软件自愈解决的是进程挂了。后者发生的概率其实更高——内存泄漏、算法异常、驱动崩溃都会让检测进程退出。5.1 为什么用 Docker把视觉检测程序容器化收益不只是部署方便环境一致性算法依赖的 CUDA、OpenCV、相机 SDK 版本全部固化在镜像里不会出现这台机器能跑那台不能跑。快速重建容器崩溃后docker restart或编排工具自动拉起几秒内恢复比重新安装快几个数量级。资源隔离限制 CPU、内存避免某个进程吃满资源拖垮整机。版本回滚镜像打 tag出问题直接切回上一个版本。一个典型的视觉服务镜像构建过程大致分四步基础镜像选用带 CUDA 运行时的 Ubuntu 基础镜像保证 GPU 推理可用系统依赖安装 Python 运行时、图像处理所需的系统库如 libgl、libglib并清理包缓存以控制镜像体积相机 SDK把厂商 SDK 拷入镜像并静默安装避免每台机器手工装驱动应用与健康检查拷贝依赖清单与业务代码安装 Python 依赖并声明健康检查命令每 5 秒探测一次、超时 2 秒、连续 3 次失败判定不健康最后指定启动入口。这样构建出的镜像在任何一台工控机上跑起来行为都一致出问题直接换镜像版本即可回滚。5.2 三层自愈机制单靠restart: always是不够的——它只能处理进程退出处理不了进程还在但已经卡死。完整的自愈需要三层第一层容器级重启在编排配置中为视觉服务声明重启策略为除非手动停止否则始终重启并配置健康检查每 5 秒执行一次探测单次超时 2 秒连续 3 次失败即判定容器不健康启动后预留 30 秒的宽限期避免服务尚未就绪就被误判重启。健康检查脚本要真正验证业务能力而不是只 ping 一下端口健康检查脚本要真正验证业务能力而不是只 ping 一下端口。一个合格的探测逻辑通常依次确认三件事状态存储是否可达能否在 1 秒内完成一次读写往返最近一次检测心跳是否在 3 秒以内说明检测循环仍在推进相机连接状态是否正常。三项全部通过才返回健康任意一项失败即返回不健康由编排工具据此触发容器重建。第二层进程级看门狗容器内的主进程可能因为死锁卡住此时容器本身还活着健康检查也可能因为实现不严谨而漏判。这时需要进程级看门狗看门狗本身是一个独立于主检测进程的守护进程它只做两件事拉起主进程、判断主进程是否还活着。启动时先拉起主检测进程之后每秒巡检一次如果发现主进程已经退出立即重新拉起如果主进程还在但心跳文件超过 5 秒没有更新就判定为卡死先强制结束该进程再重新拉起。整个过程记录日志便于事后追溯是崩溃还是卡死。主检测进程需要在每个检测周期更新心跳文件与之配套主检测进程需要在每个检测周期结束时刷新一次心跳文件——抓图、推理、向 PLC 下发结果之后把当前时间戳写入约定的心跳文件。这样心跳的更新频率就等价于检测循环的推进频率看门狗据此判断业务是否真的在跑而不是只看进程是否存在。第三层硬件看门狗如果操作系统本身卡死内核 panic、驱动死锁软件看门狗也无能为力。这时需要硬件看门狗Hardware Watchdog工控机主板上的独立定时器由软件定期喂狗一旦超时未喂硬件直接复位整机。Linux 下可以通过/dev/watchdog操作Linux 下硬件看门狗以字符设备的形式暴露给系统使用上分两步先向看门狗设备写入超时时间例如 30 秒再交由 systemd 的看门狗服务接管周期性的喂狗动作。一旦系统在超时时间内没能完成喂狗硬件层面直接复位整机不依赖任何用户态进程。配合 BIOS 中的上电自启和看门狗复位后自动启动可以实现整机级别的无人值守恢复。5.3 自愈时间预算把三层机制的时间加起来可以估算出实际的 RTO故障类型检测手段检测耗时恢复耗时总 RTO检测进程崩溃进程退出立即容器重启约 2~5s2~5s检测进程卡死心跳超时5s进程重启约 2s约 7s容器异常健康检查15s3×5s容器重建约 5s约 20s操作系统卡死硬件看门狗30s整机重启约 60s约 90s工控机硬件损坏主备心跳300ms备机接管约 500ms约 1s可以看到软件自愈的 RTO 是秒级硬件故障的 RTO 靠主备切换压到秒级以内。两者互补才能覆盖全部故障场景。6. 冗余协同把前面三层拼起来一个完整的高可用工业视觉系统大致长这样控制层状态层计算层网络层相机层工业相机 双网口交换机 A交换机 B主工控机备工控机Redis 状态存储仲裁服务PLC协同的关键点相机双网口 PRP保证图像流不中断主备工控机 仲裁保证计算不中断容器化 三层看门狗保证进程不中断状态外置保证切换后业务能接着跑PLC 侧互锁作为最后一道防线防止双主输出。7. 落地建议7.1 落地顺序不要一上来就追求 99.99%按投入产出比排序先做软件自愈容器化 健康检查 看门狗成本最低能覆盖大部分故障再做状态外置把运行状态从进程内存挪到 Redis为切换打基础然后做主备心跳、仲裁、切换流程逐步验证最后做网络冗余PRP/HSR 涉及交换机和相机选型改动最大放在最后。7.2 常见坑只做心跳不做仲裁网络分区时双主输出比不切换更危险。健康检查形同虚设只检查端口存活进程卡死时依然返回健康。状态同步不完整切换后备机不知道当前工单导致重复检测或漏检。看门狗超时设置过短正常的大图像处理耗时超过超时阈值导致误重启。忽略相机独占主备同时访问同一台相机导致采集冲突。没有故障演练架构设计得再好不演练就不知道真实 RTO。建议定期做故障注入拔网线、kill 进程、断电。7.3 故障演练清单演练项操作预期结果进程崩溃kill -9检测进程5s 内自动重启检测恢复进程卡死暂停进程SIGSTOP心跳超时后强制重启网线断开拔掉主链路网线PRP 无感切换图像不中断主节点宕机主工控机断电1s 内备机接管PLC 无感知网络分区断开主备心跳网络仲裁生效不出现双主整机卡死触发内核 panic硬件看门狗复位自动恢复8. 总结工业视觉系统的高可用本质上是把单点故障逐个消除的过程计算层用主备 仲裁 状态外置把硬件故障的 RTO 压到秒级以内网络层用双网口或 PRP/HSR 环网把链路故障的切换时间做到 0软件层用容器化 三层看门狗把进程故障的恢复时间做到秒级。三者不是替代关系而是互补关系。对光通信这类 24 小时连续产线而言客户要的不是坏了能修好而是坏了看不出来。架构设计的每一个决策都应该回到这个目标上来。