[go: up one dir, main page]

0% found this document useful (0 votes)
433 views139 pages

Siemens T2000 System Training

This document provides an overview of the structure and contents of a training course on maintaining and repairing a T2000 automation system. The 6-day course covers various components of the T2000 system through 5 modules: 1) HMI subsystem, 2) engineering and diagnostic tools, 3) automation layer, 4) dedicated controllers, and 5) auxiliary systems. Each module goes into technical details on the components, principles of operation, configuration, diagnosis, maintenance, backup/recovery procedures.

Uploaded by

Raul Callejas
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
0% found this document useful (0 votes)
433 views139 pages

Siemens T2000 System Training

This document provides an overview of the structure and contents of a training course on maintaining and repairing a T2000 automation system. The 6-day course covers various components of the T2000 system through 5 modules: 1) HMI subsystem, 2) engineering and diagnostic tools, 3) automation layer, 4) dedicated controllers, and 5) auxiliary systems. Each module goes into technical details on the components, principles of operation, configuration, diagnosis, maintenance, backup/recovery procedures.

Uploaded by

Raul Callejas
Copyright
© © All Rights Reserved
We take content rights seriously. If you suspect this is your content, claim it here.
Available Formats
Download as PDF, TXT or read online on Scribd
You are on page 1/ 139

Course structure

rg
This course is starting with brief explanation of the principles of the system for
each component and sub-component and later it explains in great detail how to
maintain and repair given component should it be required.
The components addressed at this course are listed below
• OM650 - HMI part of the T2000 system (Course module 100)

– PU - Processing Units
– SU - Server Units
– OT - Operator Terminal
e.o
– HMI Server
– OPC - OPC servers
ee
• T2000 System Configuration and Diagnostic tools (Course module 200)

– ES 680 - Engineering Station


– DS 670 - Diagnostic System

• T2000 System Communication infrastructure and Synchronisation (Course


@i

module 300)

– GPS Clock - synchronisation of DCS system components


– Networking
∗ Plant Bus
∗ Terminal Bus
ec

∗ Bridge between power plant units


∗ Other Networks
· Profibus network and special components like IM 153 mod-
ule, Y-link etc.
· TCP/IP networks
up

• Automation and Field Instrumentation layer (Course module 400)

– AP - Automation Processor
∗ I/O interfaces like SIM modules
∗ Communication interfaces like profibus master or CP1430 cards
∗ Diagnostic and other essential hardware
ro

1
2

– AP-T - Turbine Governor (Course module 400)


∗ I/O interfaces
∗ Communication interfaces
∗ Diagnostic and other essential hardware
– CM - Communication Module
– 95F - Failsafe protection
∗ I/O interfaces
∗ Communication interfaces
∗ Diagnostic and other essential hardware

rg
– S7-300 - Siemens S7 PLC used at boiler protection

• Auxiliary systems (Course module 500)

– WIN_TS - Windows Turbine Stress Monitoring System


– TDY - e.o
– Argus - Gas Turbine humming monitoring system
– PAS servers
– VM 600 - turbines, pump and generators vibration monitoring system
– Fight recorder
– Tec4system ...?
ee
• Service and maintenance systems (Course module 600)

– PG - Siemens computer system used for advanced diagnostic and


configuration
– Laptops - Other computers used for various purposes
@i
ec
up
ro
Contents

rg
1 Course planning 7
1.1 Day 1 - OM650 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Day 2 - Engineering and Diagnostic . . . . . . . . . . . . . . . . 7
1.3 Day 3 - Automation layer . . . . . . . . . . . . . . . . . . . . . . 7
1.4 Day 4 - Dedicated controllers . . . . . . . . . . . . . . . . . . . . 8
e.o
1.5 Day 5 - Auxiliary systems . . . . . . . . .
1.6 Day 6 - Hands on, Questions and Answers
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
8
8

I Siemens T2000 system principles 9


2 General T2000 architecture 11
2.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
ee
2.1.1 OM 650 process control and information system . . . . . 12
2.1.2 AS 620 Automation System. . . . . . . . . . . . . . . . . 13
2.1.3 ES 680 engineering system . . . . . . . . . . . . . . . . . 13
2.1.4 Network communication . . . . . . . . . . . . . . . . . . . 14
2.1.5 DS 670 diagnostic system . . . . . . . . . . . . . . . . . . 14
@i

II Component Based Training 15


3 OM650 - T2000 HMI subsystem 16
3.1 OM System Infrastructure . . . . . . . . . . . . . . . . . . . . . . 17
3.1.1 InfOmk.proj . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.2 InfFb.proj . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
ec

3.1.3 InfDevInst.proj . . . . . . . . . . . . . . . . . . . . . . . 20
3.1.4 InfObm.inst . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.5 License files - licensing . . . . . . . . . . . . . . . . . . . . 21
3.1.6 OM 650 files on ES680 . . . . . . . . . . . . . . . . . . . . 22
3.2 C101 - PU - Processing Unit . . . . . . . . . . . . . . . . . . . . 23
up

3.2.1 Functional principles and component basic configuration . 24


3.2.2 Component Diagnostic and Routine maintenance . . . . . 29
3.2.2.1 Routine maintenance . . . . . . . . . . . . . . . 29
3.2.2.2 Diagnostic files . . . . . . . . . . . . . . . . . . . 31
3.2.2.3 OmProj.Check . . . . . . . . . . . . . . . . . . . 32
3.2.2.4 rdb . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.2.3 Component Backup and Recovery principles . . . . . . . . 34
ro

3
CONTENTS 4

3.2.3.1 Backup Procedure . . . . . . . . . . . . . . . . 35


3.2.3.2 Restore Procedure . . . . . . . . . . . . . . . . . 38
3.2.4 Component Installation and Commissioning . . . . . . . . 40
3.2.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
3.3 C102 - SU - Server Unit . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.1 Functional principles and component basic configuration . 42
3.3.2 Component Diagnostic and Routine maintenance . . . . . 45
3.3.2.1 Routine maintenance . . . . . . . . . . . . . . . 45
3.3.2.2 Diagnostic files . . . . . . . . . . . . . . . . . . . 48
3.3.2.3 Resetting and analyzing arc subsystem . . . . . 50
3.3.3 Component Backup and Recovery principles . . . . . . . . 51

rg
3.3.3.1 Backup Procedure . . . . . . . . . . . . . . . . 52
3.3.3.2 Restore Procedure . . . . . . . . . . . . . . . . . 55
3.3.4 Component Installation and Commissioning . . . . . . . . 57
3.3.5 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.4 C103 - HMI Server - web4txp . . . . . . . . . . . . . . . . . . . . 58
3.4.1 Functional principles and component basic configuration . 59
e.o
3.4.2 Component Diagnostic and Routine maintenance . . . .
3.4.2.1 Routine maintenance . . . . . . . . . . . . . .
3.4.2.2 Diagnostic files . . . . . . . . . . . . . . . . . .
3.4.3 Component Backup and Recovery principles . . . . . . .
.
.
.
.
65
65
67
69
3.4.3.1 Backup Procedure . . . . . . . . . . . . . . . . 70
3.4.3.2 Restore Procedure . . . . . . . . . . . . . . . . . 73
3.4.4 Web4TXP system licensing . . . . . . . . . . . . . . . . . 75
3.4.5 Component Installation and Commissioning . . . . . . . . 75
ee
3.4.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.4.7 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 75

4 C201 - ES 680 - Engineering Station 76


4.0.8 Functional principles and component basic configuration . 77
4.0.9 ES 680 User interface . . . . . . . . . . . . . . . . . . . . 77
@i

4.0.10 ES 680 component file structure . . . . . . . . . . . . . . 77


4.0.11 Component Diagnostic and Routine maintenance . . . . . 78
4.0.11.1 Routine maintenance . . . . . . . . . . . . . . . 78
4.0.12 Component Backup and Recovery principles . . . . . . . . 79
4.0.13 Disk Backup Procedure . . . . . . . . . . . . . . . . . . . 79
4.0.14 Database restore procedure . . . . . . . . . . . . . . . . . 85
ec

4.0.15 Component Installation and Commissioning . . . . . . . . 85


4.0.16 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 85

5 C202 - DS 670 - Diagnostic station 86


5.1 Functional principles and component basic configuration . . . . . 87
5.2 Starting and stopping DS 670 . . . . . . . . . . . . . . . . . . . 87
up

5.3 Daily use of DS670 . . . . . . . . . . . . . . . . . . . . . . . . . . 87


5.4 Component Diagnostic and Routine maintenance . . . . . . . . . 88
5.4.1 Routine maintenance . . . . . . . . . . . . . . . . . . . . . 88
5.4.2 Component Backup and Recovery principles . . . . . . . . 89
5.5 Backup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.5.1 Backup Procedure . . . . . . . . . . . . . . . . . . . . . . 90
5.6 Restore . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
ro
CONTENTS 5

5.6.1 Restore Procedure . . . . . . . . . . . . . . . . . . . . . . 93


5.7 DS 670 system licensing . . . . . . . . . . . . . . . . . . . . . . . 95
5.8 Component Installation and Commissioning . . . . . . . . . . . . 95
5.8.1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . 95

6 C300 - OSM - Managed network switch 96


6.1 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96

7 C400 - AP 620 - Automation Processor 97


7.1 Functional principles and component basic configuration . . . . . 99
7.2 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100

rg
7.3 Component Backup and Recovery principles . . . . . . . . . . . . 101
7.4 Components Installation and Commissioning - Case study . . . . 101
7.5 Burn New IM308 Flash Card . . . . . . . . . . . . . . . . . . . . 102
7.5.1 General Info: . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.5.2 When IM608 card should be programmed . . . . . . . . . 103
7.5.3 What You Need: . . . . . . . . . . . . . . . . . . . . . . . 103
e.o
7.5.4 Get IM308 Data From ES680: . . . . . . . . . . .
7.5.5 Burn The New Flash Card: . . . . . . . . . . . .
7.5.6 Problem/Solutions: . . . . . . . . . . . . . . . . .
7.6 References . . . . . . . . . . . . . . . . . . . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
103
104
104
105

8 C450 - CM - Communication module 106


8.1 Functional principles and component basic configuration . . . . . 107
8.2 Maintenance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
ee
8.3 Component Backup and Recovery principles . . . . . . . . . . . . 110
8.4 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110

9 C490 - 95F - protection system 111


9.1 On-the-Job training
Protection system and TXP communication . . . . . . . . . . . . 112
@i

9.1.1 Control and protection systems brief description . . . . . 112


