NTPC SIPAT O&M-C&I

Date: 14.09.2010

Title of the program

DDCMIS Training by ABB under Sipat-II

Station C&I package

Name of the company visited: ABB, China

Date and venue: 19.07.2010 to 30.07.2010,

Beijing

Submitted by: Vijay Porwal

Sr. Engineer C&I(O&M)
NTPC, Sipat
 NTPC SIPAT O&M-C&I

Foreign Training Learning Report Guidelines

A hard and a soft copy of comprehensive report covering following points is to be

submitted to CC- HRD within one month of completion of training. Soft copy may be
mailed at [email protected] or submitted in a CD-ROM.

The following guidelines have to be followed while submitting

the Foreign Training Learning Report : -

1. a) For short duration Programme (upto 2 weeks duration) : Learning

report should cover session wise key learning points, new
concepts/trends, practices etc. including ppt., learning from study
tours, industrial visit etc.
(b) For long/medium duration programme (more than 2 weeks):
Area-wise detailed learning instead of session-wise details is to be
submitted
2. Report should also reflect learning w.r.t. programme objectives and
benefits stated in programme brouchure.
3. Broad coverage of Application of Learning – for self,
section, any other deptt. of NTPC, company level & Adoptable
practices in NTPC.
4. The report should be comprehensive and worth sharing in
Knowledge Management Portal
5. The format enclosed (Annexure-I) needs to be adhered to while
preparing learning report.
6 Learning Report should be sent through HOD
7. HRD will issue clearance certificate to the participant for tour claim
subject to conformity of all the points.

********
 FOREIGN TRAINING LEARNING REPORT

1 Program Details

1.1 Name of the Program DDCMIS Training by ABB under Sipat-II Station C&I
package –(Office order Ref 01:HRD:FT:21.07-
12/20010-11 dated 02.07.2010)

1.2 Duration 19.07.2010 to 30.07.2010

1.3 Country Visited CHINA

1.4 Organiser ABB CHINA

1.5.Name(s) of the ABB CHINA

Industry/
Company visited as part
of Trg.

2 Key Learnings (in detail) 21 pages detailed learning report attached in

annexure.1. In that report session wise key
learning points has been listed. Total training was
divided in 4 modules. All module were covered in
detail. Some practical exposure was given in ABB
workshop. There panel assembling and testing was
shown. Training class room was equipped with
computers in which Composer and PGP was
installed. Hands on experience of installation of
software was given on those system.
3 New Concepts Covered (in
details) 1. MAKING DCS PROJECT FROM SCRATCH: -
during composer module we learned to make new
DCS project from scratch. How to add
controllers, compile the logic and then load them.
2. DIAGRAMS IN PGP: - The diagram is an
element that defines the “graphic type” of a
dynamic object. We learned what the uses of
different diagrammes are. How to use them to
make more operator friendly graphics.
3. HARDWARE SETTINGS: - Dip shunt settings
of different cards like BRC300, IMASI23, NIS &
NPM cards etc. was explained and hands on
 experience was given to configure hardware.
4. DETECTING HARDWARE PROBLEM: - by
seeing status bytes we can detect hardware
problem and can take remedial actins
5. TRENDS IN COMPOSER: - Trends also can be
made in composer. Each block output can be
monitored in composer through trend

4 New Trends/ Practices 1. There can be more than one CNET in a plant.
(in details) These CNET can be connected through INIIT
module. In this case there will be one central
CNET others will act as subring.
2. With the help of IMCPM module EWS/OWS can
be connected to a single node directly. It can not
communicate through CNET.
3. EWS can be connected through serial
communication cable with INICT03. It will
reduce complexity of SCSI cable.
4. Through configuration viewer controller
configuration can be directly changed without
changing in CLD.

5 Application of Learning
5.1 Self DDCMIS Maintenance: - More insights was obtained
in symphony harmony DDCMIS. In ABB workshop
correct connection of prefab cables was shown. It was
also visible that how to dress Prefab cable inside panel
so that cable teeth connects with card in same line.
Replacement of faulty cards, how to configure new
cards, controllers and communication modules was also
learned.

