—

P OWER G E NER AT I O N & WATER

ABB Ability™ Symphony® Plus

S+ Operations 3.1 Service Pack 1
Release notes
—
P OWER G E NER AT I O N & WATER

ABB Ability™ Symphony® Plus

S+ Operations 3.1 Service Pack 1
Release notes
Notice
This document contains information about one or more ABB products and may include a description of or a
reference to one or more standards that may be generally relevant to the ABB products. The presence of any
such description of a standard or reference to a standard is not a representation that all of the ABB products
referenced in this document support all of the features of the described or referenced standard. In order to
determine the specific features supported by a particular ABB product, the reader should consult the product
specifications for the particular ABB product.

ABB may have one or more patents or pending patent applications protecting the intellectual property in the
ABB products described in this document.

The information in this document is subject to change without notice and should not be construed as a com-
mitment by ABB. ABB assumes no responsibility for any errors that may appear in this document.

Products described or referenced in this document are designed to be connected and to communicate infor-
mation and data through network interfaces, which should be connected to a secure net-work. It is the sole
responsibility of the system/product owner to provide and continuously ensure a secure connection between
the product and the system network and/or any other networks that may be connected.

The system/product owners must establish and maintain appropriate measures, including, but not limited to,
the installation of firewalls, application of authentication measures, encryption of data, installation of antivirus
programs, and so on, to protect these products, the network, its system, and interfaces against security
breaches, unauthorized access, interference, intrusion, leakage, and/or theft of data or information.

ABB performs functionality testing on the products and updates that we release. However, system/product
owners are ultimately responsible for ensuring that any product updates or other major system updates (to
include but not limited to code changes, configuration file changes, third-party software updates or patches,
hardware change out, and so on) are compatible with the security measures implemented. The system/ prod-
uct owners must verify that the system and associated products function as expected in the environment in
which they are deployed.

In no event shall ABB be liable for direct, indirect, special, incidental or consequential damages of any nature or
kind arising from the use of this document, nor shall ABB be liable for incidental or consequential damages
arising from use of any software or hardware described in this document.

This document and parts thereof must not be reproduced or copied without written permission from ABB, and
the contents thereof must not be imparted to a third party nor used for any unauthorized purpose.

The software or hardware described in this document is furnished under a license and may be used, copied, or
disclosed only in accordance with the terms of such license.

This product meets the requirements specified in EMC Directive 2014/30/EU and in Low Voltage Directive
2014/35/EU.

The crossed–out wheeled bin symbol on the product and accompanying documents means that used
electrical and electronic equipment (WEEE) should not be mixed with general household waste. If you
wish to discard electrical and electronic equipment (EEE), please contact your dealer or supplier for
further information.

Disposing of this product correctly will help save valuable resources and prevent any potential negative effects
on human health and the environment, which could otherwise arise from inappropriate waste handling.

Trademarks and copyright

Symphony and Symphony Plus are registered or pending trademarks of ABB S.p.A.

Ability is a trademark of ABB.

All rights to copyrights, registered trademarks, and trademarks reside with their respective owners.

Copyright © 2011-2018 ABB. All rights reserved.

Release: November 2018

Document Number: 8VZZ001359T3110

Revision: A
TA BLE O F CO NT ENTS

Table of Contents
1 INTRODUCTION ........................................................................................................................... 1
1.1 Overview ........................................................................................................................................ 1
1.2 Executive Summary ..................................................................................................................... 2
1.3 Revision Record ............................................................................................................................3
1.4 Compatibility ................................................................................................................................3
1.5 Requirements............................................................................................................................... 4
1.5.1 General thoughts on hardware requirements .................................................... 4
1.5.2 Summary Table ...........................................................................................................5
1.5.3 Software Requirements Details ..............................................................................5
1.5.4 Hardware Serverless Configuration ...................................................................... 6
1.5.5 Hardware Server based Configurations .............................................................. 6
1.5.6 Hardware Clients ........................................................................................................ 7

2 DATA SHEET ................................................................................................................................ 8

2.1 Serverless architecture .............................................................................................................. 8
2.2 Server based architecture ......................................................................................................... 8
2.3 Features: Sizes ............................................................................................................................. 8
2.4 Features: Details ........................................................................................................................18

3 Virtualization ............................................................................................................................ 24
3.1 Symphony Plus Servers............................................................................................................ 24
3.2 Redundancy architecture ........................................................................................................ 26
3.3 Network connectivity ................................................................................................................27
3.4 Equipment Lifecycle ..................................................................................................................27
3.5 Equipment Maintenance ......................................................................................................... 28
3.6 Cybersecurity ............................................................................................................................. 28
3.7 Virtual System Architectures – Matching Physical Machines Resources...................... 29
3.8 Virtual System Architectures – Resource Pooling Architecture ....................................... 31
3.9 Summary and Conclusion ....................................................................................................... 35

4 MODIFICATIONS IN THIS RELEASE ..........................................................................................36

4.1 Improvements ........................................................................................................................... 36
4.2 Fixed Problems ...........................................................................................................................37
4.3 Discontinued and Replaced Functions................................................................................. 39
4.4 Known Problems and Workarounds ..................................................................................... 40

5 INSTALLATION .......................................................................................................................... 42
5.1 Installation .................................................................................................................................. 42
5.2 Upgrading................................................................................................................................... 42
5.3 Backup and Restore.................................................................................................................. 42

I
I NTR OD UCT IO N OV ERV I EW

1 INTRODUCTION
This document represents the release notes for S+ Operations 3.1 Service Pack 1. This docu-
ment provides a brief overview on functionality. The document contains additional notes that
may be valuable to customers and service personnel working with the product.

1.1 Overview
Operator effectiveness is fundamental to a plant’s performance. However, with fewer plant
operators, a generational shift in the operator workforce, and increasing complexity of plant
operations, this is becoming ever more challenging, but not insurmountable. Symphony Plus,
with its intuitive, easy-to-use human machine interface (HMI), leads operators to greater
awareness, faster response and better decisions. S+ Operations is designed for high perfor-
mance in every aspect involved: human machine interface, integrated operations, seamless
life cycle management, information management, alarm management, security, process opti-
mization, and flexible, scalable fault tolerant design.

Figure 1-1: Power Explorer Overview

Designed for high performance

S+ Operations provides operators with distraction free, state-of-the-Art, process information
and access.

Integrated operations
S+ Operations seamlessly integrates all plant devices and systems.

Seamless life cycle management

S+ Operations allows for seamless and incremental integration of new products, technology
and functionality without the time and expense of re-engineering and retraining.

Information management
S+ Operations transforms data into meaningful information and presents it in intuitive user
specific desktop displays.

8V ZZ00 1359 T3110 A 1

EX ECUTIV E S UMMA RY I NTR OD UCT IO N

Alarm management
S+ Operations superior integrated alarm management system includes the industry’s leading
EEMUA191 – compliant alarm management analysis system.

Security
S+ Operations provides users with a secure and reliable operations environment with its
built-in security features.

Process optimization
S+ Operations combined with OPTIMAX® Plant Performance Package improves over all plant
productivity.

Flexible, Scalable, fault tolerant design

S+ Operations unique system architecture easily adapts to any power and water applications.

1.2 Executive Summary

S+ Operations is the Symphony Plus Human Machine Interface for the supervision and opera-
tion of Symphony Harmony and SD-Series based control systems. The easy-to-use HMI drives
improvement in overall operator effectiveness by leading operators to greater awareness,
faster response and ultimately better-informed decisions.

This release also includes many new usability improvements and bug fixes. A complete list of
improvements can be found in this release notes.

This release reintroduces Water Leakage management integration ability with Takadu.

The datasheet found in this document give an outline of the system capabilities of S+ Opera-
tions. Review carefully and discuss any deviation to it with your ABB product support.

Note: This release is intended for usage with SD Series, HR Series or older Harmony Rack. It
also supports native drivers as used in SCADA applications. System with Symphony Melody
or Procontrol cannot use this release. The support of these control systems will be
announced separately when available.

2 8V ZZ00 1359 T3110 A

I NTR OD UCT IO N R EVI SI ON R ECOR D

