You are on page 1of 29

Symphony Plus Training

Chapter 1 Design And Engineering Considerations

TABLE OF CONTENTS

Chapter 1 Design And Engineering Considerations

1

1.1

General Information

2

1.1.1 Objectives

2

1.1.2 Legend

2

1.1.3 Reference Documentation

2

1.2

S+ Operations Architecture

3

1.2.1 “Standalone” Architecture: single node

3

1.2.2 “Server-less” Architecture

4

1.2.3 “Server-Based” Architecture

5

1.2.3.1 “Server / Client with separate Historian” Architecture

5

1.2.3.2 “Server / Client with integrated Historian” Architecture

6

1.2.4 “Multi System” Architecture

6

1.2.5 “Hierarchical” Architecture

7

1.2.6 “Composite” Architecture

7

1.3 S+ Operations Support Node Type

8

 

1.4 S+

Operations

HSI Architecture

10

1.5 S+ Operations HISTORY Architecture

11

1.6 HARDWARE and SOFTWARE Requirements

14

 

1.6.1 General thoughts on hardware requirements

14

1.6.2 Summary Table

15

1.6.3 Software Requirements Details

15

1.6.4 Hardware Serverless Configuration

15

1.6.4.1 Small (<1000 tags)

15

1.6.4.2 Large

16

1.6.5

Hardware Server based Configuration

16

1.6.5.1 Small system servers (<1000 tags)

16

1.6.5.2 Large system with separated history

16

1.6.5.3 Large system with integrated history

16

1.6.5.4 Operator Clients for server based configurations

16

1.6.5.5 Full Office Client

16

1.6.5.6 History server if separated

16

1.6.5.7 Volume estimation of hard disks for History Server (Suggestion)

17

1.6.5.8 Applications server

17

1.7

SYSTEM LIMITS

18

1.7.1 Serverless Architecture

18

1.7.2 Server based Architecture

18

1.8

DATASHEET S+ Operations

19

1.8.1 Features: Sizes

19

1.8.2 Features: Details

21

1.9

S+ Operations Size the System

25

1.9.1

S+ Operations Size & Queue

27

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

1.1 General Information

1.1.1 Objectives

On completion of this chapter you will be able to:

· You'll be able to know the different types of nodes that can be configured with S+

· Identify which are different kind of S+ Operations Configuration available

· Configure correctly Size and Options of the system depending of the different architecture

1.1.2 Legend

>

Indicates when you go from one menu to a sub-menu

Italic

Indicates object and file names

Bold

Indicates dialog box buttons, tabs, menus etc. Indicates important topics

Indicates start/explanation of student activity

Indicates start/explanation of student activity

1.1.3 Reference Documentation

2VAA003351

Symphony Plus 2.0 Release Notes

2VAA001148E

Operation System 2.0 Configuration Guide

Symphony Plus Training

1.2 S+ Operations Architecture

Symphony Plus unique system architecture provides flexible and scalable configurations ranging from small server-less to large multi-system, multi-server architectures.

SPlus is a versatile software package that allows various hardware configurations according to the number of functions and specific customer requests. The main features implemented on a S+ node can be subdivided as follows:

o

Server functions, which mainly consist of data acquisition, alarm processing, calculation generation, historical data recording and so on.

o

Client functions, which provides the Human System Interface towards the Server functions. These functions provide the capability to access the Server data by mimic displays, alarm lists, trends, and to control the field devices. The Client functions also provide the capability for an engineer to configure and maintain the various databases, which are implemented on the Server. According to the feature implemented, a S+ node can be defined as Server only, Client/Server or Client only.

1.2.1 “Standalone” Architecture: single node

Client/Server or Client only. 1.2.1 “Standalone” Architecture: single node One server, with possible client connection

One server, with possible client connection

Client/Server or Client only. 1.2.1 “Standalone” Architecture: single node One server, with possible client connection

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

1.2.2 “Server-less” Architecture

Server-less architecture relates to S+ Operations in which there is no central system server. This is a “standalone” system in which each node has its own set of databases for Process tags, graphics, trends, etc… SPlus Engineering (Composer) is also based on Client Server architecture, but can be used as a combined Server/Client node in smaller systems.

