Understanding Signal Status Prioritization and Plausibility Logic in APL MuxAn03

In SIMATIC PCS 7 Advanced Process Library (APL), the analog multiplexer block MuxAn03 (FB 1878) executes 2-out-of-3 (2oo3) plausibility evaluation across three analog inputs (PV1, PV2, PV3) using the PlDiff tolerance parameter and a strict hierarchical signal status ranking. The block evaluates whether at least two inputs share the identical highest-priority signal status and deviate by no more than PlDiff. Signal status priority is evaluated in descending order: Good (16#80) > Simulation (16#60) > Bad device-related (16#28) > Bad process-related (16#00). If all three inputs are plausible, the lowest-index input (PV1) is routed to PV. If inputs deviate by more than PlDiff, the output status is set to Bad device-related (16#28), alerting downstream controllers to a sensor discrepancy.

Executive Summary

In safety-critical and high-reliability continuous processes, redundant analog instrumentation—such as triple-redundant temperature, pressure, or drum level transmitters—protects against single-sensor failures. The PCS 7 APL block MuxAn03 combines multiplexing with 2-out-of-3 voting and plausibility checking. When commissioning MuxAn03, control engineers often observe nuanced output switching behavior that appears non-intuitive without understanding the block's internal mathematical arbitration. MuxAn03 arbitrates not only numerical deviations but also NAMUR signal status quality codes (ST), ensuring that degraded or simulated signals never override healthy operational measurements.

Architecture and Fundamental Mechanics

The plausibility algorithm of MuxAn03 operates through structured mathematical comparison and quality code arbitration:

The Signal Status Priority Spectrum:
* Every analog input in PCS 7 APL possesses an integrated signal status (ST).
* MuxAn03 ranks signal states according to strict operational authority:
- Priority 1 (Highest): 16#80 (Good - verified process measurement)
- Priority 2: 16#60 (Simulation active)
- Priority 3: 16#28 (Bad, device-related - wire break, hardware fault)
- Priority 4 (Lowest): 16#00 (Bad, process-related - out of limits)
The Numerical Plausibility Comparison (PlDiff):
* Parameter PlDiff (Plausibility Difference) defines the maximum allowable deviation between any two sensor readings.
* The block evaluates three delta pairs:
- Delta_12 = |PV1 - PV2|
- Delta_23 = |PV2 - PV3|
- Delta_13 = |PV1 - PV3|
Arbitration and Selection Rules:
* Rule 1: All Plausible: If Delta_12 <= PlDiff and Delta_13 <= PlDiff with identical high-priority status, PV1 is output with that status (Lowest Index principle).
* Rule 2: Single Outlier: If PV1 drifts such that Delta_12 > PlDiff and Delta_13 > PlDiff, but PV2 and PV3 agree (Delta_23 <= PlDiff), the block isolates PV1 as faulty and outputs PV2 with good status.
* Rule 3: Status Mismatch with Plausible Values: If two values agree within PlDiff but have different quality codes (e.g., PV1 is 16#80 and PV2 is 16#60), the block outputs the value corresponding to the second highest priority status to maintain conservative tracking.
* Rule 4: Complete Plausibility Failure: If no two inputs agree within PlDiff, MuxAn03 sets PV.ST = 16#28 (Bad, device-related) and routes PV1 to PV.Value, raising a plausibility fault alarm.

Step-by-Step Implementation Procedure

Follow these procedures to configure and validate MuxAn03 in a triple-redundant transmitter circuit:

Instantiate Channel Drivers and MuxAn03 in CFC:
* In the CFC chart, place three Pcs7AnIn channel drivers corresponding to the three transmitters (e.g., PT_201A, PT_201B, PT_201C).
* Drag MuxAn03 (FB 1878) from APL > Channel or Math into the chart.
* Connect Pcs7AnIn_A.PV_Out to MuxAn03.PV1.
* Connect Pcs7AnIn_B.PV_Out to MuxAn03.PV2.
* Connect Pcs7AnIn_C.PV_Out to MuxAn03.PV3.
Parametrize Plausibility Difference (PlDiff):
* Open block properties on MuxAn03.
* Calculate the safe sensor tolerance band: accounting for transmitter calibration drift and measurement noise (e.g., set PlDiff = 2.0 bar or °C).
* Configure PlDiff on the block input pin.
Connect to Downstream Control Loop:
* Connect MuxAn03.PV (which includes both .Value and .ST) directly to PidConL.PV.
* Connect output PlFlt (Plausibility Fault) to an alarm block or Event block to notify operators if sensor disagreement occurs.
Compile and Download:
* Compile the S7 Program with 'Changes only' and download to the AS controller in RUN.

Verification

Test plausibility evaluation in CFC test mode. Apply identical inputs: PV1 = 50.0, PV2 = 50.2, PV3 = 50.1 (all within PlDiff = 2.0). Verify that PV.Value = 50.0 and PV.ST = 16#80. Force PV1 = 65.0 (outlier). Confirm that MuxAn03 seamlessly switches its output to PV2 = 50.2 with PV.ST = 16#80, isolating PV1. Force all three inputs apart (50.0, 60.0, 70.0); confirm that PlFlt asserts and PV.ST degrades to 16#28 (Bad).

Limitations and Operational Precautions

Do not set PlDiff narrower than the inherent measurement uncertainty of the field transmitters; an excessively tight tolerance will cause false plausibility trips during rapid process load swings. For safety instrumented systems requiring TÜV certification, use the dedicated fail-safe 2oo3 voter F_2oo3 rather than standard APL MuxAn03.

Engineer FAQ

Why does MuxAn03 select PV1 when all three inputs are healthy?

The block uses the 'Lowest Index' deterministic rule. If all inputs satisfy plausibility and share the identical highest quality status, PV1 is selected by default.

What does output pin PlFlt indicate?

PlFlt (Plausibility Fault) asserts TRUE when no two inputs agree within the configured PlDiff threshold, indicating sensor failure or severe calibration divergence.

Can MuxAn03 handle 4..20 mA transmitter wire breaks automatically?

Yes. If an input experiences a wire break, its Pcs7AnIn driver outputs status 16#28. MuxAn03 detects the bad status and votes between the remaining two healthy transmitters.

What is the difference between MuxAn03 and Med3_R?

Med3_R calculates the mathematical median of three numbers; MuxAn03 performs formal plausibility tolerance checking, quality code arbitration, and fault alarm generation.