How to Implement Independent Permit Open and Permit Close Interlocking on PCS 7 APL Valve Blocks

In standard PCS 7 Advanced Process Library (APL) valve blocks (such as VlvL, VlvMotL, and VlvAnL), the single 'Permit' input only restricts movement away from the configured safe position (SafePos), meaning it cannot natively provide independent permissions for opening and closing. To implement independent 'Permit Open' and 'Permit Close' interlocking, engineers must gate the automatic control commands (OpenAut and CloseAut) using upstream logic gates (And04) in CFC, dynamically manipulate operator authorization bitmasks in OS_Perm to disable WinCC faceplate buttons selectively, or utilize the directional operational interlock inputs (Intlock) rather than standard Permit.

APL Interlock Philosophy: Permit vs Intlock vs Protect

In the SIMATIC PCS 7 Advanced Process Library (APL), equipment protection and operational sequencing are governed by three standardized interlock categories:
1. Permit (Permit): An activation condition that must be fulfilled before a motor or valve can leave its resting neutral position. Once the equipment is running or open, losing Permit does not force it to stop or close.
2. Interlock Without Reset (Intlock): An operational interlock. If Intlock goes to 0 (unfulfilled), the equipment immediately trips to its safe position. As soon as the condition clears (returns to 1), the equipment resumes automatic operation without requiring operator acknowledgment.
3. Interlock With Reset (Protect): A high-priority safety interlock. If Protect drops to 0, the equipment trips to its safe position and remains locked out even after the interlock condition clears, until an operator manually executes a reset from the faceplate or CFC.

Directional Behavior of Permit Relative to SafePos

A frequent source of confusion among automation engineers is that APL valve blocks provide only a single Permit input pin rather than separate Permit_Open and Permit_Close pins:
* The SafePos Parameter: Valve blocks define a safe resting state via the parameter SafePos:
* SafePos = 0: Safe position is closed (Ctrl = 0).
* SafePos = 1: Safe position is open (Ctrl = 1).
* Directional Gating: The block algorithm evaluates Permit only when moving away from SafePos:
* If SafePos = 0, the valve requires Permit = 1 to open. However, closing the valve is moving toward the safe position, so the block always allows the close command regardless of Permit.
* If SafePos = 1, the valve requires Permit = 1 to close, but opening is always permitted.
* If a process requires an operational state where a valve in neutral position may be closed by an operator but is banned from opening (e.g., during vessel inerting), the native Permit input cannot fulfill this requirement on its own.

Implementing Independent Directional Permits via CFC Logic

To implement independent directional permissions for both Automatic and Manual modes:

Gating Automatic Commands (OpenAut / CloseAut):
* Insert two standard APL interlock blocks (Intlk02 or Intlk04): one for Permit_Open conditions and one for Permit_Close conditions.
* In CFC, pass the supervisory open command through an And04 block gated with Intlk_Open.Out. Connect the result to VlvL.OpenAut.
* Similarly, gate the supervisory close command with Intlk_Close.Out and connect to VlvL.CloseAut.
Directional Interlock with Intlock:
* If the valve must actively trip closed when open conditions become invalid, connect the Permit_Open logic directly to the standard Intlock input.
* If the valve must actively trip open when close conditions become invalid, invert the interlock and assign SafePos = 1.
Signal Quality Byte Enforcement:
* In APL, interlock inputs require a valid signal status byte (16#80 = Good). If a constant value 0 is written without a valid quality code, the block rejects the input and marks the signal status as invalid.

Restricting Manual Operator Commands via OS_Perm Bitmasks

To prevent an operator from clicking the 'Open' button in the WinCC faceplate while still allowing them to click 'Close':

APL blocks evaluate the 32-bit double word OS_Perm (Operator Permissions).
Specific bit positions inside OS_Perm control whether individual faceplate buttons are active:
For VlvL / VlvMotL, Bit 0 controls permission to switch to Auto, Bit 1 controls Manual, and specific bits control permission to command Open and Close.
In CFC, instantiate an SCL wrapper or bit-manipulation logic that dynamically toggles the Open permission bit inside OS_Perm:
When plant conditions disallow opening, force the Open bit in OS_Perm to 0.
The block outputs OS_PermLog, which the WinCC faceplate reads to grey out and disable the 'Open' button dynamically, while the 'Close' button remains clickable.

Comparison of APL Interlock Inputs on Valve Blocks

The table below compares the functional behaviors of the various interlock inputs available on standard PCS 7 APL valve blocks.

Interlock PinPurpose / Functional ScopeDirectional BehaviorRequires Reset?Faceplate DisplayPermitPrevents leaving safe positionOnly acts away from SafePosNoBlue 'Permit' indicatorIntlockOperational trip conditionTrips valve toward SafePosNoYellow 'Interlock' indicatorProtectSafety interlock with latchingTrips valve toward SafePosYes (Operator reset)Red 'Protection' indicatorOS_PermRestricts manual operator clicksBit-selective per faceplate buttonNoGreys out specific buttons

Verification

To confirm that directional valve permissions operate correctly:
1. In the CFC chart, verify that the Permit_Open condition is FALSE (0) and Permit_Close condition is TRUE (1).
2. Attempt an automatic open command: verify that OpenAut does not transition the valve control output Ctrl.
3. Open the valve faceplate in WinCC Runtime: confirm that the 'Open' button is greyed out and unclickable, while the 'Close' button remains operable.
4. Set the Permit_Open condition to TRUE. Confirm that the 'Open' button becomes enabled and that the valve successfully transitions to the open state.
5. In the CFC online view, verify that all interconnected signal status bytes indicate 16#80 (Good).

Limitations and Operational Precautions

Never attempt to bypass hardwired safety instrumented system (SIS) interlocks using software Permit or Intlock logic; functional safety trips must reside in dedicated safety programs.
When manipulating OS_Perm bits dynamically, ensure changes are synchronized with cyclic execution to avoid button flicker on OS faceplates.
Do not leave un-interconnected interlock pins with status 16#00 (Bad), as the block will report a channel fault and refuse to operate in Automatic mode.
Changing SafePos online requires a full review of all connected interlocks, as reversing the safe position inverts the directional behavior of the Permit block input.

Engineer FAQ

Why did setting Permit = 0 in CFC not stop the valve from opening?

If you manually typed 0 into the Permit.Value field in CFC without providing a valid signal status (ST := 16#80), the APL block ignored the manual override because the quality code was invalid. Interconnect Permit through an OpDi01 or standard interlock block to ensure valid status propagation.

Can VlvMotL have independent torque fault inputs for open and close?

Yes. VlvMotL includes dedicated torque monitoring inputs: TorqOp (Torque switch open) and TorqCl (Torque switch close), each with independent monitoring times (MonTiTorq).

What is the difference between MotRevL and VlvMotL regarding interlocks?

MotRevL (Reversing Motor) provides distinct forward and reverse interlock inputs (IntlFwd, IntlRev, PermFwd, PermRev). VlvMotL is modeled after standard valves with a defined safe position, requiring directional gating via OS_Perm or external logic.

Technical References

Related Tags

APL
VlvL
VlvMotL
Permit
Interlocks

How to Implement Independent Permit Open and Permit Close Interlocking on PCS 7 APL Valve Blocks