1.3 Revision Record

Rev. No. Description Date

A First version is published for November 2018

S+ Operations 3.1 Service
Pack 1 release

Table 1-1 Revision Record

1.4 Compatibility
The compatibility related information with respect to S+ Operations software are as follows:

– This release is compatible only with S+ Engineering 2.1.x. To engineer/configure S+ Opera-

tions 3.1, it is a must to have S+ Engineering 2.1.x.

8V ZZ00 1359 T3110 A 3

R EQ UIR EM ENTS I NTR OD UCT IO N

1.5 Requirements
1.5.1 General thoughts on hardware requirements
The hardware requirements for S+ Operations are dependent on the following factors:

– 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.

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 with-
out the need for exchanging hardware components. Lower performance hardware may pro-
vide adequate results, but this hardware has not been tested and it does not ensure perfor-
mance provisions for the future.

Hard disk requirements:

RAID system (RAID 1: mirroring) can improve the computers reliability. RAID disks can also
slow down the computer’s performance, if no hardware RAID controller is used. It is recom-
mended to use dedicated hardware RAID controllers. When using RAID 5, performance im-
provements are seen only if a high number of disks are used (at least 8 discs are required).

History server:
For the History Server in large applications and in those demanding high historian perfor-
mance, it is required to use separate disks for programs, separate disks for the alarm/event
database and separate disks for real-time value database. In case a RAID is used this means 3
independent RAID 1 with at least 6 disks in total or a RAID 5 with at least 8 disks. For high
speed historians SSD disks shall be used. Further performance improvements can be archived
using separate RAID 10 for each of the databases.

Fast display call-up times:

If fast display call-up times are expected than it is essential to use high performance opera-
tions networks (at a minimum 1 Gbit) and high CPU cycle time (> 3 GHz) for operator PCs and
servers. Follow CPU recommendation for the release of the product were tested for high per-
formance. SSD disks also for clients will speed up the performance on startup and also call-
up times.

CPU recommendation for fast call-up time use:

- For operator workstations or Serverless:

e.g. Intel Core Intel Xeon E3-1225 v5, 3.3Ghz or Intel® Xeon® Gold 5122, 3.6GHz

- For large servers:

e.g. Intel® Xeon® Gold 5118, 2.3GHz

4 8V ZZ00 1359 T3110 A

I NTR OD UCT IO N R EQ UIR EM ENTS

1.5.2 Summary Table

HSI Server History Serverless Operator Full Office Application

Server Client Client Client Server

CPU Small: Intel® Small: Intel® Intel® Xeon® Intel® I3 proces- Small: Intel®
Xeon® E3- Xeon® E3- Silver 4112, Xeon® sor Xeon® E3-
1270 v6, 1270 v6, 2.6GHz or Silver 4112, 1270 v6,
3.8GHz 3.8GHz, In- Intel Xeon 2.6GHz or 3.8GHz, Intel®
Large: In- tel® Xeon® E3-1225 v5, Intel Xeon Xeon® Silver
tel® Xeon® Silver 4114 3.3Ghz E3-1225 v5, 4114 2.2GHz
Silver 4114 2.2GHz or 3.3Ghz or Intel®
2.2GHz or Intel® Xeon® Xeon® Gold
Intel® Gold 5118, 5118, 2.3GHz
Xeon® Gold 2.3GHz
5118,
2.3GHz

RAM Small: 8 GB Small: 8 GB Small: 8 GB 8 GB 8 GB 8 GB

Large: 16 Large: 16 GB Large: 16 GB
GB

OS Windows 10 Windows 10 Windows 10 Windows Windows Windows 10

LTSC 2016: LTSC 2016: LTSCB 2016 10 LTSB 10 LTSC LTSC 2016
up to 5 up to 5 users Windows 2016 2016 Windows
computers Windows Server 2016 Windows Windows Server 2016
Windows Server 2016 Server Server
Server 2016 2016 2016

Hard As required Min. 3x 100 As required As re- As re- As required

disk by applica- GB, by applica- quired by quired by by applica-
tions As required tions applica- applica- tions
by capacity tions tions

Video Recommen- Recommen- Recommen- Recom- Recom- Recommen-

dation dation dation mendation mendation dation
1920x1200 1920x1200 or 1920x1200 or 1920x1200 1920x1200 1920x1200 or
or 1920x1080 1920x1080 or or 1920x1080
1920x1080 per screen per screen 1920x1080 1920x1080 per screen
per screen per screen per screen

Table 1-2 Hardware requirement summary table

1.5.3 Software Requirements Details

S+ Operations 3.1 Service Pack 1 supports the following operating systems:

– Windows 10 Enterprise LTSC 2016, English

– Windows Server 2016 Standard Edition, English

3rd party software as the following:

– Microsoft Office 2016, 2013 SP1 Standard or Professional 32 bit

– Microsoft SQL Server 2016 Standard Edition

– Microsoft Internet Explorer 11

8V ZZ00 1359 T3110 A 5

R EQ UIR EM ENTS I NTR OD UCT IO N

All referenced operating systems, Office, Internet Explorer and SQL Server should always in-
clude the latest security patches and service packs as well as antivirus qualified by ABB. Refer
to Field Alert document “2VAA001442 Security Updates Validation Status for Symphony Plus”
for the latest information on approved security patches and antivirus definitions. This docu-
ment is accessible in ABB Solutions Bank for registered users with valid Sentinel subscription.

Note:
On Windows 10 LTSB 2016 client acting as an operations server the maximum number of
supported “Power Explorer” Clients is 5.
To prove that you are eligible to install SQL Server 2016, make sure that you have received the
order with SQL license stickers. As a proof of legal license, you are supposed to attach them
to all client computers.

1.5.4 Hardware Serverless Configuration

1.5.4.1 Small (<1000 tags) Workstations

Workstations should have at least 4 real cores, be either a Xeon processor v5 or later with at
least 3.5 GHz. At least 8 GB RAM. Hard disks size as required for application size and history
length1.

1.5.4.2 Large Workstations

Workstations should be using Xeon Silver processors with at least 2.6 GHz. At least 8-16 GB
RAM as required by number of tags. Hard disks as required for application size and history
length1.

1.5.5 Hardware Server based Configurations

1.5.5.1 Small system servers <1000 tags

Servers with Intel Xeon v6 or later with at least 2.3. At least 8 GB RAM. Hard disks as required
for application size and history length1.

1.5.5.2 Large systems servers with or without separated history

Servers should be a Xeon Silver or Gold processor with at least 2.3 Ghz and 16 GB RAM. Hard
disks as required for application size1. In case of integrated history more hard disks are re-
quired. Refer to section Volume estimation of hard disks for History Server. But typically, such
a server needs 1 system disk and 2 separate physical (not just partitions) hard disks for his-
torical data storage. In case of RAID configuration disks are typically doubled.

1.5.5.3 History server if separated

Servers or workstations should be either a Xeon v6 processor with at least 2.4 Ghz or Xeon
Silver or Gold processors with at least 2.2 Ghz. For large Alarm/Event databases 16 GB RAM is
recommended. Hard disks as required for application size and history length 1.

For maximum performance systems should have separated disks for programs, separate
event history and separate real time values (3 separate hard disks, not only partitions).

1
See the section on Volume estimation of hard disks for History Server

6 8V ZZ00 1359 T3110 A

I NTR OD UCT IO N R EQ UIR EM ENTS

If a high volume of clients (office and PowerExplorer clients) or a high demand of history
functions is expected, then the performance can be improved by:

– Processors with faster cycle times

– Usage of solid state disks

Solid state disks usage: optimize on those with a high reliability and throughput (read/write).

In case a high number of alarms and events must be recorded (100k/day), it is recommended
that the event database is stored on SSD disks.

RAID usage:
RAID 1 (or RAID 10) can be applied by doubling the number of hard disks (so min. 6 disks for
high performance historian server or RAID 10 then 12 disks). RAID 5 must use a high number
of disks to be effective in terms of performance and reliability (at least >8 disks).

1.5.5.4 Volume estimation of hard disks for History Server