Installation of software: - Installation of new PGP

server and composer in EWS will also be useful in case
any server get failed.

Configuration of trends, reports and graphics: -

Designing of new graphics will help in better
troubleshooting and operation. Configuration of trends
and reports was also taught during the training. More
trends and reports now can be configured in system to
improve analysis of process.
 5.2 Section/ Deptt. More insights gained in hardware problems, PGP
and composer configuration will make
maintenance easier
5.3 Any other Deptt. of Graphics can be made as per operation
NTPC department requirement without using help of
ABB. Trouble shooting will be easier with the help
of trends and reports we can create additionally
5.4 Company Level Expansion of CNET in remote: - Instead of RIO
panels CNET can be extended to remote areas and
offsite also. These CNET in offsites will be
connected to main plant through by making it
subring modules.
Composer can be used with serial cable instead
of SCSI

6 Adoptable practices in
NTPC
6.1 In Deptt. / Section As described in report learning are already being
implemented in the form of modification in graphics for
better operation, troubleshooting and day to day DCS
maintenance activities.

6.2 In any other Deptt./ Hardware failure alarms are given in LVS and through
Section that operation can easily understand gravity of the
situation in case of any card/system failure.
Graphics/Mimics will be modified for better operation
and convenience.

6.3 Company level 1. Different offsites can be connected through DCS

using one central CNET and sub rings in offsites.
2. In spite of using coaxial cable twisted pair CNET can
be used which is easy to handle.

VIJAY PORWAL
Sr. ENGG(O&M-C&I),
Emp no:009322
Enclosure: Detailed learning report in annexure-1
soft copy of training material is enclosed.

Forwarded Through:- DGM (O&M-C&I) Sipat

 Annexure-1
SYMPHONY HARMONY SYSTEM

Part-I
Introduction of symphony harmony system and hardware (19.07.10 to 21.07.10)
Objectives: Course objective was to understand Harmony system overview and
details of Harmony control unit (HCU). During these sessions overview of harmony
control system and details of various components of HCU were explained.

The ABB DCS is an open integrated and distributed system for control and automation.
The Symphony system consists of the following:
• Harmony Control Products – A comprehensive set of process, regulatory and sequence
control services and I/O interfaces
• Composer 4.3 Series system Tools – An integrated set of engineering, operation, and
maintenance tools designed to support the total automation project, including planning,
configuration management, commissioning and system documentation.
• Human System Interfaces – A dynamic range of console products (server client architecture)
for accessing and viewing data from multiple operating environments, from process control
and I/O to plant and information management.

By combining the above components a powerful automation system is integrated that can be
used in applications ranging from small machine control to total, plant-wide automation. Due
to the distributed and flexible structure of the hardware and software DCS system based on
Symphony Harmony series can be expanded in an easy and cost-effective way to meet the
NTPC future needs.

SYSTEM HARDWARE

DDCMIS system offered for the project included following hardware to meet project
requirement:
Harmony Bridge Controller BRC Series
Modular Power Supply
Control Network Interface INNIS21 & INNPM12
I/O Cards IMFEC12, IMASI23, IMASO11, IMDSI22 &
IMDSO14
Remote I/O Interface IMRIO02
Termination Units NTDI01, NTAI05, NTAI06,
NTDO02, NTCF22, NTCF23
Prefab Cables NKTU01, NKAS01,
NKAS11, NKDO01
Communication Network C-Net
Symphony Harmony Rack IEMMU21

All controllers, power-supplies, communications modules and I/O slaves are housed in the
HCU cabinets. These process cabinets have front and rear access doors and can accommodate
eight (8) rows of Module Mounting Unit for process equipment. Each row can accommodate
one Module Mounting Unit, each with twelve (12) slots for modules.
The system and I/Os are powered from modular power supplies. This system is provided with
2N redundant modular power supply capacity.