9.1.2 Gas Turbine governor (SIMADYN) . . . . . . . . . . . . . 112
9.1.3 DCS control system (TXP680) . . . . . . . . . . . . . . . 112
9.1.4 Protection system (95F) . . . . . . . . . . . . . . . . . . . 113
9.1.5 Startup Frequency Controller and Static excitation unit
(SFC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
9.1.6 Unit protection . . . . . . . . . . . . . . . . . . . . . . . . 113
ec

9.1.7 OM system (OM650) . . . . . . . . . . . . . . . . . . . . . 113


9.2 Systems interconnection . . . . . . . . . . . . . . . . . . . . . . . 115
9.3 Distribution of the systems over cabinets . . . . . . . . . . . . . . 117
9.4 Protection system description in detail . . . . . . . . . . . . . . . 117
9.4.1 Hardware based over-speed protection . . . . . . . . . . . 117
up

9.4.1.1 Over-speed system diagnostic . . . . . . . . . . . 118


9.4.1.2 O/S system “REAL” test . . . . . . . . . . . . . 118
9.4.2 Software based over-speed protection . . . . . . . . . . . . 120
9.4.3 Flame monitoring . . . . . . . . . . . . . . . . . . . . . . 120
9.4.4 Manual turbine trip . . . . . . . . . . . . . . . . . . . . . 120
9.4.5 Fire protection trips . . . . . . . . . . . . . . . . . . . . . 120
9.4.6 Surge protection . . . . . . . . . . . . . . . . . . . . . . . 121
ro
CONTENTS 6

9.4.7 Unit protection . . . . . . . . . . . . . . . . . . . . . . . . 121


9.4.8 Protection circuit (protection signals coming from TXP
system) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
9.5 Protection system redundancy and reliability . . . . . . . . . . . 121
9.5.1 Non-Coincidence alarms . . . . . . . . . . . . . . . . . . . 121
9.5.2 System auto-diagnostic . . . . . . . . . . . . . . . . . . . 122
9.5.2.1 Over-speed protection diagnostic sub-system . . 122
9.5.2.2 Trip circuit diagnostic . . . . . . . . . . . . . . . 122
9.5.2.3 ET200 subsystem health monitoring . . . . . . . 122
9.5.2.4 Units synchronization check . . . . . . . . . . . . 122
9.5.2.5 95F self-diagnostic sub-system . . . . . . . . . . 122

rg
9.5.3 CPU (95F) is designed as two independent high-reliability
redundant unit . . . . . . . . . . . . . . . . . . . . . . . . 123
9.6 Trouble shooting . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
9.6.1 Start-up problems . . . . . . . . . . . . . . . . . . . . . . 123
9.6.2 Problems during running machine . . . . . . . . . . . . . 124
9.7 Installing 95F software on the PG . . . . . . . . . . . . . . . . . 125
e.o
9.7.1 How to install 95F software on new PG . . . . . . . . . .
9.8 95F testing mode . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.8.1 Download code to 95F in testing mode . . . . . . . . . . .
9.8.2 95F overall reset . . . . . . . . . . . . . . . . . . . . . . .
125
125
125
128
9.9 95F faults rectifying . . . . . . . . . . . . . . . . . . . . . . . . . 130
9.9.1 Rectify MYB00EU111B fault . . . . . . . . . . . . . . . . 130
9.9.2 Diagnostic mode after 95F restart . . . . . . . . . . . . . 130
9.10 References . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
ee
III Cybersecurity 133

IV Questions to be answered 135


@i
ec
up
ro
Chapter 1

Course planning

rg
The course duration is five and half days long. Below is described daily planning
of the course.

1.1 Day 1 - OM650


e.o
The course is starting with the HMI system (course module 100) - the most
visible part of the system - everyone sees it. First principles of the TXP / T2000
DCS system are explained followed with the details about daily maintenance
tasks, disaster recovery planning and finally detailed explanation of the system.
ee
1.2 Day 2 - Engineering and Diagnostic
Day number two will start with summarizing of functions of the OM650 and will
continue to explain engineering tool ES 680 (course module 200) in relation to
the OM650 system. This will be followed by the explanation of the networking
@i

(module 300) it’s configuration and by explanation of the time synchronisation.


The details about daily maintenance tasks of the ES 680 will be followed by
disaster recovery planning.
On the end of day DS 670 diagnostic system (course module 350) and it’s
daily use will be addressed. Since disaster recovery plan for DS 670 is identical
to the OM650 components no additional material is required.
ec

1.3 Day 3 - Automation layer


Day number three will be dedicated to automation layer specially to AP (Au-
tomation Processor - module 400) it’s structure, configuration and maintenance
up

followed by configuration tasks like adding signals to the I/O system.


This day training will be broken into three sections which will be held on
different locations as well.
• Location: Training center (case study adding analog output signal - engi-
neering and all related tasks) and Networking
ro

7
1.4. DAY 4 - DEDICATED CONTROLLERS 8

• Location: PCC (Physical implementation and examples, PCC hardware


explanation, CM module backup)
• Location: MCR - Main Control Room (Diagnostics and practical imple-
mentation of case study)

1.4 Day 4 - Dedicated controllers


On day four detailed explanation of the CM module (Module 450), principles of
protection systems like overspeed system, vibration monitoring system, Boiler
S7 protection system, 95F (course module 490) will be addressed. The functional

rg
principles and maintenance manuals are being discussed here.
This day training will be broken into three sections which will be held on
different locations as well.
• Location: Training center (Theory of protection systems)

1.5
e.o
• Location: PCC (CM module backup, hardware explanation)

Day 5 - Auxiliary systems


• After the initial test references will be discussed and reviewed.
• Analysis and discussion of disaster recovery planning will be addressed.
ee
• Auxiliary systems like WIN_TS, Argus, VM 600 are being explained
(course module 500). The maintenance point of view is being in focus
on the documentation, manuals and disaster recovery planning.
• The functional blocks explained:
@i

– Analog and binary inputs for physical hardware and signals sent over
communication
– Controllers and setpoint calculations
– Generic blocks as a timers, switches etc.
– Brief explanation of the YOR diagrams
ec

• The core I&C system explained as per reference “471 - Core I&C sagunto”
• OPC servers configuration and hands on practice of the update
• Remaining AP-T - Turbine Governors and Excitation system to be studied
and will be explained throught the future visit.
up

1.6 Day 6 - Hands on, Questions and Answers


The half of the day number six is being dedicated to the training on the ES
680 station (module 200) and training on the OM components backup (module
number 100). The hands on will be carried in CCR divided into two groups so
both teams can try both tasks.
ro
rg
Part I
e.o
Siemens T2000 system
principles
ee
@i
ec
up
ro

9
10

Objective of this section is to introduce components and subcomponents of


the Siemens T2000 system, briefly describe their function and establish basis
for further detailed training.

rg
e.o
ee
@i
ec
up
ro
Chapter 2

General T2000 architecture

rg
2.1 Overview
e.o
The Siemens T2000 DCS control system provides all I&C facilities that are nec-
essary for automating, handling, monitoring, and archiving processes specifically
for power plants. The tasks of the T2000 DCS control system are distributed
to different subsystems as shown below.

OM 650 Operating and Monitoring system. This is the process control


and information system for operator-process communication and visualization.
ee
AS 620 Automation System. This is the system used for process automa-
tion.

ES 680 Engineering System. This system is employed for configuration


and commissioning. This is a place where configuration database is located
@i

Network Communication.
• Plant bus - individual AP’s (Automation Processors) communicater with
each other via this bus and with OM system
• Terminal Bus - The HMI system is connected here
ec

DS 670 Diagnostic System. Optional component for detailed system


diagnostics.
up
ro

11
2.1. OVERVIEW 12

Figure 2.1.1: Main T2000 components are shown on this figure

rg
2.1.1 OM 650 process control and information system
e.o
The OM 650 process control and information system is the interface between the
system and the operator in the control room. This is also called HMI - Human
Machine Interface. This system enables the process to be centrally monitored
and controlled. In addition, the system provides all functions that are required
for logging the process and for archiving the data.
The HMI system is consisted of the following computers:
• PU Unit - connection with AP’s, process calculations like a running hours
ee
• SU Unit - long term archiving, description database, reports processing
• HMI server - server which generate Human Machine Interface
• TC - Thin Client - browser based client to display HMI interface
@i

For propper function each computer in HMI system requires unique name not
only within one unit but in complete poweplant.

Figure 2.1.2: Sugen computer naming concept


ec
up
ro
2.1. OVERVIEW 13

2.1.2 AS 620 Automation System.


The AS 620 subsystem performs the automation tasks of the plant processes.
• The AS 620 acquires measured values and states from the process, per-
forms open and closed-loop control functions, and transfers the resulting
manipulated variable values, correction values, and commands to the pro-
cess.
• The other subsystems employ the AS 620 subsystem as the interface to the
process. The AS 620 transfers the commands from the OM 650 operator
communication and visualization system to the process.

rg
• There are vatious versions of AS 620 depending on process needs

– AS 620B for basic automation tasks which could be onfigured as FUM


or SIM variant
– AS 620 T - Turbine controller, high speed control

2.1.3
e.o
ES 680 engineering system
The ES 680 engineering system is the central configuration system of TXP. ES
680 is used for configuring:
• the AS 620 automation system,

• the OM 650 process control and information system,


ee
• the SINEC H1 FO bus system, and the necessary hardware.
ES 680 provides a configuration package for each target system. ES 680 centrally
administers all configuration data, which means data is entered only once. The
configuration of the AS functions and processing functions in OM 650 are based
@i

on control system flow charts. A control system flowchart editor (known as


FUP editor) in the ES 680 permits interactive entry of these control system
flow charts. The configuration principle of the ES 680 is based on consistent
forward configuration. Initial configuration and modifications are exclusively
performed through the configuration system with subsequent automatic code
generation. This guarantees real time documentation of the system hardware
and all AS, OM, and SINEC functions, and permits modifications to be centrally
ec

controlled.
up
ro
2.1. OVERVIEW 14

2.1.4 Network communication


There are two principan networks at the T2000 system.

Plant bus The network structure of the SINEC H1 bus system enables com-
munication between the individual sub-systems of TXP. It mainly allows com-
munication between AP’s (Automation Processors) and OM 650 system. Special
hardware (networking cards ) is required to allow this kind of communication.

Terminal bus It’s a standard TCP/IP network where each node has a unique
IP address and node name.

rg
Other network communication If there is a need to establish communica-
tion with other systems there are possibilities of using
• OPC protocol running on PU (Processing Unit)

Module)
e.o
• Various RTU, Modbus, IEEE protocols running on CM (Comminication

The networks are designed to be “one fault tolerant”. This mean that failure of
any of one component will not cause breakdown of entire network. The network
is configured as a ring.

Figure 2.1.3: The plant bus and terminal bus are configure as a ring
ee
@i
ec

2.1.5 DS 670 diagnostic system


up

The optional DS 670 diagnostic system is the tool that is used for monitoring
and detecting malfunctions in the I&C components of TXP.
ro
rg
Part II
e.o
Component Based Training
ee
@i
ec
up
ro

15
Chapter 3

OM650 - T2000 HMI

rg
subsystem
e.o
The OM 650 process control and information system is the interface between the
system and the operator in the control room. This is also called HMI - Human
Machine Interface. This system enables the process to be centrally monitored
and controlled. In addition, the system provides all functions that are required
for logging the process and for archiving the data.
The HMI system is consisted of the following computers:
• PU Unit - connection with AP’s, process calculations like a running hours
ee
• SU Unit - long term archiving, description database, reports processing
• HMI server - server which generate Human Machine Interface
• TC - Thin Client - browser based client to display HMI interface
@i

For proper function each computer in HMI system requires unique name not
only within one unit but in complete power plant.

Figure 3.0.1: Sugen computer naming concept


ec
up
ro

16
3.1. OM SYSTEM INFRASTRUCTURE 17

3.1 OM System Infrastructure


Every OM component is part of the concept called “OM infrastructure”. The
infrastructure is defined via means of the files described in following text. The
infrastructure can be seen as shown on the figure below.

Figure 3.1.1: The infrastructure of the OM system distributed over several


components

rg
e.o
For the configuration of the distributed OM system infrastructure (INF)
ee
needs to be defined. Infrastructure is defined in following files:
• InfOmk.proj
• InfFb.proj
• InfDevInst.proj
@i

• InfObm.inst
All these files are located in the directory $OmProjData/inf
ec
up
ro
3.1. OM SYSTEM INFRASTRUCTURE 18

3.1.1 InfOmk.proj
In the file InfOmk.proj all OM components are listed and an internal unique
component number is assigned to each component. The LTK-No. must always
be negative, the LTK-Inst is the same number but positive, and the OMK-Inst
is equal to LTK-Inst plus 1.
These numbers are defined at topology diagram on ES 680 engineering sta-
tion.
ES 680 is generating these files automatically.
This file must be identical on all OM components

rg
Algorithm 3.1 Content of the InfOmk.proj file at Sugen PU unit
# InfOmk.proj

# ICC-No = negative number in steps of 100


# RedPrio = redundant priority. 1 after runup leading / 2 after runup standby
# OMC-Inst = instance number of OM component
# ICC-Inst =

# Hostname.Domain
s30ot1.TXP.OM650.scn
e.o
instance number of superset I&C component

-100
ICC-No RedPrio OMC-Inst ICC-Inst
1 101 100
s30ot2.TXP.OM650.scn -200 1 201 200
s30p1a.TXP.OM650.scn -300 2 302 300
s30p1b.TXP.OM650.scn -300 1 301 300
s30s1a.TXP.OM650.scn -400 2 402 400
ee
s30s1b.TXP.OM650.scn -400 1 401 400
@i
ec
up
ro
3.1. OM SYSTEM INFRASTRUCTURE 19

3.1.2 InfFb.proj
In the file InfFb.proj every function area from a plant is assigned to exactly one
redundant PU computer set. In bellow displayed file can be seen for example
that functional area 207 is being processed as follows:
• MAC - process calculations by subcomponent 300 which is defined in the
file InfOmk.proj as a computer s30p1a and s30p1b
• ASR - communication towards to AP’s by subcomponent 300 which is
defined in the file InfOmk.proj as a computer s30p1a and s30p1b

rg
• ARC - short term archive by subcomponent 300 which is defined in the
file InfOmk.proj as a computer s30p1a and s30p1b
• BDM - database of descriptions by subcomponent 400 which is defined in
the file InfOmk.proj as a computer s30s1a and s30s1b
• LZA - long term archive by subcomponent 400 which is defined in the file
e.o
InfOmk.proj as a computer s30s1a and s30s1b
• PRT - printing and searching archives by subcomponent 400 which is
defined in the file InfOmk.proj as a computer s30s1a and s30s1b
• NTB - notebook functions by subcomponent 400 which is defined in the
file InfOmk.proj as a computer s30s1a and s30s1b
This file must be identical on all OM components.
ee
Algorithm 3.2 Content of the InfFb file at Sugen PU unit
216 MAC=300 ARC=300 BDM=400 LZA=400 PRT=400 NTB=400
207 MAC=300 ASR=300 ARC=300 BDM=400 LZA=400 PRT=400 NTB=400
208 MAC=300 ASR=300 ARC=300 BDM=400 LZA=400 PRT=400 NTB=400
@i

210 MAC=300 ASR=300 ARC=300 BDM=400 LZA=400 PRT=400 NTB=400


213 MAC=300 ASR=300 ARC=300 BDM=400 LZA=400 PRT=400 NTB=400
215 MAC=300 ASR=300 ARC=300 BDM=400 LZA=400 PRT=400 NTB=400
217 MAC=300 ASR=300 ARC=300 BDM=400 LZA=400 PRT=400 NTB=400
ec
up
ro
3.1. OM SYSTEM INFRASTRUCTURE 20

3.1.3 InfDevInst.proj
The file InfDevInst.proj is needed for device monitoring. File structure: one
line for each device

1. Column: OMK-Instance number from the corresponding OM computer


2. Column: The instance number of the device (this number is freely se-
lectable, but it needs to be unique within the OM FC)
3. Column: Reference for the device (20550 = printer, 20500 = MOD drive)
4. Column: Device name (like the name present in /dev)

rg
This file must be identical on all OM components.

Algorithm 3.3 Content of the InfDevInst.proj file at Sugen PU unit


101 711 20600 UPS
201 712 20600 UPS
301 713 20600
302 714 20600
401 715 20600
402 716 20600
UPS
UPS
UPS
UPS
e.o
401 811 20500 MOD00
402 812 20500 MOD00
101 751 20550 HPLJ2200
201 752 20550 HPLJ2200
ee
101 753 20550 s00pr3
201 754 20550 s00pr4
101 755 20550 s00pr5
101 759 20550 s00pr9
201 750 20550 s00pr0
@i
ec
up
ro
3.1. OM SYSTEM INFRASTRUCTURE 21

3.1.4 InfObm.inst
The file InfObm.inst defines which OM subcomponents will run of given com-
puter. For details refer to specific OM component.

3.1.5 License files - licensing


This is single most problematic part of the T2000 system. It is very poorly
described however errors or misplacement of the licensing files may cause sig-
nificant problems with the system and are very difficult to find out. The OM
related license file is called OPT.conf and has to be located at $OmProjData/inf.

rg
The license is issued by the OEM and is related to the MAC address of the
main-board installed at the computer. Therefore if computer is being changed
new license is required or specific work around has to be applied.

Figure 3.1.2: Similar error might be found in error log files when there is an
issue with the OM license
e.o
ee
@i
ec
up
ro
3.1. OM SYSTEM INFRASTRUCTURE 22

3.1.6 OM 650 files on ES680


All discussed files are available on ES 680 from which they can be transferred
to the OM components if needed to be so. Detailed manual can be seen in the
reference directory called “103 - OM650 transfer and engineering”.
The following OM system parameterization files can be automatically gen-
erated from the topology diagram:
• InfOmk.proj
• InfFb.proj

rg
• Arc.proj

• Lza.proj
• Asr.proj
• bpr_LTK.dat (without the entries for devices such as printers and MODs)

still require manual editing:


• InfDevInst.proj
e.o
The following files cannot be automatically generated in the current version and

• Ot.hrn
• Ot.amu
ee
• The file for the OM I&C components bpr_LTK.dat has to be edited for
the device entries.
The log file is stored in the directory $TXP_HOME/data/$Proj/om/inf/log
under the following name: OMSYS_GEN_<date>_<time>
@i

Figure 3.1.3: Interface for the OM configuration files generation and transfer
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 23

3.2 C101 - PU - Processing Unit


This chapter is addressing OM 650 component called Processing Unit shortly
known under name PU. The pair of PUs in installed at each unit at power-plant.
It is addressing it from maintenance point of view.
Following is being addressed:
• Functional principles and component basic configuration
• Component Diagnostic and Routine maintenance
• Component Backup and Recovery principles

rg
• Component Installation and Commissioning

The processing unit is main interface between operator and automation level.
It’s main tasks are as follows:
• Communication with AP’s (Automation Processors) - Object manager
e.o
called ASR shown on figure below

– updating image of the process values


– sending commands given by the operator to the AP

• Providing short term archive - Object manager called ARC shown on


figure below
ee
• Providing various calculations like hours or energy counters - Object man-
ager called MAC shown on figure below

Figure 3.2.1: OM system status


@i
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 24

3.2.1 Functional principles and component basic configu-


ration
PU component file structure
The installation of OM 650 system is located in directories described below
• / –> this is Unix root of the file system

– /txpsys
∗ The executable programs of the OM software are located in this
directory or file system

rg
∗ There is defined system variable called $OmSys
– /txpsys/txpconf
∗ In this directory generic TXP configuration is located
∗ There is defined system variable called $OmConfData
– /txpproj/proj_std e.o
∗ In the txpproj directory or file system the engineering data are
stored (as for example the pictures for the MMI or the user-
specific network configuration data from ASR)
∗ There is defined system variable called $OmProjData
– /txptest
ee
∗ in the directory txptest the diagnostic files are located (error log
files), which are created by every OM subcomponent
∗ There is defined system variable called $OmDiagData
– /txpproz
∗ The process data (hard copies, notes, calculations) are stored in
@i

the directory txpproz


∗ There is defined system variable called $OmProzData

Each file system or directory mentioned above has a function-related organiza-


tion which is depending on the object managers installed on given OM compo-
nent.
ec

Figure 3.2.2: File structure of typical OM650 component


up

The directory structure of PU computer is as follows.


ro
3.2. C101 - PU - PROCESSING UNIT 25

• /root

– /txpsys
∗ /inf
∗ /asr
∗ /arc
∗ /mac
∗ /swi
– /txpproj/proj_std

rg
∗ /inf
∗ /asr
∗ /arc
∗ /mac
– /txptest



/inf
/asr
/arc
e.o
∗ /mac
– /txpproz
∗ /inf
ee
∗ /asr
∗ /arc
∗ /mac
@i
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 26

PU component configuration files


Infrastructure - INF For the configuration of the distributed OM system
infrastructure (INF) needs to be defined. Infrastructure is defined in following
files:
• InfOmk.proj
• InfFb.proj
• InfDevInst.proj
• InfObm.inst

rg
All these files are located in the directory $OmProjData/inf. Detailed descrip-
tion of infrastructure files can be found on page 17.

InfObm.inst The file InfObm.inst defines which OM subcomponents will run


of given computer.
e.o
This file is specific for each OM component.

Algorithm 3.4 Content of the InfObm.inst file at Sugen PU unit


#ObjMgr DirName
ASR asr
ARC arc
MAC mac
ee
@i
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 27

ASR ASR module configuration files defines configuration of the communi-


cation between OM and AP systems.
This file is located in the directory $OmProjData/asr

Asr.proj For the ASR module only one engineering file exists: the Asr.proj.
This file is generated on the ES.

rg
e.o
ee
@i
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 28

Algorithm 3.5 Content of the Asr.proj file at Sugen PU unit


# Asr . p r o j . s30p1a

# ASR − mode is norm al operation


IBS 0

# I n f o r m a t i o n f o r AS 341
IKZ_GK 341
IKZ_FB 207
IKZ_IN 1
AS_ueberwacht 1
AS_FB 207
end

# I n f o r m a t i o n f o r AS 342
IKZ_GK 342
IKZ_FB 207
IKZ_IN 42
AS_ueberwacht 1

rg
AS_FB 207
end

# I n f o r m a t i o n f o r AS 373
IKZ_GK 373
IKZ_FB 208
IKZ_IN 2
AS_ueberwacht 1
AS_FB 208
end

# I n f o r m a t i o n f o r AS 375
IKZ_GK 375
IKZ_FB 208
IKZ_IN 15
AS_ueberwacht 1
AS_FB 208
end

# I n f o r m a t i o n f o r AS 351
IKZ_GK 351
e.o
IKZ_FB 210
IKZ_IN 462
AS_ueberwacht 1
AS_FB 210
end
ee
# I n f o r m a t i o n f o r AS 392
IKZ_GK 392
IKZ_FB 210
IKZ_IN 1
AS_ueberwacht 1
AS_FB 210
AS_FB 213
AS_FB 215
end

# I n f o r m a t i o n f o r AS 311
IKZ_GK 311
@i

IKZ_FB 213
IKZ_IN 2
AS_ueberwacht 1
AS_FB 213
AS_FB 217
end

# I n f o r m a t i o n f o r AS 312
IKZ_GK 312
IKZ_FB 213
IKZ_IN 78
AS_ueberwacht 1
AS_FB 213
ec

end

# I n f o r m a t i o n f o r AS 313
IKZ_GK 313
IKZ_FB 213
IKZ_IN 125
AS_ueberwacht 1
AS_FB 213
end

# I n f o r m a t i o n f o r AS 393
up

IKZ_GK 393
IKZ_FB 217
IKZ_IN 1
AS_ueberwacht 1
AS_FB 215
AS_FB 217
end
ro
3.2. C101 - PU - PROCESSING UNIT 29

3.2.2 Component Diagnostic and Routine maintenance


When PU component starts failing proper diagnosis is required. Following some
most commons methods employed to detect which part of the system is failing
to decide on proper corrective measures.

3.2.2.1 Routine maintenance


The routine maintenance of PU component is at Sugen described by the proce-
dure F36-MI-02 [902]
Evaluation of the computer is in detail described in reference [001]

rg
• PL -t

– Check if all OM components are in operation


– All components must be if “fue” status or “akt” for hot standby
– Time must be synchronized
e.o
Figure 3.2.3: OM system status
ee
@i

• Pool /etc/dfspace

– Check for available disk space on all OM components

Figure 3.2.4: PU unit output of the /etc/dfspace command


ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 30

• Poll tail -7 /usr/lib/powerchute/*log

– Check for UPS / Battery failure - check for error messages

• OmProj.Check

– This command is not required for daily use - only after OM reconfi-
garation and after updates
– Verify OM configuration - check for any errors reported

• Evaluation of the file /txp/om650/txptest/DiagMeld* and subsequent er-

rg
rors if any

– Diagnostic files are explained in detail below


– Rule of thumb say - if both of diagnostic files have very different
dates and error messages their content are very seldom system seems
to be in order.

• /var/adm
e.o
– This is a location system log files for which root access might be
required
– verify system log files - syspages - see attachment No. 3 of the refer-
ence [001]
ee
• SAMPLER

– If any problems detected run SAMPLER - it will gather all log files
- MUST be done prior to any modifications!!!! It keeps history
– Transfer SAMPLER to the safe location
@i
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 31

3.2.2.2 Diagnostic files


Each object manager writes error log files. In these files errors and messages
are stored as a report. All diagnostic files are located in the path /txptest.

• The infrastructure module writes directly into directory /txptest.


• Every other object manager writes into its respective subdirectory. For
example the ASR writes into /txptest/asr.
• The diagnostic files are realised via a cyclic buffer. First all diagnostic
messages are written into file DiagMld.0. If this file reaches a size greater

rg
than 1 MB, then the file DiagMld.1 is created. If this file also becomes
greater than 1 MB, then DiagMld.0 is deleted and created again. Thanks
to this mechanism, the hard disk will never be full and the latest diagnostic
data are always available.
• All diagnostic files are always built with a two line set.
e.o
– The date and time of the message are written in the first line, as well
as the program name, process id, module name, module version, line
number and function name.
– On the second line we can find the error message number and the
error message description.

• Unfortunately these diagnostic files have been written by devel-


ee
opers and for other developers. Therefore they are often very
difficult to understand.
To see content of the generic diagnostic file follow these steps.
• Login as txpom user
@i

• Navigate to the location of the log files by commend

– cd $OmTestData

• Check with the directory listing which diagnostic file is newer

– ls -la Dia*
ec

• Use tail command to see last, let’s say 30 lines of the file DiagMld.0

– tail -30 D*.0

Should find that some object manager is reporting many errors, lets say asr
up

than check diagnostic files of asr manager as follows.


• Login as txpom user
• Navigate to the location of the log files by commend

– cd $OmTestData
– cd asr
ro
3.2. C101 - PU - PROCESSING UNIT 32

• Check with the directory listing which diagnostic file is newer

– ls -la Dia*

• Use tail command to see last, let’s say 30 lines of the file DiagMld.1

– tail -30 D*.1

All unix commands mentioned in this section are explaned at Bohemia Market
knowledge base at http://kb.bohemiamarket.com/index.php?title=Category:Unix_command

rg
3.2.2.3 OmProj.Check
This is a tool to verify OM configuration files.

e.o
ee
@i
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 33

3.2.2.4 rdb
The RDB is a tool to diagnose connection between AP and PU computer. To
verify communication type following commands on the PU computer.

• login as a tpom user


• type command

– rdb

• On menu select Function No. 3

rg
• Answer amount of the seconds youwant to see update - lets choose every
3 seconds
• Answer by pressing number 0 to the question if storage to file is required
• Quit by pressing DEL key
e.o
This command is as usual undocumented feature of OM 650 - detailed explana-
tion can be found at Bohemia Market knowledge base at http://kb.bohemiamarket.com/index.php?title=Rdb.
ee
@i
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 34

3.2.3 Component Backup and Recovery principles


The backup method used for processing computer is using OEM developed script
called Txp.Backup for backup purposes and Txp.Restore for restoration of the
component. This is fairly reliable procedure however should be noted that this
is logical type of the backup. Moreover !! this tools do not backup process
related data !!
There is a procedure at Sugen MIG654 [954] addressing this task.

Backup

rg
Equipment required:
• External DDS2 or DDS3 DAT tape drive
• VGA monitor
• PS2 Keyboard e.o
• Ultra wide SCSI cable with connector capable of connecting to the Adaptec
Ultra Wide SCSI controller installed in the Celsius ..... computers.
• A new DDS2 DAT tape.
• The 1.44Mb 3.5” boot and root floppy disks see how to create disk at .....
if you do not have one
ee
@i
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 35

3.2.3.1 Backup Procedure


1. Verification

(a) If a redundant component is to be backed up, ensure the redundant


component is in error free operation.
(b) If a web4txp server is being backed up, ensure all web users have
been disconnected from that component.

2. Stopping OM system

(a) Login as txpom

rg
(b) enter the Om.Stop command.
(c) When the OM process has stopped, logout the txpom user.

3. Shutdown computer

(a) Login as root user e.o


(b) Shut down the OM650 system by entering the command “init 0 ”.
(c) When the system is completely shut down and is displaying the
prompt “It is safe to power off”, then turn the power off to the system.

4. Preparing Tape Drive

(a) With the power off on the DAT drive and the power off on the
ee
OM650 component, connect the DAT to the UWSCSI adapter us-
ing the UWSCSI cable.
(b) Set the SCSI id to 2 on the DAT drive.
(c) Power on the DAT drive.
@i

(d) Insert properly labeled DDS2 DAT tape in the DAT drive, ensure
the write protect tab is closed and wait till the DAT tape drive light
stops flashing.
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 36

5. Booting the computer

(a) Clean the floppy drive by blow of air through it - otherwise floppy
disk may be damaged or not work. Over years there is lot of dust in
floppy drive.
(b) Insert the boot floppy disk in to the floppy drive on the OM650
component.
(c) Turn on the OM650 component.
(d) When the boot prompt appears on the screen, press enter key once.
(e) When prompted, eject the boot floppy disk, insert the root floppy

rg
disk in the floppy drive and press the enter key.

6. Performing backup

(a) At the “#” prompt, type the command Txp.Backup.


(b) On completion of the restore procedure, ensure that there are no
e.o
error messages on the screen indicating bad sectors, bad tape etc.
The backup takes about 15 to 20 minutes
(c) It is advisable to see the content of the tape to make sure data were
written to it. Since tape archive is created by cpio command it is easy
to see it’s content by executing command cpio -ivt -I /dev/rStp0
- more on this command can be found in Bohemia Market knowl-
edge base under this link http://kb.bohemiamarket.com/index.
ee
php?title=Cpio
(d) Eject the DAT tape.

7. Powering computer back to normal operation

(a) Type the command haltsys.


@i

(b) Turn the power off to the Celsius computer and the DAT tape drive.
(c) Disconnect the UWSCSI cable from the computer.
(d) Apply power to the OM650 component and observe its successful
boot, OM start and synchronization.
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 37

Restore
Following a system restore, it is necessary to transfer the latest generated code
to the component before activating it within the operating infrastructure. In
most cases, the OM process automatically starts, so a special procedure has to
be put in place to ensure the newly restored component is isolated until it has
the latest code transferred.
Equipment required:
• External DDS2 or DDS3 DAT tape drive
• VGA monitor

rg
• PS2 Keyboard
• Ultra wide SCSI cable with connector capable of connecting to the Adaptec
Ultra Wide SCSI controller installed in the Celsius ..... computers.
• A new DDS2 DAT tape. e.o
• The 1.44Mb 3.5” boot and root floppy disks see how to create disk at .....
if you do not have one
ee
@i
ec
up
ro
3.2. C101 - PU - PROCESSING UNIT 38

3.2.3.2 Restore Procedure


1. Shutdown computer and power it off
2. Preparing Tape Drive

(a) With the power off on the DAT drive and the power off on the
OM650 component, connect the DAT to the UWSCSI adapter us-
ing the UWSCSI cable.
(b) Set the SCSI id to 2 on the DAT drive.
(c) Power on the DAT drive.

rg
(d) Insert latest backup tape, ensure the write protect tab is open
to avoid accidental deletion of the backup tape and wait till the
DAT tape drive light stops flashing.

3. Booting the computer


e.o
(a) Clean the floppy drive by blow of air through it - otherwise floppy
disk may be damaged or not work. Over years there is lot of dust in
floppy drive.
(b) Insert the boot floppy disk in to the floppy drive on the OM650
component.
(c) Turn on the OM650 component.
(d) When the boot prompt appears on the screen, press enter key once.
ee
(e) When prompted, eject the boot floppy disk, insert the root floppy
disk in the floppy drive and press the enter key.

4. Performing restore

(a) At the “#” prompt, type the command cd /


@i

(b) Type the command Txp.Restore.


(c) On completion of the restore procedure, ensure that there are no
error messages on the screen indicating bad sectors, bad tape etc.
The restore takes about 15 to 20 minutes
(d) Eject the DAT tape.
ec

(e) Type the command haltsys


(f) Power down the computer
up
ro
3.2. C101 - PU - PROCESSING UNIT 39

5. Post restoration procedure

(a) Disconnect any LAN and CS275 Local Bus cables that connect
to the OM650 component. This includes Terminal Bus connections,
Plant Bus connections, Web Bus connections and CS275 Local Bus
Connections.
(b) Stopping OM system if started
i. login as a txpom user
ii. During startup OM650 component will very likely start auto-
matically Om.Start process

rg
iii. Check this with the PL command
iv. Activate an Om.Stop
(c) Restoration of directory structure important to OM component
i.login as a root
ii.go to following directory: cd /usr/txpom/install.
iii.
iv.
v.
e.o
Now in this directory you can see the files Om.Install and Root.Install.
First run the Om.Install by ./Om.Install command.
After completion of the process run the Root.Install by ./Root.Install
command.
vi. Now again restart the server by init 6
(d) In case there were modifications of the OM related functions since
last backup it will be required to transfer of all required code to that
ee
component.
i. Stopping OM system if started
ii. login as a txpom user
iii. During startup OM650 component will very likely start auto-
matically Om.Start process
@i

iv. Check this with the PL command


v. Activate an Om.Stop
vi. An OT would require transfer of MMI, DynFup.
vii. A PU would require transfer of LAN, ASR, and Processing Func-
tions.
viii. A PU-ME would require transfer of ASR from GetOM.
ec

ix. A SU would require transfer of Prt, BDM


x. Under special circumstances other configurations may have to be
transferred or edited manually.
(e) When it is clear that the component is correctly configured, the sys-
tem can be shut down,
up

6. Putting computer back into service

(a) re-establish LAN connections


(b) switch on the computer
(c) Please check the server status on other server monitor by typing the
command PL –t (txpom login).
ro
3.2. C101 - PU - PROCESSING UNIT 40

3.2.4 Component Installation and Commissioning


The installation of new or repaired component is described in restoration section
of the backup see on page 37 and extensive documentation can be found in OEM
documentation. Most notably [100] - OM 650 Installation and Interfaces and
[101] - Device Manual System Components and Peripherals should be referred
to.

3.2.5 References
• 001 - Admin Report Sugen - July 2013

rg
• 100 - OM 650 Installation and Interfaces
• 101 - Device Manual System Components and Peripherals
• 902 - F36-MI-02 - Sugen procedure for daily maintenance
• 954 - MIG654 - Sugen Procedure for backing up OM components
e.o
ee
@i
ec
up
ro
3.3. C102 - SU - SERVER UNIT 41

3.3 C102 - SU - Server Unit


This chapter is addressing OM 650 component called Server Unit shortly known
under name SU. The pair of SUs in installed at each unit at power-plant. It is
addressing it from maintenance point of view.
Following is being addressed:
• Functional principles and component basic configuration
• Component Diagnostic and Routine maintenance
• Component Backup and Recovery principles

rg
• Component Installation and Commissioning

The processing unit is main interface between operator and automation level.
It’s main tasks are as follows:
• BDM - keep database of descriptions - translating internal system num-
e.o
bering called IKZ to human readable KKS and Descriptions
• LZA - Long term archive which is divided into two principal archives

– Circular archive keeping records for limited amount of the time on


hardisk
– Permanent archive on external media like MOD
ee
• PRT - access to archives, data searching
• NTB - notebook functionality

Figure 3.3.1: OM system status


@i
ec
up
ro
3.3. C102 - SU - SERVER UNIT 42

3.3.1 Functional principles and component basic configu-


ration
SU component file structure
The installation of OM 650 system is located in directories described below
• / –> this is Unix root of the file system

– /txpsys
∗ The executable programs of the OM software are located in this
directory or file system

rg
∗ There is defined system variable called $OmSys
– /txpsys/txpconf
∗ In this directory generic TXP configuration is located
∗ There is defined system variable called $OmConfData
– /txpproj/proj_std e.o
∗ In the txpproj directory or file system the engineering data are
stored (as for example the pictures for the MMI or the user-
specific network configuration data from ASR)
∗ There is defined system variable called $OmProjData
– /txptest
ee
∗ in the directory txptest the diagnostic files are located (error log
files), which are created by every OM subcomponent
∗ There is defined system variable called $OmDiagData
– /txpproz
∗ The process data (hard copies, notes, calculations) are stored in
@i

the directory txpproz


∗ There is defined system variable called $OmProzData

Each file system or directory mentioned above has a function-related organiza-


tion which is depending on the object managers installed on given OM compo-
nent.
ec

Figure 3.3.2: File structure of typical OM650 component


up

The directory structure of PU computer is as follows.


ro
3.3. C102 - SU - SERVER UNIT 43

• /root

– /txpsys
∗ /inf
∗ /asr
∗ /arc
∗ /mac
∗ /swi
– /txpproj/proj_std

rg
∗ /inf
∗ /asr
∗ /arc
∗ /mac
– /txptest



/inf
/asr
/arc
e.o
∗ /mac
– /txpproz
∗ /inf
ee
∗ /asr
∗ /arc
∗ /mac
@i
ec
up
ro
3.3. C102 - SU - SERVER UNIT 44

SU component configuration files


Infrastructure - INF For the configuration of the distributed OM system
infrastructure (INF) needs to be defined. Infrastructure is defined in following
files:
• InfOmk.proj
• InfFb.proj
• InfDevInst.proj
• InfObm.inst

rg
All these files are located in the directory $OmProjData/inf. Detailed descrip-
tion of infrastructure files can be found on page 17.

InfObm.inst The file InfObm.inst defines which OM subcomponents will run


of given computer.
e.o
This file is specific for each OM component.

Algorithm 3.6 Content of the InfObm.inst file at Sugen SU unit


#ObjMgr DirName
BDM bdm
LZA lza
PRT prt
ee
NTB ntb
@i
ec
up
ro
3.3. C102 - SU - SERVER UNIT 45

LZA In the engineering file Lza.proj only the function areas ids need to be
listed. These can be found at the ES680 database or at [000].

Algorithm 3.7 Content of the Lza.proj file at Sugen PU unit


# Lza . p r o j
# g l o b a l u s e r d a t a o f TXP−OM l o n g −t i m e a r c h i v e
#
# plant xx
# SU xx
# release xx
# date nn . nn . nnnn
#
#
# enumeration o f a l l f u n c t i o n a r e a s :
216 207 208 210 213 215 217
#

rg
#===============================================================================
#
# AnzAikz : maximum number o f u s e r −s p e c i f i e d IKZ
# A nzLi k z : maximum number o f ty pe −s p e c i f i e d IKZ
#
# PDA can o n l y p r o c e s s ( AnzAikz+A nzLi k z ) IKZ ’ s
#
# AnzEr : number o f e v e n t s a sub−a r c h i v e (PDA) can s t o r e
#
# ( AnzEr ) p a r a m e t e r v a l u e s h o u l d be much g r e a t e r t h a n ( AnzAikz+A nzLi k z ) ( b e t w e e n 5−20 t i m e s )
#
#
#
#
#
#
#
#
#
#
#
maximum s i z e o f a sub−a r c h i v e :
e.o
100 + ( AnzAikz+A nzLi k z ) ∗ 2 4 + AnzEr ∗ 44 B y te

s t a n d a r d p r o j e c t p l a n n i n g ( AnzAikz = 30000 , A nzLi k z = 70000 , AnzEr = 1000000)


r e q u i r e s d i s k s t o r a g e o f a b o u t 46 MB p e r sub−a r c h i v e

d i s k s t o r a g e r e q u i r e m e n t o f p r o c e s s d a t a a r c h i v e : ( AnzTa ) i n Lza . c o n f
( AnzTa + 1 ) ∗ s i z e o f sub−a r c h i v e + j o u r n a l i n g
d i s k s t o r a g e r e q u i r e m e n t f o r j o u r n a l i n g i n c r e a s e s w i t h run t i m e
and r e l o c a t i o n r a t e ( p r o c e s s d a t a and p r o t o c o l / f i l e s ) .
# r e a l c o n d i t i o n s w i l l h a r d l y r e q u i r e d i s k s t o r a g e o f more t h a n 50 MB.
#
# P L E A S E N O T I C E :
#
# I f you e n l a r g e b e l o w l i s t e d p a r a m e t e r s t h e PDA f i l e s y s t e m may o v e r f l o w .
# I n t h i s c a s e you s h o u l d r e d u c e p a r a m e t e r AnzTa i n Lza . c o n f .
ee
# A f t e r t h a t a c t i o n n o t n e e d e d sub−a r c h i v e s may be rem ov ed from f i l e s y s t e m .
# N o t i c e t h a t you t h e r e f o r e may l o o s e e v e n t s !
#
# I f you e n l a r g e ( AnzAikz+A nzLi k z ) , p a r a m e t e r ( ShmAnzEr ) i n LzaSp . c o n f
# s h o u l d be e n l a r g e d a s w e l l .
# E n l a r g e m e n t o f t h e s e p a r a m e t e r s i n c r e a s e s s h a r e d −memory r e q u i r e m e n t o f PDA !
#
#===============================================================================
AnzAikz 30000 # number o f u s e r −s p e c i f i e d e v e n t s
A nzLi k z 70000 # number o f ty pe −s p e c i f i e d e v e n t s
AnzEr 1000000 # s i z e of a changeable a r ch ive
EreigTypen 0xffff # event types to a rc hi v e
@i

# end Lza . p r o j

3.3.2 Component Diagnostic and Routine maintenance


When SU component starts failing proper diagnosis is required. Following some
most commons methods employed to detect which part of the system is failing
ec

to decide on proper corrective measures.

3.3.2.1 Routine maintenance


The routine maintenance of PU component is at Sugen described by the proce-
dure F36-MI-02 [902]
up

Evaluation of the computer is in detail described in reference [001]


• PL -t

– Check if all OM components are in operation


– All components must be if “fue” status or “akt” for hot standby
– Time must be synchronized
ro
3.3. C102 - SU - SERVER UNIT 46

Figure 3.3.3: OM system status

rg
• Pool /etc/dfspace

– Check for available disk space on all OM components


– Compare to the other systems one additional filesystem called /tx-
e.o
parc.00.00 is present - this is a location of all process files - this place
is NOT being backup by routine backup program

Figure 3.3.4: SU unit output of the /etc/dfspace command


ee

• Poll tail -7 /usr/lib/powerchute/*log


@i

– Check for UPS / Battery failure - check for error messages

• OmProj.Check

– This command is not required for daily use - only after OM reconfi-
garation and after updates
ec

– Verify OM configuration - check for any errors reported

• Evaluation of the file /txp/om650/txptest/DiagMeld* and subsequent er-


rors if any

– Diagnostic files are explained in detail below


up

– Rule of thumb say - if both of diagnostic files have very different


dates and error messages their content are very seldom system seems
to be in order.

• /var/adm

– This is a location system log files for which root access might be
required
ro
3.3. C102 - SU - SERVER UNIT 47

Figure 3.3.6: Screenshot from the SU-B server - system messages

rg
– verify system log files - syspages - see attachment No. 3 of the refer-
ence [001]
– Specially on SU needs to be clear that there are no errors on the
hardisk or MOD - see figure below for specific errors in system log
files. [110]
e.o
Figure 3.3.5: SU unit system log files indicates problems with storage media
ee
@i

• SAMPLER

– If any problems detected run SAMPLER - it will gather all log files
- MUST be done prior to any modifications!!!! It keeps history
ec

– Transfer SAMPLER to the safe location


up
ro
3.3. C102 - SU - SERVER UNIT 48

3.3.2.2 Diagnostic files


Each object manager writes error log files. In these files errors and messages
are stored as a report. All diagnostic files are located in the path /txptest.

• The infrastructure module writes directly into directory /txptest.


• Every other object manager writes into its respective subdirectory. For
example the ASR writes into /txptest/asr.
• The diagnostic files are realised via a cyclic buffer. First all diagnostic
messages are written into file DiagMld.0. If this file reaches a size greater

rg
than 1 MB, then the file DiagMld.1 is created. If this file also becomes
greater than 1 MB, then DiagMld.0 is deleted and created again. Thanks
to this mechanism, the hard disk will never be full and the latest diagnostic
data are always available.
• All diagnostic files are always built with a two line set.
e.o
– The date and time of the message are written in the first line, as well
as the program name, process id, module name, module version, line
number and function name.
– On the second line we can find the error message number and the
error message description.

• Unfortunately these diagnostic files have been written by devel-


ee
opers and for other developers. Therefore they are often very
difficult to understand.
To see content of the generic diagnostic file follow these steps.
• Login as txpom user
@i

• Navigate to the location of the log files by commend

– cd $OmTestData

• Check with the directory listing which diagnostic file is newer

– ls -la Dia*
ec

• Use tail command to see last, let’s say 30 lines of the file DiagMld.0

– tail -30 D*.0

Should find that some object manager is reporting many errors, lets say asr
up

than check diagnostic files of lza manager as follows.


• Login as txpom user
• Navigate to the location of the log files by commend

– cd $OmTestData
– cd lza
ro
3.3. C102 - SU - SERVER UNIT 49

• Check with the directory listing which diagnostic file is newer

– ls -la Dia*

• Use tail command to see last, let’s say 30 lines of the file DiagMld.1

– tail -30 D*.1

All unix commands mentioned in this section are explaned at Bohemia Market
knowledge base at http://kb.bohemiamarket.com/index.php?title=Category:Unix_command.

rg
e.o
ee
@i
ec
up
ro
3.3. C102 - SU - SERVER UNIT 50

3.3.2.3 Resetting and analyzing arc subsystem


Sometimes it happen that values are not shown on the display and log files.
Usual suspect is ARC subsystem.
The reset of ARC archive require to stop redundant computer and than to
stop it on master as well.

Computer a02p1a Computer a02p1b


The functions on this computer are in The functions on this computer are in
AKT which means computer acts as a FUE which means computer acts as an
redundant computer. master computer.

rg
• Step 1 - Stop OM (stopping • No action until OM stops on re-
this computer prevent synchro- dundant computer
nization) - Om.Stop
• Step 3 - Transfer ASR
• Step 2 - Transfer ASR
• Step 4 - ps -ef |grep Arc

computer
e.o
• Find ARC process on master

• Kill ARC process on master com-


• Step 5 - kill -9 1514
• Wait until a02p1a restarts (as a
root user) - init 6
puter
• Step 6 - Restart computer (as a • Step 7 - Restart computer
root user) - init 6
ee
• Wait until a02p1a restarts
• Step 8 - Arc.Moni should show
that ARC contain correct data
@i

Figure 3.3.7: Identify the process number - result of Step 4 commands


ec
up
ro
3.3. C102 - SU - SERVER UNIT 51

3.3.3 Component Backup and Recovery principles


The backup method used for processing computer is using OEM developed script
called Txp.Backup for backup purposes and Txp.Restore for restoration of the
component. This is fairly reliable procedure however should be noted that this
is logical type of the backup. Moreover !! this tools do not backup process
related data !!
There is a procedure at Sugen MIG654 [954] addressing this task.

Backup

rg
Equipment required:
• External DDS2 or DDS3 DAT tape drive
• VGA monitor
• PS2 Keyboard e.o
• Ultra wide SCSI cable with connector capable of connecting to the Adaptec
Ultra Wide SCSI controller installed in the Celsius ..... computers.
• A new DDS2 DAT tape.
• The 1.44Mb 3.5” boot and root floppy disks see how to create disk at .....
if you do not have one
ee
@i
ec
up
ro
3.3. C102 - SU - SERVER UNIT 52

3.3.3.1 Backup Procedure


1. Verification

(a) If a redundant component is to be backed up, ensure the redundant


component is in error free operation.
(b) If a web4txp server is being backed up, ensure all web users have
been disconnected from that component.

2. Stopping OM system

(a) Login as txpom

rg
(b) enter the Om.Stop command.
(c) When the OM process has stopped, logout the txpom user.

3. Shutdown computer

(a) Login as root user e.o


(b) Shut down the OM650 system by entering the command “init 0 ”.
(c) When the system is completely shut down and is displaying the
prompt “It is safe to power off”, then turn the power off to the system.

4. Preparing Tape Drive

(a) With the power off on the DAT drive and the power off on the
ee
OM650 component, connect the DAT to the UWSCSI adapter us-
ing the UWSCSI cable.
(b) Set the SCSI id to 2 on the DAT drive.
(c) Power on the DAT drive.
@i

(d) Insert properly labeled DDS2 DAT tape in the DAT drive, ensure
the write protect tab is closed and wait till the DAT tape drive light
stops flashing.
ec
up
ro
3.3. C102 - SU - SERVER UNIT 53

5. Booting the computer

(a) Clean the floppy drive by blow of air through it - otherwise floppy
disk may be damaged or not work. Over years there is lot of dust in
floppy drive.
(b) Insert the boot floppy disk in to the floppy drive on the OM650
component.
(c) Turn on the OM650 component.
(d) When the boot prompt appears on the screen, press enter key once.
(e) When prompted, eject the boot floppy disk, insert the root floppy

rg
disk in the floppy drive and press the enter key.

6. Performing backup

(a) At the “#” prompt, type the command Txp.Backup.


(b) On completion of the restore procedure, ensure that there are no
e.o
error messages on the screen indicating bad sectors, bad tape etc.
The backup takes about 15 to 20 minutes
(c) It is advisable to see the content of the tape to make sure data were
written to it. Since tape archive is created by cpio command it is easy
to see it’s content by executing command cpio -ivt -I /dev/rStp0
- more on this command can be found in Bohemia Market knowl-
edge base under this link http://kb.bohemiamarket.com/index.
ee
php?title=Cpio
(d) Eject the DAT tape.

7. Powering computer back to normal operation

(a) Type the command haltsys.


@i

(b) Turn the power off to the Celsius computer and the DAT tape drive.
(c) Disconnect the UWSCSI cable from the computer.
(d) Apply power to the OM650 component and observe its successful
boot, OM start and synchronization.
ec
up
ro
3.3. C102 - SU - SERVER UNIT 54

Restore
Following a system restore, it is necessary to transfer the latest generated code
to the component before activating it within the operating infrastructure. In
most cases, the OM process automatically starts, so a special procedure has to
be put in place to ensure the newly restored component is isolated until it has
the latest code transferred.
Equipment required:
• External DDS2 or DDS3 DAT tape drive
• VGA monitor

rg
• PS2 Keyboard
• Ultra wide SCSI cable with connector capable of connecting to the Adaptec
Ultra Wide SCSI controller installed in the Celsius ..... computers.
• A new DDS2 DAT tape. e.o
• The 1.44Mb 3.5” boot and root floppy disks see how to create disk at .....
if you do not have one
ee
@i
ec
up
ro
3.3. C102 - SU - SERVER UNIT 55

3.3.3.2 Restore Procedure


1. Shutdown computer and power it off
2. Preparing Tape Drive

(a) With the power off on the DAT drive and the power off on the
OM650 component, connect the DAT to the UWSCSI adapter us-
ing the UWSCSI cable.
(b) Set the SCSI id to 2 on the DAT drive.
(c) Power on the DAT drive.

rg
(d) Insert latest backup tape, ensure the write protect tab is open
to avoid accidental deletion of the backup tape and wait till the
DAT tape drive light stops flashing.

3. Booting the computer


e.o
(a) Clean the floppy drive by blow of air through it - otherwise floppy
disk may be damaged or not work. Over years there is lot of dust in
floppy drive.
(b) Insert the boot floppy disk in to the floppy drive on the OM650
component.
(c) Turn on the OM650 component.
(d) When the boot prompt appears on the screen, press enter key once.
ee
(e) When prompted, eject the boot floppy disk, insert the root floppy
disk in the floppy drive and press the enter key.

4. Performing restore

(a) At the “#” prompt, type the command cd /


@i

(b) Type the command Txp.Restore.


(c) On completion of the restore procedure, ensure that there are no
error messages on the screen indicating bad sectors, bad tape etc.
The restore takes about 15 to 20 minutes
(d) Eject the DAT tape.
ec

(e) Type the command haltsys


(f) Power down the computer
up
ro
3.3. C102 - SU - SERVER UNIT 56

5. Post restoration procedure

(a) Disconnect any LAN and CS275 Local Bus cables that connect
to the OM650 component. This includes Terminal Bus connections,
Plant Bus connections, Web Bus connections and CS275 Local Bus
Connections.
(b) Stopping OM system if started
i. login as a txpom user
ii. During startup OM650 component will very likely start auto-
matically Om.Start process

rg
iii. Check this with the PL command
iv. Activate an Om.Stop
(c) Restoration of directory structure important to OM component
i.login as a root
ii.go to following directory: cd /usr/txpom/install.
e.o
iii.Now in this directory you can see the files Om.Install and Root.Install.
iv. First run the Om.Install by ./Om.Install command.
v. After completion of the process run the Root.Install by ./Root.Install
command.
vi. Now again restart the server by init 6
(d) In case there were modifications of the OM related functions since
ee
last backup it will be required to transfer of all required code to that
component.
i. Stopping OM system if started
ii. login as a txpom user
iii. During startup OM650 component will very likely start auto-
matically Om.Start process
@i

iv. Check this with the PL command


v. Activate an Om.Stop
vi. A SU would require transfer of Prt, BDM
vii. Under special circumstances other configurations may have to be
transferred or edited manually.
ec

(e) When it is clear that the component is correctly configured, the sys-
tem can be shut down,

6. Putting computer back into service

(a) re-establish LAN connections - ONLY when all activities terminated


up

(b) switch on the computer


(c) Please check the server status on other server monitor by typing the
command PL –t (txpom login).
(d) In case of SU unit synchronization can take many hours -
be patient do EVER NOT INTERUPT process !!!!!
ro
3.3. C102 - SU - SERVER UNIT 57

3.3.4 Component Installation and Commissioning


The installation of new or repaired component is described in restoration section
of the backup see on page 54 and extensive documentation can be found in OEM
documentation. Most notably [100] - OM 650 Installation and Interfaces and
[101] - Device Manual System Components and Peripherals should be referred
to.

3.3.5 References
• 000 - Cheat Sheet

rg
• 001 - Admin Report Sugen - July 2013
• 100 - OM 650 Installation and Interfaces
• 101 - Device Manual System Components and Peripherals
• 110 - SU problem - hardisk failure
• 111 - broken ARC subsystem
e.o
• 902 - F36-MI-02 - Sugen procedure for daily maintenance
• 954 - MIG654 - Sugen Procedure for backing up OM components
ee
@i
ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 58

3.4 C103 - HMI Server - web4txp


This chapter is addressing OM 650 component called HMI Unit shortly known
under name OT or HMI Server. The HMI servers are non-redundant computers.
However any web4txp is giving access to complete HMI system. It is addressing
it from maintenance point of view.
Following is being addressed:
• Functional principles and component basic configuration
• Component Diagnostic and Routine maintenance

rg
• Component Backup and Recovery principles
• Component Installation and Commissioning
The HMI server is responsible to process operator related screens, accessing
log files and archives and giving operator control over the plant. The Sugen
configuration allows to access all functionality of the HMI sever via Internet
e.o
Explorer from windows TC (Thin Client) computer.
ee
@i
ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 59

3.4.1 Functional principles and component basic configu-


ration
Web4TXP component file structure
The installation of OM 650 system is located in directories described below.
• / –> this is Unix root of the file system

– /txpsys
∗ The executable programs of the OM software are located in this
directory or file system

rg
∗ There is defined system variable called $OmSys
– /txpsys/txpconf
∗ In this directory generic TXP configuration is located
∗ There is defined system variable called $OmConfData
– /txpproj/proj_std e.o
∗ In the txpproj directory or file system the engineering data are
stored (as for example the pictures for the MMI or the user-
specific network configuration data from ASR)
∗ There is defined system variable called $OmProjData
– /txptest
∗ in the directory txptest the diagnostic files are located (error log
ee
files), which are created by every OM subcomponent
∗ There is defined system variable called $OmDiagData
– /txpproz
∗ The process data (hard copies, notes, calculations) are stored in
the directory txpproz
@i

∗ There is defined system variable called $OmProzData


– /txp/web
∗ For web4txp system there is a directory where web server users,
applications, access control etc. is configured

Each file system or directory mentioned above has a function-related organiza-


tion which is depending on the object managers installed on given OM compo-
ec

nent.

Figure 3.4.1: File structure of typical OM650 component


up
ro
3.4. C103 - HMI SERVER - WEB4TXP 60

The directory structure of HMI computer is as follows.


• /root

– /txpsys
∗ /inf
∗ /asr
∗ /arc
∗ /mac
∗ /swi

rg
– /txpproj/proj_std
∗ /inf
∗ /asr
∗ /arc
∗ /mac
– /txptest


/inf
/asr
e.o
∗ /arc
∗ /mac
– /txpproz
ee
∗ /inf
∗ /asr
∗ /arc
∗ /mac
@i

– /txp/web
ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 61

HMI component configuration files


Infrastructure - INF For the configuration of the distributed OM system
infrastructure (INF) needs to be defined. Infrastructure is defined in following
files:
• InfOmk.proj
• InfFb.proj
• InfDevInst.proj
• InfObm.inst

rg
All these files are located in the directory $OmProjData/inf. Detailed descrip-
tion of infrastructure files can be found on page 17.

InfObm.inst The file InfObm.inst defines which OM subcomponents will run


of given computer.
e.o
This file is specific for each OM component.

Algorithm 3.8 Content of the InfObm.inst file at Sugen PU unit


#ObjMgr DirName
ASR asr
ARC arc
MAC mac
ee
w4.Install.Para This is a file where configuration of the web4txp system is
performed. The most common task performed is adding new user to the web4txp
system, It is described in next chapter.
@i
ec
up
ro
Add new user to web4txp
system

rg
Sagunto - May 14, 2007 Adding new user into web4txp system is straight
forward. Here is how to achieve this task:
1. Login to the web4txp system as root user in order to get right to create
e.o
new users
2. Add new user into unix system see algorithm 3.9 on the next page for
more details.
3. Create password for newly created users1 by command:

(a) passwd office1


ee
(b) choose option number 1
(c) type new password and confirm it

4. Edit file /txp/web/install/w4.Install.Para

(a) add line for each additional user into the OM_USER section see
@i

figure 3.4.2 on the following page.


(b) add line for each additional thin client (computer) into the OM_CLIENT
section see figure 3.4.3 on the next page.
(c) if desired than add similar information for the ES680 station - ES_USER
section to add application name and user name – see figure 3.4.4 on
page 64.
ec

(d) if desired than add similar information for the ES680 station - ES_APPL
section to add IP address and login for given user – see figure 3.4.5
on page 64.

5. Run the configuration script ./w4.config in directory /txp/web/install/


up

(a) choose option number 6 (set up web4txp server database)

1 example is for the user called office1


ro

62
3.4. C103 - HMI SERVER - WEB4TXP 63

Algorithm 3.9 Adding new user into unix system

useradd -u 8007 -g 8000 -G web4txp -d /txp/web/users/office1 -m -s /bin/csh office1


| | | | | | |
| | | | | | +---> system name of the added user
| | | | | +---> Name of the shell
| | | | +---> create user directory
| | | +---> place of the home directory
| | +---> name of user group (check the file /etc/groups )
| +---> number of user group (check the file /etc/groups )
+---> userid (uid) system number -- for TXP system is used > 8000
(see /etc/passwd for next free number)

rg
Figure 3.4.2: Edit OM_USER section – add for each user application name

e.o
ee
@i

Figure 3.4.3: Edit OM_CLIENT section – add for each computer the line with
IP address and user name which will be used
ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 64

Figure 3.4.4: Edit ES_USER section – add for each user application name

rg
e.o
ee

Figure 3.4.5: Edit ES_APPL section – add for each computer the line with IP
@i

address and user name which will be used


ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 65

3.4.2 Component Diagnostic and Routine maintenance


When HMI component starts failing proper diagnosis is required. Following
some most commons methods employed to detect which part of the system is
failing to decide on proper corrective measures.

3.4.2.1 Routine maintenance


The routine maintenance of HMI component is at Sugen described by the pro-
cedure F36-MI-02 [902]
Evaluation of the computer is in detail described in reference [001]

rg
• PL -t

– Check if all OM components are in operation


– All components must be if “fue” status or “akt” for hot standby
– Time must be synchronized
e.o
Figure 3.4.6: OM system status
ee
@i

• Pool /etc/dfspace

– Check for available disk space on all OM components

Figure 3.4.7: PU unit output of the /etc/dfspace command


ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 66

• Poll tail -7 /usr/lib/powerchute/*log

– Check for UPS / Battery failure - check for error messages

• OmProj.Check

– This command is not required for daily use - only after OM recon-
figuration and after updates
– Verify OM configuration - check for any errors reported

• Evaluation of the file /txp/om650/txptest/DiagMeld* and subsequent er-

rg
rors if any

– Diagnostic files are explained in detail below


– Rule of thumb say - if both of diagnostic files have very different
dates and error messages their content are very seldom system seems
to be in order.

• /var/adm
e.o
– This is a location system log files for which root access might be
required
– verify system log files - syspages - see attachment No. 3 of the refer-
ence [001]
ee
• SAMPLER

– If any problems detected run SAMPLER - it will gather all log files
- MUST be done prior to any modifications!!!! It keeps history
– Transfer SAMPLER to the safe location
@i
ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 67

3.4.2.2 Diagnostic files


Each object manager writes error log files. In these files errors and messages
are stored as a report. All diagnostic files are located in the path /txptest.
• The infrastructure module writes directly into directory /txptest.
• The diagnostic files are realized via a cyclic buffer. First all diagnostic
messages are written into file DiagMld.0. If this file reaches a size greater
than 1 MB, then the file DiagMld.1 is created. If this file also becomes
greater than 1 MB, then DiagMld.0 is deleted and created again. Thanks
to this mechanism, the hard disk will never be full and the latest diagnostic

rg
data are always available.
• All diagnostic files are always built with a two line set.

– The date and time of the message are written in the first line, as well
as the program name, process id, module name, module version, line
e.o
number and function name.
– On the second line we can find the error message number and the
error message description.

• Unfortunately these diagnostic files have been written by devel-


opers and for other developers. Therefore they are often very
difficult to understand.
To see content of the generic diagnostic file follow these steps.
ee
• Login as txpom user
• Navigate to the location of the log files by commend

– cd $OmTestData
@i

• Check with the directory listing which diagnostic file is newer

– ls -la Dia*

• Use tail command to see last, let’s say 30 lines of the file DiagMld.0

– tail -30 D*.0


ec

Should find that some object manager is reporting many errors, lets say asr
than check diagnostic files of asr manager as follows.
• Login as txpom user
up

• Navigate to the location of the log files by commend

– cd $OmTestData
– cd asr

• Check with the directory listing which diagnostic file is newer

– ls -la Dia*
ro
3.4. C103 - HMI SERVER - WEB4TXP 68

• Use tail command to see last, let’s say 30 lines of the file DiagMld.1

– tail -30 D*.1

All unix commands mentioned in this section are explained at Bohemia Market
knowledge base at http://kb.bohemiamarket.com/index.php?title=Category:Unix_command

rg
e.o
ee
@i
ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 69

3.4.3 Component Backup and Recovery principles


The backup method used for processing computer is using OEM developed script
called Txp.Backup for backup purposes and Txp.Restore for restoration of the
component. This is fairly reliable procedure however should be noted that this
is logical type of the backup.
There is a procedure at Sugen MIG654 [954] addressing this task.

Backup
Equipment required:

rg
• External DDS2 or DDS3 DAT tape drive
• VGA monitor
• PS2 Keyboard
e.o
• SCSI cable with connector capable of connecting to the Adaptec Ultra
Wide SCSI controller installed in the Celsius ..... computers.

• A new DDS2 DAT tape.


• The 1.44Mb 3.5” boot and root floppy disks see how to create disk at .....
if you do not have one
ee
@i
ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 70

3.4.3.1 Backup Procedure


1. Verification

(a) If a redundant component is to be backed up, ensure the redundant


component is in error free operation.
(b) If a web4txp server is being backed up, ensure all web users have
been disconnected from that component.

2. Stopping OM system

(a) Login as txpom

rg
(b) enter the Om.Stop command.
(c) When the OM process has stopped, logout the txpom user.

3. Shutdown computer

(a) Login as root user e.o


(b) Shut down the OM650 system by entering the command “init 0 ”.
(c) When the system is completely shut down and is displaying the
prompt “It is safe to power off”, then turn the power off to the system.

4. Preparing Tape Drive

(a) With the power off on the DAT drive and the power off on the
ee
OM650 component, connect the DAT to the UWSCSI adapter us-
ing the UWSCSI cable.
(b) Set the SCSI id to 2 on the DAT drive.
(c) Power on the DAT drive.
@i

(d) Insert properly labeled DDS2 DAT tape in the DAT drive, ensure
the write protect tab is closed and wait till the DAT tape drive light
stops flashing.
ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 71

5. Booting the computer

(a) Clean the floppy drive by blow of air through it - otherwise floppy
disk may be damaged or not work. Over years there is lot of dust in
floppy drive.
(b) Insert the boot floppy disk in to the floppy drive on the OM650
component.
(c) Turn on the OM650 component.
(d) When the boot prompt appears on the screen, press enter key once.
(e) When prompted, eject the boot floppy disk, insert the root floppy

rg
disk in the floppy drive and press the enter key.

6. Performing backup

(a) At the “#” prompt, type the command Txp.Backup.


(b) On completion of the restore procedure, ensure that there are no
e.o
error messages on the screen indicating bad sectors, bad tape etc.
The backup takes about 15 to 20 minutes
(c) It is advisable to see the content of the tape to make sure data were
written to it. Since tape archive is created by cpio command it is easy
to see it’s content by executing command cpio -ivt -I /dev/rStp0
- more on this command can be found in Bohemia Market knowl-
edge base under this link http://kb.bohemiamarket.com/index.
ee
php?title=Cpio
(d) Eject the DAT tape.

7. Powering computer back to normal operation

(a) Type the command haltsys.


@i

(b) Turn the power off to the Celsius computer and the DAT tape drive.
(c) Disconnect the SCSI cable from the computer.
(d) Apply power to the OM650 component and observe its successful
boot, OM start and synchronization.
ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 72

Restore
Following a system restore, it is necessary to transfer the latest generated code
to the component before activating it within the operating infrastructure. In
most cases, the OM process automatically starts, so a special procedure has to
be put in place to ensure the newly restored component is isolated until it has
the latest code transferred.
Equipment required:
• External DDS2 or DDS3 DAT tape drive
• VGA monitor

rg
• PS2 Keyboard
• SCSI cable with connector capable of connecting to the Adaptec Ultra
Wide SCSI controller installed in the Celsius ..... computers.
• A new DDS2 DAT tape. e.o
• The 1.44Mb 3.5” boot and root floppy disks see how to create disk at .....
if you do not have one
ee
@i
ec
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 73

3.4.3.2 Restore Procedure


1. Shutdown computer and power it off
2. Preparing Tape Drive

(a) With the power off on the DAT drive and the power off on the OM650
component, connect the DAT to the SCSI adapter using the UWSCSI
cable.
(b) Set the SCSI id to 2 on the DAT drive.
(c) Power on the DAT drive.

rg
(d) Insert latest backup tape, ensure the write protect tab is open
to avoid accidental deletion of the backup tape and wait till the
DAT tape drive light stops flashing.

3. Booting the computer


e.o
(a) Clean the floppy drive by blow of air through it - otherwise floppy
disk may be damaged or not work. Over years there is lot of dust in
floppy drive.
(b) Insert the boot floppy disk in to the floppy drive on the OM650
component.
(c) Turn on the OM650 component.
(d) When the boot prompt appears on the screen, press enter key once.
ee
(e) When prompted, eject the boot floppy disk, insert the root floppy
disk in the floppy drive and press the enter key.

4. Performing restore

(a) At the “#” prompt, type the command cd /


@i

(b) Type the command Txp.Restore.


(c) On completion of the restore procedure, ensure that there are no
error messages on the screen indicating bad sectors, bad tape etc.
The restore takes about 15 to 20 minutes
(d) Eject the DAT tape.
ec

(e) Type the command haltsys


(f) Power down the computer
up
ro
3.4. C103 - HMI SERVER - WEB4TXP 74

5. Post restoration procedure

(a) Disconnect any LAN that connect to the OM650 component. This
includes Terminal Bus connections, Plant Bus connections, Web Bus
connections.
(b) Stopping OM system if started
i. login as a txpom user
ii. During startup OM650 component will very likely start auto-
matically Om.Start process
iii. Check this with the PL command

rg
iv. Activate an Om.Stop
(c) Restoration of directory structure important to OM component
i.login as a root
ii.go to following directory: cd /usr/txpom/install.
iii.
iv.
v.
e.o
Now in this directory you can see the files Om.Install and Root.Install.
First run the Om.Install by ./Om.Install command.
After completion of the process run the Root.Install by ./Root.Install
command.
vi. Now again restart the server by init 6
(d) In case there were modifications of the OM related functions since
last backup it will be required to transfer of all required code to that
ee
component.
i. Stopping OM system if started
ii. login as a txpom user
iii. During startup OM650 component will very likely start auto-
matically Om.Start process
@i

iv. Check this with the PL command


v. Activate an Om.Stop
vi. An OT would require transfer of MMI, DynFup.
vii. Check web4txp configuration
viii. Under special circumstances other configurations may have to be
transferred or edited manually.
ec

(e) When it is clear that the component is correctly configured, the sys-
tem can be shut down,

6. Putting computer back into service

(a) re-establish LAN connections


up

(b) switch on the computer


(c) Please check the server status on other server monitor by typing the
command PL –t (txpom login).
ro
3.4. C103 - HMI SERVER - WEB4TXP 75

3.4.4 Web4TXP system licensing


Customer is having five web4txp licenses. However licensing did not worked
properly. It has been found that there is a need to correct number of OT
licenses in the file /txp/web/web4txp/etc/w4_applparam.cfg
Also following conditions needs to be met:
1. correct licensing file WEB4TXP.LIC
2. Correct number of the license files in the directory /usr/DyxLic

3.4.5 Component Installation and Commissioning

rg
The installation of new or repaired component is described in restoration section
of the backup see on page 72 and extensive documentation can be found in OEM
documentation. Most notably [100] - OM 650 Installation and Interfaces and
[101] - Device Manual System Components and Peripherals should be referred
to.

3.4.6 References
e.o
• 001 - Admin Report Sugen - July 2013
• 100 - OM 650 Installation and Interfaces
• 101 - Device Manual System Components and Peripherals
ee
• 141 - TXP manual describing web4txt installation
• 142 - Installing web4txp server
• 902 - F36-MI-02 - Sugen procedure for daily maintenance
• 954 - MIG654 - Sugen Procedure for backing up OM components
@i

3.4.7 References
103 - OM650 transfer and engineering
ec
up
ro
Chapter 4

C201 - ES 680 - Engineering

rg
Station
e.o
This chapter is addressing Engineering Station known under the name ES 680.
The Engineering Station contain central database for complete DCS system
accompanied with set of maintenance tools. It Also contains graphical editor of
MMI system called OM 650 editor alias Dynavis.
There is one engineering station per power-plant unit. This chapter is ad-
dressing ES 680 from maintenance point of view.
Following is being addressed:
ee
• Principles and component basic configuration
• Component Diagnostic and Routine maintenance
• Component Backup and Recovery principles
• Component Installation and Commissioning
@i
ec
up
ro

76
77

4.0.8 Functional principles and component basic configu-


ration
Engineering station principal function is to configure all components of DCS
system called T2000 at one single place. There three principal functions of the
ES 680.
1. Configure networking for Automation processors and create a programs
on automation level
2. Create HMI interface like operator screen

rg
3. Maintain generated code and configuration files and allows their transfers

4.0.9 ES 680 User interface


The user interface is well described in the reference from TXP manual located
in the directory “200 - ES 680 User interface”.

4.0.10
e.o
ES 680 component file structure
The installation of ES 680 system is fairly complex and it’s configuration require
very deep knowledge of the Unix system, Ingres database system and knowledge
of complete ES 680 software package. Such a knowledge is beyond possibility
of this course (it would take several days to explain all). The installation TXP
manual can be found at reference directory “202 - ES 680 installation instruc-
ee
tions”.
Therefore only directories important to maintenance are being addressed
here and proper disaster recovery planning is being put in the place.
The most important directory from maintenance point of view are:
• $HOME directory of main database user
@i

• /save directories where automated night backup is located


ec
up
ro
78

ES 680 component configuration files


4.0.11 Component Diagnostic and Routine maintenance
4.0.11.1 Routine maintenance
Unit Tape cron_sicherung.prot dbrepair.prot dbrepair_result.prot nachtlauf.prot sperrdatei df -h
10 OK errors errors OK empty OK
20 OK errors errors OK empty OK
30 OK errors errors OK empty OK

rg
• Check backup directories

– cd /save

• Database checks - Data consistency errors - should be minimum amount


of them ... normally fixed by maintenance scripts.

– Check 52 - 70 errors
– Check 200 - 16 errors
e.o
• Check for the errors in cron_sicherung.prot

– Check for lines starting with E_ –> ingres problems. Solve immedi-
ately!
ee
• sperdatei

– This file MUST be empty

• Check the need for code generation


@i

– No generation needed

• Check the need for code transfer

– No download needed

• Check for the need of LAN transfer


ec

– The LAN transfer required


∗ a01wt1
∗ AP192
up

• Available disk-space. Important is /tmp directory. If full more than 50%


than problem with printer.

– df -h
ro
79

4.0.12 Component Backup and Recovery principles


Since ES680 is central depository of the project there are two different types of
backup requirements:

1. Engineering data backup - Daily, Weekly or in any other regular period


of time as per site needs
2. Computer file system (operating system and software installed on the com-
puter) backup
There is a procedure at Sugen MIG654 [954] addressing this task.

rg
4.0.13 Disk Backup Procedure
Equipment required:
• External DDS2 or DDS3 DAT tape drive

• VGA monitor
• PS2 Keyboard
e.o
• SCSI cable with connector capable of connecting to the ES680 computer
• A new DDS2 DAT tape.

Shutdown of the ES680


ee
1. Make sure all clients have been logged out of the ES680 (command: finger).
If they are not, and they have an application that opens the database, you
run the risk of corrupting the database when the ES680 is shutdown....
deep shit man!
@i

2. Log into HP Vue as root and open a terminal session.


3. Use command:

(a) shutdown –h –y 0

4. To restart the HP Machine, substitute the –h switch with –r


ec

5. The HP machine will then shutdown. It takes a bit of time so be patient.


up
ro
80

Primary Disk Root Backup


1. Make sure that the DAT tape you have matches the DAT Streamer you
are using. Normally they are backward, but not forward compatible. At
minimum you should be using DDS2 Tapes.
2. DAT Streamer must be on channel 3 (OM650 uses channel 2).
3. Connect the DAT Streamer with the 50 pin SCSI cable
4. Power up the DAT Streamer then HP machine.
5. Boot into Single User mode by pressing the esc key during the Boot up

rg
sequence (best to press the esc key as soon as you turn the HP box on).
6. Press enter at the prompt (don’t know why, just need to!).
7. Boot the system by:

(a) boot fwscsi6.0 pri

pa to find out).
e.o
(b) bo pri , providing the primary boot path is fwscsi.6.0 (use command

i. Answer “Y” to “Interact With IPL”.


ii. You will get the prompt ISL> (ISL is Initial System Loader).
iii. Load the HP Unix bootstrap: hpux –is (-is means boot into
single user mode).

8. Once booted in Single User mode


ee
(a) Change to the / (root) directory at the # prompt by command (If
you don’t do this, the entire root file system will not be backed up.
Only the file system you are in will be backed up)
i. cd /
@i

(b) Insert cleaner tape into DAT Streamer.


i. Insert DDS tape into DAT Streamer (green LED stops flashing
when DAT is fully loaded).
(c) Start backup
i. tar cv ‘ls –1‘
A. tar cv means create a new archive (c), and verbose (v) the
ec

archived files.
B. ‘ls –1‘ means list the files in a single column format.
(d) Check for error messages when completed
(e) Check that the backup procedure worked by command
up

i. tar –t |tail –50

9. Shutdown the HP machine command:

(a) shutdown –h –y 0
(b) Remove the DAT Streamer.

10. Let it Boot it into Multi User mode.


ro
81

Primary Disk Restore From DAT Tape


This is a last resort method, and all other fixes should be attempted before
doing a full ES680 restore.
There is a good chance that the code on the restored ES680 will differ from
that in the AS system. You may require a full offline download if there is
not reliable project backup. All files on the ES680 will be removed, and then
restored.
1. Make sure that the DAT tape you have matches the DAT Streamer you
are using. Normally they are backward, but not forward compatible. At
minimum you should be using DDS2 Tapes.

rg
2. DAT Streamer must be on channel 3 (OM650 uses channel 2).
3. Connect the DAT Streamer with the 50 pin SCSI cable
4. Power up the DAT Streamer then HP machine.
e.o
5. Boot into Single User mode by pressing the esc key during the Boot up
sequence (best to press the esc key as soon as you turn the HP box on).
6. Press enter at the prompt (don’t know why, just need to!).
7. Boot the system by using secondary booting option (remember your disk
is damaged)1

(a) bo sescsi.3.0 isl, or o bo sec , providing the secondary boot path is


ee
sescsi.3.0 (use command pa to find out).
(b) Answer “N” to “Interact With IPL”.
(c) A basic system installation will commence.
(d) The system will reboot several times. This is normal. When complete
the HPVue login screen will appear.
@i

(e) Login with root (no password will be required).


(f) Change to the root directory command:
i. cd /
(g) Put the DAT Tape into the DAT Streamer.
(h) Start the tape restoration by:
ec

i. tar xv
(i) Check for error messages.
(j) Shutdown the HP machine (command:
i. shutdown –h –y 0
up

(k) Remove the DAT Streamer.


(l) Let it Boot it into Multi User mode.

8. If project data changed since last backup there is a need to recover com-
plete project.

1 This may differ on model number


ro
82

ES680 Overnight Run


Scope of the Overnight Saving Procedure
The current versions of ES680 provide automatic saving of the plant data con-
figured each night. Automatic overnight saving currently covers three areas:
• The ES680 project database
• MMI data (OM path)
• Generated code for AP’s

rg
Configuration
The overnight run requires some project-specific and machine-related data in
order to properly carry out it’s task. These data are provided via the configu-
ration file. Any measure to adapt automatic overnight saving should be carried
out by the administrator at the master machine exclusively, preferably keeping
e.o
in mind the initial notes on administrative activities.
Path for the configuration files: /install/txpes/data/<Project>/dba Also, in
this path those logs are stored which are generated by the scripts and programs
being executed during the night.
ES680 Overnight Run Call-up of the overnight saving procedure To carry
out time-delayed call-up of the overnight run, Cron call-ups are set under UNIX.
This is done by using the crontab command, which can be used to transfer such
call-ups to the cron. The time response (starting time of the individual tools)
ee
is stored in a file, which is activated using crontab.
File with the path: /install/txpes/data/<Project>/txpes.cron This file is
automatically regenerated or overwritten on each update to a new ES680 ver-
sion. If additional sections for the overnight run should be stored there, an addi-
tional copy of the configuration file should be set up (e.g. txpes.cron.<project>).
@i

Verification Verify content of safe directories and daily logs.


ec
up
ro
83

Crontab modification
In alg. 4.2 on the next page is described how to set-up automatic tape backup.2

Algorithm 4.1 Crontab modification for night backup.


1. Make a copy of the existing crontab
crontab -l > crontab.list

The content of the file will look like this:


0 0 * * 1,3,5 /txp/es680/txpes/sw/sw7.4.SCO/bin/cron_nachtlauf.sh asir09
/txp/es680/txpes /txp/es680 u
0 0 * * 0,2,4,6 /txp/es680/txpes/sw/sw7.4.SCO/bin/cron_nachtlauf.sh asir09

rg
/txp/es680/txpes /txp/es680 g

Above mentioned are TXP routines installed from Germany.


2. To make tape backup add following to the end of the file crontab.list :
15 3 * * * /usr/bin/tar cvf /dev/rStp0 /save

At 3:15 morning cron program will run tar command and copy data from
e.o
the /save directory to the tape.
Used command tar cf instead of tar cvf to eliminate amount of messages
in mail. In Asir have to be modified.
3. Update cron program by the file crontab.list
crontab < crontab.list

4. Verify cron program by command


ee
crontab -l

The another possibility is to edit crontab by the command crontab -e .


2 This description is applicable to the SCO unix version. The HP version has some differ-
@i

ences in tape device names.


ec
up
ro
84

Tape verification
PLEASE VERIFY TAPE BEFORE YOU INSERT NEW ONE - see alg. 4.2 for
more details. What can be said about the output? Watch the dates of the files
located in /save/save1 and /save/save2 directories and their sub-directories which
to be same as dates of directories on the hardisk.

Algorithm 4.2 Tape verification


1. Start xterminal
2. Enter command

rg
tar tv |grep save

3. Watch the command output


rw-rw-r--3000/2000 4778 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/lz_614.mc5
rw-rw-r--3000/2000 5716 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/lz_apf.mc5
rw-rw-r--3000/2000 3798 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/meld.mc5
rw-rw-r--3000/2000 318 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/meld_aus.mc5
e.o
rw-rw-r--3000/2000 2668 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/neustart.mc5
rw-rw-r--3000/2000 246 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/ob001.mc5
rw-rw-r--3000/2000 158 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/ob019.mc5
rw-rw-r--3000/2000 142 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/ob020.mc5
rw-rw-r--3000/2000 158 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/ob021.mc5
rw-rw-r--3000/2000 158 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/ob022.mc5
rw-rw-r--3000/2000 354 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/ob023.mc5
rw-rw-r--3000/2000 354 May 09 00:00 2005 /save/save1/bisha05/as/ag0011/mc5/ap/system/ob024.mc5
rw-rw-r--3000/2000 0 Mar 23 20:03 2005 /save/save2/tahad_10/om_asr_0.tah
rw-rw-r--3000/2000 212208 Mar 23 20:03 2005 /save/save2/tahad_10/obj_link.tah
rw-rw-r--3000/2000 0 Mar 23 20:03 2005 /save/save2/tahad_10/ombez_cp.tah
rw-rw-r--3000/2000 0 Mar 23 20:03 2005 /save/save2/tahad_10/om_ver.tah
ee
rw-rw-r--3000/2000 0 Mar 23 20:03 2005 /save/save2/tahad_10/om_asr_b.tah
rw-rw-r--3000/2000 0 Mar 23 20:03 2005 /save/save2/tahad_10/om_asr_1.tah
rw-rw-r--3000/2000 0 Mar 23 20:03 2005 /save/save2/tahad_10/pd_proj.tah
rw-rw-r--3000/200017698286 Mar 23 20:03 2005 /save/save2/tahad_10/pic_d.tah
rw-rw-r--3000/2000 82722 Mar 23 20:03 2005 /save/save2/tahad_10/pic_w.tah
rw-rw-r--3000/2000 0 Mar 23 20:03 2005 /save/save2/tahad_10/pic_r.tah
rw-rw-r--3000/20002497800 Mar 23 20:03 2005 /save/save2/tahad_10/pic_p.tah
rw-rw-r--3000/2000 72700 Mar 23 20:03 2005 /save/save2/tahad_10/pr_w.tah
rw-rw-r--3000/2000 64046 Mar 23 20:03 2005 /save/save2/tahad_10/pr_m.tah
@i

rw-rw-r--3000/2000 0 Mar 23 20:03 2005 /save/save2/tahad_10/users.tah


rw-rw-r--3000/2000 22788 Mar 23 20:03 2005 /save/save2/tahad_10/s5_apf_s.tah
rw-rw-r--3000/2000 261401 Mar 23 20:03 2005 /save/save2/tahad_10/regel.tah
rw-rw-r--3000/20002923500 Mar 23 20:03 2005 /save/save2/tahad_10/msk_g.tah
rw-rw-r--3000/2000 46944 Mar 23 20:03 2005 /save/save2/tahad_10/pic_kana.tah
ec
up
ro
85

Rebuild TXP database from night run save


This procedure should only be carried out following very deep thought and if
there is no other way to fix it. Many factors should be taken into consideration
and other options may be considered.
The database backup must be available

4.0.14 Database restore procedure


1. Logon to the system where the database resides as the project adminis-
trator

rg
2. Ensure that no other users are logged into that project locally or remotely.
3. Stop the project related services by changing directory to

(a) cd $HOME/config/esMonitor

4. and entering the command

(a) esMonitor.sh stop


e.o
5. Destroy the current database by typing

(a) destroydb <project name>


(b) Create and empty database by typing
i. createdb –d<project name> <project name>
ee
(c) Change to the save directory that holds the required backup Type
i. reload.ing
(d) Reboot the system

4.0.15 Component Installation and Commissioning


@i

The installation of new or repaired component is described in restoration section


of the backup see on page 92 and extensive documentation can be found in OEM
documentation. Most notably [100] - OM 650 Installation and Interfaces and
[101] - Device Manual System Components and Peripherals should be referred
to.
ec

4.0.16 References
• 001 - Admin Report Sugen - July 2013
• 200 - ES 680 User interface
• 201 - ES680 manuals from TXP manual - how to use
up

• 202 - ES 680 installation instructions


• 203 - ES680 creating users
• 902 - F36-MI-02 - Sugen procedure for daily maintenance
• 954 - MIG654 - Sugen Procedure for backing up OM components
ro
Chapter 5

C202 - DS 670 - Diagnostic

rg
station
e.o
This chapter is addressing DS 650 server shortly known under name Diagnostic
Station. It is being addressed from maintenance point of view.
Following is being addressed:
• Functional principles and component basic configuration
• Component Diagnostic and Routine maintenance
ee
• Component Backup and Recovery principles
• Component Installation and Commissioning
@i
ec
up
ro

86
5.1. FUNCTIONAL PRINCIPLES AND COMPONENT BASIC
CONFIGURATION 87

5.1 Functional principles and component basic


configuration
There is very good TXP manual page which we will be following in this section.
See reference “250 - DS 670 interface” for functional description of the DS 670.

5.2 Starting and stopping DS 670


There is very good TXP manual describing step by step how to start and stop
diagnostic station functions. See reference “251 - Stopping and Starting DS670”

rg
and installation of the DS 670 is described in “253 - DS 670 installation”.

5.3 Daily use of DS670


DS 670 is great help for I&C department. If checked daily and errors acknowl-

system of the complete T2000.


e.o
edge daily as shown below than it could be detected in no time what is a current

Figure 5.3.1: Common acknowledge function


ee
@i
ec
up

The diagnostic of particular components can be see in the reference directory


“252 - Components diagnostic”
ro
5.4. COMPONENT DIAGNOSTIC AND ROUTINE MAINTENANCE 88

5.4 Component Diagnostic and Routine mainte-


nance
When DS 670 component starts failing proper diagnosis is required. Following
some most commons methods employed to detect which part of the system is
failing to decide on proper corrective measures.

5.4.1 Routine maintenance


The routine maintenance of DS670 component is at Sugen described by the
procedure F36-MI-02 [902]

rg
Evaluation of the computer is in detail described in reference [001] - however
should be noted that DS 670 point out any error experiencing with itself .
• Poll tail -7 /usr/lib/powerchute/*log

– Check for UPS / Battery failure - check for error messages

• /var/adm
e.o
– This is a location system log files for which root access might be
required
– verify system log files - syspages - see attachment No. 3 of the refer-
ence [001]
ee
@i
ec
up
ro
5.5. BACKUP 89

5.4.2 Component Backup and Recovery principles


The backup method used for processing computer is using OEM developed script
called Txp.Backup for backup purposes and Txp.Restore for restoration of the
component. This is fairly reliable procedure however should be noted that this
is logical type of the backup.
There is a procedure at Sugen MIG654 [954] addressing this task.

5.5 Backup
Equipment required:

rg
• External DDS2 or DDS3 DAT tape drive
• VGA monitor
• PS2 Keyboard
e.o
• SCSI cable with connector capable of connecting to the Adaptec Ultra
Wide SCSI controller installed in the Celsius ..... computers.

• A new DDS2 DAT tape.


• The 1.44Mb 3.5” boot and root floppy disks see how to create disk at .....
if you do not have one
ee
@i
ec
up
ro
5.5. BACKUP 90

5.5.1 Backup Procedure


1. Stopping DS670

(a) Follow the procedure described at “251 - Stopping and Starting DS670”

2. Shutdown computer

(a) Login as root user


(b) Shut down the DS 670 system by entering the command “init 0 ”.
(c) When the system is completely shut down and is displaying the

rg
prompt “It is safe to power off”, then turn the power off to the system.

3. Preparing Tape Drive

(a) With the power off on the DAT drive and the power off on the DS
670 component, connect the DAT to the SCSI adapter using the SCSI
cable. e.o
(b) Set the SCSI id to 2 on the DAT drive.
(c) Power on the DAT drive.
(d) Insert properly labeled DDS2 DAT tape in the DAT drive, ensure
the write protect tab is closed and wait till the DAT tape drive light
stops flashing.
ee
@i
ec
up
ro
5.5. BACKUP 91

4. Booting the computer

(a) Clean the floppy drive by blow of air through it - otherwise floppy
disk may be damaged or not work. Over years there is lot of dust in
floppy drive.
(b) Insert the boot floppy disk in to the floppy drive on the DS 670
station.
(c) Turn on the DS 670 station.
(d) When the boot prompt appears on the screen, press enter key once.
(e) When prompted, eject the boot floppy disk, insert the root floppy

rg
disk in the floppy drive and press the enter key.

5. Performing backup

(a) At the “#” prompt, type the command Txp.Backup.


(b) On completion of the restore procedure, ensure that there are no
e.o
error messages on the screen indicating bad sectors, bad tape etc.
The backup takes about 15 to 20 minutes
(c) It is advisable to see the content of the tape to make sure data were
written to it. Since tape archive is created by cpio command it is easy
to see it’s content by executing command cpio -ivt -I /dev/rStp0
- more on this command can be found in Bohemia Market knowl-
edge base under this link http://kb.bohemiamarket.com/index.
ee
php?title=Cpio
(d) Eject the DAT tape.

6. Powering computer back to normal operation

(a) Type the command haltsys.


@i

(b) Turn the power off to the Celsius computer and the DAT tape drive.
(c) Disconnect the SCSI cable from the computer.
(d) Apply power to the DS 670 station and start it as described at “251
- Stopping and Starting DS670”.
ec
up
ro
5.6. RESTORE 92

5.6 Restore
Following a system restore, it is necessary to transfer the latest generated code,
topology diagram and OM infrastructure.
Equipment required:
• External DDS2 or DDS3 DAT tape drive
• VGA monitor
• PS2 Keyboard

rg
• SCSI cable with connector capable of connecting to the Adaptec Ultra
Wide SCSI controller installed in the Celsius ..... computers.

• A new DDS2 DAT tape.


• The 1.44Mb 3.5” boot and root floppy disks see how to create disk at .....
if you do not have one
e.o
ee
@i
ec
up
ro
5.6. RESTORE 93

5.6.1 Restore Procedure


1. Stopping DS670

(a) Follow the procedure described at “251 - Stopping and Starting DS670”

2. Shutdown computer

(a) Login as root user


(b) Shut down the DS 670 system by entering the command “init 0 ”.
(c) When the system is completely shut down and is displaying the

rg
prompt “It is safe to power off”, then turn the power off to the system.

3. Preparing Tape Drive

(a) With the power off on the DAT drive and the power off on the DS
670 component, connect the DAT to the SCSI adapter using the SCSI
cable. e.o
(b) Set the SCSI id to 2 on the DAT drive.
(c) Power on the DAT drive.
(d) Insert properly labeled DDS2 DAT tape in the DAT drive, ensure
the write protect tab is closed and wait till the DAT tape drive light
stops flashing.
ee
4. Booting the computer

(a) Clean the floppy drive by blow of air through it - otherwise floppy
disk may be damaged or not work. Over years there is lot of dust in
floppy drive.
(b) Insert the boot floppy disk in to the floppy drive on the DS 670
@i

component.
(c) Turn on the DS 670 component.
(d) When the boot prompt appears on the screen, press enter key once.
(e) When prompted, eject the boot floppy disk, insert the root floppy
disk in the floppy drive and press the enter key.
ec

5. Performing restore

(a) At the “#” prompt, type the command cd /


(b) Type the command Txp.Restore.
(c) On completion of the restore procedure, ensure that there are no
up

error messages on the screen indicating bad sectors, bad tape etc.
The restore takes about 15 to 20 minutes
(d) Eject the DAT tape.
(e) Type the command haltsys
(f) Power down the computer
ro
5.6. RESTORE 94

6. Post restoration procedure

(a) Disconnect any LAN that connect to the OM650 component. This
includes Terminal Bus connections, Plant Bus connections, Web Bus
connections.
(b) Follow manuals “253 - DS 670 installation” and “251 - Stopping and
Starting DS670” for details what specific steps are required
(c) When it is clear that the component is correctly configured, the sys-
tem can be shut down,

7. Putting computer back into service

rg
(a) re-establish LAN connections
(b) switch on the computer

e.o
ee
@i
ec
up
ro
5.7. DS 670 SYSTEM LICENSING 95

5.7 DS 670 system licensing


5.8 Component Installation and Commissioning
The installation of new or repaired component is described in restoration sec-
tion of the backup and extensive documentation can be found in OEM docu-
mentation. Most notably reference from TXP manual located at “253 - DS 670
installation” is describing in great detail how to configure and commission DS
670 computer.

5.8.1 References

rg
• 001 - Admin Report Sugen - July 2013
• 100 - OM 650 Installation and Interfaces
• 101 - Device Manual System Components and Peripherals
• 250 - DS 670 interface
e.o
• 251 - Stopping and Starting DS670
• 252 - Components diagnostic
• 253 - DS 670 installation
• 954 - MIG654 - Sugen Procedure for backing up OM components
ee
@i
ec
up
ro
Chapter 6

C300 - OSM - Managed

rg
network switch
e.o
OSM is managed network witch and it is central part of all networks present
at the T2000 system. The brief description of the module can be seen at the
reference “300 - Ethernet network ring structure - OSM module” and OSM
manual “301 - OSM module manual”

6.1 References
ee
• 300 - Ethernet network ring structure - OSM module
• 301 - OSM module manual
@i
ec
up
ro

96
Chapter 7

C400 - AP 620 - Automation

rg
Processor
e.o
This chapter is addressing Automation Processor shortly AP. The AP is part of
T2000 hardware on which automation tasks are being executed. This chapter
is addressing AP 620 from maintenance point of view and it includes case study
of small hardware modification. This modification is addressing all aspects of
such a task.
Following is being addressed:
• Principles and component basic configuration
ee
• Component Diagnostic and Routine maintenance
• Component Backup and Recovery principles
• Component Installation and Commissioning
@i

This section will be carried as follows:


• Location: Training center

– The explanation of the configuration of the T2000 hardware, I/O


system
ec

∗ There will be case study adding analog signal to the system and if
time allow brief description of the binary signal will be discussed
∗ After HW configuration SW part of the signal adding will be
explained
∗ And finaly code and pbp card will be generated
up

• Location: PCC

– Physical implementation and examples


∗ How to program field devices
∗ How to deal with physical hardware
∗ Explanation of various tyoes of hardware
ro

97
98

• Location: MCR - Main Control Room

– Practical implementation of case study by students


– Will be dedicated to the diagnostic such a
∗ Simulations
∗ Dynamisation
∗ DS 670 tool

rg
e.o
ee
@i
ec
up
ro
7.1. FUNCTIONAL PRINCIPLES AND COMPONENT BASIC
CONFIGURATION 99

7.1 Functional principles and component basic


configuration
Hardware structure of AP and it’s hardware is shown below. From the software
point of view AP is PLC with preloaded standard libraries which are being
centrally configured by means of the engineering station.

Figure 7.1.1: Typical structure of the AP processor

rg
e.o
ee
Figure 7.1.2: Physical AP rack
@i
ec
up
ro
7.2. MAINTENANCE 100

7.2 Maintenance
There is an TXP maintenance manual “401 - Maintenance of AS620”.

rg
e.o
ee
@i
ec
up
ro
7.3. COMPONENT BACKUP AND RECOVERY PRINCIPLES 101

7.3 Component Backup and Recovery principles


All data in regards of the AS 620 are located on the ES 680 station. Therefore
recovery involves good backup procedures of the ES 680 and changing hardware
parts if neccessary.

7.4 Components Installation and Commissioning


- Case study
As always there is detailed manual available. However to make any sence of

rg
there is best to perform some real example.
During case study error occured and IM 308 module did not started after
programming memory card has been programmed. After studying manual “408
- AS 620 commissioninf and error description” it has been found that card needs
to be deleted prior programming.
e.o
ee
@i
ec
up
ro
7.5. BURN NEW IM308 FLASH CARD 102

Figure 7.4.1: Page from TXP manual describing the errors status LEDs of the
IM 308 card

rg
e.o
ee
@i
ec

7.5 Burn New IM308 Flash Card


7.5.1 General Info:
• This process can be done with the AP online providing:
up

– You are careful,


– You know what you’re doing,
– There are REDUNDANT AP’s, and
– That the Redundancy Fail-over works on the AP rack.
– Make sure the IM308 is in STOP and POWERED OFF when ever
you INSERT or REMOVE a Flash card!!
ro
7.5. BURN NEW IM308 FLASH CARD 103

7.5.2 When IM608 card should be programmed


• If you:

– Change any of the ET200 I/O types (i.e. from 0-10V to 4-20mA etc.
etc, etc).
– Add new ET200 stations etc, etc, etc.
– Delete any of the ET200 stations or I/O etc, etc, etc.

• Sometimes if you change a channel from T/C to RTD you also may have
to burn a new Flash Card.

rg
• If you’re just adding/deleting a signal in TXP to an existing (configured)
ET200 card, then this “Flashing” malarkey isn’t required.

7.5.3 What You Need:


e.o
• PG with Flash Card slot in it.
• PG running ComProfibus (make sure you have the correct licences in-
stalled).
• Flash Card from IM308.
• USB memory stick to get data from ES680 (could also use a Floppy Disk)
or do it over ftp
ee
7.5.4 Get IM308 Data From ES680:
• Make sure a full HW Generation has been done first!!
• On the ES680 menu:
@i

– “Generators” => “Select AP” => “Create ET200 Memory Card


Files” => Enter “AP” number.
– Check for generation errors etc. If there are errors and you continue
with burning the flash card you run the risk of damaging plant and
causing havoc!!
ec

• The new ET200 file is located at:

– $HOME/listen/as/ag0<AP #>/transfer/...
– The file will be called A00<AP #>_<Bus #>.pbp (e.g. A0021_1.pbp)

• Copy the *.pbp file over to a HMI server (using FTP) so you can copy it
up

onto your USB memory stick:

– Cmd: cd $HOME/listen/as/ag0<AP #>/transfer to the */trans-


fer/... directory detailed above,
– Cmd: ftp <HMI server name> (use PL –t to find the HMI server
name) (e.g. ftp se_hmi1).
– Login as the necessary user (usually user txpom),
ro
7.5. BURN NEW IM308 FLASH CARD 104

– Cmd: binary (to make the transfer mode as binary, instead of ASCii),
– Cmd: put A00<AP #>_<Bus #>.pbp (this puts the *.pbp file onto
the HMI server),
– Cmd: close (closes the connection to the HMI server),
– Cmd: bye (shuts down the FTP program).

