Reading S7-1500 Safety Mode Status from Non-Safety Program

Overview

On a SIMATIC S7-1500F CPU (for example CPU 1511F-1 PN, CPU 1515F-2 PN, CPU 1516F-3 PN/DP, CPU 1517F-3 PN/DP, CPU 1518F-4 PN/DP), the safety program runs inside an F-runtime group. During engineering and first-stage commissioning, an F-CPU can be operated with safety functions deactivated so that program changes can be downloaded in RUN. Production must never start in that state, so the standard (non-safety) user program must be able to detect whether the safety program is active, passivated, or disabled, and surface this state to the operator via HMI and alarm logging.

Three independent mechanisms are available:

1. F-runtime group status tags – a structured tag block exposed by TIA Portal that reflects the live state of each F-runtime group; directly readable from the standard user program.
2. Diagnostic interrupt handling via OB82 – fires when an F-module changes its diagnostic state, is passivated, or is reassigned.
3. Diagnostic buffer evaluation – the CPU stores safety-mode change events that can be read on demand with RDSYSST (SFC51) or via the web server / TIA Portal information API.

This reference describes all three mechanisms, the relevant tag layout, code samples in LAD and SCL, the HMI configuration, and the verification procedure you should run before handing the cabinet over to production.

Prerequisites

F-Runtime Group Status Tags

The most direct method. TIA Portal automatically creates a structured status block for each F-runtime group. The tag is configured under Safety Administration > F-Runtime Group > Properties > F-Runtime Group Status. Enable the option "Generate status for F-runtime group" and assign a name (default F_RTG1_STATUS).

The generated status is a WORD or DWORD with the following bit layout (firmware-dependent; values shown correspond to firmware V2.9):

The status tag is declared as a standard-accessible variable, so a normal BOOL read from OB1 works without any F-knowledge. Sample SCL snippet for OB1:

// "SafetyModeActive" TRUE only when runtime group is RUN
// and safety is not deactivated, no passivation, no error.
IF "F_RTG1_STATUS".RTG_RUN
   AND NOT "F_RTG1_STATUS".RTG_SAFETY_DEACTIVATED
   AND NOT "F_RTG1_STATUS".RTG_PASSIVATED
   AND NOT "F_RTG1_STATUS".RTG_ERROR
THEN
    "SafetyModeActive" := TRUE;
    "SafetyModeAlarm"  := FALSE;
ELSE
    "SafetyModeActive" := FALSE;
    "SafetyModeAlarm"  := TRUE;
END_IF;

If you have multiple F-runtime groups (typical with two F-runtime groups for redundancy or splitting standard and process safety), repeat the same logic for F_RTG2_STATUS, F_RTG3_STATUS, etc.

Diagnostic Interrupt via OB82

OB82 fires whenever an F-module's diagnostic state changes – for example when safety inputs are passivated, when an F-DO channel is forced, or when the module detects an internal diagnostic event. The local temporary variables of OB82 provide the slot, event type, and channel diagnostics of the affected module.

Use OB82 to:

• Set a sticky BOOL flag (e.g. SafetyIOEvent) that the standard program can poll.
• Write the offending logical address into an array so the operator can see exactly which F-channel went into passivation.
• Trigger an HMI alarm using ALARM_8P or the newer Program_Alarm with the affected module address concatenated into the alarm text.

// OB82 - Diagnostic Interrupt
#lError := #OB82_FLT_ID <> 0;
IF #lError THEN
    // Capture address and fault code
    "diagEvent".mdlAddr := #OB82_MDL_ADDR;
    "diagEvent".channel := #OB82_CHANNEL;
    "diagEvent".fltId   := #OB82_FLT_ID;
    "diagEvent".eventTs := RTM_T_RETCODE_OF_RUNTIME; // optional timestamp

    // Increment event counter for HMI
    "SafetyEventCount" := "SafetyEventCount" + 1;

    // Raise HMI alarm via Program_Alarm (TIA V17+)
    "instProgramAlarm"();
END_IF;

Diagnostic Buffer Evaluation

The CPU's diagnostic buffer contains a chronological list of events, including safety-related ones. Read entries with RDSYSST (SFC51) using SSL ID W#16#0132 for the partial list or W#16#00B2 for the diagnostic buffer.

The relevant event IDs for safety mode transitions (from the Siemens "SIMATIC S7-1500F System Manual"):

Sample call:

// Read last 10 diagnostic buffer entries
iRet := RDSYSST(REQ := TRUE,
                SSL_ID := W#16#0132,
                INDEX := 0,
                LEN := 80,
                BUSY := xBusy,
                SZL_HEADER := sHeader,
                DR := aDiagBuf);
