Troubleshooting Disabled Alarm Lock/Unlock Message Controls (MsgLock) in SIMATIC PCS 7 APL Faceplates

In SIMATIC PCS 7 Advanced Process Library (APL) faceplates—such as VlvDS or MotL—when the message lock/unlock button in the faceplate header appears disabled, grayed out, or permanently locked, the condition is driven either by controller logic holding the automation block's 'MsgLock' input active (MsgLock = 1), or by insufficient operator authorization permissions configured in the WinCC user administration. While standard operating controls require Level 5 (Process controlling), locking or unlocking process alarms from a faceplate requires Operator Authorization Level 6 (Higher process controlling) or Level 1100 (Emergency operation) in WinCC User Administrator.

APL Alarm Locking Mechanisms - Controller vs Operator Faceplate

In SIMATIC PCS 7 Advanced Process Library (APL), alarm management complies with international standards (ANSI/ISA-18.2 and IEC 62682) regarding alarm shelving, suppression, and locking. The APL provides two distinct layers for message suppression:
1. Automation Logic Layer (AS Controller Side):
- Driven deterministically by plant conditions (e.g. equipment out of service, maintenance bypass switch, or operational interlocks).
- Governed by dedicated block input pins: MsgLock (Message Lock) and MsgSup (Message Suppression).
- When active, the controller suppresses message generation at the ALARM_8P block boundary.
2. Operator Presentation Layer (HMI Faceplate Side):
- Allows qualified operators or maintenance technicians to manually lock messages for a specific piece of equipment during maintenance.
- Accessed via the padlock icon in the faceplate title bar (@pg_VlvDS.pdl or @pg_MotL.pdl).
- If the controller has already locked messages via MsgLock, manual unlocking from the faceplate is prohibited by design to prevent operators from overriding safety or maintenance interlocks.

The Role of the 'MsgLock' Block Input Parameter

In standard APL control blocks (like VlvDS from the Drives family, FB 1878):
- Function of MsgLock:
* MsgLock is an input parameter of type STRUCT (containing Value : BOOL and ST : BYTE).
* When MsgLock.Value = 1, all process alarms generated by the block (e.g., feedback monitoring error, runtime fault, position deviation) are suppressed in the AS.
* In the faceplate header, the padlock symbol displays closed (locked).
* If MsgLock is statically wired to an upstream logic gate, interlock block, or hardcoded to 1 in the CFC chart, clicking the padlock icon in the faceplate will have no effect because the controller code immediately forces the locked state on the next cyclic scan.
- Differentiating MsgLock from MsgSup:
* MsgLock: Locks messages completely; alarms are neither displayed nor logged in historical archives.
* MsgSup: Suppresses alarm visibility in the current operator picture, but the alarm event is still recorded in the long-term alarm archive.

WinCC User Authorization Levels for Alarm Management

If the controller MsgLock input is 0 but the operator still cannot toggle the lock button in the faceplate:
1. User Administrator Permissions:
- WinCC enforces hierarchical authorization levels. Standard setpoint changes or manual start commands require:
* Authorization Level 5: Process controlling (standard operator).
- Locking or unlocking alarms, placing blocks into Out of Service mode, or bypassing interlocks represents a higher operational risk and strictly requires:
* Authorization Level 6: Higher process controlling (lead operator / supervisor), or
* Authorization Level 1100: PCS 7 Emergency Operation.
2. Verifying Current User Rights:
- If the logged-in user possesses only Level 5 authorization, the padlock button in the faceplate remains disabled (grayed out) or prompts an authorization rejection dialog.

Feature Bit Configuration for Message Locking Behavior

The operational behavior of message locking is further refined by the block's Feature double-word parameter:
- Feature.Bit22 (Update Reserve / Message Locking Options):
* Controls whether message locking persists across controller restarts or resets automatically upon mode changes.
- Feature.Bit24 (Enable Message Locking via Faceplate):
* If this bit is set to 0, manual message locking from the operator faceplate is completely disabled regardless of user authorization. Only automated controller logic (MsgLock) can suppress alarms.
* To enable operator lock/unlock control from the faceplate, ensure the corresponding Feature bit is set to 1 in the CFC chart instance.

Alarm Locking Diagnostics and Parameter Mapping Table

The following table summarizes parameters governing alarm locking across PCS 7 APL blocks:

Parameter / EntityLocationSignal TypeDefault SettingOperational ImpactMsgLockCFC Block InputSTRUCT (BOOL + ST)0 (Unlocked)When 1, suppresses all block alarms from controller logicMsgSupCFC Block InputSTRUCT (BOOL + ST)0 (Active)When 1, suppresses display of alarms while maintaining archiveFeature.Bit24CFC Block InputBOOL (in DWORD)1 (Enabled)Governs whether manual locking from faceplate is permittedAuthorization Level 6WinCC User AdminUser PermissionMandatoryRequired to click and toggle the message lock padlock iconEventStateWinCC Structure TagDWORDDynamicReflects current locked status (Bit 22) to HMI faceplate

Verification

To confirm that message locking controls operate properly:
1. Open the CFC chart containing the VlvDS block in test mode. Verify that MsgLock.Value = 0.
2. In WinCC Explorer, open User Administrator. Verify that the active logged-in user account has authorization for Level 6 (Higher process controlling).
3. Open WinCC Runtime and open the VlvDS valve faceplate.
4. Click the padlock icon in the faceplate title bar:
- Verify that the confirmation dialog appears: 'Do you want to lock messages?'.
- Click OK.
- Confirm that the padlock icon updates to closed (locked) and the faceplate status displays Messages Locked.
5. Simulate an alarm condition (e.g. valve travel timeout). Confirm that no alarm entry is generated in the alarm banner.
6. Click the padlock icon again to unlock messages; confirm that normal alarm generation resumes instantly.

Limitations and Operational Precautions

When locking alarms in production environments:
1. Never Leave Alarms Locked Unmonitored: Locking messages from a faceplate blinds operators to safety-critical equipment faults. Implement administrative shift-handover logs tracking all locked or shelved alarms.
2. PLCSIM vs Physical Controllers: When testing in S7-PLCSIM or Soft-PLC (AS RTX), ensure the simulation supports ALARM_8P message server blocks. If the simulation engine does not support message server functions, message lock states may display inconsistently.
3. Audit Trail Logging: Toggling message locks generates an operator audit event in the WinCC Operation Log (Audit Trail) recording the user name, timestamp, and tag identifier.

Engineer FAQ

Why can I lock messages on MotL but not on VlvDS in the same project?

Check the CFC chart for VlvDS: its MsgLock input may be hardwired to an interlock or maintenance signal, or Feature.Bit24 may be disabled on that specific block type.

Does locking messages prevent the valve from tripping on an interlock?

No. Message locking affects strictly the alarm signaling and notification system (ALARM_8P). Controller safety interlocks (Intlock, Protect) continue functioning with full deterministic protection.

Where is the message lock status visible in the block icon?

When messages are locked, the APL block icon displays a small padlock symbol or suppresses the alarm group display indicator, alerting operators that alarms are inactive.

Can I lock messages automatically when a piece of equipment is switched to Local mode?

Yes. In CFC, connect the block's LocalAct output directly to the MsgLock input, ensuring that local field maintenance automatically suppresses spurious control room alarms.