• Retrieve the *.pbp file from the HMI server:

– Put your Memory Stick into the HMI server (it should be a Windows
machine),

rg
– Navigate to the txpom users home directory (or just do a search fro
the *.pbp file),
– Send it to the USB stick,

7.5.5 Burn The New Flash Card:


• Start ComProfibus on the PG,
e.o
• Import the *.pbp file using ComProfibus:

– “File” => “Import” => “ASCII Data” => select correct drive =>
select the *.pbp file
– The imported file should be displayed showing the ET200 chain (re-
view and make sure it’s correct for the installation).
ee
• Burn the card:

– Put the Flash card into the slot in the PG,


– Click the Head Station so it’s highlighted,
@i

– Click the Flash Button (one with the lightening bolt on it),
– Memory card will be written to.

• Final Touches:

– With the IM308 in STOP and Powered OFF, insert the new Flash
Card.
ec

– Turn the power ON and put the IM308 into RUN.

7.5.6 Problem/Solutions:
• No communication with the ET200 station:
up

– Incorrect station address (DIP switches) on IM153.


– Bus cable not ok.
– Wires (Red/Green) are switched or broken.
– End terminating resistor is not installed.

• IM308 showing “BF” (Bus Fault) or “IF” (Interface Fault):


ro
7.6. REFERENCES 105