Real-time 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+ Operations Historian consumes approximately 1.2 GB of storage
space for every 1 million events. A typical power station with 10,000 alarm & events/ day con-
sumes about 4.4 GB of disk space per year.

1.5.5.5 Application Server

Servers should be a Xeon E3 v6 with 3.6 Ghz, or Xeon Silver or Gold processor with at least 2.3
Ghz and 8-16 GB RAM. Processor, hard disk and memory type must be determined by applica-
tion size.

1.5.6 Hardware Clients

1.5.6.1 Operator Clients for server-based configurations

Workstations should have at least 4 real cores, be either a Xeon processor v5 or later with at
least 3.5 GHz. At least 8 GB RAM. Hard disks size as required for application size.

For high performance clients optimizing display call-up times, use processors with high cycle
speed such as Intel Core Intel Xeon E3-1225 v5, 3.3 Ghz or Intel® Xeon® Gold 5122, 3.6GHz.

1.5.6.2 Full Office Client

Workstations should be at least I3 processor with a minimum of 8 GB RAM.

8V ZZ00 1359 T3110 A 7

S ERV ER LESS AR CHI TECT URE DATA SH EET

2 DATA SHEET

2.1 Serverless architecture

Serverless clients are always stand-alone. No interaction may occur between clients for HSI
server functions.

However, history functions can be configured to be on a single/redundant History server

only.

Controller Limitation Serverless on Client OS

Harmony 10 k Harmony Tags

AC800M 12 Controllers

Table 2-1 Serverless architecture

For Serverless on Server OS, limits of Server based architecture apply.

2.2 Server based architecture

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

Controller Limitation Server based

Harmony 100 k Harmony Tags.

AC800M 12 Controllers

Table 2-2 Server based architecture

2.3 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 or memory.

All facts below are as recommended, tested and rationalized during standard test proce-
dures. Exceeding requirements are sometime possible and shall be discussed with product
sales.

Category Parameter or Min. Default Max.

Feature

Architecture Recommended
and tested con-
figurations

8 8V ZZ00 1359 T3110 A

DATA SH EET F EATUR ES: S I ZES

Redundancy RT Server 1 1oo2 1oo4

level

History Server 0 1 1oo2

Web Server 0 1 Parallel

Application 0 1 2
Server

Front-end Server 0 1 1oo3

Composite Ar- 0 1 1oo2

chitecture

Hierarchical ar- 0 1 1oo2

chitecture

Composite

Clusters 1 2 4

Data exchange 300 1000 2000

exceptions/s

Hierarchical

Clusters 1 2 4

Data exchange 300 1000 2000

exceptions/s
continuously

Table 2-3 : Sizes: Category Architecture

Category Parameter or Feature Min. Default Max.

Hardware

Clients Number of operations clients 1 32

per server (Power Explorer cli-
ents)

Servers Number of Servers in one Sys- 1 256

tem

Table 2-4 : Sizes: Category Hardware

8V ZZ00 1359 T3110 A 9

F EATUR ES: S I ZES DATA SH EET

Category Parameter or Feature Min. Default Max.

Database

Tags Number of Analog Tags 100 5,000 256,000

Number of Digital Tags 100 5,000 256,000

Number of Database Tags 200 10,000 512,000

Number of Characters in Tag 0 20 In SPO – 50. In

Name Composer Har-
mony – 32.

Number of Atoms per Tag 1 N/A 50

Number of Atoms per Server 0 N/A 1,000,000

Eng. Units Number of Descriptors 0 128 512

Alarm Com- Number of Comments 0 100 1,024

ments

Table 2-5 : Sizes: Category Database

Category Parameter or Feature Min. Default Max.

Alarm Handling

Tags Number of Handled Alarms N/A N/A 512,000

No. of Analog Alarm Levels N/A 8 8

No. of Rate of Change Levels N/A 2 2

No. of Deviation Levels N/A 2 2

Groups Number of Alarm Groups 0 1024 1024

Priorities Number of Alarm Priorities 0 16 31

Number of Alarm Colors 0 8 20

Tones Number of Audible Tones 0 32 1024

Table 2-6 : Sizes: Category Alarm Handling

Category Parameter or Feature Min. Default Max.

Transfer Proper- Property transfer from one tag

ties to another

10 8V ZZ00 1359 T3110 A

DATA SH EET F EATUR ES: S I ZES

Output Transfer No. of Tags to transfer 0 0 50

Tags

Cycle time Cycle time of transfer mecha- 1000ms 2000ms N/A

nism

Table 2-7 : Sizes: Category Transfer Properties

Category Parameter or Feature Min. Default Max.

RT Calculations

Tags No. of Tags per Calc. Block 0 100 2,000

Blocks No. of Calculation Blocks 0 100 10,000

Statements Statement Length N/A 256 256

Table 2-8 : Sizes: Category RT Calculations

Category Parameter or Feature Min. Default Max.

S+ Calculations

Calculation Number of Calculation Groups 1 1 10

Groups

Number of Cal- Number of Calculations per 1 1 100

culations each Calculation Group

Number of Number of Variables/Tags per 1 1 1000

Tags/Variables each Calculation

Table 2-9 : Sizes: Category S+ Calculations

Category Parameter or Feature Min. Default Max.

Operator Inter-
face

Displays Number of Displays N/A N/A 2500

Windows Number of Power Explorer per 1 1 4

Client

No. of Menu Items in the main N/A 50 100

toolbar of Power Explorer

No. of Items in the Alarm List N/A 100 280

toolbar

8V ZZ00 1359 T3110 A 11

F EATUR ES: S I ZES DATA SH EET

No. of Items in the Display N/A 5 20

Mimic toolbar

No. of Items in tree View (Fly N/A 100 2500

out Menus)

No. of simultaneous faceplates N/A 8 32

Workplaces Number of different workplaces 1 50 256

Table 2-10 : Sizes: Category Operator Interface

Category Parameter or Feature Min. Default Max.

Pocket Portal

Number of Pocket Portal clients 0 40

per Server
Number of Pocket Portal Server 1 2

Process Number of SVG Elements per

Graphics Display:
Internet Explorer 1000
Chrome 2000

Trends Trends lines per Display 20

Alarm List Number of Alarm per Display 1 N/A 100

Page

Event List Number of Events per Display 1 N/A 100

Page

GIS View Number of GIS elements 1 N/A 100000

Dashboard Number of Dashboard elements 1 N/A 50

per Display Page

Signal List Number of Signals per Display 1 N/A 100

Page

Web Browser Number of Pages 1 N/A 50

Table 2-11 : Sizes: Category Pocket Portal

Category Parameter or Feature Min. Default Max.

Security

Users Number of Individual Users As defined in Windows

User Name Number of Characters As defined in Windows

Password Number of Characters As defined in Windows

12 8V ZZ00 1359 T3110 A

DATA SH EET F EATUR ES: S I ZES

Security Level Number of Security Levels N/A N/A 16

Security Groups Number of Security Groups N/A N/A 32

Table 2-12 : Sizes: Category Security

Category Parameter or Feature Min. Default Max.

Harmony Pro-
cess Events

SOE with SEM Number of SOE devices 0 0 256/SER

Number of SOE tags 0 0 1500/SEM

Number of SOE reports 0 2 10

SOE with HPC Number of SOE tags 0 0 5000/HPC

Number of SOE devices 0 0 256

Number of Triggers 0 0 3/tag

Number of concurrent SOE re- 0 2 10

ports

Table 2-13 : Sizes: Category Harmony Process Events

Category Parameter or Feature Min. Default Max.

Summaries

Tags Real-time Tag Summaries N/A N/A Unlimited

Tag Operating Parameters N/A N/A Unlimited

Table 2-14 : Sizes: Category Summaries

Category Parameter or Feature Min. Default Max.

Short term Hist.

No. of lifetime days 1 90 90

Number of History Logs 0 N/A Unlimited per

system, 100k
per server

History resolution 1ms 1ms Event based

Data retrieval time 100ms 1s Query based

8V ZZ00 1359 T3110 A 13

F EATUR ES: S I ZES DATA SH EET

Console trends Number of Trends N/A N/A Unlimited

