This article from InSource focuses on a sample setup of AppEngine Redundancy, and what is required for it function properly.   

To understand how AppEngine based Redundancy works within the AVEVA Application Server (System Platform) product, we need to understand a few terms and concepts below.   

Platform - Logical Representation of a Computer (Physical or Virtual) in your Application Server Galaxy.  
Galaxy - The overall Application Server application with the overall plant model, alarm subsystem, Historical Acquisition/Collection, Security, and Visualization. It is a scalable structure that goes from a single node to multiple nodes. 
Automation Object Server (AOS) - The role of a Platform(s) in your Galaxy that is designated to be the Runtime workhorse in charge of collecting data from the Communication Drivers, feeding data to the Historian, and presenting values to the Supervisory Clients for Visualization.  Denoted by the AppEngine object in the IDE.   

Network Interface Card Settings and Binding Order

Before setting up the Redundancy settings in the AppEngine inside of the IDE, you will need to have BOTH Network Interface Cards set up on both your Primary Object Server (AOS) and Backup Object Server (AOS).   In my example, I am referring to them as AOS1 (Primary) and AOS2 (Backup).

1. Find your NICs under the Control Panel/Network and Internet/Network Connections as you will need 2 NICs to set up Redundancy. 
2. Identify which NIC is used for your SCADA Network, and rename it as “Primary-Network”.   
3. You can rename it to whatever you’d like, but a rule of thumb is to give it a name that distinguishes it from the other network cards, and a name that would identify its purpose as the SCADA network or PRIMARY network. 
4. Identify which NIC is used for your Redundant Message Channel, and rename it to be “RMC-Network”. 
5. Much like with the Primary or Scada NIC, you want to give it a name to distinguish it from the other NICs on the machine.   

My Sample Architecture and Network Card Binding Order

1. Go to Control Panel\Network and Internet\Network and Sharing Center
2. Go to Change Adapter Setting

   

IMPORTANT NOTE: 

It is HIGHLY RECOMMENDED that both AOS nodes be of the same Operating System version, down to the build level.   
Setting up the NIC adapter binding order isn’t as intuitive as in earlier versions of Microsoft Windows Server, thus the need for defining the Interface Metric. 
This binding order (interface metric) of the 2 NICs needs to match on BOTH AOS nodes.    
Now, you would need to set up an Interface Metric to determine its order (1 being the highest and 99 being the lowest).   

3. To set up the Interface Metric and the IP Addresses of BOTH NICs, you will need to right click on the NIC, and go to Properties. 

Primary-Network NIC

1. Set the Interface Metric to be the highest in the order by setting it to “1”, by clicking on the Properties of the Internet Protocol Version 4 (TCP/IPv4) setting, select Advanced, 
   1. Uncheck the Automatic Metric, and then set the Interface Metric.   
2. Click OK.
3. You can also set your IP Address to “Obtain an IP Address Automatically” to be assigned via DHCP, unless you use Static IP addresses.   
4. Click OK. 
5. Click OK to exit out of the Primary-Network Properties.

RMC-Network NIC

1. When setting up the IP address for both of the RMC-Networks, you need to set the Interface Metric to a higher number that actually sets the NIC to a lower order in the overall binding order.  I personally set my Interface Metric to “99” so that it is at the absolute bottom of the binding order.   
2. Click OK
3. The RMC can only use a fixed IP Address (Static) with a Subnet that is different than the Primary network.   
   1. We need to plug these into the AppEngine for AOS1 and AOS2, so make sure you keep note of these IP addresses. (See PLATFORM Setup below)
4. For my example, I am setting the following:
   1. AOS 1: RMC-Network IP Address – 10.5.21.1
   2. AOS 2: RMC-Network IP Address – 10.5.21.2
5. Set your Subnet Mask to reflect a difference in Subnet from the Primary Network.   I set my subnet mask to 255.255.0.0 which is different than the Primary-Network for both AOS1 and AO2. 
6. Click OK
7. Click OK to exit out of the RMC-Network Properties.
8. Failure to set this up correctly will result in redundancy being very unstable, and an error that says “Platform x has exceeded maximum heartbeats” in the error logger.  

Integrated Development Environment (IDE)

1. Open up System Platform Integrated Development Environment (IDE), 
2. Double-Click both of your Platforms dedicated to your Primary and Backup network.   
3. In my example, my platforms are named AOS1 and AOS2.

NOTE: When you reference the RMC-Network addresses in each Platform, you are referencing its corresponding IP Address, and NOT the RMC-Network IP Address of its backup partner.     The Local Redundant Message Port “30001” and Local Redundancy Primary Port “30000” also need to be open in your firewall.  We will add the IP Address of the RMC-Network into the Local redundancy message IP Address of both Platforms.

Platform Setup 

Both Platforms must be configured to contain their RMC network's IP address before setting up the Redundancy on the AppEngine level.  

AOS1

