企业官网建设流程全解析

一、"审计"在方案里指什么

在工控和上位机语境下，"审计"不是财务意义上的查账，而是审计跟踪（Audit Trail）：它是系统活动的流水记录，按事件从始至终的途径，顺序检查、审查和检验每个事件的环境及活动；审计跟踪通过书面方式提供应负责任人员的活动证据以支持职能的实现，既记录系统活动也记录用户活动。

具体到MaxWell.Watchdog，"落盘审计日志"的意思是：把每一次布防、心跳、异常判定、每一步停机动作及其结果，都写成不可事后随意篡改的、带时间戳的、可追溯的记录，以便事后回答三个问题——谁/什么触发的？实际执行了什么？哪些没成功？

审计跟踪通常服务于四个目标：个人职能（individual accountability）、事件重建（reconstruction of events）、入侵探测和故障分析。对你这个场景，最核心的其实是事件重建和故障分析两个。

二、审计记录该包含什么

从通用规范看，审计记录至少应包含：事件类型、事件发生的时间和地点、事件来源、事件结果、与事件相关的用户或主体的身份等。落到你的看门狗上，可以细化成：

其中"已发送未确认"这一类要单独区分，因为它和"通信失败"的风险等级完全不同——前者意味着设备可能已经动作但状态未知。

三、案例分析

案例 1：主程序崩溃后的责任界定

场景：某工站测试过程中MaxWell主程序异常退出，看门狗检测到心跳超时后执行了安全停机。事后客户质疑：“是不是看门狗误触发把测试中断了？”

审计的作用：如果日志里有完整的链路——最后一次心跳时间、判定超时的阈值与连续失败计数、触发时刻的进程存活状态、随后每一步的发送时间与返回结果——就能直接还原时间线，证明是主程序先失联、看门狗才介入，而不是反过来。这正是审计跟踪"事件重建"能力的典型用法。

反面情况：如果只记了一句"Watchdog triggered, shutdown done"，这个争议基本无法澄清，现场也很可能因此要求关闭看门狗。

案例 2：单站失败的影响范围界定

场景：停机流程中 3 号站主控板通信超时，其余站点正常关闭。

审计的作用：逐站隔离失败的设计，必须靠审计日志才能体现价值——明确记录哪些站点已安全关闭、哪些设备失联，这本身就是你方案里已经写进去的目标。没有这份记录，事后无法判断 3 号站当前处于什么状态，也就无法决定是否需要人工现场处置。

案例 3：与硬件安全回路的边界澄清

场景：发生一次异常，需要判断是上位机侧问题还是底层安全回路问题。

参考做法：硬件急停回路和软件看门狗双冗余是工业控制系统中常用的安全机制，急停信号通常直接连接 PLC 输入模块并通过硬件继电器切断主电源，急停回路应独立于其他控制回路；同时急停信号和看门狗触发都应记录到日志中，便于故障分析。审计日志在这里的价值是划清边界：如果日志显示看门狗并未触发、而急停信号有独立记录，就能把排查方向指向硬件侧。

案例 4：配置变更引发的事故追溯

场景：某次安全电压参数被现场人员改大，导致一次停机没有真正降能量。

审计的作用：这类问题往往不在停机日志里，而在配置变更审计里。系统配置变更、软件安装卸载、设备启停重启等操作都属于系统操作审计的范畴。所以除了运行日志，看门狗的配置文件变更也建议留痕（至少记录配置版本号与变更时间），否则事故复盘时会缺一环。

四、几个容易踩的坑

1. 日志本身要防篡改。审计跟踪具有完整性与不可篡改性，其数据需要受到保护以防止非法修改，强访问控制是保护审计记录免受非法访问的有效措施，而审计跟踪信息的完整性在法律问题中尤为重要。实践中常见做法是只授予系统/应用账户修改审计日志的权限，并要求日志维护通过应用接口进行，而非直接访问操作系统控制台。

2. 别把审计写进主流程的关键路径。如果写日志阻塞了停机动作，就本末倒置了。相关规范也提示应尽量在隔离的系统而不是 ICS 本身执行审计记录处理，并在审计处理失败时向相关人员报警。

3. 留存周期要提前确认。按《网络安全法》要求日志留存不少于 6 个月；涉及敏感或核心业务数据的操作日志，留存时长需覆盖事件追溯周期，通常建议不少于 1 年。这个最好在项目验收阶段就和甲方对齐，避免后期补做。

4. 嵌入式侧的对应思路可参考。在车规等更高要求场景里，会通过读取复位状态寄存器的位域判断复位原因，并在检测到看门狗超时标志时触发看门狗日志记录。你这个是 PC 侧进程级看门狗，思路可以类比：异常判定一定要区分"原因"，不能只记"发生了"。

需要的话，我可以帮你把看门狗审计日志的字段结构和 JSON 示例写出来，直接对应你方案里的停机四步骤。