Modular Power Supply - MPS III (24 VDC Input)

Modular power supply supplies 5 VDC, 15 VDC, -15 VDC & 24 VDC power to Harmony
rack components. Modular power supply modules are single width in size and are designed to
share the load equally. The modular design provides much closer sizing of power supplies to
cabinet loads and minimizes heat dissipation. An important feature is that power modules can
be replaced under live load without causing undue surges and spikes, thus increasing ease of
maintenance.
Modular power supply system consists of power chassis, power trays, power entry panel
(PEP), system fan, and bus monitor.
 Modular Power Supply Architecture Diagram

Termination Unit
A termination unit is a passive device that connects and distributes signals between the I/O
module and field wiring terminals. A termination unit has several purposes:
 Field wiring termination.
 I/O channel signal routing.
 Range and mode selection for analog I/O.
 Voltage threshold selection for digital inputs.
 Field power or system powered I/O selection.
 Circuit protection (i.e., fuses).
 Shield (i.e., chassis ground) connection.
Each type of I/O module requires its own type of termination unit. Termination units used in
system are:
NTCL01: Termination unit for C Net
NTCF22&23: Termination unit for OFC IN C Net
NTST01: Termination unit for Time Sync Link
NTAI06 : Termination unit for IMASI23 & IMDSI22
NTAI05 : Termination unit for IMFEC12
NTDI01 : Termination unit for IMASO11
NTDO02: Termination unit for IMDSO14
NTRL02B: Termination unit for IMRIO02
NTMP01: Termination unit for IMMPI01

Harmony Bridge Controller (BRC300)

The BRC300 is a high performance, high capacity process controller, which is designed to
interface with Harmony rack I/O in the Symphony Enterprise Management and Control
System. The Harmony Rack Bridge Controller (BRC300) is a 32 bit multiple loop, analog,
sequential, batch and advanced control processor. It provides information processing with
advanced data acquisition features and can easily implement complex control strategies. The
processor's set of Function Codes (over 250 standard library functions) handles even the most
comprehensive control strategies.

Features of BRC300
 Provides high availability and fault tolerance in redundant pair configuration.
 Includes two serial channels and a station link for Analog Control Stations (IISAC01)
and Digital Control Stations (NDCS03).
 Information available to any other module in the system via the communication
network.
 Make configuration changes or add points to redundant controllers without
interrupting the process.
 Eight segments that run at different cycle times are available. Assign higher priority
function blocks to segments with very fast scan times. Assign lower priority function
blocks to segments with lower scan times.
  BRC Controller has two on-board RS-232 serial ports. These allow you to interface
the BRC controller to foreign devices such as PLCs.
 BRC controller supports up to 64 slaves in any combination for a wide variety of field
I/O signals without external signal converter.

Basic specification is listed below:

Controlway
The Controlway is a high speed communication bus between Harmony rack controllers. The
BRC module uses this bus to communicate with other control modules within a Harmony
control unit. It provides a one-megabaud, peer-to-peer communication link that can support
up to 32 devices. The Controlway interface is provided by a custom integrated circuit that
links the BRC module to the Controlway. It has full DMA capabilities (allowing for quicker
operation), and two independent, redundant channels. The redundant Controlway channels run
through two paths on the module mounting unit backplane circuit. The BRC module transmits
and receives data over both channels simultaneously. By receiving data through two channels,
the BRC module can check its integrity. In this way, the Controlway minimizes the potential
that a failure on a circuit board or backplane will cause loss of module communication. The
Controlway interface also allows the BRC module to run on module bus by operating in an
83.3-kilobaud mode (switch
selectable).

Redundancy Link
The redundancy link is a dual parallel link between a primary and backup BRC
module in redundant configurations. As the primary module executes, the backup module
waits in standby mode and receives a copy of block outputs over this link. If for any reason
the primary module fails, the backup takes over without any process interruption.
NOTE: Firmware revision levels must be the same in both primary and secondary
BRC modules. If the firmware revision level is different and a failover occurs, the
redundant BRC module may operate erratically. Two parallel channels of data and control
signals connect by way of a processor bus adapter board. Each BRC module in a redundant
configuration connect through PBA boards connected by redundant PBA cables. Both
channels have parity protection.

