PROFINET Diagnostics Implementing Watchdog and Life Bit

Overview

Reliable detection of communication failures between a SIMATIC S7-1500 controller and its PROFINET IO devices is a baseline requirement for any safety-conscious, high-availability machine or process. Engineers traditionally hand-code a "life bit" — a one-shot pulse exchanged between the controller and each remote partner — and then trigger an alarm when the pulse stops toggling. While that approach still works, TIA Portal, the SIMATIC S7-1500 CPU firmware, and the PROFINET standard itself expose a much richer set of integrated diagnostics that, when used together, replace or augment a manual life bit and provide deterministic detection, root-cause data, and HMI visualization without extra wiring logic.

This tutorial consolidates the three official mechanisms Siemens exposes for PROFINET diagnostics: (1) the PROFINET update time and watchdog configuration on the IO controller interface, (2) the DeviceStates instruction and the IO system status that the CPU maintains internally, and (3) diagnostic alarms on distributed IO modules such as the ET 200AL, ET 200SP, and ET 200MP families. Each layer is mapped to TIA Portal navigation paths, the corresponding SFC/SFB/instruction calls, and the diagnostic buffer entries the CPU will produce on a fault. The article closes with a verification procedure and a troubleshooting matrix that maps LED states to root causes.

Prerequisites

• Controller: SIMATIC S7-1500 CPU, firmware 2.0 or later. The DeviceStates instruction requires firmware 2.0; the extended ModuleStates instruction requires firmware 2.6 or later. Reference the S7-1500 System Diagnostics entry ID 68011497 for the firmware-dependent instruction set.
• Engineering: TIA Portal V15.1 or later (V17/V18 recommended for current ET 200AL GSDML handling).
• IO devices: Any PROFINET-conformant device, e.g. ET 200SP (IM 155-6 PN), ET 200AL (IM 157-1 PN), ET 200MP, SINAMICS drives, or third-party PROFINET devices with GSDML import.
• Network: PROFINET switch infrastructure. Update times below 1 ms require IRT-capable switches and synchronized topology.
• HMI (optional):strong> SIMATIC HMI TP / Comfort / Unified panel for diagnostic visualization via the web server or TIA Portal HMI tags.

PROFINET Communication Diagnostics Architecture

PROFINET diagnostics stack in three layers. The first layer is the link layer: physical link, port LED state, and the LLDP topology the controller learns from the network. The second layer is the PROFINET IO channel: AR (Application Relationship) establishment, watchdog timing, and CR (Communication Relationship) state. The third layer is the application layer: process data quality, diagnostic alarms, and the user program reaction. The CPU's diagnostic buffer receives events from all three layers, and TIA Portal exposes them in Online & Diagnostics → Diagnostics buffer.

Watchdog behavior is part of the channel layer. The controller sends a PROFINET frame every UpdateTime. The IO device must respond within WatchdogTime (typically 3 × UpdateTime, configurable 1× to 192×). If no response arrives, the device drops the AR, sets its output process image to the configured fail-safe value (substitute / zero), and emits a PROFINET IO failure alarm that the CPU writes to the diagnostic buffer as event ID 0x001E (IO device failure). TIA Portal surfaces this as a red ERROR LED on the CPU and the device, and the same alarm is published on the PROFINET diagnostic interface for the HMI to read.

Configuring Update Time and Watchdog in TIA Portal

1. In the project tree, open Devices & networks and select the S7-1500 CPU.
2. Double-click the PROFINET interface in the device view to open the properties dialog.
3. Navigate to PROFINET interface → Advanced options → Real time settings → IO communication.
4. Set the Send clock (send cycle of the IO controller). Valid values depend on the CPU and the selected performance grade. For S7-1500 with Standard performance grade, valid send clocks are 1 ms, 2 ms, and integer multiples up to 4 ms. Reduced/increased send clocks down to 250 µs require IRT and the "High performance" PROFINET setting in the CPU properties.
5. Set the Update time for each IO device. The update time is an integer multiple of the send clock. TIA Portal will auto-size the update time to the minimum the device's GSDML permits; override only if you need to limit bus load.
6. Set the Watchdog time (factor of update time). The default is 3. Increase to 6–12 for wireless or routed segments where individual frame loss is tolerable.
7. Click OK and compile the project (Hardware > Compile) before downloading.

Implementing DeviceStates for IO System Monitoring

The S7-1500 maintains an internal status for every IO device, slot, and submodule. The DeviceStates instruction reads this state into a user-defined data area so the program can react to failures without polling the diagnostic buffer. The instruction lives under Instructions → Communication → PROFINET IO / PROFIBUS DP in TIA Portal. Equivalent function: SSL_IDX 0x0131 / 0x0132 / 0x0E41 via SFC 51.

STL/SCL call template (SCL):