is also based on Client Server architecture, but can be used as a combined Server/Client node
is also based on Client Server architecture, but can be used as a combined Server/Client node

Symphony Plus Training

1.2.3 “Server-Based” Architecture

The specifics of server-based architecture are the dedicated Servers in “1oo n” collection acts as gateway for values, operator interactions, messages (alarm and event) and time synchronization between Symphony control systems and the S+ Operations level. Combining of an Operations Server and an Engineering server is also supported.

Server and an Engineering server is also supported. 1.2.3.1 “Server / Client with separate Historian”

1.2.3.1 “Server / Client with separate Historian” Architecture

Server and an Engineering server is also supported. 1.2.3.1 “Server / Client with separate Historian” Architecture

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

1.2.3.2 “Server / Client with integrated Historian” Architecture

“Server / Client with integrated Historian” Architecture 1.2.4 “Multi System” Architecture The Multi System is

1.2.4 “Multi System” Architecture

The Multi System is based only on Server based Unit architectures, only. The Multi System connects different systems. Multi system configuration can be combined in different solutions, in either hierarchical or composite architecture.

Multi system configuration can be combined in different solutions, in either hierarchical or composite architecture.
Multi system configuration can be combined in different solutions, in either hierarchical or composite architecture.

Symphony Plus Training

1.2.5 “Hierarchical” Architecture

This solution is used when plant areas need a dedicated HSI system, and there is a central control room with access to the whole plant Each area server acquires data from the related plant area through the connected controllers. The central plant server acquires tags from area servers through proprietary “Inter-Server” protocol. Area clients are logically connected to the corresponding area server while plant clients are logically connected to the plant server, and have access to tags from the whole plant The HSI of the central control room has its’ own S+ Operation system with Server and Clients, as well as an independent S+ Engineering environment to configure the Central control room HSI. The data from the plant units will be transferred to the central control room S+ Engineering and will be loaded from there to the central HSI.

and will be loaded from there to the central HSI. 1.2.6 “Composite” Architecture This solution is

1.2.6 “Composite” Architecture

This solution is used when servers are required to maintain a complete database Each server acquires data from the related plant area through the connected controllers. Tags from other plant areas are acquired through the network via proprietary “Inter- Server” protocol. Clients are logically connected to one server, and from that server they can see tags for

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

all plant areas, each System (Unit in this case) has an independent S+ Engineering console. The distribution of the configuration to the S+ Operation Server Clients is done by the S+ Engineering system.

Server Clients is done by the S+ Engineering system. 1.3 S+ Operations Support Node Type S+
Server Clients is done by the S+ Engineering system. 1.3 S+ Operations Support Node Type S+

1.3 S+ Operations Support Node Type

S+ Operations supports the following node types:

· S+ Operations Servers (SPO)

SPO are real-time operations servers that support local and remote SPC. The SPO

also connects by a specific DCS scanners and drivers to the control network (controllers). The SPO is the core of the S+ Operations architecture.

· S+ Operations Clients (SPC)

SPC are operator consoles or workstations. They exist as remote and local SPC \

depending on where the server is. An SPC always comes with an installed HC.

· S+ Operations Serverless Client (SLC)

SLC combines the functions of a SPO and an SPC in one computer that independently from any other S+ Operations computer connects to the DCS network as an independent node.

· S+ Operations History Server (HS)

An HS is a history server node that collects history data for real-time data such as

Symphony Plus Training

analogue and binary values (stored in a priority database) but also has storage (MS SQL server) for alarm and event messages. A history server does server the operator consoles (SPC) with history data and also supports full office clients.

· Composer Operations Server and Client (CO)

CO is used to configure the operator station software in the various nodes. CO resides in the engineering server. The engineering server cannot be an SPO or SLC but any other computer in the desired configuration.

· S+ Operations History Full Clients (HC)

The HC (Navigator) comes with a wide set of tools to view, monitor, process and analyse history data. It supports the configuration of office graphics, office trend lines, reports and also viewing of alarms and event messages.

