AVEVA SYSTEM PLATFORM

TRANING MANUALAVANCEON DOCUMENT TEMPLATE

FOR ASHGAL DNMC PROJECT

AVEVA SYSTEM PLATFORM TRANING MANUAL

R0 03/24/2020 Issued For Approval

REV DATE DESCRIPTION

For information
PURPOSE

For review/comment

For approval

STATUS NAME DESIGNATION DATE

PREPARED Abid Hussain Tech Lead 08/21/2024

DOCUMENT NUMBER DOCUMENT TITLE REVISION

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

Table of Contents
1 AVEVA™ System Platform Overview ................................................................ 7
1.1 Overview ................................................................................................................ 7
1.2 System Platform Components and Clients ........................................................ 7
1.3 Server Components .............................................................................................. 8
1.4 Client Components ............................................................................................... 8
2 AVEVA Application Server Overview ................................................................ 9
2.1 Overview ................................................................................................................ 9
2.2 Application Server Components ......................................................................... 9
3 Creating a Galaxy ................................................................................................ 9
3.1 Overview ................................................................................................................ 9
4 The Integrated Development Environment (IDE) ......................................... 14
4.1.1 Toolboxes and Application Views ................................................................... 14

5 Automation Objects .......................................................................................... 15

6 Creating Global Derived Templates ................................................................ 17
6.1 In this Demonstration, we will create derived templates from base templates
using the System Platform IDE. .................................................................................17
7 Application Planning ........................................................................................ 18
7.1 Introduction.........................................................................................................18
7.2 Factory Layout .....................................................................................................18
7.3 The Plant Model ..................................................................................................19
7.3.2 The Area Object ................................................................................................. 20
7.3.3 Deployment of Automation Objects ............................................................... 20
7.3.4 The Deployment Model .................................................................................... 21
7.3.5 Creating the Plant and Deployment Models .................................................. 23
7.3.6 System Management Console .......................................................................... 23
7.3.7 The Runtime Environment................................................................................ 24
7.3.8 Object Viewer..................................................................................................... 25

8 Application Objects ........................................................................................... 27

8.1 Introduction to Application Objects .................................................................27
8.2 Object Attributes ................................................................................................27
8.3 Locking and Unlocking Template Attributes...................................................27

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 2 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

8.4 Containment ........................................................................................................28

9 Device Integration Servers ............................................................................... 30
9.1 Communication to Field Devices ......................................................................30
9.2 OI Servers .............................................................................................................30
9.2.2 Navigating the OI Server Manager.................................................................. 30
9.2.3 Configuring the OI Server ................................................................................ 31
9.2.4 Device Integration Objects ............................................................................... 31
9.2.5 The DDESuiteLinkClient Object ........................................................................ 31
9.2.6 Configuring the Device Integration Object .................................................... 32

10 Historizing Data for AVEVA Application Server ............................................ 33

10.1 Application Server History Components .......................................................33
10.2 Historian Installation and Deployment .........................................................34
10.2.2 Store and Forward ........................................................................................... 34
10.2.3 Saving Object Attribute Data to the Historian............................................. 34
10.3 Configure the Galaxy for Historization .........................................................35
11 Alarms and Events Overview ........................................................................... 36
11.1 What is an Alarm/Event ..................................................................................36
11.1.2 How Does ArchestrA Handle Alarms............................................................. 36
11.1.3 Types of Alarms ............................................................................................... 37

12 Object Management ......................................................................................... 38

12.1 Exporting Automation Objects.......................................................................38
12.1.2 Importing Automation Objects ..................................................................... 39
12.1.3 Exporting and Importing Objects Demonstration ....................................... 40
12.2 Galaxy Dump and Galaxy Load ......................................................................41
12.2.1 Galaxy Dump ................................................................................................... 41
12.2.2 Galaxy Dump File (.csv) Structure ................................................................. 42
12.2.3 Galaxy Load...................................................................................................... 42
12.3 Galaxy Backup and Restore ............................................................................43
12.3.1 System Management Console........................................................................ 43
12.3.2 Galaxy Database Manager.............................................................................. 43
12.3.3 Create a new Galaxy with a Galaxy backup (.cab) file ................................. 45
12.3.4 Restore ............................................................................................................. 45

13 Security ............................................................................................................... 46

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 3 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

13.1 Security Overview ............................................................................................46

13.1.2 The ArchestrA Security Model ....................................................................... 46
13.2 Authentication Mode ......................................................................................47
13.2.1 Configure Security Groups ............................................................................. 47
13.2.2 Configure Security Roles ................................................................................ 48
13.3 Set Object Security...........................................................................................49
14 Introduction to QuickScript.NET ..................................................................... 51
14.1 Script Editing Styles and Syntax.....................................................................51
14.1.2 IDE Scripts Tab ................................................................................................. 51
14.1.3 Script Execution Types.................................................................................... 52
14.1.4 Language Definition ....................................................................................... 52
14.1.5 Attribute References ....................................................................................... 53
14.2 Demonstration different script examples .....................................................53
15 Introduction to Industrial Graphics ................................................................ 54
15.1 Introduction ......................................................................................................54
15.1.2 Graphics Tab .................................................................................................... 54
15.1.3 Graphic Toolsets .............................................................................................. 54
15.1.4 Import and Export Symbols ........................................................................... 55
15.1.5 Symbol Libraries .............................................................................................. 55

16 Graphic Editor .................................................................................................... 56

16.1 Introduction ......................................................................................................56
17 Graphic Tools and Animations ........................................................................ 57
17.1 Introduction ......................................................................................................57
17.1.2 Tools Pane ........................................................................................................ 57
17.1.3 Elements List .................................................................................................... 57
17.1.4 Demonstration................................................................................................. 57

18 Industrial Graphics with Objects ..................................................................... 58

18.1 Introduction ......................................................................................................58
18.1.2 Linked Symbols vs. Added Symbols .............................................................. 58
18.1.3 Manage Symbols from the Object Editor ..................................................... 58
18.1.4 Relative References ......................................................................................... 58
18.1.5 Creating Symbols for Automation Objects................................................... 59

19 AVEVA Operations Management Interface (OMI) ........................................ 60

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 4 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

19.1 Introduction ......................................................................................................60

19.1.2 Operations Management Interface Applications ......................................... 60
19.1.3 Features and Capabilities................................................................................ 60
19.1.4 Visualization Components.............................................................................. 61
19.1.5 Screen Profiles, Layouts, and Panes .............................................................. 61
19.1.6 OMI Apps ......................................................................................................... 62
19.1.7 Screen Profiles vs. Physical Monitors ............................................................ 62
19.1.8 Create a Screen Profile.................................................................................... 62
19.1.9 Layouts and Panes ........................................................................................... 63
19.1.10 Creating a Screen Profile and Layout Demonstration. .............................. 64
19.1.11 ViewApps ....................................................................................................... 64
19.1.12 ViewApp Editor.............................................................................................. 64

20 Built-In Navigation ........................................................................................... 65

20.1.2 Auto-Fill............................................................................................................ 65
20.1.3 Preview Mode .................................................................................................. 67
20.1.4 Deploy a ViewApp ........................................................................................... 67
20.1.5 Creating and Running a ViewApp Demonstration ...................................... 67

21 Custom Navigation ........................................................................................... 68

21.1 Introduction ......................................................................................................68
21.1.2 Custom Navigation Commands ..................................................................... 68
21.1.3 Navigation Item References ........................................................................... 68

22 ViewApp namespaces ....................................................................................... 69

22.1 Overview ...........................................................................................................69
22.1.2 Predefined Namespaces and Attributes ....................................................... 69
22.1.3 Reference ViewApp Namespace Attributes.................................................. 69
22.1.4 Demonstrations ............................................................................................... 69

23 OMI ViewAPP Security...................................................................................... 70

23.1 Introduction ......................................................................................................70
23.1.2 Security Namespace and Security-Related System Attributes ................... 71
23.1.3 Implementing Security in a ViewApp Demonstration................................. 71

