WinCC Advanced Alarm Logging: StateAfter and Process Values

1. Problem Definition and Engineering Goal

Pharmaceutical, water/wastewater, and food-and-beverance plants governed by FDA 21 CFR Part 11, EU GMP Annex 11, or ISA-88 batch standards require the HMI to log both the incoming and outgoing timestamps of every operator-relevant alarm. In addition, when the alarm is generated by an analog limit violation (high/low/high-high/low-low), the engineer must record the actual process value that triggered and the process value that cleared the condition. The legacy approach of using a single Dword bit-mapped word on the PLC and toggling a corresponding HMI tag produces only the arrival event; the cleared event is invisible to the operator and to the audit log.

This reference details a working configuration on a SIMATIC TP900 Comfort panel running WinCC Advanced V13 SP1 with an active Audit Trail runtime license. It explains:

• How the integrated alarm archive captures the StateAfter column and how to interpret its values.
• How to embed a live process variable in the alarm text so the recorded value travels with the event.
• How to size the archive, locate the on-board CSV file, and export it for external review.

2. Prerequisites and Licensing

3. Alarm Architecture in WinCC Advanced V13 SP1

WinCC Advanced groups alarms into three classes: Discrete, Analog, and User-defined. Discrete alarms are driven by a single PLC bit transition; analog alarms are derived from an HMI tag that crosses a configured high/low threshold; user-defined alarms are constructed in scripts or function blocks. For an application that mirrors a PLC Dword bit (your existing approach), you will use the Discrete class. For a high/low analog limit that needs the actual process value, the Analog class is the correct target because it natively supports the limit text and a bound value tag.

The runtime state machine of an alarm, valid since WinCC Comfort/Advanced V11 and unchanged in V13 SP1, is conceptually identical to the WinCC Unified alarm states model: an alarm is Active when the trigger condition is fulfilled, Cleared when the trigger condition is released, and Acknowledged when an operator presses ACK. Each transition generates a record in the alarm archive.

4. Configuring Discrete Alarms with PLC Bit Triggers

1. In the TIA Portal project tree, expand your_HMI > HMI alarms > Discrete alarms.
2. Right-click Discrete alarms → Add new. A row appears in the alarm editor.
3. In the ID column enter a unique integer (WinCC Advanced auto-numbers if you leave the cell; do not rely on auto-numbering for FDA audit trails).
4. In the Trigger tag column, browse to the HMI tag wired to one bit of your PLC Dword. A 32-bit Dword from the PLC must be split into 32 separate HMI tags of data type Bool (one per bit) to drive 32 discrete alarms; this split is performed in the HMI tag table with the Bit access checkbox on the offset/length property.
5. In the Trigger bit dropdown, choose Trigger on rising edge (1 → 0) for an active-high alarm, or falling edge for an active-low alarm.
6. Populate the Alarm text column. Right-click inside the cell → Insert tag field (see Section 6 for details).
7. Set the Class to Warning, Error, or a custom class.
8. Set the Group for filtering in the alarm view control.

5. Understanding the StateAfter Column

When an alarm is enabled for archiving, each transition writes one row to the alarm log. The most important diagnostic column is StateAfter. The values are:

For a regulator the two crucial rows are StateAfter = 1 (the violation started) and StateAfter = 0 (the violation ended). The duration of any given alarm event is therefore:

T_duration = Timestamp(StateAfter=0) - Timestamp(StateAfter=1)

Note that this duration is not stored as a column; it must be computed downstream (Excel pivot, SQL view, Python pandas) from the paired rows.

6. Embedding Process Values in Alarm Messages

For an analog alarm (a high/low limit driven by a process tag), the value that triggered and the value that cleared the alarm are part of the same tag that triggers the alarm. The cleanest way to capture the value is to insert a tag field in the alarm text. The procedure is:

1. Select the discrete or analog alarm in the editor.
2. Click inside the Alarm text cell of the Properties pane (or in the alarm text column of the table view).
3. Right-click → Insert tag field > [your process tag].
4. WinCC inserts a placeholder of the form {Tag name} or, in the script view, a reference such as 'Process_Tag' . The runtime substitutes the current value at the moment the alarm transition occurs.

The text now reads, for example:

Reactor PT-102 high level: 87.4% (limit 85.0%)

Both the incoming row and the outgoing row carry the value of the trigger tag at the moment the transition was logged. The value at the outgoing moment is in general different from the value at the incoming moment (the analog signal has moved back through the threshold), and that is the additional information your client needs. The placeholder is not a static label; it is a runtime reference, and the value is embedded in the archive row.

If you are using discrete alarms driven by a PLC bit (your Dword approach), the trigger tag itself is a Bool and embedding it is unhelpful. In that case create a parallel process value HMI tag wired to the same engineering variable that the PLC uses to evaluate the limit. Insert that value tag in the alarm text. The result is functionally identical to a native analog alarm but allows you to keep the bit-mapped Dword pattern that you already deploy.

