PROFINET I-Device STOP: OBs Triggered on S7-1500 IO Controller

Problem Statement

When a Siemens SIMATIC S7-1500 CPU configured as a PROFINET I-Device is forced into STOP mode — by an operator, a programming device, an error, or a firmware restart — the higher-level IO Controller must detect the loss of valid process data. Engineers monitoring the controller's error OBs (OB82, OB83, OB86) frequently see no call even though the diagnostic buffer records a station failure or rack fault. The PROFINET documentation bundled with STEP 7 V13+ (TIA Portal) states that OB 86 fires for a station coming or going, but in practice the I-Device-to-STOP transition behaves differently from a pulled cable or a powered-down PROFINET slave. The link stays up, the Application Relationship (AR) remains active, and the failure surfaces only at the application layer. This article consolidates the exact OB behavior, identifies why OB 86 may not appear, and presents four engineering-grade detection methods that work on S7-1500 firmware V2.5 through V20. The reference documentation is the Siemens function manual PROFINET with STEP 7 V13 SP1 / V14 and the application note I-Device Function in Standard PN Communication.

PROFINET I-Device STOP Semantics

An I-Device is a PROFINET IO Device that is itself a PROFINET controller of a lower-level IO system, exchanging a defined set of process data with a higher-level IO Controller through configured transfer areas. Each transfer area is a contiguous block of bytes with a defined start address on both sides. The IO Controller owns the AR, schedules the cyclic data exchange, and consumes/provides the data. When the I-Device CPU transitions from RUN to STOP, the PROFINET stack on the I-Device continues to send frames to the IO Controller, but the application data is held at the last valid value or zero, depending on the "Behavior in STOP" property configured on the transfer area. From the IO Controller's perspective, the I-Device remains physically present on the network — the link is up, the device is exchanging watchdog and parameter frames, but the user data producer has stopped servicing the output area and is no longer updating the input area.

This distinction is critical. PROFINET differentiates three failure classes at the IO Controller:

• Station failure (cable pull, power loss): OB 86 fires in the IO Controller with EVT_CLASS = W#16##3931 (station failure incoming) and W#16##3961 (station return). The diagnostic buffer records a rack fault.
• Diagnostic interrupt (module-level error): OB 82 fires for each diagnostic event from a slot. The I-Device CPU itself may publish a "CPU in STOP" diagnostic record from its PROFINET interface, depending on firmware.
• I/O access error (peripheral fault during data access): OB 122 fires when user code reads or writes a transfer area while the I-Device is unreachable or in STOP and the slot's data validity flag is FALSE.

For an I-Device that goes into STOP while the PROFINET link remains active, the IO Controller's PROFINET stack does not always raise a station failure. Instead, the controller marks the slots as "data invalid" (provider stopped) and surfaces the condition only when user code attempts an I/O access. Engineers expecting OB 86 to fire for "any I-Device problem" are surprised when the IO Controller happily continues to read the last valid value from the PII.

OB Firing Matrix for I-Device STOP

Why OB 122 Does Not Fire on Optimized Block Access

The S7-1500 default data block model uses "optimized" access, where the compiler hides physical memory and the symbolic tag is resolved by the runtime system without a peripheral read. When the user code reads a transfer area symbolically (e.g., iDevice.InputWord0), the CPU copies the value from the input process image (PII) at the start of the cycle. If the I-Device is in STOP and the PII contains the last valid value, the read succeeds and OB 122 does not fire. The condition is not surfaced until either:

1. User code calls UPDAT_PI or UPDAT_PO explicitly, which returns an error code in RET_VAL, or
2. User code performs a direct peripheral access using the PEW / PAW / PED / PAD syntax on the I-Device slot's I/O address.

Optimized blocks do not prevent peripheral addressing — the misconception is that "optimized" and "symbolic peripheral" are mutually exclusive. Configure the I-Device's transfer area with the "Peripheral access" attribute visible (default in TIA Portal V16+), and use the peripheral address in the access expression. The block can remain optimized. The key is the access path, not the block attribute.

Prerequisites for Reliable Detection

Before implementing any detection method, confirm the following configuration items in TIA Portal:

1. IO Controller project compiled and downloaded. The device configuration must include the I-Device with its transfer areas and slot assignment.
2. Transfer area properties set correctly. In Devices & Networks > I-Device > Transfer areas, the "Update of process image" must be assigned to a process image partition (PIP) or to OB 1, depending on the chosen method.
3. Process image partition assigned to a cyclic OB. If you intend to call UPDAT_PI for a specific transfer area, the PIP must be assigned to the calling OB (e.g., OB 35).
4. All error OBs loaded. OB 82, OB 83, OB 85, OB 86, and OB 122 must each have a body in the IO Controller project, even if the body is empty.
5. I-Device CPU online and reachable. Verify the AR is established by inspecting the I-Device's online diagnostics > PROFINET diagnostics > Connection.

Detection Method 1: Peripheral Access to Force OB 122

The most direct way to guarantee OB 122 fires on I-Device STOP is to read the transfer area with a peripheral instruction. This forces the runtime to attempt a read from the I/O subsystem, which fails when the provider is in STOP and the data-validity flag is FALSE.

Structured Text (SCL) Example

// Force a peripheral read on the I-Device transfer area.
// If the I-Device is in STOP, the data is invalid and OB 122 fires.
#rawInputWord := "I-Device_InputArea".%IW0;

The .%IW0 syntax is a fully qualified access (FQA) in TIA Portal that compiles to a PEW read at runtime, regardless of whether the enclosing block is optimized. In the SCL editor, type the I/O variable name followed by .%IW0 for a 16-bit peripheral input read. For 32-bit, use .%ID0; for 8-bit, use .%IB0. For outputs, use .%QW0 / .%QD0 / .%QB0.

Inside OB 122, set a flag indicating the I-Device is unreachable. OB 122 provides the following start information in its temporary local data:

// OB 122 - I/O Access Error
// Latch a user flag and capture the address that failed.
"iDevice_FaultLatched" := TRUE;
"iDevice_LastFaultTime" := RD_SYS_T;
IF OB122_MEM_AREA = 1 THEN
  "iDevice_LastFaultIsInput" := TRUE;
ELSE
  "iDevice_LastFaultIsInput" := FALSE;
END_IF;
"iDevice_LastFaultAddress" := OB122_MEM_ADDR;

Performance Consideration

Reading the transfer area every cycle in the main OB 1 may add a few microseconds per access on an S7-1516 and can mask the failure window if the I-Device briefly toggles in and out of STOP. For a 1 ms cyclic task, place the peripheral access in a slower watchdog OB (e.g., OB 35 at 100 ms) and compare against the previous value to detect a stuck or zeroed input. The PERIPHERAL_READ instruction can be wrapped in a conditional execute on a cycle counter to reduce the call rate:

IF ("watchdog_cycleCounter" MOD 10) = 0 THEN
  "watchdog_rawInput" := "I-Device_InputArea".%IW0;
END_IF;

Detection Method 2: UPDAT_PI / UPDAT_PO with RET_VAL

The instructions UPDAT_PI (update process image of inputs) and UPDAT_PO (update process image of outputs) accept a mode parameter that targets a specific I/O region. They return a RET_VAL (WORD) of W#16#0000 on success or one of the standard PROFINET error codes on failure. The error codes 80A0, 80A1, 80B0, and 80B1 are the strong indicators of an I-Device-in-STOP condition.

Call these instructions in a slow cyclic OB (e.g., OB 35) to avoid burdening the main cycle. The high byte of RET_VAL is non-zero for any error. Save the LADDR of the failing area in a marker so an operator can identify which I-Device has stopped.

Ladder Logic Example (FBD equivalent shown)

NETWORK 1: Update I-Device input process image, evaluate RET_VAL
      CALL  "UPDAT_PI"
        LADDR  := 100          // Logical I/O start address of I-Device transfer area
        RET_VAL := "iDev_UpdateRetVal"
      NOP   0

NETWORK 2: Evaluate error
      L     "iDev_UpdateRetVal"
      SRW   8                 // Shift right by 8 (high byte to low byte)
      L     0
      <>I                    // If high byte <> 0, error present
      =     "iDevice_FaultLatched"

NETWORK 3: Capture specific error code for HMI display
      L     "iDev_UpdateRetVal"
      T     "iDevice_LastErrorCode"  // Word for HMI tag