24 OMI Alarms and Events App ............................................................................ 72

24.1.2 The Platform as an Alarm Provider ............................................................... 72
24.1.3 Alarm Queries .................................................................................................. 72

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 5 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

24.1.4 Alarm Border Animation ................................................................................ 72

24.1.5 Changing the Alarm Border Indicator Icon.................................................. 73
24.1.6 Using AlarmAPP .............................................................................................. 73
24.1.7 Alarm Queries .................................................................................................. 73
24.1.8 Demonstration................................................................................................. 73

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 6 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

1 AVEVA™ System Platform Overview

1.1 Overview
AVEVA System Platform, formerly Wonderware System Platform, is an industrial software
platform built on ArchestrA technology. It contains an integrated set of services and an
extensible data model to manage plant control and information management systems.
System Platform supports both the supervisory control layer and the manufacturing
execution system layer, presenting them as a single information source..
System Platform and its clients provide the framework and tools for developing, executing,
monitoring, and visualizing your applications. Services such as data acquisition, historization,
and alarming are provided by System Platform components. Services such as visualization
and trending are provided by System Platform clients.
The System Platform software is based on industry standards and Microsoft technologies,
such as Windows, .NET, SQL Server, IIS, and others. ArchestrA provides the fundamental
technology and services for the multi-user, object-oriented platform.

1.2 System Platform Components and Clients

System Platform components access and process external data from controllers, software
applications, and other data sources. System Platform clients access information from System
Platform.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 7 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

1.3 Server Components

AVEVA™ Application Server is the heart of System Platform. It provides an object oriented
framework with tools for developing and deploying applications.
AVEVA™ Historian provides process data historization and alarm and event logging for
Application Server. Data is exposed through SQL Server and/or an Open Data Protocol
(oData) interface
AVEVA™ Communication Drivers provide the platform for communication with controllers
and other data sources. Besides controller-specific protocols, they support open
communication connectivity protocols such as MQTT, OPC DA, and OPC UA. Formerly called
OI Servers, they also include legacy DA Servers and IO Servers. System Platform also
communicates directly with third-party drivers, such as third-party OPC Server

1.4 Client Components

Supervisory clients run the operator interface and provide real-time access to Application
Server data, alarms, and events. There are two supervisory client products, based on different
technologies. Both can coexist in the same System Platform solution.
AVEVA™ Operations Management Interface has a rapid-design visualization framework
with tools, and provides out-of-the-box navigation to display content based on the
application’s data model.
AVEVA™ InTouch for System Platform is based on traditional development tools to create
displays and the corresponding navigation framework from scratch.
AVEVA™ Historian Client is a collection of tools for accessing and reporting on data
historized with Historian. This client includes a Trend application for plotting data on a
graphical display, a Query application for constructing SQL queries through a point-and click
interface, and add-ins to Microsoft Excel and Word for generating reports
AVEVA™ Historian Client Web is a browser-based tool for quick data query, trending, and
analysis of data historized with Historian. It provides an intuitive interface for easy access and
use.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 8 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

2 AVEVA Application Server Overview

2.1 Overview
The Application Server is the heart of the System Platform; it provides the services and tools
to create, manage, and deploy your application. An application created with Application
Server is called a Galaxy; both terms are interchangeable.
Some of the main characteristics and benefits of Application Server are:
• Object-oriented framework that provides a modeling approach to creating and
managing applications
• Native support for DDE, SuiteLink, and OPC to access Wonderware and third-party
drivers, such as OI Servers and legacy IO Servers
• Multi-user development environment
• Self-documenting objects and versioning
• Security features to prevent users from performing unauthorized activities within the
development and runtime environments
• Redundancy capabilities for the application and for I/O communications
• Diagnostics tools for troubleshooting the application
• Extensibility through a scripting engine with .NET capabilities
• Out of the box graphic libraries; one of them designed to create Situational Awareness
HMI
2.2 Application Server Components
AVEVA Application Server is not a single piece of software but a set of software components,
tools, and services that work together for the development and deployment of industrial
automations systems. It is comprised of three software components:
• The Bootstrap is a Windows Service that provides the required software for a
computer to be able to receive a platform (a component from your application that
makes the computer part of your application)
• The IDE (Integrated Development Environment) is the Application Server
development tool for creating, configuring, and deploying your application
• The Galaxy Repository is a Windows Service that manages the development and
deployment of the application; the computer running the Galaxy Repository software
hosts the configuration project database

3 Creating a Galaxy
3.1 Overview
The IDE is used to create, configure, and manage a Galaxy. The IDE cannot be started in a
Galaxy-neutral state, so when starting the IDE, the Connect to Galaxy dialog box is first
displayed

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 9 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

This dialog box is used to:

• Connect to the selected Galaxy in the specified Galaxy Repository node and open
the IDE. If the selected Galaxy has security enabled, it will prompt you for login
credentials.
• Create a new Galaxy in the specified Galaxy Repository node.
• Delete the selected Galaxy from the specified Galaxy Repository node. As a safety
measure, Galaxies with objects deployed cannot be deleted.
When creating a new Galaxy, you use the Galaxy type to indicate what will be the default
content of the new Galaxy.

The following Galaxy types are available out-of-the-box:

• Default_EMPTY.cab – Creates a baseline Galaxy that contains only base template
objects.
• Default.cab – The recommended starting point for creating a new Galaxy; contains
default screen profiles, templates, a basic equipment mode, and an InTouch OMI View
App example that provides an introduction to key features.
• Base_InTouch.cab – Creates a Galaxy that includes only the objects and graphics
needed for tag-based Managed InTouch applications.
• Reactor_Demo_InTouch.cab – Creates a Galaxy with a version of the Reactor Demo,
based on a tag-based Managed InTouch application.
Other Galaxy types can be made available using backups of other Galaxies; this allows the

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 10 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

distribution of standards, such as preconfigured objects, graphics, and system-level

settings.

Create the Galaxy (Steps)

First, you will create a Galaxy and connect to it.
1. Open the System Platform IDE.
The Connect To Galaxy dialog box appears with the local node name displayed in the
GR node name drop-down list. Once a Galaxy has been created and accessed, the last GR
node name to which it was connected will be shown by default.
2. Click New Galaxy to create a new Galaxy.

The New Galaxy dialog box appears.

3. In the Galaxy name field, enter TrainingGalaxy.
4. In the Galaxy type drop-down list, select Default_EMPTY.cab.

5. Click create Galaxy.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 11 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

The Create Galaxy dialog box appears and shows the Galaxy creation progress. This will take
a few moments.

When complete, the Create Galaxy progress displays 100% completed.

6. Verify there are no error messages.

7. Click Close.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 12 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

The TrainingGalaxy you entered in Step 3 has been created and now appears in the Galaxy
name drop-down list.

8. Click Connect
The Connect to Galaxy dialog will close and IDE will open.

You will use the IDE to develop the Galaxy throughout the remainder of this course.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 13 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

4 The Integrated Development Environment (IDE)

The Integrated Development Environment (IDE) is the configuration and development tool for the
Galaxy. It accesses the Galaxy Repository, local or remote, and connects to the Galaxy. Once
connected to the Galaxy, the IDE allows the configuration of Galaxy-wide settings (such as
Security), as well as the creation and configuration of automation objects (such as a valve) and
graphics.

Some of the Galaxy-wide settings that can be configured with the IDE include:
• Security configuration and permissions
• Language definition for multi-language applications
• I/O communication management
• Global graphic styles
• Alarms and events logging parameters
• User preferences
• Multi-Galaxy communications

When working with objects, the IDE allows:

• Creation of new objects
• Configuration of existing objects, such as I/O points, alarm definitions, and process data to
historize
• Check-out/Check-in functionality for versioning control
• Deployment and undeployment of objects
• View object properties, such as error and warning messages, as well as cross-reference
information
• Upload changes to the runtime version of the object to the configuration database

