WATCH DOG

Watchdog system doc · MD

看门狗(Watchdog)系统技术文档

本文档说明工业设备控制软件中看门狗机制的基本原理、分层架构及各层职责。

1. 概述

看门狗(Watchdog)机制的核心作用是判断系统是否仍在正常运行,其最基础的能力是:在设定的时间窗口内,是否收到过"存活"信号("喂狗")。看门狗本身并不判断具体故障原因——例如无法区分"运动卡故障"与"相机无输出"——而只依据一条规则触发动作:超时未被喂狗即复位。

看门狗可以与具体业务逻辑结合,但这种结合应体现在软件侧的监控策略中,看门狗硬件本身不具备业务感知能力。

2. 分层架构

系统整体分为三层:硬件看门狗、软件监督器、工作线程/设备接口。

上层(硬件看门狗):不区分具体是相机故障还是轴故障,只判断"整机软件是否还存活"。
中层(软件监督器):维护一张心跳表,统一判断各监控对象是否超时,并执行对应处置动作。
下层(工作线程/设备):各自独立运行,每次"证明自己还活着"时只刷新自身的心跳时间戳(LastBeat),不负责判断超时。架构示意:

硬件看门狗 Watchdog Timer  —  整机通常 1 个芯片/寄存器
  超时未喂狗 → 复位工控机 / 切断轴与激光等危险输出
        ▲
        │  仅当关键生命线均存活时,才允许喂一次硬件狗
        │
软件监督器 Supervisor  —  定时线程,例如每 100ms 扫描一次
  心跳表 Heartbeats[]:
    camera     超时 2s     →  停止采集
    axis       超时 200ms  →  急停
    tcp        超时 5s     →  重连
    efem       超时 1s     →  停在安全位
    mainloop   超时 1s     →  重启模块
  Tick:遍历每一行,若 now − LastBeat > 超时阈值 → 执行该行对应动作
        ▲
        │  各线程仅更新时间戳,不负责判定是否超时
        │
  采集线程         运动线程         通信线程         机械手/UI主循环
  每帧图像打卡      每包轴状态打卡    每帧数据打卡      每次状态/每轮打卡
      ▲                ▲                ▲                  ▲
      │                │                │                  │
   相机/采集卡        运动控制卡        设备/MES          EFEM 机械手

3. 监控对象与响应动作

监控对象	超时含义	常见处置动作
采集线程	相机或算法卡住,画面无更新	停止采集、报警、释放资源
运动控制	轴未回到目标位置,或未收到 ACK	急停,禁止下发下一条运动指令
串口/TCP 通信	对端无响应或连接中断	重连、切换本地模式、上报 GEM Alarm
机械手/EFEM	传片过程中状态无更新	停止在安全位置,禁止盲目重试抓片
心跳线程自身	软件主循环冻结	记录日志、触发故障提示,必要时终止进程以交由硬件看门狗处理

4. 各层详解

4.1 硬件看门狗(Hardware Watchdog)

通常为工控机或运动控制卡上的一颗独立计时器芯片/寄存器(WDT),整机或整个进程通常只有一个。
只关注"这台设备的软件是否仍在正常运行",不区分具体是相机故障还是轴卡故障。
软件需每隔较短时间(如 100ms 至几秒)写寄存器或调用一次 API 完成"喂狗",由主程序或专门的喂狗线程负责。
软件正常运行时,持续喂狗使计时器不断被清零,不触发任何动作。
若软件卡死、进入死循环或进程崩溃,导致长时间无人喂狗,计时器溢出后触发硬件复位——重启工控机、复位运动卡,或切断轴、激光等危险输出。
硬件看门狗是系统的最终兜底机制。

4.2 软件监督器(Supervisor)

以独立线程运行的定时任务(如每 100ms 执行一次)。
维护一张心跳表(Heartbeats[]),记录各监控对象(采集、运动、通信、机械手、主循环等)各自的超时阈值与最近一次心跳时间(LastBeat)。
每次扫描时,对表中每一行判断:若当前时间与 LastBeat 之差超过该行设定的超时阈值,则执行该行预设的处置动作。
只有当所有关键生命线均被判定为存活时,才允许对硬件看门狗执行一次喂狗操作。

4.3 软件狗(Software-side Watchdog)

作为硬件看门狗触发复位之前的一道防线,概念上由软件监督器实现。
职责是在系统被硬件复位之前,先将设备停止在安全状态,并通过 GEM Alarm 等方式通知工厂主机系统(MES)。
硬件看门狗是最后的兜底手段;软件狗的目标是尽量在触发硬件复位之前完成安全处置和状态上报。

4.4 工作线程/设备接口

包括采集线程、运动线程、通信线程、机械手接口、UI/主循环等。
各自的职责仅限于:完成一次有效工作后,刷新自身对应的心跳时间戳(LastBeat)。
不负责判断自己是否超时,超时判定统一由软件监督器完成。

5. 看门狗与普通超时(Timeout)机制的区别

超时(Timeout):针对单次调用是否在预期时间内返回结果而设置,例如 ReadTimeout。
看门狗(Watchdog):持续监视整条生命线是否存活。即使当前没有正在等待的调用,只要在一段时间内完全没有收到任何"存活"信号,也需要被处理。二者关注的粒度不同:超时是单次操作级别的判断,看门狗是系统持续存活状态的判断。

6. 设计目的

看门狗机制的核心目的并非单纯"报告一个错误",而是防止失控的软件继续驱动轴运动、开启激光或操作机械手等危险动作。在半导体设备中,这是保障设备与人员安全的底线机制之一。

Navigation Menu