No. of Tags per Trends 1 20 20

No. of Colors for Trend Curves 15 N/A Unlimited

Maintenance Number of Digital totalizers 0 100 1,000

Totalizers Number of Analog totalizers 0 100 1,000

Table 2-15 : Sizes: Category Short Term Hist.

Category Parameter or Feature Min. Default Max.

Long Term Hist.

Process data

Number of History Logs 0 N/A Unlimited per

system, 100k
per server

History resolution 1ms 1ms Event based

Data retrieval time 100ms 1s Query based

Office Trends Number of Trend N/A N/A Disk Size

No. of Tags per Trend 1 20 50

No. of Colors for Trend Curves 1 N/A 256

Report storage Max Days N/A N/A Disk size

Max Number of Files N/A N/A Disk size

Report genera- Max Number of Report sched- 0 50 150

tion uled

Storage rate Continuous exceptions per s 0 1000 1000

Exceptional exceptions per s 0 15.000 15.000

Reading rate Reading rate exception/s 0 5000 30.000

Capacity Disk size usage 10 MB 250 GB 1 TB

Long Term Hist.

Event Data

Storage rate Continuous Events per day 0 100.000 100.000

Exceptional storage rate 0 100.000 2.000.000

Reading rate Reading rate events/s 100 1.000 5.000

Capacity Disk size usage 500 MB 100 GB 400 GB (10 y)

14 8V ZZ00 1359 T3110 A

DATA SH EET F EATUR ES: S I ZES

OPC

OPC HDA
Server

Requests Requests / min n.a 60 100

Record length Data records per request n.a 1000 10.000

Max clients Number of clients per HDA 0 1 10

server

Time range Time range per request 1s 1h 1 month

SQL Transmit-
ter

Cycle time Cycle time 5 min 15 min 1 month

Signals Signals per class 1 Cycle Cycle

time/1000ms time/500ms

Table 2-16 : Sizes: Category Long Term Hist.

Category Parameter or Feature Min. Default Max.

Printing

Printers Number of Printers 0 N/A 10

Table 2-17 : Sizes: Category Printing

Category Parameter or Feature Min. Default Max.

Communication

Drivers Number of parallel drivers per 0 N/A 200

Server

Harmony Driver Number of ICI connections per 0 1 8

Server
Number

Virtual PNI Number of VPNI Connections 0 0 1

per Server
Number of Tags per Server 0 N/A 30000

OPC DA Number of connections 0 0 100

8V ZZ00 1359 T3110 A 15

F EATUR ES: S I ZES DATA SH EET

Modbus TCP Number of devices per Server 0 0 150

Number of servers 0 0 256
Signals per device 0 0 1000
Min Cycle time 200ms 1000ms

Modbus TCP – Number of devices per driver 0 N/A 1000

Multi-device Number of servers 0 0 256
Driver Signals per device 0 0 200
Atoms per Tag 1 1 50
Min Cycle time 200ms 1000ms

Modbus serial Number of devices per connec- 0 0 100

tion 0 0 256
Number of servers 0 0 1000
Signals per device 200ms 1000ms
Min Cycle time

AC500 Number of AC500 / OPC server 0 N/A 30

Number of Servers 0 0 64
Number of OPC items per 0 N/A 10,000
AC500 0 N/A 20,000
Number of OPC items per OPC
Server

IEC 61850 Number of IEDs 0 0 160

Number of connections per 0 0 1
server 1 1 4
Number of subnetwork per 0 0 80
server 0 0 64
Number of IEDs per subnetwork 0 0 150
Number of servers
Changes per second on stack

IEC 104 Number of devices per Server 0 0 150

Number of servers 0 0 256
Signals per device 0 0 1000
Min Cycle time 200ms 1000ms

IEC 104 – Multi- Number of devices per driver 0 N/A 1000

device Driver Number of servers 0 0 256
Signals per device 0 0 200
Atoms per Tag 1 1 50
Min Cycle time 200ms 1000ms

Table 2-18 : Sizes: Category Communication

Category Parameter or Feature Min. Default Max.

Information
Management

Full Clients Number of concurrent clients 0 N/A 50

16 8V ZZ00 1359 T3110 A

DATA SH EET F EATUR ES: S I ZES

Web Clients Number of concurrent web cli- 0 N/A 200

ents

Tag Length Number of Characters 0 N/A 30

Table 2-19 : Sizes: Category Information Management

8V ZZ00 1359 T3110 A 17

F EATUR ES: DETAI LS DATA SH EET

2.4 Features: Details

Category Parameter or Feature Current

Database

General Configuration On-line and Off-line.

Tags Standard Format Excel (XLSX), XML, TEXT

Compatibility to ... Win Tools

Eng. Units Standard Format Composer (conversion to or from MDB

file).

Compatibility to ... Excel (XLS) or CF File.

Alarm Com- Standard Format Win Tools (CF File), Excel (XLSX)
ments

Table 2-20 : Details: Category Database

Category Parameter or Feature Current

Alarm Handling

General Alarm Acknowledgment Global (user restricted), per Individual

Tag,

Alarm Inhibit Per database or individually.

Page Acknowledgement Acknowledges whole alarm page.

Alarm Action Program Automatic per Individual Tag, Manual

per Individual Tag.

Alarm Shelving Manual per Individual Tag.

Alarm out of service Manual per group

Alarm latching Manual per Individual Tag.

Alarm removal Manual per Individual Tag.

Tags Variable Alarm Levels Activation configurable per individual

tag and per alarm condition.

Alarm Dead-band The Alarm Action Program must be

separately implemented.

RTN as New Message Configurable per individual tag.

Remove Alarm Message on Configurable per individual tag.

Acknowledge

Groups Group Tree Configurable.

Default: 16 main groups and 16 sub-
groups for each main group.

18 8V ZZ00 1359 T3110 A

DATA SH EET F EATUR ES : DETAI LS

Nodes Acknowledgment Broadcast Configurable (default NO).

Tones Types of Audible Tones Beep, Wave file (one shot or continu-
ous), Horn (via external activation).

Audible on Alarm Configurable per individual tag.

Audible on RTN Configurable per individual tag.

Alarm Audible Silence Global.

Disable Audible on Configurable (default YES).

Acknowledge

Pages Alarm Display Alarm Page per group and Unacknowl-

edged Alarm Window.

Alarm Filtering Individually by choosing displayed col-

umns

Alarm Summary Summary always on view and One click

to display.

Message Format Font Height and Weight of Configurable.

Message

Multiple customizable alarm Configurable and runtime selectable

views

Alarm Comments on Alarm Configurable (default NO).

Display

Value Updated within Alarm Configurable (default YES).

Display

Milliseconds within Date/Time Configurable (default YES).

Time of Alarm Resolution 1 Millisecond.

Date and Time Configurable.

Standard: dd-mmm-yy or
Alternate: according to Regional Op-
tion settings.

International Date Configurable according to Regional

Table 2-21 : Details: Alarm Handling

Category Parameter or Feature Current

Human Interface

General Language Multi-language supported. Default

English. Other languages e.g. Japanese
supported if translation files are pro-
vided.

8V ZZ00 1359 T3110 A 19

F EATUR ES: DETAI LS DATA SH EET

Displays Graphic Editor Embedded Editor

Import Existing Mimics SLGM (via conversion)

Update Frequency of Dynamics Selectable 1 Sec. or 5 Sec.

Standard Input Format Dbase III/IV (DBF) or Excel (XLSX).

Windows Multi-screen Configurable (default NO).

Drag able Windows Configurable (default NO).

Process Control SP and CO Increment Configurable (default 0.2%).

SP and CO Fast Increment Configurable (default 4%).

Double Click to Select Popup Configurable (default NO).

Table 2-22 : Details: Human Interface

Category Parameter or Feature Current

Security

General Access Windows users.

Technology Windows Single Sign On.

Log In Log In Windows Username and Password.

Username Case sensitivity by Windows policy.

Password Case sensitivity by Windows policy.

Default Log-in User Current Logged In Windows User.

Log-in Display Configurable.

Log Out Log Out Manual on demand or Automatic on

time-out.

Log-out on Time-out Configurable.