Detection Method 3: DeviceStates Instruction

The DeviceStates instruction (available in S7-1500 firmware V2.0+) returns the operational state of a configured PROFINET device. Unlike the methods above, it does not require a peripheral access and works even with optimized symbolic reads. The instruction is part of the standard PLC program library and appears in the "PROFINET IO" folder in the TIA Portal instructions catalog.

// DeviceStates call - MODE 0 returns state of all configured IO devices
#iStatesRet := "DeviceStates_0"(
  MODE   := 0,
  LADDR  := 0,
  RESULT := "iDev_StateArray"
);

When the I-Device transitions to STOP, the device remains in the configured list and is reported as TRUE in some firmware versions, or FALSE in others. Cross-reference with a heartbeat to disambiguate. For per-device state, use MODE 1 (LADDR = logical address of the I-Device).

Note that DeviceStates reports the PROFINET AR (Application Relationship) state, not the application-level provider status. An I-Device with an active AR but a stopped CPU may be reported as OK by PROFINET and as stopped by your heartbeat. Use DeviceStates as a supplement, not a primary detector.

Detection Method 4: Heartbeat / Watchdog Bit

The most portable and platform-independent method is a heartbeat bit toggled by the I-Device's application code in a fast cyclic OB (e.g., OB 30 at 10 ms with a 50% duty cycle so the master sees a transition at least every 100 ms). The IO Controller monitors the bit and latches a fault if it does not see a transition within a defined window.

I-Device Side (SCL, cyclic in OB 30)

IF "heartbeat_toggle" THEN
  "iDevice_Heartbeat" := TRUE;
  "heartbeat_toggle" := FALSE;
ELSE
  "iDevice_Heartbeat" := FALSE;
  "heartbeat_toggle" := TRUE;
END_IF;

IO Controller Side (SCL, cyclic in OB 35 at 100 ms)

IF "iDevice_Heartbeat" = "heartbeat_lastValue" THEN
  "heartbeat_stuckCounter" := "heartbeat_stuckCounter" + 1;
ELSE
  "heartbeat_stuckCounter" := 0;
  "heartbeat_lastValue"   := "iDevice_Heartbeat";
END_IF;

IF "heartbeat_stuckCounter" >= 3 THEN
  "iDevice_FaultLatched" := TRUE;   // Three consecutive 100 ms cycles with no toggle
  "iDevice_FaultTimestamp" := RD_SYS_T;
END_IF;

This method is preferred for the following reasons:

• It detects both the I-Device STOP and the I-Device CPU hang (no OB 30 execution).
• It is unaffected by PROFINET diagnostic quirks or OB firing behavior.
• It works identically across S7-300, S7-400, S7-1200, S7-1500, and third-party controllers.
• The time-to-detect is bounded by the toggle period × 3, which is a tunable engineering parameter.
• It survives firmware updates that change the OB firing semantics.

Timing Diagram: Heartbeat Detection

Implementation Comparison

Process Image Partition (PIP) Configuration

For UPDAT_PI and peripheral access methods, the I-Device transfer area must be assigned to a PIP that is updated by the calling OB. The default PIP 1 (OB 1) updates every cycle. To use OB 35 (100 ms) as the watchdog OB, create a new PIP in TIA Portal:

1. Open Devices & Networks > select the IO Controller CPU.
2. Navigate to Properties > Process image partitions.
3. Click "Add new partition" and name it (e.g., PIP_iDevice_Watchdog).
4. Assign PIP_iDevice_Watchdog to OB 35 with an update rate of 100 ms.
5. Open the I-Device > Transfer areas > select the input area > Properties > Process image > assign to PIP_iDevice_Watchdog.
6. Compile and download. The transfer area is now updated only when OB 35 runs.

This separation allows the main OB 1 to read the I-Device at full speed for normal operation, while OB 35 handles the slower watchdog checks without impacting cycle time.

Safety and Process Implications

In safety-related applications (PROFIsafe over PROFINET), the I-Device STOP transition is handled by the PROFIsafe layer independently of the standard PROFINET I/O mechanism. The PROFIsafe driver on the IO Controller monitors the safety AR and raises a fail-safe state (substitute values = 0) within the PROFIsafe watchdog time (typically 100 ms to 500 ms). The methods described in this article do not replace PROFIsafe diagnostics; they are supplementary to it.