· S+ Operations Webserver (WS)

The WS support the connection of web clients based on http (https) protocol. Web clients can be used to monitor graphics (both operator and office graphics), trends,

reports and alarm and events.

· S+ Operations Application Server (APS)

The APS is used to run specific applications such as performance calculations, report scheduler, totalizer programs and any kind of optimization application. Typically an APS is an HC. Before starting with the installation the architecture of the desired configuration must be defined. Composer Operations (CO) or if you plan to use Composer System can help you with this definition. For supported configuration please refer to the section of CO. All standard configurations are described there. Of course also private configurations can be realized. Typically those should be derived from the standard configurations. The individual settings for those are done in CO.

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

1.4 S+ Operations HSI Architecture

Symphony Plus Operations HSI Server:

· Supports multiple servers with parallel data streams

· Provides N+N server redundancy

· Symphony Plus Operations HSI Clients can connect to any server

Plus Operations HSI Clients can connect to any server · Symphony Plus Operations HSI Clients have

· Symphony Plus Operations HSI Clients have a Server Access List: if communication with a server is lost, the client re-connect automatically to the next server

· Each server can acquire data in parallel, or, if parallel paths not available, from other servers

· One server is the designated MASTER for actions on the field

· Backfill of data and configuration changes

servers · One server is the designated MASTER for actions on the field · Backfill of

Symphony Plus Training

1.5 S+ Operations HISTORY Architecture

List of all supported architecture and related configuration modality.

· single server HSI+HISTORIAN

configuration modality. · single server HSI+HISTORIAN HSI + HISTORY Server · single server HSI + server

HSI + HISTORY Server

· single server HSI + server HISTORIAN

+ HISTORY Server · single server HSI + server HISTORIAN HSI Server HISTORY Server · double

HSI

Server

Server · single server HSI + server HISTORIAN HSI Server HISTORY Server · double servers HSI+HISTORIAN

HISTORY

Server

· double servers HSI+HISTORIAN redundant

HISTORY Server · double servers HSI+HISTORIAN redundant HSI + HISTORY Server1 HSI + HISTORY Server2 ·

HSI + HISTORY

Server1

double servers HSI+HISTORIAN redundant HSI + HISTORY Server1 HSI + HISTORY Server2 · double server HSI

HSI + HISTORY

Server2

· double server HSI + single server HISTORIAN

Server1 HSI + HISTORY Server2 · double server HSI + single server HISTORIAN HSI Server1 HSI

HSI

Server1

Server1 HSI + HISTORY Server2 · double server HSI + single server HISTORIAN HSI Server1 HSI

HSI

Server2

Server1 HSI + HISTORY Server2 · double server HSI + single server HISTORIAN HSI Server1 HSI

HISTORY

Server

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

· double servers HSI + double servers HISTORIAN redundancy

· double servers HSI + double servers HISTORIAN redundancy HSI HSI HISTORY HISTORY Server1 Server2
· double servers HSI + double servers HISTORIAN redundancy HSI HSI HISTORY HISTORY Server1 Server2
· double servers HSI + double servers HISTORIAN redundancy HSI HSI HISTORY HISTORY Server1 Server2
· double servers HSI + double servers HISTORIAN redundancy HSI HSI HISTORY HISTORY Server1 Server2

HSI

HSI

HISTORY

HISTORY

Server1

Server2

Server1

Server2

· different plant units with local HSI servers and unique HISTORIAN server

Unit1

with local HSI servers and unique HISTORIAN server Unit1 HSI HSI HISTORY Server1 Server2 Server Unit2
with local HSI servers and unique HISTORIAN server Unit1 HSI HSI HISTORY Server1 Server2 Server Unit2
with local HSI servers and unique HISTORIAN server Unit1 HSI HSI HISTORY Server1 Server2 Server Unit2

HSI

HSI

HISTORY

Server1

Server2

Server

Unit2

HSI HSI HISTORY Server1 Server2 Server Unit2 HSI Server1 HISTORY Server · different plant units with

HSI

Server1

HISTORY Server1 Server2 Server Unit2 HSI Server1 HISTORY Server · different plant units with local HSI

