Generating WinCC Alarms Without Manual Tag Entry: AS-OS, VBS API, and Bit-Level Methods

1. Overview: The Alarm Engineering Bottleneck

In a typical WinCC HMI/SCADA project, alarm configuration is one of the most labor-intensive engineering activities. A mid-sized plant with 200 motors, 400 valves, and several hundred discrete I/O points can easily produce 2,000 to 5,000 individual messages. When every message requires a manual tag entry in the WinCC Tag Management and a parallel entry in Alarm Logging, the engineering time balloons, the configuration database becomes error-prone, and every PLC-side signal rename cascades into a manual HMI-side update.

Siemens offers several mechanisms that allow the engineer to either push the alarm definition down to the PLC (so the message travels with the program) or to read the alarm state from a packed bit-pattern tag using a single HMI tag per device. The methods covered in this article are:

1. AS-OS engineering: configure messages in STEP 7 and have them exported to WinCC automatically.
2. The WinCC Configuration Tool: bulk-edit alarm text, message classes, and acknowledgment from an external spreadsheet.
3. VBS / C API call against the Alarm Logging runtime to set/reset messages programmatically.
4. Bit-level Alarm Logging on a single status tag, so one DWORD drives up to 32 alarms.

All four methods are valid production techniques; the correct choice depends on whether STEP 7 and WinCC are co-located, whether the project uses PCS 7, and whether the HMI platform is classic WinCC or TIA Portal WinCC Professional.

2. Alarm Engineering Approaches Comparison

3. Method 1 - AS-OS Engineering with Alarm_8 / Alarm_8P

The AS-OS engineering concept is the canonical Siemens answer to "do I have to type every alarm in WinCC?". The principle is that the message text, message class, acknowledgment requirement, and trigger tag are all defined in the STEP 7 project on the PLC side, and the STEP 7 / WinCC integrator exports them to WinCC in a single batch operation.

3.1 PLC-Side Configuration

1. Open the STEP 7 project containing the S7-300 / S7-400 program (or the TIA Portal project for S7-1500).
2. Insert an FB alarm block. For S7-300/400, the standard block is FB 35 (ALARM_8P) from the standard library; for S7-400H and S7-1500 the corresponding type is ALARM_8P with up to 8 associated values. For simpler applications the legacy FB 33 (ALARM) or FB 36 (NOTIFY_8P) can be used.
3. Wire the message trigger bit, the acknowledge variable, and the message number. The message number is the linkage between the PLC program and the WinCC text library; the same number must exist in both.
4. Edit the message text directly on the symbol or on the block instance. STEP 7 stores this text in the S7 program container. Up to 10 associated values (EV_1 through EV_10) can be embedded; each is sent to WinCC as a tag value at runtime.

3.2 Export to WinCC

1. In the STEP 7 / WinCC configuration tool (Options > STEP 7 - WinCC Assignment or the PCS 7 plant view), select the S7 program and the target WinCC project.
2. Trigger the Compile OS (PCS 7) or Export Messages (classic STEP 7) action. This writes a binary file containing every message text, message class, and tag association.
3. WinCC ingests the file and creates a single raw data tag of type WORD or DWORD per CPU, plus the full message text in Alarm Logging. No per-alarm WinCC tag is generated.
4. At runtime, the CPU sends the message number and the up-to-10 associated values as a frame; WinCC looks up the text by number and displays it without ever polling an individual tag.

3.3 Limits and Notes

• Message number range is 0 to 65535 in classic AS-OS; PCS 7 reserves 0-9999 for system messages.
• Maximum of 10 associated values per message, each 4 bytes (REAL or DWORD) or 8 bytes (REAL extended).
• The technique is S7-300/400 / S7-1500 native. It is not available for third-party PLCs over OPC, although a similar pattern can be built with the WinCC Alarm Logging Alarm_DLGHMI and a custom message frame driver.

4. Method 2 - WinCC Configuration Tool (Smart Tools)

The WinCC Configuration Tool is delivered as part of the WinCC Smart Tools package and is the official bulk-editor for Alarm Logging. It exchanges CSV files with the WinCC project database, which means the alarm list can be edited in Excel and then re-imported.

4.1 Typical Workflow

1. Install the Configuration Tool from the WinCC DVD under Smart Tools > WinCC Configuration Tool. It is also documented in the WinCC Information System under Smart Tools.
2. Open the tool, point it at the active WinCC project, and select Export Alarms. A CSV is produced with one row per message.
3. Edit the CSV in Excel. Reasonable column mappings are: Number, Class, Type, Tag, TriggerBit, MessageText_EN, MessageText_DE, AckModel.
4. Save the CSV and run Import Alarms. The tool writes directly into the WinCC project database; Alarm Logging is updated without manual entry.

4.2 Spreadsheet-to-Alarm-Logging Mapping

