Troubleshooting Persistent Diagnostic Alarms on Driver Block MOD_D1 After Replacing Fail-Safe Modules

When replacing a failed fail-safe analog input module (e.g. SM 336) restores healthy module LEDs but leaves a persistent diagnostic alarm on driver block MOD_D1 (showing Maintenance Status MS = DW#16#80000000 and Alarm_8P SIG_5 = True), the root cause is an unacknowledged PROFIsafe passivation state. In SIMATIC S7 F-Systems, replacing safety hardware does not automatically re-integrate I/O channels. The fail-safe channel driver (F_CH_AI) asserts an acknowledgment request (ACK_REQ = 1). To eliminate the diagnostic alarm, pulse the fail-safe re-integration input (ACK_REI) via safety logic or click the F-acknowledgment button on the safety faceplate, which clears passivation and resets MOD_D1 status.

Architecture of Diagnostic Driver Block MOD_D1 and Alarm_8P

In SIMATIC PCS 7, the Driver Generator automatically instantiates diagnostic driver blocks (such as MOD_D1 / FB 92) within diagnostic system charts (@1/, @2/) to monitor central and distributed I/O modules.

MOD_D1 handles hardware diagnostic interrupts dispatched by organization blocks OB82 (Diagnostic Alarm) and OB83 (Module Removal/Insertion). Process alarms are transmitted to the WinCC OS Server using the standard system function block Alarm_8P (SFB 35). Each of the 8 signal inputs (SIG_1 to SIG_8) represents a specific hardware fault condition.

Root Cause: PROFIsafe Passivation and Mandatory Re-integration

When a fail-safe module (such as 6ES7336-4GE00-0AB0 / SM 336) suffers a wire break, power loss, or internal fault:

Safety Passivation: The fail-safe runtime system immediately passivates the module or channel, substituting safe fail-safe values (typically 0.0 mA or substitute values) and asserting PASS_OUT = 1 on block F_CH_AI.
Safety Standard Requirement (IEC 61508 / IEC 61511): Safety guidelines strictly forbid automatic re-integration of safety circuits upon hardware restoration to prevent unexpected machine restarts.
Persistent Alarm State: Even though the new module is physically inserted and healthy, S7 F-Systems maintains the passivated state until a deliberate human or programmatic acknowledgment (ACK_REI) is received. Until re-integrated, MOD_D1 continues flagging maintenance status.

Decoding Maintenance Status MS = DW#16#80000000 and SIG_5

Inspecting the instance data block of MOD_D1 reveals exact diagnostic indicators:

MS = DW#16#80000000: Indicates Maintenance Demanded / Acknowledgment Required. The module is operational, but maintenance status cannot clear until safety re-integration is completed.
ALARM_8P_1.SIG_5 = True: Maps to the diagnostic message: Module passivated / Channel error awaiting acknowledgment.
MSGSTAT1 = W#16#0: Indicates the Alarm_8P message has been dispatched to the OS but has not completed its outgoing state cycle.

Step-by-Step Re-Integration and Alarm Clearance Workflow

Execute the following sequence to restore normal diagnostic status:

Inspect Safety Channel Driver (F_CH_AI):
- In CFC, open the safety chart containing the F_CH_AI block associated with the replaced module.
- Verify that ACK_REQ = 1 (Acknowledgment requested) and PASS_OUT = 1.
Trigger Re-Integration Pulse (ACK_REI):
- On the WinCC OS safety faceplate (or Safety Matrix Viewer), log in with authorized safety credentials and click F-Ack.
- Alternatively, toggle the global safety acknowledgment tag connected to F_CH_AI.ACK_REI from 0 to 1 and back to 0.
Verify Passivation Drops:
- Confirm ACK_REQ drops to 0 and PASS_OUT transitions to 0.
Acknowledge OS Alarm: In WinCC AlarmControl, click the single acknowledge button on the diagnostic alarm row.
Inspect MOD_D1: Confirm MS returns to DW#16#0 and SIG_5 transitions to False.

Comparison of Standard vs Fail-Safe Hardware Diagnostic Clearance

The table below contrasts diagnostic behaviors between standard and fail-safe modules in PCS 7:

| Diagnostic Dimension | Standard I/O Module (e.g. SM 331) | Fail-Safe I/O Module (e.g. SM 336) |
|---|---|---|---|
| Driver Block | MOD_D1 / MOD_D2 | MOD_D1 + F_CH_AI |
| Diagnostic Interrupt | OB82 / OB83 | OB82 / OB83 + PROFIsafe telegrams |
| Re-integration Behavior | Automatic upon hardware recovery | Strictly manual / acknowledged re-integration |
| Safety Passivation Flag | Not applicable | F_CH_AI.PASS_OUT = 1 |
| Alarm Signal (SIG_5) | Clears automatically when OB82 clears | Clings until safety ACK_REI is issued |
| Required Action | Replace hardware & acknowledge OS | Replace hardware, execute ACK_REI, acknowledge OS |

Verification

Confirm complete diagnostic resolution:

Open SIMATIC Manager, select the AS station, and open PLC > Diagnostic/Setting > Module Information.
In the diagnostic buffer, confirm the latest event is Module re-integrated or Diagnostic interrupt cleared.
In CFC, monitor MOD_D1; confirm MS = DW#16#00000000 and all SIG_x flags on ALARM_8P_1 are False.
In WinCC OS Runtime, verify that the diagnostic alarm clears from the incoming list and the maintenance wrench symbol disappears from process block icons.

Limitations and Operational Precautions

Observe the following safety precautions during module maintenance:

Field Device Health Mandatory: Never execute safety re-integration (ACK_REI) without confirming that field sensors are properly connected and operating within calibrated 4...20 mA ranges.
PROFIsafe Address Verification: When inserting a new fail-safe module, verify that the DIP switch setting on the side of the module matches the exact PROFIsafe destination address (F_Dest_Add) configured in HW Config.
Do Not Bypass MOD_D1: Never delete or un-interconnect MOD_D1 driver blocks; they provide critical lifecycle monitoring required for compliance with machinery safety standards.

Engineer FAQ

Why does MOD_D1 show an alarm when the physical module has a green LED?

Because fail-safe modules require formal safety re-integration (ACK_REI) after a fault. Until acknowledged in the safety logic, the channel remains passivated, causing MOD_D1 to assert its maintenance alarm.

What does MS = DW#16#80000000 signify on a PCS 7 diagnostic block?

It represents the standardized Maintenance Status code for 'Maintenance Demanded / Action Required', indicating that a device requires user intervention or acknowledgment before normal operation can resume.

How can I acknowledge all passivated safety channels simultaneously?

By creating a central F-acknowledgment push button in the safety program that distributes a pulse to the ACK_GL input of the F-Control block (F_CTRL) or ACK_REI inputs across all fail-safe channel drivers.