The IDE also includes import and export capabilities, including:

• Objects
• Global graphic styles
• Script function libraries, such as .NET assemblies to use within a script

4.1.1 Toolboxes and Application Views

The toolboxes included with the IDE hold libraries of reusable objects and graphics:
• Template Toolbox – Contains all automation object templates in your Galaxy organized
by folders called Template Toolsets
• Graphic Toolbox – Contains all symbols and Client Controls organized by folders called
Graphic Toolsets. Graphics created within an automation object are not displayed in this
toolbox.

The application views included with the IDE are used to display and configure relationships
between objects:

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 14 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

• Model – Relationship between automation object instances as it pertains to the

automation scheme of the application, usually the physical layout of the plant.
• Deployment – Relationship between automation object instances as it pertains to the
computers where the objects will be deployed (where the objects will run)
• Derivation – Parent-child relationship between all automation objects in the Galaxy, from
base templates to each individual instance
• IO Devices – Relationship between automation object instances and the Device
Integration objects; it allows automatic assignment of I/O references.

5 Automation Objects
Automation objects, along with the relationship between each other, are the centerpiece of
the object-oriented framework of Application Server. Through automation objects, you can
model virtually anything related to the Galaxy, from an area or section of the plant, to every
equipment in the field, to the actual computers running your application.

For this, Application Server provides objects in three different categories:

• System Objects
• Device Integration Objects
• Application Objects

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 15 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

The main benefit of an object-oriented approach to configuring the Galaxy is that it allows
for the encapsulation of all configuration elements of each element of your system in an
automation object. This self-contained approach reduces the engineering time associated
with the development and maintenance of the application.

All automation objects include the following features and configuration options:
• Inputs and Outputs
• Scripting
• Historical Configuration
• Security Requirements
• Alarms and Events Configuration
• Graphic Symbols
Automation objects are provided in the form of templates and instances. Templates allow the
configuration of reusable standards while instances implement the standards for each
individual equipment. For example, all common configuration for the valves in the application
can be modeled in a $Valve template and then instances for the actual CV101, CV102, and
CV103 valves can be created out of the $Valve template

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 16 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

6 Creating Global Derived Templates

6.1 In this Demonstration, we will create derived templates from base templates
using the System Platform IDE.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 17 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

7 Application Planning
7.1 Introduction
The object-oriented framework of Application Server makes it easy to develop and maintain
a Galaxy by encapsulating all-related functionality in individual objects and combining all
common configuration in templates that can be easily spawned into multiple instances. A
Galaxy can be made out of hundreds and even thousands of objects, so careful planning is
recommended before creating these objects to avoid backtracking and redesigning objects
down the road.
The following is a suggested project development workflow to get you started on creating
your first Galaxy.

The first three steps are the most important, since the objects derivation hierarchy will rely
on this (and cannot be fixed later on without recreating it); the other three items (plant model,
security model, and deployment model) can be updated later if needed.

7.2 Factory Layout

The factory example for this training course is divided in four main sections or areas:
Receiving, Production, Packaging, and Shipping; with the Production area including two
production lines: Line 1 and Line 2.
All these areas will be modeled in the Galaxy using the $Area object and will be the basis for
the plant model.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 18 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

7.3 The Plant Model

The plant model, or area model, as sometimes referred to, is a hierarchical representation of
the automation scheme of the application. It basically servers two functions: logical
organization of all the objects in the Galaxy; and the distribution of alarms within the system.
The automation scheme is usually based on the physical layout of the plant, where each
section and sub-section is represented by an object in the Galaxy. While every plant and
factory has its own particular layout, in general terms you could classify the structure as
follows:

The plant model is also how alarms are distributed in the system; for example, if the
production area has two production lines, the operator for Line 1 will only want to see alarms
for that area, while the Production Supervisor might want to see alarms for both lines. This
functionality is inherent in the plant model.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 19 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

7.3.2 The Area Object

The Area object is one of the simplest objects to configure, but its functionality is key to the
implementation of the Galaxy, as it is the basis for the plant model.
• Represents an area of the plant or an automation process
• Can only be nested up to 10 levels
• Provides grouping and distribution of alarms
• Used as filters by alarm clients
• On the plant model, the rest of the objects are assigned to it
• On the deployment model, it hosts all application objects
7.3.3 Deployment of Automation Objects
To run your application, the automation object instances in your Galaxy must be deployed to
the runtime environment. When an object is deployed, the underlined software that makes
the object (from the base template) and the object's configuration (I/O references, alarms,
history, scripts, and so on) are copied to the target computer; the software also gets installed
or registered in that computer and the object is run, or both.
In contrast, undeploying objects will stop them, uninstall them, and finally remove them
(software and configuration) form the computer they were deployed to.
• Changes made to the configuration of an object are not automatically deployed.
• To deploy changes to an deployed object, usually referred to as redeploy, you just
need to deploy the object again.
• Deployment occurs from the Galaxy Repository computer to the target runtime
computers.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 20 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

• To be able to deploy automation objects, you must define the Deployment Model for
the Galaxy.
7.3.4 The Deployment Model
The Deployment Model is a hierarchical representation of where your objects are going to
run (or are running); in other words, the distribution of all your objects across all the
computers that are part of your Galaxy.
The computers themselves are represented by the WinPlatform object. This is the first (and
maybe only) object that is deployed on computers that are part of the Galaxy. One, and only
one WinPlatform object, can be deployed to a computer; in other words, a computer can
belong to one and only one Galaxy at a given time.

• The WinPlatform object is at the top of the hierarchy and the first to be deployed; it
sets the infrastructure for the Galaxy and manages all the off-node communications.
• WinPlatform objects host AppEngine objects, which are the primary runtime engines
in charge of running the rest of the objects in the Galaxy, as well as handling the
communication between objects hosted in the same engine.
• AppEngine objects host Area objects for alarm grouping and filtering.
• Area objects host Application objects, which primarily represent the equipment in the
plant (valves, motors, tanks, conveyors, and so on).
• AppEngine objects also host Device Integration objects, which allow communication
to the field through drivers such as OI Servers, OPC Servers, and legacy IO Servers.
• AppEngine objects can host several areas and device integration objects.
• WinPlatform objects can host more than one AppEngine object; this allows for
running different objects at different speeds (scan rates).
For visualization purposes, WinPlatform objects also host ViewEngine objects and
ViewEngine objects host InTouchViewApp objects. An instance of the InTouchViewApp object
represents a visualization application or HMI; the ViewEngine object allows the deployment
of the visualization application to remote computers.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 21 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

The deployment model hierarchy indicates the deployment dependencies between the
objects; hosted objects cannot be deployed, if the hosting object is not deployed first. For
example, an Area object cannot be deployed, if the hosting AppEngine object is not deployed
first; in turn, the AppEngine object cannot be deployed, if the hosting WinPlatform object is
not deployed first.
To rearrange the deployment model, the objects need to be undeployed first. For example,
to move an Area from one AppEngine to another, the Area and its hosted application objects
must be undeployed first; the AppEngine objects can remain deployed, as well as any other
objects deployed to those AppEngine objects.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 22 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

7.3.5 Creating the Plant and Deployment Models

7.3.6 System Management Console

The System Management Console (SMC) provides Application Server diagnostics by allowing
you to view the runtime status of some system objects and to perform actions upon those
objects. The SMC is a Microsoft Management Console (MMC) container snap-in for all the
diagnostic and management utilities for your Galaxy application. Actions include setting
platforms and engines in an executable or idle mode and starting and stopping platforms
and engines.
The System Management Console is used to assist system integrators and system
administrators in performing administrative tasks and diagnostics on the IDE. It provides
application infrastructure diagnostics by allowing the viewing of runtime status of some
system objects and the ability to perform actions upon those objects.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 23 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