HISTORY

Server

· different plant units with local HSI servers and double HISTORIAN servers

Unit1

Unit2

local HSI servers and double HISTORIAN servers Unit1 Unit2 HSI Server1 HSI Server1 HSI Server2 HSI

HSI

Server1

servers and double HISTORIAN servers Unit1 Unit2 HSI Server1 HSI Server1 HSI Server2 HSI Server2 HISTORY

HSI

Server1

double HISTORIAN servers Unit1 Unit2 HSI Server1 HSI Server1 HSI Server2 HSI Server2 HISTORY Server1 HISTORY

HSI

Server2

servers Unit1 Unit2 HSI Server1 HSI Server1 HSI Server2 HSI Server2 HISTORY Server1 HISTORY Server1 HISTORY

HSI

Server2

Unit1 Unit2 HSI Server1 HSI Server1 HSI Server2 HSI Server2 HISTORY Server1 HISTORY Server1 HISTORY Server2

HISTORY

Server1

Unit2 HSI Server1 HSI Server1 HSI Server2 HSI Server2 HISTORY Server1 HISTORY Server1 HISTORY Server2 HISTORY

HISTORY

Server1

Unit2 HSI Server1 HSI Server1 HSI Server2 HSI Server2 HISTORY Server1 HISTORY Server1 HISTORY Server2 HISTORY

HISTORY

Server2

Unit2 HSI Server1 HSI Server1 HSI Server2 HSI Server2 HISTORY Server1 HISTORY Server1 HISTORY Server2 HISTORY

HISTORY

Server2

Symphony Plus Training

From the Historian system point of view the only differences for above configuration are into:

· Host file

· Redundant Activation (for S + Operations HSI does not matter what's on the other side

it is a historian or two HISTORIAN, other side is Historian, it means that I can add

redundant at later time without having to install anything from a DVD only

configuring Host File and Red Proxy)

Is so also possible to combine data from different historian servers but only at client level

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

1.6 HARDWARE and SOFTWARE Requirements

1.6.1 General thoughts on hardware requirements

The hardware requirements for S+ Operations are dependent on the following factors:

o

Number of tags in the HSI real-time database

o

Total number of clients

o

Special applications

o

Number of transactions/sec, configuration of signals, process dynamic, etc.

o

Expected response time for the users

The table below provides a summary of hardware configurations that were found to

produce good performance during the testing of S+ Operations.

WARNING: It is not allowed to run any other non-Symphony Plus software packages on the below mentioned configurations to ensure the stability and performance of the system.

Also keep in mind that systems which improve the reliability of the computer such as

RAID disks typically slow down the computer’s performance. When using RAID 5,

performance improvements are seen only if a high number of disks are

used (at least 8).

S+ Operations computer recommendations place a high emphasis on performance in

order to allow the system’s hardware to meet the needs of future

releases of S+ Operations without the need for exchanging hardware

components.

Lower performance hardware may provide adequate results but this

hardware has not been tested and it does not ensure performance provisions for the future.

Symphony Plus Training

1.6.2 Summary Table

Symphony Plus Training 1.6.2 Summary Table 1.6.3 Software Requirements Details S+ Operations 2.0 supports the following

1.6.3 Software Requirements Details

S+ Operations 2.0 supports the following operating systems:

o

Windows 2008 R2, 64bit Standard, English

o

Windows 7, 64bit Professional, English

Support for 32 bit Windows 7 Professional and Server 2008 R1 32 bit is limited to engineering nodes. 3rd party software as the following:

o

Microsoft Office 2010 Standard or Professional 32 bit

o

SQL Server 2008 32 bit or 64 bit

All referenced operating systems always include the latest service pack and security patches if not otherwise excluded.

1.6.4 Hardware Serverless Configuration

1.6.4.1 Small (<1000 tags)

Workstations should be either a Xeon processor with at least 2.4 GHz or a I5 processor with at least 3.3 Ghz. At least 4 GB RAM. Hard disks size as required for application size and history length.

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

1.6.4.2

Large

 

