Buffering WinCC Alarms with Timestamps After PCS 7 Comms Loss

1. Problem Statement

When the SIMATIC S7 AS (Automation Station) loses its S7 connection to the WinCC OS (Operator Station) or HMI, transient process messages and bit-triggered alarms generated during the outage window are not delivered. Without an application-level buffering strategy, those events appear "lost" to the operator when the link is restored, even though the PLC has preserved the original time of occurrence in its local clock.

This article documents the standard Siemens mechanisms to retain numbered process messages (ALARM_7B, ALARM_8P) and bit-triggered alarms during a WinCC–PLC communication loss, and to log them with their original timestamp once the channel is re-established. It also covers the companion "Communication fault" alarm that operators must see the moment the link drops.

2. Prerequisites

• SIMATIC PCS 7 V8.2 / V9.0 with WinCC Runtime (Classic) for ALARM_7B and the FB701 buffering pattern.
• OR SIMATIC S7-300 / S7-400 with TIA Portal V17 / V18 / V19 / V20 and WinCC RT Professional for ALARM_8P.
• An S7 connection configured between the AS and the OS / HMI — Industrial Ethernet (TCP/IP) per RFC 1006, or PROFIBUS with S7 Communication.
• WinCC Alarm Logging enabled on the OS / HMI project, with a configured message archive segment (circular log).
• Synchronized clock on the AS and OS — SIMATIC Time-of-Day Synchronization or NTP (RFC 5905) — with both ends set to the same time base (UTC recommended).

3. Message Numbering Fundamentals

Two families of alarm blocks are relevant to this discussion. They both implement the S7 "numbered message" concept: a message number is generated on the AS, the S7 Communication layer transmits it to the OS, and WinCC Alarm Logging matches the number to a configured text.

When the PLC is online and the S7 connection is healthy, WinCC receives every ALARM_7B / ALARM_8P message number in the order it is generated. The HMI's Alarm Logging engine appends the event to the running archive with the PLC's wall-clock time.

When the S7 connection drops, the S7 Communication layer on the AS queues pending acknowledgments and message-number transmissions in a small kernel-level buffer (typically a few hundred events). If the outage exceeds that buffer capacity, message numbers are dropped on the AS side, and WinCC can no longer reconstruct the missing events. The mitigation is an application-level FIFO buffer on the AS that retains message numbers and timestamps until the OS reconnects and drains them.

4. Buffering Process Messages with FB701 (PCS 7 ALARM_7B)

Siemens publishes a reference FB, FB701 "BufferFB", that wraps ALARM_7B and persists pending messages in a DB on the AS. A full demo project (SCL source + WinCC OS sample) is bundled with the PCS 7 example package "Buffering of Process Messages including Time Stamps with ALARM_7B", distributed via the Siemens Support portal (entry 29477737) and the PCS 7 V8.2 / V9.0 master data library.

The buffer principle:

1. ALARM_7B is invoked from your process logic (driver blocks such as CTRL_PID, MOT_SPEED, VALVE_ANA, or user FBs).
2. FB701 captures the call (event ID, state, timestamp, associated values) and writes it to a circular DB, named DB_WorkDB by convention.
3. FB701 monitors the S7 connection status to the OS — via the STATUS output of the BSEND / BRCV pair, or via UDT 65 in the PCS 7 connection DB.
4. When the connection is healthy, FB701 forwards the queued entry to ALARM_7B, which signals WinCC.
5. When the connection is down, FB701 holds the entry in DB_WorkDB with its original UTC timestamp from SFC1 (READ_CLK) or the time-stamped interrupt OB.
6. On reconnect (rising edge of the S7 connection status), FB701 drains the DB in FIFO order, calling ALARM_7B for each buffered message. WinCC receives them in chronological order with the original timestamp attached.

Implementation steps:

1. Open the PCS 7 master data library and copy FB701, DB_WorkDB, and the accompanying UDTs into your S7 program.
2. Adjust the FIFO size (default 256 entries) to match the worst-case outage × your message rate. Each entry is typically 32–64 bytes; size DB_WorkDB accordingly.
3. Replace direct calls to ALARM_7B in your process blocks with calls to FB701. The input interface is identical; the buffering parameters are added.
4. Compile and download the program to the AS. Verify the FB701 message numbers are reachable in the symbol table.
5. In WinCC Explorer, regenerate the OS via Compile OS so the message configuration imports the FB701 message numbers and the associated text strings.

