Implementing a Watchdog Timer Freeze Detection in SIMATIC PCS 7 CFC Using DeadTime and CompAn02

To verify in SIMATIC PCS 7 Continuous Function Charts (CFC) that a cyclic watchdog timer signal continues to increment and has not frozen over a 10-second monitoring window, engineers can deploy the Advanced Process Library (APL) blocks DeadTime (FB1821) and CompAn02 (FB1817). By feeding the live watchdog signal into DeadTime configured with a dead time parameter of 10.0 seconds, the block outputs the signal value from exactly 10 seconds prior. The comparator block CompAn02 evaluates whether Live_Value > Delayed_Value. If the live signal fails to exceed the delayed signal, CompAn02 trips its boolean output to trigger an operator alarm. For optimal memory efficiency, this logic should execute in a 1-second cyclic interrupt task (OB38) rather than the high-frequency OB35 (100ms) task.

Watchdog Freeze Detection in Distributed Safety and Process Systems

In distributed process automation architectures, subsystems—such as third-party skids, remote RTUs, safety instrumented systems (SIS), and analyzers—frequently communicate heartbeats to the central PCS 7 automation system. A common failure mode in serial, Modbus, or Ethernet communication links occurs when a communication driver crashes while holding the last known value in memory ('frozen data' or stale registers).

If the watchdog signal simply increments a counter, verifying that the value is non-zero is inadequate; the engineering system must verify that the value is actively changing over time. Specifically, the value at time $t$ must be strictly greater than the value at time $t - 10\text{s}$. If the counter wraps around (e.g., 0-32767), overflow handling must also be incorporated.

APL Block Architecture: DeadTime (FB1821) and CompAn02 (FB1817)

The SIMATIC PCS 7 Advanced Process Library provides mathematical and signal processing blocks that solve this requirement graphically without requiring custom SCL code:

Block TypeBlock NumberKey ParametersFunction in Freeze DetectionDeadTimeFB1821In (Input signal), DeadTime = 10.0, SampleTimeBuffers incoming values in an internal ring array; outputs value delayed by 10sCompAn02FB1817In1 (Live signal), In2 (Delayed signal)Evaluates In1 > In2; asserts Out1 if condition met; asserts Out2 if frozenTimerPFB1856Ti (Timeout delay), In (Freeze condition)Provides alarm debouncing to prevent nuisance trips during counter rolloverEventTsFB1886In1 (Alarm bit)Generates time-stamped alarm message in WinCC Alarm Logging

By pairing DeadTime with CompAn02, the live incoming signal is compared against its own historical baseline continuously.

Step-by-Step Implementation and Cyclic OB Optimization

Execute the following configuration steps in the CFC editor:

Task Execution Optimization: The DeadTime block allocates an internal array size based on $N = \text{DeadTime} / \text{SampleTime}$. Executing a 10-second delay in OB35 (100ms) creates an array of 100 floating-point values ($10.0 / 0.1$). Executing in OB38 (1s) creates an array of only 10 values ($10.0 / 1.0$), saving memory and CPU execution cycles. Assign the chart to execute in OB38.
Instantiate DeadTime Block: Place DeadTime (FB1821) on the chart. Connect the incoming watchdog integer/real signal to DeadTime.In. Parameterize DeadTime.DeadTime = 10.0.
Instantiate Comparator Block: Place CompAn02 (FB1817) adjacent to DeadTime. Connect the live watchdog signal to In1. Connect the delayed output DeadTime.Out to In2.
Configure Overflow Handling: To prevent false alarms when an integer counter rolls over from maximum to zero, pass the frozen condition (In1 <= In2) through a TimerP block set to 3 seconds. A genuine freeze will persist indefinitely, while a rollover will clear on the very next sweep.
Link to Operator Annunciation: Connect the timer output to the CSF input of an equipment block or directly to EventTs to generate a high-priority 'Watchdog Frozen' alarm in WinCC.

Verification

Verify freeze detection operation using these testing procedures:

Normal Increment Validation: In online CFC test mode, supply an incrementing ramp signal to DeadTime.In. Verify that CompAn02.In1 > CompAn02.In2 and the alarm output remains 0 (healthy).
Freeze Simulation: Force the incoming watchdog signal to hold a static value. Observe that after exactly 10 seconds, DeadTime.Out catches up to In1.
Alarm Assertion: When In1 == In2, verify that CompAn02 drops its healthy output, the debouncing timer expires, and an alarm message appears in the WinCC alarm banner.

Limitations and Operational Precautions

When implementing watchdog timers with DeadTime, note these operational factors:

Counter Rollover: If the monitored counter is a 16-bit integer (0 to 32767) that rolls over to 0, In1 will temporarily be less than In2. Ensure a debouncing timer or delta calculation ($(In1 - In2) \neq 0$) is used if rollovers are frequent.
CPU Stop/Start Initialization: During CPU startup (OB100), the DeadTime internal buffer fills with default initial values. Use the block's initialization output to suppress alarms during the first 15 seconds after restart.
SampleTime Integrity: If the block is moved between OBs, recompile CFC to ensure SampleTime recalculates correctly.

Engineer FAQ

Can I use a simple timer block instead of DeadTime?

Yes. You can use an edge-detection pulse block (R_TRIG) that resets a timer whenever the counter changes. If the timer ever reaches 10 seconds without being reset, it indicates a frozen signal.

Why is DeadTime preferred over edge detection in some plants?

DeadTime directly verifies that the value is actively increasing, rather than merely fluctuating between two toggle states. It provides a robust continuous analog trend of rate-of-change.

Does the DeadTime block consume Process Objects?

No. Mathematical and utility blocks like DeadTime and CompAn02 do not possess the S7_m_c attribute and do not consume AS Process Object licenses.