– Incorrect station address (DIP switches) on IM153.


– Bus cable not ok.
– Wires (Red/Green) are switched or broken.
– End terminating resistor is not installed.
– IM153 has no power supply.
– ET200 not mounted as per Topology Diagram.
– ET200 module may have faulted.

• File import errors on the PG:

rg
– PG config files (gsd, gse, master etc) are missing from the PG740.
– File not transferred properly from the ES680.
– Check end of each section for incomplete lines of 0x0. Need to correct
with “Notepad” to make them 0x0.

7.6 References
e.o
• 401 - Maintenance of AS620 - excerpt from the TXP manual addressing
errors
• 402 - AS maintenance training
ee
• 404 - TXP maintenance - AS620 - complete TXP manual instruction
• 405 - profibus
• 406 - programming memory card
• 408 - AS 620 commissioninf and error description
@i
ec
up
ro
Chapter 8

C450 - CM - Communication

rg
module
e.o
This chapter is addressing CM communication module. The CM module is used
for communication with foreign systems. This chapter is addressing AP 620 from
maintenance point of view and it includes demonstration of the configuration of
the CM module.
Following is being addressed:
• Principles and component basic configuration
ee
• Component Diagnostic and Routine maintenance
• Component Backup and Recovery principles
• Component Installation and Commissioning
This section will be carried as follows:
@i

