通信已经恢复，安全输入为什么仍然是 0？同样设置了手动确认，为什么另一次短暂掉电后，过程值却自行恢复？判断这类现象，不能只问“按哪个复位”，而要先确认谁触发了钝化、影响哪些通道，以及当前处在哪个恢复阶段。 [1] [3]

这是「SIMATIC Safety 工程笔记」的恢复机制篇，写给已经会查看 F-I/O 诊断和安全功能块、需要解释恢复行为的读者。以 S7-1500F 与 ET 200SP 数字 F-I/O 为主要情境，区分通信故障、模块或通道故障、程序主动钝化，以及系统启动；完整 DB 接口和各功能块行为另见对应专题。

规则基线为 Siemens SIMATIC Safety V21 与 STEP 7 Safety V21 Instructions（11/2025）。原有三张恢复时序图继续用于对应机制的说明；新增程序连接图来自 V14 SP1 历史例程，单独标明范围。本文为资料解读与检查建议，未进行仿真或实机复现；不将普通数字 I/O 的结论推广到全部 GSD 设备、模拟量或特殊启动机制。

恢复输出之前：先控制危险运动与能量，核对维护授权、现场人员和仍然存在的动作请求。重新集成可能让输出重新采用过程命令，不是只清除画面报警。下面不授权在生产设备上拔线、强制变量或循环产生确认脉冲。 [8] [11]

一、读到 0 之后，先判断数据和故障入口

钝化（passivation）时，输入侧向安全程序提供故障安全值，输出侧不再按原过程命令输出；重新集成（reintegration）则恢复使用过程数据。本文讨论的数字通道在相应钝化条件下使用安全值 0。这个词描述数据处理状态，不等于模块永久损坏。 [1]

一个急停触点正常动作，也可能让程序读到有效的 0；而通信中断时得到的 0，可能是安全替代值。两者都不能凭数值本身区分。模块诊断、对应通道的质量状态和故障前后的变化，需要放在一起看；数字安全输入仍须处理系统提供的过程映像值，不能用旧的 1 顶替当前安全值。 [1] [7]

先从下面四个入口找证据。这是本文的排查分类，不是把所有情况都写成同一套“错误消失—按确认—启动”的操作。

入口	先找什么证据
通信故障	相关 PROFIsafe 诊断、故障持续时间、通信恢复与 ACK_REQ 的先后。
模块或通道故障	故障槽位和通道、钝化粒度、实际确认策略，以及模块测试要求。
程序主动钝化	PASS_ON 的写入来源和保持条件，是否同时存在其他故障。
F 系统启动或 F-I/O 掉电	CPU 是否重启、哪个供电域中断、I/O 何时恢复，以及实际 F 监控时间。

同一个外部现象可以触发多个分支。例如，供电中断后可能同时出现通信和通道诊断。先保存最初的记录，再判断恢复时还剩哪些条件；不能只拿最后一条报警解释整个过程。手册还列有 DISABLE 等主动停用情境，已有工程使用这些功能时，应继续追查相应接口，不把本表当作全部原因清单。 [1]

二、通信故障消除后，为什么仍在等待确认

按手册所述，F-CPU 与某个 F-I/O 之间的安全通信错误被检测到后，该 F-I/O 的全部通道钝化。这里的“全部”指相关 F-I/O，不是整条产线。对于支持值状态的相应 S7-1200/1500 配置，通信故障时模块状态和通道状态应结合官方对应列解读。 [2] [7]

通信恢复只完成一部分条件。相关错误全部消除、系统将 ACK_REQ = 1 置位后，再收到规定的用户确认上升沿，才重新集成。因此，设备已能在线访问而输入仍使用安全值，不一定是新的硬件故障。 [2] [8]

原文图 1 对应官方输入 F-I/O 时序：① 是通信故障及钝化，② 是通信错误全部消除，③ 才是重新集成。读图要比较②与③，而不是只看最终数据回来没有；这些事件间距不代表某个固定的等待秒数。 [2]

恢复检查应具体到目标模块：诊断是否仍在、ACK_REQ 是否出现、确认进入的是不是该模块的接口。ACK_REQ = 0 既可能是尚不具备确认条件，也可能是确认已经完成；不能把这一个位当成永久的“模块健康”标志。 [5]

这里的确认不能通过把 ACK_NEC 改成 0 来普遍省略。ACK_REI 章节将每次通信故障后的用户确认，与模块或通道故障的可配置确认方式明确分开。先确认故障种类，再解释参数，不能把自动通道恢复策略套到通信错误上。 [4] [8]

三、模块故障与通道故障，分开看范围和恢复方式

1. 一个通道恢复，不代表整块模块所有通道恢复