Control Network
Cnet is a unidirectional, high speed serial data network that operates at a 10-megahertz
or two megahertz communication rate. It supports a central network with up to 250 system
node connections. Multiple satellite networks can link to the central network. Each satellite
network supports up to 250 system node connections. Interfacing a maximum number of
satellite networks gives a system capacity of over 62,000 nodes.

On the central network, a node can be a bridge to a satellite network, a Harmony

control unit, a human system interface, or a computer, each connected through a Cnet
communication interface. On a satellite network, a node can be a bridge to the central
network, a Harmony control unit, a human system interface, or a computer.
 Interfacing Modules INNIS01 & INNPM11
.

Cnet-to-HCU Communication Interface

The Harmony control unit interface consists of the INNIS01 Network Interface
Module and the INNPM12 or INNPM11 Network Processing Module. This interface can be
used for a node on the central network or on a satellite network. Through this interface the
Harmony control unit has access to Cnet and to Controlway at the same time. Controlway is
an internal cabinet communication bus between Harmony rack controllers and the
communication interface modules.
The HCU interface supports hardware redundancy. Redundancy requires a full set of duplicate
modules (two INNIS01 modules and two INNPM12 or INNPM11 modules). The secondary
network processing module (INNPM12 or INNPM11) continuously monitors the primary
through a direct ribbon cable connection. A failover occurs when the secondary detects a
primary module failure. When this happens, the secondary assumes responsibility and the
primary is taken offline.

Cnet-to-Computer Communication Interface

The Cnet-to-computer interfaces are the INICI03 and INICI12 interfaces. The INICI03
interface consists of the INNIS01 Network Interface Module, the INICT03A Computer
Transfer Module, and the IMMPI01 Multifunction Processor Interface Module.
Figure Cnet-to-HCU Interface

Figure Cnet-to-Computer Interface (INICI03)

Network Interface Module

 The INNIS01 Network Interface Module is the front end for all the different Cnet
communication interfaces. It is the intelligent link between a node and Cnet. The INNIS01
module works in conjunction with the transfer modules and the network processing module.
This allows any node to communicate with any other node within the Symphony system.
The INNIS01 module connects to its Cnet communication network through a cable connected
to an NTCL01 termination unit. Communication between nodes is through coaxial or
twinaxial cables that connect to the termination units on each node.

Cnet-to-Computer Transfer Module

The INICT03A Computer Transfer Module and INICT12 Computer Transfer Module
handle all communication with a host computer. These modules are command driven through
software on the host computer. The module receives a command from the host computer,
executes it, then replies. Its firmware enables the host computer to issue commands for data
acquisition, process monitoring, and process control, and to perform system functions such as
security, time synchronization, status monitoring, and module configuration.
The INICT03A module can store up to 30,000 point definitions (depending on point types).
The INICT12 module can store up to 10,000 point definitions. For the INICT03A module, the
circuit board contains microprocessor based communication circuitry that enables it to
directly communicate with its INNIS01 module and to directly communicate with an
IMMPI01 module. It communicates with the IMMPI01 module through a ribbon cable
connection. The IMMPI01 module handles the actual host computer interface and supports
SCSI serial communication. For the INICT12 module, the circuit board contains
microprocessor based communication circuitry that enables it to directly communicate with its
INNIS01 module and to directly communicate with a host computer using RS-232-C serial
communication. The module cable connects to an NTMP01 termination unit. Two RS- 232-C
ports are located on the termination unit. The NTMP01 jumper configuration determines DTE
or DCE operation.

Network Processing Module

The INNPM12 or INNPM11 Network Processing Module acts as a gateway between
Cnet and Controlway. The module holds the Harmony control unit database and handles the
communication between controllers residing on Controlway and the INNIS01 module.
The INNPM12 or INNPM11 module is a single printed circuit board that occupies one slot in
the module mounting unit. The circuit board contains microprocessor based communication
circuitry that enables it to directly communicate with its INNIS01 module and to interface to
Controlway.

