From TIA Portal to WinCC: Configuring Alarms & Runtime Messages Step-by-Step

• Create stable alarm conditions in PLC logic before configuring messages in WinCC.
• Separate process alarm state from HMI acknowledgement state unless the process specification explicitly requires a PLC handshake.
• Use consistent severity, priority, text and equipment naming across the plant.
• Test activation, return-to-normal, acknowledgement and communication loss as separate cases.

1. Alarm Engineering Model: PLC Condition → WinCC Message

A useful alarm path is Process Condition → PLC Alarm Bit → WinCC Tag → Alarm Message → Operator Action → History. The PLC owns the condition because it has deterministic access to the process. WinCC owns presentation and operator interaction.

Examples include high-high temperature, VFD fault, low pressure, communication failure, motor overload and permissive failure. Each condition should have a clear setpoint or logical cause and a defined return-to-normal rule.

2. Create Alarm Conditions in TIA Portal

Keep alarm logic readable and group related alarm bits in a dedicated interface DB. The following SCL pattern is deliberately simple and can be translated to LAD/FBD:

// Example alarm conditions
AlarmDB.HighHighTemp := Temp_Act >= Temp_HH_SP;
AlarmDB.VFDFault     := VFD01_Fault;
AlarmDB.LowOilLevel  := Oil_Level_Pct <= Oil_Low_SP;
AlarmDB.IOCommFault  := NOT RemoteIO_Healthy;

Do not add artificial latching automatically. Decide whether an alarm should follow the live condition, latch until reset, or require a PLC reset based on process risk and the alarm philosophy.

3. Build a Dedicated PLC Alarm Interface

A dedicated alarm interface makes SCADA mapping predictable and avoids searching through unrelated DBs during commissioning.

4. Configure Alarm Messages in WinCC

1. Create or verify the PLC connection.
2. Create WinCC process tags for the alarm bits or use integrated symbolic tags where supported.
3. Open the WinCC alarm/message editor appropriate to the product generation.
4. Create the message and select the trigger tag/bit.
5. Assign message class, priority, text and optional process value.
6. Configure acknowledgement behavior according to the alarm philosophy.
7. Place an alarm control/message view on the Runtime screen.
8. Activate Runtime and test one alarm end-to-end before bulk import.

5. Alarm Classes, Priority and Acknowledgement

Do not use the same priority for every event. A practical classification may separate critical trips, process alarms, warnings, maintenance/system events and operator information.

Acknowledgement confirms that an operator has seen the alarm; it does not mean the process condition is healthy. Keep “active”, “returned” and “acknowledged” states conceptually separate.

6. Runtime Messages and Operator Context

Alarm text should tell the operator what happened, where it happened and what to check. Avoid generic messages such as “Fault 27”. A better message is “Line 2 / VFD-03 fault — inspect drive fault code and motor permissives.”

Use dynamic process values in the message only when they add context, for example actual temperature at the time of alarm. Do not overload every alarm with unnecessary parameters.

7. Timestamp Strategy

For sequence analysis, the timestamp source matters. If network delay is important, controller-generated event timestamps or appropriately configured system timestamps may be required. For ordinary HMI alarm display, the WinCC Runtime timestamp may be sufficient. Define this requirement before commissioning rather than after a difficult incident.

8. Alarm Commissioning Test Sequence

1. Record the normal state.
2. Simulate or safely create the alarm condition.
3. Verify PLC alarm bit.
4. Verify WinCC tag changes with good quality.
5. Verify message text, class and priority.
6. Verify audible/visual indication if configured.
7. Acknowledge and confirm acknowledgement state.
8. Remove the abnormal condition and verify return-to-normal.
9. Check history/archive entry.
10. Test communication loss so stale values are not mistaken for normal process state.

9. WinCC Alarm Troubleshooting

10. Hands-On Alarm Lab

Create four alarm bits in a PLC DB: HighHighTemp, VFDFault, LowOilLevel and IOCommFault. Map them into WinCC, assign different priorities, commission an alarm view and document the expected active/return/acknowledge sequence for each alarm.