S7 PLC Network and Device Diagnostics in STEP7 and TIA Portal

1. Overview

Siemens SIMATIC S7 PLCs expose a layered diagnostic architecture that begins at the CPU operating system and extends through the user program, HMI panels, OPC UA servers, and external network management systems. The capability is implemented through dedicated organization blocks (OBs), system functions (SFCs), system function blocks (SFBs), standard user FBs (notably FB 126), and the System Status List (SSL) that the CPU maintains in real time.

For STEP 7 V5.5 the diagnostic tools (SFC 51, SSL, FB 126) are described in the manual "Programming with STEP 7" (entry 45531107). For TIA Portal the equivalent for S7-1200/S7-1500 is the RDREC/WRREC record set approach combined with the structured PROFINET diagnostics of the integrated PN interface. Both ecosystems differentiate between diagnostic interrupts (asynchronous, OS-driven) and process interrupts (event-driven, process-related), a distinction that determines alarm handling, priority, and resource planning.

This reference covers:

• Diagnostic OBs and their triggering events
• Diagnostic alarm vs process alarm semantics
• SFC 51 (RDSYSST) and SSL partial list reference
• FB 126 (PROFIBUS/PROFINET diagnostics) usage
• PROFINET IO diagnostics in the user program
• PROFIBUS DP slave diagnostics with SFC 13 (DP_NRM_DG)
• Status data block for external monitoring systems
• SNMP integration for network monitoring (GET, SET, TRAP)
• Self-monitoring of the PLC's own port statistics
• HMI connection and WinCC diagnostic surface
• Commissioning procedure and verification
• Troubleshooting matrix for field use

2. Diagnostic OB Architecture in S7

The S7 CPU operating system calls diagnostic OBs when it detects specific fault or status events. These OBs run asynchronously to the cyclic program and are the foundation of all PLC-based fault detection. If the corresponding OB is not loaded, the system defaults to the behavior defined for that OB (typically STOP for OBs 80–87, 121–122).

2.1 OB 82 — Diagnostic Interrupt

OB 82 is the primary diagnostic OB for module-level and channel-level diagnostics. The local data contains the event identifier, the slot number, and pointers to the module's diagnostic data. Use SFC 13 (DP_NRM_DG) for PROFIBUS DP standard diagnostics, or call FB 54 (RALRM) for PROFINET IO to retrieve the full diagnostic record.

In TIA Portal, enable module diagnostics in the device view under Properties > Diagnostics > Channel diagnostics. The PROFINET IO module's record set 0x800A (multi channel diagnostics) is delivered to OB 82 on each event.

2.2 OB 86 — Rack/IO System Failure

OB 86 fires when a DP master system, a PROFINET IO system, or an expansion rack fails or returns. The local data includes the logical address of the master interface and the affected station/device number. The state-change bit is set on both the incoming (rack fails) and outgoing (rack returns) edge.

2.3 OB 121 / OB 122 — Program and I/O Errors

OB 121 reports programming errors (illegal pointer, range violation, BCD conversion error). OB 122 reports I/O access errors (module missing, access to a non-existent I/O address). Both are critical for detecting internal program quality issues that do not surface as I/O faults.

3. Diagnostic Alarms vs Process Alarms

3.1 Diagnostic Alarms

Diagnostic alarms report a state change in a module or field device that is not directly tied to a process value. They are always OS-driven and routed to OB 82 (with supporting OBs). Examples:

• Wire break on a digital input
• Short circuit on a digital output
• Module failure (ET 200S station loss)
• Channel overrange/underrange on an analog input
• Parameterization error on a PN device
• Hot-swap insertion/removal

3.2 Process Alarms

Process alarms report the result of a process event and are bound to a hardware-triggered condition:

• High-speed counter reaches a preset value
• Position limit reached on a TO axis
• PTO output completed
• Hardware-interrupt-triggered edge on a digital input (OB 40–47)

Process alarms are not fault indicators and do not, by themselves, justify an alarm acknowledgment flow in the HMI. They are bound to the controlled process and may occur during normal operation.

3.3 Resource Implications and Configuration