Part-II
INTRODUCTION OF FUNCTION CODES (22.07.10)
Objectives: Course objective was to understand function of Harmony control system.
Function Code: Function Code is a control logic language mainly used in Symphony System.
The controllers of Symphony System also support other control logic languages, such as C
Language, Basic Language, Ladder Logic and Batch 90 Language.

Function Code Control Logic Language includes many function codes. A function
code is an algorithm that defines specific functions. For example, some function codes can
perform arithmetic operation; some function codes can perform logic operation; some
function codes can perform control operation; some function codes can perform exception
report; some function codes can perform IO definition, and so on. Each function code has a
number and a description name. Function codes are linked together to form a process control
strategies. Symphony System offers more than 170 function codes.
Function Code Library: Function codes that reside in the ROM of a controller. A controller
of Symphony System has three type of memories: ROM, RAM and NVRAM.

ROM: Operating instructions, self-diagnostic programs and standard function codes reside in
the ROM of a controller. All function codes that reside in the ROM of a controller are called
the Function Code Library of the controller. When you configure a controller, you can only
use the function codes that are supplied in its function code library.

NVRAM: Used to store user’s configuration.

RAM: Configurations run in the RAM of a controller.

The Features of Function Code

 Function code is a kind of block language. It has three elements, i.e. function
code , block address and specification.

 It is very easy to use these function codes to configure control schemes.

 Function code configuration needs to know the hardware environment. It is

closely associated with I/O slave modules.

Part-III (23.07.10 to 27.07.10)

Objectives: Course objective was to understand installation and configuration of
composer

Introduction to Composer:-

The Functions of Composer

The Composer provides a comprehensive set of engineering and maintenance tools for the
Symphony Enterprise Management and Control System. The Composer environment
greatly simplifies the configuration and maintenance of Symphony system.
 Features of Composer
• Integrated suite of configuration tools;
• Reduced engineering time;
• Compatibility with INFI 90 Open system;
• Engineered to operate on the latest platform Windows 2000; Windows XP; Windows
2003;
• Multiple user client/sever architecture;
• Object exchange(enhanced library support);
• Revision control;
• Advanced troubleshooting;
• International language support;
Software Requirements
• Composer software;
• Windows 2000 (Service pack 4), or Windows XP (service pack 2), or Windows 2003
(service pack 1);

 The Window Structure of Composer

1. System Structure Window
The System Architecture window functions similar to Microsoft’s file explorer.
The left pane of the window (Navigator) displays a hierarchical representation of the
Symphony system. When a system object is selected, the right pane displays(Content) a
detailed view for the selected object.
The content side of system window supports two views:
Document view - shows configuration documents associated with the selected system object.
Data browser view - displays tag information associated with the selected system object.

2. Object Exchange
The object exchange (object library) window presents the user with a view of the
reusable components that can be used to create control system configurations. Objects are
organized in folders. Standard system components such as function codes and standard shapes
and symbols are organized under the system folder.
User can define their own folders within object exchange. User-defined objects can include
macro logic, shapes, symbols, standard drawings or control logic template.

3. Output Window
The output window provides a textual feedback of all operations performed in the
Composer application. The contents of the active tab in the output window can be deleted,
printed, or saved by right clicking on the text and selecting Clear Window, Print, or Save.

 The Procedure of Controller Configuration

Define Download Tune

Configure Control Compile
a Project Config. File Configuration
Logic Documents Controller
to Controller

Project: a complete description of the control system. It contains all of the information
necessary for process control and shows the architecture of all of the hardware used
throughout the project. Each project must have its own folder. It is not possible to store two
Composer project in the same folder.

Control Logic Document:

A group of sheets containing control logic (usually with a similar purpose). A controller
configuration frequently contains multiple control logic documents.

