WinCC OA Server-Client Sizing: 6AV6351 Part Numbers & PowerTags

SIMATIC WinCC OA: Platform Definition and Engineering Role

SIMATIC WinCC Open Architecture (WinCC OA) is Siemens' distributed, event-driven SCADA platform engineered for large-scale plant supervision, energy dispatch, transportation tunnels, water networks, building automation, and process industries requiring tens of thousands to hundreds of thousands of datapoints across geographically distributed sites. WinCC OA originated as PVSS II (Prozessvisualisierungs- und Steuerungssystem), the flagship SCADA product of ETM professional control GmbH (Erlangen / Pfaffstätten, Austria), which Siemens integrated into the SIMATIC HMI portfolio. The platform retains the underlying architecture and CTRL scripting language from its PVSS heritage while adopting SIMATIC product identifiers and the 6AV6 catalog family. It is positioned above the TIA Portal WinCC tier (WinCC Comfort / Advanced / Professional) and below SIMATIC PCS 7 / PCS neo, occupying the "Extra Large" SCADA segment.

WinCC OA is not a soft PLC HMI nor a single-machine WinCC Runtime - it is a multi-server, multi-client, distributed control room. The runtime is built around a manager concept: every functional subsystem (data manager, event manager, DB manager, driver manager, alert manager, UI manager, redundancy manager) is a discrete process that can be distributed across hardware nodes. Because of this, projects in the PowerTag count range of 100 sit well below the platform's natural comfort zone; nevertheless, the same part numbers and license model apply, and the smallest published PowerTag tier is exactly the size a 100-tag three-machine project would consume.

The engineering entry point is the WinCC OA Engineering tool, installed alongside the WinCC OA Console on the configuration machine. Engineering is project-based: the project contains the datapoint model (DPTs / DPEs), the graphic panels, the historical RDB schema, the alarm classes, the user management database, and the CTRL scripts. The project is version-managed through a subversion-based archive, exported to the runtime by the WCCOAprj tool, and activated on the server by the Console.

WinCC OA vs WinCC (TIA Portal): Choosing the Right SCADA Tier

The SIMATIC HMI / SCADA portfolio is divided into five functional tiers, each with a discrete product family, license model, and engineering toolchain. Choosing the wrong tier for a sub-100 PowerTag project typically results in 3x to 10x excess integration cost without functional benefit. The tiers are summarized below.

For a project with three machines, one PLC each, one HMI each, with selected process tags exposed to a remote PC plus historical trending and alarm archiving, tier 2 or tier 3 is the engineering baseline. WinCC OA tier 4 should only be selected if at least one of the following architectural constraints is true:

• The data must be aggregated from a controller or third-party system that WinCC OA's native drivers cover better than WinCC Runtime Professional's (e.g. IEC 60870-5-104 from substation RTUs, DNP3 from North American telemetry, BACnet from building automation).
• The deployment requires more than 32 simultaneous clients across multiple sites.
• The system must scale into hundreds of thousands of datapoints in later project phases.
• The customer's corporate standard mandates WinCC OA on all SCADA deployments.
• The runtime must be virtualized on a large VMware / Hyper-V farm with a centralized Oracle-based historical archive.

If none of these constraints applies, the correct Siemens part number family is 6AV21xx (WinCC Runtime) within the TIA Portal catalog, not 6AV6351 (WinCC OA). See the SIMATIC HMI portfolio page for the current product map.

Distributed Server-Client Architecture

WinCC OA is a manager-based distributed runtime. Every functional block - data point manager, event manager, database manager, driver manager, redundancy manager, UI manager, alert manager - runs as an independent process that can be deployed on a different physical or virtual node. Communication between managers is handled by an internal TCP-based event bus; this is what makes the platform horizontally scalable to the 2048-server physical limit.

The principal architecture components are:

• Server: Holds the datapoint model (DPTs / DPEs), executes control logic, hosts the historical database (Oracle RDB or file-system HDB), and exposes data to clients. One server per project is the standard configuration, but a single project can span many servers in a distributed system.
• Console: A server with an attached engineering and operator station role. The console is the primary node for configuration, online diagnostics, para module access, and parameterization. In a small project the console and the server can be the same machine.
• Client: An operator station (UI) that subscribes to datapoint updates from a server. Clients are read-write for the datapoints they have permission to change; the server remains the authority. A thin client is supported via Citrix / RDP; a web client is available with the WinCC OA Web option.
• Distributed System: A logical grouping of multiple servers that share a single datapoint model across sites, with automatic datapoint routing. Up to 2048 servers can belong to a single distributed system; engineering reality sits closer to ~550 nodes before latency and bandwidth dominate.
• Redundancy Pair: Two servers configured for hot-standby failover. The active server handles all requests; the standby server keeps an in-memory copy and the historical database mirrored. Failover is sub-second and transparent to clients.

