HMICare 运行健康看护

5.1 设计目标与定位

SCADA 系统上线之后，真正的风险往往来自「软件自身的长期运行状态」，而不是「现场设备」。现场反复出现的失效模式有：

5.1.1 两组能力模型

5.2 体系结构与运行形态

HMICare 采用单线程看护引擎：采样、判定、重启、落库全部跑在创建它的事件循环里，仅由 QTimer 驱动，不创建任何线程。这带来两个工程收益——没有采样竞争、没有锁等待；同时行为完全可预期（唯一会短暂阻塞的是低频的 minidump 写盘与磁盘空间读取）。

5.2.1 三种运行形态

界面与服务可以同时运行而不冲突：二者通过命名管道通信，并由命名互斥体 Global\HMICareWatchdogRole 保证同一时刻只有一个「看护者」。先拿到角色的一方执行监护与重启，另一方自动退化为只读观测 + 指令下发。状态栏第一格会明确标注当前角色，避免运维误判「谁在管事」。

5.2.2 自愈兜底链

目标进程崩了    →  HMICare 重启它（带重启风暴保护与退避）
HMICare 崩了    →  Windows SCM 重启 HMICare（服务化部署）
服务器重启了    →  服务开机自启 → 延迟 5 秒 → 拉起目标

两端都有兜底，这是「专业看护」与「脚本轮询重启」的本质区别：脚本一旦自己被杀，整条自愈链就断了，而系统不会有任何提示。

5.2.3 控制通道与角色互斥

服务运行在 Session 0、界面运行在交互会话，两者是不同进程。它们通过本地命名管道交换快照与控制指令：真正执行监护的一侧启动 ControlServer，另一侧以 ControlClient 异步收发（同一时刻只发一条请求，收到回复再发下一条，不阻塞事件循环）。

角色互斥由命名互斥体 Global\HMICareWatchdogRole 保证：服务与界面都可能具备看护能力，但同一时刻只有一个真正执行重启，否则会出现「双看护互抢」把进程反复重启。判角色时必须用只观察不抢占地探测（watchdogRoleBusy() + 读 var/watchdog.pid），而不是查「本进程是否持锁」——后者在独立进程里永远为 false，会让 --status 误报「无人看护」。

5.2.4 服务宿主的线程约束

Windows 服务的 ServiceMain 由 SCM 在另一个线程上回调，而 Qt 的事件循环与 QTimer 必须活在本进程创建它们的那个线程。因此实现上让 SCM 调度器（StartServiceCtrlDispatcher）跑在一个独立线程上，Qt 主事件循环留在主线程，两边用互斥体 + 条件变量握手，服务控制码（停止/暂停等）只置原子标志、由主线程轮询处理。

这带来两个结果：引擎本身仍是单线程的（采样、判定、重启、落库都在主事件循环内），没有锁与竞争；而服务控制不会因为在错误线程等待而挂死。安装服务时一次性配好「开机自启 + 延迟启动 + SCM 级失败自动重启（5 s / 15 s / 60 s 三次）」——这是自愈链路的最后一道保险。

5.3 故障自愈与现场保护

自愈不是「发现不在就拉起」这么简单。工业现场需要回答三个问题：为什么重启（原因可追溯）、重启前有没有留下现场（可分析）、会不会越重启越糟（风暴保护）。

5.3.1 恢复状态机

5.3.2 重启风暴保护

5.3.3 现场保护

5.4 内存精细化管理

内存治理要区分两类现象：正常业务波动与单向泄漏。把前者当泄漏会误重启，把后者当波动会等到 OOM。

5.5 运行自检：四维环境与功能体检

5.5.1 磁盘与存储

5.5.2 网络与通信链路

5.5.3 运行安全与访问审计

5.5.4 运行状态与可用性

5.5.5 关键功能探针

FEP收数@file:C:\scada\chmi_channel_diag.json     # 文件在且新鲜 = 健康
历史归档@tcp://127.0.0.1:6389                     # 可连接 = 健康
报警发布@http://127.0.0.1:8080/api/v1/health      # HTTP 200 = 健康
SCADA主程序@process:HMIPlayer.exe                 # 进程在 = 健康

