WinCC Unified TIA Portal V16: SCADA Architecture and Licensing

WinCC Unified in TIA Portal V16: SCADA Architecture, Licensing, and Selection Reference

Siemens WinCC Unified is the current-generation SCADA and HMI runtime that ships as an integrated component of the TIA Portal engineering framework. Introduced as the successor line to WinCC Flexible / WinCC Comfort Panels, the Unified line consolidates the engineering workflow for Comfort Panels, Unified Comfort Panels, and PC-based Unified runtime into a single toolchain. With the release of TIA Portal V16, the platform gained the ability to scale to multi-user SCADA projects without leaving the engineering environment, and the runtime architecture was reworked around a web-server model. This reference covers the engineering model, tag architecture, licensing matrix, deployment options, and a comparative analysis against legacy and open-source SCADA systems so that controls engineers can make a defensible selection.

1. TIA Portal V16 and the Unified Product Line

TIA Portal V16 is the engineering environment for the SIMATIC WinCC Unified V16 runtime. V16 was the first version in which the Unified runtime was released for general PC-based SCADA use; earlier V15.1 builds were limited to Unified Comfort Panels. Refer to the official Siemens TIA Portal V16 release notes and readme for the exact feature set, supported operating systems, and known restrictions at GA.

Subsequent versions of TIA Portal (V17, V18, V19, V20) added new device classes, GraphQL, ProDiag, and expanded tag counts. The figures quoted here are the V16 ceiling. When sizing, always reference the Siemens Industry Online Support portal for the active version's readme because the project size limit is a licensing ceiling, not a hard-coded runtime cap.

2. Tag Architecture: PowerTags, Tags, and Project Sizing

WinCC Unified distinguishes between Tags (internal driver tags, structured tags, indirect addressing) and PowerTags (process tags that count against the licensed quantity). Every external PLC tag, every archive tag, and every alarm tag consumes PowerTags; internal constants and graphics list entries do not.

For a V16 SCADA project, the practical upper bound for a single PC runtime is 5000 PowerTags when the project is enabled for the maximum project size. If the actual count exceeds the licensed quantity, the runtime enters a demo mode at start-up; it runs but displays a watermark and refuses to license beyond the trial. Always match the license to the engineering count plus a 10-20% engineering reserve, not to the marketing ceiling of the runtime.

2.1 Counting Discipline

To count PowerTags reliably in V16:

1. Compile the project in TIA Portal.
2. Open the Project tree → Runtime settings → Tag table statistics.
3. Filter to External tags only; sort by PowerTag column.
4. Add the configured archives (logging tags) and configured alarms (message tags) on top of the external count.
5. Subtract internal tags, constants, and text lists.

3. Licensing Model and Cost Structure

WinCC Unified V16 uses a PowerTag-license model, sold in tiered packages. The exact part numbers and current list prices are published on the Siemens Industry Mall and are subject to regional adjustment; the figures below are representative of the V16-era entry points and should be verified at order time. The license model consists of two layers:

1. Base runtime license — the SCADA server itself (the V16 PC runtime).
2. PowerTag license — incremental pack of process tags in fixed sizes (100, 500, 1000, 5000, 32000 in later versions).

If variable logging is required, the corresponding logging tags must be licensed as PowerTags. The WinCC Unified V16 base package does not include process diagnostics, energy management, or audit trail; these are sold as option packages and must be added when the scope requires them. To verify a current offer, request a quote against a WinCC Unified V16 (or successor) project file in the Siemens configuration portal for the target country.

4. Runtime Architecture: Web Server Model

WinCC Unified V16 re-architects the runtime as an HTML5 web server rather than a Windows-native SmartServer. The PC runtime publishes screens, alarms, archives, and trends over HTTPS; clients (Chrome / Edge / WebKit on iOS) connect to the runtime URL and receive the HMI surface as a single-page application. The implications are significant for system design:

• Zero install on clients. A new operator station is a browser shortcut to the runtime URL.
• Mixed device support. A single project serves industrial PCs, plant-floor touch panels, office workstations, and mobile devices.
• Web widget embedding. Screens can host third-party HTML / JavaScript controls without recompilation.
• Scripting model. VBScript (legacy) and JavaScript (Unified) are both available; JavaScript is the strategic path going forward.
• Server-side state. Screens and current values live on the runtime, not on the client; closing a browser does not lose the current view.

4.1 Network Layout

The runtime listens on HTTPS (TCP 443) by default. Typical deployment topology:

