Resolving Supervision Alarm Display on KTP 700 Basic Panels

Resolving Supervision Alarm Display on KTP 700 Basic Panels in TIA Portal V13

This technical reference addresses a documented field issue where supervision alarms generated inside an S7-1500 GRAPH sequence do not appear on the alarm view of a Siemens SIMATIC KTP 700 Basic panel configured with TIA Portal Professional V13 SP1 Update 2 and WinCC Basic SP1 Update 2. The article explains the architectural root cause, provides a fully working PLC-based workaround using a discrete alarm bit and alarm groups, and documents the verification steps required to confirm correct operation on the panel.

Problem Details

The reported symptom is that one or more supervision conditions declared inside an S7-1500 GRAPH FB (for example, interlock violation, step supervision timeout, or transition supervision) are evaluated by the CPU, the supervision bits toggle in the GRAPH instance DB, but no alarm text appears in the HMI alarm view on the KTP 700. The panel is online, the connection to the S7-1500 is established (no diagnostic buffer entries for connection loss), and standard discrete alarms that are wired directly from a global DB bit do display correctly.

The typical engineering environment is:

• Controller: SIMATIC S7-1500 (any CPU from CPU 1511-1 PN up to CPU 1518-4 PN/DP with firmware V1.8 or higher in the affected plants)
• HMI: SIMATIC KTP 700 Basic, 7-inch, PN interface, firmware V13 SP1 Update 2 or compatible
• Engineering: TIA Portal Professional V13 SP1 Update 2 with WinCC Basic SP1 Update 2 (engineering component for Basic panels)
• Sequence: S7-1500 GRAPH FB with step supervision and transition supervision configured

Root Cause Analysis

The root cause is a documented capability gap between the GRAPH FB on an S7-1500 CPU and the alarm engine of a WinCC Basic (Basic Panel) runtime. GRAPH publishes step supervision, transition supervision, and acknowledgment bits through the GRAPH instance DB and also exposes them through ALARM_S (alarm with associated value) and ALARM_D (alarm with acknowledge) system blocks. Those ALARM_S/ALARM_D messages carry an internal alarm numbering scheme.

WinCC Comfort/Advanced and WinCC Unified runtimes can interpret that alarm numbering scheme and render the GRAPH-derived messages directly in the HMI alarm view. The WinCC Basic runtime, however, does not support the alarm numbering procedure and therefore cannot subscribe to or render messages emitted by GRAPH FBs or by other blocks that require ALARM_S/ALARM_D numbering semantics.

Consequences on the KTP 700:

• GRAPH supervision alarms are dropped at the WinCC Basic alarm dispatcher
• The PLC's ACK_STATE, SS_STATE, SF_STATE, and SA_STATE GRAPH bits are still visible in online watch but no event is published to the HMI
• Alarm classes, alarm groups, and the alarm log on the Basic panel never receive the supervision event

Affected Hardware and Software Matrix

Solution Architecture

The robust workaround is to consolidate GRAPH supervision events inside the PLC user program and publish them to the HMI as discrete (bit-triggered) alarms. The PLC reads the GRAPH instance DB supervision bits, debounces them, builds a composite supervision alarm bit per condition, and exposes those bits in a global data block that the HMI polls through standard discrete alarm configuration.

The architecture has three logical layers:

1. GRAPH layer — step supervision, transition supervision, and acknowledgment flags are evaluated by the S7-1500 GRAPH runtime and stored in the GRAPH instance DB.
2. Adapter layer — a user FC (for example FC_GRAPH_AlarmAdapter) reads the GRAPH supervision bits, OR-combines them by severity class, sets one or more discrete alarm bits in a global DB (DB_HMI_Alarms), and clears them on positive acknowledgment.
3. HMI layer — the KTP 700 alarm view is configured to subscribe to the discrete alarm bits in DB_HMI_Alarms, render text from the HMI text library, and acknowledge them in groups.

PLC Program Implementation

Step 1: Create a global data block that exposes supervision alarm bits to the HMI.

DATA_BLOCK "DB_HMI_Alarms"
{ S7_Optimized_Access := 'TRUE' }
VERSION : 0.1
NON_RETAIN
VAR
   bGraphStepSupervision : Bool;   // any step supervision active
   bGraphTransSupervision : Bool;  // any transition supervision active
   bGraphInterlockError  : Bool;   // any interlock violation
   bGraphAckRequest      : Bool;   // operator requested acknowledgment
   iAlarmGroupActive     : Int;    // bitmask of currently raised groups
END_VAR
END_DATA_BLOCK

Step 2: Implement the adapter FC that converts GRAPH bits into the discrete alarm bits above. The example below uses the GRAPH instance DB IDB_Sequence from a typical S7-1500 GRAPH FB and exposes group bits 1..8.

FUNCTION "FC_GRAPH_AlarmAdapter" : Void
VAR_TEMP
   tAnySet : Bool;
END_VAR
BEGIN
   // --- Step supervision: OR of all step supervision flags ---
   "DB_HMI_Alarms".bGraphStepSupervision :=
       "IDB_Sequence".SS_STATE[1] OR "IDB_Sequence".SS_STATE[2]
    OR "IDB_Sequence".SS_STATE[3] OR "IDB_Sequence".SS_STATE[4];

   // --- Transition supervision: OR of all transition flags ---
   "DB_HMI_Alarms".bGraphTransSupervision :=
       "IDB_Sequence".SF_STATE[1] OR "IDB_Sequence".SF_STATE[2]
    OR "IDB_Sequence".SF_STATE[3] OR "IDB_Sequence".SF_STATE[4];

   // --- Interlock violation: ANY_ERROR bit ---
   "DB_HMI_Alarms".bGraphInterlockError := "IDB_Sequence".ANY_ERROR;

   // --- Group mask (1..8) used by alarm groups in HMI ---
   tAnySet := "DB_HMI_Alarms".bGraphStepSupervision
           OR "DB_HMI_Alarms".bGraphTransSupervision
           OR "DB_HMI_Alarms".bGraphInterlockError;

   IF tAnySet THEN
       "DB_HMI_Alarms".iAlarmGroupActive := 16#000F;
   ELSE
       "DB_HMI_Alarms".iAlarmGroupActive := 16#0000;
   END_IF;