7. Archive Configuration for Audit Trail

1. Open HMI alarms > Properties > Archive.
2. Tick Archive alarms.
3. Choose a Storage location: Storage card (SD/USB) for audit-grade persistence; internal flash only for short-term diagnostic logs.
4. Set Path. The default for Comfort panels is /media/simatic/<volume>/Logs.
5. Enable Sequential numbering and Time stamp format = ISO 8601 (yyyy-MM-dd HH:mm:ss.fff). The millisecond field is essential when reconstructing events in fast loops.
6. Under Audit Trail, tick Record operator actions, Record system events, and Record value changes.
7. Set the Number of records conservatively. A TP900 with a 4 GB SD card can hold > 1 million alarm rows in CSV, but the runtime builds an in-memory index; the recommended upper bound for an Audit Trail project is 500,000 records before the index is rolled.

The alarm log columns written to disk are:

8. Reading and Exporting the Alarm Archive

The runtime writes two files per segment:

/media/simatic/<volume>/Logs/Alarms_<YYYYMMDD>.csv
/media/simatic/<volume>/Logs/Alarms_<YYYYMMDD>.ldf   (signature)

The CSV is plain text, comma-separated, with a header row. The .ldf companion is the cryptographic hash file used by the Audit Trail viewer; it is not a human-readable file but must be preserved untouched to keep the chain of custody valid.

To retrieve the file:

1. Stop the runtime (Settings → Stop Runtime) or pull the SD card while the panel is powered down. Hot-swapping is permitted on the SD slot of the TP900 Comfort.
2. Mount the card on a Windows PC. The CSV opens directly in Excel or in any text editor.
3. To compute event duration, use an SQL view such as:

SELECT a.AlarmNumber,
       a.TimeAndDate AS Incoming,
       b.TimeAndDate AS Outgoing,
       DATEDIFF(SECOND, a.TimeAndDate, b.TimeAndDate) AS Duration_s,
       a.AlarmText AS Value_at_incoming,
       b.AlarmText AS Value_at_outgoing
FROM   AlarmLog a
JOIN   AlarmLog b
  ON   a.AlarmNumber = b.AlarmNumber
 AND   a.StateAfter  = 1
 AND   b.StateAfter  = 0
 AND   b.TimeAndDate > a.TimeAndDate
 AND   NOT EXISTS (SELECT 1 FROM AlarmLog c
                    WHERE c.AlarmNumber = a.AlarmNumber
                      AND c.StateAfter   = 1
                      AND c.TimeAndDate BETWEEN a.TimeAndDate AND b.TimeAndDate);

This pattern matches the open/close pair of a single alarm event and is the standard query in regulated environments.

9. Verification Procedure

1. Compile the HMI project, download to the TP900 Comfort, and start the runtime.
2. Force one of the trigger bits on the PLC to 1 using the watch table or the PLC's force table. Confirm the alarm appears in the alarm view control on the panel with the substituted process value.
3. Clear the bit. Confirm a second row appears in the archive with StateAfter = 0 and the (now lower) process value in the text.
4. Stop the runtime, extract the SD card, open the CSV, and verify the two rows are present and that the timestamps differ by the expected duration.
5. If your client requires user attribution, log in as Operator_A, trigger the alarm, log out, log in as Operator_B, and acknowledge it. Confirm two additional rows appear (one with the user at acknowledgement time).

10. Troubleshooting Matrix

11. Best Practices for Regulated Environments

• Disable Allow operator to delete alarms. Operators must never alter the log; only engineers with a password may clear the on-screen buffer.
• Synchronize the panel time to an SNTP/NTP source at least every 24 h. The audit timestamp is only as trustworthy as the panel's RTC.
• Use the Analog class for any limit that can be expressed as a numeric range. The runtime will automatically log both the incoming and the outgoing transition with the substituted value, and the engineering effort is lower than mirroring the same logic in PLC code.
• Keep the Dword bit-mapped pattern only for non-analog or non-numeric alarms (valve open, motor running, interlock active). The bit pattern is efficient but blind to the value that caused the bit to flip.
• Document the alarm ID numbering scheme in the project Functional Specification. Auditors will ask why alarm 1024 follows alarm 1023 and not 1025.
• Reserve one alarm class named Audit (custom) for batch/lot boundary events; do not mix it with operational warnings.
• Schedule a daily export of the CSV to a network share via the panel's Service Tool or via an external WinCC Audit Trail Viewer license. The CSV on the SD card is the source of truth but a redundant off-panel copy protects against card failure.
• Do not enable Allow modification of alarms in the alarm view. Once an alarm is in the archive it must be immutable.

12. Frequently Asked Questions