4. PCS 7安全程序结构

在PCS 7中，安全程序并不是“把普通程序写得更可靠一点”，而是运行在与标准程序严格隔离的独立执行体系里。理解这套结构，是后续做F-块编程、安全运行组划分和编译下载的前提。本节围绕五个关键对象展开：安全程序与非安全程序的分离边界、F-CALL调用机制、F-块、安全运行组，以及安全程序的编译与下载流程。

一、安全程序与非安全程序的分离

PCS 7的CPU中同时存在两类程序：标准用户程序（Standard User Program）和安全用户程序（Safety Program）。两者在同一个CPU内运行，但被强制隔离，隔离体现在三个层面。

存储与执行隔离：安全程序存放在独立的安全程序容器中，由F-运行时系统（F-Runtime）调度，标准程序由普通运行时调度。安全程序不能直接读写标准程序的DB，标准程序也不能直接调用F-块。

数据交换隔离：两类程序之间只能通过受控接口交换数据。标准程序向安全程序传递数据，必须经过F-块的输入参数或专门的F-共享DB；安全程序向标准程序回传状态，也必须通过F-块输出或F-共享DB。这种“窄接口”设计使安全程序的输入输出可被审查和验证。

访问保护：安全程序带访问保护（Access Protection），需要密码才能打开、修改和下载。任何对F-块的修改都会改变安全程序的签名，必须重新编译并走完整的下载确认流程。

二、F-CALL：安全程序的唯一入口

标准程序无法直接调用F-块，必须通过F-CALL。F-CALL是标准程序中一个特殊调用块，它把安全程序的执行“挂”到标准程序的循环中。可以把它理解为安全程序与标准程序之间的执行接口。

F-CALL的关键特性有三点。第一，一个安全程序通常只允许一个F-CALL实例，它负责触发整个安全运行组的执行。第二，F-CALL必须放在会被循环执行的组织块中（通常是OB1或循环中断OB），否则安全程序不会被执行。第三，F-CALL本身不携带安全逻辑，它只是执行入口，真正的安全逻辑在F-块中。

如果F-CALL被误删或未被循环调用，安全程序将停止刷新，F-块输出会进入安全状态（通常为去能量状态），这是设计上的失效安全行为，但也会导致联锁误动作，因此F-CALL的位置和调用条件需要重点检查。

三、F-块：安全逻辑的载体

F-块是安全程序中执行安全功能的块，包括F-FB、F-FC和F-DB。它们与标准块在编程外观上相似，但受F-运行时系统管理，并带有安全属性。常用的F-块类型包括：

• F-FB/F-FC：编写安全逻辑，如急停处理、联锁判断、许可条件计算。
• F-DB：存放安全程序的中间状态和输出，只能被安全程序访问。
• F-I/O访问块：用于读取F-输入模块和写F-输出模块，是安全程序与现场安全信号之间的通道。

F-块编程有两条硬性约束。其一，F-块内只能使用F-库中经过认证的指令和块，不能随意调用标准库块。其二，F-块必须被F-CALL间接调用，不能由标准程序直接调用。F-块的输出在正常运行时按逻辑刷新，在检测到安全程序故障时按配置进入安全状态。

四、安全运行组

安全运行组（Safety Run Group）是安全程序的执行单元。一个安全程序可以包含一个或多个安全运行组，每个运行组有独立的执行周期和独立的F-CALL。运行组的划分依据是安全功能的响应时间要求：响应要求高的功能放在执行周期短的运行组，响应要求低的功能放在执行周期长的运行组。

例如，急停联锁要求响应时间不超过100 ms，可放入10 ms周期的运行组；而某些温度高高联锁允许500 ms响应，可放入100 ms周期的运行组。运行组周期越短，CPU负荷越高，因此划分运行组本质上是在响应时间与CPU负荷之间做平衡。

每个安全运行组在编译后会生成独立的运行组签名。下载时，运行组可以单独下载，但同一运行组内的F-块必须整体一致，不能只下载其中一部分。

五、安全程序的编译与下载流程

安全程序的编译与下载比标准程序严格得多，核心原因是必须保证“下载到CPU的程序”与“经过验证的程序”完全一致。流程如下。

第一步：生成安全程序签名。编译前，系统会对安全程序的所有F-块、F-DB和运行组配置计算签名（Signature）。签名是内容的数字指纹，任何修改都会导致签名变化。

第二步：编译安全运行组。在CFC/SFC中执行“编译安全程序”，系统按运行组分别编译，检查F-块调用关系、F-库指令使用、运行组周期设置是否正确。编译不通过时，错误会定位到具体F-块和具体网络。

第三步：一致性检查。编译后，系统比较离线项目与在线CPU中的安全程序签名。若不一致，说明CPU中的安全程序与当前项目不同，需要确认是下载新程序还是保留旧程序。

第四步：下载。下载安全程序需要具备安全权限，并输入密码。下载过程中CPU会进入安全停止或保持安全状态，下载完成后安全程序重新启动。

第五步：确认签名。下载后，系统显示新的安全程序签名，操作人员需要确认该签名与预期一致。这一步是安全验收的关键记录，签名应记入安全台账。

六、结构关系小结

把上述对象串起来看：标准程序通过F-CALL触发安全程序；安全程序按安全运行组划分执行周期；每个运行组内由F-块实现安全逻辑，通过F-I/O访问现场安全信号；编译时按运行组生成签名，下载时按运行组整体下载并确认签名。这条链路中，分离是前提，F-CALL是入口，F-块是载体，运行组是执行单元，编译下载是交付手段。五者缺一不可，任何一环配置错误都会直接影响安全功能的可用性和可验证性。

实际项目中，建议在CFC中为每个安全运行组建立独立的图表层级，命名中体现运行组编号和周期，例如“SG1_10ms_急停”“SG2_100ms_温度联锁”。这样在编译报错、下载确认和后期变更时，可以快速定位到具体运行组，减少误操作风险。