For a three-machine trending application, a single server with three clients is the minimum topology. Whether the server is the same physical machine as the engineering console or split to a separate box is a deployment decision driven by the WinCC OA Console license, not by the Server license. The redundancy option (two servers in hot-standby) is generally skipped at this scale unless the customer requires 24/7 alarm acknowledgement with no data loss.

Decoding the 6AV6351 Part Number Family

All WinCC OA licenses are sold under the Siemens MLFB prefix 6AV6351. The structure is:

6AV6351 - 1 [Function] [Tier] [License] - [Variant] AA0

The three part numbers raised in the source break down as follows:

System Specifications and Engineering Limits

The published engineering limits of WinCC OA V3.x are summarized below. These limits are the basis of all sizing decisions; the "Dependent on the system configuration" footnotes are not optional - they are the rule under which the platform is sold.

PowerTag Licensing Model and Counting Rules

WinCC OA licensing is datapoint-licensing. A PowerTag is a single datapoint element that has a value (real, integer, bool, string, blob, time) and a configuration. The license model is based on the number of datapoints created in the project, not on the number of external (PLC) tags. The following counting rules are the source of most license-budget overruns on WinCC OA projects:

1. Internal structure elements count individually. A single S7 DB with 50 BOOLs imported via the S7 Plus driver expands to 50 PowerTags - one per BOOL bit position - not one per DB. Use the DPs (summary) panel in the para module to verify the count.
2. Sub-elements of a structure count individually. A REAL array of length 10 inside a datapoint expands to 10 PowerTags.
3. Driver internal tags count. The S7 Plus driver creates internal tags (connection state, error code, last-updated timestamp, per-tag status) that consume PowerTags. A driver for 50 external tags typically adds 100-300 internal tags.
4. Alarms do not consume PowerTags but they do require an Alert license. A project that adds alarm handling on top of trending is an additional MLFB.
5. Historical datapoints (HDs) are licensed separately from PowerTags. If the project needs to archive 50 PowerTags into the historical database, 50 HD licenses are required on top of the 50 PowerTags.
6. Internal calculation tags count. A calculated alarm rolling-average datapoint counts as one PowerTag.
7. Connection datapoints count. A driver connection is itself a datapoint (the "_Connection." element of the driver). At least one per driver instance.
8. System datapoints count. The _System datapoint family (server status, manager status, RDB state) consumes PowerTags and is included in the count.

For a "under 100 PowerTags" project, the external tag count is the starting point. With three SIMATIC S7 PLCs and ~30 selected process tags each, the external tag count is ~90. Adding S7 Plus driver internals (status, error, last-update, per ~30 external), the PowerTag count lands at ~150-200. The smallest published PowerTag tier (the 1AA30 / 1A30 MLFB) is sized to handle this with margin.

Part Number Selection for the Three-Machine Trending Project

The recommended configuration for a project with 3 PLCs, 3 HMIs, 1 SCADA server, 3 clients, historical trending, alarm archive, and < 100 external process tags is the following BOM:

The 6AV6351-1EA31-1AA0 part number is structurally a client license; the difference from -0AA0 lies in the license-scope suffix. For a project of this scale, the two MLFBs are functionally interchangeable from a runtime perspective - the difference is commercial (bundle vs standalone procurement, SUS scope). Confirm the exact license scope with the Siemens Industry Mall quotation, not from the part-number string alone.

Connectivity: SIMATIC S7, OPC, Modbus, and Beyond

WinCC OA's protocol coverage is the principal reason it is selected over WinCC Runtime Professional. The driver catalog includes native support for the following:

For three S7 PLCs, the S7 Plus driver is the primary connection. The driver supports parallel S7 connections, optimized block read/write, and direct symbol access from a TIA Portal export (via the Symbol Import tool). The S7 Plus connection datapoint holds the connection state, error code, and last-update timestamp as internal PowerTags - these are visible in the para module and are included in the PowerTag license count.

A typical S7 Plus connection block looks like:

ConnectionName:      S7_PlantLineA
ConnectionType:      S7 Plus
IpAddress:           192.168.10.20
Rack:                0
Slot:                1
TsapLocal:           01.00
TsapRemote:          01.01
ConnectionResource:  1
PollGroupMs:         500

The PollGroupMs parameter governs the read cycle for tags not in the on-change (event-driven) group; the default 1000 ms is correct for trending. Sub-200 ms is not recommended for S7 Plus - it can saturate the S7 connection resource on the PLC side. Event-driven (spontaneous) updates require the PLC to support S7 put-aput-get and the datapoint to be flagged for the on-change group in the para module.