• Location: Training center

– The explanation of the configuration of the CM module hardware


and explanation

• Location: PCC
ec

– Physical backup of the CM module configuration file


up
ro

106
8.1. FUNCTIONAL PRINCIPLES AND COMPONENT BASIC
CONFIGURATION 107

8.1 Functional principles and component basic


configuration
CM module is a PC computer running DRDOS operating system and consist
of two principal parts (1) TXP part which is responsible for communication
with TXP system and (2) foreign system part which in implementation of the
required protocol. The setup of the CM module is implemented via means of
the CM.INI file.

Figure 8.1.1: CM 104 drawing

rg
e.o
ee
@i

There is a procedure for transfering CM.ini file described at “451 - Commu-


nication to CM module - transfer CM.ini”.
ec
up
ro
8.1. FUNCTIONAL PRINCIPLES AND COMPONENT BASIC
CONFIGURATION 108

Algorithm 8.1 Example of CM.ini configuration file with modbus configuration


;-------------------------------------------
;
; CM104 Modbus Configuration File
;
; Hardware with 4 serial ports (Serial 1 to 4)
;-------------------------------------------

;-------------------------------------------
; Remote Terminal Interface (Serial 1)

[OPERATE]
Hardware=CM104
Baudrate=57600 (default)
;Baudrate=115200
PortAdr=0x3f8
Irq=4
RtsCts=2
; Dataframe is fix (8-N-1)

