Safety 项目里最容易留下隐患的地方之一，是 Standard Program 和 Safety Program 之间的数据边界。两边当然可以交换数据，但“能访问”不等于“这些数据自动具备安全属性”。
具体的读写权限就一张表，建项目时直接对照：
| 数据对象 | Standard Program | Safety Program |
|---|---|---|
| 标准 DB 变量 | 读、写 | 对一个变量可选择读或写 |
F-DB 变量 |
只读，不允许写 | 读、写 |
| 位存储器 | 读、写 | 对一个位存储器可选择读或写 |
| F-I/O 过程映像输入 | 可读 | 读 |
| F-I/O 安全输出过程映像 | 不允许写入安全控制值 | 由 Safety Program 管理 |
| F-FB 实例 DB | 可读 | 读、写 |
两个“不允许”是这张表的核心：安全数据可以向外提供状态，但不允许标准程序反向修改。
一、先明确数据属性
Siemens 的基本原则是：Safety 程序应优先处理来自 F-I/O、其他 Safety 程序或其他故障安全来源的数据。标准变量属于 unsafe data，即使 Safety 程序允许读取，也必须按它真实的来源和用途去评估。
所以 Standard Program 可以为 Safety Program 提供模式、设定或辅助信息，但这些值本身不能替代 F-I/O 提供的安全过程信号。
反方向是通的：Standard Program 可以读取 F-FB 实例 DB、F-DB 以及 F-I/O 的过程映像，拿去做 HMI 显示、普通诊断和标准控制联锁。但真正控制 F-DQ 的逻辑仍应在 Safety Program 内完成。
二、为什么建议使用 Transfer DB
Siemens 推荐为 Standard Program 和 Safety Program 的数据交换建立专门的 transfer data blocks。两边的程序块不需要互相深入引用内部数据结构，只通过约定好的交换区传递信息。
这种做法的价值是解耦。只要 Transfer DB 的结构不变，标准程序内部的普通改动通常不会直接影响 Safety Program，反过来也一样。
但交换 DB 不是“随便改也没关系”的普通接口——它自身的结构一旦改变，仍会影响使用它的 Safety Program。它只是把受影响面从“任何一个普通 DB”缩小到“这一个约定好的 DB”。
三、结构变更为什么会影响 Safety
如果 Safety Program 直接读取一个标准 DB，而这个标准 DB 发生结构变化，Safety Program 可能变为 inconsistent。Siemens 明确指出，这类结构变化需要具备对 safety-related project data 的访问权限。
实际后果是：一个看上去只改了标准程序的改动，可能连带触发 Safety 部分的重新编译与验收流程。所以项目后期应该冻结 Standard 与 Safety 之间的接口结构，而不是把 Safety Program 直接绑在大量普通 DB 的内部字段上。
四、常见误解
| 常见说法 | 实际情况 |
|---|---|
| Safety Program 读到的变量都是安全变量 | 数据是否安全取决于来源和安全链，不取决于“在哪个程序里被读取” |
| Standard Program 可以写 F-DB | Standard Program 只能读 F-DB，不能写 |
| Standard Program 改 DB 结构不会影响 Safety | 如果该 DB 被 Safety Program 使用，结构变化会造成 Safety 不一致 |
| Safety 输出可以由普通程序直接写 F-DQ | F-I/O 安全过程输出应由 Safety Program 管理 |
五、总结
最稳妥的做法是把“谁拥有数据、谁只能读取、谁可以写入”在项目开始时就定义清楚。普通状态、模式和显示数据走专门的 Transfer DB；真正的安全过程信号，继续依赖 F-I/O 和故障安全数据链。
本系列上一篇：西门子安全程序结构；下一篇：ESTOP1 急停实战。
Comments NOTHING