模块级故障会影响相关 F-I/O 的全部通道；通道故障的影响范围则还取决于组态采用整模块钝化还是通道级钝化。后者允许已排除故障的通道恢复，尚有故障的通道继续保持安全替代值。这个区别直接影响该看总状态，还是该追到具体通道。 [3]

对支持 RIOforFA-Safety 且采用通道级钝化的相应 S7-1200/1500 配置，官方状态表中模块 QBAD、PASS_OUT 可以保持不变，而故障通道的值状态已变为 0。不能因此把“QBAD 没报警”翻译为每个输入都有效；也不能把这列行为推广到所有协议和 CPU。 [7]

2. 手动与自动策略，只在各自的适用条件下成立

先查实际模块使用哪一种设置：没有 Channel failure acknowledge（通道故障确认）参数的 F-I/O，查看关联 DB 的 ACK_NEC；有该参数的模块则按对应通道参数处理。不要想当然地同时改两处，或把另一个模块的界面当成自己的设置位置。 [1]

在适用 ACK_NEC 的情境中，0 对应自动重新集成，1 对应用户确认。手册 S010 只允许在过程从安全角度允许自动重新集成时采用 0。自动策略不是软件替人完成了一次人工确认，而是选用了另一种被允许的恢复方式。 [4]

图 2 是输入 F-I/O 自动恢复的官方例子，用于对照图 1 的人工确认等待阶段；并不表示输出模块也必然在故障消除的同一瞬间恢复。 [3]

有些输出 F-I/O 需要先施加规定测试信号，才能确认故障已经消除。ACK_REQ 说明指出，相关确认可能要在故障排除后等待数分钟才可进行，具体以模块手册为准。这里既不能承诺固定恢复时间，也不能对任何持续异常都只建议“再等一会儿”。 [5]

再看图 3：通道 0 与通道 1 分别发生故障，前者先排除并重新集成，后者随后才恢复。一次确认不会修复仍存在的通道故障；ACK_REI 的恢复范围是当时已满足恢复条件的相关通道，并不是操作者任意点选的某一路。 [3] [8]

四、PASS_ON 还为 1 时，先追查主动钝化的原因

PASS_ON 是程序请求，不是硬件自动返回的故障标志。只要关联 F-I/O DB 中的 PASS_ON = 1，相关 F-I/O 就保持钝化；该接口作用于整块 F-I/O，不能通过它实现任意单通道钝化。 [6]

例如，设备维修条件一直请求钝化，外部接线即使已经恢复，模块也不会因为连续收到确认就取消这项程序请求。这个例子是由接口行为作出的推理，说明应追查谁写入 PASS_ON，而不是先更换输入模块。

检查时先看该变量的交叉引用、所属 F 运行组、置位和解除条件，再辨认它是否用于经设计的启动保护。不要在线强制 PASS_ON 为 0 来验证“是不是它挡住了”。解除请求可能恢复过程数据；原保护条件为什么存在，以及解除后哪些输出会生效，都要先弄清楚。 [6] [11] [12]

状态也不必成对变化：官方表中 PASS_ON 为 1 时 QBAD 为 1，但 PASS_OUT 保持不变。因此，PASS_OUT 没变化不能反证程序没有主动钝化。取消主动请求也不是对其他通信或通道故障的确认，应继续按实际存在的故障分支核对。 [7]

五、确认接口要先看对象，再看上升沿

1. ACK_REI 对应相关 F-I/O，不是故障消除命令

ACK_REQ 由系统给出，ACK_REI 接收用户确认。手册 S011 要求确认信号来自手动操作，不允许自动产生的信号代替。把 ACK_REQ 反馈到 ACK_REI，或周期性发复位脉冲，虽然可能产生电平变化，却丢掉了被要求的人工确认来源。 [5] [8]

图 4 来自与前面组态、急停篇相同的 V14 SP1 例程。它显示 %M0.6 经触点连接至相关 F-I/O DB 的 ACK_REI，有助于区分“确认信号来源”和“被确认的模块接口”。 [15]

原例程文字提到用 M 位给出应答，但这张图没有展示 M0.6 的上游产生逻辑。本文不能据此宣称自动翻转 M 位符合 S011，也不把图中地址写成现场调试步骤。阅读自己的工程时，必须继续追到手动操作来源及允许确认的条件。 [8] [15]

确认信号还要被当前程序识别为有效上升沿。持续为 1 不会不断产生新沿；故障尚未排除时曾按过按钮，也不能代替之后在可确认阶段的操作。若 ACK_REQ 已出现而没有恢复，先核对接口对象、信号先后和实际执行路径。 [5] [8]

2. ACK_GL 的“全局”只在当前 F 运行组内

ACK_GL 通过 ACK_GLOB 的上升沿，对它所在 F 运行组中满足条件的 F-I/O 或通道进行统一确认。它不是全 CPU、全站点或全产线的清错按钮。用户确认的来源要求仍然存在，也不会消除尚未排除的故障。 [8] [9]

