Configuring Alarm Acknowledgment Interlock Latching with APL Feature.Bit22 and MsgAckn1

To implement interlock latching that prevents automatic equipment restart until an operator acknowledges the trip alarm in WinCC, enable Feature.Bit22 ('Send message state to block outputs') on the monitoring block (MonAnL or MonDiL). When enabled, internal ALARM_8P state feedback updates output MsgAckn1. The condition MsgAckn1 = W#16#FFFF (decimal 65535) confirms that all incoming and outgoing messages are fully acknowledged. Route MsgAckn1 to latching logic or compare its decimal value to reset interlock latches. Alternatively, use standard APL interlock blocks (Intlk02, Intlk04, Intlk08) with Feature.Bit27 enabled, which natively latches tripped inputs until an operator clicks Reset.

Principles of Interlock Latching and Alarm Synchronization

In continuous process facilities, safety standards frequently dictate that tripped machinery (such as feed pumps or burner valves) must not automatically restart when process conditions return to normal. Even if a high-temperature or low-pressure condition clears, the protective interlock must remain latched until an operator acknowledges the alarm in the WinCC alarm banner and issues an explicit reset command.

In SIMATIC PCS 7 Advanced Process Library (APL), achieving this synchronization between HMI alarm acknowledgment and AS control logic can be handled via two distinct architectures: extracting internal ALARM_8P acknowledgment status using Feature.Bit22, or deploying standard APL interlock blocks (Intlk02, Intlk04, Intlk08) with input latching enabled (Feature.Bit27).

APL Feature.Bit22 and ALARM_8P Feedback Architecture

By default, technological monitoring blocks (MonAnL, MonDiL) and motor/valve blocks (MotL, VlvL) call internal system message blocks (ALARM_8P) without routing message status to external block pins. Setting Feature.Bit22 = 1 activates feedback of internal message status to block outputs:

MsgErr: Indicates internal communication or parameterization error in ALARM_8P.
MsgStat: Reports internal execution status of the message handler.
MsgAckn1 (and MsgAckn2): Exposes the exact 16-bit acknowledgment word (ACK_STATE) directly from ALARM_8P.

When an alarm event triggers, MsgAckn1 transitions to indicate an unacknowledged incoming event. Once the operator acknowledges the alarm line on the WinCC OS client, the alarm system transmits acknowledgment back to the AS, setting MsgAckn1 to W#16#FFFF.

Internal Bit Structure of MsgAckn1 and ACK_STATE

The table below details the internal bit structure of the 16-bit word output MsgAckn1, which directly mirrors ALARM_8P.ACK_STATE.

Bit PositionAssociated SignalBit Value = 0 (Unacknowledged)Bit Value = 1 (Acknowledged)Bit 0Signal 1 (SIG_1) Incoming EventIncoming alarm pending acknowledgmentIncoming alarm acknowledgedBit 1Signal 2 (SIG_2) Incoming EventIncoming alarm pending acknowledgmentIncoming alarm acknowledgedBit 2Signal 3 (SIG_3) Incoming EventIncoming alarm pending acknowledgmentIncoming alarm acknowledgedBit 3Signal 4 (SIG_4) Incoming EventIncoming alarm pending acknowledgmentIncoming alarm acknowledgedBit 4Signal 5 (SIG_5) Incoming EventIncoming alarm pending acknowledgmentIncoming alarm acknowledgedBit 5Signal 6 (SIG_6) Incoming EventIncoming alarm pending acknowledgmentIncoming alarm acknowledgedBit 6Signal 7 (SIG_7) Incoming EventIncoming alarm pending acknowledgmentIncoming alarm acknowledgedBit 7Signal 8 (SIG_8) Incoming EventIncoming alarm pending acknowledgmentIncoming alarm acknowledgedBit 8 to 15Signals 1 to 8 Outgoing EventsOutgoing alarm pending acknowledgmentOutgoing alarm acknowledgedWord Status: W#16#FFFFAll Incoming and Outgoing SignalsAt least one message unacknowledgedAll alarms acknowledged (Decimal 65535)

