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

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
Indicates dialog box buttons, tabs, menus etc.
Bold
Indicates important topics

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
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.
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
One server, with possible client connection
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.
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.
1.2.3.1 Server / Client with separate Historian Architecture
1.2.3.2 Server / Client with integrated Historian Architecture
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.
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.
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 InterServer protocol.
Clients are logically connected to one server, and from that server they can see tags for
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.
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
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.
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
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
1.5 S+ Operations HISTORY Architecture

List of all supported architecture and related configuration modality.
single server HSI+HISTORIAN
HSI + HISTORY
Server
single server HSI + server HISTORIAN
HSI
Server
HISTORY
Server
double servers HSI+HISTORIAN redundant
HSI + HISTORY
Server1
HSI + HISTORY
Server2
double server HSI + single server HISTORIAN
HSI
Server1
HSI
Server2
HISTORY
Server
double servers HSI + double servers HISTORIAN redundancy
HSI
Server1
HSI
Server2
HISTORY
Server1
HISTORY
Server2
different plant units with local HSI servers and unique HISTORIAN server
Unit1
HSI
Server1
HSI
Server2
HISTORY
Server
Unit2
HSI
Server1
HISTORY
Server
different plant units with local HSI servers and double HISTORIAN servers
Unit1
Unit2
HSI
Server1
HSI
Server1
HSI
Server2
HISTORY
Server1
HISTORY
Server2
HSI
Server2
HISTORY
Server1
HISTORY
Server2
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
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
Total number of clients
Special applications
Number of transactions/sec, configuration of signals, process dynamic, etc.
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 computers 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 systems 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.
1.6.2 Summary Table
1.6.3 Software Requirements Details

S+ Operations 2.0 supports the following operating systems:
o
Windows 2008 R2, 64bit Standard, English
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
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.
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
.
For maximum performance systems should have separated disks for programs, event
history and real time values. If a high volume of clients (in particular office clients) is
expected then the performance can be improved by:
Processors with faster cycle times
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.
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.
1.7.2 Server based Architecture

For architectures following the server based architecture, the below general limits apply.
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.
1.8.2 Features: Details
1.9 S+ Operations Size the System
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..)
Typology of field interface
Third part system to be interconnect
System language
Time Synchronization mode
Evaluate the system sizes and options:
SERVERS:
Number (total number of servers involved)
Use (front-end, main, web, historian, gateway)
Redundancy (couple of servers)
DB node definition (list of server)
DB structure (fields to be used)
Server alignment definition
CLIENTS:
Graphic area definition (display size, 16:9 or 4:3)
Number (total number of clients involved)
Clients connectivity (List of serves where to connect)
TAGS:
Number of tags
Tag typology
Number of OPC items (if OPC interface required)
Number of tags to historian
Networker definition
TRENDS:
Number of real time groups
Calculations:
Number of calculation
Frequency
USERS:
Number of users
Typology (Operator, Maintenance, Supervisor, etc)
Language
MENU:
HMI navigation (tree standard, buttons, display links)
HISTORIAN:
Playback length
Tags to be exported to HISTORY
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 [08] - 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 [0512000] Range of possible index to be associated to all the tags;
is related to tag DB field name. INDEX set the maximum number of
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 [0256000] - 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 [0256000] - 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 [0max 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
Same for HalmQueueEntries (Entries in Alarm Queue)

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

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

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

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

Uploaded by

Copyright:

Available Formats

Symphony Plus Training

Chapter 1 Design And Engineering Considerations