官方限制每个 F 运行组只能调用一次 ACK_GL，调用需要相应实例，EN/ENO 不能接线。选择这个方式前，要查清运行组里会被同时确认的模块；一个确认按钮可能恢复多个设备的过程数据，不能只观察眼前这一块。 [9]

采用的确认路径	另一条路径必须满足的条件
通过 ACK_GL 的 ACK_GLOB 确认	相关 F-I/O DB 的 ACK_REI 必须为 0。
通过某个 F-I/O DB 的 ACK_REI 确认	ACK_GL 的 ACK_GLOB 必须为 0。

这是官方对两条路径的条件约束，不是建议把两个输入接到同一个脉冲上“保险复位”。相关通道、值状态与 F-I/O DB 的安全程序访问还应属于同一 F 运行组，不能把同一接口分散到两个运行组里控制。 [9] [12]

原文命名差异：本次读取的通信及通道故障章节把全局输入写作 ACK_REI_GLOB，而 ACK_GL 的功能说明和参数表写作 ACK_GLOB。本篇按指令参数表标识实际接口，同时保留这一差异；不是另有一个可以互换使用的新引脚。 [2] [3] [9]

六、系统启动和短暂掉电，为什么可能不等人工确认

F 系统启动期间，F-I/O 先处于钝化。手册说明，正常启动条件下的自动重新集成不受 ACK_NEC 或通道确认设置控制，最早在启动后的第二个 F 运行组周期发生。“最早第二个周期”不等于“第二个周期一定完成”：设备和通信条件可能使它经历更多周期；通信建立超过相应 F 监控时间时，不走这一自动恢复结果。 [10]

F-I/O 自身短暂失电还要与 F-CPU 重启分开。S012 警告指出：供电中断短于该 F-I/O 分配的 F-monitoring time 时，可能不受手动确认设置限制而自动重新集成；长于该时间时，系统检测到通信错误。原文没有为“恰好相等”提供单独分支，这里不替它补一个确定结论。 [3]

因此，比较两次“断电恢复”前，应先记录哪个设备失电、CPU 是否进入过 STOP、掉电持续时间和模块实际监控值。只有“断过一下电”的描述，无法证明两次经历了相同的恢复路径。这是检查建议，不要求在现场人为制造临界掉电。

监控时间的任务是兼顾正常通信的可用性与过程允许的安全时间，不是用来强制选择某一种确认行为。为了让掉电总被识别成通信错误而随意缩短时间，或为了不报警而任意放大，都不能代替响应时间核算与启动保护。 [13]

启动保护要阻止的是不允许的过程输出，不只是保存一个报警。手册 S008 指出，安全程序启动时 F-DB 通常按初值初始化，保存的错误信息会丢失；不允许意外启动的过程，应在安全程序中实现相应保护，并在能够安全输出时才接受用户确认。 [11]

官方给出的原理例子，是用 F-DB 中初值为 TRUE 的 BOOL 识别启动，在它有效期间禁止过程输出，例如通过 PASS_ON 主动钝化；安全输出条件具备、故障已消除后，再由用户确认解除。这里说明设计思路，不提供缺少设备互锁和验证的通用复位程序，也不把 CPU 重启当成消警方法。 [11]

七、恢复检查要停在明确的状态证据上

把当前故障种类辨认清楚后，再按下面的顺序排查。此表用于选择下一项观察，不是看到某个位就直接赋值的操作表；同样的症状在不同模块和策略下可能对应不同分支。

观察到的状态	下一项检查
过程值仍为 0，尚未确定是否钝化	对照真实输入、模块诊断、目标通道质量和主动请求；不先断言模块故障。
PASS_ON 持续为 1	查程序写入来源及解除条件；不要用确认覆盖主动保护。
手动恢复场景中 ACK_REQ 尚未出现	查故障是否完全消除、模块测试是否完成，以及是否看对 DB；不持续发确认。
ACK_REQ 已出现，确认后仍未恢复	核对用户信号来源、有效沿、目标接口、运行组和两条确认路径是否冲突。
通道已重新有效，但设备仍不允许动作	转查对应安全功能实例、启动保护及输出执行链；不继续给模块重复复位。

“恢复有效”还不等于“输入应当为 1”。输入重新采用现场过程值后，真实开关如果仍处于 0，程序继续读到 0 完全可能是正确结果。应先核对数据来源和实际工况，再讨论下游逻辑，而不是用一个期望的电平倒推恢复是否成功。 [1]

后续的急停、门监控和反馈监控各有自己的状态。模块确认解决过程数据恢复，功能块状态要回到对应实例解释，机器能否启动还要看外围条件。详细调用分别见 ESTOP1、SFDOOR 和 FDBACK；本篇不重复它们的完整时序。