The two alarm classes are distinguished by the OB context and the local-data bytes that identify the source. In TIA Portal, the alarm configuration dialog separates "Diagnostic" from "Process" alarms and assigns different alarm classes (acknowledgment, severity, color) for HMI display. To prevent CPU overload during a fault storm:

• Group diagnostics by station to limit alarm volume
• Use SFB 35 (ALARM_8P) or SFC 105 (ALARM_S) sparingly; prefer PC-based alarm logging via WinCC
• Apply debouncing in the user program (only forward the rising edge of a fault)

4. System Status List (SSL) and SFC 51

The SSL is the CPU's internal mirror of system state. SFC 51 (RDSYSST) reads partial lists of the SSL into a destination data area. It is the only mechanism for reading the SSL from the user program and is available on both STEP 7 V5.5 and TIA Portal. The full list of supported SSL partial lists and record layouts is described in the manual "Programming with STEP 7 V5.5" (entry 45531107).

4.1 SFC 51 Call Interface

CALL SFC 51 ("RDSYSST")
 REQ        := TRUE
 SZL_ID     := W#16#0091  // example: module diagnostic data
 INDEX      := W#16#0000
 BUSY       := #SZL_BUSY
 SZL_HEADER := #SZL_HDR
 DR         := P#DB100.DBX0.0 BYTE 200
 RET_VAL    := #RET

The destination area must be at least 200 bytes; the actual length is returned in the SZL_HEADER record (bytes 0–1 of the destination). The SZL partial list layout begins with a 2-byte SZL header followed by N data records.

4.2 SSL Partial List Reference

4.3 Reading PROFINET IO Device Status

// SCL example (TIA Portal)
"SZL_BUSY" := FALSE;
IF NOT "SZL_BUSY" THEN
    "RDSYSST_DB"(REQ := TRUE,
                 SZL_ID := W#16#0121,        // Status of all PN IO devices
                 INDEX := W#16#0000,
                 BUSY := "SZL_BUSY",
                 SZL_HEADER := "SZL_HEADER",
                 DR := P#DB200.DBX0.0 BYTE 200,
                 RET_VAL := "RET_VAL");
END_IF;

The destination area receives a 2-byte SZL header followed by N records of 28 bytes each. Each record includes the device ID, slot, status, and fault information. Status byte values are 0 (OK), 1 (warning), 2 (error), 3 (missing/not reachable).

4.4 Reading the Diagnostic Buffer with SFC 59

CALL SFC 59 ("RD_REC")
 REQ        := TRUE
 IOID       := B#16#54          // local diagnostic buffer
 LADDR      := W#16#0000
 RECNUM     := B#16#0000        // entry 0 = latest
 RET_VAL    := #RET_VAL
 BUSY       := #BUSY
 RECORD     := P#DB500.DBX0.0 BYTE 32

Each 32-byte record contains the timestamp (8 bytes), the event ID (2 bytes), and the event text (20 bytes ASCII). To iterate over the buffer, repeat with RECNUM = 0, 1, 2, … until RET_VAL = W#16#80A0 (end of buffer reached).

5. FB 126 — Aggregated Bus State

FB 126 is a Siemens-published function block in the standard library for STEP 7 V5.5 that aggregates the diagnostic state of an entire PROFIBUS or PROFINET segment into a user-defined data block. The equivalent in TIA Portal is delivered as FB 126 "Diagnostic_FB" in the "Diagnostic Blocks" library.

5.1 FB 126 Interface

5.2 Example Call (STEP 7 V5.5 STL)

CALL FB 126, DB126
 MODADDR := W#16#7FFE    // Logical address of DP/PN master
 DIAG_DB  := P#DB200.DBX0.0 BYTE 200

The FB evaluates SSL partial lists 0x91, 0x92, 0xB1, 0xB2 internally and writes a flattened view into the user DB.

6. PROFINET IO Diagnostics in the User Program

PROFINET IO uses a record-based model where each device maintains a set of standard records accessible via acyclic services of the IO controller. The full reference is in the application example "PROFINET IO — Diagnostics Processing in the User Program" (entry 24000238).

6.1 PROFINET Record Set Reference

6.2 Reading Records with RDREC (SFB 52)