Table 2-23 : Details: Security

Category Parameter or Feature Current

Process Events

General Sequence of Events Standard and distributed.

Sequence of Events Resolution 1 Millisecond.

Tags Number of SOE Events Configurable.

20 8V ZZ00 1359 T3110 A

DATA SH EET F EATUR ES: DETAI LS

Duplication of SOE to Digital In- Configurable (default YES).

puts

Logs Multiple SOE Logs Kept individual or merged.

Table 2-24 : Details: Process Events

Category Parameter or Feature Current

Summaries

Tags Real-time Tag Summary Multiple filtering criteria.

Table 2-25 : Details: Summaries

Category Parameter or Feature Current

Online Hist.

General Types of Data Playback

Trends Types of Historical Trends Instantaneous Value, Minimum, Maxi-

mum, Total, Count, Monitor and Ratio.

Trend Displaying Formats Trend or Table.

Trend Time Displaying Real-time or Historical.

Curve Highlight on Trend Bolding of Selected Tag.

Tag Engineering Unit Scale on Default: 0 - 100 % or

Trend E.U. Scale of Selected Tag.

Trend Curve Analysis Pause Real-time trending, Zoom and

Pan Functions, Drag Cursor.

Trend Configuration On-line or Off-line.

Category Parameter or Feature Details

Trend Display Configurability On-line.

Tag Scale, Curve Color and Display

Statistic Data of Trend Curves On Demand.

Average, Minimum and Maximum, Time
of Minimum and Maximum.

Chronol. Alarms Alarm Summary Multiple Filtering Criteria.

Table 2-26 : Details: Online Hist.

8V ZZ00 1359 T3110 A 21

F EATUR ES: DETAI LS DATA SH EET

Category Parameter or Feature Current

Long Term Hist.

General Type of Data Real time analogue and binary data,

Chronological Alarm Messages, reports,
Post Trip logs

Archival Storage On-line hard disk, SSD supported

Automatic Archiving on Time Configurable.

Basis

Manual Archiving Supported.

Media Archive to BD, DVD, CD, Disk, File.

Logs Data Logging Custom Excel Work-sheet.

Category Parameter or Feature Details

SOE Sequence of Events Logging SQL DB, Standard Text File, Custom Ex-
cel Work-sheet

Table 2-27 : Details: Long Term Hist.

Category Parameter or Feature Current

Ext. Interfaces

OPC OPC Interface OPC Server and OPC Client (DA 1.x, 2.0,
AE1.x, HDA 1.x)

WEB WEB server HTTP and HTTPS, Graphics, trends, alarm

& events, reports, signal explorer

Hardware

Hosts Architecture Serverless, Client/Server

Host PC Custom
(Dell and HP suggested).

Clients Client Switch-over to Server Automatic or Manual.

Server List for Clients Configurable.

Category Parameter or Feature Details

Nodes Redundancy Multi-Master Nodes.

Field Field Hardware Symphony Plus, Infi 90

Table 2-28 : Details: Ext. Interfaces

22 8V ZZ00 1359 T3110 A

DATA SH EET F EATUR ES: DETAI LS

Category Parameter or Feature Current

Communication

Standard Supported C-Net, Infinet.

Scanner Suite Capability to Host Drivers for Foreign Protocols.

Suite provided for support.

Embedded Drivers for Modbus Protocol Modbus TCP, OPC

Table 2-29 : Details: Communication

8V ZZ00 1359 T3110 A 23

SYMPH ON Y P LU S S ERV ER S VI RTUA LI ZATI O N

3 Virtualization
When planning to run S+ Operations in a virtual environment, the following sizing of servers
and network components that will provide the underlying foundation to run the application is
required.

– The following dependencies must be considered:

– Number of Symphony Plus Servers to provide the required DCS functions

– Process workload which will consume Symphony Plus resources

– Redundancy architecture

– Network connectivity

– Equipment Lifecycle

– Equipment Maintenance

– Cybersecurity

This section provides information and guidelines for engineers designing a S+ Operations
system in a virtual environment. Due to the dynamic nature of virtualization, evolving tech-
niques for its deployment and the special requirements imposed by a Distributed Control
System that at its core has personnel and equipment safety embedded at the forefront, it is
highly recommended that ABB be engaged early on in any virtualization design.

3.1 Symphony Plus Servers

Although defining the number and functions of Symphony Plus servers within a DCS architec-
ture is beyond the scope of this section, it must be said that their number impacts the design
of the infrastructure that will run the virtual machines.

The number of Symphony Plus servers is typically determined by the functionality required to
monitor and control the process. As such, typically the following servers are used:

– S+ Operations

– S+ Operations Historian

– Symphony Plus Alarm Management

– Symphony Plus Optimization

– Symphony Plus Scanner

– S+ Calculations

– At times, these functions may be combined into a single server, such as:

• S+ Operations Historian and Alarm Management

The benefits are obviously a reduction in the number of physical machine components, at the ex-
pense of increasing its computing resources. Similarly, this also has an impact on the virtualization
architecture, which would run a reduced number of virtual machines, but each defined with an in-
creased set of resources.

When configuring and defining physical machines to run these functions, the capabilities and limita-
tions of the physical sub-systems in a server are taken into account. In a virtual environment, how-
ever, it is the performance of the virtual machine's resources which are used. To properly account
for such, it is advisable to list all the Symphony Plus servers and note their functionality. This will

24 8V ZZ00 1359 T3110 A

VI RTUA LI ZATI O N SYMPH ONY P LU S S ERV ER S

account for the resources required by each of the Operating Systems, plus the resources required
by each of the Symphony Plus servers for their intended function.

Actions:
– Count number of Symphony Plus Servers

– List their functions

– From the appropriate Symphony Plus manual determine what resources are needed if
they are to be satisfied by a physical machine.

From the above, determine:

– Number of Operating Systems to run

– Number of nodes that will be virtualized

– Minimum HW requirements for O/S

– Minimum HW requirements for 3rd party SW|

This is a first approximation since plant characteristics will be determined next.

Process workload which will consume Symphony Plus resources

This refers to determining the degree to which the plant will require resources of the Sym-
phony Plus system. Although determining system sizing is beyond the scope of this manual,
some examples are shown below:

S+ Operations Server:

– Number of tags

– Number of alarms per hour

– Number of Operator Stations

S+ Operations History Server:

– Number of analog cyclical data to be stored

– Number of digital cyclical data to be stored

– Number of alarms and events to be stored

Calculation Engine:

– Number of calculations

– Scanner Servers:

– Number of scanned tags

Operations Workstations:

– Number of monitors

– Types of graphics (High Performance, Gray Scale, etc.)

From this plant characterization, a given set of physical resource requirements will be deter-
mined. These requirements are to be added to the requirements for each of the nodes deter-
mined in step one.

8V ZZ00 1359 T3110 A 25

R EDU NDA N CY A RCH IT ECT UR E VI RTUA LI ZATI O N

From the appropriate Symphony Plus manual, determine what resources are needed, as if
they are to be satisfied by a physical machine.

– Number of CPUs required for each server

– Amount of RAM for each server

– Amount of storage required for each server

– Network speed for each server's Ethernet interface

– Number of network connections for each server

3.2 Redundancy architecture

Almost all DCS systems are designed with redundancy in such a manner that no single point
of failure would render the DCS unavailable.

This means that duplicating the servers is a mandatory requirement.

Duplicating the system in a virtual architecture is akin to duplicating the number of physical
servers, should have the system been designed as a physical system in which all server func-
tions are carried out by individual physical machines. It must be noted that Symphony Plus is
not only a highly available system, but also a real-time redundant system in which a single
failure does not cause loss of data, even in the face of real-time operation.

This design requirement has been thoroughly tested within the redundancy mechanisms of
the Symphony Plus application, in a design that is either entirely physical, or which mimics
the physical deployment. In other words, real-time redundancy via mechanisms other than
those provided by Symphony Plus are not supported, such as vMotion, High Availability or any
other similar technologies.

This does not mean that vMotion, High Availability or other techniques cannot be applied to
further increase the resiliency and availability of the system. It means that these technolo-
gies are to be thought of for different reasons, such as increasing the system availability, eas-
ing maintenance, or other non-real-time requirements.