For non-safety process control, the recommended response to an I-Device fault is:

1. Latch the fault flag and timestamp.
2. Switch the process to a defined safe state (e.g., hold last value, drive outputs to 0, or transfer to a backup controller).
3. Annunciate the fault on the HMI with the I-Device's PROFINET device name, slot number, and the specific error code from RET_VAL or OB 122.
4. Require operator acknowledgment before resuming normal control.

Disabling the I-Device Function Programmatically

From TIA Portal V18 onward, the I-Device function can be disabled in the I-Device CPU's user program. This is documented in the TIA Portal V20 I-Device Programming Manual. The disable takes effect on the next STOP→RUN transition of the I-Device CPU. Once disabled, the higher-level IO Controller sees the I-Device as fully removed (station failure), OB 86 fires with W#16##3931, and the controller can respond with a defined fallback rather than the ambiguous "data invalid" state. This is the preferred method for orderly shutdown of an I-Device in a process where the I-Device is taken offline for maintenance.

Verification & Commissioning Steps

1. Load all error OBs. In TIA Portal, add OB 82, OB 83, OB 85, OB 86, OB 122 to the IO Controller project. Each must have a body, even if the body is empty. Compile and download.
2. Configure the I-Device transfer area with "Peripheral access" visible. In Devices & Networks > I-Device > Transfer areas, ensure the area is enabled for read/write and that the "Update of process image" is set per your detection method.
3. Force the I-Device into STOP. Use Online & Diagnostics > Stop CPU on the I-Device. Trigger the transition from the IO Controller side to verify OB behavior.
4. Inspect the IO Controller's diagnostic buffer. Look for rack fault (OB 86) and I/O fault (OB 122) entries. The event IDs and timestamps confirm which OBs fired.
5. Verify the UPDAT_PI RET_VAL. Monitor the RET_VAL in a watch table. A non-zero high byte (e.g., W#16#80B1) confirms the data-invalid state.
6. Test the heartbeat. With the I-Device in RUN, observe the IO Controller's heartbeat_stuckCounter cycling between 0 and 1. Force the I-Device to STOP and verify the counter increments to 3 within 300 ms.
7. Test the recovery path. Issue a RUN command to the I-Device. Verify all flags clear and the OB 86 station-return event (W#16##3961) appears in the IO Controller's diagnostic buffer.
8. Document the response time. Record the time between the I-Device STOP command and the fault flag latch on the IO Controller. For a 100 ms heartbeat window, expect 300 ms. For OB 122 on peripheral access in OB 1, expect 1–2 ms.

Troubleshooting Matrix

Cross-Platform Notes

The OB behavior described here is specific to the S7-1500 / S7-1200 generation running TIA Portal projects. On S7-300/400 with STEP 7 V5.x, the behavior is similar but the symbolic/peripheral distinction is less pronounced because classic STEP 7 uses absolute addressing by default. On ET 200SP CPUs, the same OB matrix applies because the runtime system is shared with the S7-1500 family.

Third-party IO Controllers (e.g., Allen-Bradley ControlLogix with PROFINET scanner, Beckhoff CX with PROFINET device) implement their own diagnostic mechanisms and do not use Siemens OBs. For mixed-vendor architectures, the heartbeat method is the only fully portable detection mechanism and is the recommended engineering practice.

HMI / Web Server Display

For operator visibility, expose the following tags on the HMI or via the CPU's integrated web server:

• iDevice_FaultLatched (BOOL): Master fault indicator.
• iDevice_LastErrorCode (WORD): Hex code from UPDAT_PI RET_VAL or OB 122 fault code.
• iDevice_LastFaultTimestamp (DTL): Time of the most recent fault.
• heartbeat_stuckCounter (INT): Current stuck count for diagnostics.
• DeviceStates_Result (ARRAY of BOOL): Per-device health from DeviceStates.

The S7-1500 web server can be configured under CPU Properties > Web server > User-defined pages to display these tags without an external HMI. This is useful for remote diagnostics in cabinet installations.

FAQ