When an AVEVA System Platform Galaxy misbehaves, the symptom is often far from the cause: a deploy that times out, an IDE that cannot reach the Galaxy Repository, or a redundant AppEngine pair that reports missed heartbeats. AVEVA's System Platform documentation describes the checks in its deployment guide and diagnostics pages. This article puts them in the order we work through a running Galaxy: names and addresses, the Network Account, communication settings, deployment order, redundancy and attribute quality. It is based on AVEVA's System Platform 2023 R2 SP1 P04 documentation; for InTouch-level faults see InTouch HMI troubleshooting.
1. Names and IP addresses between nodes
AVEVA's deployment guide asks for one condition that is easy to miss: every node in the Galaxy must reach every other node by both its host name and its IP address, whichever network address type the WinPlatform uses. Where computers have fixed IP addresses, AVEVA says to add the name-to-address mapping to the hosts file. If either check fails in one direction, AVEVA warns that the IDE may not connect to a remote Galaxy Repository and deployments may fail.
The same guide recommends two network cards on computers that host I/O communication drivers, for load balancing and redundancy, and a dedicated control network for PLC traffic.
2. The Network Account
The Network Account (called ArchestrA User in earlier releases) is the Windows account that lets System Platform computers talk to each other. AVEVA's rules for it:
- The same Network Account must be used on every node that communicates.
- If an existing account is used, its password must never expire and must not be changed.
- It must not be deleted with Windows account tools, or System Platform may stop working.
- For a domain account, use the short domain name, not the fully qualified name.
- By default the account cannot log on locally or through Remote Desktop.
An expired or changed password on this account is one of the first things to rule out when nodes stop communicating after a period of normal operation.
3. Communication settings on the WinPlatform
The $WinPlatform object has Message Exchange (MX) attributes that AVEVA suggests tuning when bandwidth is limited, the connection is intermittent or the Galaxy has thousands of instances:
| Attribute | Default | AVEVA's suggested starting point |
|---|---|---|
| Message time-out | 30,000 ms | 300,000 ms, to avoid time-outs when deploying many instances |
| NMX heartbeat period | 2,000 ms | 2,000 ms |
| Consecutive missed NMX heartbeats allowed | 3 | 4 on Automation Object Servers, the Galaxy Repository and visualisation nodes, to avoid false failovers |
AVEVA presents these as starting values for tuning, not fixed settings.
4. Deployment order in large Galaxies
System Platform deploys objects in cascade, in hierarchical order. AVEVA defines a large system as roughly 20,000 to 50,000 I/O points and a very large one as 50,000 or more. For a large system, AVEVA recommends cascade deployment from the platform level, with platforms hosting primary engines deployed before those hosting backup engines. For a very large system it gives a sequence using multi-select: the Galaxy Repository platform, all other platforms, primary AppEngines, backup AppEngines, then the primary engines for I/O, skipping objects already deployed.
5. Redundant AppEngines: what a network failure does
AVEVA's redundancy tables show how a pair reacts to each failure. Two points come up often on site:
- A failure on the Redundant Message Channel (RMC) between the pair does not trigger a failover. The active engine keeps running, its status becomes Active with the standby not available, and the partner status becomes unknown.
- In a peer-to-peer topology with only the two platforms of the pair, a failure on the supervisory network does not trigger a failover either: the partner status shows missed heartbeats while the pair keeps synchronising over the RMC, and a failover has to be forced manually or by script.
The attributes to watch are RedundancyStatus and RedundancyPartnerStatus on the AppEngine.
6. Attributes and diagnostic tools
Object Viewer shows deployed objects and their attributes at run time and can change a value for testing. It opens from the IDE, from the Operations Control Management Console under Platform Manager, or from a command prompt with aaObjectViewer.exe; the /New switch starts it in advanced diagnostic mode. AVEVA notes that saving a watch list with Ctrl + S creates an empty file, so use the right-click save instead.
In scripts, AVEVA recommends the quality test functions IsGood, IsBad, IsUncertain, IsInitializing and IsUsable rather than comparing the quality value with numbers such as 192 for Good.
For the network itself, AVEVA's diagnostics page points to ping and tracert: round-trip times generally under 200 milliseconds, the spread between minimum and maximum, dropped packets, and changes in TTL that suggest replies are taking different routes. We also use Windows Performance Monitor and Event Viewer alongside these.
7. Read the known issues of your patch level
AVEVA publishes known issues per patch. For example, it lists a licensing issue where a System Platform 2023 R2 SP1 node that also has AVEVA Work Tasks 2023 R2 cannot start the IDE after Patch 02 is applied, with a workaround that copies two files and restarts the node. When a fault appears right after a patch, the known issues list of that patch is worth reading before anything else.
How TDL approaches it
TDL Industrial Automation is listed in AVEVA's Partner Finder as a System Integrator in the AVEVA Partner Ecosystem. We work inside running Galaxies, including the facility and power monitoring systems at Samsung SEHC, maintained under a yearly contract, and the System Platform displays of the biomass system at Nestlé Tri An. Before changing a Galaxy we back it up and record the version and patch level of each node. More on this service: AVEVA (Wonderware) system integrator in Vietnam.
Frequently asked questions
Why can the IDE not connect to the Galaxy Repository on another computer?
AVEVA requires every node to reach the others by both host name and IP address. If either fails in one direction, the IDE may not connect to a remote Galaxy Repository and deployments may fail; with fixed IPs, add the names to the hosts file.
What should the Network Account password policy be?
AVEVA requires a password that never expires and is not changed, the same account on every node, and the account must not be deleted with Windows tools.
Does a Redundant Message Channel failure cause a failover?
No. The active engine keeps running with the standby shown as not available; in a two-platform peer-to-peer setup, a supervisory network failure does not cause a failover either.
How should a script test attribute quality?
With the quality functions such as IsGood() or IsBad(), which AVEVA recommends over comparing the quality value with numbers like 192.
Sources
- AVEVA, Communication, System Platform 2023 R2 SP1 P04 deployment guide
- AVEVA, Network account and About network account privileges
- AVEVA, Improve communication with remote nodes
- AVEVA, Deploying objects in a large or very large system
- AVEVA, Communication failure in the supervisory (primary) network and RMC communication failure
- AVEVA, Object Viewer, Test for attribute quality and Diagnostics
- AVEVA, Licensing known issues
Read 13 November 2026. This article paraphrases the sources and does not quote them; read the original documents before designing or working on a system.