Control Logic Template: Preconfigured configuration documents used to simplify

the creation of new control logic document. A control logic template, when dragged into a
controller, becomes a control logic document.

The Procedure of Controller Configuration

1. Open the project containing the controller to be configured.

2. Create a control logic document by:
a. Dragging a control logic template from the exchange onto the controller.
- or -
b. Right clicking the controller and selecting New > Logic Document
from the pop-up menu.
3. Open the control logic document. This opens the Automation Architect window.
4. Configure the sheets of the control logic document using the information
provided in Chapter 6.
5. Repeat steps 2 through 4 for all control logic documents required by the
controller.
6. Return to the Composer window.
7. Compile the controller. This creates a configuration file within Composer.
8. Download the controller (configuration file) to the actual controller.
9. Test and then execute the configuration.

Create a New Project

 Open a New Composer Project
 Create Border Information
 Add a Node to Control Network
o Add a Control Unit
o Add a Console
o Add a HAC
o Add a SEM
 Add a Controller
 Add a Control Logic Document
 Add a Display Group to a Console (for C-VMS)
 Add Lists to Project

Add a Controller
The “Role” of the Controller is extremely important. There are three possible scenarios:

• One Controller - An individual controller or “stand alone” is configured with

 “Primary” as its role. Only one controller is added to the structure.

• Two Controllers - A controller with redundancy but with the same address and not
intended for on-line configuration (such as in a burning process or
in a nuclear plant …) the role would be “Primary/Redundant.” Only one controller is
added to the structure.

• Two Controllers - This would include a Primary controller with a backup controller
which will perform on-line configuration. The software will have
two addresses: n=Primary and n+1=Backup. In this case, two controllers must be
added to structure. The first is considered the “Primary” and the backup is considered
to have the role of “Backup w/Online.”

Firmware revision will be automatically set when the status of the controller is “on line.”
The ID is for the first set of number or characters to link the cross -referenced sheets to the
controller. In the case of Backup w/online, each controller must have the same characters.

Communication Configuration
There are two possibilities for communication to the Control Network. The Computer must
either be a server with a physical connection to the communication controllers or the
computer will be configured as a client and will TCP/IP through a communication server.
• Communication server
Physical ICI – a logical number chosen for the identification of the ICI where the
computer connects to the control network.
Device – how the connection is made to the ICI which could be through COM1 or COM2,
the communication port on computer, or through the ENET (ethernet).
TCP/IP section has a port value which must stay at 3001.
Communications Client
Client Logical ICI number - the number of the ICI where the Communication Sever computer
is connected.
Server Node- the name of Communication Sever computer.
TCP/IP - Use this option if the computer are on an O-net (Operation Network) and all located
in the same workgroup.
Local - This option is selected if the server and the client are located on the same computer.

Part-IV (28.07.10 to 30.07.10)

PGP CONFIGURATION
Objectives: Course objective was to understand PGP operation and configuration.

Database configuration :- Database Subsystem includes following databases:

 Engineering Unit Database

  Logic State Descriptor Database
 Alarm Comment Database
 Text Selector Database
 Tag Database

There are two kinds of configuration methods for all above databases: one is online
configuration; the other is offline configuration. The default directories for above offline
database files are as follows:

 Engineering Units Database files: <…>\config\eu，database files can be CF or

DBF or XLS files;
 Logic State Descriptor Database files: <…>\config\lsd，database files can be CF
or DBF or XLS files;
 Alarm Comment Database: <…>\config\alrm，database files can be DBF or XLS
files;
 Text Selector Database: <…>\config\text，database files can be DBF or XLS
files;
 Tag Database : <…>\config\tag，database files can be DBF or XLS files;

User can firstly create offline database files by the Dbase III/IV or Excel utility or by the
Symphony Engineering Work Station, and then build online databases according to the offline
database files by running Build Data Base procedure of System Setup. By running Export
procedure of System Setup, online databases can also be exported to offline database files.

Tag configuration