The console tree shows the items that are available in the console. The snap-ins that appear
below the SMC node will depend upon the software installed:
• Galaxy Database Manager (GR Node only)
• Operations Integration Server Manager (OI Server or WinPlatform deployed)
• Log Viewer (all Wonderware nodes)
• Platform Manager (all Application Server nodes)
• Other snap-ins (for example, Historian Server) will be available when other
Wonderware software is installed

7.3.7 The Runtime Environment

All deployed objects, as per the defined deployment model, constitute the runtime
environment of the Galaxy. This runtime environment is governed by the AppEngine objects
running the application objects, device integration objects, and areas from the Galaxy.
At any given scan, the objects are executed in the following order:

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 24 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

7.3.8 Object Viewer

Object Viewer is a runtime tool that allows you to test, diagnose, and troubleshoot the Galaxy
by providing read and write access to all deployed automation objects across all computers
in the Galaxy. The tool is targeted to application developers and maintenance personal;
operators or other users of the Galaxy should use a graphical interface such as an InTouch
application

You can open the Object Viewer tool from two places:
• The IDE, as long as there is a local platform deployed
• The Platform Manager, from any computer with a platform deployed
Open and Add Items to Object Viewer

Use the SMC Platform Manager to Open Object Viewer

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 25 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 26 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

8 Application Objects
8.1 Introduction to Application Objects
Application Server is designed as an Object-Oriented Application. The objects are
fundamental to Application Server. Application Objects can be configured to do a number of
things in Application Server.
8.2 Object Attributes
When you add an attribute to a template, the attribute, its data type, and writeability are
automatically locked in the child instances.
If attribute parameters such as initial values and security classifications are locked in the
template, they cannot be changed in child instances. If these parameters are unlocked in the
template, the initial value and security are editable and lockable in derived templates. When
unlocked in either the base or derived template, the value is editable in instances
After you add an attribute to an instance, it appears in the Attribute Browser list for use with
the scripting and attribute configuration functions.
Attribute names can have up to 32 alphanumeric characters, including periods. Attribute
names must include at least one letter.

The Attributes tab allows you to configure an existing attribute for I/O, alarms, and history
functionality not embedded in the original object.
8.3 Locking and Unlocking Template Attributes
When you create derived templates, you can lock or unlock some or all of the attributes.
Locking an attribute prevents the attribute from being changed in derived templates or
instances. You can only lock attributes in templates.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 27 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

Locking an attribute in a template specifies that its value or setting is inherited by all derived
objects, both templates and instances. Locking an attribute also makes the attribute act as a
constant during run time.

Based on this concept, an attribute can have one of three logical lock types:
• Unlocked: Both Templates and instances can have these. Attribute is read-write. The
object has its own copy of the attribute value and is not shared by derived objects.
• Locked: Only Templates can have these. Attribute value is read-write. Derived objects
don't have a unique copy of the attribute value, but instead share the locked one (it
is Locked In Parent - see next item). By changing the value of a locked attribute, the
logical value of that attribute is updated in all derived objects.
• Locked In Parent: Both Templates and instances can have these. Attribute is read-
only. The object does not have a unique copy of the attribute value, but references
the one in the ancestor in which the attribute is Locked
8.4 Containment
Containment is the relationship in which one object includes another. Containment
relationships organize objects in a hierarchy. You can build objects that represent complex
devices consisting of smaller, simpler devices.
In scripts, these objects can be referred to by the name that derives from the containment
relationship. This name is called a hierarchical name.
ApplicationObjects can be contained by other ApplicationObjects. This provides context for
the contained object and a naming hierarchy that provides a powerful tool for referencing
objects.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 28 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 29 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

9 Device Integration Servers

9.1 Communication to Field Devices
Connectivity from the Galaxy to field devices is needed to supervise and control processes
and equipment; for this, application objects representing equipment in the field need to
communicate with controllers, such as PLCs and RTUs. These concepts extend to any
automation object in the Galaxy.
The communication between automation objects in the Galaxy and the controllers is done
through device integration objects that reside in the Galaxy and field protocol-specific drivers
external to the Galaxy, such as OI, legacy IO, and OPC servers.

9.2 OI Servers
The OI Server Manager is a part of the SMC suite of utilities. It enables the configuration,
diagnosis, activation, or deactivation of a local OI Server or a remote OI Server located on a
different node from the OI Server Manager.
You can open multiple instances of the OI Server Manager at the same time; however, you
can only use the first instance to create device hierarchies and configure an OI Server. In all
other instances of the OI Server Manager hierarchy and configuration settings are set to read-
only.
9.2.2 Navigating the OI Server Manager
Within the SMC the OI Server Manager has a hierarchical tree of items named the Console
Tree, and a configuration pane named the Details pane. The configuration pane on the right,
also named a faceplate, will vary depending on the type of OI Server being configured. The
OI Server Manager has one or more node groups in its hierarchy and each node group
comprises one or more nodes. A node represents a computer that hosts at least one OI
Server.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 30 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

9.2.3 Configuring the OI Server

The Configuration node is used to configure an OI Server for runtime. The Configuration node
has two functions. First, it has several global parameters that can be configured to adjust the
OI Server runtime performance. These parameters apply to all server instances in the server
group.
Second, the Configuration node has its own hierarchy of configurable objects. Each object
represents a physical device, such as a channel, port, bridge, or PLC. Some OI Servers have
two levels of objects in the hierarchy. For example, a parent object may represent a network
channel, port, or bridge, while a child object may represent an individual device on that
network

9.2.4 Device Integration Objects

Application Server includes the following device integration objects for communication with
the drivers:
• $DDESuiteLinkClient
• $OPCClient
These device integration objects can be deployed to any platform in the Galaxy as long as
they have network access to the drivers. They support the following client protocols:
9.2.5 The DDESuiteLinkClient Object
The DDESuiteLinkClient object allows real-time access to any DDE or SuiteLink server
application, including OI Servers and legacy IO Servers. There is a one-to-one relationship
between an instance of the $DDESuiteLinkClient object and a running server application; to
reference data points in more than one server application, you must configure and deploy
more than one instance of the $DDESuiteLinkClient object

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 31 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

9.2.6 Configuring the Device Integration Object

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 32 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

10 Historizing Data for AVEVA Application Server

10.1 Application Server History Components
To save your process data to a historical database, you must install the Historian. A Historian
can be installed on any computer outside the Galaxy, but on the same network. In a
production environment, the Historian should be installed on a dedicated computer.
Each Engine in the Galaxy is configured with the location of the Historian storage node to
which its history data is to be sent. This configuration is stored in an attribute within the
Engine.

The following figure shows the major ArchestrA components to save process data from a
production device to the Historian.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 33 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

10.2 Historian Installation and Deployment

Historian is installed and deployed using its standard mechanism. Historian can be deployed
on any PC in the Galaxy, or on a PC outside the Galaxy but on the local network. Historian
requires a SQL Server Database for its configuration data. This SQL Server Database can be
the same or different one used by the Galaxy Repository. More than one Historian can be
utilized by a single
Galaxy. However, a single engine sends its history to only one Historian.A single Historian can
receive historical data from a single Galaxy only.
10.2.2 Store and Forward
If the Historian shuts down or the network connection to it is lost while an application is
running, historical data continues to be stored locally on the computer hosting the
WinPlatform Object.
When the Historian node recovers, data is forwarded from the local node to the Historian
node at a low priority.
10.2.3 Saving Object Attribute Data to the Historian
Attribute values can be saved as historical data when values change. Data quality and time
are also associated with attribute values. When available, Application Server uses the
extended attribute’s value, the timestamp when the value changed, and the calculated quality
of the data to create a Value, Time, Quality (VTQ) packet sent to the Historian. If there is no
timestamp associated with the attribute value, the current scan time from the AppEngine
hosting the Object is used instead.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 34 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

10.3 Configure the Galaxy for Historization

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 35 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

11 Alarms and Events Overview