rg
;-------------------------------------------
;Redundanzverbindung on (Serial 2)

;[SYNCHRONISATION]
;PortAdr=0x2f8
;Irq=3
;Baudrate=115200
; Dataframe is fix (8-N-1)

;-------------------------------------------

[H1]
SubUnit=Single
;Exclude=08.00.06.05.31.41
;Mac=08.00.06.13.21.11
Mac =08.00.06.00.00.92
ApCmTimeout=20

;-------------------------------------------
e.o
;Modbus Slave (Serial 2)
;U7: EP RAPPER SYTSEM RED. A

[ModbusSlave_1]
PortAdr=0x2f8 ; SERIAL 2
Irq=3 ; SERIAL 2
Baudrate=19200
ee
Parity=None
StopBits=1
DataBits=8

Slave=1
Timeout=5000

;Offset for each Function Code

;Read Coil Status Code 1


; base address = 1
@i

;RCS-Offset = -1
RCS-Offset = 0

;Read Input Status Code 2


RIS-Offset = -10001

;Read Holding Register Code 3


; base address = 40001
;RHR-Offset = -40001
RHR-Offset = 0

;Read Input Register Code 4


ec

RIR-Offset = -30001

;Force Single Coil Code 5


; base address = 1
FSC-Offset = -1

;Preset Single Register Code 6