Tag configuration can be done through online and offline both ways. There are several fields
which are universal for all types and source of tags and some fields are specific to particular
type and source of tag.

TYPE DESCRIPTION
INFY INFINET RACK
EXT GENERIC EXTERNAL COMMUNICATION
CALC INTERNAL CALCULATION TAG
LAB CONSTANT LAB ENTRY
USER INTERNAL USER APPLICATION PROGRAMME
DEVSTA DEVICE STATUS
OPC OPC COMMUNICATION

The TAGUID code is internally generated the first time a tag is added to the PGP database. To
identify logical address and source of tags ICI no., loop, PCU, module, and block no. is given
in database.

Trend group subsystem :- trend group can also be configured online as well as offline. There
are several types of trend groups.
Tags in trend groups can be added directly or through tag list file. Trends groups can also be
derived trend group in which tags can be sourced from some other ternd group.

Historical Trend Group:- Sample frequency, no. of samples, bad samples and archival units
has to be set to define historical trend group. These types of trend groups are useful in
capturing max, min and average values and calculating excursions.
Post trip trends can also be generated with changing state of digital tag.

Report Subsystem
PGP provides a complete set of functionalities for generating and managing reports.

Report logs are used to obtain data from the PGP database, either from the realtime and
the historical archives, and to load data into spreadsheets, allowing the user to format,
store and perform calculations using live and historic process data.

The reports are generated and maintained on the PGP Server computer.

The report generation program produces files that may be printed and/or archived
on the hard disk. To control the disk allocation of the report archive, the maximum
number of files kept archived and the maximum latency time can be defined for
each report.
PGP provides two special function libraries that can be used in Excel: one is public
function library (Tnt.xla), the other is thermodynamic function library (Steamlib.xla). public
function library (Tnt.xla) is located within the folder of “<…>\config\reports\”, and
thermodynamic function library (Steamlib.xla) is located within the folder of “<…
>\config\Calc\”. These two libraries should be added to Excel as Add-In for creating
template work-sheets.
 Graphic Display
The main elements of a Graphic Display are the following:
1. Background Data :- All static implementatons are called the Graphic Display
background. The static information may consist of shapes, lines, text, special
characters, etc.
2. Dynamic Fields :- Each Graphic Display may contain Dynamic Objects to
represent plant status.
3. Display Header :- Each Graphic Display contains a Header block of information.
The Graphic Display Header contains information such as The Graphic Display name
and description.
Graphic Display Builder Program
The Graphic Display Builder program is named DisplayBuilder.exe. The program is
located in the \Power Generation Portal\bin folder.

Starting the Graphic Display Builder

Start the Graphic Display Builder using these methods:
• Double-click the DisplayBuilder.exe file.
• Double-click any file with the .UCBG extension.
• In PGP Explorer select Display from the Configuration menu.

Editable Format Files

Editable format files include all elements to define a Graphic Display. These files are
identified with the following extensions:

Executable Format Files

Executable Format files include all elements required for realtime processes, like PGP
Explorer, to show the Graphic Display with the current plant status. Each executable
format file is identified with these extensions:
Diagrams

Installation of PGP
Operating System
Power Generation Portal must be installed on a Personal or Server Computer running the
Microsoft Operating System:
• Windows 2000 Professional or Windows 2000 Server,
version 5.0, upgraded to Service Pack 2 or later.
• Windows XP Professional, version 2002. Service pack 1 and 2
• Windows 2003 Enterprise Edition

Other Packages (1)

 The Power Generation Portal setup kit includes some external packages needed for the
Power Generation Portal features
The following packages are included with the Power Generation Portal CD. They must be
installed on the system before Power Generation Portal is installed:
 DOTNETFX.EXE - Microsoft .NET framework 1.1 package
 SOAPSDK.EXE - SOAP Toolkit 3.0
 AdbeRd70_enu_full.exe - Adobe Acrobat Reader
 Sentinel Protection Installer 7.1.0.exe
 Drive for the Sentinel license key. Install only if needed.