// Returns the state of every IO device in the PROFINET IO system assigned to the head module
#iRetVal    : INT;            // Return value (0 = OK, 0x80xx = error)
#iState     : ARRAY[0..15] OF BOOL;  // Status bits, one per IO device index
#iLADDR_IO  : WORD := 100;    // HW ID of the PROFINET IO system (see device properties)

#iRetVal := "DeviceStates"(
    LADDR    := #iLADDR_IO,    // Logical address of the PROFINET IO system / DP master system
    MODE     := 1,             // 1 = state of IO devices, 2 = state of DP slaves, 4 = state of IO modules, 5 = state of submodules
    STATE    := #iState        // Destination area: receives 16 BOOL states
);

// MODE 1: each bit of STATE corresponds to one configured IO device.
// Bit = 1 means "device OK"; bit = 0 means "device failed, not configured, or wrong module".
// MODE 4: status of each IO module in the addressed station.

Bit-level interpretation of STATE (MODE = 1):

To convert the BOOL array into an aggregated alarm, the typical pattern is a flap detection: a bit must be 0 for at least two consecutive calls before the alarm is raised, and must be 1 for three consecutive calls before the alarm is cleared. This avoids nuisance trips on a single dropped frame.

System Diagnostic Blocks (SFC/SFB) for S7-1500

For more detailed root-cause data, the S7-1500 supports the legacy System Status List (SSL) and the new System Diagnostics. The block to read diagnostic records from a slot is RDREC (SFB 52 in S7-300/400, native instruction in S7-1500). The block to read the full PROFINET diagnostics record (slot 0, index 0x8000) is DPNRM_DG for PROFIBUS, or PNIOFRT / PNIO_REC for PROFINET.

Reading the diagnostic buffer of the CPU (SCL):

// Reads the most recent diagnostic buffer entries into #diagBuffer
// SFC 13 "DPNRM_DG" is the PROFIBUS variant; for PROFINET use RDREC on the CPU's own PROFINET interface.
// For S7-1500, the recommended way is the instruction "Gen_UsrMsg" plus the System Diagnostics display in the HMI/Web server.

"RDREC_DB"(        // Instance of SFB 52 "RDREC"
    REQ      := TRUE,
    ID        := 0,           // HW ID of the CPU's own PROFINET interface = 0 for self
    INDEX     := 16#8000,     // Standard PROFINET diagnostic record
    LEN       := 100,         // Buffer length to read
    RECORD    := #diagBuffer  // Destination byte array
);

For the HMI side, the S7-1500 web server exposes the diagnostic buffer at https://<cpu-ip>/diagnostic/buffer.html. The same data is available as system-defined HMI tags under HMI Tags → Show all tags → System diagnostics if the SIMATIC HMI is configured against the S7-1500 with the "System diagnostics" option enabled. Reference: Siemens manual "Network and Communication Diagnostics" (PDF).

Implementing a Life Bit Toggle in User Program

Where the application requires end-to-end liveness detection — for example, a master PLC synchronizing data with a partner PLC over PROFINET/PN-coupling, or a CPU monitoring a SINAMICS drive's Telegram — a dedicated life bit is still the most explicit mechanism. The implementation is two-directional: the local CPU toggles a bit in the output image, the partner CPU echoes it back in its own output image, and the local CPU compares the echoed value to the expected toggle pattern on every OB1 cycle.

SCL example — life bit generator and checker:

DATA_BLOCK "dbLifeBit"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
NON_RETAIN
   STRUCT
      toggle : BOOL;       // Output image bit sent to the partner
      echoIn : BOOL;       // Echo received from the partner
      echoLast : BOOL;     // Last echo value (for edge detection)
      tmr : TON;           // Monitors the period between valid echoes
      elapsed : TIME;      // Current elapsed time
      fault : BOOL;        // Latched life bit fault
   END_STRUCT;
END_DATA_BLOCK

FUNCTION_BLOCK "fbLifeBitCheck"
VAR
    tof : TIME := T#2S;    // Allowed silence window before fault
END_VAR
BEGIN
    // 1) Toggle the outbound bit every cycle (or on a fixed timer).
    "dbLifeBit".toggle := NOT "dbLifeBit".toggle;

    // 2) On every rising edge of the echo, restart the timer.
    IF "dbLifeBit".echoIn AND NOT "dbLifeBit".echoLast THEN
        "dbLifeBit".tmr(IN := FALSE);
        "dbLifeBit".tmr(IN := TRUE, PT := tof);
    END_IF;
    "dbLifeBit".echoLast := "dbLifeBit".echoIn;
    "dbLifeBit".elapsed := "dbLifeBit".tmr.ET;

    // 3) Latch a fault when the echo goes silent for > tof.
    IF "dbLifeBit".tmr.Q THEN
        "dbLifeBit".fault := TRUE;
    ELSIF "dbLifeBit".echoIn THEN
        "dbLifeBit".fault := FALSE;
    END_IF;
