西门子安全程序结构：F-runtime group、Main Safety、F-FB 与 F-DB 怎么组织

前一篇把 F-I/O DB 单独拆开讲，这一篇回到 Safety 程序整体结构。S7-1200/1500 的安全程序不是把若干黄色网络散落在项目里，而是由一个或两个 F-runtime group 组织起来。

很多人第一次建 Safety 程序时的困惑是：到底该把自己的逻辑写在哪里，以及为什么有些块不允许互相访问。搞清楚运行组的结构和边界，这两个问题就同时解决了。

调用关系先记住这一条：

F-OB → Main Safety → 用户 F-FB/F-FC → 安全功能指令

建程序的顺序也按这个链来：

顺序	做什么
1	确定用几个运行组，默认一个就够
2	确定 Main Safety，它只是入口，不是装所有逻辑的地方
3	按功能拆 F-FB/F-FC，比如急停、安全门、反馈监控各一个
4	明确每个 F-I/O 与 F-DB 属于哪个执行边界

一、F-runtime group 是什么

Siemens V21 将 Safety 程序划分为一个或两个 F-runtime group。运行组是 F-System 内部形成的逻辑结构，把彼此相关的安全块、F-I/O、数据块和系统块放在同一个执行上下文里。

一个典型运行组包含 F-OB、Main Safety、用户创建的 F-FB/F-FC、一个或多个 F-DB、F-I/O DB、F-runtime group information DB、库中的安全块、F-system blocks 以及自动生成的 F-block。

对于 S7-1200/1500，F-OB 是运行组的执行入口。F-OB 周期性调用分配给它的 Main Safety；Main Safety 则是你真正开始组织安全功能的第一层用户块。

安全门、急停、反馈监控等功能不需要全部堆在 Main Safety 内，而是可以继续拆成独立的安全功能块。Main Safety 是结构入口，不是垂直堆放所有逻辑的容器——这一点在项目变大之后差别很明显。

对象	作用	配置要点
`F-FB`	带静态数据的故障安全功能块	每个调用需要实例数据；同一 F-FB 跨运行组使用时必须使用不同实例 DB
`F-FC`	无实例数据的故障安全函数	适合无状态逻辑和数据处理
`F-DB`	保存 Safety 程序使用的故障安全数据	可在 Safety 程序中读写，但运行组访问有边界规则
`F-I/O DB`	F-I/O 状态、钝化与重新集成接口	由系统自动生成，不是普通用户 DB
F-runtime group information DB	提供运行组与 Safety 程序整体信息	包含循环时间、运行时间、Collective F-Signature 等信息

在 S7-1200/1500 F-CPU 中启用 F-capability 后，STEP 7 Safety 会默认建立第一组运行组。Siemens V21 示例中可以看到 FOB_RTG1 [OB123]、Main_Safety_RTG1 [FB1] 和对应的实例 DB。

这套默认结构的意义是先给你一个可执行的 Safety 框架。后续你只需要在 Main Safety 下调用自己的安全功能块，而不是重新设计 Safety 调度机制。

Siemens 允许把 Safety 程序拆成两个 F-runtime group。一个典型目的，是让一部分安全回路运行在更高优先级、更快周期的运行组中，以获得更短响应时间。

但两个运行组之间不能像普通程序那样随意共享安全数据，跨运行组的数据交换需要使用专门的 F-runtime group communication。

拆成两个运行组会改变执行周期、数据边界和响应时间计算，不能只为了“分类更清楚”而随意拆分。

常见说法	实际情况
同一个 F-I/O 可以被两个运行组读取	同一 F-I/O 的通道和值状态只能从一个 F-runtime group 访问
同一个 F-FB 实例可以跨运行组复用	F-FB 可以复用，但必须使用不同实例 DB
F-I/O DB 可以随便在哪个 Safety 块里访问	只能从访问对应 F-I/O 的那个运行组访问