1. Add the IP Address of the RMC-Network into the Local redundancy message IP Address.   In my example, 10.5.21.1 is the RMC-Network IP address of AOS1.   
   1. Save to check this object back in.   
2. Do NOT Deploy yet. 

AOS2

1. Add the IP Address of the RMC-Network into the Local redundancy message IP Address.   In my example, 10.5.21.2 is the RMC-Network IP address of AOS2.   
   1. Save to check this object back in.   
   2. Do NOT Deploy yet. 

AppEngine Setup 

Now that we have our Platforms defined with their respective RMC-NETWORK IP Addresses, our AppEngine that we are setting to have a redundant partner will need to have its configuration set as well.  

1. Before you open the AppEngine that is part of the AOS that is deemed to be the Primary AOS, your AppEngine object MUST BE ALREADY UNDEPLOYED.   
   
2. Under the Redundancy tab of the AppEngine object, check “Enable Redundancy”.   The reason to have the Platforms UNDEPLOYED is that if the Platforms haven’t been provided with their RMC-Network IP Address in the Local redundancy message IP Address, you would receive an error message when checking the AppEngine back in that states that the Platforms for the Primary and Backup have not been properly configured. 
3. Save and Check back in. 
    
4. When you check in the AppEngine object, it creates a CLONED object called AppEngine (Backup) that does not expose the contained objects that the primary AppEngine would have.   This is normal.   Do NOT Open the AppEngine (Backup) .  
   
5. Drag and Drop the AppEngine(Backup) directly underneath the Platform that is the Backup Object Server (AOS). 
6. In my Example, AOS2 is the name of my Backup object server.   
   
7. Select BOTH Platforms, and right click to Deploy. 
    
    
8. If you select both Platforms, Cascade Deploy should be greyed out.    If not, make sure that it is NOT selected. 
9. Right click on the AppEngine that is the Primary under AOS1, and right click to deploy.   
10. Choose Cascade Deploy and Include Redundant Partner when you hit deploy.
11. Cascade Deploy will deploy the AppEngine and all of the Objects that it is hosting.   
12. Include Redundant Partner means that you don’t have to go to the AppEngine(Backup) to Deploy as this option will do that for you.   
13. When deployed, the icons should show as such to show which is primary and which is secondary. 
     

Object Viewer

1. Right click on the primary AppEngine now that it IS Deployed, and select “View in Object Viewer”. 
   1. If the Object is not deployed, you will not have the “View in Object Viewer” selection on the right click menu.
2. Choose the following Attributes to drag to the Watch Window:

• Redundancy.PartnerStatus
• Redundancy.Status
• Redundancy.PartnerPlatform

Descriptions for Values for the AppEngine.Redundancy Status and Partner Status

Active: 

Comm via RMC is Good

Standby-Not Ready

Standby-Sync’ing with Active 

Standby-Ready

Active - Standby not Available: 

Comm via RMC is Bad

Determining Failover Status: 

The initial state of a redundancy-enabled AppEngine when it is first started. 

Standby - Missed Heartbeats:

1) the heartbeat pings are not received from its Active partner through the RMC

2) the heartbeats from active engine have been missed through the primary Process LAN

Standby - Not Ready: 

1) its lost communications with its partner object or it maintains communications with its partner but missed checkpoint updates or alarm state changes from the Active AppEngine

2) new objects are deployed and necessary files are not installed on the Standby AppEngine yet

3) the Standby AppEngine lost communications over the RMC before it completed synchronizing data.

Standby - Ready: 

completed synchronizing code modules and checkpoint data with the Active AppEngine. Ideal Partner Status

Standby - Sync'ng with Active:

 The state of an AppEngine when it is synchronizing code modules with the Active object. If code modules exist on the Standby computer that do not exist on the Active node, they are uninstalled, and likewise, any code modules that exist on the Active node but not on the Standby node are installed. After all code modules are synchronized, the AppEngine transitions to Standby-Sync’d Code state.

Standby – Sync’d Code: 

The state of a Standby AppEngine that successfully synchronized all code modules with the Active object.

Standby - Syncing Data: 

The state of a Standby AppEngine when all object-related data, including checkpoint and subscriber information, are synchronized with the Active object. An object in this state typically transitions to Standby-Ready state.

Switching to Active: 

A transitional state when a Standby AppEngine is commanded to become Active.

Switching to Standby: 

A transitional state when an Active AppEngine is commanded to become Standby. When the active engine is switched to standby, the engine will be restarted. This transition state can be switched off by the user changing the attribute of the engine.

Failed: 

The state of a redundant partner when its process crashes or is terminated by the user. The AppEngine process can be restarted using System Management Console/PlatformManager.

Unknown: 

The state of a redundant partner when a communication loss occurs between AppEngines or when the partner AppEngine is stopped, shutdown, or undeployed.

If your AppEngine.Redundancy.PartnerStatus says “Standby - Ready”, then this is a sign that your redundant nodes are working properly due a proper setup!