5. Bit-Triggered Alarm Buffering (Generic S7 Approach)

If your alarming is purely bit-triggered (a BOOL edge in a data block is the alarm source) rather than going through ALARM_7B / ALARM_8P, you must add explicit buffering logic in user code. The principle is the same as FB701 but you own the buffer.

1. Capture the rising edge of the alarm bit in a latched BOOL or a FIFO of BOOLs with timestamps.
2. Store the original event time using SFC1 "READ_CLK" or a time-stamped DB entry written from OB35 (cyclic interrupt) or OB40 (hardware interrupt).
3. Hold the latched events in a retentive DB. The DB attribute is set under DB Properties > General > Retain.
4. On reconnect, replay the events to the HMI either as ALARM_8P calls (preferred — the operator sees a single message number with timestamp) or as a summary "Communication restored — N events buffered" message with a count tag.

The simpler engineering approach is to call ALARM_8P from the reconnect routine, generating one "Buffered: <description>" message per buffered event. Debounce upstream (edge detection, hysteresis on the analog source) to keep the count bounded during a noisy outage.

6. ALARM_8P Implementation in S7-300 / S7-400

The original question also asked about using the FB701 approach with ALARM_8 (SFB34). ALARM_8 is the simpler, non-parameterized predecessor of ALARM_8P (SFB35). For new work on S7-300 / S7-400 with TIA Portal or STEP 7, prefer ALARM_8P because it accepts a VARIANT pointer to instance-DB structures (UDT), enabling structured message texts and up to 10 associated values.

To wrap ALARM_8P with a buffer similar to FB701:

1. Define a UDT for the buffer entry: UDT_AlarmEntry with tTimestamp : DTL, dwMsgNo : DWORD, wState : WORD, and an array of 10 associated values as REAL / DINT / BOOL.
2. Instantiate a DB AlarmBuffer with N copies of the UDT and two INT pointers iHead / iTail.
3. Each alarm trigger calls a wrapper FB that writes the entry into AlarmBuffer.
4. A cyclic OB (OB1 or OB35) drains the buffer and calls ALARM_8P for each entry, gated by the S7 connection status.

SCL skeleton (STEP 7 / TIA Portal):

// SCL – Buffer wrapper for ALARM_8P
FUNCTION_BLOCK FB_AlarmBuffer
VAR
    pBuffer : POINTER TO ARRAY[1..256] OF UDT_AlarmEntry;
    iHead   : INT := 1;
    iTail   : INT := 1;
    bConnOK : BOOL;
END_VAR
BEGIN
    // Enqueue on event
    IF iEventTriggered THEN
        pBuffer[iHead].tTimestamp := tNow;     // filled by SFC1 READ_CLK
        pBuffer[iHead].dwMsgNo    := dwMsgNo;
        pBuffer[iHead].wState     := wState;
        iHead := (iHead MOD 256) + 1;
    END_IF;

    // Dequeue on healthy connection
    IF bConnOK AND (iHead <> iTail) THEN
        ALARM_8P(MSG_ID := pBuffer[iTail].dwMsgNo,
                 ID     := pBuffer[iTail].wState,
                 EV_ID  := dwEvID,
                 SE     := bSingle,
                 ACK    := bAckPending);
        iTail := (iTail MOD 256) + 1;
    END_IF;
END_FUNCTION_BLOCK

7. WinCC Alarm Logging Configuration

On the OS / HMI side, Alarm Logging must be configured to accept late messages and store them in the long-term archive. The behavior is documented in the TIA Portal help: Alarm Logging in WinCC RT Professional.

1. Open the HMI device configuration in TIA Portal and enable Alarm Logging in the runtime settings. For PCS 7 with WinCC Classic, this is on by default but verify in WinCC Explorer > Computer > Properties > Alarm Logging.
2. Configure the message classes and message types. Add a dedicated class Process Message — Buffered if you want to filter replay events in the Alarm Control view.
3. In the message archive settings, set the segment size and path. For PCS 7 with WinCC RT, the default circular archive is on the OS server. For RT Professional, the archive lives on the HMI device's local storage or a configured network share.
4. Set the time base to UTC if the AS synchronizes via NTP; otherwise match the AS clock's time base to avoid a 1-hour offset on DST transitions.