; base address = 40001
PSR-Offset = -40001

;-------------------------------------------
; Display an identification string
up

[DISPLAY]
Info=CM92_TO_SHOAIBAH2

;-------------------------------------------
; Enable the CM104 log-files

[ErrorLog]
TestMode=0
Diagnostic=1

;-------------------------------------------
;End of configuration file
ro
8.1. FUNCTIONAL PRINCIPLES AND COMPONENT BASIC
CONFIGURATION 109

Algorithm 8.2 Example of CM.ini configuration file with IEC 60870 protocol
;-------------------------------------------
;
; CM104 IEC60870-5-104 on TCP/IP Configuration File
;
; Hardware with 4 serial ports (Serial 1 to 4) an 2 Ethernet ports
; Serial 1 is used as operating interface
; Serial 2 is reserved for redundancy link in case of redundant cm solution
; for non redundant CM this interface can be used to connect also a Modbus device
; Serial 3 not used
; Serial 4 not used
;-------------------------------------------

;Note:
;Unnecessary blocks, parameters and comments must be commented out by ; at the beginning of a line

;--------- Serial operating terminal / remote terminal on SERIAL 1 ---------------------


[OPERATE]
Hardware =CM104

rg
PortAdr =0x3F8
Irq =4
RtsCts =2
Baudrate =57600 ;the default Baudrate is 57600 baud unless otherwise specified - data frame is fixed (8-N-1)
;-----------------------------------------------------

;-------- Redudancy Connection on SERIAL 2 -----------


[SYNCHRONISATION]
PortAdr =0x2F8
Irq =3
RtsCts =2 e.o
Baudrate =115200 ;the default Baudrate is 115200 baud unless otherwise specified - data frame is fixed (8-N-1)
;------------------------------------------------------

;--------- Plant bus specific configuration -----------------------------------


[H1]

SubUnit=B ;Specify whether the CM is non-redundant or part (A or B) of a


;redundant machine. Here non-redundant mode has been specified.
;SubUnit=Single
;SubUnit=A
;SubUnit=B
ee
Mac =08.00.06.05.31.12 ;The MAC address of the CM ( see: node setup)
;This is an example of an Ethernet address (MAC address) typical of TXP

Exclude =08.00.06.05.31.41 ; Here the MAC address of the DS670 of TELEPERM XP conntected to the plant bus must be
; specified. This is an example of an address.

ApCmTimeout =10 ;Specify the maximum time in seconds that may pass without data having been received
;and before the CM signals a failure of the AP-CM connection.
;If no time is specified twice the configured receive cycle time is used.
@i

;After expiration of the ApCmTimeout the process image of the AP is deleted as well.

;SaveEsFiles =2 ;SaveEsFiles=2 causes seq-files received from the ES to be saved on the Flash. This
;setting has a major impact on the time response and therefore may be used for testing purposes only

NoTimersStamp =1 ;if NoTimeStamp=1 all time tags are generated in the CM. No time tags
;will be taken over. If you change the setting you again need to
;transfer the configuration to the CM.
ec

; --------- Info String ----------------------------------------------------------


[DISPLAY]
Info =CM104_UNIT_B_IEC60870_5_104_TCP/IP ;Display/info about the display of a string in HMI.
;(The first blank marks the end of the string)

;---------- Error logging -----------------------------------------------


[ErrorLog]
FileSize =40000 ;FileSize specifies the maximum size of the files ErrLog01.txt and ErrLog02.TXT in bytes
up

TestMode =1 ;If TestMode=1 has been specified, no alarms will be written into the file Errlog01.txt and ErrLog02.txt

;Diagnostic =1 ;Errors detected during the runtime are saved in the file
;ErrLog01.txt and ErrLog02.txt on the Flash during error logging.
;Logging may only be activated during the commissioning phase since
;each write access to the Flash will have a major impact on the real-time
;response of the system. Active error logging may result in sporadic
;faults of the H1 communication!

;---------- Subsystem connection Settings ------------------------------------------


ro

;-------------------------------------------
; CM-PC Configuration File
;
;-------------------------------------------
;adress from cm104
[TCP/IP]
ip = 140.80.10.53
netmask = 255.255.255.0
;router = 192.168.255.2
hops = 42
;-------------------------------------------

;-------------------------------------------
[IEC]
RED_MODE = 3
;-------------------------------------------

;-------------------------------------------
8.2. MAINTENANCE 110

8.2 Maintenance
8.3 Component Backup and Recovery principles
All engineering data in regards of the CM module are located on the ES 680
station. Therefore recovery involves good backup procedures of the ES 680 and
changing hardware parts if neccessary. However there is a configuration file
CM.ini which is essential for proper function of the CM module and therefore
as such must be backed up.

rg
8.4 References
• 450 - CM modules - TXP manual collection
• 451 - Communication to CM module - transfer CM.ini

e.o
ee
@i
ec
up
ro
Chapter 9

C490 - 95F - protection

rg
system
e.o
This chapter is addressing 95F - protection system. It is not addressing 95F
engineering nor exact configuration of this processor. It is addressing typical
maintenance task as debuging during the startup. It is explaining function of
particular trip circuits and adding some important information as documented
on various sites.
Finally practical use of the COM 95 software is being demonstrated.
Following is being addressed:
ee
• Turbine protection system principles
• Discussion about particular trip circuits like

– overspeed protection system


– TXP protection circuits *EZ* diagrams
@i

• Practical use of the COM 95 software is being demonstrated


This section will be carried as follows:
• Location: Training center
ec

– The explanation of the protection system as described above

• Location: PCC

– Physical use of COM 95F software


up
ro

111
9.1. ON-THE-JOB TRAINING
PROTECTION SYSTEM AND TXP COMMUNICATION 112

9.1 On-the-Job training


Protection system and TXP communication
9.1.1 Control and protection systems brief description
The gas turbine control and protection system contain the following subsystems:
• Gas Turbine governor (SIMADYN)
• DCS control system (TXP680)
• Protection system (95F)

rg
• Startup Frequency Controller and Static excitation unit (SFC)
• Unit protection
• OM system (OM650)
e.o
• Auxiliary diagnostic sub-systems

– WIN_TS (turbine stress monitoring)


– Flight recorder (fault recorder)

9.1.2 Gas Turbine governor (SIMADYN)


This subsystem is responsible for load and speed control of the turbine.
ee
9.1.3 DCS control system (TXP680)
This system is responsible for:
• Communication between subsystems
@i

– SFC system
– 95F protection system
– Ball valves control system
– Communication to GE system over modbus
ec

– Simadyn communication
– OM650 subsystem

• Open loop control


• Collecting I/O signals
up

• Motor logic
ro
9.1. ON-THE-JOB TRAINING
PROTECTION SYSTEM AND TXP COMMUNICATION 113

9.1.4 Protection system (95F)


This system is responsible for safe operation of the machine and its protection
if critical values are reached:

• Hardware based over-speed protection


• Software based over-speed protection
• Flame monitoring
• Manual turbine trip1

rg
• Fire protection trips2
• Surge protection
• Unit protection
• Protection circuit (protection signals coming from TXP system)
e.o
If conditions are in boundaries the protection system allow:
• opening ESV3 valves
• permission to open Ignition Valves
It is necessary to remind you that “Protection System” never initiates any
startup commands. All commands are given by TXP system and releases to
ee
manipulate outputs are given if process values are in safe boundaries.

9.1.5 Startup Frequency Controller and Static excitation


unit (SFC)
This sub-system is responsible for:
@i

• machine startup
• generator excitation

9.1.6 Unit protection


ec

This sub-system is responsible for electrical protection of generator.

9.1.7 OM system (OM650)


This system is interface for humans (MMI - Man Machine Interface) and it is
made of the following sub-systems:
up

• OT - Operation Terminal - this function is sometimes called MMI


• PU - Process unit - this unit is responsible for:
1 Redbuttons
2 Bluebuttons
3 Emergency Shut-off Valve
ro
9.1. ON-THE-JOB TRAINING
PROTECTION SYSTEM AND TXP COMMUNICATION 114

– Communication to the AP’s (Automation processor). This function


is called ASR
– Short term data storage
– Long term data storage - LZA
– Process calculation - calculation of running hours, counters
– Description database - BDM - Assigning KKS and Description to all
system tags

• ES - Engineering station - here is stored all configuration for AP’s and only
place where such configuration can be modified. This station is available

rg
via OM menu.
When ES and PU are running on one computer then this computer is called CU
(Compact Unit). Both computers are processing data is parallel. Only one com-
puter is executing command and is called “Master”. In case of “Master” failure
the computer called “Slave” become “master” and continue in operation - this
e.o
make smooth operation possible. No data will be lost or operation interrupted.
ee
@i
ec
up
ro
9.2. SYSTEMS INTERCONNECTION 115

9.2 Systems interconnection

Figure 9.2.1: Schematic interconnection of the systems - Please note that this
is ONLY schematic and plant configuration must not be exactly the same as
shown in this diagram. Exact plant configuration is shown in topology diagram
which can be found in appendix.

rg
e.o
ee
@i
ec
up
ro
9.2. SYSTEMS INTERCONNECTION 116

Figure 9.2.2: Topology Diagram - Network Infrastructure

rg
e.o
ee
@i
ec
up
ro
9.3. DISTRIBUTION OF THE SYSTEMS OVER CABINETS 117

9.3 Distribution of the systems over cabinets

Table 9.1: Distribution of the systems in cabinets


Cabinet System
05CJR01 Gas Turbine governor (SIMADYN), Flight
recorder, Plant clock
05CJP01 DCS control system (TXP680) AP11
05CJP01 DCS control system (TXP680) AP12
05CJP02 DCS control system (TXP680) AP13

rg
05CJP02 Communication center, modbus interfaces
05CJP41 Protection system (95F)
05CJQ01 Over-speed protection, flame detectors, vibration
sensors interface, flow computers
05CJT01 SFC and excitation unit
05CHA01/02 Unit protection

9.4
05CPA01~03
e.o
ET200 station, DCS I/O system

Protection system description in detail


1. Hardware based over-speed protection
2. Software based over-speed protection
ee
3. Flame monitoring
4. Manual turbine trip4
5. Fire protection trips5
6. Surge protection
@i

7. Unit protection
8. Protection circuit (protection signals coming from TXP system)

9.4.1 Hardware based over-speed protection


ec

There are two sets of the O/S (over-speed) protection.


The set on the top consists of three input conditioners Braun E1518 and
three relays Braun E1553 together with external relay logic shown below. This
set is called hardware based over-speed protection.
After energization or trip it is necessary to press button T2 which will en-
ergize relays BA75.1 and BA83.1 and BA91.1. If there is no trip then relays
up

BA75.3 and BA83.3 and BA91.3 get energized and over diodes will energize
BA75.2 and BA83.2 and BA91.2 which will make sure that relays relays BA75.3
and BA83.3 and BA91.3 stay energized after button T2 is released. If any chan-
nel is tripped then appropriate relay Baxx.3 get de-energized and will generate
signal XK6x over its contact.
4 Red buttons
5 Blue buttons
ro
9.4. PROTECTION SYSTEM DESCRIPTION IN DETAIL 118

Example:
Cause:
• MBA10CS102 XK61 trip

Effect :
• Relay BA83.3 will lost supply and will de-energize
• Signal XK62 will be set to “0”
The speed signals are controlling directly relays K2, K3, K6 and K7 in the 95F

rg
cabinet and together with the K1 and K5 are forming hardware based O/S
protection of the turbine. If relays K2, K3, K6 and K7 get de-energize then
power supply for the solenoid valves of the ESV valves lost energy and those as
such close.
The set on the button is performing software based O/S protection and its

processed accordingly.
e.o
outputs are going directly to the 95F system where they are evaluated and

Table 9.2: List of sensors for hardware based over-speed protection


KKS Note
05MBA10CS101
05MBA10CS102
ee
05MBA10CS103

9.4.1.1 Over-speed system diagnostic


The system is containing two frequency simulators for diagnostic. Each sim-
ulator is emulating the “TRIP” speed and “NOT TRIP” speed. All tests are
@i

managed by the 95F system and any discrepancy cause trip of the turbine and
failure of O/S system test.
If any sensor of three in each set is not working properly then test will not
be invoked and test will not be completed.

9.4.1.2 O/S system “REAL” test


ec

During the commissioning “over-speed” test was conducted which is made by


setting trip speed to 700rpm and machine is started up by SFC to the washing
speed and on 700rpm must be tripped.
up
ro
9.4. PROTECTION SYSTEM DESCRIPTION IN DETAIL 119

Figure 9.4.1: Schematic of hardware over-speed

rg
e.o
ee
@i
ec
up
ro
9.4. PROTECTION SYSTEM DESCRIPTION IN DETAIL 120

Table 9.3: List of sensors for software based over-speed protection


KKS Note
05MBA10CS104
05MBA10CS105
05MBA10CS106

9.4.2 Software based over-speed protection


There are two sets of the O/S (over-speed) protection.
The set on the bottom consists of three input conditioners Braun E1518 and

rg
three relays Braun E1553. Output of these signals is send directly to the 95F
as binary inputs.

9.4.3 Flame monitoring


Flame monitoring system make sure that there is not injected fuel into com-
e.o
bustion chamber without being burned. If both flame detectors detect “NO
FLAME” in either combustion chamber than ESV valves will be closed.

Table 9.4: List of sensors for flame monitoring


KKS Note
05MBM11CR101/102 Signal processing modules are located in cabinet 05CJQ01
05MBM21CR101/102 Signal processing modules are located in cabinet 05CJQ01
ee
9.4.4 Manual turbine trip
The manual trip buttons “yellow” are located all around the plant and in central
control room. There are slight differences of the system behavior if is tripped
@i

by “yellow” or “blue” button. Please refer to the operating manual for more
details. All buttons also contain signal which indicate on TXP system the exact
location of the button pressed.

Table 9.5: List of buttons for manual turbine trip


KKS Note
ec

05MYBGS020A/B All buttons are in serie, thus only two signals are generated; each
button contain three signals - one is used for location identification.

9.4.5 Fire protection trips


up

System can be tripped by:


• Fire alarm system in case of fire detection
• Manually by pressing “blue” button - buttons are located all around the
plant and in main control room
ro
9.5. PROTECTION SYSTEM REDUNDANCY AND RELIABILITY 121

Table 9.6: List of fire alarm trip signals


KKS Note
Blue buttons All contacts are in parallel and in each button are four
contacts - one is “location” signal
05MBY00EY011 / 012 / 013 There are three signals from fire alarm panel