CTRL Scripting, Event Manager, and Control Logic

WinCC OA control logic is written in CTRL, a C-like scripting language interpreted by the Event Manager. Unlike ladder or ST on a PLC, CTRL scripts run in the SCADA server's address space and respond to datapoint value changes rather than scan cycles. This is what makes the platform "event-driven" - a CTRL function is invoked when a subscribed datapoint's value, quality, or timestamp changes, not on a periodic scan.

Two principal CTRL constructs are used in 90% of projects:

main()
{
   float v1, v2;
   getValue(v1, "PlantLineA.Tank1.Level");
   getValue(v2, "PlantLineA.Tank1.LevelHigh");
   if (v1 > v2)
   {
      setValue("PlantLineA.Alarm.LevelHigh", TRUE, 1);
   }
   else
   {
      setValue("PlantLineA.Alarm.LevelHigh", FALSE, 0);
   }
}

The same logic can be written as a database trigger for better performance - the trigger fires on the underlying DB row change, eliminating the per-event manager dispatch overhead. CTRL scripts are also used for command processing (write authorization, interlock logic), batch sequence control, and external interface (TCP socket, file I/O) integration. The Event Manager runs as a single process on the server; for hot-standby redundancy the standby runs the same scripts on the mirrored datapoint state and takes over within one poll cycle of a failover.

Historical Database: HDB vs Oracle

WinCC OA supports two historical backends:

• HDB (file-system based): A purpose-built binary archive stored on the local file system. Each historical datapoint is stored in a fixed-size data file; older files are rotated based on the configured retention period. The HDB is included with the server license at no additional cost and is the recommended backend for projects under ~10,000 PowerTags. Query performance is excellent for time-range lookups; the limitation is single-node scaling - a single HDB instance cannot span multiple servers.
• Oracle RDB: An Oracle 19c (or later) database used as the historical backend. Oracle is licensed separately and is required for multi-server cluster configurations, centralized historian across distributed systems, and enterprise-grade query, backup, and replication. Oracle is also required when the historical archive must be queried by external BI tools (Power BI, Tableau) or by an external MES.

For a sub-100-PowerTag project with a single server, the HDB is the correct choice. A daily HDB backup to a network share provides disaster recovery; the on-disk format is self-describing and the restore is a file copy followed by a metadata rebuild. Retention periods are configured per log in the para module; typical settings are 90 days for fast (1-s) archives, 1 year for slow (1-min) archives, and 5 years for summary (1-hour) archives.

WebUX, Mobile, and Web Client Options

WinCC OA offers a browser-based operator UI called WebUX. WebUX is a thin-client renderer of the WinCC OA graphics; it runs in any modern browser (Chrome, Edge, Firefox) without a plugin and supports the same datapoint read/write that the native client supports. WebUX is licensed separately under the 1F (Web Client) MLFB family.

For a three-machine project, WebUX is rarely required - the three dedicated client PCs already cover the operator stations. WebUX becomes relevant when:

• An additional read-only operator station is needed on a non-Windows machine (Linux, macOS, iPad).
• Managers want to view the SCADA from outside the plant network via VPN.
• The project has 50+ ad-hoc users (maintenance, engineering, plant manager) that would not justify 50 client licenses.

WebUX is a renderer, not a separate SCADA - the datapoints, history, and alarms are the same WinCC OA server. The WebUX connection is over HTTPS (port 443) with TLS, and user authentication is the same user management RDB as the native client. See the Siemens Industry Online Support portal for the WebUX manual and current browser support matrix.

Cybersecurity: TLS, Certificates, and User Roles

WinCC OA V3.16+ supports TLS-encrypted manager-to-manager communication using X.509 certificates issued by a project-specific CA. The certificate is generated by the WinCC OA Certificate Authority tool, distributed to each manager, and used to authenticate the TCP event-bus connections. Without TLS, all manager-to-manager traffic is plaintext on the LAN - acceptable on a physically isolated plant network, unacceptable for any deployment that crosses an IT/OT boundary or uses an industrial wireless segment.

User authentication is centralized in the user management RDB (typically the file-system UDB for small projects, Oracle for plant-grade). User roles are configurable per project; typical roles are Operator (read-only on most datapoints, write on operator-allowed datapoints), Engineer (full read/write, no para change), Administrator (full read/write, para change, user management), and Auditor (read-only with audit-log write). Each user action is logged to the audit trail with timestamp, user, source IP, and datapoint - the audit trail is itself a historical datapoint and is archived in the HDB or Oracle.

Hardware, OS, and Virtualization Requirements