END_FUNCTION_BLOCK

Map dbLifeBit.toggle to the first spare bit in the PROFINET output area toward the partner, and read the echo from the corresponding input bit. The same FB is mirrored in the partner CPU, which sends the toggle back on its own output bit. For SINAMICS drives, the life bit can be carried in the free bits of the standard Telegram (PZD word 1, bit 15 is the standard "control word bit" placeholder) or a user-defined PZD word. Always reserve the life bit in a non-safety PZD; safety telegrams (PROFIsafe) have their own built-in watchdog and must not be modified.

ET 200 Distributed IO Diagnostic Alarms

Each ET 200 distributed IO module (IM 155-6 PN, IM 157-1 PN, IM 155-5 PN, IM 151-3 PN for ET 200AL, etc.) generates a diagnostic alarm for channel faults, module faults, and AR-loss events. For a complete list of diagnostic events and the corresponding record indices, refer to the device manual — for example, the ET 200AL CM 4xIO-Link manual collection (TIA Portal cloud docs) for the IO-Link master 6ES7147-5JD00-0BA0.

The CPU receives the diagnostic alarm and writes it to the diagnostic buffer. The user program can intercept the alarm in OB 82 (diagnostic alarm OB). The OB 82 start information provides the channel, the diagnostic event ID, and the IO flag byte, allowing a program to convert the alarm directly into an HMI message without polling.

OB 82 template variables (SCL):

// Temporary variables in OB 82
// laddr        : WORD    // Logical address of the slot that raised the alarm
// channel      : UINT    // Channel number within the module
// io_flags     : BYTE    // I/O flags (incoming/outgoing, diagnostic, manufacturer)
// diag_event  : WORD    // Diagnostic event ID
// multi_error : WORD     // Multiple-error flag

IF #io_flags.0 THEN   // Incoming diagnostic (bit 0 = 1)
    // Raise HMI message: "Channel fault, address &laddr, channel &channel"
    "HMI_Msg"(REQ := TRUE, ID := 1001, ARGS := #laddr);
END_IF;
IF #io_flags.1 THEN   // Outgoing diagnostic
    "HMI_Msg"(REQ := TRUE, ID := 1002, ARGS := #laddr);
END_IF;

If OB 82 is not programmed, the CPU remains in RUN and writes the diagnostic alarm only to the diagnostic buffer; HMI and web server visualize the event. If you want a stop reaction, the CPU properties → HMI & Web server → System diagnostics can be set to trigger an OB 82 with a configurable reaction priority.

Web Server Diagnostic Visualization

The S7-1500 web server (firmware 2.0+) ships with a diagnostics page that requires no user programming. Enable it in CPU properties → Web server → Activate web server on this module, and grant the appropriate user rights. The diagnostics page lists, in real time:

• Module status of every PROFINET device, slot, and submodule (color-coded green / red / gray)
• Diagnostic buffer entries with timestamp, event ID, and description
• Port-level statistics (frame counters, CRC errors, discards) for every PROFINET port
• Live I&M (Identification & Maintenance) data for each IO device

When a third-party OPC-UA client consumes the same data — for example, an Ignition gateway alarming on connection loss — the equivalent tag is the OPC-UA server's own connection status node, typically surfaced as Gateway/OPC/Connections/<connection_name>/Status or a vendor-specific quality code on the tag. The principle is identical: a loss of the underlying PROFINET AR is reflected as a quality flag on every tag whose path passes through the failed device.

Verification and Testing Procedures

1. Online compile and download the project to the CPU. Confirm Online & Diagnostics → Diagnostics status → All OK on the CPU.
2. Monitor DeviceStates in a watch table. With all devices healthy, every bit of STATE must be 1. Note the bit assignment: bit 0 = IO device index 0, bit 1 = index 1, etc.
3. Pull a PROFINET cable from a non-critical device (or set its port to "Monitored off" in the device properties for a simulated test). Within WatchdogTime × UpdateTime the corresponding bit in STATE must transition to 0, and the CPU diagnostic buffer must contain a new event with ID 0x001E ("PROFINET IO: IO device failure") and the slot number of the lost device.
4. Confirm OB 82 execution in the watch table for the OB 82 start info variables. If OB 82 is not loaded, the diagnostic buffer entry is still produced but no user-code action occurs.
5. Reconnect the cable. The AR must re-establish within a few seconds; the corresponding bit in STATE must return to 1; the diagnostic buffer must contain an "IO device returns" event.
6. Verify the life bit by reading the partner's echo bit and the local dbLifeBit.elapsed value. The elapsed time must reset to zero on every rising edge of the echo. Manually block the partner's update (set its PN interface to "off" via TIA Portal online) and confirm dbLifeBit.fault latches after tof elapses.

Troubleshooting Matrix

FAQ