IF NOT xBusy AND (iRet = 0) THEN
    FOR i := 1 TO 10 DO
        IF aDiagBuf[i].EventID = W#16#9F12 THEN
            // Safety was JUST deactivated - log to HMI
            "HMI_SafetyDeactivated" := TRUE;
        END_IF;
    END_FOR;
END_IF;

For real-time alarming without polling, prefer the OB82 mechanism; use the buffer only for forensic logging (audit trail) of when safety mode was toggled.

Passivation Status Per Channel

Each F-module exposes a per-channel passivation bit. You can query the status via:

• RDREC (SFB52) reading record index 0x8000 (F-I/O passivation status) from the F-module's slot.
• The VALUE_STATUS tag automatically generated by TIA Portal for ET 200SP F-modules. The bit QUALITY = bad indicates a passivated channel.

Useful for HMI screens that color-code individual channels:

// F-DI 16x24VDC HF (slot 4), base address 100
// Read record 0x8000 once per OB1 cycle for passivation bitmap
iRet := RDREC(REQ := TRUE,
              IOID := 0,
              LADDR := 100,
              RECNUM := 16#8000,
              RET_VAL := iRetVal,
              BUSY := xBusy,
              RECORD := aRec);

F-Signature Verification

Every F-runtime group has a 32-bit F-signature computed at compile time. If a programmer downloads a modified safety program without re-validating the F-signature in TIA Portal, the F-runtime group enters an error state. You can mirror the expected signature into a standard DB at compile time and compare it at runtime:

// Compile-time constant from TIA Portal "Safety > F-Signature"
#ExpectedSig := 16#A1B2_C3D4;
IF "F_RTG1_STATUS".RTG_SIGNATURE_OK
   AND ("ActualSignature" = #ExpectedSig)
THEN
    "SignatureValid" := TRUE;
ELSE
    "SignatureValid" := FALSE;
END_IF;

This is independent from the OB82 mechanism and catches the case where someone re-flashed the safety project without coordinating with operations.

HMI Configuration and Alarm Generation

Create the following HMI tags in WinCC / Unified Comfort:

Configure two HMI alarms:

1. Alarm 1 – "Safety mode deactivated", class "Error", triggered by rising edge of SafetyModeAlarm. Text must include the actual reason: 'Safety runtime group 1 is not active (RTG_RUN=0 / SAF_DEACT=1). Production lockout engaged.'
2. Alarm 2 – "F-I/O passivation", class "Warning", triggered by rising edge of SafetyEventCount. Include channel from diagEvent.mdlAddr and diagEvent.channel.

For Unified Comfort Panels use the Program_Alarm instance for fully dynamic alarm text with embedded module address and channel number.

Commissioning Sequence and Verification

Validate the detection logic before you allow the line to enter production:

1. Compile the F-runtime group, note the F-signature, store it in ExpectedSig.
2. Download both safety and standard program. In TIA Portal, go online and verify that F_RTG1_STATUS.RTG_RUN = TRUE and RTG_SAFETY_DEACTIVATED = FALSE.
3. Force SafetyModeActive via the watch table to FALSE – confirm that HMI alarm 1 appears with the correct text and that any production-start permissive tied to SafetyModeActive is blocked.
4. In TIA Portal, choose Safety > Deactivate safety mode for the F-runtime group. Confirm that RTG_SAFETY_DEACTIVATED becomes TRUE and the alarm fires within one OB1 cycle.
5. Pull an F-DI module or disconnect the PROFIsafe cable to an ET 200SP station. Verify OB82 triggers, SafetyEventCount increments, and alarm 2 appears with the correct module address.
6. Reconnect / rein – confirm the outgoing diagnostic also fires (clear the alarm message manually if your HMI is configured to auto-ack).
7. Re-activate safety mode in TIA Portal, perform a signature acceptance download, and verify SafetyModeActive returns to TRUE and the alarm clears.

Troubleshooting Matrix

Safety-Program Constraints You Cannot Bypass

The standard user program can read safety state but cannot modify it. The following are enforced by the F-CPU regardless of your logic:

• You cannot set RTG_RUN or RTG_SAFETY_DEACTIVATED from a standard FB/FC.
• You cannot write to F-DB variables except through the F-block interfaces.
• You cannot acknowledge passivation of an F-channel from the standard program – only the F-runtime group itself can reintegrate.
• Modifying the standard program does not require an F-signature acceptance; modifying the safety program does.

See the Siemens manual collection for the F-CPU family at the official TIA Portal help and the F-CPU system manual for full rules on what is and is not accessible across the safety boundary. A documented configuration reference for the disabling safety mode workflow is published at SIMATIC Safety: Disabling safety mode.

FAQ