Based on Symphony Plus documentation, determine what resources are needed to imple-
ment the desired redundancy. Some redundancy schemes are N+1, N+2, etc.

– These determine the number of host servers:

– N+1 = One extra host server

– N+2 = Two extra host servers

– N+N = Double servers needed for operation

26 8V ZZ00 1359 T3110 A

VI RTUA LI ZATI O N NET WORK CONNECTIV IT Y

3.3 Network connectivity

In a physical environment, there are at least two different networks that must be accounted
for: The Operations Network, where clients and servers exchange data for (as an example)
display purposes, and the Control Network, where the servers and controllers exchange data
for receiving field data and sending commands to plant equipment. In a typical design, these
networks are separate and require separate ports. They also require different performance
levels. For instance, the Operations Network requires gigabit speeds, while the control net-
work may satisfy the architecture's needs at 100 mbps speeds.

At other times, other ancillary functions may also be desired, such as Out-Of-Band manage-
ment or Disaster Recovery. These requirements all add to the architecture of a virtual envi-
ronment, just like it does in a physical environment. However, because of the possibility of
aggregation, it is important to define what type of network design will be implemented in
the virtual environment, and tally the traffic expected on each interface. This traffic is also
the result of the plant's characterization, discussed in the previous section.

To properly design the system, it is to be noted that some traffic which in a physical environ-
ment necessarily leaves and enters a network interface, may, in a virtual environment remain
within the host. This improves performance of the system, for some operations. But for
some operations, it places more requirements on the physical network interface, because of
the aggregated traffic. Thus, a tally of what traffic comes into and out of the network inter-
faces is required:

From the appropriate Symphony Plus manual, determine network requirements and tally:

– Expected network interfaces being aggregated

– Number nodes participating in a given interface

This will determine if a single network interface is required, or whether multiple interfaces
need to be aggregated, or even if ports of high speed are needed, such as 10 Gbps, or 40
Gbps, etc.

Finally, although almost all network switches have the required fabric speeds required for
systems of the type typically deployed in a DCS, it is important to make sure the bandwidth
calculated within this section matches up with the specifications of the network switch.

3.4 Equipment Lifecycle

One reason to replace servers is because of failures or obsolescence of its components. This
is most common with mass storage, which is the weakest of all components in a server.
When it comes to storage however, it doesn't need to be replaced just because of failures. At
times, a server's disks need to be replaced not because they have failed, but because they
cannot be upgraded or retrofitted to perform additional functions desired of the system -
such as because more virtual machines are to be deployed or because additional strain is
placed on the DCS.

In a virtual environment, there are several ways to deal with this need. One is to replace com-
ponents with more up-to-date specifications. This method, however, may require that the
virtual system be taken offline. To avoid such, another avenue is available: to have additional
resources added to the system. This is possible because in a virtual environment, the modifi-
cation of the host does not mean that any of the virtual machines is modified. In this case,
they are simply given more resources. It is the underlying hypervisor's function and ability to
treat its resources as components that can easily be added.

8V ZZ00 1359 T3110 A 27

EQ UIP M ENT MA I NT ENA N C E VI RTUA LI ZATI O N

However, resources cannot be added to a host, unless the host is prepared to receive them.
Thus, the virtual machine host must be sized properly for the desired lifecycle.

Identify long term plant requirements and determine what additional features will be re-
quired throughout the life expectancy of the system. Then determine storage, network and
memory requirements as per the sections above

Tally these requirements and add them as required resources that the Virtual Machine host
will be required to support in the future.

– Processors

– Memory

– Storage

– Network bandwidth requirements

3.5 Equipment Maintenance

All systems require maintenance, whether to replace failed hardware, to move onto upgraded
equipment, or for expansion or added functionality. During these periods of maintenance,
the system must be powered down. Most of the time, during which the hardware is main-
tained, the underlying application remains the same. Virtualization allows for easier mainte-
nance of the system, by moving the virtual machines from one server to another. More gener-
ically, it can be said that the virtual machines can be moved from one resource to another,
such as from one storage resource to another.

In this case, one must account for the required storage to relocate the virtual machines.

From each application's specifications, determine the amount of storage required and tally
it. These requirements include:

– Operating System requirements for installation

– Operating System requirements for operation

– Symphony Plus Application requirements for installation

– Symphony Plus Application requirements for operation

– Third Party Application requirements for installation

– Third Party Application requirements for operation

– Symphony Plus Data Storage requirements

3.6 Cybersecurity
In particular, this section refers to Disaster Recovery. ABB's standard Disaster Recovery appli-
cation is Rapid Recovery, which creates on-line periodic backups of all nodes. This recurrent
and permanent on-line backup method relies on a reliable and agile network, which is best
served by a separate network infrastructure specifically for Disaster Recovery. Determining
the amount of data to be backed up is very complex because Disaster Recovery software pro-
vides two algorithms to reduce the amount of data being stored in their backup repositories:

28 8V ZZ00 1359 T3110 A

VI RTUA LI ZATI O N VI RTUA L SYSTEM ARCH I T ECTUR ES – MATCHI NG PH YSICA L MA CHI NES R ES OUR CES

Compression
Performs compression on the data being stored, by removing most redundant data and in-
stead adding error correction and data protection.

De-duplication:
Avoids having to store multiple copies of the same data from different nodes on the system.

Because of these two mechanisms, computing the amount of data to be stored is extremely
complex. At times, compression and de-duplication can achieve compression ratios close to
90% and so it is best to follow the recommendations for storage of the Disaster Recovery ap-
plication separately.

However, the main requirement for Disaster Recovery is to have a resilient and agile network,
with plenty of bandwidth to quickly supply data to the Disaster Recovery backup server. It is
this requirement which (for optimal operation) mandates the use of a separate network with
enough bandwidth to transfer data quickly. It is best to have at least a 1 Gbps network di-
rectly from the virtual machine hosts to the Disaster Recovery server.

From the previous section, determine the approximate amount of storage required and ag-
gregate it.

Affect the total storage requirement by a factor of 50%. This conservative figure is the
amount of data that will be stored in the Disaster Recovery server repository.

However, only a fraction of this data will be sent over to the Disaster Recovery server. That
is because the Disaster Recovery agent only sends the data that has changed and not every
disk sector or bit. It is this value which will determine network bandwidth requirement.

A conservative figure of 10% of the 50% is recommended.

3.7 Virtual System Architectures – Matching Physical

Machines Resources
From the above it can be seen that the starting point for designing a virtualized system are
the requirements for deploying a physical system.

A possible architecture then is to design and apply resources based on the requirements laid
out for a physical infrastructure.

8V ZZ00 1359 T3110 A 29

VI RTUA L SYSTEM ARCH I T ECTUR ES – MATCHI NG PH YSICA L MA CHI NES R ES OUR CES VI RTUA LI ZATI O N

Figure 3-1 A single host-based architecture

The hardware resources (shown within the orange box) are identified and managed by the
Hypervisor. The configuration of each Virtual Machine (shown as vertical stacks of resources)
mimics what would be an otherwise physical system, with actual disk resources defined
within the software as individual RAID containers, each assigned to a given virtual machine.

This approach, has the following benefits:

– The same principles and calculations applied to select hardware for physical machines can
be used to design the virtual machines,

– Simple to configure the virtual host, because its specifications are the sum of the specifi-
cations of each individual physical server or workstation,

– Provides ample resources for sudden, unexpected, random and hard to determine work-
loads,

– Because no specialized hardware is used, the system is very cost effective and compact in
size, especially for small virtual deployments,

– It is easy to determine expansion requirements because it follows a physical model, easy

to replicate in a virtual environment, and

– All resources are contained in the same host, making it simple to deploy.

However, this approach, also has some drawbacks:

– Hypervisor efficiencies, are not considered and as a result, the system becomes over-de-
signed,

– The hosting server’s physical limits become a limiting factor in system growth,

– The hosting server’s physical limitations also impose an upper limit on the size of the vir-
tual infrastructure,