11.1 What is an Alarm/Event
The alarm and event capabilities in the system provide for users to automate the detection,
notification, historization, and viewing of either application (process) alarms and events or
system/software alarms and events.
Examples of alarms include:
• A process measurement has exceeded a predefined limit, such as a high temperature
alarm.
• A process device is not in the desired state, such as a pump that should be running
has stopped.
• The system hardware is not operating within desired limits, for example the CPU
utilization on a Platform exceeds a certain percentage for an extended time.
Examples of events include:
• A plant process has started; for example, a new batch or campaign starts.
• The operator has changed a plant operator parameter; for example, a setpoint on a
temperature controller.
• The system engineer has changed the runtime system configuration; for example,
deployment of a new AutomationObject.
• The system engineer has started or stopped a system component; for example,
stopping an engine.
11.1.2 How Does ArchestrA Handle Alarms
A Platform can act as a single Alarm Provider that provides alarms to the Distributed Alarm
subsystem. A Boolean check box is provided in the Platform AutomationObject indicating
whether it subscribed to Areas or not for alarm and event reporting.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 36 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

11.1.3 Types of Alarms

Application Server supports the following types of alarms
• Limit alarms
• Deviation alarms
• Diagnostic alarms
• Rate of change alarms
• Bad value alarms
A limit alarm compares the current value to one or more predetermined alarm limits within
the attribute’s full range of values. If the value exceeds a limit, an alarm occurs.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 37 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

12 Object Management
12.1 Exporting Automation Objects
Use the IDE's export function to share objects with other users or to recreate them in other
Galaxies. The resulting file (.aaPKG extension) contains the selected objects, their associated
templates and the configuration state of those objects. The export file can later be imported
into the same or another Galaxy.
If any of the selected objects are currently checked out, only the checked in versions are
exported. Exporting an entire Galaxy is similar to using the Galaxy Database Manager utility
to back up the database. However, the change logs for the objects are not exported while
they are saved during backup. Also, the backup process retains security model settings for
objects while exporting them does not.
To export an object, select an object in the Template Toolbox or Application Views pane, and
then on the Galaxy menu, select Export | Object(s).

The Export Automation Object(s) dialog box appears. In the dialog box, browse to the path
and add a file name (.aaPKG extension) for the export file.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 38 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

Click Save. Click Cancel to terminate the export function. If you click Save, a progress box is
displayed.

When the export process is finished, click Close. The resulting .aaPKG file can be used to
import the chosen objects into another existing Galaxy.

12.1.2 Importing Automation Objects

Objects can be reused from another Galaxy in your Galaxy. This saves time if the objects are
already set up in another Galaxy.
Importing instances previously exported from a Galaxy retains previous associations, when
possible, such as assignment, containment, derivation, and area.
Objects can be imported from exported .aaPKG files or from an .aaPDF file. An .aaPDF file
contains the configuration data and implementation code for one or more base templates. It
is created by a developer using the ArchestrA Object Toolkit.
Before starting, you cannot have two objects with the same name or more than one copy of
the same version of an object in the same Galaxy. When you import an object, these conflicts
are identified and you can manage them.
To import Automation objects, on the Galaxy menu, select lmport | Object(s).

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 39 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

The Import AutomationObject(s) dialog box appears

Browse for the file with either a .aaPKG or a .aaPDF extension. You can select more than one
file. Click Open.
The Import Preferences dialog box appears

12.1.3 Exporting and Importing Objects Demonstration

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 40 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

12.2 Galaxy Dump and Galaxy Load

12.2.1 Galaxy Dump
Object instances and their configuration data can be exported to a comma-delimited format
Galaxy dump file (.csv extension).
The Galaxy Dump function only dumps instances. Templates cannot be dumped. The .csv file
contains the configuration for the checked in versions of the selected objects as well as the
checked out objects of the user who initiates the Galaxy dump. The file contains only those
attributes that are unlocked and configuration time-writable, one column per attribute.
Attributes that are locked or runtime writable only are not saved to the file. The following are
not exported:
• Scripts libraries are not exported. Scripts within an object are exported.
• Attributes that are not text based are not exported
• Custom object online help files are not exported.
On the Galaxy menu, select Export, and then click Galaxy Dump

The Galaxy Dump dialog box appears. Browse to the location to which you want to dump the
selected instances and enter the name of the .csv file.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 41 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

Click Save to continue or Cancel to end the export function.

If Save is chosen, the Galaxy Dump progress box is displayed.

After the Galaxy dump process is finished, click Close. A .csv file has been created containing
the selected objects and configuration data. Note that attribute properties that have been
locked will not be part of the Galaxy dump CSV file.
12.2.2 Galaxy Dump File (.csv) Structure
Dumped objects are organized in the resulting .csv file based on the template from which
each is derived. A header row per template indicates the instance's columns' reference.
Comments can be added in the resulting .csv file by adding a line preceded by a semi-colon.
12.2.3 Galaxy Load
Object instances and their configuration data in an existing Galaxy can be exported to a
commadelimited format Galaxy dump file (.csv extension). A .csv file can be edited in most
text editors and spreadsheet programs.
Using editing functions like copy and paste, you can create quantities of already configured
objects ready to be imported into your Galaxy.
To import a .csv file, on the Galaxy menu, select Import, and then click Galaxy Load

The Galaxy Load dialog box appears.

In the Galaxy Load dialog box, browse to locate the .csv file that contains the objects and
configuration data you want to import.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 42 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

Select the file and click Open to continue or Cancel to end the import function.
If Open is chosen, the Galaxy Load Conflict Resolution dialog box is displayed.

12.3 Galaxy Backup and Restore

12.3.1 System Management Console
The System Management Console is used to help system integrators and system
administrators perform administrative tasks and diagnostics on an ArchestrA application. Its
console tree lists the items available for these tasks. One of these items is the Galaxy Database
Manager used to back up and restore a Galaxy.

12.3.2 Galaxy Database Manager

You use the Galaxy Database Manager to back up and restore a Galaxy. Backing up a Galaxy
creates a single backup file (.cab extension) containing all the files, configuration data, and
object deployment states required to recreate the Galaxy in an empty Galaxy Repository.
During the backup, no write operations are allowed to the Galaxy Repository. If write activity
is occurring, you should back up at a later time.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 43 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

Restoring a Galaxy uses the backup file to overwrite an existing Galaxy or to create the backed
up Galaxy in a different Galaxy Repository. The restore process prompts you for confirmation
before a Galaxy is overwritten.
All objects should be undeployed before beginning to restore a Galaxy. During the restore,
no clients can use the Galaxy Repository. If these conditions are not acceptable, you should
restore at a later time.
To back up a Galaxy, expand Galaxy Database Manager. Select the Galaxy to backup, and
then on the Action menu, select Backup.

A warning appears.

Acknowledge the warning and name the .cab file to be created

Click Save. The Galaxy Database Manager progress appears

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 44 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

12.3.3 Create a new Galaxy with a Galaxy backup (.cab) file

You may also create a new Galaxy using the cab file created when a Galaxy backup is
performed. You must first copy the backup cab file to:
C:\Program Files (x86)\ArchestrA\Framework\Bin\BackupGalaxies
In the New Galaxy window, create a new Galaxy and select your backup Galaxy in the Galaxy
type field.
12.3.4 Restore
When you restore a database from backup, any information saved to the database since the
backup was performed is overwritten with the restored information. All changes to the
database since the backup are lost. Also, any transactions in progress when the backup was
performed are rolled back.
Select the existing Galaxy, and then on the Action menu, click Restore

The Galaxy Database Manager dialog box appears.

Click Yes to continue restoring and No to terminate the restore function. If you choose Yes,
select the name (.cab extension) of the backup file you want to use and click Restore.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 45 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

13 Security
13.1 Security Overview
ArchestrA security is designed to prevent users from performing unauthorized activities. This
includes users of:
• IDE for configuring and managing objects
• System Management Console (SMC) for performing maintenance and system
administration functions.
• Any runtime operations
13.1.2 The ArchestrA Security Model

Each attribute of an AutomationObject is given a security classification. This provides the