Power Generation Portal relies on Microsoft Excel for report generation. Power
Generation Portal supports Microsoft Excel 97, Microsoft Excel 2000 and Microsoft
Excel XP.

Installing Power Generation Portal

This is the core installation of Power Generation Portal.
 Log on as Administrator
 Use Windows Explorer to locate the Power Generation Portal distribution kit
folders.
 Run the Setup.exe program to install Power Generation Portal. A series of
questions allow you to customize the installed package. In most cases the
suggested default answer is valid.
 Select the desired path for the files.
 Select the Setup Type
 Restart the Computer

Post Installation
After you restart the computer the installation procedure start a post-installation program
which automatically performs some necessary actions for setup. Actions include:

Client/Server Environment Configuration

The steps below describe how to configure the proper client/server environment.
Log on as Administrator.
 Select Start > Programs > ABB Industrial IT > Power Generation Portal >
System Setup.
 Expand the Client/Server folder, and then select Client/Server.

General Setup
Many of the actions required for the setup of Power Generation Portal have been
automated and collected into a General Setup phase. The General Setup phase is part of
the Post Installation procedure which is automatically started after the Power Generation
Portal installation. However it can be also manually started after every installation or
upgrade of Power Generation Portal.

Licensing Registration
 The following license registration procedure must only be performed on systems that are
configured as Servers, or client and Servers. Do not perform this procedure on client
systems.

 Select Start > Programs > ABB Industrial IT > Power Generation Portal > System
Setup.
 Select the License Entry item from the option tree, and then select Basic Features.
 Fill in the relevant fields (including the software key) accord to the license
certificate, or select Add from File if you have a file containing this information.
 Click the Validate button. A message will indicate if the validation was successful.
 Review the data if the license does not validate.
 Click the Save button when everything is correct.
 Press the Test Checkout button to verify the license against the current Machine
ID.
 Repeat the previous steps Drivers and Applications license groups.
 Exit the License Entry program by clicking the Exit button.

C-NET Interface (semAPI) Configuration

 The C-NET Interface package (semAPI) provides the communication between the
C-NET and Power Generation Portal.
 The C-NET interface configuration must be performed on the server(s) only. This
includes systems configured as Server Only and Client and Server. The server is
the computer physically connected to the C-NET.
 Select the ABB Industrial IT folder and then select the Power Generation Portal
folder. The C-NET Interface setup program is located in the folder: Power
Generation Portal\semAPI\Exe\Winnt
 Configure C-NET Interface package.
 Run (double-click) the iciconf.exe program.
 Set Physical ICI Device to desired serial or SCSI port.
 Set the communication speed accord to the ICI speed set up
 Set the Network Communication Protocol to TCP/IP (default) if the computer is
equipped with a network interface. If TCP/IP is not installed, set the Network
Communication Protocol to LOCAL.
 Click the Save button. A message will indicate if the procedure was successful.
 Click the Quit button.

Building Data Files

 Only perform this procedure if the computer will operate as a Server (Server Only
or Client and Server).
 Only perform this procedure when Power Generation Portal is first installed, or
when a complete cleanup of the data file is required.

 Local data files are usually not shipped with the distribution kit. You need to build
the local data files using the following database build procedure.
 The kit provides configuration files that you can customize based on your specific
requirements. These configuration files effect how the database build procedure
creates local data files. You can either:
o Customize the configuration files and then perform a database build.
o Perform a database build using the default configuration files.
 At least one database build must be completed in order to run Power Generation
Portal properly.
 In the procedure below all system builders are activated. They will process all
input data files in the configuration folders. Be sure that all input data files are
properly set, and that temporary or test input files are not stored in the configuration
folders.
o Log-in as Administrator.
o Select Start > Programs > ABB Industrial IT > Power Generation Portal
> System Setup.
o Expand the Build Database folder, and then select Build All. All system
builders will be executed in sequence. Wait for a message indicating that
system generation has completed.
o Exit System Setup.
 When the database build is complete the Power Generation Portal application is
ready to run.