8. Loss-of-Communication Alarm Generation

Independent of buffering process alarms, operators must be informed that the S7 connection is down. The standard approach is to generate a "Communication fault" alarm on the OS by monitoring the connection status of the S7 channel.

On the AS side, the connection status can be evaluated in the connection DB (UDT 65 in PCS 7, or via the STATUS output of the BSEND / BRCV pair). On the OS / HMI side, WinCC exposes the connection status in the internal @ConnectionState tag group of the S7 channel. A value of 0 = OK, non-zero indicates a fault with a Siemens-specific error code (e.g., 0x0001 = connection not established, 0x0002 = partner not reachable, 0x000F = handshake failure).

Recommended implementation:

1. In the HMI tags, map the S7 connection status word to an internal HMI tag, e.g., HMI_Tag_PlcConnectionState.
2. Add a WinCC message of class System — Communication triggered by a value change to a non-zero state. Use a hysteresis tag or a one-shot edge to avoid flapping during transient link bouncing.
3. Set the Acknowledge requirement on this alarm so operators must confirm receipt of the comms-loss event.

For PCS 7, the OS project automatically generates "Connection failure" events from the S7 channel diagnostics; verify them in WinCC Explorer under Messages — System. The system message number is typically 1000000 series and uses the channel diagnostic word from the S7 driver.

9. Verification and Commissioning Tests

Validate the buffering configuration in a controlled scenario before plant acceptance. Capture the AS event log and the WinCC Alarm Control window side by side for each test.

1. Disconnect the Ethernet cable between the AS and the OS. Confirm the "Communication fault" alarm appears on the OS within 5–10 seconds (WinCC default channel diagnostic interval, configurable in the channel parameters).
2. While disconnected, trigger 3 process alarms on the AS (e.g., force a motor overload or a level-HH). Each event must be written to DB_WorkDB / AlarmBuffer with its original timestamp.
3. Reconnect the cable. Within one polling cycle, all 3 alarms must appear in WinCC Alarm Control in original chronological order, with timestamps matching the AS event log within 1 second.
4. Cycle power on the AS to confirm the retentive buffer survives an outage. Repeat the test: disconnect the cable, then power-cycle the AS, then restore cable. The buffered messages must still appear on the next connect.
5. Stress test: trigger 50 alarms per second for 2 minutes while the cable is disconnected. The buffer must not overflow, and the FIFO must drain in order on reconnect without losing or duplicating entries.

10. Troubleshooting Matrix

11. Performance and Sizing Notes

Buffer sizing rule of thumb: BufferSize ≥ MaxOutageSeconds × PeakMessageRate × 1.5. The 1.5× safety factor covers retransmission on partial reconnect and transient bursts.

For a plant that generates up to 50 alarms / minute at peak, and a worst-case outage of 30 minutes, the buffer must hold at least 50 × 30 × 1.5 = 2,250 entries.

FB701 default 256 entries is adequate for outage windows under 5 minutes at typical PCS 7 message rates. Increase to 1,024 for chemical / pharma processes with multi-minute communication interruptions from wireless access points, redundant OS fail-over, or scheduled maintenance windows.

For ALARM_8P with the wrapper pattern, each UDT_AlarmEntry is 32–64 bytes depending on the number of associated values. A 1,024-entry buffer requires 32–64 KB of work-memory and is fully retentive in the AS load memory.

12. Implementation Checklist

• FB701 (or equivalent wrapper) copied into the AS program, retentive DB sized for the worst-case outage.
• All process blocks call FB701 / wrapper — no direct ALARM_7B / ALARM_8P calls outside the wrapper.
• OS / HMI compiled after the block changes; message numbers regenerated.
• Alarm Logging archive configured with sufficient segment size; circular log path on a durable drive.
• AS and OS clocks synchronized to UTC; TIME_SYNC enabled on the S7 connection.
• Communication fault alarm configured in WinCC with hysteresis to avoid flapping.
• Commissioning test 1–5 from Section 9 executed and signed off.

13. FAQ