Comparing Alarm-Based Reset vs Native Interlock Latching

Engineers must evaluate whether to use MsgAckn1 comparison or standard APL interlock blocks:

Alarm-Based Reset (MsgAckn1 = W#16#FFFF): Couples reset directly to the alarm system banner. When the operator presses the global 'Acknowledge Horn / Alarm' button in WinCC, the interlock condition clears. While convenient, this approach can lead to unintended equipment restarts if an operator acknowledges alarms without inspecting the underlying root cause.
Native APL Interlock Latching (Intlk02 / Intlk04 / Intlk08 with Feature.Bit27 = 1): The recommended Siemens standard. When any interlock input trips, the interlock block latches Out = 0 regardless of whether the physical input recovers. The operator must open the interlock faceplate or actuator faceplate and click the dedicated Reset button (RstOp or RstLi). This guarantees deliberate operator intent independent of alarm acknowledgment.

Step-by-Step Procedure to Implement Latching Logic

Follow this procedure to configure alarm acknowledgment latching in Continuous Function Chart (CFC):

Enable Feature.Bit22 on Monitoring Blocks:
- In the CFC editor, open the object properties of the monitoring block (e.g., MonAnL).
- Locate parameter Feature and set Bit 22 = 1 ('Send message state to block outputs').
Extract Acknowledgment Status:
- Insert a type conversion block (e.g., W_BO to unpack individual bits, or Word_To_Dint / comparison block).
- Interconnect MonAnL.MsgAckn1 to the converter input.
- Compare the output value: if Value == 65535 (W#16#FFFF), acknowledgment is complete.
Wire Latch Reset Logic:
- Feed the trip condition (e.g., MonAnL.AH_Act) into the S input of an SR (bistable flip-flop) block.
- Feed the acknowledgment signal into the R input of the SR flip-flop.
- Route the flip-flop inverted output to the Protect or Permit input of the target actuator block (MotL, VlvL).
Alternative: Configure APL Intlk08 with Feature.Bit27:
- Insert Intlk08. Connect process signals to inputs In01 through In08.
- Set Intlk08.Feature.Bit27 = 1 ('Interlock latching'). Connect Intlk08.Out to MotL.Protect.
- Interconnect MotL.RstOp or field reset pushbutton to Intlk08.RstLi.

Verification

Verify latching and acknowledgment logic through the following commissioning tests:
1. Force an analog input above its high-high alarm threshold (MonAnL.AH_Lim): verify that MonAnL.AH_Act = 1 and MsgAckn1 changes from W#16#FFFF to W#16#FFFE.
2. Confirm that the associated motor trips (MotL.Protect = 0).
3. Remove the simulated process override: verify that process condition returns to normal, but the interlock output remains latched.
4. In the WinCC alarm banner, click 'Acknowledge': verify that MsgAckn1 returns to W#16#FFFF and the reset signal unlatches the interlock logic.

Limitations and Operational Precautions

Using MsgAckn1 requires bidirectional communication between the WinCC Alarm Logging server and the automation system. If network communication between OS Server and AS is severed, alarm acknowledgments from the OS client will not reach the controller, leaving the equipment permanently locked out. Furthermore, when grouping dozens of signals across a single interlock, evaluating MsgAckn1 on every individual monitoring block creates complex logic networks. Utilizing standard Intlk08 blocks with Feature.Bit27 is significantly more scalable and robust.

Engineer FAQ

What does MsgAckn1 = W#16#FFFF mean?

It indicates that all incoming and outgoing alarms associated with signals 1 through 8 in the internal ALARM_8P block are fully acknowledged by the operator.

Why is MsgAckn1 missing from my CFC block?

By default, MsgAckn1 is hidden and inactive. You must set Feature.Bit22 = 1 to activate message status feedback, and set the pin visibility attribute to 'Visible' in the CFC block properties if necessary.