Please ensure Javascript is enabled for purposes of website accessibility
Powered by Zoomin Software. For more details please contactZoomin

AVEVA™ System Platform

Medium-sized network

  • Last UpdatedAug 12, 2024
  • 2 minute read

This topology is generally applicable to medium-sized systems where the processing requirements of each software component can be easily handled by the nodes providing the projected performance support. If other dimensions of the system, such as I/O, engine loading, and complexity of the galaxy.

The primary characteristic of this topology type is that Visualization and ApplicationObject Server functionalities coexist in the same node, and the IDE and GR coexist on another node within the distributed local network.

AOS/Visualization node

The Visualization and ApplicationObject Server components are combined on the same node. Both components share the Platform, which handles communication with other nodes in the Galaxy. The Platform also allows for deployment/undeployment of ApplicationObjects.

If you plan to combine the Visualization and Application Object Server components on the same node, evaluate the resource requirements for the following:

  • Active tags-per-window if using InTouch HMI

  • Number of I/O

  • Alarm displays

  • Historized tags

These values will impact ApplicationObject service performance. Refer to System sizing guidelines for computer resource recommendations.

Note: For details on Alarm System configuration, see Implement alarms and events.

IDE/GR/SMS node

As in the case of the AOS/Visualization node, the System Platform IDE and Galaxy Repository, along with the System Management Server are combined onto a second node. Additional consolidation is possible, for example, by installing the Communication Drivers on this node as well. All components share the Platform for communication with other nodes and components.

Distributed local network topology

Client operating systems such as Windows 10 can manage up to 10 simultaneous active connections with other nodes. If the system contains more than 10 simultaneously-active nodes, Windows Server must be used for all nodes.

Communication driver nodes

Different I/O data sources have different requirements. Two main groups are identified:

  • Legacy I/O Server applications (SuiteLink, DDE, and OPC Servers) do not require a platform on the node on which they run. They can reside on either a standalone or workstation node.

    However, the DI client objects used to communicate with those data sources such as the DDESuiteLinkClient object, OPCClient object, and InTouchProxy objects must be deployed to an AppEngine on a Platform. Although it is not required that these DI client objects be installed on the same node as the data server(s) they communicate with, it is highly recommended in order to optimize communication throughput.

  • Communication Drivers and their corresponding DIObjects must reside on the same computer hosting an AppEngine.

Best practice

Historian node: The Historian software should run on a designated node. The number of historized tags will determine the sizing of the node. Refer to System sizing guidelines for for computer resource recommendations.

Engineering Station and GR (Configuration Database): The Engineering Station node hosts the System Platform IDE and optionally, InTouch WindowMaker to facilitate Application Server and InTouch Software application development. As the GR node, it hosts the SQL Server database that stores the Galaxy's Configuration Data.

In This Topic
Related Links
TitleResults for “How to create a CRG?”Also Available in