5. Method 3 - VBS / C API for Programmatic Alarm Control

WinCC exposes its Alarm Logging runtime through a COM automation interface. The VBScript object HMIRuntime.Alarm (in classic WinCC) and the equivalent C/C# API in WinCC Professional allow the engineer to raise and clear messages from a script, without ever having defined the alarm in Alarm Logging beforehand.

5.1 Raising a Message via VBScript

Sub RaiseMotorAlarm(motorTagName, stateBit)
    Dim alarm
    Set alarm = HMIRuntime.Alarm

    ' State machine for the motor faceplate:
    '   bit 0 = running
    '   bit 1 = tripped
    '   bit 2 = overload warning
    '   bit 3 = communication fault

    If (stateBit And 1) <> 0 Then
        alarm.CreateSystemState "Motor " & motorTagName & " running", 0
    End If

    If (stateBit And 2) <> 0 Then
        alarm.CreateSystemState "Motor " & motorTagName & " TRIPPED", 1
    End If

    If (stateBit And 4) <> 0 Then
        alarm.CreateSystemState "Motor " & motorTagName & " overload warning", 2
    End If

    If (stateBit And 8) <> 0 Then
        alarm.CreateSystemState "Motor " & motorTagName & " COM fault", 1
    End If
End Sub

5.2 Available API Surface

5.3 The "Customized Object" Use Case

The original question in this thread was: "I want a custom object whose internal bits should generate alarms. Is this possible?" The answer is yes, with two distinct approaches:

1. Bind the custom object's bits to a status DWORD tag and use Method 4 below (bit-level Alarm Logging). The object is re-usable, the alarm definition is project-wide.
2. Place a VBScript on the object that calls HMIRuntime.Alarm.CreateSystemState on demand. No WinCC tag at all is required; the alarm is generated from the script context. This is the most "config-free" approach but loses the standard Alarm Logging view of state and acknowledgment.

6. Method 4 - Bit-Level Alarm Logging on a Packed Tag

This is the most popular method for reducing tag count. Instead of creating one WinCC tag per alarm trigger, the engineer creates one DWORD (or WORD) per device and defines up to 32 alarms on individual bits of that single tag.

6.1 Setting Up Bit-Level Trigger

1. In WinCC Tag Management, create a single tag, e.g. Motor1_StatusWord, of data type UNSIGNED32 (DWORD).
2. Open Alarm Logging, create one message row per bit you want to alarm on, and set the trigger to Motor1_StatusWord with the bit number field set to 0, 1, 2, ... up to 31.
3. Define the message class, text, and acknowledgment model per bit. For instance bit 0 = "Motor 1 overload trip", bit 1 = "Motor 1 breaker open", bit 2 = "Motor 1 VFD fault", etc.

6.2 Why This Works at All

Alarm Logging is a polling engine. The polling cycle (default 250 ms, configurable in the WinCC project properties) reads the trigger tag, masks the configured bit, and raises the alarm if the masked value transitions from 0 to 1. Because the mask and the bit interpretation live in Alarm Logging rather than in the tag, you get N alarms for the price of one tag acquisition.

6.3 Limits

• Maximum 32 bits per DWORD, so up to 32 alarms per device. A motor with 20 alarms consumes one tag and produces twenty messages.
• The CPU side must pack the bits; the engineer should document the bit map in a project-wide naming convention (e.g. Dev_Status.bit0 = overload, bit1 = breaker, ...). The faceplate can use the same convention for color coding.
• One bit per alarm. Multi-bit patterns (e.g. "state = 0x03 means warming up") require either two separate messages or a derived tag with a comparison expression.

7. TIA Portal Unified Alarm Engineering

The TIA Portal (STEP 7 V15 and later, WinCC Professional / WinCC Unified) merges the PLC and HMI configuration under one engineering tool. This naturally aligns with the original question: "Can WinCC read messages from a single raw-data block defined in the PLC?"

7.1 HMI Alarm Configuration Inside TIA Portal

1. Open the TIA Portal project and select the HMI device.
2. Navigate to HMI alarms > Discrete alarms. The editor lists all PLC tags with their symbol comments.
3. For each PLC tag you want to alarm on, click Add. A new alarm row is generated, pre-populated with the PLC tag name and the symbol comment as default message text.
4. Edit message class, acknowledgment model, and trigger bit if the tag is a bit-packed structure. The compiler propagates the configuration to the WinCC runtime database on download.

7.2 PLC Program Blocks for TIA Alarm Generation

For S7-1200 / S7-1500, the alarm blocks are Program_Alarm (S7-1500) and the legacy WRMSG / WRMSG_Q instructions. The pattern is:

// SCL example for S7-1500
IF #overloadTrip THEN
    "Program_Alarm".OVERLOAD(MSG := 'Motor #name overload tripped', 
                             Severity := 1, // 1 = error
                             EnableTag := TRUE);