八、验证恢复行为，要保留故障前后的完整记录

验证前：先批准测试环境、危险能量控制、允许的故障模拟方式和恢复条件。通信中断、失电和输入故障测试都可能影响多个回路，不能为了得到某张图里的状态而在运行设备上随意拔线。

测试应按实际采用的分支安排：通信故障消除但尚未确认；通道先后恢复；输出模块仍在等待测试；程序主动钝化尚未解除；正常系统启动；以及短时 I/O 失电。无需为文章凑齐每一种故障，但不能用一次拔插后的成功恢复，代表全部配置和启动条件。

记录至少应能连起这些对象：CPU 与模块版本、站和槽位、通道与 F-I/O DB、F 运行组、确认策略、实际监控时间、故障出现与消除的时刻、确认信号及恢复后的过程值。手动确认是否被识别、哪些通道恢复、现场输出是否安全，分别给出观察结果；未测试的部分保持未测试。

如果排查改变了确认策略、主动保护逻辑、运行组或硬件配置，需要定位全部相关变更并进行影响分析，再验证受影响部分。受影响内容可能没有直接改过代码；只测试刚修改的那个位不足以证明其余回路没有变化。 [14]

最终应能回答：这次是哪个条件使数据被替代，恢复条件何时具备，确认作用于哪些对象，以及数据恢复以后什么机制继续阻止意外启动。需要查变量方向与成员范围时，转到 F-I/O DB 状态与控制接口；交付证据另见 程序验收、签名与归档。

资料来源

除第9项为 STEP 7 Safety V21 Instructions、第15项为 V14 SP1 历史例程外，以下为 Siemens《SIMATIC Safety – Configuring and Programming》V21（11/2025）章节。文中的分支表和检查顺序是有来源的整理，不是已在本站设备上完成的测试记录。

1. Siemens：Process Data or Fail-Safe Values。When are fail-safe values used?、Fail-safe value output、S009、Reintegration；本篇仅讨论数字 F-I/O。

2. Siemens：After communication errors。Behavior after communication errors、Reintegration；图1对应输入 F-I/O 的通信故障时序，事件①～③。

3. Siemens：After F-I/O or channel faults。故障范围、Reintegration、供电警告 S012；图2对应自动恢复示例，图3对应通道级人工恢复事件①～⑥。

4. Siemens：ACK_NEC。ACK_NEC 的适用故障类型、初值及 S010；不把这一变量写成全局启动策略。

5. Siemens：ACK_REQ。请求置位与清除、通道恢复、输出模块测试完成前的等待。

6. Siemens：PASS_ON。主动钝化整块 F-I/O，PASS_ON 保持为1时的行为。

7. Siemens：QBAD/PASS_OUT/DISABLED/QBAD_I_xx/QBAD_O_xx and value status。按 CPU、协议特性、故障类型与钝化粒度区分的状态表。

8. Siemens：ACK_REI。确认条件、通道级恢复范围、手动产生确认信号的警告 S011。

9. Siemens：ACK_GL: Global acknowledgment of all F-I/O in an F-runtime group。STEP 7 Safety V21 Instructions，11/2025；Description、Note、Parameters；实际接口名 ACK_GLOB、每组调用限制和两条确认路径的条件。

10. Siemens：After startup of F-system。启动自动重新集成的最早周期、通信建立超时分支及 S008。

11. Siemens：Programming startup protection。S008、Example of restart/startup prevention；初始化与用户确认之间的输出禁止。

12. Siemens：Rules for F-Runtime Groups of the Safety Program。Rules；F-I/O 通道、值状态、DB 与 F 运行组的访问对应。

13. Siemens：Configuring the monitoring times。监控对象、Rules、General procedure；可用性与过程安全时间两项约束。

14. Siemens：Acceptance of Changes。Introduction、影响分析、S072、S071；不展开全部签名识别专题。

15. Siemens：TIA Portal 中 S7-1500F CPU 与 ET200SP 安全模块的配置例程。V14 SP1 历史例程，第1节环境及第4节，原图4-4；CPU 1511F-1 PN V2.1、ET200SP F-DI 6BA00。仅说明图中连接，不据此认可未展示的手动来源和启动保护。

图片说明：前三张图沿用原文媒体及其标注的官方出处，第四张为官方历史例程原图；未生成、未改绘。第三方图像权利归原权利人，不纳入本站原创文字的 CC BY-NC-SA 许可。本轮未取得额外转载许可证明。

修订说明：按故障来源、钝化范围和确认条件重组，补充 PASS_ON、启动与短暂掉电边界，以及确认对象的区别；不设正文目录。资料复核：2026-09-10。本文为官方文档解读与明确标识的检查建议，未进行仿真或实机验证。