System Platform and Application Server

Application Server is a core component of System Platform. The Galaxy, stored in the Galaxy Repository (GR), is the top level object in Application Server, and encompasses the whole supervisory control system. A Galaxy is represented by a single logical namespace and a collection of Platforms, AppEngines, and application objects. The Galaxy defines the namespace in which all components and objects reside.

Because of its distributed nature and common services, Application Server does not require expensive server-class or fault-tolerant computers to enable a robust industrial application.

Application Server distributes objects throughout a distributed (networked) System Platform environment, allowing a single application to be split into a number of different component objects, each of which can run on a different computer.

Before exploring the following System Platform topologies, review the main components and how they will be distributed based on requirements and functionality. The main components are:

• IDE: Application Server development node (Engineering workstation). The System Platform IDE runs on this node. If you are using InTouch HMI for System Platform for visualization, WindowMaker can reside on this node, in addition to the IDE.

• GR: Galaxy Repository. This is the configuration database. The GR uses a Microsoft SQL Server database.

• AOS: ApplicationObject Server (run time) nodes. Multiple sets of redundant AOS nodes can be implemented.

• OI: Operations Integration nodes contain the communication drivers that function as the interface to the PLCs in the control network.

• Historian Server. This runs the Historian database and saves historical data. The Historian also uses a Microsoft SQL Server database.

• Visualization nodes running AVEVA OMI ViewApps or InTouch WindowViewer. There are differences in how InTouch HMI and AVEVA OMI handle different types of controls. Consider the following:

  • ActiveX controls: Allowed by InTouch, but cannot be used with OMI.

  • .NET controls: For InTouch, .NET controls can be embedded directly in an Industrial Graphic (the Industrial Graphic functions as a container for the control). For OMI, .NET controls must be placed in panes (one control per pane). If an Industrial Graphic used in OMI contains an embedded .NET control, OMI will strip out the control before it displays the graphic. The only way that Industrial Graphics can interact with .NET controls in OMI is through layout scripting. You must first build a layout that hosts both the Industrial Graphic and the .NET control in separate panes, and embed that layout into a pane. In this case, the layout with the .NET control and Industrial Graphic is the content that is embedded into another layout.

Each System Platform and Application Server component can be installed on its own node, or a single node can contain multiple components. In a small system, all Application Server components can exist on a single node. The same principles and resource requirements apply to both physical environments and virtual environments that leverage Hyper-V or VMware.

The following figure shows a multi-node System Platform topology, running the IDE, GR, Historian, System Management Server, License Server, OI Server, and AOS Servers on separate nodes. The IDE, GR, OI Server, and AOS Servers are components of Application Server.