9.4.6 Surge protection


There are three differential pressure switches on the turbine compressor to make
sure that the compressor does not surge. If two out of three signals detect com-

rg
pressor “surge” than ESV valves will be closed and turbine will stop immediately.

Table 9.7: List of the surge protection signals


KKS Note
05MBA11CP001 / 1 / 2 / 3

9.4.7 Unit protection


e.o
This signal is generated by “unit protection sub-system” in case of serious elec-
trical fault in generator circuit. Please refer to the “unit protection sub-system”
documentation for more details.

9.4.8 Protection circuit (protection signals coming from


ee
TXP system)
There are many more trip signals which are processed by DCS system and which
may trip turbine. Those signals are send over six binary signals. Those signals
are tested automatically before each turbine start and may be tested manually
as well by “Test button” located in protection system cabinet.
@i

9.5 Protection system redundancy and reliability


To ensure reliability of the system the following measures are taken:
• Input sensors are configured as
ec

– 2 out of 3 logic
– 2 out of 2 logic
• CPU (95F) is designed as two independent high-reliability redundant unit
up

9.5.1 Non-Coincidence alarms


In case that there is more than one signal in the different to the others non-
coincidence logic is implemented. What does non-coincidence alarm mean?
Let’s say we have three signals in surge protection. If one signal out of three
showing trip and two others not than we get non-coincidence alarm. In other
words non-coincidence alarm is generated when signals do not have the same
value at the same time.
ro
9.5. PROTECTION SYSTEM REDUNDANCY AND RELIABILITY 122

9.5.2 System auto-diagnostic


As mentioned earlier many sub-systems contain diagnostic signals
• over-speed protection diagnostic sub-system
• trip circuit diagnostic
• ET200 subsystem health monitoring
• units synchronization check
• 95F self-diagnostic sub-system

rg
9.5.2.1 Over-speed protection diagnostic sub-system
The over speed hardware is tested every hour by testing frequency and prior to
the start

9.5.2.2 e.o
Trip circuit diagnostic
Trip circuit is tested for functionality prior to every start of the turbine.

9.5.2.3 ET200 subsystem health monitoring


System has implemented “Health” signals for various parts of the I/O subsystem
to make sure that AP (automation processors) are alive and their I/O sub-
systems is working properly.
ee
9.5.2.4 Units synchronization check
The unit “A” and “B” exchange variety of hardware signals which monitor mainly
outputs. This makes sure smooth start-up of every unit and health monitoring.
In other words unit “A” is monitoring unit “B” and vice versa.
@i

9.5.2.5 95F self-diagnostic sub-system


System performs complete self-diagnostic. All systems parts are checked out at
least once an hour. Any problem result switching of the unit into the diagnostic
mode.6 In this mode there are various possible actions for outputs:
ec

• outputs are passivated

• outputs are set to some pre-defined value.

Passivation / Depassivation Passivation means that output are set inac-


tive. If this happens on one unit ONLY then the turbine will continue running.
up

A lot of error messages will be sent to the TXP system. While error is rectified
then outputs have to be de-passivated. De-passivation can be made by pressing
button located on the upper-front side of the cabinet.
6 Yellow LED is on
ro
9.6. TROUBLE SHOOTING 123

9.5.3 CPU (95F) is designed as two independent high-


reliability redundant unit
Every unit is built from two CPU units which are synchronized over synchro-
nization bus.

Figure 9.5.1: Each PLC is build from two CPU units.

rg
e.o
ee
@i

9.6 Trouble shooting


ec

9.6.1 Start-up problems


There can be problems during start-up sequence. Usual problem is that ESV
valves does not open. What could go wrong during startup:
1. Low pressure in feeder line
up

2. No flame detection
3. Not a correct speed
There could be many other reasons why protection system does not release ESV
valves. Error log messages have to be carefully examined and analyzed with the
help of operating manual.
ro
9.6. TROUBLE SHOOTING 124

9.6.2 Problems during running machine


Every error message from protection system has to be carefully examined and
rectified as soon as possible in order to prevent unnecessary trip of the machine.

rg
e.o
ee
@i
ec
up
ro
9.7. INSTALLING 95F SOFTWARE ON THE PG 125

9.7 Installing 95F software on the PG


9.7.1 How to install 95F software on new PG
1. Copy software to the PG (over network or over the floppy)
2. Now install it to the directory you like (for example d:\asir )
3. Edit file Gt05abpx.ini and file gt05bpx.ini as shown on alg. 9.1 on the fol-
lowing page and 9.2 on page 127. You need to place correct paths to that
file. If you do not wish to modify these files manually follow points 4 to 7
listed below.

rg
4. Create new project Project ---> Set. By pressing F4 you can move around
in the tabs.
5. Go to the tab number 5 (Options) and by pressing F3 choose right direc-
tory (d:\asir)
e.o
6. Set correct files and directories in ALL tabs - mainly Program file in tab
number 2 and Symbols files and Assignment list in tab number 3
Please remember that there are slight differences between unit
A (located on the top of cabinet rows A and B) and unit B
(located on the top of cabinet rows D and E) !!!
7. Save a project by pressing ENTER and selecting File ---> Project ---> Save
As
ee
The above is illustration how to do it in case you did not edit files as above.
Because you prepared your files you can simply press F10 and open init file as
you prepared above.
@i

9.8 95F testing mode


9.8.1 Download code to 95F in testing mode
Now we should make sure that file in PG is same to the content of the RAM
(EPROM) in 95F system.
ec

1. Go to project ---> set (tab number 1 ) PLC and by selecting mode and
pressing F3 go online. Keep in mind if you are working with unit A or
unit B!!!!
2. Now you can go to File -> Blocks -> Compare and compare PLC to the pro-
gram file while selecting in Selection Block list ?A? ? means ALL blocks.
up

There will be differences in following blocs:

DB 100 Block does not exist in program file


DB 200 Block does not exist in program file
DB 252 Block does not exist in program file
DB 253 Block does not exist in program file
DB 254 Block does not exist in program file
FB 230 Block does not exist in program file
FB 231 Block does not exist in program file
FB 232 Block does not exist in program file
ro
9.8. 95F TESTING MODE 126

Algorithm 9.1 S5 configuration files to be edited - ORIGINAL of the file


[Project]
Version=7.10.000
[OnlineSettings]
PathFile=C:\STEP5\S5_HOME\@@@@@@AP.INI

rg
PLCMode=0
PLCInterface=0
PLCInterfacePar=COM1: Standard
ChangeOnline=4
AttrPLCMode=0
Pathoptions=0
PathName=
PLCChangeProgFileUpdate=0
[BlocksSettings]

ProtProgFile=0
Represent=2
Address=0
Comments=1
Checksum=0
DocBlockMode=0
e.o
ProgFile=D:\STEP5\S5_DATEN\ASIR_BIS\BISHA05\GT-PROT\02_GT05\GT05A0ST.S5D

FBFXPreHeaderMode=0
[SymbSettings]
SymbIniFile=D:\STEP5\S5_DATEN\ASIR_BIS\BISHA05\GT-PROT\02_GT05\GT05A0Z0.INI
SymbSeqFile=D:\STEP5\S5_DATEN\ASIR_BIS\BISHA05\GT-PROT\02_GT05\GT05A0Z0.SEQ
Symbols=1
ee
SymbDisplay=0
SymbLength=16
SymbCommLength=40
ProtSymbFile=0
ProtSeqFile=0
[DocSettings]
PrinterFile=C:\STEP5\S5_HOME\PT10Q8DR.INI
OutFile=D:\STEP5\S5_DATEN\ASIR_BIS\BISHA05\GT-PROT\02_GT05\NONAMELS.INI
FooterFile=D:\STEP5\S5_DATEN\ASIR_BIS\BISHA05\GT-PROT\02_GT05\GT05A0F2.INI
@i

DocCommFile=D:\STEP5\S5_DATEN\ASIR_BIS\BISHA05\GT-PROT\02_GT05\GT05A0SU.INI
CharSetASCII=0
PrinterInterface=0
Footer=1
DocumOutFile=0
[EpromSettings]
SysidFile=D:\STEP5\S5_DATEN\ASIR_BIS\BISHA05\GT-PROT\02_GT05\NONAMESD.INI
Prommer=0
EpromMode=1
ec

[OptionsSettings]
QuestEnd=1
QuestProjSave=1
Warning6x=0
Sorting=1
SortOrder=0
ProjFilesChangeLock=0
[STLBatchSettings]
up

STLSourceFile=D:\STEP5\S5_DATEN\ASIR_BIS\BISHA05\GT-PROT\02_GT05\NONAMEA0.SEQ
ro
9.8. 95F TESTING MODE 127

Algorithm 9.2 S5 configuration files to be eddited - MODIFIED file


[Project]
Version=7.10.000
[OnlineSettings]
PathFile=C:\STEP5\S5_HOME\@@@@@@AP.INI

rg
PLCMode=0
PLCInterface=0
PLCInterfacePar=COM1: Standard
ChangeOnline=4
AttrPLCMode=0
Pathoptions=0
PathName=
PLCChangeProgFileUpdate=0
[BlocksSettings]
ProgFile=D:\asir\GT05A0ST.S5D
ProtProgFile=0
Represent=2
Address=0
Comments=1
Checksum=0
DocBlockMode=0
e.o
FBFXPreHeaderMode=0
[SymbSettings]
SymbIniFile=D:\asir\GT05A0Z0.INI
SymbSeqFile=D:\asir\GT05A0Z0.SEQ
Symbols=1
ee
SymbDisplay=0
SymbLength=16
SymbCommLength=40
ProtSymbFile=0
ProtSeqFile=0
[DocSettings]
PrinterFile=C:\STEP5\S5_HOME\PT10Q8DR.INI
OutFile=D:\asir\NONAMELS.INI
FooterFile=D:\asir\GT05A0F2.INI
@i

DocCommFile=D:\asir\GT05A0SU.INI
CharSetASCII=0
PrinterInterface=0
Footer=1
DocumOutFile=0
[EpromSettings]
SysidFile=D:\asir\NONAMESD.INI
Prommer=0
EpromMode=1
ec

[OptionsSettings]
QuestEnd=1
QuestProjSave=1
Warning6x=0
Sorting=1
SortOrder=0
ProjFilesChangeLock=0
[STLBatchSettings]
up

STLSourceFile=D:\asir\NONAMEA0.SEQ
ro
9.8. 95F TESTING MODE 128

FB 233 Block does not exist in program file


FB 234 Block does not exist in program file
FB 235 Block does not exist in program file
FB 236 Block does not exist in program file
FB 237 Block does not exist in program file
FB 238 Block does not exist in program file
FB 240 Block does not exist in program file
FB 241 Block does not exist in program file
FB 242 Block does not exist in program file
FB 243 Block does not exist in program file

9.8.2 95F overall reset

rg
Manual reset
With manual reset all data in both units are deleted.
1. Set both switches RUN/STOP in STOP position
2. Switch OFF both units
3. Remove batteries from both units
4. Switch ON both units
5. Insert batteries
e.o
6. Switch ON both units
If EPROMS are not inserted system is in TEST mode –> download code into
ee
the PLC.
1. File -> Transfer -> Blocks and in selection write ”A” (means all).
Some blocks cannot be transfered:
FB 255
@i

OB 31
DB 1

2. Do same for BOTH PLC?s (unit A tier A,B ;and unit B tier D,E)
3. After loading is necessary to restart unit by cycling switch run to stop and
back to the run.
ec
up
ro
9.8. 95F TESTING MODE 129

Figure 9.8.1: Description of the 95F testing mode from the manual

rg
e.o
ee
@i
ec
up
ro
9.9. 95F FAULTS RECTIFYING 130

Table 9.8: Errors reported by 95F program


Error description Byte Nr. Signal Group Nr.
48: Module wrongly configured in DB1 12 12
48: Module wrongly configured in DB1 4 27
48: Module wrongly configured in DB1 6 27
48: Module wrongly configured in DB1 8 27

9.9 95F faults rectifying

rg
9.9.1 Rectify MYB00EU111B fault
The above mentioned error was detected on the 95F equipment. Cross reference
list shown that this error is set by output Q64.6 which is set in PB210:21 by bit
F5.5 coming out of the logic in PB210:19. In that logic it was found that bit is
set by F 72.6 which means “PASSIVATED SG14”. The same error could be seen
e.o
in I/O externals errors which shown that the slots 10, 14, 22 were passivated.
On the figure 9.9.1 on the following page can be seen slot numbering for bisha06
project.
The problem was wrongly located switch on the card located on slot 22.

9.9.2 Diagnostic mode after 95F restart


The 95F is entering into the diagnostic mode immediately after its restart. The
ee
overall reset has been performed and software newly loaded - problem prevail.
The COM 95F diagnostic program is reporting errors mentioned in table 9.8.

Solution
• All cards have been tested in second (properly working) 95F rack
@i

• DB1 has been verified


• Software configuration has been reloaded after reset

Finally it has been found that bus connector linking external I/O card is not
properly connected. Connector has been reconnected and the system is working
again without problems.7
ec

7 See 95F manuals link located in Sagunto PR64 directory or search for manuals with order

number 4NEB 812 6220-02 and manual for the software COM 95F with order number 6ES5
895 6MF23
up
ro
9.9. 95F FAULTS RECTIFYING 131

Figure 9.9.1: Slot numbering for 95F - 06CJQ41

rg
e.o
ee
@i
ec
up
ro
9.10. REFERENCES 132

9.10 References
• 495.0 - Maintenance of 95F
• 495.1 - Simulations 95F

• 496 - COM 95F - programming software for 95F


• 497 - 95U - S5 Programmable Controller Manual For 95U

rg
e.o
ee
@i
ec
up
ro
rg
Part III
e.o
Cybersecurity
ee
@i
ec
up
ro

133
134

The idea is to address questions what to do about networking safety. This


section to be ommitted due lack of sufficient knowledge of the audience. This
section require some networking knowledge and hands on experience.

rg
e.o
ee
@i
ec
up
ro
rg
Part IV
e.o
Questions to be answered
ee
@i
ec
up
ro

135
136

Day one
1. How does the single fault tolerant for OSM ring structure works (make a
sketch)?
2. What will happen if BDM manager of master SU fails?
3. What does SAMPLER command do?
4. What does rdb command do?
5. What is meaning of InfFb.proj file?

rg
6. Where (on which path) diagnostic files are located?
7. What is the command to know the status of the OM system?
8. What should be the SCSI id of DAT tape?
9. What does Sig.Attach command do?
e.o
10. What is the configuration file for Web4TXP and where it is located?
11. Where is the location of OM licensing file and how it’s named?

Day two
ee
1. Describe the hierarchy level where we do the engineering for HW & SW?
2. What does “crontab –l” command do?
3. What information does semaphore directory reveals?
4. Where is the night backup file saved? And what does actually it saves?
@i

5. What does the “tar t”, “tar c” “tar x” commands do?


6. How to identify and unlock FUP diagram?
7. What types of errors are monitored by DS?
ec

Day three
1. How to configure bridge OSM? What steps are needed?
2. Why do we disable time sync on Bridge OSM?

3. How to configure RM mode on OSM?


up

4. Describe S5 AP rack structure used in Sugen plant.


5. From where Thin Client takes time?
6. What’s the use of batteries on AP rack?
7. How to extract PBP file from ES680?
ro
137

8. What are the steps to do the engineering of Analog signal on ES680?


9. How to configure IM308 memory card?
10. What will happen if Hopf Clock fails?

Day four
1. What is the purpose of failsafe protection system & how it’s communicat-
ing with AP? (describe communication and physical hardware involved)

rg
2. Describe general hardware structure of 95F.
3. What is the purpose of CM104 system & how to take its backup?
4. Describe how signals flow from vibration sensors to AP.
5. Describe general function of Argus system.
e.o
ee
@i
ec
up
ro
List of Figures

rg
2.1.1 Main T2000 components are shown on this figure . . . . . . . . . 12
2.1.2 Sugen computer naming concept . . . . . . . . . . . . . . . . . . 12
2.1.3 The plant bus and terminal bus are configure as a ring . . . . . . 14

3.0.1 Sugen computer naming concept . . . . . . . . . . . . . . . . . . 16


3.1.1 The infrastructure of the OM system distributed over several
e.o
components . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.1.2 Similar error might be found in error log files when there is an
issue with the OM license . . . . . . . . . . . . . . . . . . . . . .
3.1.3 Interface for the OM configuration files generation and transfer .
17

21
22
3.2.1 OM system status . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2 File structure of typical OM650 component . . . . . . . . . . . . 24
3.2.3 OM system status . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.2.4 PU unit output of the /etc/dfspace command . . . . . . . . . . . 29
ee
3.3.1 OM system status . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.3.2 File structure of typical OM650 component . . . . . . . . . . . . 42
3.3.3 OM system status . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.3.4 SU unit output of the /etc/dfspace command . . . . . . . . . . . 46
3.3.6 Screenshot from the SU-B server - system messages . . . . . . . . 47
3.3.5 SU unit system log files indicates problems with storage media . 47
@i

3.3.7 Identify the process number - result of Step 4 commands . . . . . 50


3.4.1 File structure of typical OM650 component . . . . . . . . . . . . 59
3.4.2 Edit OM_USER section – add for each user application name . . 63
3.4.3 Edit OM_CLIENT section – add for each computer the line with
IP address and user name which will be used . . . . . . . . . . . 63
3.4.4 Edit ES_USER section – add for each user application name . . 64
ec

3.4.5 Edit ES_APPL section – add for each computer the line with IP
address and user name which will be used . . . . . . . . . . . . . 64
3.4.6 OM system status . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.4.7 PU unit output of the /etc/dfspace command . . . . . . . . . . . 65

5.3.1 Common acknowledge function . . . . . . . . . . . . . . . . . . . 87


up

7.1.1 Typical structure of the AP processor . . . . . . . . . . . . . . . 99


7.1.2 Physical AP rack . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.4.1 Page from TXP manual describing the errors status LEDs of the
IM 308 card . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102

8.1.1 CM 104 drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . 107


ro

138
LIST OF FIGURES 139

9.2.1 Schematic interconnection of the systems - Please note that this


is ONLY schematic and plant configuration must not be exactly
the same as shown in this diagram. Exact plant configuration is
shown in topology diagram which can be found in appendix. . . . 115
9.2.2 Topology Diagram - Network Infrastructure . . . . . . . . . . . . 116
9.4.1 Schematic of hardware over-speed
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
9.5.1 Each PLC is build from two CPU units.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
9.8.1 Description of the 95F testing mode from the manual . . . . . . 129
9.9.1 Slot numbering for 95F - 06CJQ41 . . . . . . . . . . . . . . . . . 131

rg
e.o
ee
@i
ec
up
ro

You might also like