Configuring Dynamic Alarms and Tags in WinCC Professional V15.1

Problem Definition: Runtime Tag and Alarm Instantiation in WinCC Professional V15.1

Engineers migrating from classic WinCC (v7.x), Wonderware InTouch, or any SCADA platform that allows runtime modification of the tag and alarm database frequently ask the same question of TIA Portal V15.1: can WinCC Professional create new HMI tags or new alarm records at runtime, from a C or VBScript? The documented answer in V15.1 is unambiguous. WinCC Professional does not expose a public runtime API that creates new HMI tag definitions or new entries in the Alarm Logging database. The VBScript host, the C-Script host, and the C/C++ Open Development Kit (ODK) operate on the runtime instance of the project, not on the engineering schema. The schema is fixed at compile time.

This constraint is at odds with several real engineering workloads, in particular mass-generated alarm populations built from PLC user-defined types (UDTs). A typical case is 150 motor instances, each containing 10 sub-blocks, each containing 3 alarm BOOLs. The HMI alarm count is 150 × 10 × 3 = 4500 alarm records. Manually engineering 4500 alarm records in the TIA Portal HMI alarms editor is impractical, and the engineer wants a script to generate them automatically. The script can run, but it must run at engineering time, not at runtime, and the only first-party Siemens API that writes the TIA project database programmatically is TIA Openness, not ODK.

WinCC Edition Capability Comparison (TIA Portal V15.1)

WinCC is delivered in four TIA editions with very different scripting and engineering surfaces. The TIA V15.1 capability matrix for the topic at hand is summarized below.

The first six rows of the matrix are the relevant ones for the present problem. The capability "Create HMI tag at runtime" is the key, and it is uniformly "No" across all V15.1 editions. The same is true of "Create HMI alarm at runtime". Where the editions differ is the engineering-time and runtime extension surface: WinCC Professional is the only edition that exposes ODK and the only edition that participates in TIA Openness for the HMI side.

Root Cause: Compile-Time Alarm and Tag Schema

The HMI alarms editor in TIA Portal V15.1 writes alarm records into the HMI project database at compile time. Each record carries a fixed numeric ID, a fixed trigger tag reference, a fixed alarm class assignment, a fixed priority, and a fixed text block. At runtime, the WinCC Alarm Logging service resolves incoming tag events against this compiled index, raising and clearing alarms by ID. The runtime has no documented function to insert a new ID into the index.

HMI tags are stored in the same project database. The runtime receives a tag list at startup and uses it for name resolution on every read and write. There is no documented VBScript, C-Script, or ODK entry point that appends a new tag to the live tag list.

This is a deliberate architectural choice. The runtime is decoupled from the engineering tool. Runtime schema mutation would invalidate the project license, the audit trail, and the alarm logging indexes. Siemens' recommended solution is to do all schema work at engineering time, in the TIA Portal environment, with TIA Openness as the programmatic surface.

ODK (Open Development Kit): The C/C++ Runtime Extension Surface

ODK is the only documented C/C++ extensibility surface in WinCC Professional. It is delivered as a Software Development Kit installed alongside WinCC Professional and exposed through header files, import libraries, and a runtime DLL. ODK functions fall into several groups, summarized in the table below.

ODK functions in the Data Manager group operate on tags that already exist in the compiled project. DM_VAR_DECL retrieves the address of a known tag; it does not create one. MS_WriteMessage raises an alarm whose ID and parameters are pre-engineered; it does not register a new alarm ID. The ODK headers do not contain a symbol that would extend the live tag list or the live alarm index, and attempting to call the underlying SQL database directly is undocumented and unsupported.

The practical use of ODK in V15.1 is to read/write tags with sub-millisecond latency from compiled C/C++ code, to raise and acknowledge alarms in tight loops (for example, in a custom high-speed event collector), and to integrate WinCC with a third-party control loop. ODK is the wrong tool for mass alarm generation.

TIA Openness: The Engineering-Time Alternative

