WinCC VBScript Alarm and Event Handling

1. Define the alarm lifecycle before adding VBScript

Every alarm should have a documented source, priority, message, operator response, acknowledgment rule and return-to-normal behavior. Configure these functions in WinCC Alarm Logging wherever possible.

2. Read alarm context from approved tags

When a supplementary action is required, read a small set of explicit context tags rather than reconstructing the entire alarm state in VBS.

Function ReadAlarmContext()
    Dim alarmActive, equipmentId, faultCode

    alarmActive = HMIRuntime.Tags("Alarm_Active").Read
    equipmentId = HMIRuntime.Tags("Alarm_EquipmentId").Read
    faultCode = HMIRuntime.Tags("Alarm_FaultCode").Read

    ReadAlarmContext = CStr(alarmActive) & "|" & _
        CStr(equipmentId) & "|" & CStr(faultCode)
End Function

Confirm tag quality and data type in the deployed release. The configured alarm remains authoritative even if this supplementary read fails.

3. Open contextual diagnostics without creating popup storms

A high-priority alarm may offer a button that opens the relevant equipment diagnostic view. Avoid opening repeated modal windows automatically for every state change.

Sub RequestAlarmDiagnostic(ByVal equipmentId)
    If Trim(CStr(equipmentId)) = "" Then
        HMIRuntime.Trace "Diagnostic request rejected: no equipment" & vbCrLf
        Exit Sub
    End If

    HMIRuntime.Tags("UI_SelectedEquipment").Write CStr(equipmentId)
    'Call the supported popup or picture-window method for this WinCC release.
    HMIRuntime.Trace "Alarm diagnostic requested for " & _
        CStr(equipmentId) & vbCrLf
End Sub

Use a validated equipment map and the navigation pattern described in WinCC screen navigation, faceplates and reusable instances.

4. Record a supplementary event with stable fields

A custom record may capture diagnostic context not contained in the standard alarm message. Use a stable schema and avoid storing sensitive operator information unnecessarily.

Sub TraceAlarmEvent(ByVal equipmentId, ByVal faultCode, ByVal actionName)
    Dim eventLine
    eventLine = "ALARM_EVENT|equipment=" & CStr(equipmentId) & _
        "|fault=" & CStr(faultCode) & _
        "|action=" & CStr(actionName)

    HMIRuntime.Trace eventLine & vbCrLf
End Sub

For durable records, use the configured alarm archive, historian or approved database. HMIRuntime.Trace is primarily a diagnostic aid, not a compliance archive.

5. Support acknowledgment without bypassing WinCC controls

Use the supported alarm-control acknowledgment function and configured authorization. A script may prepare context or navigate to the alarm control, but it should not create an undocumented parallel acknowledgment mechanism.

• Require the configured role for acknowledgment.
• Preserve alarm identity, original timestamp and acknowledgment timestamp.
• Do not acknowledge alarms automatically merely because a popup was opened.
• Test acknowledgment during communication loss and redundant-server changeover where applicable.

6. Design sounds and notifications conservatively

Custom sounds or external notifications must be bounded, rate-limited and aligned with the alarm philosophy. Repeated script triggers can create duplicate notifications or operator overload.

• Trigger on a defined state transition, not every cyclic evaluation.
• Record delivery success and failure separately from alarm acknowledgment.
• Provide a supported silence or escalation workflow.
• Do not transmit plant or operator data to external services without approval.

7. Handle event-script failures explicitly

An error in a supporting script must not suppress the configured alarm. Keep the action small, trace the failing operation and clean up external objects.

Sub RunAlarmSupportAction()
    On Error Resume Next
    Err.Clear

    Call TraceAlarmEvent("M101", 27, "OPEN_DIAGNOSTIC")

    If Err.Number <> 0 Then
        HMIRuntime.Trace "Alarm support error " & CStr(Err.Number) & _
            ": " & Err.Description & vbCrLf
        Err.Clear
    End If

    On Error GoTo 0
End Sub

Continue with WinCC VBScript error handling and diagnostics for reusable failure patterns.

8. Test alarm transitions and recovery states

9. Commissioning checklist

• Review the alarm against the site alarm philosophy.
• Confirm WinCC Alarm Logging owns lifecycle and acknowledgment.
• Verify supplementary scripts are transition-based and bounded.
• Test every user role and abnormal communication state.
• Confirm custom records do not conflict with the approved historian.
• Document triggers, context tags, navigation targets and failure behavior.

10. Example: bottling-line filler fault

A filler motor overload creates a configured WinCC alarm with priority, timestamp and acknowledgment requirements. The operator can open a motor-specific diagnostic faceplate, while a supporting VBS action traces the equipment identifier and fault code. Clearing or acknowledging the alarm still follows the configured alarm lifecycle; the script does not reset the drive or bypass the PLC fault logic.