• Control network (OT): S7-1500 PLCs, IO, drives — terminated at the engineering cell switch.
• SCADA server: PC runtime, antivirus, time sync (NTP), UPS — single subnet connection to control network and plant LAN.
• Plant LAN / WLAN: client browsers, supervisor workstations.
• Optional DMZ: external remote access via terminal server or read-only Web Client on segregated VLAN.

Do not expose the SCADA runtime directly to the internet. Even with HTTPS, the runtime has no native IP allow-list; the standard mitigation is a reverse proxy with TLS termination and ACL, or a terminal server for remote operators. See IEC 62443-3-3 for zone and conduit guidance; the IEC standards portal holds the full text.

5. Engineering Workflow in TIA Portal V16

The Unified editor in TIA Portal V16 uses a single project to hold PLC, HMI, and SCADA logic. This unifies tag propagation — a change to a PLC UDT propagates to all HMI references without manual re-linking, as long as the UDT is shared. The workflow for a new project is:

1. Create the TIA Portal V16 project and add the S7-1500 station with the PLC tags / UDTs.
2. Add the WinCC Unified PC station, choose the device type (PC Unified V16), and set the project size in Runtime settings.
3. Define HMI tags; mark those that count as PowerTags by binding to PLC connections.
4. Configure the connection to the S7-1500 (PROFINET / S7 / OPC UA).
5. Build screens, faceplates, and the alarm / archive configuration.
6. Compile, simulate with the Unified RT simulator, and download to the runtime PC.
7. Transfer the license file (.upd) via the Automation License Manager.

Simulation is a key advantage: the Unified Comfort Panel simulator and the PC runtime simulator both run inside TIA Portal V16 on the engineering workstation, which shortens the loop between edit and verify. Cross-reference the TIA Portal V16 WinCC Unified system manual for the exact simulator behaviors and licensing implications of the simulator vs. real runtime.

6. JavaScript and Web Control Integration

WinCC Unified V16 supports JavaScript in two roles: as a screen scripting language and as a custom web control host. JavaScript screens can read and write HMI tags through the Unified API, call ODK (Open Development Kit) functions, and consume third-party REST endpoints. This is a meaningful departure from VBScript in WinCC Comfort, because it opens the runtime to standard web tooling.

Typical use cases:

• Embedding an external charting library (e.g., an HTML5 trend widget) inside a screen.
• Calling a MES REST API from a faceplate to confirm a production order before enabling a button.
• Rendering SVG-based custom graphics that respond to live tag values.
• Implementing business rules that the PLC should not be expected to host.

7. Comparison with Legacy and Competing SCADA Systems

Controls engineers frequently evaluate WinCC Unified against the InTouch / System Platform, Citect, iFIX, and FactoryTalk View families. The decision is rarely about the runtime engine; it is about the ecosystem: tag propagation, version control, and the cost of license expansion. The table below compares the engineering profile of each system; the financial profile (license cost, annual support, upgrade cadence) varies by region and must be quoted case by case.

The key point is not which product is "best" but which product has the lower total cost of ownership in a given plant context. In an all-Siemens plant, WinCC Unified inside TIA Portal V16 shortens the engineering loop and reuses the same tag database. In a mixed-vendor plant, a vendor-neutral SCADA such as InTouch / System Platform or AVEVA may be cheaper to integrate. The capital cost of the SCADA is typically smaller than the engineering cost over the project life; the selection should weight that.

8. Open-Source SCADA Alternatives

For non-regulated, smaller-scale applications, several open-source SCADA platforms offer reasonable capability. The two most cited in European controls communities are RapidSCADA and OpenSCADA. They differ significantly in architecture, language, and license.

8.1 RapidSCADA Practical Notes

RapidSCADA exposes a web UI by default, which makes it a natural fit for sites that already have a web client preference. Communication drivers include Modbus, OPC, IEC 60870-5-104, and several proprietary PLC protocols. To productionize it:

1. Deploy on a Windows Server or hardened Linux box with NTP sync.
2. Front-end the web UI with a reverse proxy and TLS.
3. Configure periodic configuration export to a version-control repository.
4. Define a service-level agreement with the integrator for hot-fixes.

9. Node-RED as a SCADA Communication Backbone

Node-RED is a flow-based development tool built on Node.js. While it is not a SCADA in the sense of an HMI runtime, it is increasingly used as the communication and protocol-translation layer in front of a SCADA engine. Common roles include:

• Converting between Modbus TCP / OPC UA / MQTT / REST.
• Buffering and timestamping values before forwarding to the SCADA database.
• Aggregating multiple PLCs into a single tag space for a higher-level SCADA.
• Implementing the MQTT broker that an IIoT gateway uses to publish to the cloud.

The combination Node-RED + RapidSCADA is a frequent low-budget SCADA stack for non-critical applications. For higher reliability, Node-RED is often used as a sidecar to WinCC Unified: it publishes a consolidated MQTT topic, and a Unified script subscribes via the ODK or via a third-party MQTT driver to forward into the runtime tag space. This pattern is documented in industry white papers; consult the Node-RED official documentation for protocol drivers and the MQTT specification for QoS guidance.

10. Linux SCADA Reality Check

Despite the maturity of the Linux ecosystem for industrial servers, no major commercial SCADA ships as a first-class Linux product. AVEVA Edge (formerly InTouch Edge), WinCC, and iFIX all require Windows for the server runtime. Linux appears in three legitimate roles:

1. Historian / data lake: AVEVA Historian has a Linux option; OSIsoft / AVEVA PI runs on Linux; InfluxDB and TimescaleDB on Linux back many open-source stacks.
2. Protocol gateway: Node-RED, Ignition Edge on Linux, Kepware, or custom Python services running on industrial Linux boxes (e.g., Siemens IOT2050, Harting MICA).
3. Web visualization: a Linux server hosting Grafana or a custom React / Angular front end reading from a historian.

The full SCADA stack on Linux is achievable with open-source tools, but the engineering and validation cost usually exceeds the license savings of a commercial Windows SCADA for a regulated plant. For research, lab, and pilot installations, however, a Linux-only stack (OpenSCADA + Node-RED + Grafana + InfluxDB) is a defensible choice.

11. Selection Workflow: Decision Matrix

Use the matrix below as a starting point for SCADA selection. Score each criterion 1-5 for the candidate product and weight by project importance.

The weighted total guides the selection. For an all-Siemens automotive plant, WinCC Unified V16 in TIA Portal almost always wins. For a multi-vendor water utility, an open-source or vendor-neutral SCADA wins on cost. For a pharmaceutical facility, vendor support and validated versions dominate.

12. Commissioning and Verification Checklist

For a WinCC Unified V16 SCADA project, the following verification steps should be executed before site acceptance. They are not optional; each maps to a class of commissioning failure that is hard to recover from in production.

1. License transfer: confirm the Automation License Manager reports the full PowerTag count, not demo mode.
2. PowerTag accounting: export the compiled tag count and match to the license.
3. Connection test: from the SCADA server, ping every PLC and read a known value from each.
4. Alarm generation: force a process alarm from the PLC and verify the message appears within the configured acquisition cycle.
5. Archive write: trigger a process variable change and confirm the log row is written within one cycle.
6. Web client: open the runtime URL in Chrome from a non-server workstation, log in with a non-admin account, and verify role-based screen visibility.
7. Failover: if redundant, kill the active server and confirm the standby takes over within the configured timeout.
8. Time sync: confirm the SCADA server is NTP-synchronized to the plant time source, not the workstation local clock.
9. Backup: schedule a daily project export and a runtime configuration snapshot to a network share.

13. Migration Path from Legacy WinCC

Engineers often inherit a legacy WinCC V7 (or older WinCC Flexible) project and must move to Unified V16 or later. The migration toolset in TIA Portal supports a partial migration, but it is not lossless. Plan the migration as a project, not a tool click.

For a sizable legacy project, allocate 30-50% of the original engineering time for the migration, plus regression testing against the original. Treat it as a new project that happens to look like the old one.

14. Field-Proven Caveats

Across multiple V16 deployments, the following issues recur. Address them in the design phase, not the field:

• PowerTag count surprises. UDT expansion and archive tags push the count above the license tier. Always license to actual count + 20%.
• JavaScript execution order. Multiple scripts on one screen can fire in non-deterministic order under load. Centralize logic in faceplate scripts where possible.
• Chrome / Edge version drift. The runtime depends on specific browser versions; constrain the operator station browser via GPO and disable auto-update.
• Time zone handling. The runtime stores UTC; the client renders local time. An operator in another time zone sees a different timestamp. Document this and align the project's time display conventions.
• Web client session limits. Default concurrent session limits in V16 are conservative. Confirm with the project size setting; undersizing causes silent client disconnects.
• Archive storage: default ring-buffer on the local drive is not sized for plant life. Configure a network share and a documented retention policy.

15. FAQ