TIA Openness is a .NET API (C# or VB.NET) that drives the TIA Portal engineering environment programmatically. It can create HMI tags, HMI alarms, screens, PLC blocks, connections, and configuration data. It is the only first-party Siemens API that writes the TIA project database. TIA Openness is documented in the Siemens TIA Openness programming manual, available on the Siemens Industry Online Support portal.

The Openness workflow for a 4500-alarm project is the only fully supported way to do the task. The phases are:

1. Pre-engineer a single alarm record in TIA Portal to validate the text format, the alarm class, and the trigger tag pattern.
2. Export the motor list from the PLC project (for example, as a CSV file generated from the S7-1500 PLC's symbol table or from an Excel tool).
3. Write a TIA Openness C# console application that iterates over the motor list and creates the corresponding HMI tags and alarm records.
4. Compile the C# application and run it against the TIA Portal instance.
5. Open the TIA project, verify the count of new records, compile, and transfer the runtime to the HMI server.

A representative C# skeleton is below. The TIA Openness assemblies are located under C:\Program Files\Siemens\Automation\Portal V15.1\PublicAPI\V15.1 on a default installation. The full reference is in the TIA Openness API documentation.

using System;
using System.IO;
using System.Linq;
using Siemens.Engineering;
using Siemens.Engineering.Hmi;
using Siemens.Engineering.Hmi.Tag;
using Siemens.Engineering.Hmi.Alarm;

class Program
{
    static void Main()
    {
        var portal = new TiaPortalInstance();
        var tia = portal.Portal;
        var project = tia.Projects.Open(
            new FileInfo(@"C:\Projects\Plant.ap15"));
        var hmi = project.Devices
            .OfType<HmiDevice>()
            .First(d => d.Name == "HMI_RT_1");
        var tagFolder = hmi.TagFolder;
        var alarmGroup = hmi.AlarmGroups[0];
        var alarmClass = hmi.AlarmClasses
            .First(c => c.Name == "Error");
        var motors = File.ReadAllLines("C:\\Data\\motors.csv");
        int created = 0;
        foreach (var motor in motors)
        {
            for (int blk = 0; blk < 10; blk++)
            {
                for (int bit = 0; bit < 3; bit++)
                {
                    string tagName = $"Motor_{motor}_B{blk}_Alarm{bit}";
                    var tag = tagFolder.Tags.Create(tagName);
                    tag.DataType = HmiTagDataType.Bool;
                    tag.Connection = "HMI_Connection_1";
                    tag.PlcAddress = $"DB{100 + blk}.Motor_{motor}.Alarm{bit}";
                    var alarm = alarmGroup.Alarms.Create(
                        $"Alarm_{motor}_B{blk}_Alarm{bit}");
                    alarm.TriggerTag = tagName;
                    alarm.AlarmClass = alarmClass;
                    alarm.EventText = new[]
                    {
                        $"Motor {motor} block {blk} alarm {bit} raised"
                    };
                    created++;
                }
            }
        }
        project.Save();
        Console.WriteLine($"Created {created} alarms");
    }
}

UDT-Based Alarm Multiplexing: Operational Pattern

For very large alarm populations, the engineering-time generation can be reduced further by multiplexing the alarm text through a single alarm record whose display text is composed at runtime from PLC tag values.

The pattern is:

1. Define an S7-1500 PLC UDT UDT_Motor_Alarms with fields: MotorName STRING[16], AlarmRunning BOOL, AlarmTripped BOOL, AlarmWarning BOOL.
2. Create 150 instances of the UDT as DataBlock "MotorDB".Motors[1..150].
3. In the HMI alarms editor, create three alarm records with placeholder text such as Motor %s alarm running where %s is bound to the trigger tag's parent block name.
4. Engineer 150 × 3 = 450 alarm records (one per motor per bit) by TIA Openness. The placeholder resolves at runtime to the actual motor name from the MotorName tag.

Operator-visible behavior: a fault on motor 27 shows Motor M_0027 alarm tripped in the Alarm Control, even though the alarm record was engineered as a single template replicated 150 times. This pattern is supported in WinCC Professional V15.1 and is the recommended approach for high-count alarm populations.

WinCC Unified: The Modern Alternative

WinCC Unified is the successor HMI runtime introduced in TIA Portal V16 and continued in V17, V18, V19, V20, and V21. Its architecture is fundamentally different from WinCC Professional: a containerized Chromium-based UI, a JavaScript scripting host, and an OPC UA-centric tag model. For the present problem, two changes matter.

1. Tag model. Unified's tag model is largely driven by OPC UA subscriptions. The runtime registers interest in OPC UA items and receives updates without a fixed compile-time list. This is closer to a true dynamic tag system.
2. Alarm API. Unified's alarm control is configured in the engineering system and is exposed to the runtime. The alarm control's content can be filtered, sorted, and rendered dynamically from the engineering configuration, with placeholder support in the alarm text.

For V21 documentation, see the Siemens TIA documentation cloud at Alarm control (RT Unified) - WinCC Unified V21. Migration from WinCC Professional V15.1 to WinCC Unified V21 is a project-level decision involving screen re-authoring, script re-hosting, and a fresh HMI license, and is not a drop-in replacement. For new projects that anticipate very large alarm populations or dynamic HMI content, Unified is the forward-looking choice.

Complete Mass Engineering Workflow for WinCC Professional V15.1

Prerequisites for the recommended workflow:

• TIA Portal V15.1 installed with the TIA Openness option enabled in the installation dialog.
• Visual Studio 2015 or later (Community Edition is sufficient) for the C# host.
• The target TIA project file (.ap15) accessible from the engineering station.
• A valid WinCC Professional V15.1 license on the engineering station (the engineering license is separate from the runtime license).
• The motor list as a CSV file in the MotorName,BlockIndex,BitIndex format.

Step-by-step procedure:

1. Open TIA Portal V15.1 with the target project. Confirm that the HMI device exists and that the alarms editor is reachable.
2. Engineer one template alarm record manually. Set the alarm class (for example, "Error"), the priority, the trigger tag, and the event text format. Save the project and close TIA Portal.
3. In Visual Studio, create a new C# Console App project. Add references to the TIA Openness assemblies: Siemens.Engineering.dll, Siemens.Engineering.Hmi.dll, and the language pack assemblies for the locale in use.
4. Implement the loop shown in the previous code block. Validate the CSV parser against a small subset (for example, 10 motors) before scaling to the full 150.
5. Start TIA Portal in with target mode (or in API mode) and run the C# application. Monitor the output window for the created-alarm count.
6. When the Openness run completes, open the TIA project and check the alarms editor. The expected count is 150 × 10 × 3 = 4500 records, plus the template record.
7. Compile the TIA project. Compilation of a 4500-alarm project typically takes 15 to 45 minutes on a modern engineering station, dominated by the alarm logging database build.
8. Transfer the runtime to the HMI server. Use the WinCC RT loader or the SIMATIC Automation Tool for unattended transfer.
9. Start the runtime and verify the alarm population in the Alarm Control screen.

Multiplexed Alarm Text Configuration

For the multiplexed alarm pattern, configure the alarm text in the TIA Portal HMI alarms editor as follows.

The %s placeholder follows the WinCC alarm text formatting rules; multiple placeholders (%s %d) are supported for string and integer substitution. The placeholder resolution engine is invoked on every alarm state change and does not require any extra scripting.

Diagnostic Tags, Performance Limits, and Sizing

WinCC Professional V15.1 runtime exposes internal diagnostics through system tags prefixed with @. The relevant tags for a 4500-alarm project are listed below.

For sizing, a 4500-alarm TIA project on disk typically consumes 40 to 80 MB of compiled runtime data, dominated by the alarm logging SQLite database and the project translation tables. The runtime memory footprint scales with the number of active alarms and the configured history depth. With a 24-hour history and an average alarm rate of 10 events per second, plan for 4 to 6 GB of working set on the HMI server. The hard upper limit on the SQL-CE-based alarm logging database in V15.1 is 4 GB, corresponding to roughly 100 million historical alarm records before rotation is required.

Verification Procedure

1. Start the WinCC Runtime on the HMI server. Confirm the runtime is in "Online" state on the system tray icon.
2. Open the Alarm Control screen on the HMI. Confirm 0 active alarms at idle.
3. From the PLC, force the AlarmRunning bit of Motors[1] to TRUE. Confirm one alarm appears in the Alarm Control within 2 seconds and the message text reads Motor M_0001 alarm running.
4. Repeat for 5 additional motors, distributed across the 150-motor array. Confirm the multiplexed text resolves correctly for each.
5. Acknowledge all visible alarms from the Alarm Control toolbar. Confirm @AlarmLogging.UnacknowledgedAlarms returns to 0.
6. Clear the trigger bits in the PLC. Confirm all alarms clear within 2 seconds and @AlarmLogging.ActiveAlarms returns to 0.
7. Open the WinCC diagnostics log (default path C:\ProgramData\Siemens\Automation\Logs) and scan for entries with severity "Error" or "Warning". Confirm no 0x8004xxxx (license), 0x8007xxxx (tag resolution), or 0x800Bxxxx (alarm logging) codes are present.
8. Disconnect the PLC connection from the WinCC side. Confirm the connection-status tag @ConnectionState_HMI_Connection_1 reports "Disconnected" and the Alarm Control shows the connection-fault alarm (default severity "Warning").
9. Reconnect the PLC, clear the connection-fault alarm, and confirm the runtime returns to the idle state.

Edge Cases and Known Constraints

Several field-tested caveats apply to the V15.1 stack.

• Project database size. TIA Portal V15.1 has a known issue with project databases exceeding 2 GB. The .ap15 file may exhibit slow save/load behavior above this threshold. Mitigation: split the HMI into multiple HMI devices if the alarm count exceeds approximately 3000 per device.
• ODK and antivirus. Some antivirus products quarantine the ODK runtime DLL CCDMHelper.dll. Add an exception for C:\Program Files\Siemens\Automation\WinCC\bin in the antivirus policy.
• String placeholder encoding. When the %s placeholder source tag contains non-ASCII characters (for example, Cyrillic or Chinese), the alarm text rendering may corrupt on Western-engineered HMI stations. Set the alarm logging locale in TIA Portal to match the operator language and ensure the runtime is started with the matching Windows code page.
• Alarm acknowledgement propagation. Acknowledgements sent from a V15.1 client do not propagate to a v7.x server, and vice versa. If the plant has mixed-version HMIs, plan for an alarm routing gateway.
• TIA Openness on a domain-joined station. TIA Openness requires a fully licensed TIA Portal instance, not a viewer. It will fail to start on a station that has only the TIA Portal Viewer installed.
• Compile time for 4500 alarms. Expect 15 to 45 minutes of compile time on a current-generation engineering station (8-core, 32 GB). The bottleneck is the alarm logging database build, not the screen compilation.
• Openness script and TIA Portal collision. Running an Openness C# application while TIA Portal has the same project open in interactive mode is not supported. Close TIA Portal or use the Openness "with UI attached" mode to avoid database-locking errors.

Cross-Platform Context

The constraint that runtime cannot create tags or alarms is not unique to Siemens. Most regulated SCADA platforms treat the tag and alarm schema as a compile-time artifact for auditability and deterministic behavior. Platforms such as Inductive Automation Ignition pursue a different model where tags are database rows and can be created at runtime through scripting, but this is an architectural difference rather than a deficiency. Engineers evaluating WinCC Professional V15.1 against such platforms should weigh the licensing model, the audit trail, the engineering-time generation tooling (TIA Openness), and the operational performance of the multiplexed alarm pattern documented above.

FAQ