ability to define who can write to attributes of an object.
Security Groups are simply the grouping of objects that you want to behave in the same way
with respect to security. Every AutomationObject belongs to exactly one Security Group. By
default all new objects belong to the Default Security Group, which cannot be removed.
Roles generalize Users function, such as Intake Operator or Dispatcher. Roles are granted
permissions onto a number of Security Groups. If, for instance, a Role is granted Tuning access
to a Security Group, then that role has write permissions to all object attributes with a security
classification of Tuning (but none other). Roles are also granted utility functions-based
permissions, such as Deploy or Can Edit.
The final aspect of the Security Model is the User. This describes the access to the system
allowed by a User. The User can be granted as many Roles as needed to perform their job.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 46 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

13.2 Authentication Mode

13.2.1 Configure Security Groups

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 47 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

13.2.2 Configure Security Roles

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 48 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

13.3 Set Object Security

Operators interact with objects through the individual attributes of those objects. Each
attribute on the Object Editor that can be modified by operators at run time and can have an
associated security control, which is used to modify its run-time security classification.

When security is enabled, security symbols will appear next to values for which security is
configurable. Security symbols are not visible in the template or its derived instances unless
enabled in the parent template. If an attribute's security classification is configurable, click
the security control to select one of seven possible states:

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 49 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

• FreeAccess Lets you change this value without restriction even if you have no defined
permissions on the object. Anyone can write to these attributes to perform safety or
time critical tasks that can be hampered by an untimely logon request, such as halting
a failing process.
• Operate Lets you work with Operate permissions to do certain normal day-to-day
tasks. These include writing to attributes like Setpoint or Command for a Discrete
Device object. This level of security requires you to have Operate permission for the
security group for the object.
• SecuredWrite Requires you to authenticate using your user name and password each
time you want to write to the attribute. You also need to have Operate permissions
for the object.
• VerifiedWrite Requires you to have Operate permissions to log on again and a
second, different user to also log on as the verifier before writing to the attribute. The
verifier needs to have Can Verify Writes permission for the object.
• Tune Allows users with Tune Operational permissions to tune the attribute in the run-
time environment. Examples of tuning are attributes that adjust alarm setpoints and
PID sensitivity.
• Configure Allows users with Configure Operational permissions to configure the
attribute’s value. Requires that the user first put the object off scan. Writing to these
attributes is considered a significant configuration change. For example, a PLC register
that defines a Discrete Device input.
• ViewOnly Only allows users to read this attribute’s value in the run-time environment.
This attribute is never written to at run time, regardless of the user's permissions.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 50 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

14 Introduction to QuickScript.NET
14.1 Script Editing Styles and Syntax
Application Server supports two types of scripts:
• Simple scripts can perform assignments, comparisons, simple math functions, and
similar actions.
• Complex scripts can perform logical operations using conditional branching with IF-
THENELSE type control structures.
14.1.2 IDE Scripts Tab

From within the Script Editor the user can leverage the Attribute-Picker tool to browse
through the attribute namespace of the hosting object and other objects to pick a certain
attribute to be included in the script code. The tool does not distinguish between attributes
of on-engine and offengine objects.
Similar to browsing for script functions, the user can also browse for .NET / COM objects that
have been imported using the IDE.
Script language syntax validation is performed by selecting the red check mark above the
script window.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 51 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

14.1.3 Script Execution Types

The editor exposes five script types

Startup scripts are called when an object containing the script is loaded into memory, such
as during deployment, platform, or engine start.
OnScan scripts are called the first time an AppEngine calls this object to execute after the
object’s scan state changes to OnScan
Execute scripts are called each time the AppEngine performs a scan and the object is OnScan.
OffScan scripts are called when the object is taken OffScan. This script type is primarily used
to clean up the object and account for any needs to address as a result of the object no
longer executing.
Shutdown scripts are called when the object is about to be removed from memory, usually
as a result of the AppEngine stopping. Shutdown scripts are primarily used to destroy COM
objects and .NET objects and to free memory.
14.1.4 Language Definition
All QuickScript .NET keywords and variable name identifiers are not case sensitive. However,
the case is preserved throughout editor sessions.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 52 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

Both single line and multi-line comments are supported. Single line comments start at a ' in
a source code line that has no matching ending ' in the line. Multi-line comments start with
a { and end with a } and can span multiple lines as the name suggests.
Examples:
Dim A; 'This is a single line comment
Dim B; {This is an example of a multi-line comment}
14.1.5 Attribute References
Relative References : References that go up the hierarchy to parent objects are called relative
references.

Relative references are especially useful in templates because absolute references typically
do not apply or make sense.

14.2 Demonstration different script examples

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 53 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

15 Introduction to Industrial Graphics

15.1 Introduction
Industrial graphics can be used to customize graphic representations of your processes in a
view application. They can be embedded in or linked to automation objects, providing an
efficient way to visualize object-specific information in your application, such as processing
status, alarms, history, and more. They also support the use of custom properties, relative
references, scripts, and more.
Industrial graphics are also known as symbols. Prebuilt libraries of symbols are provided with
System Platform, including the Industrial Graphic Library and the Situational Awareness
Library. You can use symbols from these libraries in your applications, or create your own
symbols with the Graphic Editor in the System Platform IDE.
15.1.2 Graphics Tab
The Graphics tab in the System Platform IDE hosts libraries of symbols, controls, profiles,
layouts, and other graphic-related content that can be used in the Galaxy. Items available on
the Graphics tab by default depend on which Galaxy template was used to create the Galaxy.

15.1.3 Graphic Toolsets

Symbols, controls, and other items listed in the Graphics tab can be organized into a hierarchy
of toolsets. Some toolsets are included on the Graphics tab by default, depending on the
Galaxy type used to create the Galaxy. You can also create your own toolsets and sub-toolsets
to organize your symbols, controls, and other items as needed.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 54 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

15.1.4 Import and Export Symbols

You can export one or more selected symbols or graphic toolsets to an aaPKG file. From the
Graphics tab, select the symbols or graphic toolsets that you want to export. Then from the
Galaxy menu, select Export | Object(s).
15.1.5 Symbol Libraries
Two symbol libraries are provided on the Graphics tab for all Galaxy types:
• Industrial Graphic Library contains pre-built, realistic-looking symbols of standard
industrial objects
• Situational Awareness Library contains pre-built symbols with a simplified look and
minimum visual detail, designed to enhance an operator’s situational awareness of
current process conditions

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 55 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

16 Graphic Editor
16.1 Introduction
You can use the Graphic Editor to create, configure, and modify symbols. The editor provides
a drawing area called the canvas, on which you can build symbols. You can embed basic
graphic elements, such as lines, rectangles, curves, and more onto the canvas. Or, you can
embed symbols from Toolbox tab, Assets tab, and Templates tab onto the canvas and use
the symbols as-is or modify them.

• Toolbars and Menus: Buttons and menu commands for performing various functions,
such as saving the symbol, zooming the display, selecting line color, and more.
• Drawing Canvas: Area where elements are placed and arranged to create a symbol.
• Elements List: Hierarchical list of elements on the canvas.
• Element Tools: Collection of elements that you can use to create symbols on the
canvas. Includes basic elements, such as lines, rectangles, and so on, as well as other
tools and controls.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 56 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

17 Graphic Tools and Animations

17.1 Introduction
You can use tools from the Graphic Editor to draw graphic elements on the drawing canvas.
Graphic elements can be directly edited on the canvas using tools provided in the Graphic
Editor, such as menu options, toolbar options, properties, and more. Animations can also be
added to the graphic elements.
17.1.2 Tools Pane
The Graphic Editor provides a set of element tools that you can use to draw and select
elements on the drawing canvas.
The Tools pane is a collection of elements that you can use when creating and editing
symbols.

17.1.3 Elements List

The Elements pane shows a hierarchical list of graphic elements and embedded symbols by
name on the drawing canvas.

