InTouch HMI or System Platform: standalone and managed applications, the Galaxy and AVEVA's sizing rules

When a plant extends or replaces an AVEVA (Wonderware) HMI, the first design question is whether InTouch HMI on its own is enough or whether the application should move into System Platform. AVEVA's documentation does not answer it with a single rule, but it gives the facts that decide it: the two kinds of InTouch application, what a Galaxy adds, the sizing limits of each node, and which computer suits which role. This article puts those facts side by side from AVEVA's InTouch HMI and System Platform 2023 R2 SP1 P04 documentation. For the product family and the history of the Wonderware name, see What is AVEVA.

1. Two kinds of InTouch application

AVEVA separates standalone and managed InTouch applications:

The import path matters for an existing plant: a standalone application that has run for years can be brought into the IDE as a managed application instead of being redrawn.

2. What a Galaxy adds

A managed application lives in a Galaxy, and a Galaxy brings three things that standalone InTouch does not have:

• A central configuration database. The Galaxy Repository stores the configuration in Microsoft SQL Server, one database per Galaxy, and keeps every node informed of global changes such as the security model.
• A deployment model. Each computer in the System Platform network has a WinPlatform, an AppEngine and an Area deployed to it, and objects are assigned to areas, so the engineer decides which computer runs which part of the plant.
• Redundant engines. AppEngines can run as a primary and backup pair; AVEVA's redundancy tables describe how the pair behaves on each network failure, and our System Platform troubleshooting article covers the common cases.

3. AVEVA's sizing rules

AVEVA's system sizing guidelines set limits that apply whichever way the application is built:

• A 64-bit operating system is required for any system size, and a Windows Server operating system is required for large installations.
• SQL Server Express is supported only for small systems, meaning fewer than 25,000 I/O per node.
• Each active AppEngine needs one logical processor and runs as a 32-bit process.
• AVEVA recommends one logical processor for each engine of a redundant pair; both may share one logical processor only while they use less than 40% of CPU and memory, otherwise the node risks overload at failover.
• An AppEngine typically hosts from 5,000 to 50,000 objects, depending on attributes, scripts and graphics.

AVEVA's deployment guide defines a large system as about 20,000 to 50,000 I/O points and a very large one as 50,000 or more.

4. Which computer for which role

AVEVA's table of node types marks, for each component, the type of computer it prefers:

The same table marks most roles as supported on an all-in-one computer, which is how small systems often start.

5. How we decide

These are TDL's working habits, not AVEVA requirements:

• Number of areas that share equipment types. Templates pay off when the same pump, valve or motor appears on many lines; one machine or one small area rarely needs a Galaxy.
• What already runs. An existing standalone application can be imported into the IDE, so moving to System Platform does not mean redrawing every window.
• I/O per node. Near the 25,000 I/O limit of SQL Server Express, the database edition becomes part of the design.
• Redundancy. A process that must keep running through a server failure points to redundant AppEngines, and so to System Platform.

How TDL approaches it

TDL Industrial Automation is listed in AVEVA's Partner Finder as a System Integrator in the AVEVA Partner Ecosystem. We have worked with both: a Wonderware application on the Maggi line upgrade at Nestlé Dong Nai, and System Platform at Samsung SEHC and on the biomass system at Nestlé Tri An. More on this service: AVEVA (Wonderware) system integrator in Vietnam.