四类探针（http: / tcp: / file: / process:）覆盖了「服务是否响应」「端口是否可连」「数据是否新鲜」「进程是否存在」四种典型健康语义；并支持单次超时、连续失败告警与数据陈旧告警，避免单次抖动造成误报。

5.5.6 「静默失效」的判定规则

四维自检真正要抓的是静默失效：进程在、端口通，但业务已经不再产生新数据。这类故障不会触发任何重启逻辑，因此必须靠「新鲜度」与「增量」来判定。

5.6 数据、历史与巡检报告

HMICare 的历史库为 SQLite（WAL 模式），默认位于 <exe目录>\var\hmicare.db；不可写时回落到 %ProgramData%\HMICare，并可用环境变量 HMICARE_DATA_DIR 覆盖。

5.6.1 巡检报告

菜单「文件 → 导出运行健康报告（HTML）」或 Ctrl+P 导出自包含 HTML 报告，覆盖十章内容：

5.6.2 历史库的分表设计

历史库为 SQLite 并启用 WAL 与 busy_timeout，允许「一写多读」——服务与界面可能同时打开同一个库。表结构按「采样 / 事件 / 维度 / 元数据」分类：

为什么新维度不追加到 sample 表：sample 使用位置绑定写入且已在现场部署，追加列会让老库上的写入整体错位；而且四维自省的采集频率与 2 s 采样不同，单独建表既能保持老库原地升级（新增表、不改既有表结构），也不需要为「每 2 秒一行」的存储成本买单。

保留策略：原始采样默认 7 天、聚合/事件/重启默认 180 天、四维快照与功能明细按深度保留天数滚动清理；审计表永不自动清理——删审计等于销毁证据，哈希链只保证「未被篡改」，不保证「未被删除」。

5.7 配置、部署与运维

5.7.1 配置热更新

5.7.2 命令行

hmicare.exe                        打开界面；服务未运行时界面自带看护
hmicare.exe --console              前台守护，无界面，日志打到控制台
hmicare.exe --install [--start]    注册为系统服务（需管理员）
hmicare.exe --status               打印服务、看护角色、被监护进程与历史库状态
hmicare.exe --ui-selftest          界面自检（验收 / CI 用）
hmicare.exe --target <exe>         仅本次运行改用其它被监护程序

5.7.3 目录与文件

5.7.4 界面自检与像素级回归

看护器的界面是运维与它交互的唯一窗口，因此界面本身也需要被验证。平台提供两级自检，且都不需要人工点界面：

为什么需要像素级回归：自检报告能证明「数据绑上了控件」，但仪表盘指针、等级色带、量值条是自绘的——报告里的数字对，不等于图上的画面对。这类缺陷在代码审查与单元测试里都看不见，只能靠「渲染 → 反解 → 比对」自动判定。

5.8 告警代码速查

告警代码是运维与看护之间的通用语言：看到代码就知道该查什么。代码按维度分组，下表摘录最需要现场处置的部分。

5.8.1 进程与内存

5.8.2 磁盘、链路、安全与可用性

5.9 安全边界与已知限制

5.10 与其它监控手段的技术对比

HMICare 与通用 IT 监控不是替代关系：通用监控负责主机、网络与机房基础设施，HMICare 负责「SCADA 业务是否可用、采集链路是否健康、软件是否需要自愈」。两者可以通过「运维指标快照」与标准接口对接，形成完整的分层监控体系。

5.11 本章小结

HMICare 的设计目标可以概括为一句话：让 SCADA 系统的运行质量可观测、可自愈、可追溯、可交付。可观测——进程、服务器、磁盘、链路、安全、可用性六个面全部有指标与告警；可自愈——崩溃、挂起、内存越限自动拉起，并带现场保护与风暴保护；可追溯——事件、重启、审计、可用性全部落库并导出巡检报告；可交付——单文件部署、配置热更新、报告自包含，运维无需专业工具即可上手。