17.1.4 Demonstration

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 57 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

18 Industrial Graphics with Objects

18.1 Introduction
When adding symbols into an automation object, you can create symbols within the object
and then embed symbols from the Graphics tab into those symbols. Alternatively, you can
use the linked symbols feature, whereby you directly link external symbols from the Graphics
tab to the automation object.
When adding a symbol or linking an external symbol in a template object, the symbol in the
template will be propagated to all derived objects. The symbols inherited from the template
object cannot be removed.
18.1.2 Linked Symbols vs. Added Symbols
Linking an external symbol to an automation object creates an association between the object
and a symbol in the Graphics tab. The symbol in the Graphics tab can be linked with other
automation objects, which are not necessarily part of the derivation hierarchy. Changes to
the symbol from the Graphics tab will apply to all automation objects to which this symbol is
linked.
On the other hand, adding a symbol to an automation object is to create a symbol that is
natively hosted by the object. You can edit the symbol within the object, such as when you
embed a symbol from the Graphics tab and then customize it as needed for the object. When
the symbol in a template object changes, the changes will propagate to its child objects and
wherever they are referenced.
18.1.3 Manage Symbols from the Object Editor
When editing an object in the Object Editor, you can link external symbols or add symbols to
the object from the Content pane on the Attributes tab.

18.1.4 Relative References

References that go up the object hierarchy to parent objects are called relative references.
Relative references, such as “Me” and “MyArea” are valid reference strings. The following
relative references refer to the current object.
• Me
• MyArea
• MyEngine

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 58 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

• MyPlatform
• MyContainer
• MyHost
18.1.5 Creating Symbols for Automation Objects

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 59 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

19 AVEVA Operations Management Interface (OMI)

19.1 Introduction
Operations Management Interface leverages both HMI and SCADA systems to deliver a
convergence platform for both Operational Technology (OT) and Information Technology
(IT). Built on the same core ArchestrA technology as System Platform, the Operations
Management Interface visualization engine provides rich, modern user experiences across
platforms.
With Operations Management Interface, applications can be assembled based on a data
model, resulting in minimal engineering and increased manageability. Additionally, an out-
of-the-box framework provides native multi-monitor support.
Operations Management Interface is installed as part of Application Server. It can coexist on
the same computer as InTouch for System Platform
19.1.2 Operations Management Interface Applications
An Operations Management Interface application is called a View Application, or just
ViewApp. ViewApps are represented as objects that are created, configured, and deployed
from within the System Platform IDE. Once deployed, they can be launched through the
AVEVA OMI Application Manager or the AVEVA InTouch Application Manager.
19.1.3 Features and Capabilities
Runtime Preview:Operations Management Interface ViewApps can be tested in a runtime
preview session, without deploying or redeploying the ViewApps.
Built-in navigation: ViewApps have a built-in navigation model that enables users to browse
for and display graphics and other types of content in a running ViewApp. The default
navigation model is based on the plant model of the Galaxy, but the navigation hierarchy can
be customized.
ViewApps have built-in security that is integrated with Galaxy security. ViewApp security is
built into the application’s navigation so that a navigation item can be shown or hidden at
runtime based on the logged-in user’s security credentials as defined for the Galaxy.
Single sign-on service enables the ViewApp to provide common authentication for the OMI
Apps that are included in the ViewApp. In a running ViewApp, OMI Apps that require user
authentication run in the context of the logged-in ViewApp user
Operations Management Interface natively supports industrial graphics, such as symbols
provided in the Industrial Graphic and Situational Awareness libraries, as well as custom
symbols created with the Graphic Editor. Symbol features, such as animations, element styles,
and Symbol Wizards created using the Symbol Wizard Editor are supported.
Operations Management Interface supports faceplate compatibility mode for symbols.
Symbols enabled for faceplate compatibility mode allow users to manage a set of similar
symbols using a single symbol. Instead of creating a separate faceplate for each symbol, a
faceplate can be adapted for different symbol configurations by showing or hiding graphic
elements on the faceplate itself at runtime.
Resolution Independence for Displays
Custom Namespaces for ViewApps.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 60 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

19.1.4 Visualization Components

19.1.5 Screen Profiles, Layouts, and Panes

Framework components of an Operations Management Interface ViewApp include screen
profiles and layouts, which are created before you create a ViewApp.
A screen profile defines the physical characteristics of one or more client workstation
monitors that will show a running ViewApp, including how the screens are arranged with
respect to one another.
A layout consists of one or more rectangular areas of content for a screen, and is used to
determine how runtime information is displayed in a ViewApp. The rectangular areas within
the layout are called panes. The layout determines how the panes are positioned on the
screen, as well as other visual characteristics and runtime behaviors.
A pane is a subdivision of a layout and serves as a container for content to be displayed at
runtime. Each pane can be configured to hold zero, one, or more content items, such as
symbols, navigation trees, another layout, and others. A pane can encompass an entire screen
or only a portion of a screen

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 61 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

19.1.6 OMI Apps

An OMI App is a collection of one or more controls with specific functions and capabilities,
and is primarily developed with Windows Presentation Foundation (WPF). Other
technologies, such as Windows Forms (WinForms) and HTML5, can also be used. Apps can
be used as content in an Operations Management Interface ViewApp to provide various types
of information based on their function and configuration, such as a navigation hierarchy, an
interactive map, and more. A set of default Apps is included in the Galaxy.
Eg AlarmApp, TrendApp, MapApp NavigationApp etc
19.1.7 Screen Profiles vs. Physical Monitors

19.1.8 Create a Screen Profile

Screen Profile Editor
Add Screens
Set Primary Screen
Remove Screens
Arrange Screens

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 62 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

19.1.9 Layouts and Panes

A layout defines the organization of one or more rectangular areas of a screen called panes,
which contain content shown in a running ViewApp. A pane is a subdivision of a layout and
is a container for content. Content can be symbols, Apps, or a layout assigned from another
layout.
Create a Layout
Layout Editor
• Build Page
• Script Page

Add Panes
Pane Options
Slide-In Panes
Assign Content to Panes
Apply Content Types to Panes
Apply Content Types to Layouts

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 63 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

19.1.10 Creating a Screen Profile and Layout Demonstration.

19.1.11 ViewApps
$ViewApp is provided in the Galaxy as a base system object to create Operations
Management Interface applications. A derived ViewApp template can be configured in the
ViewApp Editor for creating a view application as needed. After a derived ViewApp object is
configured, an instance can be derived and deployed to run the view application.
To create a ViewApp, you must derive a ViewApp template from the $ViewApp base system
object, initialize and configure the template, and then derive a ViewApp instance from the
ViewApp template.
19.1.12 ViewApp Editor
• Configure and customize the navigation model for the ViewApp
• Edit or change the screen profile associated with the ViewApp
• Edit, change, or remove a layout associated with the ViewApp
• Edit or add content to layout panes
• Test the ViewApp in preview mode, without deploying or redeploying the instance

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 64 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

20 Built-In Navigation
By default, the built-in ViewApp navigation model reflects the plant model for the Galaxy.
In the navigation list in the ViewApp Editor, the root of the model is named Home, with Assets
shown as a top-level item for objects as reflected in the Model view.
The navigation is customizable. For example, you can add and remove custom navigation
items to the navigation hierarchy. The root item (named Home by default) cannot be deleted,
but it can be renamed.

20.1.2 Auto-Fill
Auto-Fill is a navigation behavior that controls how content is automatically placed in panes,
without having to configure each view of a running ViewApp.
To use this feature:
• The layout panes of the ViewApp must have the Use For Auto-Fill property enabled
• The navigation items of the ViewApp must have Auto-Fill Content configured as
Current only; Current, then up; or Current, up, then down; but not None.
Auto-Fill Content options are:
• Current only: At runtime, content from the current navigation item is automatically placed in
available panes of the layouts assigned to screens of the screen profile
• Current, then up: At runtime, Auto-Fill searches for layouts that initially fill the screens prior
to determining the content to be shown in specific panes. The current navigation item is
inspected for any commands that place layouts or content full screen. For screens that remain
empty, Auto-Fill examines the parent navigation item up to the root of the navigation hierarchy
for additional content to apply to the empty screens.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 65 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