ELSE
    "Program_Alarm".OVERLOAD(Enable := FALSE);
END_IF;

Each Program_Alarm instance generates one alarm row visible in the TIA Portal HMI alarm editor. The text and the trigger live in the PLC code; the HMI side only renders the alarm.

7.3 Exporting PLC Messages into a Classic WinCC Project

For projects that use STEP 7 (classic) and WinCC separately, the AS-OS export is the supported route. The relevant setting is in SIMATIC Manager > Options > Configure AS-OS Assignment. See the WinCC message configuration FAQ for the exact menu path and the supported message number ranges.

8. Project Transfer and OS Download Workflow

A second practical concern that often comes up: STEP 7 is installed on the engineering laptop, while WinCC is installed on the customer PC. There are three supported transfer flows.

8.1 Zip and Transfer

The most common flow. The engineer copies the WinCC project folder (typically C:\Program Files\Siemens\Automation\WinCC\WinCCProjects\<ProjectName>), zips it, and copies it to the customer PC. WinCC V7.x stores all configuration, graphics, and the runtime database in this folder, so the transfer is self-contained. Restart the WinCC Explorer on the target PC and the project opens with the same paths as on the engineering station provided the drive mapping is preserved.

8.2 OS Download (PCS 7 / Step 7 Integrated)

1. On the engineering station with STEP 7 / PCS 7 and the WinCC Configuration software installed, open SIMATIC Manager.
2. Select the OS, right-click and choose Download OS to Target System. STEP 7 transfers the compiled OS runtime to the WinCC station over the configured network.
3. The customer PC needs the WinCC runtime license and a network route to the engineering station. No manual file copy is required.

8.3 TIA Portal Download

In TIA Portal the equivalent is Online > Download to Device > Software (only) for the HMI device. The HMI device must be reachable on PROFINET / Ethernet and the HMI runtime on the target station must be in transfer mode.

9. STEP 7 and WinCC Co-Installation Requirements

AS-OS engineering requires the STEP 7 / WinCC integrated toolset on the same PC (either both installed, or STEP 7 installed with the WinCC add-on). The Configuration Tool and the VBS API do not require STEP 7 on the runtime PC; they only need WinCC. Bit-level Alarm Logging needs neither. The table below summarizes the workstation requirements.

For WinCC V7.5 and later, the WinCC Information System documents these methods under Working with WinCC > Alarm Logging and Smart Tools > WinCC Configuration Tool. Refer to the WinCC V7.5 System Manual for the message-class taxonomy and the WinCC Information System FAQ for the runtime architecture.

10. Verification and Commissioning

Whichever method is chosen, the verification procedure is the same.

1. Tag simulation: In WinCC Explorer, open Tools > WinCC Tag Simulation. Force the trigger tag (or each individual bit for Method 4) to 1 and confirm the corresponding message row appears in the Alarm Control view.
2. Acknowledgment path: Click the message in the Alarm Control and confirm the horn / acknowledgment icon toggles correctly. If the message is set to "must be acknowledged", the alarm stays in the active list until acknowledged.
3. Bit masking verification: For Method 4, force bit 17 of the status DWORD to 1 and confirm that only the alarm configured on bit 17 fires, not the alarm on bit 18. This catches the common mistake of mis-numbering bits in the Alarm Logging row.
4. Project transfer integrity: After the customer PC is updated, open the project, regenerate the runtime database, and confirm that the message text in the Alarm Control matches the engineering project. WinCC stores the text in the runtime database, so a corrupted transfer can leave the engineering database correct but the runtime database stale.
5. Archive round-trip: If the project archives alarms, trigger a sample alarm, wait for the configured archive cycle, and read the alarm back from the archive. This confirms that the message number / class is correctly mapped in the database, not just in the editor.

11. Troubleshooting Matrix

12. Field Notes and Best Practices

• Pick one method per project. Mixing AS-OS (which expects a STEP 7 / WinCC integrated engineering flow) and bit-level (which expects a single packed status tag) inside the same project produces confusing message-number collisions and double-firing alarms.
• For S7-1500 with TIA Portal, use the Program_Alarm block family; the engineering effort per alarm is the lowest in the Siemens portfolio.
• For classic WinCC + S7-300/400 plants with hundreds of identical motors, the Configuration Tool combined with a bit-level status word is the fastest path: one CSV defines the alarm text, one tag per motor carries the bit pattern, and the operator faceplate reuses the same screen for every device.
• For PCS 7 plants, AS-OS is the only sanctioned approach. The PCS 7 course covers the message-number reservation, the standard message classes, and the operator authorization handling that the AS-OS pipeline assumes.
• Always export the alarm list (CSV) and the tag list (CSV) at project handover, and archive them under version control. The WinCC project database is a binary blob; a future engineer who needs to bulk-edit will be grateful for a text export.

13. Frequently Asked Questions