// Read I&M0 from a PROFINET device
"DPRDREC_DB"(REQ := TRUE,
            ID := 3,                  // Hardware identifier of the PN device
            INDEX := 255,             // I&M0 record index
            MLEN := 64,
            VALID := "VALID",
            BUSY := "BUSY",
            ERROR := "ERROR",
            STATUS := "STATUS",
            LEN := "REC_LEN",
            RECORD := P#"IM_DATA".DATA);

A STATUS of W#16#0000 with VALID = TRUE indicates a successful read. Common error codes:

6.3 FB 54 (RALRM) for Asynchronous Diagnostics

FB 54 (RALRM) is the recommended call in OB 82 to receive the complete diagnostic record. Unlike the OB 82 local data, FB 54 returns the full channel diagnostics with the correct record set and a structured interpretation.

// In OB 82
CALL "RALRM" (MODE := 1,                // 0=all info, 1=alarm info only
              F_ID := 0,                // Hardware identifier
              MLEN := 64,
              NEW := "NEW_DIAG",
              STATUS := "ALRM_STATUS",
              ID := "ALRM_ID",
              LEN := "ALRM_LEN",
              TINFO := P#"ALARM_TINFO".DATA,
              AINFO := P#"ALARM_AINFO".DATA);

The AINFO output contains the full channel diagnostic record starting with the PROFIdrive/PROFINET header, the slot, sub-slot, channel, and error specifiers. The TINFO output contains the slot information, the module state, and the timestamp.

7. PROFIBUS DP Slave Diagnostics

For PROFIBUS DP standard slaves, SFC 13 (DP_NRM_DG) reads the standard diagnostic data (6 bytes minimum) and the slave-specific diagnostics. The full sample application is in the entry "Determining and displaying failed DP slaves" (entry 6932419).

7.1 Standard DP Diagnostic Layout

7.2 SFC 13 Call

CALL SFC 13 ("DP_NRM_DG")
 REQ        := TRUE
 LADDR      := W#16#7FFE    // Logical address of the DP slave
 RET_VAL    := #RET_VAL
 BUSY       := #BUSY
 RECORD     := P#DB300.DBX0.0 BYTE 32

For DP-V1/V2 slaves, use SFB 52 (RDREC) to read acyclic record sets with INDEX 0x0000–0x7FFF for module and channel diagnostics. The full Siemens example describes how to evaluate bit 0 of byte 0 to detect a station failure and how to set the device state in a status DB.

8. Status Data Block for External Monitoring

A monitoring system outside the PLC (SCADA, plant historian, network management) needs a structured data block that the PLC maintains and that the external system polls over PROFINET, OPC UA, or a third-party protocol. The recommended approach is to maintain a status DB that mirrors the SSL view in a compact form.

8.1 Status DB Layout

8.2 Cyclic Update Logic

1. OB 1: Periodically (e.g., every 5 s) call FB 126 to refresh the bus state.
2. OB 82: Set the "Diagnostic interrupt active" bit and append the event to a ring buffer.
3. OB 86: Set the "Rack/IO system failure" bit; clear once the bus is restored.
4. OB 1: Pack the status DB into a 64-byte area and expose it via the process image or a PUT/SEND connection for the monitoring system.

For S7-1500 with OPC UA server enabled (T-CPU or firmware >= V2.0), the status DB can be exposed directly as an OPC UA method or dataset, eliminating a custom protocol.

8.3 Buffer Overflow Handling

The CPU's diagnostic buffer has a finite size (typically 320 entries for S7-300/400, 1024 for S7-1500). When it fills up, the oldest entries are overwritten. Set the "Diagnostic buffer overflow flag" when a new event ID indicates overflow and forward the flag to the NMS so it can request a full buffer dump.

9. SNMP Integration for Network Monitoring

When the S7 CPU has an integrated PROFINET interface (S7-300 with CP 343-1 Advanced, S7-400 with CP 443-1 Advanced, S7-1200 firmware >= V4.0, S7-1500), it can act as an SNMP agent (v1/v2c) and report port statistics of switches and managed devices to a higher-level NMS. The example "Monitoring and Control of Network Components with a SIMATIC S7-CPU (with PROFINET) and the SNMP functions GET, SET and TRAP" (entry 57249109) provides:

• FB SNMPv1_GET — request a single OID from a managed device
• FB SNMPv1_SET — write an OID
• FB SNMPv1_TRAP — send a trap to the NMS

The full reference is in the "SIMATIC NET Network management Diagnostics and configuration with SNMP Diagnostics Manual" (entry 103949062).

9.1 SNMP OIDs for PROFINET Port Statistics

9.2 SNMP Polling Logic in SCL

// Poll ifInErrors of port 1 of switch 192.168.1.10
"SNMP_GET_DB"(REQ := TRUE,
              IP_ADDR := 'C0A8010A'x,  // 192.168.1.10
              COMMUNITY := 'public',
              OID := '1.3.6.1.2.1.2.2.1.14.1',
              TIMEOUT := T#2S,
              BUSY := "SNMP_BUSY",
              ERROR := "SNMP_ERR",
              VALUE := "SNMP_VALUE");

For cyclic polling, place the call in a cyclic interrupt OB (OB 35 at 1 s) and store the values in a trend DB. TRAP processing uses the same FB family and triggers on OID transitions that the user defines (e.g., ifInErrors > 100).

9.3 SNMP Trap Configuration

Trap PDUs use UDP/162. The S7 client receives traps on UDP/162 and unpacks the varbind list. The trap destination IP is configured in the instance DB of FB SNMPv1_TRAP. For bi-directional monitoring, set the S7 IP as a static NMS entry on the managed switch and ensure the switch ACL allows UDP/161 (GET/SET) and UDP/162 (TRAP) from the S7 source IP.

10. Self-Monitoring of PLC Port Statistics

The PLC can monitor its own PROFINET port counters using SSL partial list 0x0F32 (port list) combined with internal counters. The relevant data is also exposed through the diagnostic buffer of the integrated PN interface.

10.1 Procedure

1. Use SZL_ID = W#16#0F32 to read the list of all PN ports of the local interface.
2. For each port, the record contains the port index, link state, speed, and a flag indicating whether the port counter is supported.
3. Where supported, read the port's internal counters via record set 0x802A or the local port statistics block in the CPU web server.
4. Store the delta between two polling cycles in the status DB and report to the NMS.

10.2 S7-1500 Native Web Server Diagnostics

For S7-1500 CPUs with firmware >= V2.0, the integrated web server exposes:

• Diagnostics > Module state
• Diagnostics > Diagnostic buffer
• Diagnostics > Port statistics (1 s, 1 m, 1 h, 24 h graphs)

A separate PLC application can call the WebRead (SFC 99) function to retrieve the same data in JSON format and feed it into the user program. The web server can be configured to push diagnostics to a configurable URL via the "Web API" feature, which uses JSON over HTTPS.

11. HMI and WinCC Diagnostic Surfaces

An HMI panel or a WinCC Runtime is typically the first diagnostic surface the operator sees. Several integration patterns are available.

11.1 Connecting an HMI (e.g. OP177B 6" Mono)

For an OP177B connected to a SIMATIC S7-300/400 PLC over MPI/Profibus, the HMI connection is set in WinCC Flexible / TIA Portal under Connections. The most common cause of "not connected" is a mismatch between the HMI connection name and the PLC's PG/PC interface. Verify the following:

1. The MPI/Profibus address of the HMI must be unique on the segment (default 1 for HMI, 2 for PLC).
2. The baud rate must match (default 187.5 kbit/s for MPI, 1.5 Mbit/s for Profibus DP).
3. The bus terminator must be set on both ends of the segment.
4. The PLC must have an empty MPI/Profibus interface available for the HMI (some CPUs share the same port with the programming device).

11.2 WinCC Alarm Logging

In TIA Portal, configure alarm classes under HMI tags > Alarm classes. Diagnostic alarms from OB 82 should be mapped to the "Error" class with acknowledgment, and process alarms to the "Warning" class without acknowledgment. WinCC logs each alarm with the timestamp from the PLC's diagnostic buffer.

11.3 WinCC Unified and OPC UA

For S7-1500 with WinCC Unified (V16+), the OPC UA server of the CPU exposes the status DB directly. A user-defined data type (UDT) on the WinCC side is automatically generated from the OPC UA browse, eliminating the need to map each tag manually.

12. PROFIBUS vs PROFINET Diagnostic Differences

The SNMP and topology discovery differences are covered in detail in the "SIMATIC NET Network management Diagnostics and configuration with SNMP Diagnostics Manual" (entry 103949062).

13. Commissioning and Verification

13.1 Prerequisites

• STEP 7 V5.5 SP2 or higher, or TIA Portal V13+ with the corresponding CPU firmware
• For PROFINET: PN-enabled CPU or CP (S7-300 with CP 343-1 Advanced, S7-400 with CP 443-1 Advanced, S7-1200 V4.0+, S7-1500)
• For SNMP: SNMP-capable managed switches with a public community string
• Online connection to the CPU for SZL reads during commissioning
• The example project libraries imported into the program

13.2 Step-by-Step

1. Load all required diagnostic OBs into the CPU (OB 82, OB 83, OB 85, OB 86, OB 100, OB 121, OB 122).
2. Insert FB 126 in OB 1 and connect MODADDR to the logical base address of the master interface.
3. Create a status DB and call SFC 51 in OB 1 to populate the SZL views (recommend at 500 ms cycle).
4. Add FB 54 (RALRM) in OB 82 to capture the full record on each interrupt.
5. For PROFINET, enable module-level diagnostic interrupts in the device configuration of each module.
6. For SNMP, import the FB SNMPv1_GET from the Siemens example and call it in OB 35.
7. Wire the status DB to an OPC UA server tag set (S7-1500) or a PUT connection (S7-300/400) to expose it to the NMS.
8. Compile and download.

13.3 Verification Tests

1. Wire break: Force a wire break on a digital input and verify that OB 82 fires, the status DB is updated, and the OPC UA tag changes.
2. Device loss: Disconnect a PROFINET device and verify that OB 86 fires, the per-device state byte goes to 0x03 (missing), and the SNMP trap is received.
3. Diagnostic buffer: Use the CPU's diagnostic buffer view (online > diagnostics > buffer) to confirm the same event is logged.
4. External polling: Send a diagnostic buffer query from the NMS and verify that all events are time-stamped and sequential.
5. Resource check: Check the OB priority and resource consumption using the "Resources" tab in the CPU online view. OB 82 priority should be set between 16 and 24 to allow the cyclic OB 1 to continue.
6. OPC UA browse: Open UaExpert and browse the S7-1500 OPC UA server, verify the status DB tags are present and update on event.

14. Troubleshooting Matrix

15. Best Practices

• Export the diagnostic buffer (SFC 59 RDREC for S7-300/400, native view in TIA Portal) periodically to the plant historian.
• Apply a time-stamp reconciliation (PLC time vs NTP) to allow cross-system event correlation. Use the S7-1500 NTP client to avoid drift.
• Limit the buffer query to the last 100 entries to avoid CPU overload.
• Configure an OB 82 priority of 17 and an OB 86 priority of 19 in the CPU properties to ensure that diagnostic and rack-failure events are processed before cyclic tasks but after time-critical OBs.
• Use maintenance records (0xF00A) for "demand/required" events that are not critical but indicate upcoming service actions.
• For PROFIsafe devices, do not forward diagnostic records to the safety logic; process them only in the standard user program.
• For S7-1500 with firmware >= V2.5, prefer the System Diagnostics (RD_SINFO / Get_IM_Data) UDTs in the IEC system library over the legacy SZL approach.
• Document the per-device state byte mapping in the project documentation so the NMS team can interpret the status DB without consulting the PLC program.

16. Conclusion

A complete PLC-based diagnostic and network monitoring system on S7 uses three layers:

1. Module- and bus-level diagnostics through OB 82, OB 86, and the SSL via SFC 51.
2. Aggregated bus state through FB 126 and a user-defined status DB.
3. External visibility through OPC UA, PUT, or SNMP, depending on the NMS platform.

The same architecture works for both STEP 7 V5.5 and TIA Portal, with the difference that the latter consolidates block libraries, the device configuration, and the web-server diagnostics in a single tool. For S7-1500 firmware >= V2.5, the System Diagnostics UDTs and the OPC UA server provide a more compact alternative to the legacy SZL approach. The diagnostics described here, combined with the SNMP and web-server interfaces, deliver the equivalent of a SCADA-style monitoring surface without a dedicated monitoring workstation.

FAQ