• Current, up, then down: Similar to Current, then up with an additional action. At runtime, if
the Auto-Fill search reaches the root of the navigation hierarchy and there are still empty
screens or panes, the first child of the current navigation item is inspected to see if it has
content that applies to the available screens or panes.
• None: At runtime, no content associated with this navigation item is automatically shown
unless specific commands have been created to show content in a running ViewApp.

If multiple panes configured for the same content types are available, but there is only one
symbol with a content type that matches the panes, then only that symbol will be populated
in one of the panes. Panes are filled in alphabetical order of the pane names. In the following
example, only the Detail symbol is filled to Pane01

Current Then Up

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 66 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

20.1.3 Preview Mode

You can use the preview mode from the ViewApp Editor to test your ViewApp without
deploying or redeploying it to runtime. The preview session launches immediately and runs
in a separate window to show the current content and ViewApp configuration. The current
navigation item in the preview session is based on which navigation item is selected in the
ViewApp Editor.

Automatic Update Mode

20.1.4 Deploy a ViewApp

Client System

20.1.5 Creating and Running a ViewApp Demonstration

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 67 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

21 Custom Navigation
21.1 Introduction
A ViewApp provides built-in navigation, which can be customized to give users the ability to
view specific types of content associated with each navigation item.
21.1.2 Custom Navigation Commands

21.1.3 Navigation Item References

One of the properties for a Navigation item is Reference, which is the full path referenced by
the item in the Navigation model hierarchy. To configure the Reference property, click the
down-arrow to the right of the Reference field. You can configure a reference to an asset
from the Model hierarchy (plant model) or to a specific toolset from the Graphics tab.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 68 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

22 ViewApp namespaces
22.1 Overview
A ViewApp namespace is a repository for ViewApp attributes. You can create references to
these attributes in scripts, symbol animations, and OMI Apps to allow attribute values to be
shared across different layouts and panes of a running ViewApp.
22.1.2 Predefined Namespaces and Attributes
Predefined namespaces and attributes are provided according to their functionality
• Language namespace: To access and set the current language information
• System namespace: To access date and time information
• Navigation namespace: To access and interact with the built-in navigation
• Security namespace: To access security-related information
• Settings namespace: To use with industrial graphics as global properties
• ViewApp namespace: To access the read/write status of a running ViewApp and set
the display of an on-screen keyboard for use in a running ViewApp.
• Style namespace: To access Galaxy style information
22.1.3 Reference ViewApp Namespace Attributes
References to ViewApp namespace attributes must be prefixed with the reserved system
name “MyViewApp” and be in the following form:
MyViewApp.ViewAppNamespace.AttributeName
MyViewApp.Navigation.PreSibling
MyViewApp.Navigation.NextSibling

22.1.4 Demonstrations

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 69 of 73

AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

23 OMI ViewAPP Security

23.1 Introduction
A ViewApp has built-in security that is integrated with Galaxy security. Industrial graphics can
be shown or hidden during runtime in the ViewApp, based on current logged in user
information. For example, you can use the current logged in user information as a condition
to configure the visibility animation for a specific graphic element. If the condition is true, the
graphic will display at runtime.
Before you implement security in a ViewApp, the following must be completed
• Security must be enabled for the Galaxy with an authentication mode of Galaxy, OS
User Based, or OS Group Based. Additionally, roles and users must be created and
configured with the proper Operational permissions.
• Based on the authentication mode you select, ViewApp users must be added to the
security system with a user name and password. The user should be associated with
a role in the security authentication system with a defined Access Level.
Major tasks for implementing security for ViewApps include the following:
• Implement login security within the ViewApp by using the security-related method
ShowLoginDialog(), for example, in an action script of a button.
• Implement visibility or disable animations using security-related attributes within the
symbols that are going to be used as content of the ViewApp. For example,
MyViewApp.Security.LoggedInAccessLevel can be used.
• Configure the Access Level property for a navigation item in the ViewApp, which
determines whether the navigation item and its referenced hierarchy are accessible in
runtime.
When a navigation item is selected in the ViewApp Editor, the Access Level and User Roles
properties are available in the Security category on the Properties tab. They are set to “Not
Configured” by default.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 70 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

23.1.2 Security Namespace and Security-Related System Attributes

Security-related system attributes operate in the MyViewApp.Security namespace. The names
of the security attributes are specified with the prefix MyViewApp.Security. For example, you
might use MyViewApp.Security.attribute_name.
The following security-related attributes can be used in Value Display animations to display
information about the user logged in to a running ViewApp.
• AutoLogOff: Returns True or False to indicate if a user will be logged off after a period
of inactivity.
• AutoLogOffRemainingTime: Returns the remaining length of a user’s inactivity period
in seconds.
• AutoLogOffTimeSpan: Specifies the length of the inactivity period in seconds a logged
in user is allowed. The default value is 600 seconds.
• AutoLogOnCurrentUser: Returns True or False to indicate if users can log on
automatically to a ViewApp with their Windows credentials. The default value is True.
• LoggedInAccessLevel: Read Only Access level of the security role assigned to the user
logged in to ViewApp.
• LastSuccessfulLogin: UTC time stamp of the most recent successful log.
• LoggedIn: Returns True or False, indicating if a user is currently logged into a ViewApp
or not.
• LoggedInUserName: Read Only User name specified by the user logged in to a
ViewApp.
• LoggedInUserRoles: Read Only User roles assigned to the logged-in user, in CSV
format.
23.1.3 Implementing Security in a ViewApp Demonstration

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 71 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

24 OMI Alarms and Events App

The alarm and event capabilities allow users to automate the detection, notification,
historization, and viewing of application (process) alarms and events or system/software
alarms and events.
24.1.2 The Platform as an Alarm Provider
A Platform can act as a single alarm provider that provides alarms to the visualization client’s
distributed alarm subsystem. A Boolean check box is provided in the Platform automation
object indicating whether or not it subscribes to Areas for alarm and event reporting.
24.1.3 Alarm Queries
Alarm queries are used within Alarm Clients to retrieve real-time alarm information and event
reports from the Galaxy.
\\nodename\Galaxy!area!object.attribute
\Galaxy!area!object.attribute
\Galaxy!Area1 \Galaxy!Area2
24.1.4 Alarm Border Animation
Alarm Border animation shows a highly visible border around a symbol or graphic element
when an alarm occurs. The color and fill pattern of the border indicates the severity and
current state of the alarm. Plant operators can quickly recognize alarm conditions when Alarm
Border animation is used.

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 72 of 73

 AVEVA SYSTEM PLATFORM
TRANING MANUALAVANCEON DOCUMENT TEMPLATE
FOR ASHGAL DNMC PROJECT

24.1.5 Changing the Alarm Border Indicator Icon

Alarm border animation shows an indicator icon at the top left corner of the border with
alarm severity as a number from 1 to 4. Other indicator images represent alarm suppressed,
silenced and shelved modes.
A default Alarm Border indicator image is assigned to each alarm mode and severity level.
The default images appear in the Image fields of the Alarm and events dialog box. The images
are saved as files in the installation path.

24.1.6 Using AlarmAPP

AlarmApp is an OMI App that you can place in your ViewApps to show live and historical
alarms and events. At runtime, the pane configured with the AlarmApp shows alarms and
events in tabular form, with each row representing a single alarm or event. The background
color of a row for an alarm indicates the severity and current state of the alarms.
24.1.7 Alarm Queries
The AlarmApp supports standard Galaxy alarm query formats. Some example formats are:
• \galaxy!area

• \\node\galaxy!area

24.1.8 Demonstration

Q1808002-UM-M3SCADA-R0 © 2024 Avanceon Page 73 of 73