END_FUNCTION

Step 3: Call the FC in OB1 (or in a cyclic OB30 if you need deterministic 100 ms refresh). The call must be unconditional so that falling edges are also captured by the HMI alarm engine.

HMI Alarm Configuration

Step 1: In the KTP 700 project tree, open HMI alarms > Discrete alarms. For each supervision bit, create a new alarm record:

Step 2: For each alarm, set the trigger to On rising edge so the alarm is announced when the bit goes high, and On falling edge so the outgoing state is logged. Confirm the alarm text length is ≤ 80 characters per line to remain within the Basic panel memory model.

Step 3: Wire the alarm view to render the alarm log. In the screen editor, drag an Alarm view object onto the supervision page and select the alarm classes Warnings, Errors, and System.

Acknowledging Multiple Alarms with Alarm Groups

Acknowledging multiple supervision bits at once is implemented through alarm groups. The Basic panel supports group acknowledgment at the panel level, and the operator can press Acknowledge on the alarm toolbar to clear every alarm in the selected group.

1. In the HMI project, open Runtime settings > Alarms > Alarm groups.
2. Create group Group 1 - Graph supervisions and assign the three discrete alarms created above.
3. Create group Group 2 - Acknowledgments and assign the acknowledgment alarm.
4. Confirm that Operator can acknowledge alarm groups is enabled.
5. For each discrete alarm, set Acknowledge model = Acknowledge by group.

On the panel, the operator selects one or more alarms and presses the group Acknowledge button. WinCC Basic resets the trigger tags through the standard write mechanism. If the PLC still drives the supervision bit high, the alarm reappears immediately; this is the correct behavior for a still-active condition.

Modernization Path: Comfort Panel or WinCC Unified

When the engineering scope allows hardware replacement, the cleanest long-term fix is to migrate from the KTP 700 Basic to a Comfort panel (for example TP700 Comfort) or to a Unified Comfort panel (for example MTP700 Unified). Both runtimes support the GRAPH alarm numbering procedure and can render GRAPH supervision events natively without an adapter FC.

For new projects, the recommended workflow on a Unified Comfort panel or Unified PC is to use ProDiag supervisions, which provide integrated plant diagnostics on the HMI without changes to the user program. Supervisions are configured in TIA Portal on the FB/FC and are automatically visualized on the HMI with detailed diagnostic views. The relevant official documentation is the Siemens TIA Portal Help for WinCC Unified: Basics of supervision with ProDiag (RT Unified).

Key differences to keep in mind when migrating:

• ProDiag supervisions are part of the program code of the PLC; they require no additional discrete alarm configuration in the HMI.
• ProDiag generates an integrated diagnostic overview that is automatically populated on the HMI; no manual wiring of trigger tags is required.
• On Unified Comfort panels, the alarm view supports ProDiag supervisions natively; on WinCC Unified PC Runtime the same supervision objects are available with extended detail views.
• GRAPH on S7-1500 still emits ALARM_S/ALARM_D messages that Unified runtimes interpret directly; the adapter layer is therefore not required when the target is Unified.

Verification Procedure

After downloading the project to the PLC and HMI, perform the following verification sequence on the live plant or on a PLCSIM Advanced simulation:

1. Online connection check: On the panel, open Diagnostics > Connection and confirm the S7-1500 connection shows status Connected. No yellow or red indicators.
2. Tag visibility test: In WinCC Basic online, force the bit DB_HMI_Alarms.bGraphStepSupervision to TRUE. The corresponding alarm text Step supervision active must appear in the alarm view within one refresh cycle (default 1 s).
3. Edge test: Reset the forced bit. The alarm must transition to the outgoing state with timestamp and remain visible until acknowledged.
4. Group acknowledge test: Force all three supervision bits. Open the alarm view, select one alarm in group 1, press Acknowledge group. All alarms in group 1 must transition to acknowledged.
5. GRAPH interlock test: Trip a real interlock condition in the running GRAPH sequence. The alarm Interlock violation must appear automatically without manual forcing.
6. Alarm log test: Open the alarm log on the panel and confirm that all incoming and outgoing events are recorded with date, time, and status.
7. Power-cycle test: Power-cycle the panel while the alarm bit is high. On restart, the alarm must reappear in the alarm view because the trigger tag is reread from the PLC on each connection establishment.

Troubleshooting Matrix

Engineering Best Practices

• Treat the adapter FC as a fixed part of every project that uses GRAPH on a Basic panel. Document the mapping from GRAPH instance DB bits to DB_HMI_Alarms in the project comment.
• Keep one global alarm DB per CPU. Centralizing the alarm tags simplifies HMI configuration and reduces the number of connections the panel must open.
• Use distinct alarm groups for supervision alarms, operator prompts, and system messages. This gives the operator a clean separation during acknowledgment.
• Limit the number of active alarms per screen to 50 or fewer to stay within the recommended alarm throughput for a KTP 700 Basic.
• If the plant will be modernized to Comfort or Unified within the lifecycle of the equipment, structure the adapter FC so that its discrete outputs can be replaced by ProDiag supervisions without changing the PLC alarm interface.