WinCC OA runs on Windows Server 2019 / 2022 (server) and Windows 10 LTSC / Windows 11 (client / console). The exact supported Windows build is defined by the WinCC OA version (V3.18+ at the time of writing) and is documented in the WinCC OA Installation manual on the Siemens Industry Online Support portal. The minimal hardware matrix for a sub-100 PowerTag project:

WinCC OA supports virtualization (VMware vSphere, Microsoft Hyper-V, KVM) and has reference architectures for virtualized server-client deployments. CPU and memory overcommit must be sized against the project's value-change rate; a vCPU-to-pCPU ratio above 4:1 on the server typically degrades the event-manager response time. Oracle-based HDB requires Oracle 19c or later when used; the file-system-based HDB (recommended for projects under 1,000 PowerTags) needs no external database software.

Sizing Example: Three-Machine Trending Project

Working through the use case in concrete terms - three machines, one PLC each, ~30 selected process tags per machine, S7 Plus connection, historical trending, alarm archive, one SCADA server, three clients:

1. External tag count. 3 machines × 30 selected process tags = 90 external tags.
2. Connection datapoints. 3 S7 Plus connections (one per PLC) = 93 PowerTags.
3. Driver internals. ~150 internal tags (status, error, last-update, per ~30 external) = 243 PowerTags.
4. Calculated tags. ~20 internal tags for trending rollups (1-min average, 15-min average, totalizer, deviation) = 263 PowerTags.
5. System tags. ~30 system tags (manager status, server CPU, RDB latency) = 293 PowerTags.
6. License tier. 293 PowerTags sits in the smallest published PowerTag tier (1AA30). Verify with the para module (DPs (summary)) after first import.
7. Historical archive. 90 historical datapoints (HDs) for trending. The 1AA30 server license includes the HDB module; verify the HD count limit in the same tier.
8. Alarms. ~30 alarm datapoints (high-temperature, low-pressure, door-open, motor overload, communication-loss). Alert module license is included in the server tier but verify with the order.
9. Topology. 1 server + 1 console (same machine) + 3 client PCs. No redundancy, no distributed system, no web client.
10. BOM (final). 1 × 6AV6351-1AA30-0AA0 + 1 × 6AV6351-1CA30-0AA0 + 3 × 6AV6351-1EA31-0AA0.

Total perpetual license cost is dominated by the three client seats; the server + console combination is the smallest unit Siemens ships. As a sanity check, a comparable WinCC Runtime Professional configuration (TIA Portal, single PC, 256 PowerTags) is typically 30-50% of the WinCC OA BOM at this scale.

Commissioning and Verification Checklist

Once the BOM is on order and the hardware is in place, the following verification steps confirm the deployment is correctly sized and licensed. Run them in order; do not skip the license activation step before importing the project.

1. License activation. Use the WinCC OA Console's License menu (or the WCCOAlic tool from the command line) to enter the license key. The SLD (Software License Download) key arrives by email from Siemens; the SUS contract governs update eligibility.
2. PowerTag audit. Open the para module, select the project, and run DPs (summary). Compare the actual PowerTag count against the licensed tier. If the count exceeds the tier, upgrade to the next tier MLFB before commissioning.
3. Driver connection test. Right-click each S7 Plus connection in the para module, select Test. The connection state should report Connected, error code 0, and a recent last-update timestamp. A non-zero error code at this point indicates a TSAP mismatch, a PLC-side connection resource limit, or a firewall blocking port 102 (ISO-TSAP) / 1025-1030 (S7 Plus secondary ports).
4. Alarm test. Trigger a configured alarm by writing a value above the alarm threshold from the TIA Portal side. Confirm the alarm appears in the Alert screen, the chronological log, and the historical RDB. Verify the alarm text matches the configured pattern.
5. Trend test. Open a trend configured on a historical datapoint. Confirm the trend shows current and historical values, and that the historical values match the raw datapoint state when zoomed in. A common commissioning error is a wrong HD configuration (polling cycle, retention period) that causes the trend to display flatlines.
6. Client test. Log in to each of the three client PCs, open the same project, and verify the UI loads, the trend populates, and a write to a datapoint from one client is reflected in the other two within the configured update cycle.
7. Performance baseline. Run the WCCOApmon performance monitor for 24 hours under normal load. Document value-changes-per-second, manager CPU, RDB write latency, and event-queue depth. Use this as the project baseline and as the comparison point for any future performance complaints.
8. Backup verification. Configure the HDB backup per the WinCC OA Administrator manual. For a sub-100-PowerTag project, a daily file-system HDB backup to a network share is sufficient. After the first backup completes, restore to a test machine and verify the project loads and the trends populate.
9. Cybersecurity verification. If TLS is required, verify the certificates are installed on every manager node, the event-bus is encrypted, and the external WebUX port is closed when not in use. Run an nmap from an external machine to confirm no unintended ports are open.

FAQ