– The advantages of overprovisioning cannot be realized, and

– The advantages of more specialized disk technologies, with higher efficiencies, reliability
and resiliency cannot be realized.

30 8V ZZ00 1359 T3110 A

VI RTUA LI ZATI O N VI RTUA L SYSTEM ARCH I T ECTUR ES – R ES OUR CE PO O LI NG AR C HIT ECT UR E

3.8 Virtual System Architectures – Resource Pooling

Architecture
A different alternative is to design the virtual machine host server to provide the needed re-
sources, regardless of what requirements or what architecture a purely physical design would
have required.

In this approach, the virtual machine host is considered as a pool of resources, which will be
made available to each of the virtual machines. These resources are then consumed as the
virtual machines run, and as each virtual machine workload varies over time. Furthermore,
this architecture does not need to follow any design technique, which in an individual physi-
cal server would be considered.

Pooling resources requires then having information on the capabilities, not of each compo-
nent that makes up a sub-system, but rather of the sub-system. This approach has the merit
of using each sub-system’s state of the art performance and capabilities to the fullest.

It also allows taking full advantage of the highly specialized capabilities of the hypervisor op-
erating system, such as overprovisioning of the system, as will be described later.

The following sub-systems are considered:

– CPUs: Processing power is pooled on the host and assigned to each virtual machine on an
as-needed basis. This sub-system is highly linear in nature and requires simply adding up
all available cores to determine available capability. As cores are utilized, they are sub-
tracted from the pool.

– Memory: Amount of DRAM and bandwidth is pooled on the host and, similarly to what
happens with the CPUs, it is assigned to each virtual machine as needed. This is a linear
resource which means that total memory on the host determines maximum capability of
the system, and as it is consumed it is subtracted from the pool.

– Disks: This sub-system is significantly more complex than CPU and RAM. There are two
main specifications that must be considered: performance and storage.

• Performance: This resource determines the capability of the virtual machine to per-
form. It is the main factor that determines what workload each application can sus-
tain.

To understand the required disk performance, a complete understanding of each applica-

tions needs is required. This requires understanding the boundaries of the workload that will
be imposed on each application and the desired or needed response times users expect to
experience.

Disk performance is specified by IOPS and Mbps figures, with each of these figures being ad-
ditive to determine maximum system capabilities.

As IOPS and Mbps resources are utilized, they are subtracted from the pool.

The difficulty with this resource is not how much is available (because that is calculated by
simple addition), but how much of it is used, how it varies over time and how much is re-
quired to be in reserved for peak conditions.

• Storage: This resource determines amount of data that can be held and number of ap-
plications that can be installed on the virtual machines. It does not determine how well
the system operates.

Total storage capacity is simply the sum of all available disks and becomes the pools
total available resource. As storage is consumed by applications storing data or appli-
cations being installed, capacity is subtracted from the pool.

8V ZZ00 1359 T3110 A 31

VI RTUA L SYSTEM ARCH I T ECTUR ES – R ES OUR CE PO O LI NG AR C HIT ECT UR E VI RTUA LI ZATI O N

There is some degree of randomness and non-determinism in required storage capac-

ity, stemming from storage used by the Operating System and applications during op-
eration – such as for memory paging, caching or other such dynamic techniques. How-
ever, this is minimal compared to actual storage requirements for data and
applications and can be easily accounted for.

The disk sub-system now, can be design in such a manner as to not require any specific type
of configuration, so long as it provides the level of performance needed by the applications.
The following techniques can be used to design the disk sub-system (list is not exclusive nor
exhaustive):

– On server storage (also called “Direct Attached Storage”, or DAS)

– Off server storage

• Storage Area Network

– iSCSI
– Fiber Channel

• Network Attached Storage

It is important to note that in all cases, virtual machines are neither aware nor require to be
constrained by a design. All that is required is that the performance and storage require-
ments be satisfied by the disk sub-system.

– Network: Because of the nature of Ethernet this is one resource that is not additive. Hav-
ing additional Network Interface Cards (NICs) does not provide additive receive or trans-
mit bandwidth. But neither is the need for this resource additive either.

Because in the virtual host all virtual machines are (or can be) “connected” via the hypervi-
sor’s virtual switch, what in a physical environment is traffic into and out of the server, be-
comes data exchanged internal in the virtual machine host – data which never leaves the
boundaries of the hosting server. The more virtual machines running in the virtual machine
host, the less traffic must traverse the physical NIC.

This does not mean there isn’t traffic into or out of the virtual machine host. Such traffic is
(or may be) traffic to thin clients, operator workstations, redundant servers or any other ma-
chine which consumes or provides data to virtual machines running in the host. It is this traf-
fic which must be accounted for when considering how much will traverse the NIC.

Latency of the network can be minimized by increasing the number of NICs, by providing mul-
tiple paths for different virtual machines to have greater access to network resources outside
of the physical host. Other network techniques such as Link Aggregation can also be used,
which will provide greater resources to the pool.

The dynamic and random nature of the utilization of Ethernet network resources means
these resources are not linear. However, techniques similar to those used for physical net-
work systems can be used to determine required network resources available to the host
pool, to be made available to virtual machines within the host.

– Power Supplies: Power supply capacity and power consumption of the system is linear,
which means the resource is additive and the consumption of each virtual machine can
simply be subtracted from the pool. However, predicting the exact power consumption of
the system is extremely complex.

Because this is not a sub-system than can be easily modeled, it is best to consult with the
manufacturer of the physical host, to determine power supply requirements.

This approach, has the following benefits:

32 8V ZZ00 1359 T3110 A

VI RTUA LI ZATI O N VI RTUA L SYSTEM ARCH I T ECTUR ES – R ES OUR CE PO O LI NG AR CHIT ECT UR E

– The virtual machine host architecture can be designed independently of the architecture
of each virtual machine, without regard for the requirements of early physical systems,

– Because of this independence, each virtual machine host sub-system can take full ad-
vantage of state of the art techniques for making resources available to the virtual ma-
chines,

– Without the constraints of a design philosophy, hypervisor efficiencies are fully realized,
such as the overprovisioning of any resource within its pool. This is especially useful for
improved memory, CPU and disk resource utilization,

– The hosting server’s physical limits do not limit system growth.

However, this approach, also has some drawbacks:

– Designing the virtual machine host becomes more complex. This also translates to an in-
creased learning curve for maintenance,

– Care must be exercised to no overprovision the system to the point where it is not capable
of addressing sudden, increased peak workloads,

– Over the life of the system, operating and maintenance expenses are significantly lower,
but, in the short term, capital expenses may be higher.

One possible architecture showing DAS:

Figure 3-2 Resource pooling architecture

The above architecture shows a couple of servers where all resources are local to the server.

8V ZZ00 1359 T3110 A 33

VI RTUA L SYSTEM ARCH I T ECTUR ES – R ES OUR CE PO O LI NG AR C HIT ECT UR E VI RTUA LI ZATI O N

However, a different architecture is also possible, where the disk resources are located out-
side of the servers, as a shared sub-system.

This is shown below:

Figure 3-3 A single host-based architecture, external storage

34 8V ZZ00 1359 T3110 A

VI RTUA LI ZATI O N S UMMA RY A ND CO NCLUS I ON

The above architecture shows the conceptual layout of a virtual system utilizing off-server
shared storage. The shared storage may be designed as a completely independent sub-sys-
tem, with state of the art techniques.

Some of these techniques include:

– Any type of RAID array, designed to meet the requirements of the application and its
workload,

– Any type of off-server storage connection, be it iSCSI, Fiber Channel or Network Attached
Storage (NAS),

– Shared storage built into converged infrastructure servers, or standalone chassis specifi-
cally for hosting disks and disk controllers.

3.9 Summary and Conclusion

Symphony Plus is supported in a virtual environment, where advanced architecture tech-
niques can be used to great benefit in areas of cost reduction, increased lifecycle, improved
maintenance and easy growth.

Although many different virtualization techniques can be used, care must be exercised to re-
tain the real-time capabilities of Symphony Plus without compromised. For this reason, it is
recommended that ABB be engaged early in the development, design and implementation of
any virtualization architecture.