Workstations should be either a Xeon processor with at least 2.4 GHz or a I7 processor with at least 3.3 Ghz. At least 8 GB RAM. Hard disks as required for application size and history length

 

1.6.5 Hardware Server based Configuration

1.6.5.1

Small system servers (<1000 tags)

 

Server or workstations should be either a Xeon processor with at least 2.4 Ghz or a I5 processor with at least 3.2 Ghz.At least 4 GB RAM. Hard disks as required for application size and history length

1.6.5.2

Large system with separated history

 

Servers should be a Xeon processor with at least 2.4 Ghz and 8 GB RAM. Hard disks as required for application size.

1.6.5.3

Large system with integrated history

 

With all controllers HSI Server and History server can be integrated in one computer

providing the computer is a: Server with dual (2x) Xeon processors with at least 2.4 Ghz

and

8 GB RAM. Hard disks as required for application size and history length

1.6.5.4

Operator Clients for server based configurations

 

Workstations should be a Xeon processor with at least 2.4 Ghz or a I5 processor with at least 3.2Ghz and 4 GB RAM. Hard disks as required for application size.

1.6.5.5

Full Office Client

 
 

Workstations should be a I3 processor with a minimum of 2 GB RAM.

1.6.5.6

History server if separated

Servers or workstations should be either a Xeon processor with at least 2.4 Ghz or a I5 processor with at least 3.2 Ghz and 4 GB RAM. Hard disks as required for application size and history length

Symphony Plus Training

o

Processors with faster cycle times

o

Usage of solid state disks

While there are big differences today in solid state disks, those with a high reliability and throughput (read/write) should be used.

1.6.5.7 Volume estimation of hard disks for History Server (Suggestion)

Realtime value history:

S+ History only records signals when a value change occurs that exceeds a defined tolerance band. The maximum possible signal-recording rate relates to the sum of all changes of all tags

per second. Typically , a power plant unit with 20k tags and well-defined dead bands (0.1%-0.5% dead band and 0.5-1 seconds scan rate) uses about 50-200 GB/year disk space.

Event history:

As a calculation basis, S+ History consumes approximately 1.2 GB of storage space for every 1 million events. A typical power station with 10,000 alarm & events/ day consumes about 4.4 GB of disk space per year. NOTE:S+ Operations History is not compatible with hard disk greater than 6 Tera Bytes.

1.6.5.8 Applications server

Servers or workstations with either a Xeon processor with at least 2.4 Ghz or a I5 processor with at least 3.2 Ghz and 4GB RAM. Hard disks as required for application size.

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

1.7 SYSTEM LIMITS

1.7.1 Serverless Architecture

Serverless clients are always stand-alone. No interaction may occur between clients for HSI server functions. However S+ History functions can be configured to be on a single/redundant History server only.

configured to be on a single/redundant History server only. 1.7.2 Server based Architecture For architectures following

1.7.2 Server based Architecture

For architectures following the server based architecture, the below general limits apply.

1.7.2 Server based Architecture For architectures following the server based architecture, the below general limits apply.

Symphony Plus Training

1.8 DATASHEET S+ Operations

1.8.1 Features: Sizes

Minimum, default and maximum values of sized features of the package are described below. In most cases values listed as “Unlimited” are only limited by disk capacity.

of the package are described below. In most cases values listed as “Unlimited” are only limited

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

Symphony Plus Training

Symphony Plus Training 1.8.2 Features: Details

1.8.2 Features: Details

Symphony Plus Training 1.8.2 Features: Details

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

Symphony Plus Training

Symphony Plus Training

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

Symphony Plus Training

Symphony Plus Training 1.9 S+ Operations Size the System These paragraph will give instructions in order

1.9 S+ Operations Size the System

Symphony Plus Training 1.9 S+ Operations Size the System These paragraph will give instructions in order

These paragraph will give instructions in order to define the requirements for the size of the system and first configuration. Size of the system means define the numbers which compose the application starting

from:

o

Architecture (servers, redundancy, clients, historian, etc )

o

Typology of field interface

o

Third part system to be interconnect

o

System language

o Time Synchronization mode Evaluate the system sizes and options:

SERVERS:

o

Number (total number of servers involved)

o

Use (front-end, main, web, historian, gateway)

o

Redundancy (couple of servers)

o

DB node definition (list of server)

o

DB structure (fields to be used)

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

o Server alignment definition

CLIENTS:

o

Graphic area definition (display size, 16:9 or 4:3)

o

Number (total number of clients involved)

o

Clients connectivity (List of serves where to connect)

TAGS:

o

Number of tags

o

Tag typology

o

Number of OPC items (if OPC interface required)

o

Number of tags to historian

o

DB structure (fields to be used)

o

Networker definition

TRENDS:

o

Number of real time groups

o

DB structure (fields to be used)

o

Networker definition

o

Calculations:

o

Number of calculation

o

Frequency

o

DB structure (fields to be used)

o

Networker definition

USERS:

o

Number of users

o

Typology (Operator, Maintenance, Supervisor, etc…)

o

Language

o

DB structure (fields to be used)

Symphony Plus Training

MENU:

o

HMI navigation (tree standard, buttons, display links)

o

DB structure (fields to be used)

HISTORIAN:

o

Playback length

o

Tags to be exported to HISTORY

o

HISTORY Long term archive definition

1.9.1 S+ Operations Size & Queue

Base on above information a proper server S+O registries setting may be applied

before proceeding with build:

Set the following registry keys using SysSetup on the CO server:

Registry:

…\Options\AECondSize [0… max number of OPC tags configured in the application] - Number of entries OPC Alarm and Events conditions table

entries in the queu…\Options\EntriesInPlbQueue [0… max number of tags configured in the application] - Number of e to playback archive

…\Options\PlaybackMaxDays [0… max number of days for playback ] - Maximum number of days for playback snapshots. The max supported value is 10 days.

…\Options\PlaybackMaxFiles [0… max number of files into playback] - Maximum number of files for playback snapshots

…\Options\AlacQueueEntries [0… max number of tags configured in the application] - Number of entries in the alarm action queue

…\Options\DipQueueEntries [0… max number of tags configured in the application] - Number of entries in the exception queue to DIP

…\Options\NetQueueEntries [0… max number of tags configured in the application] - Number of entries in the network communication queue

…\Options\OpcQueueEntries [0… max number of OPC tags configured in the application] - Number of entries in the OPC queue

…\Options\ScannerQueueEntries [0… max number of Scanner tags configured in the application] -Number of entries in the exception queue to the Scanner

…Sizes\MXCIU [0…8] - Defines how many ICIs (C-NET to Computer Interface) are

present on the system. Size it according to the hardware configuration.

Set to 0 if C-NET interface is not used

…Sizes\MXINDX [0…512000] – Range of possible index to be associated to all the tags;

is related to tag DB field name. INDEX set the maximum number of

S322-01 S+ Operations - Advanced Configuration - Design and Engineering Considerations RevC.doc

index to be used in tag DB configuration, this value is not related to MXPVID or MXDIID but it must big enough to cover all the configured tags. …Sizes\MXPVID [0…256000] - This is the main system parameter that sizes the database and the files related to digital tags. Size it in order to have some spares but consider that this parameter is the most responsible for memory and disk space allocation. Number of analog tags (PVs). Set the maximum analog tags to be used in tag DB plus some spare. …Sizes\MXDIID [0…256000] - This is the main system parameter that sizes the database and the files related to digital tags. Size it in order to have some spares but consider that this parameter is the most responsible for memory and disk space allocation. Number of digital tags (DIs). Set the maximum digital tags to be used in tag DB plus some spare. …Sizes\NMALAD [0…max number of tags configured in the application] - Number of entries in the alarm display queue …Sizes\NMALQE [0… max number of tags configured in the application] - Number of entries per process in the alarm queue

[0… max number of tags configured in the application] - Number of entries per process in

Symphony Plus Training

Symphony Plus Training Same for HalmQueueEntries (Entries in Alarm Queue) (7500,7500,15000,15000,50000,5000)

Same for HalmQueueEntries (Entries in Alarm Queue)

(7500,7500,15000,15000,50000,5000)