Safety 程序编译通过、设备能够运行，并不等于安全项目已经完成。交付之前还得回答一个问题：你怎么证明现在跑在 F-CPU 里的，就是那个被检查过的程序？
靠项目名称、修改日期或者“我刚才下载的”都不算。STEP 7 Safety 为此提供了一套签名和文档机制。
一个可追溯的交付包至少要能回答下面五个问题：
| 问题 | 靠什么回答 |
|---|---|
| 验收的是哪一个 Safety Program | Collective F-Signature |
| 文档是哪一版 | Safety Summary（页脚带签名） |
| F-CPU 里跑的是不是这一版 | 在线/离线签名对比 |
| 后来改过什么 | 各类签名的变化 |
F-BaseID 是多少 |
单独记录，签名里没有 |
最后一行是最容易漏的，后面会单独说。
一、Safety Administration Editor
Safety Administration Editor 是 STEP 7 Safety 中管理和检查安全项目状态的核心入口。Siemens V21 在这里显示 Safety mode、Safety Program 状态、Collective F-Signature、Collective F-SW-Signature、Collective F-HW-Signature、F-communication address signature，并可以生成 Safety Summary。
对于 S7-1200/1500，还可以在这里管理 F-runtime group，并查看安全块信息。验收阶段不应该只在普通项目树中逐个看块，而应把它作为整体一致性检查入口。
二、Collective F-Signature 是什么
STEP 7 Safety 使用数字签名识别安全程序。Collective F-Signature 用来标识整个 safety-related project data 的状态；对于 S7-1200/1500，还能分别看到软件相关的 Collective F-SW-Signature 和硬件相关的 Collective F-HW-Signature。
| 签名 | 作用 | 配置要点 |
|---|---|---|
Collective F-Signature |
标识整个安全相关项目数据 | 用于把 Safety Summary、离线项目和 F-CPU 中运行版本对应起来 |
Collective F-SW-Signature |
标识 Safety Program 软件部分 | Safety 程序变化时会变化 |
Collective F-HW-Signature |
标识故障安全硬件组态部分 | F-HW 组态变化时会变化 |
| F-communication address signature | 标识安全通信地址相关数据 | 用于相关 Flexible F-Link 通信变更识别 |
验收记录不要只写“程序已确认”，应该把用于识别该 Safety 程序的 Collective F-Signature 拄上去。一年后有人问“当时验的是哪个版本”，能回答的只有这个号。
三、Safety Summary 有什么用
Safety Summary 是安全相关项目数据的正式文档基础，可以电子方式保存，例如生成 PDF。Siemens 明确指出，它与其他系统文档一起用于检查各组件的正确性，而正确性是系统验收的前提。
Safety Summary 页面页脚包含 Collective F-Signature，用于把这份文档明确绑定到对应的 Safety Program。生成验收版本时，应保留完整文档；如果后续复制、添加电子签名或注释，也必须保持其完整性。
四、在线/离线一致性怎么确认
完成离线检查后，还要确认目标 F-CPU 中运行的程序与离线验收版本一致。Siemens 的程序识别步骤要求连接到正确的 F-CPU，在 Safety Administration Editor 中比较在线和离线的 Collective F-Signature，并检查在线/离线程序一致性。
如果一张网里有多台 F-CPU，首先还要确认当前在线连接的确实是目标 CPU，例如通过 Online & diagnostics 中的识别手段确认，避免“签名对比做了，但连错了 CPU”。
签名相同是重要识别条件，但验收仍包含功能测试、项目数据检查和其他系统验证，不能把“签名一致”当成全部验收。
五、F-BaseID 为什么要单独检查
Siemens V21 特别说明，F-BaseID 不进入 Collective F-Signature，也不进入 Collective F-HW-Signature。
这一条的实际后果是：F-BaseID 变了，所有签名都可能看不出来。如果项目归档或验收需要确认它，就必须单独检查和记录，不能依赖 Collective F-Signature 帮你发现。
六、哪些变更会触发重新验收
Safety 程序里的功能变化、F-HW 组态变化都会通过相应签名表现出来。Siemens 还明确指出，如果把 Safety 指令切换到功能不完全相同的版本，重新编译后功能可能变化，F-block 签名、Collective F-Signature 和 Collective F-SW-Signature 也会变化，并且可能需要重新执行 acceptance test。
| 变更 | 关注项 | 处理原则 |
|---|---|---|
| Safety 逻辑修改 | F-SW-Signature / Collective F-Signature | 重新编译、检查变更范围并按需要重新验收 |
| F-I/O 或 F-CPU 组态修改 | F-HW-Signature / Collective F-Signature | 重新确认硬件安全参数与在线/离线一致性 |
| Safety 指令版本改变且功能不完全相同 | 块签名、F-SW-Signature、Collective F-Signature | 不能只做重新编译，应评估功能变化并可能重新验收 |
F-BaseID 变化 |
单独记录 | 不能依赖 Collective F-Signature 发现 |
七、总结
Safety 项目的最后一步不是“下载完成”，而是建立一个可验证、可追踪、可复现的验收状态。用 Safety Administration Editor 管理一致性，用 Collective F-Signature 识别版本，用 Safety Summary 固化文档，再通过在线/离线对比确认目标 F-CPU 中运行的就是这一版程序。
需要说明的是，功能测试记录、设备风险评估和安全功能验证仍然属于整个机械与设备安全验收的一部分。本文讲的是怎么证明程序版本，不是怎么证明设备安全。
本系列上一篇：F-I/O 钝化与重新集成。本篇为 SIMATIC Safety 核心系列第 14 篇。
Comments NOTHING