8V ZZ00 1359 T3110 A 35

I MPR OV EM ENTS M OD IF I CATI ONS I N TH I S R ELEAS E

4 MODIFICATIONS IN THIS RELEASE

4.1 Improvements
Following improvements are done compared to previous release.

• Usability improvements

– X-Y plot capability is introduced, there are three patterns supported by X-Y plot
function:
o Single Points, display shows on point
o Multi Points, displays historical data and up to present data by points
o Continuous curves, displays historical data and up to present data by a line

– Capability to calculate moving average of input analog signals (only for Harmony
Connectivity) on real time values
– Digital Signal Trend: Digital value style display which consist of Tag number, de-
scription, process value and engineering unit in tabular format. Frame sizes and
font sizes are stretched according to window size and number of signals.
– Improvements in Event list of Pocket Portal
– Print Preview tool improvements
– Alarm List improvements
– Favorites improvements
– Real time summary improvements
– Trend improvements
– Pop up menu display improvements
– Possibility to configure background color of alarm list, favorites, Real time sum-
mary, trend display, trend summary, Enhanced maintenance tag UI, Pop Up menu,
Window Manager, Operating Parameter, Relational information and Digital Signal
Trend. It is also possible to define theme and apply.
– Remote Operations improvements
– Possibility to define redundancy at Group level for S+ Calculations.

36 8V ZZ00 1359 T3110 A

M OD IF I CATI ON S I N TH I S R ELEAS E F I XED PRO B LEMS

4.2 Fixed Problems

Tracking Title Description
number

Operator action
from a faceplate
20180417- Operator action from a faceplate causes duplicate en-
causes duplicate
497782 tries in the event list
entries in the
event list

Audit trail installa-

190432 Audit trail installation returns error
tion returns error

Menu folder is no Menu folder is no more present in path c:\Pro-

187210
more present gramData\ABB Symphony Plus\Operations\SV3\config

Harmony faceplate
are not usable if Harmony faceplate are not usable if trace verbose is en-
187768
Trace verbose is abled for enabled
enabled

PRCBTN command executed from connectivity server

(where event importer service is not running) are not
recorded into Historian

PRCBTN com-
mands from Con-
Solution:
nectivity server
(where event im- MsgCollector writes only tracking events to the Even-
189929
porter is not run- tImporter file if the following system setting under
ning) are not rec- APPS\HistInterface is set to YES.
orded into
WriteTrackingEventsOnly (REG_SZ)
Historian

In case of above is missing or defined any other values,

every event is written to S+ Operations History

DataExpt does not Data Export faceplate does not report inserted string
137961
report saved string that Is also stored in an atom.

N90STA Tag: Value

mismatch be- N90STA tag value mismatch between “View atom” and
141164
tween “View atom” “RtSumm”
and “RtSumm”

Alarm List: Two

alarm filter op-
Alarm List: Two alarm filter options getting selected
184417 tions getting se-
while user clicks only one
lected while user
clicks only one

8V ZZ00 1359 T3110 A 37

F I XED PRO B LEMS M OD IF I CATI ONS I N TH I S R ELEAS E

Adding new tags into display and navigating to another

page without saving the modified trend display causes
Power Explorer:
loss of changes.
Trend configura-
176790 tions set by user is
not saved during
Solution: A pop-up has been introduced that prompts
page navigation
the user to about action to be taken while trying to nav-
igate.

Power Explore stops responding for a while and Dum-

pHang process launched if user uses “Left arrow” and
“Right arrow” keys.

Workaround:
Power Explorer:
Stops responding In display header configuration, ensure FWD and BCK is
for a while if user not set to NULLPAGE and is set to empty in case of
185040 proper display is not set.
uses “Left arrow”
or “Right arrow”
keys

Workplace launch
Workplace launch with two monitors configured takes
196372 with two monitors
more than 5 minutes
takes time

Global symbol modifications required related display to

be opened and saved manually.

Solution:

New commandline has been introduced as follows that

Global symbol can be executed from Windows RUN prompt,
modifications re-
DisplayBuilder.exe <Name of the Display> /SILENT
192027 quire related dis-
/REFRESHSYMBOL
plays to open and
save manually The above mentioned commandline is automatically
opens the defined displays in a silent way and refreshes
symbol related changes, then completes the Add to
System part.

Note: Ensure displays are properly closed and not

opened in display builder while executing the com-
mandline.

38 8V ZZ00 1359 T3110 A

M OD IF I CATI ON S I N TH I S R ELEAS E D IS CONT INU ED A ND R EP L ACED F U NCT IO NS

Display builder sometimes fails to save file in case

mimic file is in remote shared folder.
Display builder
191686 sometimes fails to
save file Solution:

Attempts to save the file in remote location up to three

times, there after prompts the user to rename the file.

Values Inserted in
a Tag does not Values Inserted in a Tag does not propagate to Non-
191558
propagate to Non- Source Mask Node of Multi Server System
Source Mask Node

PSView does not

support screen PSView does not support screen shot of second moni-
194217
shot of Second tor and takes only primary monitor
Monitor

Color of the Alarm

Indicator in Wel- Color of Alarm Indicator in Welcome_DALL and in Alarm
193524 come DALL and in group button remains in RED regardless of ACTIVE/RTN
Alarm group but- conditions
ton remains in RED

Table 4-1 Fixed Problems

4.3 Discontinued and Replaced Functions

All previous engineering tools like Ibdbase, System Setup etc. are discontinued. Engineering
of S+ Operations is centralized with S+ Engineering workbench.

8V ZZ00 1359 T3110 A 39

K NOWN PRO BLEMS AN D WO RK AR OU ND S M OD IF I CATI ONS I N TH I S R ELEAS E

4.4 Known Problems and Workarounds

Tracking Title Description

number

The string value management in playback is optimized

in S+ operations 3.1 to avoid consumption of huge stor-
String values in
age space.
playback increase
163213
too much the play- Solution:
back size
It is mandatory to delete all the playback database
while upgrading from S+ operations 3.0 version.

License usage re-

port is not getting License status viewer is not reporting usage counts of
135560
updated in License different licensed features.
Status Viewer

Time format shown in the alarm list is displayed in 24

Hrs format, when windows time format configured to
be 12 Hrs.

Time format dis-

played in Alarm list
170244 is different from
Windows time for-
mat

RCM faceplate
177547 doesn’t show over- RCM faceplate doesn’t show override indication
ride indication

Power explorer doesn’t prompt user to save trend modi-

Power Explorer
fications while navigating to other page
doesn’t prompt
179158
user to save trend
modifications Workaround: Always SAVE modification manually be-
fore navigating.

40 8V ZZ00 1359 T3110 A

M OD IF I CATI ON S I N TH I S R ELEAS E K NOWN PRO BLEMS AND WO RK AR OU ND S

Alarm list doesn’t limit the number of alarms to be dis-

played in an alarm list as defined in the balcddeck.xml
file
Alarm List: Page
180740 view doesn’t work
properly Workaround: Add “max_buffered_alarms=3” into Stand-
ard setting

Specifications
tuned using Block
details\Tune Block
application of S+
177021 Operations are not
aligned with S+
Engineering Oper-
ations Engineering
database

Online DB men-
tioned below are
not aligned with
S+ Engineering
Operations Engi-
neering database
 USB
 User Fa-
161945 vorite
 Operator
Note
 Trend
Group
 Custom
DB
 DB Snap-
shot

Table 4-2 Known Issues and Workarounds

8V ZZ00 1359 T3110 A 41

I NSTA LLAT IO N I NSTA LLAT IO N

5 INSTALLATION

5.1 Installation
Follow the detailed instructions mentioned in installation guide

5.2 Upgrading
Follow the detailed instructions mentioned in installation guide

5.3 Backup and Restore

Follow the detailed instructions mentioned in installation guide

42 8V ZZ00 1359 T3110 A

 Revision History

Rev. Page Change Description Date / Initial

- All Initial Release 2018-06-26/

IAPG
—
Visit us

www.abb.com/powergeneration

Document Number: 8VZZ001359T3110 A

www.abb.com/water
www.abb.com/symphonyplus