technical specification instrumentation 6 process control

SLOVNAFT a.s.

R&M Division

This document is property of MOL Group. The use is only allowed with the written permission of MOL Group.

MOL Group

TECHNICAL SPECIFICATION INSTRUMENTATION

6 Process Control Systems

MGS-S-REF-I-6

Rev 1.00.01

SLOVNAFT a.s. MGS-S-REF-I-6 R&M Division

TECHNICAL SPECIFICATION - INSTRUMENTATION Rev.: 1.00.01

6 Process Control Systems Date: 31.01.2014

Page/Pages: 2/4

This document is property of MOL Group. The use is only allowed with the written permission of MOL Group

Release list

Rev. Date Description Edited Verified Approved

0.00.00 20.01.2006 Basic release 0.00.01 12.12.2008 Issued for comments A. Pozsgai L. Pallagi 1.00.00 30.11.2011 General issue L. Pallagi A. Pozsgai 1.00.01 31.01.2014 General review Z. Stanová R. Kopálek Head of Technology


Rev 1.00.01 3/4

Contents Release list ................................................................................................................................................................... 2

Book Breakdown ........................................................................................................................................................... 4


4/4 Rev 1.00.01

BOOK BREAKDOWN

Description Identifier Revision

Process Control Systems MGS-S-REF-I-6 1.00.01

Integrated Control System MGS-S-REF-I-6.0 1.00.00

Requirements for DCS system MGS-S-REF-I-6.1 1.00.01

Requirements for Safety Instrumented System MGS-S-REF-I-6.2 1.00.01

Requirements for PLC system MGS-S-REF-I-6.3 1.00.00

Requirements for Advanced Process Control MGS-S-REF-I-6.4 1.00.00

Requirements for Field Instrumentation Maintenance System

MGS-S-REF-I-6.5 1.00.00

Requirements of a protection, diagnostic and expert system for rotating equipment MGS-S-REF-I-6.6 1.00.00

RIS connection MGS-S-REF-I-6.7 1.00.00

Requirements related to the development of an on-line analytical diagnostic and maintenance network MGS-S-REF-I-6.8 1.00.00

Alarm System and HMI display design and implementation

MGS-S-REF-I-6.9 1.00.00

Design of Gas Alarm System MGS-S-REF-I-6.10 1.00.00

SLOVNAFT a.s.

R&M Division


MOL Group


6 Process Control Systems 0 Integrated Control System

MGS-S-REF-I-6.0

Rev 1.00.01

SLOVNAFT a.s. MGS-S-REF-I-6.0 R&M Division



0 Integrated Control System Page/Pages: 2/8


Release list


0.00.00 20.01.2006 Basic release (MGS-I-6) 0.00.01 12.12.2008 Issued for comments (MGS-I-6) L.Pallagi Á.Pozsgai 1.00.00 30.11.2011 General issue L.Pallagi Á.Pozsgai 1.00.01 31.05.2016 Revision Z. Stanová R. Kopálek Head of

Maintenance


Rev 1.00.01 3/8

Contents Release list ................................................................................................................................................................... 2

Integrated Control System ............................................................................................................................................ 4

1 General .................................................................................................................................................................. 4

2 Deviations .............................................................................................................................................................. 4

3 Definitions .............................................................................................................................................................. 4

4 Definition and Control Levels of the Integrated Control Systems (ICS) ................................................................ 4

4.1 Definition of Integrated Control System (ICS) .............................................................................................. 4

4.2 Segmentation ................................................................................................................................................ 5

4.3 Communications-flow ................................................................................................................................... 5

5 Requirements on system integration and subsystem connection ......................................................................... 5

5.1 Integration of DCS and other systems .......................................................................................................... 5

5.2 Integration of SIS systems ............................................................................................................................ 6

5.3 Integration of serial subsystems ................................................................................................................... 6

5.3.1 Requirements on serial lines and data representation ............................................................................. 6

5.3.2 Requirements on serial redundancy ......................................................................................................... 7

5.4 Integration of systems via OPC .................................................................................................................... 7

6 Requirements on integrated FAT .......................................................................................................................... 7

7 Applicable standards and provisions ..................................................................................................................... 7

8 Appendix ................................................................................................................................................................ 8


4/8 Rev 1.00.01

INTEGRATED CONTROL SYSTEM

1 General This document defines requirements on Integrated Control Systems.

2 Deviations The applicable Project Specification may contain deviations from or changes to this document. Deviations from the contents of this specification and the Project Specification shall be permissible only on the basis of prior written approval by MOL.

3 Definitions APC (Advanced Process Control) : Board term of different kind of process control tools, often used for solving multivariable control problems or discrete control problem.

BPCS (Basic Process Control System) : Basic Process Control System which responds to input signals from the process, its associated equipment, other programmable systems and/or an operator and generates output signals causing the process and its associated equipment to operate in the desired manner but which does not perform any safety instrumented functions.

Communications Subsystem : The hardware and software that performs the transmitting and receiving of digital information.

Distributed Control System (DCS): Partitioning of the total basic control functions among independent control devices which are communicating trough a control network, whose purpose is the control of the an industrial process or plan. The control network distributes the control functions, data access and process management.

FIMS (Field Instrumentation and Maintenance System) : System to gather detailed information on the intelligent instruments, the forecasting of the expectable problems by monitoring the limit values of the status characteristics, the quick identification of the possible failures and the improvement of the operation reliability through this, the reduction of the losses of production due to failures, as well as the establishment and summary of the remote maintenance into one uniformed system; altogether the reduction of the maintenance and operational costs. ICS (Integrated Control System): ICS is the all integrated and cooperative devices, equipment, information technologies that provide the control of the controlled process.

OPC (OLE - Object Linking and Embedding for Process Contro l): Software application which allows bi-directional data flow between two separate applications. These applications may be running on the same or on separate servers. PLC (Programmable Logic Controller) SIS (Safety Instrumented System) : Safety Instrumented System (SIS) used to implement one or more safety instrumented functions. An SIS is composed of any combination of sensor (s), logic solver (s), and final elements(s). This can include either safety instrumented control functions or safety instrumented protection functions or both. RIS (Refinery Information System): System for the continuous retrieval and storage of process data, collecting the information generated by the control systems (ICS) of various production and energy/utility units, making these suitable for processing on a common platform, in a common database in the Refineries of MOL Plc.

4 Definition and Control Levels of the Integrated C ontrol Systems (ICS)

4.1 Definition of Integrated Control System (ICS) ICS is the system of all integrated and co-operative devices, equipment, information technologies:

• DCS (Distributed Control System, including intelligent field devices) and

• PLC (Programmable Logic Controller) as parts of BPCS,

• other stand-alone BPCS subsystems (intelligent controllers, integrated into DCS)

• SIS (Safety Instrumented System),

• APC (Advanced Process Control),

• FIMS (Field Instrumentation and Maintenance System),

• and any other systems that provide monitor and control of the process.


Rev 1.00.01 5/8

ICS is a universal control system that integrates different cooperating subsystems to ensure all required process controls/automations and provide unified interface to the personnel. Definition and security segmentation of Control Levels

4.2 Segmentation 1. To protect the Process Control Network we segment the network in various security zones. To control the

traffic between these zones security-controls will be defined. These controls can be quite simple like access-lists on the network equipment and firewalls.

2. The segmentation of the network is based on the ISA SP 95. This guideline offers a framework on how to split the functional components of the process automation environment in levels. These levels are used in the technical infrastructure as network segments / security zones. This section discusses the leveling as defined for continuous production processes.

4.3 Communications-flow 1. Between the different levels / security-zones strict rules for communication exist according the table below:

Field Instruments

ICS/DCS Advanced

Control Demilitarized Zone (DMZ)

Business Network

Level 0 1 2 3 4 0 FF LF NC NC NC 1 FF LF NC NC 2 FF VL NC 3 LF VL 4 FF

Key: FF Free Flow of information LF Limited Flow of information VL Very Limited Flow of information NC No Communication

2. These communication-rules will be enforced by security-controls (e.g. access-lists), IP addressing-scheme,

network-architecture.

3. The Business Network has to be logically separated from the Process Control Network (PCN) on physically separate network-devices. Requirements for enterprise connectivity are:

• There must be a single access point (with firewall) between the Process Control Network and the Business Network.

• To enable communication between PCN and Business Network an acceptable architecture is to implement an intermediate DMZ (De-Militarized Zone)-network. This DMZ network-segment shall be connected to a dedicated interface of the firewall.

• The firewall will then be configured in such a way that enterprise-users are allowed to have specific (restricted) communication with the DMZ only; the same is valid for the PCN-users.

• No direct communications between PCN and Business Network is allowed.

5 Requirements on system integration and subsystem connection

5.1 Integration of DCS and other systems 1. All integrated control system shall have a governor system to connect the different subsystems (e.g. SIS,

PLCs, other intelligent devices, etc.) and higher level (APC, RIS, etc.) systems.

2. The governor system of the integrated process control system is the DCS (Distributed Control System).

3. The DCS system shall have the information technologies and network/linear connections necessary to integrate the different subsystems.

4. The governor DCS system shall have an exactly pre-determined standard communication and information interface.

5. DCS and systems to be integrated shall have serial or network communication capability with standard hardware (RS485, Ethernet etc.) and software (protocol MODBUS, TCP/IP, OPC etc.) elements. Its application software shall be prepared for the communication by the operating system.

6. Types of connection shall be:


6/8 Rev 1.00.01

• Serial communication;

• Network client-server connection;

7. Operator interfaces of the subsystems (DCS, SIS, APC, Vibration Monitoring, F&G, analyzers, etc.) shall be provided on the DCS system for monitoring and operation.

8. Time synchronization of all subsystems is required.

9. All SIS or PLC systems, Vibration Monitoring, F&G, analyzers, etc. shall be connected to the DCS system by ways described below.

5.2 Integration of SIS systems 1. Requirement for Manufacturer selection of DCS and SIS systems see App.

2. SIS shall be fully integrated into the DCS system with common internal bus system, diagnostics, configuration environment and database.

3. SIS logic solver of compressors shall be independent of other logic solvers.

4. SIS logic solver of BMS can be shared with ESD logic solvers.

5.3 Integration of serial subsystems Other subsystems (PLCs, Vibration Monitoring, F&G, Analyzers, etc.) shall be integrated into the ICS system with communication line. Serial or Network communication line shall be provided.

5.3.1 Requirements on serial lines and data represe ntation 5. Serial communication port of subsystem shall be connected to the DCS host port. RS485 (2- or 4-wire)

Modbus RTU slave communication shall be supplied.

6. TCP/IP-Modbus and Terminal Server-Modbus connection types are also allowed; in this case all of serial requirements shall be applied on all related network elements.

7. If required (2 or more intelligent equipment installed in the subsystem), multidrop configuration is allowed.

8. If required (modbus address range is too short for all data), virtual multidrop configuration (one equipment with more RTU addresses) is allowed.

9. All data (with same type) shall be supplied with one sequential data block to be reached by Modbus Master with one function code.

10. All address range shall be able to handle with single and block type function codes. No error codes (exception) are allowed between the lowest and highest address.

11. Mixing of digital and analog signals is allowed, but address range of digital and analog shall be well separated.

12. Minimum 10 percent spare addresses shall be supported for future extension for each type of data.

13. Float type of analog data are not allowed. Only fixed point or normalized data are allowed in one 16 bit register.

14. Multiregister representation is allowed for only totalized (or other longer) values.

15. Vendor shall provide communication table of addresses, tag names, descriptions and data representation form of all analog and digital data.

16. Data representation for analogs: engineering unit, low and high scale, value at low and high scale, number of decimals.

17. In case of transmitter failure, bad value status shall be provided (e.g.: extreme high/low or special value in the data register). External status bits shall be avoided, if possible.

18. Data representation for digitals: exact meaning of 0 and 1 status.

19. Modbus addresses must not be shared, one data - one address shall be considered. No any indexed function or block driven request-answer method is allowed.

20. In case of using protocol converter equipment between subsystem equipment and DCS, when communication of Package unit fails, the protocol converter must not supply old invalid data from its own database.

21. Serial lines coming from technological site or other special areas (e.g. electrical substation) shall be connected to the process control system through galvanic isolation.

22. If the Satellite room for the Control system including third party system and the Control room with Control system operator workstations and other HMI are placed in the different places, for data connection shall be implement the following:

• the redundant optic cable shall be used for data connection

• each branch of redundant data connection shall be led in the independent cable routes and on the different cable bridges


Rev 1.00.01 7/8

• in case of mechanical damage or the fire at one cable route the data connection shall not be interrupted.

• the cable routes leading through places with increased fire risk (e.g. production unit technology) shall be avoided

5.3.2 Requirements on serial redundancy 1. Using of protocol multiplier equipment shall be avoided. Equipment with only one (non-redundant) serial port

shall be directly connected as a non-redundant subsystem.

2. Redundant serial communication ports of the subsystems shall be same but fully independent.

3. Redundant pairs of serial ports shall not be in the same physical communication card of the subsystem (slave) or DCS (master).

4. DCS diagnostics shall detect communication line failures even it is not activated.

5. RTU addresses, communication parameters, Modbus address ranges, etc. shall be same on each lines.

6. Both communication lines shall be able to be independently and asynchronously used from the other. There shall not be any affect from other line status.

7. Same data shall be provided or received at same Modbus address on both lines.

8. In case of writing to the subsystem, DCS shall send the proper function code once, only on one of communication lines. Subsystem shall update its communication database of redundant ports to be exactly same. At next reading cycle (from any ports) both (redundant) registers shall show the previously changed value.

5.4 Integration of systems via OPC 1. The DCS and higher/subsystem shall have standard physical network and a communication protocol (IEEE

802.3 Ethernet, TCP/IP protocol), supported with network client-server connection (OPC client-server).

2. The redundancy requirements shall also be applied to the client-server connection.

3. Failure or a break in the communication shall cause a specific system alarm and shall not affect the functionality of the BPCS and SIS.

4. Communication functions shall be able to read/write the data and parameters (e.g. tag parameter) of the ICS system.

6 Requirements on integrated FAT All of requirements of MGS-M-REF-I-13.1 & MGS-S-REF-I-13.1 shall be applied with following complements:

• At place of FAT all of systems to be delivered or integrated shall be presented and connected to each other to check all integrated functions.

• If one of components cannot be physically presented (e.g. existing DCS system is increased), functionally same provisional test system shall be provided.

• Simulation environment shall be avoided if possible.

• All of inter-system communication capability shall be checked.

• All communication redundancy and diagnostic function between system components shall be checked.

7 Applicable standards and provisions The following standards shall be observed:

• EN 61000-4-2, IEC 61000-4-3, IEC 61000-4-4 Electromagnetic Compatibility (EMC)

Furthermore, the following MOL Group standards shall be observed:

• MGS-M-REF-I-6.1 & MGS-S-REF-I-6.1 Requirements for DCS System

• MGS-M-REF-I-6.2 & MGS-S-REF-I-6.2 Requirements for Safety Instrumented System

• MGS-M-REF-I-6.3 & MGS-S-REF-I-6.3 Requirements for PLC system

• MGS-M-REF-I-6.4 & MGS-S-REF-I-6.4 Requirements for Advanced Process Control

• MGS-M-REF-I-6.5 & MGS-S-REF-I-6.5 Requirements for Field Instrumentation Maintenance System

• MGS-M-REF-I-6.6 & MGS-S-REF-I-6.6 Requirements of a protection diagnostic and expert system for rotating equipment

• MGS-M-REF-I-6.7 & MGS-S-REF-I-6.7 RIS connection


8/8 Rev 1.00.01

• MGS-M-REF-I-13.1 & MGS-S-REF-I-13.1 Requirements of Factory Acceptance Test (FAT)

• MGS-M-REF-I-13.2 & MGS-S-REF-I-13.2 Requirements of Site Acceptance Test (SAT)

8 Appendix 5.2 Integration of SIS system ad. 1 DCS and all SIS systems (e.g. BMS and compressor) shall be delivered by same Manufacturer if possible.

SLOVNAFT a.s.

R&M Division


MOL Group


6. Process Control Systems 1. Requirements for DCS System

MGS-S-REF-I-6.1

Rev 1.00.01




1 Requirements for DCS System Page/Pages: 2/26


Release list


0.00.00 20.01.2006 Basic release 0.00.01 12.12.2008 Issued for comments Á. Pozsgai L. Pallagi 1.00.00 30.11.2011 General issue L. Pallagi Á. Pozsgai 1.00.01 31.01.2014 General review P. Jakubec R. Kopálek Head of Technology


Rev 1.00.01 3/26

Contents 1 General .................................................................................................................................................................. 5

2 Deviations .............................................................................................................................................................. 5

3 Applicable codes & standards ............................................................................................................................... 5

4 The DCS in the Integrated Control System ........................................................................................................... 5

5 General requirements for the DCS ........................................................................................................................ 5

6 Design Requirements for the DCS ........................................................................................................................ 5

6.1 DCS performance and size ............................................................................................................................ 5

6.1.1 Definition of response period for the conventional DCS system........................................................... 5

6.1.2 Definition of response period for hybrid control system (within Fieldbus and DCS controller) ............. 5

6.1.3 Definition of response period for Fieldbus control system (within Fieldbus) ......................................... 6

6.1.4 Requirements on Control Response Period ......................................................................................... 6

6.2 Spare and expandability ................................................................................................................................. 6

6.3 Requirements for control loops (Single Loop Integrity) .................................................................................. 7

7 Requirements on I/O subsystem ........................................................................................................................... 7

7.1 General requirements on I/O subsystem ........................................................................................................ 7

7.2 Types of I/O modules ..................................................................................................................................... 8

7.2.1 HART I/O ............................................................................................................................................... 8

7.2.2 Foundation Fieldbus I/O ........................................................................................................................ 8

8 Requirements on the controller functions .............................................................................................................. 8

8.1 Control functions of the controller ................................................................................................................... 8

8.2 Programming possibility ................................................................................................................................. 9

8.3 Sequential Control .......................................................................................................................................... 9

8.4 Application computer ...................................................................................................................................... 9

8.5 Advanced Control function in the DCS system .............................................................................................. 9

9 Requirements for Regulatory Control Function of DCS ........................................................................................ 9

9.1 Fault detection and handling .......................................................................................................................... 9

9.2 Mode and connection ................................................................................................................................... 10

10 Requirements on operator interface ............................................................................................................. 10

10.1 Operator Workstations and printers ......................................................................................................... 10

10.1.1 Requirements on Operator Workstations ............................................................................................ 10

10.1.2 Requirements on printers .................................................................................................................... 10

10.2 Requirements on HMI displays ................................................................................................................ 10

10.2.1 Faceplate............................................................................................................................................. 11

10.2.2 Group display ...................................................................................................................................... 11

10.2.3 Detailed point display .......................................................................................................................... 11

10.2.4 Controller tuning panel ........................................................................................................................ 11

10.2.5 Trend display ....................................................................................................................................... 11

10.2.6 Alarm summary ................................................................................................................................... 12

10.2.7 Real time graphic display .................................................................................................................... 12

10.2.8 Event journal display ........................................................................................................................... 12

10.2.9 System and Diagnostic Displays ......................................................................................................... 13

10.2.10 Process Visualization Strategy for fieldbus system ............................................................................ 13

10.2.11 Other display requirements ................................................................................................................. 13

10.3 Requirements on reports ......................................................................................................................... 13

11 Requirements on database .......................................................................................................................... 14

11.1 System Access ........................................................................................................................................ 14

11.2 Requirements on configuration database ................................................................................................ 14

11.3 Requirements on real-time process database ......................................................................................... 14

11.4 Requirements on alarm and event database ........................................................................................... 15

11.4.1 General requirements on alarm and event database ......................................................................... 15

11.4.2 Alarming system .................................................................................................................................. 15

12 Requirements on the developing environment ............................................................................................. 16

12.1 Engineering Workstation .......................................................................................................................... 16

12.2 Requirements for configuration tools ....................................................................................................... 16

13 Requirements for application software ......................................................................................................... 17

13.1 Functional Design Study for application software .................................................................................... 17

13.2 General requirements for application software ........................................................................................ 17

13.3 Rules for tag database building ............................................................................................................... 17


4/26 Rev 1.00.01

13.4 Configuration of control loops ................................................................................................................. 18

13.5 Rules for operator group building ............................................................................................................ 18

13.6 Rules for graphics picture building (see also: MGS-M-REF-6.9 & MGS-S-REF-6.9) ............................. 18

14 RIS connection (see MGS-M-REF-6.7 & MGS-S-REF-6.7) ........................................................................ 19

15 Power supply requirements ......................................................................................................................... 19

16 Requirements for the grounding system ...................................................................................................... 19

17 Requirements on cabling and wiring............................................................................................................ 20

18 Constructional requirements for cabinets .................................................................................................... 21

18.1 General requirements ............................................................................................................................. 21

18.2 Nameplates, cable and wire tagnames, labelling ................................................................................... 21

19 Requirements for Manufacturer services ..................................................................................................... 22

20 Tests ............................................................................................................................................................ 22

20.1 FAT, SAT requirements (see also MGS-M-REF-I-13.1, MGS-M-REF-I-13.2 and MGS-S-REF-I-13.1, MGS-S-REF-I-13.2) ................................................................................................................................................ 22

20.1.1 DCS hardware test ............................................................................................................................. 23

20.1.2 DCS application software test ............................................................................................................ 23

21 Documentation contents .............................................................................................................................. 24

21.1 DCS proposal documentation contents .................................................................................................. 24

21.2 DCS standard documentation contents .................................................................................................. 24

21.3 DCS as-built documentation contents ..................................................................................................... 24

21.3.1 DCS system documentation ............................................................................................................... 25

21.3.2 Installed application software documentation .................................................................................... 25

22 Appendix: ..................................................................................................................................................... 26


Rev 1.00.01 5/26

REQUIREMENTS FOR DCS SYSTEM

1 General The present specifications contain basic requirements for Distributed Control Systems (hereinafter referred to as DCS), freezes special application rules to be considered that may differ from standards or refine it.

2 Deviations The applicable Project Specification may contain deviations from or changes to this document.

Deviations from the contents of this specification and the Project Specification shall be permissible only on the basis of prior written approval by MOL.

The specified solutions shall be in conformance with the specification system, standards and requirements of the applicable project documentation.

3 Applicable codes & standards According to chapter MGS-M-REF-I & MGS-S-REF-I-4

Additional reference: see App.

4 The DCS in the Integrated Control System The DCS as a kind of the Basic Process Control System (BPCS) is the central part of the Integrated Control System (hereinafter ICS, for abbreviations and details see: MGS-M-REF-I-6.0 & MGS-S-REF-I-6.0).

5 General requirements for the DCS The system shall be composed of manufacturer's standard hardware, systems software, and firmware that shall be configured to meet all requirements described below. The DCS system architecture shall be composed of standards based technology.

6 Design Requirements for the DCS During the DCS design and sizing, the following most essential criteria shall be considered:

• DCS performance and size;

• Spare and built-in extendibility;

• Requirements of control loops (Loop Integrity);

6.1 DCS performance and size

6.1.1 Definition of response period for the convent ional DCS system The response period is the time elapsed between the change in the input of the I/O subsystem (e.g. the change of the process variable) and the action on the output (the manipulated value) effected by this change – as a result of the control algorithms (PID, signal selector, summers, calculation blocks, etc.) executed in the DCS. The control response period shall be the total time to perform the following steps:

• Analog to Digital conversion of analog input signal (4-20 mA) and writing value to I/O processor.

• Pass the input value to the controller to perform the control algorithm.

• Execute the control function block(s).

• Pass the calculated output value of control algorithm to the I/O processor.

• Digital to analog conversion to generate the output signal (4-20 mA).

6.1.2 Definition of response period for hybrid cont rol system (within Fieldbus and DCS controller) Hybrid control is a term given to a control strategy that incorporates function blocks running in both field devices and a DCS controller. The control response period shall be the total time to perform the following steps:

• Execute the Analog Input Function Block in the transmitter and publish the process variable value on the fieldbus.


6/26 Rev 1.00.01

• Receive the process variable at the DCS and transmit it internally to the controller to perform the control algorithm.

• Execute the control function block(s).

• The total bus transmission time to publish the calculated output value of control algorithm on the fieldbus.

• Execute the connected Analog Output Function Block.

6.1.3 Definition of response period for Fieldbus co ntrol system (within Fieldbus) Fieldbus control is a term given to a control strategy that incorporates function blocks running only in the field devices. The control algorithm may be located within the final control element hardware or field transmitter. The control response period shall be the total time to perform the following steps:

• Execute the Analog Input Function Block in the transmitter and publish the process variable value on the fieldbus.

• The total bus transmission time to publish the process variable value of Analog Input Function Block on the fieldbus (Note: It is not necessary if the Analog Input Function Block and the control algorithm function block are located at the same field device).

• Execute the control function block(s) in the fieldbus device.

• The total bus transmission time to publish the calculated output value of control algorithm on the fieldbus (Note: It is not necessary if the control algorithm function block and the Analog Output Function Block are located at the same field device).

• Execute the connected Analog Output Function Block.

6.1.4 Requirements on Control Response Period

The control response periods for regulations, controls and measurements are defined by technological requirements in accordance with the specification of the Licensor.

The typical maximum control response periods for different type of controllers, see table below:

Description Typical Maximum Control Response Period for DCS

System Liquid pressure 500 msec Gas pressure 500 msec Differential pressure 500 msec Flow 500 msec Temperature 1 sec Level 1 sec Others (analysers) 1 sec Designated Fast Process Control Loop 250 msec Discrete signals 500 msec

In the case of faster controls (e.g. antisurge control, reactor temperature control), individual controllers shall be integrated to the DCS system.

6.2 Spare and expandability The delivered DCS shall have 10% built-in spare and 20% expandability. Any alterations from this fundamental requirement are included in the chart below:

Description Built -in spare Expandability Remark I/O card/slot - 20 % For each I/O card I/O channel 10 % - For each I/O type Control algorithm* 10 % - controller CPU capacity Point, tagname Total 20,000 pcs / system PCN node no - 30 % Electrical power of Power Supply

Min. 20 % Shall be sufficient for all

extendable devices Terminal strips 15 % 25 % Internal cable duct 30 % - Cabinet empty space 15 % - Communication, network 30 % - Communication: serial, to HMI,


Rev 1.00.01 7/26

Description Built -in spare Expandability Remark OPC, peer to peer, etc.

All licenses to cover built-in spare I/Os and controller capacity listed above shall be delivered.

* Note: In the case of controllers, the integrated spare refers to the memory use, the CPU runtime, the number of configured algorithms, the HMI and other communication. The built-in spare may not reduce the response period set forth in the response period requirements. The Central Processing Unit(s) of DCS system shall include sufficient capacity to permit 50% of the slower control algorithm (with 500 msec and 1 sec response period) to be changed to 250 msec.

6.3 Requirements for control loops (Single Loop Int egrity) Single loop integrity is required to prevent a single component failure from affecting more than one control loop. An occasional failure of any part of a control loop or any DCS component (e.g. power units) shall not cause the necessity of the manual operation of an actuating unit belonging to more than one control loop.

System elements used commonly by more control loops (e.g. I/O processor, CPU’s, power supplies, operator work station etc.) shall be of redundant design.

7 Requirements on I/O subsystem

7.1 General requirements on I/O subsystem The I/O subsystem shall have modular structure.

It shall support the simultaneous use of different type I/O cards (AI, AO, DI, DO, Serial) and redundant and/or non-redundant I/O modules.

In case of equipments which have spare pair (e.g. pumps A and B) use of non redundant card is accepted, but the status, control and command signals of equipment “A” shall not be connected to I/O card where equipment “B” is connected.

Surge Protection Device (SPD) shall be installed for I/O which connected to field devices.

I/O modules shall be protected against static discharge and sort-circuiting. It shall have current reduction function.

Process I/O circuits shall be protected against common mode transient surges of up to 500 V RMS. Such transient surges shall not cause damage or system performance degradation.

All digital process I/O circuits shall be designed to ensure that accidental normal mode connection of up to 300 Vac/dc for an unlimited period of time shall not cause damage other than to the I/O module to which it is connected.

Common mode rejection ratios of 60 dB or greater from DC to 60 Hz and normal mode rejection ratio of 30 dB or greater at 60 Hz are required.

Analog input and output modules shall provide pass through capability to exchange non-control data, both HART and Foundation Fieldbus, with asset management applications, utilizing the infrastructure of the system.

Different channels of same analog (4-20mA) input I/O card shall be able to connect to active (4 wire) and passive (2 wire) transmitters (mixed).

Digital output circuits shall be provided with protection for the switching of inductive loads.

The following configurable fail-safe options shall be available for each output module:

• Drive to zero output (4 mA for a 4-20 mA analog output, de-energized for a digital output)

• Maintain last good output value for an analog or hold for a digital output.

The fail-safe actions listed above shall be taken upon processor failure or communication break between the controller and the I/O module, if so configured.

The internal buses of control system, the power supply and the other I/O signals shall be galvanically isolated from each other and also from the external I/O signals. In addition, galvanic isolator shall be applied for all analog and discrete I/O channels to be isolated from the field connection.

Passive IS isolators (Zener barriers) are not accepted. Active intrinsically safety and galvanically isolator shall be used in case of intrinsically safe input and output needs.

Use of the 230 Vac DO card is not allowed. The 24 Vdc DO card via isolator interposing relays shall be used for the 230 Vac DO functions. The 24 Vdc relays shall be located in the relay cabinets.

Intensive and advanced diagnostic system shall be provided (e.g. line fail detection, input range check, “loop-back” check, etc.).

The field device failure alarm levels shall be selected:

• for analog input: extended range, input open;


8/26 Rev 1.00.01

• for analog output: output open detection;

• for status signals: wire break and shortcut detection.

Construction of DCS shall provide fast troubleshooting and repair of the cards under charge (“hot-swapping”) and shall provide I/O card replacement without disconnecting the wire/cables of I/O card.

Accuracy of analog input cards shall be better than 0.1 %.

The connection of 2.5mm2 (14 AWG) wire shall be provided at the connection of the I/O signals.

7.2 Types of I/O modules The I/O subsystem shall have the following types of I/O modules:

Type of I/O module Type of signal Note Analog Input 4-20 mA Conventional and HART

2 and 4 wires (passive and active)

Analog output 4-20 mA Conventional and HART

TC input J, K With coldpoint compensation

RTD input Pt 100 2/3/4 wires

Pulse input pulse modulated analog

Digital (discrete) input 24 Vdc, Dry contact Dry contact / Isolated

Digital (discrete) output 24 Vdc, Dry contact Dry contact / Isolated, On/Off, Momentary (Pulse)

Digital input SOE 24 Vdc 20 msec / timestamp

Serial Interface RS-232, RS-485/422 MODBUS-RTU master-slave

Foundation Fieldbus digital via bus FFB H1

7.2.1 HART I/O The system shall be capable of supporting HART inputs and outputs. The DCS system shall be able to read all variables provided by the field device.

7.2.2 Foundation Fieldbus I/O The H1 Module shall support control in the field or in the DCS system controller – i.e. it shall be possible to assign a function block to execute in the DCS system controller or in the field device without changes to the control strategy.

Appropriate power shall be provided to power all field devices on each H1 segment.

An LED indication of power, error condition, and status shall be provided on each H1 module.

Each H1 module shall be able to support a minimum of two segments. Each segment shall support a minimum of 16 Foundation Fieldbus devices (limitations of number of devices connected to an H1 e.g. IS solutions or control loop criticality specified in Fieldbus Foundation guidelines shall be considered: AG-181).

The H1 module shall communicate to the system controller on the same I/O bus as traditional I/O. The H1 module shall be an integral part of the I/O subsystem. No gateways or scanners are permitted.

The H1 module shall provide pass through capability to transfer non-control data to field device asset management applications.

8 Requirements on the controller functions

8.1 Control functions of the controller On the base of the EN 61131-3 standard the control functions shall be divided into the following larger groups:

• Function block diagram (FBD)

• Sequential Function Charts (SFC)

The controller – according to the EN 61131-3 standard – shall have the following algorithms and functions:

• I/O function block

• Computational Functions

• Control function block

• Digital logic and control function block


Rev 1.00.01 9/26

• Sequential function chart (SFC) block

8.2 Programming possibility The standard algorithms of the DCS does not provide complete solutions for each control function, therefore it shall have free or user programming possibilities. The program language shall use the commands, operations and functions (standard built in software components of DCS system).

8.3 Sequential Control The system shall be capable of performing the following sequential control without any modifications to the standard configuration software.

Sequence Language: A structured, EN 61131-3 compliant high-level control programming language shall be available and shall conform to the following specifications:

• It shall provide the necessary facilities for real-time control of sequential processes.

• It shall have access to process control and other database information.

• It shall be possible to modify the program logic while other sequences are active.

8.4 Application computer An application computer shall be provided which is able to perform standard supervisory control functions and fully integrated with the regulatory control functions.

It shall be possible for supervisory control applications to be scheduled, run on demand, or triggered by events.

Supervisory Control applications shall be executed by a dedicated hardware element that is an integrated part of the DCS system. In case of failure of this hardware, normal process control functions shall be executed by controllers.

The supervisory system shall have access privilege to the complete database, with privileges to change the following:

• Alarm limits, priorities, and enable/disable;

• Tuning parameters;

• Inputs to sequence blocks;

• Point status;

• Application schemes;

• Controller mode;

• Controller setpoint.

8.5 Advanced Control function in the DCS system The DCS database shall be able to (physically) connect to a third-party HOST computer via OPC protocol for the external application program (Advanced Control).

Advanced Control related loops (AC manipulated tags) shall be clearly visible to the operator in a standard faceplate display and all HMI display types.

Loop mode shall be switched by operator to local from remote (manipulated by Advanced Control) on demand.

All non AC related loops shall not be affected.

For more requirements of Advanced Control, see MGS-M-REF-6.4 & MGS-S-REF-6.4.

9 Requirements for Regulatory Control Function of D CS

9.1 Fault detection and handling Invalid value status shall be generated for inputs and propagated through control schemes if any of the following conditions are exist:

• value can not be transferred by the communication subsystem,

• value is out of range,

• value can not be measured or calculated,

• value is declared invalid by an application program,

• value is declared invalid by the source instrument.

It shall be possible for an invalid value status to be used as a logical input to initiate control algorithm changes.

When a control algorithm's input is declared invalid, it shall be possible to configure the output to fail as follows:


10/26 Rev 1.00.01

• Hold last good value,

• Zero output signal,

• Full-scale output.

In the event of communications subsystem failure, regulatory control algorithms shall continue operating with the last valid information.

9.2 Mode and connection All loops shall support bumpless transfer.

It shall be possible to configure data connection between (software) control modules running on different (hardware) components of DCS system (e.g. cascade setpoints). These communication shall be scheduled and executed by the system.

Control blocks shall be able to perform automatic mode switching based on external or internal logic inputs.

The control blocks shall offer the option of tracking for setpoint (update setpoint to the input value) or holding the last valid setpoint before initiating event.

For the primary controller (in cascade loop) an initialization option shall be available (the primary controller’s output tracks the secondary controller’s setpoint caused by state of the secondary controller).

When any tracking or initialization is active, this state shall be clearly visible to the operator in a standard faceplate display and all HMI display types. The state available as a parameter which can be accessed for either a graphic display or an application program.

Control functions with integral action shall provide windup protection (inhibit the integral action when the control block output is constrained by conditions). This state shall be clearly visible to the operator in a standard faceplate display and all HMI display types. The state available as a parameter which can be accessed for either a graphic display or an application program.

Control and computational functions shall include the ability to propagate the status parameters of connections (windup, initialization, etc.) through multilevel control strategies.

In case of FFB system, the control modes an initialization procedure of loops shall conform to Foundation Fieldbus guidelines (AG-181). Standard Foundation Fieldbus control algorithms shall be identical regardless of whether they reside in system controllers or the H1 field devices.

10 Requirements on operator interface

10.1 Operator Workstations and printers

10.1.1 Requirements on Operator Workstations Minimum two Operator Workstations shall be employed for each plant DCS.

Failure of any component shall not cause the failure of more than one workstation.

The Operator Workstations shall include as a minimum one display monitor, keyboard and pointing device.

Furniture/console-type (built-in) ergonomic operator workstations shall be supplied, included all related furniture (AUX consoles, workplaces, printer stands etc.).

User configurable buttons or screen targets to select operational functions or displays with a single entry shall be provided.

Workstations shall be able to be equipped with multiple display monitors per workplace. Each of these monitors shall be handled by a single keyboard and pointing device and shall be able to show more HMI displays (e.g. two different graphic displays) at the same time.

10.1.2 Requirements on printers At least one networked, color laser printer shall be supplied in the DCS system.

The capability of hardcopy of any active display shall be available from any operator (or engineering) workstations.

The system shall support both full color and black and white copies for all types of displays and lists.

Each operator workstation shall have access to all printers of DCS system via network.

10.2 Requirements on HMI displays Standard display set of HMI shall include overview, group, point (detailed individual loop), trend (single and multi-loop), process graphics, diagnostics, alarm and event journal.


Rev 1.00.01 11/26

10.2.1 Faceplate All loop controllers (or other tags) shall have own faceplates. These faceplates shall allow easy access to tuning variables, trending set point values (both local and remote), alarm settings, auto/manual, remote/local, and percent output. Faceplates shall show dynamic process and status information about a single control loop and shall permit an operator to change control parameter values or operation mode.

The system shall automatically provide default faceplates for each tag. User shall not be required to configure a faceplate display for each tag or control module.

Faceplates shall be defined to pop-up when the appropriate location on a process graphic is selected with the pointing device.

Faceplates shall display the following information:

• Tag ID.

• Tag descriptor.

• Process input, setpoint, and output values displayed numerically with engineering units.

• Process input in bar graph representation with scale divisions.

• Process setpoint and output in bar graph or in moving arrow representation.

• Auto/manual mode and remote/local setpoint status.

• Visual indication for alarm status.

• Symbolic and alphanumeric indication of discrete states both for two state devices and multi-state devices.

It shall be possible to perform the following control actions from a faceplate:

• Change control block mode.

• Change setpoint in auto mode

• Adjust outputs in manual mode

• Change other operator adjustable parameters.

• Issue commands to multi-state devices

Single faceplates shall be provided for control and indication of multi-state devices. For example, a motor operated valve shall indicate open, closed, intermediate position, and fault.

10.2.2 Group display HMI shall contain group display with faceplates of min. 8 tags (mixed control, analog, digital I/Os) for operator intervention.

Configuration possibility shall be provided to create new group displays (for selected loops).

Other important HMI displays (detail, alarm, trend display) shall be called by single operation from group display.

10.2.3 Detailed point display The detailed point display shall contain all important data of the selected loop, e.g. reference to the background algorithm with its parameters (e.g. P, I, D, filtering time constant), I/Os, alarm settings etc.

Change possibilities shall be provided for the parameters belong to the operator functions.

10.2.4 Controller tuning panel Each loop controller shall have a special trend panel for tuning. It shall show the loop controller tuning values and include the capability to change the loop controller tuning values while trending. Different colors shall be used for each parameter trended. The minimum controller parameters to be trended shall be Setpoint (SP), Process variable (PV) and controller output signal (OP).

Trending intervals shall be user selectable between 0.5 seconds to 5 seconds. The trend panel must show as a minimum between 2 minute and 20 minutes of trending. It can have its own short-period historical database to show curves and not necessary to be integrated into the real-time process database historical functions. Tuning panel may be a part of detailed point display.

10.2.5 Trend display The trend display shall provide a graphical curves of the real-time and historical values of process data of min. 8 optionally selected loops. Both historical and real-time trend information shall be integrated into a single trend within a trend window, with seamless movement between them. Different colors shall be used to each variable trended. Trend displays shall be reached by all operator workstations.


12/26 Rev 1.00.01

The trend display shall show time axis, engineering units of parameters, scale etc. to provide information for the operator. Zoom in/out and moving forward/back in time shall be possible. A mechanism for selecting a location on the trend, such as a hairline cursor and reading the digital values from the historical data at that point in time shall be provided.

Comprehensive analysis capabilities shall be included. Each trend of a graph may have different time references, and may be moved vertically, amplified, or compressed. In addition, an individual trend can be shifted in time to compare to trends at other points in time. Comparing a single tag at two different time intervals shall be possible on the same trend.

User trend displays shall be configured by operators to set up additional trend displays of selected variables for specific troubleshooting activities. Additional trend display capacity shall be available for at least 10 percent of the historical trend display groups.

10.2.6 Alarm summary This display shall show all current process alarms and shall not clear unless the alarm is acknowledged; and the item initiating the alarm has returned to normal condition.

Multi-page displays may be used. It shall be possible to page forward or backward by a single operator action. The display shall list alarms in tabular format in order of occurrence with the most recent at the top.

Alarm summary display shall provide a sequential display of alarm events, deviations from the pre-adjusted alarm values of the process parameters, and from the normal states of the discrete characteristics.

The alarm summary shall contain the date and time (DD:MM:YY hour-min-sec) of the event, its acknowledgement, and its end, as well as the name of the loop and the properties of the alarm event.

Determination of the sequence shall be provided based on time of the events.

Alarm summary shall provide sorting and filtering possibility by tagname, area, priority etc. of the alarm events.

Access the associated (graphic, detailed or faceplate) display shall be possible by simple operator action.

10.2.7 Real time graphic display All process parameters shall be accessible through the graphic display. Navigation through the displays should be easy and intuitive. One overview graphic display per process unit shall be provided in order to quickly access the detailed graphics.

Pop-up functions (faceplates, trends, reports, etc.) should allow large amounts of detailed information to be quickly accessed without extensive clutter on a process graphic.

Photos and scan images shall be possible to use in a graphic display to help an operator easily identify the process parameters being operated. Dynamic information shall easily be added to the images.

New graphic display shall be possible to place in service without interrupting an operator's ability to control the plant.

Graphic display shall use the symbols and marks conventionally used in the technical practice (e.g. different colors for the process flows, standard symbols for the equipments and instruments, etc.).

The graphic display shall show the current measured characteristics and/or calculated parameters in numerical or graphical form (e.g. column graph, trend etc.) and shall cyclically refresh them.

All control, monitoring, and status attributes of any tag shall be displayable on graphics. For analog points this requirement includes measurement, setpoint, alarm limits, and output. For digital points this requirement includes input and output status. Status information includes: alarm status, control mode, and control status.

Numeric data shall be configurable on an individual basis. If the decimal point is not used, it shall be suppressed.

State indication shall be possible for each state of a multi-state device by unique foreground/background color combination.

Symbolic representation of data on the graphics shall be performed by color changes (foreground and background independently), and flashing in any combination.

Screen target shall be possible to configure to call up other displays.

10.2.8 Event journal display All events generated by the system shall be captured and electronically logged chronologically to the event database on a hard disk on one or more designated workstations. Events shall be time-stamped by the event generator. Events and their associated time stamp are passed to the event handler for capture.

It shall be possible to retrieve and sort events by time (ascending or descending order) or by type. The Operator shall be able to filter the events on certain criteria such as time, tag/source, or any specific fields. Events and the historical trend information for a control tag shall be integrated into a single view.


Rev 1.00.01 13/26

All events shall be time stamped at the point of origin. Events generated in the controller shall be time-stamped in the controller. Those generated in the workstation shall be time stamped in the workstation.

10.2.9 System and Diagnostic Displays On-line and off-line diagnostics shall be provided to assist in system maintenance and troubleshooting. Diagnostics shall be provided for every major system components and peripherals. This shall include segment as well as device diagnostics and firmware diagnostics in the devices. If diagnostics do not exist for particular peripheral devices (for example printers and terminals,) the system must detect and provide an error indication for the failure of these devices.

It shall be possible to configure, monitor, and troubleshoot Foundation Fieldbus devices and HART devices from the control room. The DCS system shall be capable of storing calibration information and device status history for each field device. It shall also be possible for the DCS system to upload field device configuration changes implemented in the field. Once the configuration information is stored in the DCS system, it shall be possible to download it to any other similar device, whether a new or replacement device.

Existing signal wiring shall be used to pass field device data to the diagnostic utility. This shall not degrade the operation of the system in any way.

Remote access shall be possible by modem for remote troubleshooting purposes. User shall have the capability to disable this feature without disconnecting the modem.

Diagnostics displays shall provide exact state of the integrated control system for the operators and maintenance personnel and shall contain the state of all units and network elements of the control system, and provide detailed information if required.

Communication System Status Displays: Standard displays shall show the operational status of the communication system. The communication parameters of each module connected to the communication system (on-line, off-line, failed, primary failed, backup failed) shall be shown. Displays shall show errors for each of the redundant paths.

On-line displays shall indicate the results of self-diagnostic tests. Failure diagnosis shall be sufficiently specific to indicate which modules or devices are at fault. The displays shall be designed to help maintenance and engineering personnel diagnose faults in the system and communications paths. Each category of diagnostic display shall be organized hierarchically.

10.2.10 Process Visualization Strategy for fieldbus system The process visualization shall be configured to show only the information that is relevant to the process.

Displayed information of conventional and fieldbus tags shall be consistent.

10.2.11 Other display requirements Display reaction time : Any kind of displays shall be appeared on the screen in 1 second from operator initiation.

Data refresh : All type of display shall be automatically refreshed by real-time database. All numeric and dynamic display data shall be updated in 3 seconds from first appearing of the page and shall be cyclically updated by 1 second. Updates shall not require operator initiation.

Value integrity : Displayed values of the process shall show its status too. Data with abnormal state (bad conditions – not working transmitter, broken wire, bad I/O card or communication, etc.) shall be well recognizable on all related displays. Special indication shall be used to indicate that a value is NOT valid. Any dynamic or numeric data of any displays shall not show older value than 1 second.

Displays and Graphics Access : Operators shall be able to easily access specific displays and graphics by pressing dedicated function keys or screen targets, selecting from a list of displays in directories or menus, or by typing display or graphic names. Hierarchical Displays : Moving shall be possible between related displays and graphics of different detail levels or of the same detail level with a maximum of two operator actions.

Paging : Cycling through a predefined series of displays shall be possible with a maximum of one operator action.

Inactive alarm or status messages shall be invisible to the operator.

10.3 Requirements on reports Reports shall provide printed form of management information, data summaries according to the requirements of the plant management and the operator, tables and accounts.

Using of any variable or calculated value of real-time process database shall be possible in a report.

Reports shall be possible to be displayed on an operator workstation or printed on a hardcopy printer and/or saved to the disk.

Hourly, daily, monthly, end-of-month, quarterly and yearly reports shall be supported.


14/26 Rev 1.00.01

Reports shall be activated by following events:

• On demand (operator request);

• Scheduled (shift, daily and monthly);

• Special process event.

Report shall be possible to be exported into MS-Excel format.

System shall provide integrated standard report formats (alarm, event, hourly average, daily average, etc.).

11 Requirements on database

11.1 System Access Access to databases or DCS system functions shall be restricted by using passwords. Identified users shall be possible to define with unique access privileges. It shall also be possible to define groups of users. All users within each group shall have the same privileges.

Access to the areas of the plant shall also be limited by access privileges.

The access to the system shall be global for the entire DCS based on user privileges.

At least three access levels shall be provided:

• Operator

• Supervisor

• Engineer (configurator).

11.2 Requirements on configuration database The DCS system shall use a common, global configuration database to be shared by all components of the system.

The access to the configuration database (enter data, modification, deleting) shall be controlled by the security functions of the system. All modification in the system configuration database shall be logged in the system journal.

System configuration database shall be stored on highly reliable store device (redundant: e.g. RAID: Redundant Array of Independent Disks technology: RAID1 or RAID5). Database shall be possible to backup/restore to/from an external storage device by the engineer.

11.3 Requirements on real-time process database The real-time process database shall be capable of updating all tags with minimum 1 second frequency.

All process variable values, controller set point values, and controller output values shall be stored digitally in non-volatile memory or hard disk within the control system equipment.

Database integrity shall be guaranteed by reliable store device (e.g. RAID1 or RAID5) or other database redundancy. Historical data collection shall be made automatically by centralized configuration.

No distinction shall be made between direct process variables (e.g. flow, temperature, pressure, level, etc.) or indirect calculated process variables (e.g. velocity, density, ratio, concentration, etc.).

All process variables, controller set points and controller outputs shall be sampled and the real-time values shall be stored at intervals according to the chart below.

Storage capacity shall be sufficient to store process variable data, controller set point data, and controller output data for at least the previous 10 day period. Only “lossless” data compression techniques may be used during this period. The control system equipment shall be able to access and display the stored data at the operator station console and/or other console on demand at any time.


Rev 1.00.01 15/26

Real-time process data history requirements:

Type of data Parameter / type Sampling time History time (lossless)

History time (compressed)

Analog input PV / snapshot 60 sec > 10 days > 100 days

Analog input PV / average 1, 8, 24 hours > 10 days > 1 year

Control PV, SP, OP / snapshot 15 - 60 sec > 10 days > 100 days

Control PV / average 1, 8, 24 hours > 10 days > 1 year

Periodic safety saving of the real-time process database shall provide to external data storage. This off-line database shall be observed by special viewer software for real reproducibility and analization of past processes for several years.

11.4 Requirements on alarm and event database

11.4.1 General requirements on alarm and event data base All alarms and events shall be stored digitally in non-volatile memory or hard disk within the control system equipment. Database integrity shall be guaranteed by reliable store device (e.g. RAID1 or RAID5) or other database redundancy. Collection shall be made automatically by centralized configuration.

The alarm and event journal shall have at least 15,000 recording places for each type of alarms & events.

Periodic safety saving of the alarm & event database shall provide to external data storage. This off-line database shall be observed by special viewer software for real reproducibility and analization of past processes for several years.

The alarm and event database shall automatically store the followings:

• Process alarm (event, acknowledge, end)

• System alarm (event, acknowledge, end)

• System state change (event)

• Operator intervention (event)

• Operator message (event, acknowledge)

11.4.2 Alarming system Detailed requirements: MGS-M-REF-I-6.9 & MGS-S-REF-I-6.9: Alarm System and HMI display design and implementation.

The alarm function shall be permissible and shall have possibility to prohibit by loops, process units and areas. A list of inhibited alarms shall be available to be displayed and printed.

It shall have multilevel configurable alarm priority (journal, low, high, emergency etc.).

All alarms for a process area may be assigned to any operator workstation at configuration time. All alarms shall be displayed on the workstation(s) designated. The audible alarm shall be user configurable for different tones or patterns.

The system shall have an adjustable volume control.

The system shall use global alarm acknowledgement allowing a single acknowledgement from any workstation to acknowledge that alarm on all workstations and to silence the audible alarm.

The alarm system shall have SOE (Sequence Of Events) journal possibility, with time resolution less than 50 msec.

Alarms shall cause visible display annunciation at (and only at) a Workstation configured for those alarms. The annunciation shall occur within 3 seconds of detecting the initiating event. It shall be possible to acknowledge process alarms only from a Workstation configured for those alarms. It shall be possible for an operator to acknowledge any alarm configured at his Workstation by no more than two actions. An alarm shall be acknowledgeable only if it is shown on a visible display.

11.4.2.1 Process Alarm Initiation Initiating process alarms shall be possible by configuring alarm attributes of any process I/O point or any DCS system point calculated from process I/O or internal calculation.

Dead band parameters shall be configured on individual alarm basis which include:

• On delay time

• Enable delay time


16/26 Rev 1.00.01

• Off delay time

• Alarm hysteresis

User specific alarms shall be possible to be added to any tag in the system. These alarms can utilize any parameter, perform calculations, etc. to determine unique alarm conditions.

For analog tags, the configurable triggers for process alarms shall include:

• Process variable high limit exceeded

• Process variable high high limit exceeded

• Process variable low limit exceeded

• Process variable low low limit exceeded

• Process variable rate-of-change high

• Process variable deviation from setpoint

• Process variable invalid value

For digital tags, the configurable triggers for process alarms shall include

• either state

• change of state.

11.4.2.2 System Alarm Initiation All devices connected to the DCS system communication network shall be monitored for failures. A system alarm shall be generated for each failure detected.

12 Requirements on the developing environment

12.1 Engineering Workstation An engineering workstation shall be provided for DCS system with minimum one display, keyboard and mouse.

Location of engineering workstation shall be well separated from operator workstations or any unauthorized people.

Removable storage media shall be provided for engineering workstation.

12.2 Requirements for configuration tools Developing/configuration tools shall be integrated into the system and shall provide generating or modifying database and configuration data with the following functions:

• Database generation, modification and backup

• Configuration of standard displays

• Graphic display generation and modification

• Control algorithm generation and modification

• Report generation and modification

• System access configuration (user and group managing)

• Down/uploading to/from the system

• Software/firmware upgrading of system elements

• File access and backup

• Testing & diagnostics

• Utility program access

An interactive editor shall be provided for building and maintaining the system configuration database.

The editor shall be capable of import/export from/to at least one of general database file types (xls, dbf, csv, etc.).

Access shall be provided for multiple users and logging of any database changes.

The configuration tool shall employ fill-in-the-blanks or graphical block connecting format. It shall have step-by-step prompts to guide sequential actions followed by validation responses on completion of the actions. It shall request only applicable information based on previous responses.

A common configuration tool shall be used for traditional and Foundation Fieldbus based control. Selecting the location of control in the system controller or in the field device shall be supported. Configuration of the control module shall be the same regardless of where the control is located.


Rev 1.00.01 17/26

User shall be able to view control strategies as defined in the configuration while they execute in real-time, as well as view the real-time input and output values. When a tag is selected, the operator shall be able to press a single button to view the control strategy. No additional configuration shall be necessary to provide this functionality.

Configuration tool shall support off-line development (e.g. off-line database and graphical display creation), simulation and off-line testing, and shall have on-line help and documentation.

On-line modification during operation without any affection of non-changed elements shall be supported.

Configuration tools shall have self-documentation.

13 Requirements for application software

13.1 Functional Design Study for application softwa re Before software implementation phase, all designed application software components shall be approved by Client. Software Functional Design Study (FDS) documentation shall be created by the Vendor includes the following elements:

• System drawing of ICS system;

• Short description about supplied DCS system (hardware, required upgrades, new components, operator workstations, using of fieldbus);

• Subsystem integration methods, communication subsystems (SIS, APC, rotating machine monitoring, package units, gas alarm system, etc.), RIS connection;

• DCS tagname conventions;

• Hierarchy solutions of DCS application (process areas, units, operation groups etc.)

• Applicable graphics picture translation rules, color code, symbols, etc.;

• All of designed graphics pictures (includes for all package, subsystem, SIS, etc. See later);

• Typical solutions for control loops and other monitoring points (conventional and fieldbus, with operator faceplates);

• Typical solutions for device controlling (MOVs, pumps, etc., with operator faceplates);

• List of I/O allocation (included built in spares);

• Load of controllers (and communication lines) to be expected;

• Percentage of spares to be supplied (CPU load, I/Os, empty cards, historization etc.);

• Alarming and event conventions (with typical examples);

• Historization conventions (with typical examples);

• List of control loops (with integrity level and control response period);

• List of other loops (with control period);

• List of operation groups;

• Description of special algorithms (e.g. sequence control, non-typical solutions);

• Description of logic and calculations;

• Short description of new or non-standard operator functions;

• Reports.

13.2 General requirements for application software Any textual information (in descriptions, captions, graphic images, etc.) shall be specified in local language.

The configuration, graphics picture development, reporting etc. applied at the existing DCSs in operation shall be considered when designing and implementing the DCS application software.

The control tasks for the particular technology process shall be specified during the design phase. The control tasks shall be indicated in the piping and instrumentation diagram (P&I), applying the standard tag system, the letter codes specifying the functions as well as the signal and function connections. In the P&I, the ICS tasks as well as their implementation method and place shall be unambiguously specified (e.g. DCS, SIS, PLC, etc.).

It shall be aimed at having the name and function of the DCS function blocks represented in the P&I and those of the DCS function blocks to be implemented shall correspond to one another.

13.3 Rules for tag database building General rules for tagname creation are specified in MGS-M-REF-I-10 MGS-S-REF-I-10.

For limited DCS tagname convention, the following variations shall be considered:


18/26 Rev 1.00.01

• “Alarm” = “A” character can be omitted.

• For alarms, “High” =”H”; “Low” = “L” (and “LL”, ”HH”) characters can be deleted.

• “Indication”= “I” character can also be omitted.

• Internal DCS tagnames shall be defined as variation of the base tagname with addition of extra characters (e.g. “_IN” or “_OUT1”) or replaced one character at right position (e.g. “BPT001” for transmitter analog input of BPC001).

Usable engineering units are defined in MGS-M-REF-I-4 & MGS-S-REF-I-4

13.4 Configuration of control loops The output of the control loop (OP, OUT) and the AO shall always show the opened position in percentages, that is the 0% shall always mean closed, and the 100% shall always mean opened position, independently from the operation direction of the actuator unit (FC, FO).

The switchover of the controller mode (MAN-AUT, AUT-CAS) shall be bumpless in the outlet.

Failure of the control signal of the regulator (PV) shall cause no bump in the outlet of the regulator (OP, OUT), and its mode shall change to manual (MAN).

The normal operational mode of each regulator shall be unambiguously indicated (e.g. MAN, AUT, CAS etc.).

13.5 Rules for operator group building Each analogue point (indication, regulation, etc.) as well as each point operable by operator (e.g. open-close, start-stop, etc.) shall be allocated to an operator group.

Points conjugated from process and operating point of view shall be arranged in the same group.

The name of the operator group shall refer to the process unit or the particular control task.

The operator group including the analogue points shall have connected trend display.

13.6 Rules for graphics picture building (see also: MGS-M-REF-6.9 & MGS-S-REF-6.9) All the graphics displays shall follow the graphics display building rules (structure, color codes, standard image components, etc.) applied at the existing DCS in operation.

The graphics displays shall transform the controlled process structure in a simplified way. They shall furthermore include the static and dynamic information in suitable quantity and depth.

In case of logic displays, the coloring and dynamic elements shall be designed that information are simple, clear a helpful enough for the operator in all state of logic. Non-important information shall be hide to avoid any misunderstanding.

The graphics displays shall be arranged in a hierarchy, from the overall images to the detailed images. The graphics displays - in accordance with the hierarchy - shall be connected to one another, making navigation amongst the graphic displays easier. The DCS shall have a main graphics picture (menu).

The graphics display shall include navigation fields with the help of which the most essential HMI interfaces (e.g. alarm summary, group image, trend, etc.) can be reached.

The most representative graphics picture shall be allocated to all tags configured in the DCS, and it shall be capable of being launched with one operator action.

Using operator workstations, the operators shall be prohibited from reaching operating system capabilities, opening desktop or running other applications.

The application software shall have the following essential displays:

• Main menu (display navigator);

• Overview display (base material, with product flows);

• Process flow charts (with static and dynamic information);

• Flow charts for utility or package subsystems (with static and dynamic information);

• SIS system logic display (includes logic, actual status, interlock setting values, POS/MOS status, more important timings (e.g. airing time), SIS outlet status);

• Status indication of rotary machines (START-STOP, LOCAL-REMOTE, running hours, etc.);

• Material and energy balance (with yield information);

• Technological process card, operational setting value image;

• Display for setting laboratory data, analysis, and parameters;

• System status display (PS, UPS, SIS, PLC, communication lines);


Rev 1.00.01 19/26

• Status of gas alarm system;

• Other auxiliary information displays.

14 RIS connection (see MGS-M-REF-6.7 & MGS-S-REF-6. 7)

15 Power supply requirements Powering of DCS cabinets and other dual-powered equipments:see App.

Each DCS cabinet shall have two independent and separated power supply inputs with circuit breaker. All internal power supply unit (e.g. I/O power of 24Vdc) shall be delivered.

Each operator workstation and other single powered equipments of DCS system shall be powered with UPS 230Vac by independent circuit breaker in the existing Power Distributor Cabinet of the control room.

Each workstation shall be capable of being taken off-line or powered down independently, without affecting the operation of the controls system, including the other workstations.

All installed circuit breakers and/or Power Supply Units (or power lines) shall have monitoring capability (e.g. voltage-free contact), which provides a signal for diagnostics on the DCS system in any case of power failure.

Redundant elements of the DCS (primary and backup) shall be equipped with power supply independently and separated from one another. In case of one power supply (UPS or non-UPS) down, all functions of control system shall be continued without affecting the operation.

Power system of DCS marshalling cabinets and other interface cabinets shall be designed in such a way that the broken down power supply unit can be switched off, removed and replaced without interruption in the power supply.

Loop-powered (2-wired) field equipments shall be powered by isolator units from the marshalling cabinet.

Non-loop-powered, 24Vdc (4-wired) field equipments shall be powered via power distributor terminals from the marshalling cabinet. Each equipment shall have its own fuse and shall have status indication (e.g. LED) which makes the identification of the broken fuse.

230Vac powered field (instrumentation) equipments shall be powered by independent circuit breaker in the existing Power Distributor Cabinet of the control room (UPS).

See: MGS-M-REF-12.7 & MGS-S-REF-I-12.7

16 Requirements for the grounding system Manufacturer shall provide an overall schematic diagram of the grounding requirements of the complete system. The system Manufacturer shall provide the designer, contractor and maintenance staff with data on the grounding requirements of the system.

The grounding diagram shall include all the equipment and devices to be grounded, the grounding points, the applied grounding lines (indicating cross-section and lengths), as well as the necessary grounding bar (with dimensions).

When extending an existing system, the system Manufacturer shall consider the grounding layout of the existing systems, and it shall match the grounding diagram of the new system to the existing one.

The system Manufacturer shall consider the relevant and effective standards (e.g. application of line color codes, etc.).

There is a common neutral grounding system (three phase + neutral, with grounded common point) in plants of MOL Group refineries (hereinafter NEPEN).

All available metal structures (cabinets, frames, etc.) and any metal structures becoming under voltage shall be connected to the grounding system.

All electrical devices shall be connected to the grounding system, and their external grounding point shall be unambiguously marked.

The system elements shall have specified grounding points. The design of the grounding point shall meet the requirements of the system Manufacturer (e.g. grounding resistance). The grounding resistance shall be less than 1 Ohm.

No protection grounding independent from the grounding system unified with the neutral conductor can be used in the plant.

When designing the grounding, the development of ground current loops as well as the effect of electrical circuits on one another shall be avoided.


20/26 Rev 1.00.01

It is of general effect that the shielding of the cables and the signal cables may only be grounded in the control room.

The grounding of the shield and the signal cable shall be arranged separated from the grounding of the metallic structures and the network, and shall be connected electrically at one point.

For the grounding of the shield and the signal cable, a copper-grounding conductor of a cross section of at least 75 mm2 arranged separately of the metallic structure, in each cabinet.

See: MGS-M-REF-12.7 & MGS-S-REF-I-12.7

17 Requirements on cabling and wiring The cable connections for the cabinets shall be ensured from underneath.

Due to the connection of the field cable shields, the cabinet shall be equipped with an insulated shielding bus, which shall be equipped with sliding screwed clamps.

In the cabinets, for fixing the cables, and the grounding of the armouring of the cables, a grounding bus shall be installed, which shall be connected to the grounding star-point of the control room.

The cables shall be clamped with a fixing tool equipped with clamps.

The electrical equipment, the wiring, the terminal blocks and the connectors shall comply with the electrical classification of the control room.

On the other side of the terminal blocks for the connection of the multi-wire cables, individual wire shall be used.

For the connection of the field cables, openable (blade contact) terminal blocks shall be used (except for the 3-wired RTD or TC signals).

For the power, outlet, inlet signals as well as for those of different voltage level, different terminal strips shall be provided.

For the connection of the signal cables of the I/O cards in the DCS, as many terminal blocks shall be installed as to have enough for the connection of all the I/O channels. The terminal strip assignment shall follow the channel assignment of the I/O card in order.

Intrinsically safe signals shall be separated from any other signal lines, and shall also be differentiated with blue color and a label. Terminal strips for receiving intrinsically safe signals shall be blue, and shall be separated inside the cabinet.

Special care shall be taken for the separation of the signal cables from the power supplies one.

Cables with different signal kinds, as well as cables with different voltage levels shall be installed separately from each other. In equipment, the wiring shall be arranged separated by voltage levels, they shall be fixed in wire-chases.

The individual lined cross-wiring between cabinets shall be avoided.

In the signal distribution or marshalling cabinets, the terminal strip assignment shall be designed in such a way that it shall follow the wire assignment of the multi-wire cables in order, including the spare wires as well.

Each cables and lines shall be installed in cable channels, no loose lines are allowed.

Each equipment element and connected terminal strips shall be equipped with a label.

The connection of the stranded (flexible) wires and the taking in of the wires shall be solved with moulded wire chucks.

Multi-wire cable connections shall be provided by Manufacturer (with system cable connector) between the cabinets, the cabinets and the operating panel, and the operating panel and printers.

Manufacturer shall perform wiring and cabling inside cabinets at their own site.

The wiring customs and wires marking of the manufacturer can be applied, but they shall meet any international standards.

The contractor on site shall do the cabling among the cabinet groups; the Manufacturer shall specify the cables.

The layout of the cabinets shall be of such as to minimize the quantity of the connection cables.

Multi-wire optical cables shall be included in optical distribution cabinet. Manufacturer shall specify the necessary optical cables and all the optical devices necessary for their connection. The system Manufacturer is responsible for the finish, certifying, connecting and installing the optical cables.

The system Manufacturer shall install the spares necessary for the wiring and cabling to the system.


Rev 1.00.01 21/26

18 Constructional requirements for cabinets

18.1 General requirements The design of cabinets shall follow the Project Specification of the Client. Each cabinet (DCS, MC, relay, etc.) shall be of the same color (default: RAL7032).

Each cabinet shall have removable lifting eyes, which shall be removed, after the cabinet has been installed.

The cables and wires are conducted into the cabinets from underneath, therefore the lower cover plate of the cabinets shall be removable, or cover plate capable of cable entry shall be used. The lower part of the cabinet shall include a fixing device with clamps for fixing the cables, or a clamping bar which shall be equipped with sliding screwed clamps.

The supplied cabinets shall be connectable and ranged to one another. The side plates shall be removable, and shall have suitable fittings for connection.

The opening direction of the doors shall be such that they shall not open opposite to the escape route direction.

The DCS system cabinets shall be lockable.

The doors shall be removable.

The accessibility of the cabinets shall be ensured both from the front and the rear; the devices in the cabinets shall be well accessible and serviceable.

In the cabinet, cooling fan suitable for its heat dissipation shall be used. The breakdown of one fan in the cabinet shall not cause the overheating of the cabinet. The broken down fan shall generate an alarm in the DCS with a voltage free and NC normally closed contact.

The DSC cabinets shall be equipped with thermometers and the temperature value shall be displayed and alarmed on the DCSEach cabinet shall have an internal lightning fed by UPS and separated with a fuse.

Each marshalling cabinet shall have a grounded 230Vac/50Hz socket fed by normal mains power supply and separated by a fuse.

The contact for the breakdown of the fan and the voltage-free contact of the temperature switch can be stringed. The system Manufacturer is responsible for the integration of the alarm signals of the cabinets into the DCS.

Replaceable dust collector filters shall be fixed to the bottom of the doors.

Each cabinet shall have a document storage pocket of A4 size.

18.2 Nameplates, cable and wire tagnames, labelling Each device installed in the system and in the cabinets (e.g. I/O cards, I/O terminal panels, circuit breakers, terminal strips, etc.) shall be unambiguously tagged. The tags used in the drawings and the system documentation as well as in the implemented system shall correspond to one another.

The connection of the particular I/O card and the terminal panel shall be unambiguously specifiable on the basis of the I/O cards and the connected I/O terminal tags. The internal system configuration id of the system I/O card and the I/O card and the terminal panel id shall be unambiguously match and identifiable.

The devices installed in the system shall be located so that their type and serial number shall be identifiable.

Each line and cable shall be unambiguously tagged. The wires of the cables as well as the individual wires shall be equipped with id tags, which shall refer to the place of connection. The id tag of the DCS system cables shall include furthermore the “from where-to where” connection information.

The cabinets shall be equipped with labels. When naming the cabinets, the following name conventions shall be applied:

Description Plant code

Cabinet property

Number of devices Cabinet name

Marshalling cabinet XXX MC 01..n XXXMC01..n-F/R

DCS cabinet XXX DCS 01..n XXXDCS01..n-F/R

Relay cabinet XXX RC 01..n XXXRC01..n-F/R

Power supply cabinet XXX PS 01..n XXXPS01..n-F/R

UPS cabinet XXX UPS 01..n XXXUPS01..n-F/R

Power distribution cabinet

XXX PDC 01..n XXXPD01..n-F/R

Local panel XXX LCP 01..n XXXLCP01..n-F/R

Central panel XXX MCP 01..n XXXMCP01..n-F/R


22/26 Rev 1.00.01

Description Plant code

Cabinet property

Number of devices Cabinet name

Control board XXX CB 01..n XXXCB01..n-F/R

Operator station XXX OPS 01..n XXXOPS01..n-F/R

Printer XXX PRT 01..n XXXPRT01..n-F/R

Console XXX CON 01..n XXXCON01..n-F/R The labels of the cabinets shall furthermore be equipped with F (Front) and R (Rear) tags.

The labels, cable and line tags applied during the construction assembly of the system shall be fixed solidly, the texts shall be weather and UV-proof, and easily identifiable. Engraved labels shall be applied.

19 Requirements for Manufacturer services Manufacturer shall provide the following services for the supplied equipment:

• All the design data determining the local adaptation and interfacing of the process control system, including the grounding plan for the system, as well as the requirements on the grounding design, requirements for the power supply, data provision for the I/O interface connection points, etc.

• The check list for the tasks before commissioning.

• The on-site technical supervision and control for the installation, commissioning, checking and setup of the equipment.

• The necessary training for the Client’s staff—system engineer, maintenance staff and operators.

• Manufacturer shall provide the documentation necessary for the approval of the supplied equipment by the national authorities, as well as the documentation required by the approving authority, and the quality certifications of the supplied devices. Manufacturer’s responsibility extends to the products and services by any third party involved by Manufacturer. Manufacturer shall provide guarantee on the devices and services supplied by Manufacturer, as well as on the solution and trouble-free operation of the process control tasks. Manufacturer shall not be released from their guarantee responsibilities even in the case if their assessment of the devices or services necessary for the solution of the task was wrong.

20 Tests It is strictly required that the DCS system shall be supplied as a “complete operating system”, including basic devices and connected subsystems and any engineering services such as system and information network generation, configuration, programming and system integration.

Integrated FAT/SAT shall be provided with all related subsystems physically connected to the DCS system (DCS operator display is the HMI of the SIS, connected PLC system and so on, these all shall be installed at FAT procedure).

The tests shall be performed on the basis of the latest approved specification, instrumentation design, data provision and the signed contract.

The tests to be described may not be replaced with the system manufacturer’s own test.

20.1 FAT, SAT requirements (see also MGS-M-REF-I-13 .1, MGS-M-REF-I-13.2 and MGS-S-REF-I-13.1, MGS-S-REF-I-13.2)

The purpose of the FAT, SAT tests is to establish whether the DCS and the connected subsystems are designed, installed and configured in accordance with the specification.

The tests shall be performed at the manufacturer’s premises (Factory Acceptance Test: FAT), and shall be repeated after the assembly work has been completed at the user’s premises (Site Acceptance Test: SAT).

The Manufacturer of the DCS shall install and operate the complete control system and its connected subsystems at their premises before delivery.

The DCS Manufacturer shall perform their own standard internal test before the FAT, and present its certification to the Client. Manufacturer’s internal test shall include a complete system check, supplemented with the hardware, software and control functions of all the subsystems (e.g. PLC, SIS, packages, etc.), paying special attention to the communication of the connected systems.

The DCS Manufacturer shall operate the complete system continuously for a period of 48 hours. The hardware tests shall be performed during this period.

The DCS Manufacturer shall perform the FAT with the Client present.

Ten weeks before the tests, Manufacturer shall hand over the detailed description of the standard tests (FAT, SAT protocols) to the Client, as well as the program and the schedule of the tests. Manufacturer shall provide one copy


Rev 1.00.01 23/26

of an as-built documentation on the system as the attachment to the test protocol. Client shall approve the FAT and SAT protocols.

The testing of the application software and control functions on the basis of the data provision by the Designer shall also be part of the FAT and SAT.

The system Manufacturer shall provide suitable testing devices, testing systems and qualified personnel to proceed with the tests according to schedule. Protocol shall be prepared of each test.

The participation of the representatives of the Client shall not in any way release the system Manufacturer from their guarantee responsibilities regarding material quality, installation, production and operability. The tests shall include but not be limited to the followings:

20.1.1 DCS hardware test

• The DCS Manufacturer shall implement all electrical (e.g. system cabling, power supply, grounding, internal cabling, etc.) and communication connections (e.g. DCS-PLC, optical (FO) connections, etc.) for the testing of the DCS and the connected subsystems.

• Quantity and type checking of the installed hardware according to the hardware specification and the contract.

• Quantity and type checking of spare parts.

• Checking of documentation, certificates and software licenses.

• Visual checking of the system, checking for constructional, mechanical integrity, as well as for the system being unbroken and free of damages.

• Checking for the completion of the installed units.

• Checking of the power supply of the DCS system according to the power supply diagram (UPS and PS).

• Checking of the system alarm of the installed UPS units.

• Checking of the cooling of the DCS system cabinets (fans).

• Checking of the grounding of the control system according to the grounding and shielding diagrams.

• Checking of the labels (cable labels, etc.) of the control system.

• Checking of the system cabling of the control system.

• Checking of the adequacy of the - mechanical and electrical - connections (from protection, separation and grading aspects).

• Checking of terminal strips assignment and internal cabling.

• Checking of the connection of the control system and the subsystems, system integrity testing.

• Checking of inputs and outputs on accordance with the measurement circuit diagrams and the system drawings. The checking of inputs and outputs shall extend to each I/O card, and at least 10% of the I/O points shall be checked.

• Redundancy checking.

20.1.2 DCS application software test

• Checking of the DCS system basic functions according to the standard FAT protocol of the Manufacturer of the control system (e.g. operator functions, alarm and reporting functions, etc.).

• Complete checking of the DCS and the application software and control functions of its connected subsystems.

• The system Manufacturer shall ensure test system, simulation solutions and test settings for the checking of the application. After the FAT checking have been completed, Manufacturer shall ensure the elimination and deletion of the simulation and test environment for the testing.

• Checking of the configuration of the I/O subsystem:

o AI: Checking of hardware position, measuring range, unit of measure, input linearization, alarm settings, etc.

o AO: Checking of hardware position, output direction (FO/FC) and “safe” status.

o DI: Checking of hardware position, statuses, and alarm status.

o DO: Checking of hardware position, statuses, “safe status”.

• Checking of control algorithms:

o Checking of the connection of function blocks (e.g. cascade connection).


24/26 Rev 1.00.01

o Checking of the settings of function blocks (e.g. PID parameters, control direction, alarm settings).

o Checking of logic control tasks in accordance with logic and control diagram.

o Checking of sequential control tasks.

• Checking of the connections of subsystems in accordance with the communication charts.

• Checking of SIS system connections (e.g. SOE event log).

• Checking of user operation interfaces.

• Checking of dynamic and static contents of graphics pictures in accordance with P&I.

• Checking of dynamic and static contents of reports.

• Checking of high control level algorithms (e.g. APC functions).

21 Documentation contents

21.1 DCS proposal documentation contents Textual documentation with drawings on the basis of which the operational principle and operation mode can be unambiguously understood and assessed. The proposed documentation shall include the following documentation:

• DCS structure, elements and connections

• Structure of information networks, subsystem connections

• Description of applied information technologies

• Control room layout, internal view plan

• System functions with their capacity

• Power supply requirements

• Requirements for the grounding system

• Grounding, shielding and typical loop drawings.

• Spare part requirements

• Maintenance demand, maintenance constructions

• Environmental and application conditions

• Certificates of internationally recognised testing institutes

The proposal shall include furthermore the description, type number or id, quantity, unit prices for the system elements (hardware, software, services) as well as options or alternatives.

Any deviations from the enquiry shall be listed separately.

21.2 DCS standard documentation contents Textual documentation with drawings on the basis of which a suitable amount of information can be obtained for the design, installation, application software development and maintenance. The documentation can be stored electronically, e.g. on CD-ROM (Adobe Acrobat (pdf) format). The supplied integrated control system documentation shall include the following documentation:

• DCS overview (system concept)

• DCS design requirements (specifications and technical data)

• DCS installation instructions (constructional design, power supply, grounding, etc.).

• DCS maintenance instructions (manuals)

• DCS operation manual

• DCS engineering reference manuals

• DCS system software installation, system settings, network devices configuration.

• Software licences, authority, author permits, etc.

• DCS application software manuals (software installation, building, testing and documentation manuals)

• Documentation for products and subsystems supplied by third parties

21.3 DCS as-built documentation contents Textual documentation with drawings includes the hardware and software documentation for the installed and as-built system. The DCS hardware and software documentation shall be issued in the second week after the successful FAT procedure, before the DCS on-site installation, and the as-built documentation in the fourth week


Rev 1.00.01 25/26

after the successful SAT procedure. The implemented integrated control system documentation shall include the following documentation.

21.3.1 DCS system documentation

• Detailed design specification

• List of installed devices with type, serial number, as well as hardware and firmware revision.

• System overview drawing of the integrated control system

• Network topology, with installed network devices

• Scaled control room layout drawing

• Layout drawing for cabinets

• Card allocation for integrated control system and I/O subsystem (rack, card)

• Internal system cable layout drawing and system cable arrangement of DCS.

• Internal cable and wiring diagrams

• Cable distributions, marshalling cabinet terminal strips allocation, wiring diagrams for signal transformers.

• I/O subsystem, I/O cards terminal blocks wiring diagram.

• As-built power supply diagram

• As-built grounding diagram

21.3.2 Installed application software documentation

• Technical description (e.g. tagname), system structure and description

• Operational descriptions

• System configuration data (e.g. address allocation)

• I/O allocation

• Point configuration

• Function block list, configuration parameters

• Function block connections (loop connection, FBD: Function block diagram)

• SFC: Sequential Function Charts

• Logic drawings for controls

• Software source lists (heading, revision, comments)

• Operator interfaces, graphics displays, supplemented with the building rules for graphics pictures as well as the basic element set.

• Reporting functions documentation

• RIS (Refinery Information System) data provision with the following contents:

o Measuring circuit tagname

o Extension (e.g. PV, SP, OP etc.)

o DCS name (plant)

o Measuring circuit (point) describing name

o Unit of measure

o Lower measuring range

o Upper measuring range

o Measuring circuit type

o Unit name

o Digital loop status

• In electronic format (archiving)


26/26 Rev 1.00.01

22 Appendix:

3 Applicable codes & standards Additional reference: N/A

15: Power supply requirements Powering of DCS cabinets and other dual-powered equipment: DCS cabinets and other dual-powered equipments of DCS system shall be powered by different phase of three phase UPS by independent circuit breakers in the existing Power Distributor Cabinet of the control room.

SLOVNAFT a.s.

R&M Division


MOL Group


6. Process Control System 2. Requirements for Safety Instrumented System

MGS-S-REF-I-6.2

Rev 1.01.02




2 Requirements for Safety Instrumented System Page/Pages: 2/23


Release list


0.00.00 20.01.2006 Basic release Á .Pozsgai L. Pallagi 0.00.01 12.12.2008 Issued for comments Á. Pozsgai L. Pallagi 1.00.00 30.11.2011 General issue Á. Pozsgai L. Pallagi 1.00.01 31.01.2014 General review P. Jakubec R. Kopálek Head of Technology 1.01.02

31.1.2016 Revision Z. Stanová R. Kopálek Head of

Maintenance


Rev 1.01.02 3/23

Contents 1 Overview ................................................................................................................................................................ 4

2 Deviations .............................................................................................................................................................. 4

3 Applicable codes & standards ............................................................................................................................... 4

4 Safety Instrumented Systems ............................................................................................................................... 4

5 General requirements for Safety Instrumented System ........................................................................................ 4

5.1 General Safety Lifecycle requirements ......................................................................................................... 4

5.2 General requirements of SIS design ............................................................................................................ 6

5.3 General requirements for ESD and IS system design .................................................................................. 6

5.4 General requirements for GDS system design ............................................................................................. 7

5.5 General requirements for BMS system design ............................................................................................. 8

6 Requirements for field devices of Safety Instrumented System ........................................................................... 8

6.1 General field devices requirements .............................................................................................................. 8

6.2 Sensor requirements .................................................................................................................................... 9

6.3 Final element requirements ........................................................................................................................ 10

6.4 Input and output signal conditioners and wiring requirements ................................................................... 10

6.5 Field Instrumentation Maintenance System (FIMS) and HART consideration within SIS .......................... 10

6.6 Physical security considerations ................................................................................................................. 11

7 Requirements for PES Logic Solver of SIS ......................................................................................................... 11

7.1 General requirements on PES Logic Solver ............................................................................................... 11

7.2 Requirements for the CPU of PES Logic Solver ........................................................................................ 13

7.3 General requirements on I/O subsystem .................................................................................................... 14

7.4 Requirements for the safety bus system .................................................................................................... 14

7.5 Spare and expandability of PES Logic Solver ............................................................................................ 15

8 Requirements for application software of PES Logic Solver ............................................................................... 15

8.1 Safety PLC control functions ...................................................................................................................... 15

8.2 Requirements for application software of SIS ............................................................................................ 16

9 Development environment of the PES Logic Solver ........................................................................................... 17

10 Requirements for installation, commissioning and safety validation .............................................................. 17

10.1 Requirements for installation ...................................................................................................................... 17

10.2 Requirements for commissioning ............................................................................................................... 18

10.3 FAT requirements ....................................................................................................................................... 18

10.4 Requirements for safety validation ............................................................................................................. 19

11 Operational requirements for Safety Instrumented System ........................................................................... 20

11.1 Override requirements of Safety Instrumented System ............................................................................. 20

11.2 Proof Test requirements of Safety Instrumented system. .......................................................................... 22

11.3 Management of Change requirements for Safety Instrumented System ................................................... 23

12 Appendix ......................................................................................................................................................... 23


4/23 Rev 1.01.02

REQUIREMENTS FOR SAFETY INSTRUMENTED SYSTEM

1 Overview The present specifications contain basic requirements for Safety Instrumented Systems (hereinafter referred to as SIS) controlling oil industry processes.

The Project Specification may contain variations or modifications from this document.

This general specification related to Functional Safety Quality Assurance (as furthermore FSQA) and it is intended to use as a technical requirement for SIS focused on technical considerations and supports the application of SIS.

2 Deviations The applicable Project Specification may contain deviations from or changes to this document.

Deviations from the contents of this specification and the Project Specification shall be permissible only on the basis of prior written approval by MOL PLC.


3 Applicable codes & standards • EN 61508-1..7:2010 Functional safety of electrical/electronic/programmable electronic safety-related

systems

• EN 61511-1..3: 2005 Functional safety. Safety instrumented systems for the process industry sector.

• Additional reference: see App.

4 Safety Instrumented Systems The Safety Instrumented Systems (SIS) implements the required safety functions necessary to achieve or maintain a safe state for the protected process or equipments in order to reduce the frequency of hazardous events (prevention system) or to mitigate the severity of consequences (mitigation system).

SIS boundaries and constraints The SIS shall include all elements from the sensor to the final control element(s) that are required to perform the Safety Instrumented Function (SIF), including inputs, outputs, utility systems (e.g., electrical power, instrument air etc.), and Logic Solvers.

Also shall be included hardware and software, including communication links, which are required to perform the SIF. Portions of the system that are not required to perform the SIF and have no potential adverse impact on the performance of the SIF are not considered as part of the SIS.

Typical type of SIS:

• Emergency Shutdown System (ESD: e.g. machinery protection system) and safety Interlock System (IS: e.g. gas break through protection)

• Burner Management System (BMS: for fired equipment)

5 General requirements for Safety Instrumented Syst em

5.1 General Safety Lifecycle requirements All necessary activities involved in the design-, implementation- and operation of SIS shall fulfill the safety lifecycle requirements defined in EN 61508 and EN 61511 standards.

Hazard and risk analysis:

• The determination of safety requirements for SIS should be based on a process hazard analysis (PHA: e.g. HAZOP).

Allocation of safety functions to protection layers:

• If a process hazard and risk assessment (e.g. LOPA) based on PHA determines that the mechanical integrity of a process, the process control (Basic Process Control System (BPCS) and alarm with operator’s response) and other protective device are insufficient to mitigate the potential hazard, a SIS is required.


Rev 1.01.02 5/23

• Required Safety Integrity Level (SIL) for each SIF shall be determined

SIS safety requirements specification (SRS):

• The SRS shall include safety functional requirements and safety integrity requirements as a design inlet.

• Safety integrity requirements should include:

o Required SIL for each SIF

o Process demand rate (Low, High and Continuous) shall be defined as the occurrence of a process deviation that causes an SIS to transition a process to a safe state.

o Reliability requirements if the spurious trips are hazardous (Spurious Trip Rate: STR)

o Requirements for diagnostics, maintenance and testing

• Safety functional requirements should include:

o Required safety state and way to achieve that

o Process conditions under which actions are initiated

o Safety functional requirements specify the task (simplified logic) of SIS, safety action type (energize, de-energize) and functional narrative

o Required trip limits and settings

o Required Sensor(s) which are able to sense the process condition due to potential hazard

o Required Final Element(s) which are able to force the hazardous process to safety state

o Other requirements as consideration for resetting, manual shutdown, bypass: maintenance- and process override, interface to BPCS system, etc.

SIS design and engineering:

• To design the SIS to meet the requirements for safety functions and safety integrity.

• Define the SIS architecture to ensure the SIL is met (for example, voting 1oo1, 1oo2, 2oo2, 2oo3)

• Define the Logic Solver to meet the highest SIL (if different SIL levels are required in a single logic solver).

• Select a functional proof test interval (PTI) to achieve the SIL.

• Verify the conceptual design against the SRS.

• Develop a detailed SIS design including:

o General requirements

o Specification and selection of SIS Logic Solver (LS, PES Logic Solver )

o Specification and selection of field devices (sensors, final elements)

o Interfaces (graphic HMI display on BPCS, local panel, Annunciator)

o Energy sources (PS, UPS, utilities required for SIS)

o System environment (field, control room)

o Application logic plan (application software)

o Operation, maintenance or testing requirements (operation-, maintenance- and test manual)

SIS installation commissioning and validation:

• To assemble, install, commission and integrate the SIS according to specifications and detail design (Factory Acceptance Test)

• To validate that the SIS meets in all respects the requirements for safety in terms of the required safety instrumented functions and the required safety integrity (SIL Verification, Site Acceptance Test)

• The SIL of the entire SIF shall be verified via a calculation of PFDavg considering redundant architectures, proof test interval, proof test effectiveness, any automatic diagnostics, average repair time and the specific failure rates of all elements included in the SIF, furthermore the SIF with their subsystems shall be checked to assure compliance with minimum hardware fault tolerance (HFT) requirements.

SIS operation and maintenance:

• To ensure that the operation and maintenance do not compromise safety integrity and to keep the protected process in safety.

• Modifications are properly designed and controlled (Management of Change)

• The safety integrity of the SIS shall be maintained throughout its lifetime (periodical Proof Test)


6/23 Rev 1.01.02

5.2 General requirements of SIS design

• Equipment and components which are used shall be certified according to EN 61508/61511, only safety-related components shall be used.

• The design of the SIS shall be in accordance with the SRS.

• The Logic Solver (LS) part of SIS should be based on Programmable Electronic System (PES).

• A SIS may have a single SIF or may address multiple SIF that have a common Logic Solver and/or input and output devices. When multiple SIF are combined within a SIS with different SIL’s, then the shared or common hardware and software elements shall conform to the highest SIL of the most stringent SIF in the system. Components of the system that are not common must meet the SIL requirements for the SIF that they address.

• The PES LS part of SIS shall be redundant with SIL3 safety integrity level for BMS and Gas Detection System (GDS) systems.

• Spurious Trip Rate (STR) shall not be less than 10 years per safety trip group for ESD, IS, BMS and GDS systems.

• The BPCS shall be designed to be separate and independent to the extent that the functional integrity of the SIS is not compromised.

• The probability an SIS will fail on demand (PFD) shall be reduced by increasing device diagnostic coverage (DC) with using of advanced diagnostic techniques and increasing of the frequency at which devices are tested or decreasing of the test interval (TI). The test interval shall not be less than 1 year.

• The reliability of SIF should be increased or STR should be reduced by installation of redundant (double, triple) devices in arranged in voting group (2oo2, 2oo3) such a way the safety integrity shall not be compromised.

• In case of 2oo2, 2oo3 inputs shall be wired to unique input card for decreasing possibilities coming from base card, power supply and cables.

• The whole Safety Instrumented Function shall fulfill the safety integrity requirements, not just to the components of SIS.

• Redundant components shall be separated so as to reduce common cause failures.

• The SIS shall be designed in such a way that once it has placed the process in a safe state, it shall remain in the safe state until a reset has been initiated unless otherwise directed by the safety requirement specifications.

• Use of fail-safe principles is required so that the actuator takes up the safe state on loss of signal or power

• The conditions and restrictions for operation in degraded mode of SIS shall observed. Typically a timing restriction should be planned for the degraded mode of operation.

• The SIF has a response time associated with the sensor, logic solver, and final element subsystems. The sum of the response times shall be less than the process safety time.

• The operator interface shall not be allowed to change the SIS application software.

• PID and other control algorithms should not be used for SIF. Each control function should be checked to verify that it does not provide a safety-related function.

• Each individual field device shall have its own dedicated wiring to the system I/O.

• Using a field bus is not allowed!

• When online testing is required, test facilities shall be an integral part of the SIS design.

• The SIL verification shall be performed at end of the design phase to check the design against the SIL requirements defined in SRS. SIL verification report shall be provided for all designed SIF by a certified SIL verification tool.

5.3 General requirements for ESD and IS system desi gn The purpose of ESD and IS system mainly:

• To force the hazardous process to safety state

• To avid undesirable consequences of a hazardous event

Requirements for ESD and safety IS system design:

• The ESD System and IS shall scan analog and discrete on/off inputs from field sensors, perform arithmetical operations, analog limit detection, logical functions and shutdown of plant units or part hereof, according to the given strategy specified in SRS.


Rev 1.01.02 7/23

• The ESD and IS system shall be based on Safety Instrumented System which shall be the integrated part of the overall Integrated Control System (ICS).

• An ESD and safety IS function (e.g. initiated by a safeguard) shall - as soon as necessary after actuation - put the process in a safe state within Process Safety Time (PST). The SIS response time shall be less than the process safety time (PST).

• The SIF as part of ESD and IS shall be testable, able to validate and maintainable with regard to its protective function.

• During start-up it is allowed to bypass some Trip Alarms in order to reset the ESD or IS-group. This can be carried out by activating the corresponding Process Override Switch (POS) on the Auxiliary Console.

• The ESD and IS system shall have facility to bypass selected field devices for maintenance testing called Maintenance Override Switch (MOS). They can be based on software switch.

• The manual reset function shall meet the following conditions:

o Each ESD and IS group shall have a manual reset function.

o The manual reset function shall be provided through a separate and manually operated device within the SIS and shall be by deliberate action. Trips shall not be self resetting.

o The manual reset function shall be situated outside the hazardous (or danger) zone related to protected process and in a safe position from which there is good visibility for checking the hazardous zone.

o The manual reset push buttons shall be placed on the Auxiliary Consoles or Shutdown Console or Local panel according to project specification. It shall not be possible to reset an ESD or IS-group as long as there is an activated Trip Alarm on, unless it is bypassed by POS. The reset of ESD and IS group shall meet the requirements of T-diagram indicated on P&ID.

o The manual reset function shall enable the control system for accepting a separate operational (start, open/close) command

o The manual reset function shall not initiate operation (e.g. motion, start, open/close) or a hazardous situation by itself.

• The manual ESD stop devices shall meet the following conditions:

o Manual means (for example, emergency stop push button), independent of the logic solver, shall be provided to actuate the SIS final elements unless otherwise directed by the safety requirement specifications.

o The manual ESD stop devices shall be located in an easily accessible and non-hazardous position either outside the room where the protected equipment is installed or along the emergency exit route and its purpose appropriately marked.

o The manual ESD stop devices shall be initiated by a single human action

o The manual ESD stop devices shall be hard wired dual switches (NC/NO) to detect line failure.

o The initiator of the ESD stop device shall be a mushroom-shaped push button which snaps in and may only be released by a key or special tool.

o The initiator of the ESD stop device shall be colored red and the surface behind it shall be colored yellow

o Control room located manual ESD stop devices shall be provided a red colored protective cover

o The field located manual ESD stop devices shall be pull type.

• The output status of ESD or IS group (for each solenoid valve or rotating equipment) shall be indicated on the BPCS HMI graphic display and the operational place of manual reset function as permission to reset.

• A command disagree alarm related to output of ESD or IS group shall be generated to indicate the failed operation of final elements.

• All changes in logic status of ESD or IS group shall be recorded, including changes of status, inputs, inactivation of inputs of ESD/IS group, first out alarm, etc.

5.4 General requirements for GDS system design GDS system is one of protection layer which used to reduce the process risk. The purpose of GDS system should be mainly:

• To allow a mitigation action (e.g. sprinkler system, emergency ventilation system, emergency steam injection etc.) to reduce the consequences of a hazardous event.


8/23 Rev 1.01.02

• To provide continuous automatic monitoring function to alert personnel to the presence of hazardous gas condition.

See references for detailed GDS system design:

o MGS-M-REF-I-6.10

o MGS-S-REF-I-6.10

5.5 General requirements for BMS system design The Burner Management System is dedicated to furnace safety and operator assistance in the starting and stopping of fuel preparation and burning equipment and for preventing missoperation of and damage to fuel preparation and burning equipment.

• The hardware and software of BMS shall be compliance with the requirements of EN 61508/61511.

• Electrical and control equipment of BMS (e.g. Logic Solver) system shall be certified (e.g. by TÜV) to meet the requirements for the following standards:

o EN 298: 2003:Automatic gas burner control systems for gas burners and gas burning appliances with or without fans

o EN 50156-1: 2004: Electrical equipment for furnaces and ancillary equipment. Requirements for application design and installation.

• The electrical equipment of BMS shall be selected and mounted so that it withstands the potential electrical, chemical and mechanical stresses at its place of use as well as external influences e.g. environmental stresses.

• The SIF’s of BMS system shall conform at a specified SIL to IEC 61508.

• The functional characteristics of BMS shall fulfill the requirements of the following standards:

o EN 746-2: 2010: Industrial thermo-processing equipment. Safety requirements for combustion and fuel handling systems *

Note for EN 746-2: 2010 standards: The BMS system is being used in MOL refineries which are related to process industry sector so the EN 61511 standards should be used instead of EN 62061 and EN ISO 13849-1 standards which are related to safety of machinery despite as required in the EN 746-2: 2010 standard.

• The guarding functions (e.g. gas pressure, temperature) performed by components for which no relevant product standards are existing (e.g. EN 298: Automatic burner control system, EN 1643: Valve proving system, EN 1854: Pressure sensing devices, EN 161: Automatic shut-off valves, EN 12067-2: Gas/Air ratio control), shall comply with at least SIL2.

• The functions which will lead to immediate hazard in case of failure (e.g. flame supervision, ratio control) performed by components for which no relevant product standards are existing shall comply with at least SIL3.

• Any changes to hardware or software shall be documented, approved, and maintained.

• The BMS application software shall be password protected and can only be accessed or modified by authorized personnel.

• The BMS or its safety functions shall not have the ability to be manually bypassed by operators.

• Safety shut-off valves shall not be bypassed

• The BMS local panel and the control panel in the control room shall contain a hardwired manual shutdown switch that is independent of the BMS system.

• Safety-related operating characteristics such as purge times, trial for ignition times, flame failure response times, trip limits. etc., shall not be readily accessible by the operator. These characteristics shall not be adjustable when the safety system is in operation and online.

See references for detailed BMS system design:

o MGS-M-REF-I-21

o MGS-S-REF-I-21

6 Requirements for field devices of Safety Instrume nted System

6.1 General field devices requirements

• Field devices shall be selected and installed to minimize failures that could result in inaccurate information due to conditions arising from the process and environmental conditions.


Rev 1.01.02 9/23

• Conditions that should be considered include corrosion, freezing of materials in pipes, suspended solids, polymerization, cooking, temperature and pressure extremes, condensation in dry-leg impulse lines, and insufficient condensation in wet-leg impulse lines.

• The conditions for use specified by the manufacturer are to be observed. Particular attention is to be paid to:

o Protection from excessive voltage and EMC

o Environmental conditions

o Ex-protection - if required.

• Use of good engineering practice and well proven techniques for process connections and sample lines to prevent blockage, hydraulic locking, sensing delays etc. Appropriate measures to protect against the effects of the process on the process connection or sensor, such as vibration, corrosion, and erosion

• De-energize to trip shall be used. Energize to trip discrete input/output circuits shall apply a method to ensure circuit and power supply integrity.

• Each individual input-output field device shall have its own dedicated wiring to the system input/output.

• In general, the closed loop principle is to be maintained for all external safety circuits which are connected to the SIS. (e.g. Use of positively actuated switches operating in a positive mode together with idle current (de-energize to trip)).

• Analog devices (transmitters) are generally preferred to discrete devices (switches), because the use of the analog signal allows for on-line detection of device faults

• Surge Protection Device (SPD) shall be used in order to protect electrical safety field device against electrical surges and spikes, including those caused by lighting. The active parts and cable cores shall be provided with suitable lightning arrestor or over-voltage SPD if this is necessary to maintain safety.

• Use visual indicators, such as paint, tags, stamps, etc., to identify SIS devices.

• The field devices used in SIS shall be in compliance with EN 61508 and/or EN61511.

• The field devices used in SIS shall be certified to a desired level of safety by an independent, recognized agency (e.g. TÜV).

• The manufacturer of any safety field device is obliged to provide user instructions to convey essential safety information:

o Description of the safety function

o Safety Integrity Level (SIL capability)

o Every failure mode in and estimated failure rate (lambda)

o Periodic proof test and/or maintenance requirements

o Safety architecture (e.g. 1oo2), Hardware Fault Tolerance

o Classification as type A or type B

o SFF (Safe Failure Fraction);

o PFD (Probability of Failure on Demand) and/or PFH (Probability of Dangerous Failure per Hour);

o Information about the database for calculation of the values above (e.g. average ambient temperature, failure rate data, specific failure modes, etc.);

6.2 Sensor requirements

• HART enabled (smart sensors) shall be write-protected to prevent inadvertent modification from a remote location, unless appropriate safety review allows the use of read/write. The review should take into account human factors such as failure to follow procedures.

• In case of the internal diagnostics detect a failure; the safety transmitter/sensor shall signal the PE Logic Solver to take appropriate action.

• Transmitter can be designed to fail toward a trip condition or away from a trip condition. If it is designed to fail away from the trip condition, then it is important that the operator gets an alarm on the transmitter failure and is trained to take the necessary corrective action to get the transmitter repaired as quickly as possible.

• If redundant transmitters are used, comparison of the analogue values detects anomalies that may occur during normal operation (e.g. discrepancy alarm). Monitoring of SIS process variable measurement (PV) and comparison against the equivalent BPCS PV either by the operator or the BPCS (or ICS).

• Time delays may be provided to prevent nuisance alarms due to variations in sensor response to process changes caused by sensor location or sensor technology.


10/23 Rev 1.01.02

6.3 Final element requirements

• Use of fail-safe principles so that the actuator takes up the safe state on loss of signal or power (electricity, air, etc.); e.g. use of a spring return actuator. (De-energize to trip)

• Provision for uninterruptible power supply or reservoir supplies of sufficient capacity should be provided for power if the SIS performs energize to trip. The power of SIS which performs energize to trip shall be taken into account for validation.

• Failure detection and performance monitoring should be used (valve travel diagnostics, limit switches, time to operate, torque, etc.) during operation. (On-line testing and diagnostics)

• The pushbuttons of safety final elements shall be locked so that the ESD parameters cannot be inadvertently changed by the buttons during normal operation.

• Valves should be properly selected, including choosing the correct sizing for actuator thrust requirements with additional safety cushions as per safety manual.

o Process fluid and physical process conditions should be properly considered for selecting suitable valve type and style. (Specifications)

o Metallurgical selection of the valve body, trim material, linkages, etc., should be properly selected (Technical requirement)

o Environmental conditions should be taken into account for minimizing stem blockage, corrosion, dust protection, etc. (Outside environmental conditions)

o Actuators may also include microprocessor-based digital valve controllers (i.e., smart positioners) with configurable travel, stroking speed, pause time, etc.

Partial Stroke Test (PST) requirements:

• PST is the one of the method to improve the diagnostic coverage in order to reduce probability of failure (not proof testing).

• Safety shutoff valves that remain in one position for long periods of time and it can be become stuck in that position and may not operate when needed shall be periodically tested (proof test) or to ensure PST diagnostics

• The actuator of safety shutoff valves should have capability to perform time scheduled automatic PST initiated by internal preconfigured scheduler, through a safety related Logic Solver, HART command or initiated on demands by operator from the local panel or remotely from control room.

• In order to use the PST as an automatic diagnostic tool the PST shall be shall be scheduled to run at least once per month or ten times within the expected hazard demand interval.

• Results from the PST and proof tests shall be recorded and reviewed periodically.

• During each PST, pneumatic supply, actuator pressure, and valve position are tested to verify whether the valve components will perform.

• The actuator of safety shutoff valves should be capable of annunciating faults resulting from a PST. And should have a discrete output will be de-energized for any fault related to resulting from a PST.

• For most PST fault conditions, the safety shutoff valves should attempt to remain in the energized state until an ESD trip command is given.

6.4 Input and output signal conditioners and wiring requirements

• An SIS should be wired and grounded according to the procedures defined by the manufacturer in the Safety Manual.

• Input/output interface devices have failures that can be unsafe that should be identified and quantified.

• Independent systems or redundant channels should not share multicore cables with each other or power circuits, and may require diverse routes depending upon the safety integrity level to be achieved.

6.5 Field Instrumentation Maintenance System (FIMS) and HART consideration within SIS

• The smart field devices (e.g. HART enabled transmitter/valve) used in SIS shall be connected to Field Instrumentation Maintenance System (FIMS) through HART transparent safety I/O card (preferred) or HART Multiplexer (MUX).

• The FIMS of PES Logic Solver can be integrated and used together with the FIMS of BPCS system.

• HART MUX connection to 4-20 mA signal shall be isolated and decoupled such that a failure of the HART MUX does not affect the 4-20 mA signal.


Rev 1.01.02 11/23

• Documentation about the FMEA of the MUX interface to the 4-20 mA signal shall be provided to show that the normal operation or the failure of MUX will not affect the 4-20 mA signal.

• The HART enabled field devices used with SIS shall be suitable for the SIL rating of the safety loop as per IEC 61511 guidelines. HART enabled field devices shall be documented to be non-interfering the 4-20 mA safety signal.

• The data (secondary variables, device information, diagnostics, and status data) received from the HART field device must not be used for safety related reactions in the SIS.

• To avoid failures resulting from unintended configuration changes of the HART capable field devices, protection mechanisms, which may be provided by the HART devices, shall be used. The configuration changes of safety field device is only allowed when it is out of service.

• As a part of management of safety policy, practices and procedures, the FIMS (HART master) must be password protected to allow maintenance of and modifications to the HART enabled field devices connected to SIS by authorized people only. The Safety procedure should include provisions to avoid re-configuration of HART enabled field devices by mistake.

• Modifications and settings of smart devices that are connected to FIMS system shall be restricted (e.g. with perimeter key-switch, internal disallowance in transmitter, password etc.), and the modifications shall be logged.

• Online changes to the field device configuration, online calibration and online maintenance shall be avoided and must be evaluated depending on the application.

6.6 Physical security considerations Physical countermeasures shall be used to protect an SIS system, as well as related buildings and equipment, from natural hazards, environmental hazards, and unauthorized intrusion. It shall be based on the security policies of SIS manufacturer and SIS employer.

• Physical security relates to creating a secure environment for the protection of tangible or physical assets (i.e. computers, networks, information and operations equipment) from damage, loss, unauthorized access or misuse.

• Critical information or assets should be placed in a secure area protected by security perimeters and entry controls. One or more physical security perimeters should be established to provide barriers for unauthorized access to facilities.

• Connections: All connections (i.e., power and communications, including I/O field wiring, I/O bus wiring, network cables, inter-controller connection cables etc.) under the control of the organization should be adequately protected from tampering or damage.

• Means should be provided to control access to SIS including the logic solver, SIS maintenance interfaces, test and bypass functions, SIS alarms, sensors, and final elements. The access protection may be in the form of locked cabinets, "read only" communication, access codes, passwords, administrative procedures, etc.

7 Requirements for PES Logic Solver of SIS The PES Logic Solver supplier shall provide an integrated design including, input module(s), output module(s), CPU, communication (safety bus), internal diagnostic measures, maintenance interface device(s), and developing software. The integrated design shall be documented.

7.1 General requirements on PES Logic Solver

• The hardware architecture shall include self-checking firmware, external and internal watchdog systems, redundant processors, and dual I/O cards as required to achieve the specified SIL.

• The PES logic solver shall be separated from the BPCS

• The lifetime limit of the PES Logic Solver shall not be less then 20 years based on the worst case component wear-out.

• Safety-configured and EN 61508 series compliant PES Logic Solvers shall include diagnostics (internal and/or external diagnostic) which detect various fault. All safety functionalities referring to discover the faults of the PES Logic Solver shall be part of the embedded system. The types and diagnostic coverage will generally be described in the Safety Manual.

• Extensive diagnostics on each module, channel and functional circuit shall be provided to discover operational faults for alarming purpose. This fault information shall be available to a safety application which shall be able to properly manage to avoid an unnecessary shutdown of a process or plant.


12/23 Rev 1.01.02

• Architecture of PES Logic Solver shall ensures fault tolerance and provides error-free, uninterrupted control in the event of hard failures of components or transient faults from internal or external sources.

• Necessary checks of sensors and final elements should be implemented within the application software, for some functions, approved function blocks exist.

• The logic solver shall be designed to insure the process will not automatically restart when power is restored.

• Safety Manual that provides all the information relating to the functional safety of PES Logic Solver shall be provided.

• Design considerations specify all aspects of configuration and application programming that is relevant to the safe configuration and programming of the PES Logic Solver. These will include but not be limited to: PES Logic Solver processing times, I/O update rates, communication rates, sequence of PES Logic Solver operations, system alarm handling requirements, constraints of configuration and programming.

• The response time of the PES Logic Solver subsystem is the time between any change on a SIF input channel that should result in a trip and the time that the output channel or channels change to the tripped state. The time is measured from screw terminal to screw terminal. The response time is impacted by the configured scan rate. Scan time shall be set below 50 % of the required response time of PES Logic Solver. If scan time is greater than 50 %, an alarm should be available.

• The scan time (or cycle time) of applied PES Logic Solver shall not exceed 500 msec.

• The actual scan time of PES Logic Solver shall never exceed the maximum allowable scan time (defined in the Safety Manual). The actual scan time shall have 30% spare to the maximum allowable scan time. (Note: If the actual scan time of PES Logic Solver exceeds the maximum allowable scan time for the PES Logic Solver, the main processors will reset, causing the PES Logic Solver to go to the safe state, with all outputs de-energized.)

• Care is to be taken that system parameters which may have an affect upon safety are set correctly in safety-critical applications, particularly:

o Safety integrity level

o Maximum cycle time (or scan time)

o System configuration

o Process safety time

o Interval for foreground tests and background tests

o Time limit for monitoring of the communication

o Access limitations for external communicators (e.g. programming equipment and process control systems)

o I/O configuration and connections

o Reaction to I/O errors

o Reaction to system errors

o Safety Bus

• PES Logic Solver configuration should be redundant, it shall be provided for central processor unit, power supply, communication modules as a minimum. The I/O modules may be redundant. Automatic switchover to standby CPU shall be provided in case the primary CPU fails. Failed module shall be serviceable without affecting the active one with minimum down time.

• The PES Logic solver system shall be modular in construction and expandable in future by adding additional modules, which shall be easily accessible for maintenance and repair.

• The types of modules shall be kept to minimum possible in order to have inter-changeability and low spares inventory

• Each elements of the PES Logic Solver shall be established in such a way that they maintain their operational capacity even in extreme environmental effects as follows:

• Temperature: In the electrical installation rooms, the electrical equipment shall be capable of operating correctly in ambient temperatures between +5 °C and +35 °C

• Electromagnetic compatibility: Per relevant equipment standard and other standards with electromagnetic compatibility (EMC).


Rev 1.01.02 13/23

When tested the safety relevant functions shall remain operational in accordance with the manufacturer’s specifications. Furthermore, the equipment shall not reset when tested in lockout condition.

• Humidity: The electrical equipment shall be capable of operating correctly within a relative humidity range of 30 % to 95 % (non-condensing).

• Protection against electrical surge and discharge: Surge protection: min. 5 kV, electrostatic discharge protection: min. 15 kV.

• Protection against vibration and sock (bumping): Against vibrations: 0,5 G (10 – 50 Hz).

Shock: 10 G, 11 msec.

• Power Supply: Mains operation: from 90 % to 110 % of nominal voltage continuously and from 80 % to 120 % of nominal voltage for 1,5 sec.

Nominal frequency: from 95 % to 105 % continuously and from 90 % to 110 % for 5 s.

• The system structure shall be able to reduce the risk of errors resulting from operation and maintenance to a minimum.

o Each module shall be keyed so that modules can only be inserted into the correct module rack slot

o It shall have minimal hardware jumper.

o Modules shall be inserted and removed from a module rack without removing power.

o Calibration shall be performed digitally

o The software security and password protections have to prevent unauthorized software changes.

o Modules shall be designed with drip-proof housings

• The double feed of controller and I/O cabinets shall be installed as is specified in MGS-M-REF-I-6.1 & MGS-S-REF-I-6.1 chapter 15.

7.2 Requirements for the CPU of PES Logic Solver The system structures of CPU: The system structures describe the possible degradation behavior after fault detection and fault localization for the central processing units.

Table 1.: System structures of CPU during degradation Fault -free

system Degradation 1 Degradation 2 Degradation 3 System structure

2oo4D 1oo2D 1oo1D

with time restriction Shutdown

Safety related and fault tolerant

2oo4 1oo2 Shutdown Safety related and fault

tolerant

1oo3 Shutdown Safety related

2oo3D 1oo2D 1oo1D




tolerant

1oo2D 1oo1D





tolerant


• An internal safety application of PES Logic Solver should include a manner that initiates a safe shutdown of the process being protected and controlled when a CPU operates in a degraded mode for a specified maximum time.


14/23 Rev 1.01.02

• Timing restriction after degradation: The maximum duration for single-channel (1oo1) operation depends on the specific process and shall be specified individually in the SRS for each ESD application. For ESD applications only supervised operation should be possible after reaching a single channel mode of operation. Online repair is possible. If not repaired, single channel operation is possible with the recommended following maximum timing:

o For SIL2 application: shutdown after a maximum of 72 hours of supervised operation in single channel mode.

o For SIL3 application: shutdown after a maximum of 24 hour of supervised operation in single channel mode.

Acceptable CPU structures of PES Logic Solver:

• 1oo2D (one output from two, with diagnostics)

• 2oo3D (two outputs from three, with diagnostics, TMR: Triple Modular Redundant)

• 2oo4D (two outputs from four, with diagnostics, QMR: Quadruple Modular Redundant)

7.3 General requirements on I/O subsystem

• Use of the Foundation Fieldbus (FFB) devices and FFB is NOT allowed.

• Surge Protection Device (SPD) shall be installed for I/O which are connected to field devices.

• Simultaneous use of different type I/O cards (safety related (SR) and non safety related (NSR) AI, DI, DO) are allowed.

• The use of redundant and non-redundant I/O modules shall be provided.

• Internal buses of control system, power supply and the other I/O signals shall be isolated from the external I/O signals. All of the analogue and discrete I/O channels shall be galvanically isolated.

• Active intrinsically safety (IS) and galvanically isolator shall be used in case of intrinsically safe inputs and outputs needs. Use of passive IS isolator (zener barrier) is not allowed.

• Uses of the 230 Vac DO card are not allowed. The 24 Vdc DO card via isolator interposing relays shall be used in case of the 230 Vac DO functions. The 24 Vdc relays shall be located in the relay cabinets.

• It shall be ensured that an occasional failure of any I/O module shall not cause the breakdown of the fault-free I/O modules.

• Safety I/O modules (SAI, SDI, SDO) shall have intensive and advanced diagnostic system that shall be performed by the firmware periodically.

• When a fault of safety input modules (internal failure in the module, broken input connection, external loop power fault, no communication between output modules and CPU) is detected, the status of input channel shall change to “bad” and a predefined value (input value of error occurrence) shall be transferred to the application logic.

• When a fault of safety output modules (internal failure in the module, stuck at ON/OFF, open loop, external power down, no communication between output modules and CPU) is detected, the output shall be forced by a shutoff-switch to fail-safe state (OFF).

• The replacement of the cards under charge (“hot-swapping”) shall be provided.

• I/O card replacement without disconnecting the I/O card shall be provided.

• Accuracy of analog input cards shall be better then 0.1 %.

• The connection of 2.5 mm2 (14 AWG) wire shall be provided at the connection of the I/O signals.

• I/O’s belong to ESD functions shall be connected to redundant SR I/O cards.

• POS and MOS switches shall be connected to non-redundant and SR DI cards.

• The connections of annunciation panel shall be connected to non-redundant and non-SR I/O cards.

7.4 Requirements for the safety bus system

• The system shall shutdown if a failure of the safety bus is detected.

• Fault Tolerance shall be provided: The safety bus shall have the option of being redundant in order to improve online availability to prevent nuisance shutdowns. The safety bus shall support full active redundancy, operating in 2oo2 mode, and provide the highest level of both safety and online availability required in EN 61511. A failure of any single safety bus in a multiple bus SIS shall not degrade the performance of the other buses nor degrade the performance of any equipment connected to the buses (i.e., no common cause).


Rev 1.01.02 15/23

• Security: The safety bus shall have sufficient security to prevent inadvertent changes to the configuration of the safety functions.

• Operation: The safety protocol can be turned on or off using a switch so that the same hardware can be used for safety-related or non-safety-related. Online replacement shall be possible without affecting the safety bus. This override shall be time limited. The safety bus shall be media independent. Any segment shall be capable of operating over communications media suitable to the specific application requirements (e.g., wire, fiber, etc.).

• Diagnostics: Safety bus diagnostics shall be implemented in a manner transparent to the user. The SIL capability (in accordance with EN 61508) of all software and firmware used by the communications or diagnostics processes of the safety bus shall be declared, other than in the case of software or firmware the failures of which are detected by automatic diagnostics of the bus.

• Documentation: The safety bus documentation shall clearly define how the bus has achieved its claimed SIL and availability (e.g., per EN 61508). The safety bus documentation shall include a safety manual (per EN 61508) that also is sector specific (e.g., process sector per EN 61511), since one bus may not be suitable for all sectors.

7.5 Spare and expandability of PES Logic Solver The delivered PES Logic Solver shall have 10% built-in spare and 20% expandability. Any alterations from this fundamental requirement are included in the chart below:

Description Built -in spare Expandability Remark I/O card /slot - 20 % For each I/O card I/O channel 10 % - For each I/O type Scan / Cycle time* 30 % Electrical power of Power Supply


Terminal strips 15 % 25 %

Internal cable duct 30 % - Cabinet empty space 15 % - Communication, network 30 % - Communications to DCS, SER

* Note: In the case of PES Logic Solver, the integrated spare refers to the memory use, the CPU runtime, the number of configured algorithms, and communication. The built-in spare shall not reduce the cycle times set forth in the cycle time requirements.

8 Requirements for application software of PES Logi c Solver Software architecture of PES Logic Solver shall include communications drivers, diagnostic functions and fault handling, input/output functions, executive application software and derived functions as required to achieve the specified SIL.

• The PES Logic Solver’s application software environment shall have a minimum set of the basic programming elements and shall comply with the syntactic and semantic rules for the most commonly used programming languages, including graphical languages as EN 61131-3: 2003 standard defines.

• PES Logic Solver shall use the graphical programming method shall be based on Functional Block Diagram as a minimum defined by the EN 61131 standard.

8.1 Safety PLC control functions

• The Safety PLC shall have the following algorithms and functions:

o Input function

o Control function

o Output function

• Input functions:

o AI, DI, numerical and Boolean (flag) input

o Diagnostics input

o System status input

• Output block functions:


16/23 Rev 1.01.02

o DO, numerical and Boolean (flag) output

• Control functions:

o Data and type conversions.

o Boolean algebraic elements, gates, logical blocks (i.e. OR, AND, NOT, NOR, NAND, XOR).

o Timer (ON-Delay, OFF-Delay, PULSE).

o R-S Flip-flop

o Comparator (EQ, GT, LT, GE, LE, MIN, MAX).

o Counters (up/down).

• Arithmetic functions: ADD, SUB, MUL, DIV, SQRT, ln(x), ex.

o Linearization, signal characterization

o Possibilities for making user-defined function blocks.

• Other necessary functions:

o Alarm functions

o Sequence of Events management

o Sequence of Events Recording (SER) functions

o Communication to DCS system

8.2 Requirements for application software of SIS At the application software development, the following aspects shall be considered:

• Safety orientated configuration and application programming shall be carried out with safety tools and checked by a competent person who is independent of the application developer.

• Care is to be taken that the details of the planning and engineering (system parameters which may have an affect upon safety) are set correctly in safety critical application.

• Application programs and data which are relevant to safety shall be separated from programs and data which are not relevant to safety. Safety paths are to be marked in logic plans and parameter lists. The safety consistence shall be checked. Proof of freedom of interaction (interference-free) of non-safety-related program parts shall be shown for every modification.

• System reaction times to external requirements shall be tested. System reaction times to internal errors are to be taken into account. Keep the reaction time of the application program constant.

• Conformity of the programs that are loaded in the PES Logic Solver with the programs theoretically checked previously must be proved. This especially includes proof that the compiled version of the programs, which are to be jointly used, provide the specified safety functions.

• Application program shall be based on logic diagrams or cause + effect matrices only

• Proven-in-use or pre-tested function blocks should be used. Maintain a application library of such blocks.

• A safety related output being controlled by an Non Safety Related signal only shall be avoided

• There shall be no timing between the SR input and SR output of such type, which hinders safe operation.

• No unused defined symbol may remain in the system.

• No function blocks having defective connection or parameter may remain in the system.

• Functions causing malfunction shall be avoided (e.g. division by zero, etc.)

• Logic causing uncertain status shall be avoided.

• Tools and development tools supporting checking and documentation requirements belonging to the validity procedure shall be preferred.

• Calculation errors should be avoided by design. This means that an application should be designed in such a way that the operands of a symbol in the application software (logic) can never get an invalid value. Calculation errors may occur in the application program if:

o The calculated value is outside the specified range.

o The square root of a negative number is taken.

o A logarithm function is loaded with a negative value or zero

o A divide-by-zero occurs.

o An overflow occurs during a calculation.

o The value for a counter is outside the specified range.


Rev 1.01.02 17/23

9 Development environment of the PES Logic Solver The development system shall provide assistance in configuration, commissioning, start-up, optimizing, documentation and maintenance.

Requirements for the development environment:

• Authorization procedure shall apply to the development system (user, password, etc.). It shall limit the accessibility of the PES Logic Solver to avoid unauthorized access or the modification of the parameters or the configuration.

• Dedicated PC shall be used in such a way it is not connected to a business network in order to ensure the cyber security.

• Virus scanner shall be used and always on according to the vendor’s instructions. It shall be regularly-updated.

• Proven system utilities shall be used and vendor diagnostics to periodically determine the health of the PC.

• The development system shall log any modifications (Project History).

• Shall have MS-Windows environment (e.g. cut, copy, paste, drag and drop).

• Shall have simple system configuration possibility.

• Export-import possibility for database building (i.e. from MS Excel).

• Shall support off-line development (i.e. off-line database or logic functions building).

• Shall have module base (EN 61131-3) graphic development environment.

• Shall have multi-applicable module and element sets (often used function block: first-out, 2oo3 etc.).

• Shall have simulation and I/O force possibility

• Shall on line help and documentation

• On-line modification possibility (parameters, limits with authorized access)

• The development environment shall have self-documentation and report possibility.

• Shall have records of resource usage during the development.

• Shall have checking and testing functions necessary for the validation of the safety system, supplemented by their validation reports (EN 61508).

• Not copy a project file while it is open in the application software.

10 Requirements for installation, commissioning and safety validation

10.1 Requirements for installation

• The SIS should have a satisfied FAT before installation.

• All electrical installations must conform to applicable local codes and regulations.

• All SIS components shall be properly installed per the detail design of SIS and installation plan.

• The installation instructions, user manuals and the Safety Manuals related of SIS shall be considered and followed.

• The all of operational and environmental condition of SIS which effects the safety integrity of SIS shall be observed (e.g. internal temperature of cabinet, FAN not running signal)

• The PES Logic Solver shall be installed in enclosure with EMC-reduction shielding (15 dB minimum).

• The redundant components of SIS shall be powered and equipped by redundant and separated power supply in order to reduce the common cause failure.

• In case an external power supply is used, an EMC power line filter should be directly fitted after the power supply input terminals is required.

• The installed circuit breakers shall have a voltage-free contact (NC: Normally Closed), which provides a signal on the released status in order to generate a common alarm. The fuses shall have status indication (e.g. LED) which makes the identification of the broken fuse.

• The floating ground principle is not allowed.

• The wiring of the external power supply and the internal power supply shall be physically separated. This can be realized by using separate ducts and a separate power supply distribution.

• The installer and the commissioning team shall have proof of functional safety management


18/23 Rev 1.01.02

10.2 Requirements for commissioning The SIS component and construction shall be checked and tested to confirm that the installation is in accordance with manufacturer’s specifications, detail design and ready for startup in a safe manner and in compliance with SRS and project requirements.

• Commissioning activities shall include, but not be limited to, confirmation of the following:

o To confirm that all equipment and facilities related to SIS have been mechanically completed

o Power supplies, utilities energy sources have been properly connected and are operational;

o Earthing, grounding has been properly connected.

o Surge Protection Devices have been properly installed and connected.

o All safety field devices have been properly calibrated and are operational

o To confirm that all actuated final elements with a safety functions fail to a safe position as per SRS

o All I/O of PES Logic Solver have been properly connected and all loops are closed and operational

o The all of scale, ranges, limits, settings, time delays are properly configured.

o PES Logic Solver has been properly configured and is operational without any system alarm.

o Interfaces (Local Panel, HMI, Annunciation, Firs-out alarm) have been properly installed and are in operational

• The commissioning shall be reported

10.3 FAT requirements The objective of a factory acceptance test (FAT) is to test the SIS includes the logic solver and associated software together to ensure it satisfies the requirements defined in the safety requirement specification. By testing the logic solver and associated software on FAT prior to installing in a plant, errors can be readily identified and corrected.

See references for Factory Acceptance Test (FAT) requirements:

o MGS-M-REF-I-13.1

o MGS-S-REF-I-13.1

FAT requirements:

• The FAT should be conducted in accordance with the FAT planning. These tests should show that all the logic performs correctly. For each test carried out the following should be addressed:

o The version of the test planning being used;

o The safety instrumented function and performance characteristic being tested;

o The detailed test procedures and test descriptions;

o A chronological record of the test activities;

o The tools, equipment and interfaces used.

• The results of FAT should be documented, stating the test cases, the test results, and whether the objectives and criteria of the test criteria have been met. If there is a failure during test, the reasons for the failure should be documented and analyzed and the appropriate corrective action should be implemented.

• The tests shall be performed at the manufacturer’s premises (Factory Acceptance Test: FAT), and shall be repeated after the assembly work has been completed at the user’s premises (Site Acceptance Test: SAT).

• The Vendor of the Safety Instrumented System shall install and operate the complete system and its connected subsystems at their premises before delivery.

• The Safety Instrumented System Vendor shall perform their own standard internal test before the FAT, and present its certification to the Client. Vendor’s internal test shall include a complete system check, supplemented with the hardware, software and control functions of all the subsystems (Annunciator panel, SER, LCP, MCP etc.), paying special attention to the communication of the connected systems.

• The Safety Instrumented System Vendor shall operate the complete system continuously for a period of 48 hours. The hardware tests shall be performed during this period.

• The Safety Instrumented System Vendor shall perform the FAT with the Client present.

• Ten weeks before the tests, SIS Vendor shall hand over the detailed description of the standard tests (FAT protocols) to the Client, as well as the program and the schedule of the tests. The SIS Vendor shall provide one copy of an as-built documentation on the system as the attachment to the test protocol. Client shall approve the FAT protocols.

• The system Vendor shall provide suitable testing devices, testing systems and qualified personnel to proceed with the tests according to schedule. Protocol shall be prepared of each test.


Rev 1.01.02 19/23

• The participation of the representatives of the Client shall not in any way release the system Vendor from their guarantee responsibilities regarding material quality, installation, production and operability.

10.4 Requirements for safety validation The safety validation aims to demonstrate that the installed and commissioned SIS meets the safety integrity and functional requirements of SRS in all respect.

The validation of the achieved safety integrity level of installed SIF shall be carried out by the certified SIL verification tool if there is any change in the installed SIF against the designed SIF. The SIL verification report of SIF shall be attached to the SIL verification book performed at end of the SIS design phase.

Site Acceptance Test (SAT) requirements: The activity of demonstrating that the SIS meets the functional requirements of SRS after installation and commissioning is referred to as a Site Acceptance Test (SAT).

See references for Site Acceptance Test (SAT) requirements:

o MGS-M-REF-I-13.2

o MGS-S-REF-I-13.2

SAT activities shall include, but not be limited to the following:

• The functional verification of SIS. To confirm that the safety functions of SIS are accordance with the SRS and the functional design (Logic, Cause and Effects Diagrams)

• To demonstrate the safety operation of the SIS.

• To confirm that the SIS response time is less than the process safety time (PST)

• The SIS performs under normal and abnormal operating modes (for example, start-up, shutdown) as identified in the safety requirement specification.

• Confirmation that adverse interaction of the BPCS and other connected systems do not affect the proper operation of the safety instrumented system.

• The SIS properly communicates (where required) with the BPCS or any other system or network.

• Sensors, logic solver, and final elements perform in accordance with the SRS, including all redundant channels.

• SIS documentation is consistent with the installed and commissioned system.

• Confirmation that the SIF performs as specified on invalid process variable values (for example, out of range).

• The proper shutdown sequence is activated.

• The SIS provides the proper annunciation and proper operation display.

• Computations that are included in the SIS are correct.

• The SIS reset functions perform as defined in the safety requirement specification.

• Bypass/override functions operate correctly.

• Start-up overrides operate correctly.

• Manual shutdown systems operate correctly.

• The proof-test intervals (PTI) are documented in the maintenance procedures.

• Diagnostic alarm functions perform as required.

• Confirmation that the SIS performs as required on loss of utilities (for example, electrical power, air, hydraulics) and confirmation that, when the utilities are restored, the safety instrumented system returns to the desired state.

Application software test

• The test of application software related to PES Logic Solver shall be carried out according to SAT requirements.

• The configuration of each input point through the processing logic to the output point shall be checked through review, simulation and testing techniques to confirm that the I/O data is mapped to the correct application logic.

• Each application software module shall be checked through review, simulation and testing techniques to determine that the intended function is correctly executed and unintended functions are not executed.


20/23 Rev 1.01.02

• The tests shall be suitable for the specific application module being tested and the following shall be considered: exercising all parts of the application model, exercising data boundaries, timing effects due to the sequence of execution, proper sequence implementation.

• The application software tests shall show that all application software modules and components/subsystems interact correctly with each other and with the underlying embedded software to perform their intended function.

• The results of the application software module testing shall be available.

• Test of the maximum system reaction time to all external events.

• Test the re-start after power failure in all operating modes.

• Check modifications always with the certified revision comparator.

• Check during commissioning that the compiled configuration loaded in the safety instrumented system and the configuration theoretically checked previously are equal.

11 Operational requirements for Safety Instrumented System

11.1 Override requirements of Safety Instrumented S ystem If a SIF is intended to take temporarily out of operation for maintenance purpose so-called "maintenance override” or for process operation purpose so-called "process override”) then the following consideration should be taken into account:

• It is to be ensured that the plant operator is clearly informed about this operating condition.

• It is to be ensured that the plant operator still receives sufficient information about the safety status of the plant.

• Before a Maintenance Override Switch (MOS) is activated, all work and permit procedures shall be followed, so that a record is available indicating the name of the person who switched on the override. The permit procedure shall include a check that the control or indicating transmitter measurement, used as backup, is fully functional.

• A detailed instruction is to be produced for switching override on or off.

• When the SIF sensor is in override, the operator shall check the related control or indicating transmitter measurement frequently once the pre-alarm is on, so that manual actions (removal of the override or manual ESD) can be taken if the process moves too close to the trip set point.

• Operations personnel will be solely responsible and authorized to switch a SIF sensor into override (by POS).

• MOS shall not be used as a part of application software or operating procedures.

• MOS has not been engineered to be used as a Process Override Switch (POS) as well.

• Override switches (MOS/POS) shall be activated for as short time as possible

• All MOS/POS related events shall be logged on the BPCS or recorded on the Sequence of Events Recorder (SER) with a time stamp.

• The MOS/POS activated indication shall only come on when an Override / Bypass command is issued and the enable switch is turned to the enable position and the override logic is performed in the Logic Solver.

• The operator shall check, when switching on an override that the indications described above function properly.

• Direct overrides on inputs and outputs are not allowed (e.g. using clamps or hard wired jumper).

Maintenance override criteria (for MOS):

• The MOS shall be operated by the personnel in charge of the maintenance (technician).

• MOS shall be restricted to avoid any unauthorized operation.

• MOS (maintenance override) switches: each particular inputs of SIF shall be provided with MOS with the exception of inputs in “2ooN voting” configuration, flame detectors of the fired equipment and for gas hazard detectors of F&G detector system and (axial) displacement type sensors.

• All inputs that can be overridden must be predefined during the SIS design. A list of these inputs must be maintained on the system.

• Logic solver outputs (to final elements) shall not be overridden because, within one protection group, they are usually the result of more than one input.

• Only one input may be overridden by MOS for each defined safety instrumented function (SIF).


Rev 1.01.02 21/23

• The “MOS enabling” could permit the overrides function so it shall have indication on the BPCS system because of the operator should confirm the override condition.

• The MOS switches shall be arranged to MOS protection group.

• Each MOS protection group shall have one dedicated lamp located next to the “MOS enable” switch of the MOS group.

• Each MOS group shall have one dedicated “MOS Enable” key switch, located in the Auxiliary Console. Only one MOS can be activated at any one time within the MOS group. (Note: Multiple MOS overrides in a Safety PLC are allowed as long as only one override is used in a given safety related group.)

• In cases where one sensor is used for both high and low initiation, one MOS shall override both initiations.

• Maintenance overrides shall be announced and shall be applied a timer (one for MOS group of a SIF) to indicate the duration time of override state with overtime alarm.

• The time limit of MOS will be alarmed by means of a time out alarm in conjunction with a procedure.

• The MOS time out alarm will not cause the MOS to be automatically removed (causing a trip).

• The maintenance overrides lasting: see App.

• The MOS action shall not override the alarm function.

• MOS facilities will only be provided SIF sensors where a second or back-up indication and an associated means to stop the process are available to operator. Furthermore, the process dynamics are such that the operator has time to act.

• Where the sensor is a calculated variable e.g. air/fuel ration, the MOS shall override the calculated variable.

• In case of using MOS for 2ooM voting arrangement, the voting logic shall ensure that the voting arrangement should be degraded into more safe state (from 2oo2 to1oo1 and from 2oo3 to1oo2). The safety integrity shall not be compromised by MOS used for 2ooM.

• The hardware MOS switches are allowed to connect to the inputs of the Safety PLC as MOS. These inputs are used to deactivate sensors that are under maintenance. The maintenance condition is handled as part of the application program of the Safety PLC.

• The hardware MOS switches are connected to safety related DI cards of the PES Logic Solver. In that case the MOS switches shall be located in the SCR behind a closable door to avoid any unintended or unauthorized operation.

• The BPCS (DCS) “software” MOS’s are allowed, if failures in the BPCS (DCS) do not affect the proper operation of the SIS and the “software” MOS solution has been approved by international certification company (e.g. TÜV) according to the relevant safety standard (EN 61508/61511) and the solution shall be fully described in the safety manual of SIS.

• The BPCS (DCS) “software” MOS’s shall be based on separate maintenance station with restricted access.

• Common grouped alarm shall be provided for each activated MOS related to MOS group in order to reduce the number of standing alarms.

• Indications on a dedicated graphic HMI display of BPCS system shall be provided for each activated MOS and the inputs are overridden and the outcome of override functions.

Process override criteria (for POS):

• The POS shall be operated by the authorized personnel in charge of the operation (supervisor).

• All inputs that can be overridden operational purpose must be predefined during the SIS design.

• Process overrides may not last longer than defined in SRS.

• Process overrides shall be announced and shall be applied a timer (one for POS) to indicate the duration time of override state with overtime alarm.

• A time limit shall be placed on the duration a POS in on.

• The time limit of POS will be alarmed by means of a time out alarm in conjunction with a procedure.

• The POS time out alarm will not cause the POS to be automatically removed (causing a trip).

• POS (process override) switches shall be connected to the safety related DI cards of the PES logic Solver.

• For the safety POS functions, hardware "key type" switches shall be used to avoid unauthorized access. The function of the POS if the temporary release of process parameters for process reasons (startup, mode change, etc.), where the particular process parameter does not allow operation.


22/23 Rev 1.01.02

• The status of POS shall be indicated on the BPCS graphic HMI display, and shall be logged as well. The POS switches shall be mounted on the Auxiliary Console in the control room.

Forcing of I/O Points

• The configuration or developing software’s on-line mode provides the capability to disable and force any variable within a PES Logic Solver. This capability is intended for FAT/SAT, online-test and verification activities ONLY during installation and commissioning.

• The SIS shall provide a common force enable switch that allows forcing of signal

• Actions when applying or removing forces shall be always communicate

• All forces shall be cleared when the Force Enable key switch is deactivated.

• All force actions should be logged on BPCS or recorded in the SERsystem for review/historical purposes.

11.2 Proof Test requirements of Safety Instrumented system.

• The proof test needs to be written by personnel trained & competent in proof testing and fully aware of the process risks associated with carrying out the proof test.

• The written proof test protocol should be subject to formal document control procedures.

• The written proof test protocol should take account of recognized human factors in order to reduce the potential for errors and violations

• The written proof test protocol should describe all identified hazards associated with undertaking the test together with the any necessary precautions.

• Interval of proof test shall be determined at the design phase to ensure the safety integrity and reliability of the SIS, but only as necessary.

• All test equipment used for proof testing SIS should be calibrated and the calibration should be traceable to recognized national standards.

• Proof tests should address the necessary functional safety requirements of SIF, including functions such as sequence of safety operation, trip limits, response time, POS/MOS etc.

• Proof testing should be designed to expose any reasonably foreseeable unrevealed fail to danger fault conditions in all components including process sensors, logic solvers and final elements, and in the means of connecting the SIF to the process.

• The proof test of a SIF should reflect real operating conditions as accurately as possible.

• If reasonably practicable, the SIF should be initiated by manipulation of the process variable without driving the process into the hazardous condition.

• Any approach which involves driving the process into the demand state should be accompanied by risk assessment and additional controls.

• Where process variables cannot be safely or reasonably practicably be manipulated, sufficient confidence in the correct operation of sensors should be gained by simulation, which maximizes the % of the loop tested also comparison with other measurements.

• The inherent difficulties associated with testing valves and in-line measurement should be addressed during the design phase of SIF and additional provisions such as corroborative measurements should be made where necessary.

• Where the partial testing of SIF or components of SIF is adopted, the impact on process operation, functional safety and overall test coverage should be established by assessment and additional controls should be applied where SIF installations should be tested as found and should not be disturbed during proof testing.

• The procedure must describe in detail the putting back into service following the proof test. That is, ensuring that the SIF is returned to its full functional state, unless it has not achieved its design functionality.

• Proof testing should be an integral and explicit part of the planning and scheduling of the safety management system.

• The timing of proof tests should be dictated by the need to demonstrate and maintain functional safety and should not be compromised by operational or business considerations.

• The results of proof testing should be recorded and maintained for the purposes of periodic reporting, audit and historical analysis. Data arising from proof testing should be collated, reviewed and acted upon in order to maintain or improve functional safety.


Rev 1.01.02 23/23

• The entire testing program should be reviewed annually to determine if testing frequency is adequate or if a design modification needs to be implemented.

Non-conformance procedures:

• If the SIF fails to meet its design intent during proof testing then this shall be recorded.

• For failures such as failed to operate within their set value tolerance then it may be acceptable for the test technician to reset. A full functional proof test must then be carried out

• For failures that identify a functional failure of an element within the sub-system being tested this shall also be recorded.

• In addition the plant operator or supervisor shall be advised that the SIF has failed and be advised of the expected time to repair.

• The operator will need to provide alternative means of achieving the required functionality of the SIF. This will mean that a risk assessment is required based on the identified risk(s) the SIF is reducing.

• It is recommended that this is formalized using the Management of Change procedure.

11.3 Management of Change requirements for Safety I nstrumented System

• Management of change (MOC) procedures shall be followed to ensure that no unauthorized changes are made to an SIS application.

• A design-change review, code-change review, and functional testing are recommended to verify the correct design and operation.

• After a SIS has been commissioned, no changes to the system software (operating system, I/O drivers, diagnostics, etc.) are allowed without type approval and recommissioning.

• Any changes to the application or the control application should be made under strict MOC procedures. All changes should be thoroughly reviewed, audited, and approved by a safety change control committee or group.

• Before making any changes to application software in PES Logic Solver, the existing running application software should be uploaded and be compared the revision and time stamp with the archived application software is being modified in the developing PC to ensure matches between them.

• After an approved change is made, it should be archived.

• In addition to printed documentation of the application, two copies of the application should be archived on an electronic medium that is write-protected to avoid accidental changes.

• It is mandatory that, after verification and approval of any type of application modification, proper configuration management is applied to make sure that all that all stations and backup systems that may have an instance of this application program get updated to the modified version.

12 Appendix

3 Applicable codes & standards Additional reference: N/A

11.1 Override requirements of Safety Instrumented S ystem

ad: Maintenance override criteria (for MOS):

● The maintenance overrides lasting: N/A

SLOVNAFT a.s.

R&M Division


MOL Group

TECHNICAL SPECIFICATION

INSTRUMENTATION

6. Process Control Systems

3. Requirements for PLC system

MGS-S-REF-I-6.3

Rev 1.00.00




3 Requirements for PLC system Page/Pages: 2/11


Release list


0.00.00 31.10.2008 Basic release

0.00.01 01.10.2011 General review G. Kulcsár Z. Stanová

1.00.00 30.11.2011 General issue G. Kulcsár Z. Stanová


Rev 1.00.00 3/11

Contents Release list ................................................................................................................................................................... 2 Requirements for PLC System ..................................................................................................................................... 4 1 General .................................................................................................................................................................. 4

1.1 Deviations ..................................................................................................................................................... 4 1.2 Applicable standards and specifications ....................................................................................................... 4

2 Functions of PLC systems ..................................................................................................................................... 4 2.1 Definition of PLC systems ............................................................................................................................. 4

3 Installation of the PLC, Environmental Conditions ................................................................................................ 4 4 Scope of Supply .................................................................................................................................................... 4 5 Spare and expandability ........................................................................................................................................ 4 6 Hardware requirements for PLC systems ............................................................................................................. 5

6.1 Requirements for the CPU ............................................................................................................................ 5 7 General requirements on I/O subsystem............................................................................................................... 5

7.1 AI ................................................................................................................................................................... 6 7.2 DI .................................................................................................................................................................. 6 7.3 AO ................................................................................................................................................................. 6 7.4 DO ................................................................................................................................................................. 6

8 Requirements for application software .................................................................................................................. 7 8.1 Functions of PLC .......................................................................................................................................... 7 8.2 Requirements for application software ......................................................................................................... 7

9 Integration of PLC Systems ................................................................................................................................... 7 10 Development environment of PLC systems ..................................................................................................... 7 11 Power supply requirements .............................................................................................................................. 7 12 Requirements for the grounding system ........................................................................................................... 8 13 Requirements on cabling and wiring ................................................................................................................ 8 14 Constructional requirements for cabinets ......................................................................................................... 9 15 Nameplates, cable and wire tagnames, labelling ............................................................................................. 9 16 Documentation required ................................................................................................................................. 10

16.1 PLC System standard documentation contents ........................................................................................ 10 16.2 PLC system as-built documentation contents ........................................................................................... 10


4/11 Rev 1.00.00

REQUIREMENTS FOR PLC SYSTEM

1 General

The present specifications contain basic requirements for PLC systems in non SIS application controlling oil industry processes.

1.1 Deviations

The Project Specification may contain variations or modifications from this document.

No variations from the content of this documentation or the Project Specification are permitted unless the written approval of MOL Group.

1.2 Applicable standards and specifications

Standards specified in MGS-M-REF-I-4 & MGS-S-REF-I-4 shall be followed.

2 Functions of PLC systems

2.1 Definition of PLC systems

The Programmable Logic Controller (PLC) is used for process controlling (for combinations and sequential control tasks) of minor or part industrial technologies and complex industrial equipment and further used for measured-data gathering functions.

3 Installation of the PLC, Environmental Conditions

Environmental Condition: MGS-M-REF-I-4 & MGS-S-REF-I-4 shall be followed.

4 Scope of Supply

PLC shall be delivered with complete functions and tested. It is strictly required that the PLC shall be delivered as a “complete operational system”, including basic devices, auxiliary (connection cables, etc.) and all engineering services, such as configuring, system generating, data loading, etc.

The tools and documentation necessary for the performance of the tasks specified in the instrumentation tasks shall be delivered as follows:

All hardware devices, such as:

Redundant or non-redundant controller (CPU), I/O subsystem, I/O modules (redundant or non-redundant).

Networks, networking and communication devices (to DCS, local operator panel, developing system).

Redundant power supply units.

Cabinets (PLC, Marshalling, relay etc.)

Intrinsically safe and galvanic separators, overvoltage protection devices, I/O cards, cable distributors, terminal strips, terminal panels, system cables and internal cables, etc.

Individual equipment and products (local signal system, operating panel (OP), LCP, MCP etc.)

Materials necessary for their assembly and installation.

Design and construction drawings, as well as cable diagrams necessary for the assembly

System and user software with licenses.

The development environment.

Documentation necessary for its operation, maintenance and development (3 copies printed, 3 copies in electronically format).

Parts and spare parts necessary for the commissioning of the system.

5 Spare and expandability

The delivered PLC system shall have 10% built-in spare and 20% expandability. Any alterations from this fundamental requirement is included in the chart below:


Rev 1.00.00 5/11

Description Built-in spare

Expandability Remark

I/O card /slot - 20 % For each I/O card

I/O channel 10 % - For each I/O type

Cycle time* 30 %

Electrical power of Power Supply


Terminal strips 15 % 25 %

Internal cable duct 30 % -

Cabinet empty space 15 % -

Communication, network 30 % - Communications to DCS

* Note: In the case of PLC system controllers, the integrated spare refers to the memory use, the CPU runtime, the number of configured algorithms, and communication. The built-in spare may not reduce the cycle times set forth in the cycle time requirements.

6 Hardware requirements for PLC systems

6.1 Requirements for the CPU

Shall have flash EPROM (for the OS and the application)

Shall have a hardware clock

Shall have diagnostic signals in its front panel (LED).

Memory contents shall be protected

Shall have galvanically and optically isolated communication boards (RS-232, RS-485, etc.)

Support open communication standards with other PLCs and DCS system.

7 General requirements on I/O subsystem

General requirements on I/O subsystem:

The connection of Field Instrumentation Maintenance System (FIMS) shall be provided with HART devices (e.g. HART transmitter) and HART multiplexer. The FIMS of PLC can be integrated and used together with the FIMS of ICS system.

The I/O subsystem shall have modular structure.

Simultaneous use of different type I/O cards (AI, AO, DI, DO) shall be possible.

Use of redundant and non-redundant I/O modules shall be supported.

Common mode rejection ratios of 60 dB or greater from DC to 60 Hz and normal mode rejection ratio of 30 dB or greater at 60 Hz are required.

All digital process I/O circuits shall be designed to ensure that accidental normal mode connection of up to 300 Vac/dc for an unlimited period of time shall not cause damage other than to the I/O module to which it is connected.

Digital output circuits shall be provided with protection for the switching of inductive loads.

Internal buses of PLC system, power supply and the other I/O signals shall be isolated from the external I/O signals. All of analog and discrete I/O channels shall be galvanically isolated.

Active intrinsically safety and galvanically isolator shall be used in case of intrinsically safe input and output needs.

24 Vdc DO card via isolator interposing relays shall be used for the 230 Vac DO functions. The 24 Vdc relays shall be located in the relay cabinets. Use of the 230 Vac DO card shall be approved by MOL Group.

I/O modules shall be protected against static discharge, surge and sort-circuiting.

A short circuit of any input or output shall not cause the failure of any other input or output.

It shall provide that one occasional failure shall not cause the breakdown of the redundant units.

Its construction shall provide fast troubleshooting and repair.


6/11 Rev 1.00.00

It shall provide the replacement of the cards under charge (“hot-swapping”).

It shall provide I/O card replacement without disconnecting cables. (removable terminals)

Accuracy of analog input cards shall be better than 0.1 %.

The connection of 2.5 mm2 (14 AWG) wire shall be provided at the connection of the I/O signals.

All output channels (AO, DO) shall have a pre-adjusted value (fail-safe value), if there is a break in the connection between the output card and the controller (shed mode).

The I/O subsystem shall have the following types of I/O modules:

Type of I/O module Type of signal Note

Analog Input 4-20 mA, 1-5 V Conventional or conventional + HART

2 and 4 wires

Analog Input HART 4-20 mA HART

Analog output 4-20 mA Conventional or conventional + HART

TC input B, E, J, K, N, R, S, T With coldpoint compensation

RTD input Pt 100 2/3/4 wires

mV input -10 – 100 mV

Digital (discrete) input 24 Vdc Dry contact / Isolated

Digital (discrete) output 24 Vdc Isolated

Digital input SOE 24 Vdc 20 msec / timestamp

Serial Interface RS-232, RS-485/422 MODBUS-RTU as minimum

master-slave

Profibus-DP RS-485 master-slave

7.1 AI

Temperature linearization and thermocouple cold junction compensation shall be provided.

Analog input modules shall provide the repeatability and accuracy shown below:

Repeatability:+ 0.05% of span

Accuracy: + 0.1% of full span

Analog input modules shall be able to power 4-20 mA field instrumentation loops with a loop resistance of 600 ohms.

7.2 DI

The system shall be capable of supporting DI signal; time stamped to 0.5 second or better resolution.

7.3 AO

The system shall support 4-20 mA with concurrent smart valve positioner protocol outputs.

Analog output modules shall provide the repeatability and accuracy shown below:

Repeatability:+ 0.1% of span

Accuracy: + 0.25% of span

7.4 DO

The system shall be capable of supporting the following:

On/Off

Momentary (configurable width)

The following solid state output ratings shall be available:

24 Vdc

Relay or solid state output contacts that are free of voltage and ground shall be available.

Latching and non-latching momentary contact outputs shall be available.


Rev 1.00.00 7/11

8 Requirements for application software

8.1 Functions of PLC

The execution of the algorithms - configured and programmed according to the control functions (combination, sequential) – on the base of the data collected by the I/O subsystem, and transmitting these results to the I/O subsystem. If the PLC system is part of an integrated control system, it shall be able to receive and send data from and to the higher-level control system (e.g. DCS).

8.2 Requirements for application software

At the designing of the functions and software development, the following aspects shall be considered:

No unused defined symbol may remain in the system.

No function blocks having defective connection or parameter may remain in the system.

Functions causing malfunction shall be avoided (i.e. division by zero, etc.)

Logic causing uncertain status shall be avoided.

The controller database shall match the hardware configuration.

9 Integration of PLC Systems

The PLC system shall provide connection to ICS (usually DCS) to create a high-integrated common system.

The PLC system shall be completely integrated into the ICS with the use of network communication (e.g. Ethernet TCP/IP) or serial communication link (e.g. RS232/485).

The system elements of the ICS (e.g. DCS, ESD, PLC, etc.) shall be physically separated. The system elements of the DCS and the PLC System shall not be located in the same cabinet.

The display of duplicated information shall be avoided in the ICS.

Accepted communication types::

o serial communication

o network client-server connection (option)

Application of serial communication:

The serial line connection can be bus connection or Point-to-Point connection

Connections to be applied:

RS-232, RS-485, RS-422.

Serial communication protocols to be applied:

MODBUS-RTU, PROFIBUS-DP

Information technologies to be supported for network client-server connection:

OPC client-server connection:

OPC: OLE for Process Control, OLE: Object Linking and Embedding. OPC Server, OPC Client, OPC Event Server etc.

10 Development environment of PLC systems

The development system shall provide assistance in configuration, commissioning, start-up, optimizing, documentation and maintenance.

Safety requirements shall apply to the development system (user, password, etc.). It shall limit the accessibility of the PLC system to avoid unauthorized access or the modification of the parameters or the configuration.

11 Power supply requirements

Requirements for electrical energy supply:

The power supply for the PLC system equipment and the signal converters shall be equipped with redundant, fault-tolerant and closed design battery backup power supply.

The power supply system shall be designed in such a way that the broken down power supply unit can be switched off, removed and replaceable without interruption in the


8/11 Rev 1.00.00

The installed circuit breakers shall have a voltage-free contact (NC: Normally Closed), which provides a signal on the released status. The fuses shall have status indication (e.g. LED) which makes the identification of the broken fuse.

A common failure signal shall be established in the PLC system from the contacts signaling the failure of the power supply units, UPS units and the integrated batteries.

12 Requirements for the grounding system

All available metal structures (cabinets, frames, etc.) and any metal structures becoming under voltage shall be connected to the grounding system.

All electrical devices shall be connected to the grounding system, and their external grounding point shall be unambiguously marked.

The system elements shall have specified grounding points. The design of the grounding point shall meet the requirements of the system Vendor (e.g. grounding resistance). The grounding resistance shall be less than 2 Ohms.

No protection grounding independent from the grounding system unified with the neutral conductor can be used in the plant.

When designing the grounding, the development of ground current loop as well as the effect of electrical circuits on one another shall be avoided.

It is of general effect that the shielding of the cables, and the signal cables may only be grounded in the control room.

The grounding of the shield and the signal cable shall be arranged separated from the grounding of the metallic structures and the network, and shall be commoned with them in one place.

For the grounding of the shield and the signal cable, a copper grounding conductor of a cross section of at least 75 mm2 arranged separately of the metallic structure, in each cabinet.

13 Requirements on cabling and wiring

The cable connections for the cabinets shall be ensured from underneath

In the cabinets, for fixing the cables, and the grounding of the armouring of the cables, a grounding bus shall be installed, which shall be connected to the grounding star-point of the control room.

In the cable distribution and marshalling cabinets, screwed cable clamping shall be used at the connections of terminal strips and the PLC system terminal panels.

For the feed, outlet, inlet signals as well as for those of different voltage level, separated terminal strips shall be provided.

For the connection of the signal cables of the I/O cards in the PLC system, as many terminal strips shall be installed as to have enough for the connection of all the I/O channels. The terminal strip assignment shall follow the channel assignment of the I/O card in order.

Intrinsically safe signals shall be separated from any other signal lines, and shall also be differentiated with blue colour and a label. Terminal strips for receiving intrinsically safe signals shall be blue, and shall be separated inside the cabinet.

Special care shall be taken for the separation of the signal cables from the power supplies one.

Cables with different signal kinds, as well as cables with different voltage levels shall be installed separately from each other. In equipment, the wiring shall be arranged separated by voltage levels, they shall be fixed in wire-chases.

Each cables and lines shall be installed in cable channels, no loose lines are allowed.

Each equipment element and connected terminal strips shall be equipped with a label.

The connection of the stranded (flexible) wires and the taking in of the wires shall be solved with moulded wire chucks.

Vendor shall perform wiring and cabling inside cabinets at their own site.

The layout of the cabinets shall be of such as to minimize the quantity of the connection cables.


Rev 1.00.00 9/11

14 Constructional requirements for cabinets

The following requirements shall be considered:

The design of cabinets shall follow the Project Specification of the Client. Each cabinet (PLC, MC, relay, etc.) shall be of the same colour (RAL: 7032).

Each cabinet shall have removable lifting eyes, which shall be removed, after the cabinet has been installed.

The cables and wires are conducted into the cabinets from underneath, therefore the lower cover plate of the cabinets shall be removable, or cover plate capable of cable entry shall be used. The lower part of the cabinet shall include a fixing device with clamps for fixing the cables, or a clamping bar, which shall be equipped with sliding screwed clamps.

The supplied cabinets shall be connectable and ranged to one another. The side plates shall be removable, and shall have suitable fittings for connection.

The opening direction of the doors shall be such that they shall not open opposite to the escape route direction.

The system cabinets of PLC system shall be lockable.

The doors shall be removable.

The accessibility of the cabinets shall be ensured both from the front and the rear; the devices in the cabinets shall be well accessible and serviceable.

In the cabinet, cooling fan suitable for its heat dissipation shall be used. The breakdown of one fan in the cabinet shall not cause the overheating of the cabinet. The broken down fan shall generate an alarm in the PLC system with a voltage free and NC normally closed contact.

Each cabinet shall have a temperature switch for signaling high temperature. The temperature switch shall be connected to the PLC system with a voltage free and NC normally closed contact for alarm signaling purposes.

Each cabinet shall have an internal lightning fed by UPS and separated with a fuse.

Each marshalling cabinet shall have a grounded 230 V AC / 50 Hz socket fed by normal mains power supply and separated by a fuse.

Replaceable dust collector filters shall be fixed to the bottom of the doors.

Each cabinet shall have a document storage pocket of A4 size.

15 Nameplates, cable and wire tagnames, labelling

Each device installed in the system and in the cabinets (e.g. I/O cards, I/O terminal panels, circuit breakers, terminal strips, etc.) shall be unambiguously tagged. The tags used in the drawings and the system documentation as well as in the implemented system shall correspond to one another.

The connection of the particular I/O card and the terminal panel shall be unambiguously specifiable on the basis of the I/O cards and the connected I/O terminal tags. The internal system configuration id of the system I/O card and the I/O card and the terminal panel id shall be unambiguously matchable and identifiable.

The devices installed in the system shall be located so that their type and serial number shall be identifiable.

Each line and cable shall be unambiguously tagged. The wires of the cables as well as the individual wires shall be equipped with id tags which shall refer to the place of connection. The id tag of the PLC system cables shall include furthermore the “from where-to where” connection information.

The cabinets shall be equipped with labels. When naming the cabinets, the following name conventions shall be applied:

Description Plant code Cabinet property

Number of devices

Cabinet name

Marshalling cabinet XXX MC 01..n XXXMC01..n-F/R

PLC system cabinet XXX PLC 01..n XXXPLC01..n-F/R

Interposing relay cabinet XXX IRC 01..n XXXIRC01..n-F/R

Power supply cabinet XXX PS 01..n XXXPS01..n-F/R


10/11 Rev 1.00.00

Description Plant code Cabinet property

Number of devices

Cabinet name

UPS cabinet XXX UPS / RUPS 01..n XXXRUPS01..n-F/R

Power distribution cabinet XXX DT 01..n XXXDT01..n-F/R

Local panel XXX LCP 01..n XXXLCP01..n-F/R

Central panel XXX MCP 01..n XXXMCP01..n-F/R

Control board XXX CB 01..n XXXCB01..n-F/R

The labels of the cabinets shall furthermore equip with F (Front) and R (Rear) tags.

The labels, cable and line tags applied during the construction assembly of the system shall be fixed solidly, the texts shall be weather and UV-proof, and easily identifiable. Engraved labels shall be applied.

16 Documentation required

16.1 PLC System standard documentation contents

Textual documentation with drawings on the basis of which a suitable amount of information can be obtained for the design, installation, application software development and maintenance. The documentation can be stored electronically, e.g. on CD ROM (Adobe Acrobat (pdf) format). The supplied PLC system documentation shall include the following documentation:

PLC System overview (system concept)

PLC System design requirements (specifications and technical data)

PLC system installation instructions (constructional design, power supply, grounding, etc.).

PLC system maintenance instructions (manuals)

PLC system operation manual

PLC system engineering reference manuals

PLC System software installation, system settings, network devices configuration.

Software licenses, authority, author permits, etc.

PLC system application software manuals (software installation, building, testing and documentation manuals)

Documentation for products and subsystems supplied by third parties

16.2 PLC system as-built documentation contents

Textual documentation with drawings includes the hardware and software documentation for the installed and as-built system. The PLC system hardware and software documentation shall be issued in the second week after the successful FAT procedure, before the PLC system on-site installation, and the as-built documentation in the fourth week after the successful SAT procedure. The implemented PLC system documentation shall include the following documentation:

16.2.1 System documentation of PLC System

Detailed design specification

List of installed devices with type, serial number, as well as hardware and firmware revision.

System overview drawing of the PLC system

Network topology, with installed network devices

Scaled control room layout drawing

Layout drawing for cabinets

Card allocation for PLC system and I/O subsystem (rack, card)

Internal system cable layout drawing and system cable arrangement of PLC system,

Internal cable and wiring diagrams

Cable distributions, marshalling cabinet terminal strip assignment and allocation, wiring diagrams for signal transformers.

I/O subsystem, I/O cards terminal strips wiring diagram.


Rev 1.00.00 11/11

As-built power supply diagram.

As-built grounding diagram.

16.2.2 Installed application software documentation

Technical description (e.g. tagname), system structure and description

Review of safety functions, operational descriptions

Lists of setting (alarm) values and timers.

System configuration data (e.g. address allocation)

I/O allocation

I/O Point configuration

Logical drawings of control functions, function-block list, configuration parameters. List and source code of application software (with comments).

Certifications, approval documentation.

DCS Operator interfaces, graphics displays, supplemented with the building rules for graphics pictures as well as the basic element set.

Source program on CD or DVD with password (in case it is protected)

SLOVNAFT a.s.

R&M Division


MOL Group


INSTRUMENTATION

6. Process control systems

4. Requirements for Advanced Process Control

MGS-S-REF-I-6.4

Rev 1.00.00



6 Process control systems Date: 30.11.2011

4 Requirements for Advanced Process Control Page/Pages: 2/7


Release list


0.00.00 31.10.2008 Basic release Batha R.

0.00.01 01.11.2011 General review J. Horváth Z. Stanová

1.00.00 30.11.2011 General review J. Horváth Z. Stanová


Rev 1.00.00 3/7

Contents Release list ................................................................................................................................................................... 2 Requirements for Advanced Process Control .............................................................................................................. 4 1 Contents of documentation ................................................................................................................................... 4

1.1 Alterations ..................................................................................................................................................... 4 2 General features of Advanced Process Control .................................................................................................... 4

2.1 Functions and purpose of Advanced Process Control (APC) ...................................................................... 4 2.2 Typical reasons for use of Advanced Process Control ................................................................................. 4

3 Structure of the Advanced Process Control, tasks of levels ................................................................................. 4 3.1 Structure and levels of the Advanced Process Control ................................................................................ 4 3.2 Other requirements for Advanced Process Control ...................................................................................... 5

4 Requirements for hardware and software of Advanced Process Control ............................................................. 5 4.1 Requirements for implementation of APC .................................................................................................... 5 4.2 Requirements for Advanced Regulatory Control .......................................................................................... 6 4.3 Requirements for on-line optimising level ..................................................................................................... 6

5 Requirements for design of Advanced Process Control ....................................................................................... 6 5.1 Design principles of Advanced Process Control........................................................................................... 6 5.2 Design & implementation of APC ................................................................................................................. 6 5.3 As-built documentation contents .................................................................................................................. 7


4/7 Rev 1.00.00

REQUIREMENTS FOR ADVANCED PROCESS CONTROL

1 Contents of documentation

This documentation includes the definition and requirements for design, implementation and documentation of the Advanced Process Control.

1.1 Alterations

Project specifications may contain exceptions to or alterations of these requirements. Deviations from the contents of this specification and project specification may be allowed, however, only on the basis of written authorisation from MOL Group.

2 General features of Advanced Process Control

2.1 Functions and purpose of Advanced Process Control (APC)

The control structure based on APC shall be implemented in the DCS or in a connected computer, and shall use typical measurements, controllers and actuators to give more efficient production or control the plant to the previously specified optimum inside safety constraints.

This optimum may be e.g.:

maximum feed,

growing the yield of more valuable products,

minimal energy costs,

minimal usage of other materials (e.g. expensive additives),

minimal production time,

specific value-adding parameter of the product,

weighted average of parameters above,

minimal variance of a parameter.

The general goals are growing safety and stability of the process and maximising the rate of product value per production costs.

Other applications: computing, estimating (predicting) a product parameter based on the measured physical parameters, that cannot be measured on-line in the process or the measurement is too expensive.

Importance of APC is growing because of rising energy costs, more stringent product specification and increasing environmental concerns, as well as the harsh competition in the market.

2.2 Typical reasons for use of Advanced Process Control

Typical APC applications of units are in case of:

substantial time delay and lags in dynamic responses,

variable to be controlled (or virtually measured) which cannot be measured on-line,

non-linear dynamic response,

constraints, specified limits,

interactions between variables/controllers,

significant external disturbances.

3 Structure of the Advanced Process Control, tasks of levels

3.1 Structure and levels of the Advanced Process Control

The structure of the APC shall be hierarchical for the unambiguous specification of block functions and data exchange methods. There are independent control modules which shall receive their setpoints from the higher level loops and shall pass the outputs to the lower level loops based on computing algorithms.

The levels of the APC shall be:


Rev 1.00.00 5/7

1. Basic Regulatory Control level: generally indicators and PID controllers that measure one physical variable and control it (hold near setpoint). This level is not a part of APC, but roles as an interface to the real process.

2. Advanced Regulatory Control level: above the regulatory control level the modules manipulate setpoints of single PID-loops (or other parameters), or can realise complex mathematical algorithms. The tasks at this level may be:

Calculated Variable Control: process variables can be controlled that cannot be directly measured on the process or the measurement is too expensive. A kind of virtual sensor calculated, based on a model and on-line measured variables. If possible, the model can be updated by periodic analyser or laboratory data.

Multivariable Control: its function is the same as the single-loop controller, but controls more variables at or near their setpoints with compensation of loop interactions.

Predictive Control: used in case of long time delays between the manipulated value change and process response. This model-base structure is more efficient than the classic PID controller.

Adaptive Control: When the control parameters (P,I,D, etc.) are dependent on operating point, there shall be continuous parameter tuning.

Constraint Control: Some variables of the process shall be retained between constraints. When the process variable is approaching the constraint, the control shall slow down the process. When the constraint is exceeded, quick control action shall be used to bring the process back into the required region.

3. On-line optimisation level: the goal is the determination of the operating points of the production and holding the process variables in its proximity, to maximise profitability.

Local Optimiser: used to optimise process of an individual equipment or connected units, e.g. yield/costs maximum.

Global Plant Optimiser: Over the local optimisers there are optimal values of main variables for the global plant to maximise efficiency. The execution time is several multiplies of the major time constant of the plant.

3.2 Other requirements for Advanced Process Control

Beyond the above mentioned functions, the APC shall realise the following operating phases:

3.2.1 Model updating

The mathematical model for the process operation shall be updated (at least in its parameters) to reflect the current operating conditions, because all disturbing effects cannot be considered and the process itself may depend on current operating points.

The model updating shall be applied on:

global plant optimisers,

local optimisers,

and all elements of Advanced Regulatory Control level.

3.2.2 Data validation and checking

For good performance, the APC needs a large number of on-line process data. Some of them will not be available all the time because of transmitter error, wire-break, etc. Therefore the APC shall also deal with the continuous verification of the reliability of the individual or correlating data received from process level. If incorrect measured value is received, the APC shall indicate them to the operator.

4 Requirements for hardware and software of Advanced Process Control

4.1 Requirements for implementation of APC

The APC – especially its lower levels – is a part of plant control system, so the operator interface and related new objects (to help operators to handle the plant without APC) shall be implemented on the Integrated Control System (ICS, DCS).

If the solution needs more performance than the ICS has, the APC functions can be implemented on an external hardware platform. In this case, the following requirements shall prevail:

The external computer (APC station) shall be PC-architecture, high-performance industrial workstation, with at least 19” colour monitor, powered by UPS.


6/7 Rev 1.00.00

The operation system of the APC station shall be Microsoft Windows

The connection to the process control system shall be supplied by a dedicated module of the ICS.

During the implementation, the Ethernet connection, TCP/IP and OPC protocol (APC station is client, ICS is server) shall be preferred.

4.2 Requirements for Advanced Regulatory Control

Advanced regulatory controls and complex calculations are nearest the ICS level measures and single-loops. Periodic execution time is between seconds and minute. Functions with direct information for the operator shall be realised on (redundant) ICS controllers, using standard ICS modules.

Related operator displays (HMI) shall be realised on the operator stations of the ICS. Each advanced controller shall be indicated on independent displays that shows input/output and controlled variables, status flags, limits, modes of cascade PID loops, etc. The alarm messages and status of the complex APC controller shall be shown on the display and each event shall be logged. Main parameters shall be changed by the operator (with password or key protection).

Cascade loops shall be constructed to be able to cooperate with APC in its special mode (e.g. RCAS, RMAN) and in other modes work independently of APC.

Continuous updating of the model is not operator level function, but “goodness of the model” shall be able to be observed at the ICS level.

4.3 Requirements for on-line optimising level

The APC controller shall have linear program (LP) function that ensures the optimal tuning of controlled variables considering the costs of parameters.

5 Requirements for design of Advanced Process Control

5.1 Design principles of Advanced Process Control

5.1.1 Modularity

The components of the APC shall be designed to be able to work as independently of others as possible. When one has to be turned off, the others may not stop. Modularity is good for easy handling of the same functions with same displays and operator interface panels.

5.1.2 Robustness

The APC modules shall function efficiently under conditions different than those used for design. Alternate computing procedures or value replacing shall be provided if all of the inputs to a control module are not available. The goal is to keep the APC working in as many extraordinary cases as possible.

5.1.3 Simplicity

During the design, APC shall be built to be as simple as permitted by the problems. Involved or overly complicated functions shall be avoided. Simplicity contributes to ease of understanding, operator confidence, troubleshooting and system maintenance.

5.2 Design & implementation of APC

5.2.1 Feasibility Study

Feasibility Study shall be prepared to map possibilities of advanced process control application for the plant. This study shall be made based on followings:

The Process and Instrumentation diagram (P&I) and I/O list of ICS

On the basis of their experience on similar units as well as their own knowledge, Contractor recommends APC applications for units of the plant that the APC can be applied on.

The study shall include estimated savings and expected benefits of the APC application, detailed by units of the plant, as well as its future measuring methods and check possibilities.

The study shall include the list of the non-existing but recommended measurements and control structures to be modified.

The study shall include the estimated costs phase by phase of the project considering the ICS extension needs as well.


Rev 1.00.00 7/7

5.2.2 Functional Design Specification

This is the design of the Advanced Process Control application, that shall include:

Detailed description of all APC elements, inputs and outputs, and connections to other APC modules.

List of all equipment, hardware and software elements for the implementation of the APC, its specifications.

It shall include the ordering specification of new measurements and description of modified control structure.

Estimation of savings based on plant parameters and cost components in case of other benefits (e.g decrease of parameter variances) the calculation for the expected value.

Methods for continuous measuring of “goodness” of the APC controllers and savings.

5.2.3 Step test

This test can be performed on site, in the plant. Mass of main input parameters shall be collected generating main actuator outputs one by one.

Collected data are sent to a mobile database from a provisional on-line connection to the ICS or the historical database. Preliminary APC parameters shall be identified based on this data (controlling identification).

5.2.4 APC system integration

The APC related hardware and software components are installed and integrated into the ICS system in this phase. All of hardware/software shall be modified and installed. This procedure shall be supervised by the ICS system administrator.

The preliminary parameters of the APC modules can be tuned after installation has been successfully made.

This phase shall include the operator training.

5.3 As-built documentation contents

As-built documentation shall be issued in the finished project, including:

Process & instrumentation diagram (P&I) of the plant completed with APC blocks.

Functional description of the system structure and operation.

Operating and handling manuals.

I/O list of measures not existing in the plant but installed for the implementation, as well as APC related control structures to be possibly modified

Modification of ICS configuration.

Lists of APC blocks, descriptions, configuration parameters.

Connections of function blocks.

Program lists (commented source code)

APC panels and graphic displays for operators.

Description of calculations (new calculated values, inferentials)

Post audit documentation

Post audit documentation shall be issued on the finish phase of the project, including:

Comparison of benefit during APC-ON / APC-OFF period

SLOVNAFT a.s.

R&M Division


MOL Group


INSTRUMENTATION

6. Process Control Systems

5 Requirements for Field Instrumentation Maintenance System

MGS-S-REF-I-6.5

Rev 1.00.00




5 Requirements for Field Instrumentation Maintenance System Page/Pages: 2/14


Release list


1.00.00 30.11.2011 General issue L.Pallagi R.Batha


Rev 1.00.00 3/14

Contents Release list ................................................................................................................................................................... 2 Field instrumentation maintenance system (FIMS) ...................................................................................................... 4 1 General .................................................................................................................................................................. 4 2 Deviations .............................................................................................................................................................. 4 3 General requirements for the FIMS ....................................................................................................................... 4 4 The functional requirements of the FIMS .............................................................................................................. 4 5 Requirements to FIMS elements ........................................................................................................................... 6 6 Diagnostic capability of FIMS system.................................................................................................................... 7

6.1 General requirements for diagnostic capability of FIMS ............................................................................... 7 6.2 Requirements for self-diagnostics and manageability .................................................................................. 7 6.3 Requirements for advanced diagnostics of field devices ............................................................................. 7 6.4 Requirements for predictive maintenance .................................................................................................... 7

7 Transmitter diagnostics ......................................................................................................................................... 8 8 Control valve diagnostics ...................................................................................................................................... 9

8.1 Requirements for on-line diagnostics ........................................................................................................... 9 8.2 Requirements for off-line diagnostics ........................................................................................................... 9

9 Partial Stroke Test (PST) of safety shut-off valves ............................................................................................. 10 10 Displays & printed reports requirements of FIMS ........................................................................................... 11

10.1 General requirements on display of FIMS .................................................................................................. 11 10.2 FIMS reporting function .............................................................................................................................. 11 10.3 General report contents .............................................................................................................................. 12

11 Database connection between FIMS and SAP/PM ........................................................................................ 13 11.1 Preview ....................................................................................................................................................... 13 11.2 Introduction ................................................................................................................................................. 13 11.3 FIMS Application Server ............................................................................................................................. 13 11.4 Requirement on database connection ........................................................................................................ 13

12 Vendor’s obligations ....................................................................................................................................... 13 12.1 Scope of supply .......................................................................................................................................... 13 12.2 Service supply obligations .......................................................................................................................... 14

13 Applicable standards and provisions .............................................................................................................. 14


4/14 Rev 1.00.00

FIELD INSTRUMENTATION MAINTENANCE SYSTEM (FIMS)

1 General

The present specification includes the requirements for the Field Instrumentation Maintenance System applied in industrial process control - hereinafter maintenance system.

This specification does not cover analyzers connected to Analyzer’s Maintenance Network, intelligent MOVs have their own central control unit, expert diagnostic system of rotating machines, diagnostics of Safety PLC and BPCS elements (PLC, DCS, etc.).

2 Deviations

The applicable Project Specification may contain deviations from or changes to this document. Deviations from the contents of this specification and the Project Specification shall be permissible only on the basis of prior written approval by MOL PLC. The specified solutions shall be in conformance with the specification system, standards and requirements of the applicable project documentation.

3 General requirements for the FIMS

Each applied FIMS shall meet the following general requirements:

The processing of signals received from field devices in the field instrumentation maintenance system (FIMS) shall not affect the output signals of transmitters used for control and regulation, the operating algorithms of controllers and regulations, the functioning ability of final control elements or the ex-proof protection of field devices.

It shall be capable to integrate with the ICS.

The solutions where FFB and HART devices can be uniformly handled by the maintenance software shall be preferred.

It shall facilitate the checking and testing of complex control loops, logic and shutdown functions by simulating measurement signals from the respective transmitter and the readability of the actual position of control valves.

Different access levels are needed for different functions, which shall be password or key protected. Only authorized personnel shall be permitted to work in the system, it shall provide security against the access and intervention of unauthorized personnel. The device shall include write security ensuring protection against the accidental modification of data.

The configuration modification of the intelligent field device applied in safety instrumented control systems shall be ensured with a separate safety level (password).

It shall have a common database which includes historical data as well, allowing the history of the device to be checked. It shall archive any changes in settings of the device, as well as diagnostic actions, configurations, calibrations and operator notes, in a retrievable way. It shall also store the time of modification and the data of the person performing the modification.

Adding of new devices shall be simple, and the system shall be of a design expandable in a flexible way.

4 The functional requirements of the FIMS

Each applied FIMS shall meet the following functional requirements:

FIMS shall support the assistance in the implementation and commissioning activities, performance of device configuration,

FIMS shall provide function for checking, modification of parameters and calibration via the Integrated Control System and their documentation.

FIMS shall have provision of on-line or offline diagnostic information.

FIMS shall support predictive, proactive and preventive maintenance of field devices in order to reduce the needed reactive maintenance and repairing down time.

FIMS shall provide a capability to upload, download and store configuration information from connected field devices.

FIMS shall store the field device configuration information to robust field device database.


Rev 1.00.00 5/14

FIMS shall provide universal support for standardized fieldbus (e.g. HART, FF - FOUNDATION fieldbus) with device-specific support for a multitude of device manufacturers.

FIMS shall support administration of traditional (non-smart) field devices.

FIMS shall provide field device diagnostics which are divided into three categories:

o Failure detection and identification

o Condition monitoring

o Performance monitoring

Failure detection and identification:

o Field Device shall perform failure detection on the entire device (electronics, sensors and configuration) and the interconnecting/grounding wiring in order to detect any failure.

o Failure alerts of field device shall be event driven and do not require polling for access.

o Be capable to monitor in real-time the basic status information as information that is included with every message from a field device.

o Basic status information shall enable the host application to immediately identify warning or error conditions detected by the field device.

o Status messages also shall enable the user to differentiate between measurements that are outside sensor or range limits and actual hardware malfunctions.

Condition monitoring (on-line):

o Collects data on-line and shows trends under real process conditions.

o FIMS shall automatically poll device conditions information and alert users to a potential problem before the problem begins to disturb processes.

o Field Device shall have a diagnosis within the device itself by self-monitoring.

o Field Device statuses based on its conditions such as alert or warning shall be generated by a field device itself.

o The results of conditions monitoring shall be reliable to enable the operator or maintenance staff to take the appropriate action.

o All the relevant conditional parameters shall be readable and timely.

o Out of operational specification of field Device shall be detected. Deviations from the permissible ambient or process conditions shall be determined by the device itself through self-monitoring or faults in the device itself indicate that the measuring uncertainty of sensors or deviations from the set value in actuators is probably greater than expected under operating conditions.

o The collected real-time data from real processes affecting field devices is visualized through the color-coded alert system, thus providing a clear view of condition.

o The operational status of field device (e.g. out of service, diagnostic in progress, calibration in progress, test mode) shall be alerted.

o Condition monitoring uses a user friendly interface that allows the information to be shown for maintenance staff across the ICS network structure in real time.

o Alerts and warnings shall be also e-mailed or web-enabled interfaced through internet to the right maintenance persons.

o In accordance with NAMUR NE107, alerts and warnings shall be classified with status classifications such as 'maintenance required', 'function check failure', and 'outside of specification'. This approach supports categorization of diagnostics according to NE107, thus ensuring the right diagnostic information is available to the right person - at the right time.

Performance monitoring:

o It shall be based on monitoring and trending of performance related quantities.

o Preselected and monitored field device related quantities and trends shall be compared to fixed and user modifiable limits on a regular basis and whenever any of the values exceed the defined limit, the valve controller shall generate an alert.

o Diagnostic counter shall be provided that counts the number of times the particular diagnostic was detected during the life of the field device.

The FIMS shall communicate digitally with the intelligent field instruments, which provide information on the status and operational conditions of the instruments as well, and also remote configuration is possible.

The system shall support the most widespread standards of open digital field communications protocols.


6/14 Rev 1.00.00

The following communication buses can be applied:

Table-1: Field bus technology for FIMS

Type Field bus technology Standards

Device bus HART communication (4-20 mA, HART

multiplexer) EN 61784-1 CPF 9, EN 61158 Type 20

Fieldbus network

Foundation Fieldbus (FF-H1) EN 61784-1 CPF 1, EN 61158 Type 1

Profibus PA EN 61784-1 CPF 3, EN 61158 Type 3 EN 50170

Wireless field communication

Wireless HART IEC/PAS-62591

ISA SP100.11a Wireless ISA SP100.11a (draft)

The FIMS and the connected field devices shall support the Electronic Device Description Language (EDDL), Electronic Device Description (EDD) and Field Device Tool / Device Type Manager (FDT/DTM) format in order to ensure the interoperability.

5 Requirements to FIMS elements

The following is a list of the possible FIMS elements as well as their requirements:

Intelligent (smart) field devices, HART multiplexers and (ICS) I/O cards:

o In case of HART field device the HART devices shall be logged with the Hart Communication Foundation and used according to HART Technology guides and the DDL specifications in the EDDL International Standard (EN 61804-2).

o In case of Foundation Fieldbus (FFB) field device the FFB devices shall be logged with the Foundation Fieldbus Check Mark Logo.

HART multiplexer:

o The HART multiplexers which are part of the Safety Instrumented System shall be safety related and complied with EN 61508.

FIMS system server:

o Have sufficient backup (memory, disk capacity, power) for running the actual and the next version of the software.

o Have enough storage space for the common database storing the field instrument data.

o Be a platform for running modern diagnostic software.

o Provide communication interface for HART, Foundation Fieldbus and Wireless devices, hand-held communicators & calibrators and OPC link to clients & applications.

FIMS system client:

o Use Microsoft Windows operating system.

o Provide a memory and background storage capacity conforming to the number of devices to be connected.

FIMS maintenance software:

o Provide the central database of the field instruments connected to the FIMS server in a form allowing copying, saving and re-loading.

o Provide operator interface for the maintenance personnel.

o Provide tools and software packages for the configuration, calibration, debugging and testing of the field units.

o Archive configuration and diagnostic data for future verification.

FIMS application server: (see later)

HART communicator:

o The device shall be connectable to the FIMS, and the data of the intelligent field device shall be interchangeable with the server database data (upload/download).


Rev 1.00.00 7/14

6 Diagnostic capability of FIMS system

6.1 General requirements for diagnostic capability of FIMS

As a minimum, diagnostic capabilities shall report critical failures of devices.

Diagnostics shall be reported to the FIMS via Alarms and Alerts of field devices.

Polling schemes for diagnostics are not acceptable. Diagnostic alerts of field device shall be event driven and do not require polling for access.

Diagnostics shall be reflected in data quality to the operator and control loop, as well as through separate diagnostic alarms intended for maintenance.

Remote diagnostics of field devices from any FIMS workstation shall be provided.

FIMS shall provide for a separate FIMS workstation (client) to allow device diagnostics separate from operating functions.

FIMS shall provide a streamline routine maintenance tasks such as loop checkout, configuration and calibration.

FIMS shall provide an automatic documentation of diagnostics and maintenance activities.

The FIMS system with the connected fieldbus shall provide pass-through capability to transfer non-control data (diagnostic, device alerts, and calibration settings) from field device to FIMS applications.

The desired diagnostic capability of field device shall be based on criticality levels (Level 1,2,3,4) where Level 1 has the highest criticality and the Level 4 has the lowest:

Level1 Failure of a Level 1 field device will result in a total system trip, causing a shutdown of the entire unit, or other unavoidable losses in excess of 10M EUR. The safety related field device shall be Level 1.

Level 2 Failure of a level 2 field device will result in a total system trip, causing a shutdown of the entire unit, or other unavoidable losses in excess of 100K EUR. However, the Level 2 field device’s process dynamics allow time for quick recovery from the failure, either by quickly fixing a fault or by taking manual control.

Level 3 Failure of this field device will not result in any short-term risk of total unit shutdown or major operating losses.

Level 4 No Control and safety, Level 4 field devices are measurement only devices that shall not be used for control and safety purpose.

6.2 Requirements for self-diagnostics and manageability

The FIMS system shall include self-diagnostic capabilities (in order to detect also all faults & failures occurring in its own units & multiplexers and output the respective alarms).

It shall include an easy-to-survey scalable man-machine interface, facilitating the quick location of the faults/failures occurring and assisting in the identification of the origin of the fault (detector failure, transmitter failure, communication fault, configuration error, operating error).

The system shall include a unified database, providing facilities for its copying, back-up saving (downloading & uploading), modification and correction.

6.3 Requirements for advanced diagnostics of field devices

The execution of diagnostic processes shall be initiated or scheduled by the operator.

The results of continuous self-diagnostics shall be displayed both on the operator console monitor and the screen of the maintenance workstation.

Abnormal Situation Prevention Detection

The intelligent smart field device shall have sophisticated diagnostics able to detect abnormal process conditions in a wide variety of applications based on statistical process monitoring (e.g. the sensor samples pressure at high frequency and the transmitter internally computes the statistical mean of the pressure and standard deviation of the process noise over a user defined period of time).

6.4 Requirements for predictive maintenance

The FIMS system shall include features supporting the principle of predictive maintenance.


8/14 Rev 1.00.00

The application (of off-line or on-line predictive maintenance) shall allow the failure of instrumentation items to be predicted, making it possible to take the necessary actions by placing orders for repairs and spare parts supply before an item fails and is lost, reducing thereby the shutdown time of the technological process concerned.

The system shall measure/count the variables having an effect on maintenance needs (e.g. the number of valve stem strokes), detect hidden faults.

The FIMS system shall store measuring data for future analysis and comparisons,

System shall be capable of predicting faults/failures from the phenomena detected (alarm function) in order to avoid the occurrence of failures/malfunctions and process upsets occurring as their result.

It shall provide combined diagnostic capabilities (infer impending failures from information supplied by several devices)

FIMS shall optimize maintenance/servicing intervals, schedule maintenance and calibration activities on the basis of the above information (estimate the service of instrumentation items).

7 Transmitter diagnostics

Level 1, 2 minimum diagnostic requirements:

Temperature transmitters shall detect open and shorted temperature sensors.

Magnetic flowmeters shall detect an empty pipe, high process noise.

Coriolis flowmeters shall detect air slugs.

Pressure transmitter shall have plugged impulse line detection capability.

All transmitters shall have statistical process monitoring.

All transmitters shall have vibration, noise and drift monitoring.

plus requirements of Level 3,4


Field communication status (including but not limited to):

o Parity error

o Overrun error

o Framing error

o Checksum error

Transmitter device status (including but not limited to):

o Field device malfunction

o Configuration changed

o Cold start

o Analog output current fixed

o Analog output saturated

o Primary variable out of limits

o Non-primary variable out of limits

o Sensor failure

o Sensor malfunction

o Sensor disconnected

o Electronic Board failure

o Bad grounding

o Operating conditions out of specifications (e.g. cell temperature)


Rev 1.00.00 9/14

8 Control valve diagnostics

8.1 Requirements for on-line diagnostics

At normal process conditions the positioner of control valve shall have next diagnostic capabilities.


Measuring of valve friction, statistics and alert with adjustable limit (in case of sliding stem valves);

Measuring of valve torque statistics and alert with adjustable limit (in case of rotary valves);

Measuring of bench-set, statistics and alert with adjustable limit;

Travel Accumulator: contains the total change in travel, in percent of ranged travel. The accumulator only increments when travel exceeds the deadband. Then the greatest amount of change in one direction from the original reference point (after the deadband has been exceeded) will be added to the Travel Accumulator, alert with adjustable limits;

Cycle Counter (Changes of direction): displays the number of times the valve travel has cycled. Only changes in direction of the travel after the travel has exceeded the deadband are counted as a cycle. Once a new cycle has occurred, a new deadband around the last travel is set, alert with adjustable limits;

plus requirements of Level 3,4


Measuring of I/P converter input signal (drive signal) and alert with adjustable limit;

Measuring of input signal or setpoint (if not digital, e.g. 4-20mA);

Measuring of actuator signal pressures (the input pressure to the actuator);

Measuring of valve position (by travel sensor);

Calculating of travel deviation: the difference between setpoint and actual travel (valve position) and alert with adjustable limit;

Measuring of supply pressure and alert with adjustable limit;

Measuring of environmental temperature and alert with adjustable limit;

Measuring of actuator differential pressure: the pressure differential across the piston(s) on double acting cylinders;

Assembly error alert;

Calibration/configuration error alert;

Electronics failure (memory, processor, communication) alert;

Sensor(s) failure alert;

Mechanical failure alert;

Positioning error alert;

8.2 Requirements for off-line diagnostics

Out of normal process conditions the positioner of control valve shall have next diagnostic methods:

Dynamic Scan: shall show the integrity of the valve body and actuator assemblies. Parameters (Input Start [%], Input End [%], Scan Time [sec], and Collection Interval [sec]) shall be adjustable.

Valve Signature: Actuator pressure [bar] – Travel [mm] curve, in full stroke, both directions (open-close).

Dynamic Error Band: Valve position [%] – Input signal [%] curve, in full stroke, both directions (open-close).

Drive Signal: Input signal of I/P converter [%] – Input signal [%] curve, in full stroke, both directions (open-close).

Step Response: Valve position [%] – Time [sec] curve, in full stroke, both directions (open-close). Parameters (Number of steps, End Point [%], Ramp Time [sec] and Collection Time [sec]) shall be adjustable.

Step Response with supply pressure: Valve position [%] – Time [sec] curve.

Step Response with Drive Signal: Valve position [%], Input signal of I/P converter [%] – Time [sec] curve.


10/14 Rev 1.00.00

9 Partial Stroke Test (PST) of safety shut-off valves

The FIMS shall be able to generate their own SIF performance databases and digital documentation of tests and test results over the life cycle.

The proof test shall demonstrate that the automated safety shut-off valve can operate as required, such as achieving the safe state position, speed of response, and leak tightness.

The equipment shall be approved by the MOL for the PST application. Partial stroke test facilities shall be subjected to analysis and testing and shall have demonstrated history in the process sector. The PST application shall be SIL3 compliant in accordance with EN61508 per notified body (e.g. TÜV), is suitable for use in safety instrumented functions.

General requirements for Partial Stroke Test (PST):

The Partial Stroke Test shall not compromise the safety integrity of related SIF.

The Partial Stroke Test shall not increase spurious trip rate.

The Partial Stroke Test shall be activated by manually (operator’s demand), automatically (scheduled at a particular time) and by means of a separate Binary Input from SIS Logic Solver (option) and it shall be controlled from a FIMS.

The FIMS related to PST shall provide a maximum PST time alarm.

The Partial Stroke Test as part of FIMS shall provide test results and valve test history. The maintenance records shall be in compliance with EN 61511.

The use of safety related positioner with integrated Partial Stroke Test functionality with travel sensor, pressure sensor, certified solenoid valve, limit switches, PST fault alarm output etc) are allowed.

In case of integrated PST in smart positioner, the state of the last three performed PST tests shall be stored in the smart positioner with a time stamp.

The PST test parameters shall be adjustable in the FIMS and/or smart positioner with integrated PST.

PST shall have means for preventing inadvertent manual opening of the safety shut-off valve - which is in the emergency closed position as a result of a trip signal - and prior to reset of trip signal in the PE Logic Solver.

PST as part of the FIMS shall monitor the full stroke travel movement and time of safety shut-off valve in the event of emergency closure of the safety shut-off valve as a result of a trip signal from PE Logic Solver.

The PST test shall involve moving the valve a minimum of 10-15%, which tests a portion of the valve failure modes. The remainder of the failure modes shall be tested using a full-stroke test. The Proof Test Coverage (PTC) shall be taken in consideration. (Note: Based on the OREDA data, the maximum percentage of the failures that can be detected by a partial-stroke test is 70%. The remaining 30% of the failures can only be detected using a full-stroke test.)

Regardless of the partial stroke test method and its Proof Test Coverage (PTC), a (full stroke) proof test shall be conducted at an interval appropriate to detect incipient and degraded conditions, as well as to detect failures of the safety shut-off valve that are not detected by the partial stroke test. The remaining failures shall be detected by a (full) proof test, which demonstrates that the valve operates as specified.

The ESD trip function of safety shut-off valve shall be available during Partial Stroke Test. The ESD trip function shall have priority over any PST function by:

o bleed the actuator of safety shut-off valve by a separate safety related SOV installed between the positioner and the actuator (Note: no SOV test opportunity)

o removing the power of smart positioner with a safety related relay or force it in safety position. In this case the smart positioner shall be safety related and certified according to EN 61508 (SIL3 for shutdown). (Note: demand for full stroke by removing of energy at positioner input that would inhibit the smart positioner from working so no diagnostic capabilities would be available during this operation, making full stroke monitoring impossible.)

If the Partial Stroke Test does NOT test the solenoid, then a redundant solenoid shall be required to meet higher SIL ratings.

Full stroke testing (FST) of the SIF during plant shutdown shall be supported by the diagnostic features implemented in the smart positioner and/or FIMS.

Valve signature of safety shut-off valve shall be collected during on-line PST and when Full Stroke Test initiated via a safety demand (plant trip)

The smart positioner shall be safety related, because the positioner can fail and vent air from the valve actuator, the positioner does contribute to the spurious process trip rate during normal operation.


Rev 1.00.00 11/14

The PST test status shall be assigned to a performed partial stroke test. As a result, it shall be possible to recognize whether a partial stroke test was successfully completed or not. In the case that the PST test was not successfully completed, the possible source of error shall be indicated. PST test status (e.g. PST test in progress, alert on failed PST or FST) shall be reported to PE Logic Solver as well.

The PST signatures shall be automatically stored in the software database of FIMS and have ability for retrieval of PST/FST data and other diagnostic data. The diagnostic analysis shall be graphically plotted over time to easily identify performance degradation.

The test shall be conducted according to a written procedure. Verification of test execution shall be included in the procedure, as necessary.

The team shall assess the hazards of performing a full stroke test on an in-service block valve and the hazards if the valve does not return to its normal operational state when the test is completed.

10 Displays & printed reports requirements of FIMS

10.1 General requirements on display of FIMS

FIMS system shall be separated from the operator/engineering workstations, may be used to manage and display real-time and historical diagnostic & maintenance information.

FIMS shall provide displays to configure, troubleshoot, and test the connected field devices and maintain a database of these devices.

FIMS shall provide a capability to upload, download and store configuration information to/from connected field devices.

For security reasons, the FIMS system (servers, client stations) and functions shall be maintained on a separate FIMS server with access only from a controlled area. This will prevent changes from being made to the network, thus affecting the entire control system, without proper control and management of change procedures in place.

Failure diagnosis shall be sufficiently specific to indicate which printed circuit boards, modules, or devices are at fault.

The displays shall be designed to help maintenance and engineering personnel diagnose faults in the system and communications paths.

Each category of diagnostic display shall be organized hierarchically.

Online displays shall indicate the results of self-diagnostic tests.

Communications diagnostic displays of FIMS shall show errors for each of the connected field bus with redundant paths (if available).

All alerts generated by the field devices trough FIMS system shall be captured and electronically logged chronologically to the alert database on a hard disk on one or more designated FIMS workstations.

Alerts of field devices and FIMS shall be time-stamped by the event generator.

It shall be possible to retrieve and sort alerts by time (ascending or descending order) or by type.

The Operator shall be able to filter the alerts on certain criteria such as time, tag name, area name, or any specific event.

Alerts and the historical trend information for a field device tag shall be integrated into a single view.

The system shall provide the following displays and printed reports:

o Database of instrumentation items installed in the process unit,

o Listing of devices by tagname, vendor, type/model, etc.

o Search by device tagname, vendor and device type/model, etc.

o Event and failure log of connected devices,

o By system architecture.

10.2 FIMS reporting function

FIMS shall have a reporting and documentation tools for printing the recorded results of diagnostic, calibrations and testing activity and alerts in chronologically orders related to connected field devices.

FIMS reports shall be exported in Acrobat PDF format and stored in FIMS server.

Print on demand shall be included for all views possible with the alerts of field devices and FIMS viewer application.


12/14 Rev 1.00.00

Full audit trail capabilities of each field device connected to FIMS shall be recorded and reported, including as found and as left calibration history.

The historian of FIMS shall have record, query and sorting ability, including the ability to sort on and generate a report.

FIMS shall support the reporting procedure with a template report related to particular field devices intended use for calibration or testing.

The application of FIMS shall enable the reports (PST, calibration etc.) for the field device to have an entry of the person responsible for validating the procedure related to report.

Calibration report shall include the following (including but not limited to):

o A unique calibration certificate number;

o Calibration status;

o Calibration data related to calibrated field devices;

o Functional location of the device;

o Date the calibration was performed;

o Date the calibration will expire;

o Calibration interval for the device.

The PST results shall be recorded in the FIMS and reported as a PST report which shall be acceptable by safety audit and readily available.

The PST report with approved contents (e.g. by TÜV) shall be part of Safety Audit Documentation for proof of testing.

The PST report shall explain how the product was tested and what application criteria must be met for the product to retain its certification.

PST report shall include the following (including but not limited to):

o A unique PST certificate number;

o PST status;

o PST data related to calibrated field devices;

o Functional location of the device;

o Date the PST was performed;

o Date the PST will expire (according to the PST interval);

o PST interval for the field device;

o PST setpoint (80-90%);

o PST response time;

o PST solenoid test (passed);

The FIMS shall have a capability to calibrate the connected field devices and the results of calibration shall be recorded in the FIMS and reported to documentation library of FIMS.

The FIMS shall have a documents library consisting of the calibration reports for the plant field devices being monitored in the FIMS.

10.3 General report contents

Date and time of test;

Owner of field device;

Plant name and location of field device;

Serial number of field device;

Tag number of field device;

Position of field device;

Type of field device;

Model number;

Serial number;

Manufacturer;

Device/hardware/firmware revision;


Rev 1.00.00 13/14

Device Description revision;

Size.

11 Database connection between FIMS and SAP/PM

11.1 Preview

This chapter defines requirements on implementation of data connection between FIMS (Field Instrument Maintenance System) and SAP/PM (FIMS integration).

11.2 Introduction

The solution for FIMS SAP integration shall be executed to enable MOL approach compliance requirements. MOL personnel shall be able to:

Ensure all plant devices being monitored by FIMS meet compliance standards;

Use the FIMS database to generate Plant Maintenance (PM) notifications to SAP;

Plan the maintenance and calibration of devices using SAP;

Have work order numbers for device maintenance/calibration created in SAP on account of PM Notifications coming from the FIMS Enterprise Server to be sent down to FIMS;

Automatic update of the calibration status of the plant devices;

A documents library consisting of the calibration reports for the plant devices being monitored in the FIMS;

11.3 FIMS Application Server

The FIMS Application Server is a modular addition to FIMS which shall provide a bi-directional link for real-time diagnostic alert information to the transactional environment of the SAP system.

The Application Server is a software application that provides the necessary real-time filtering and prioritization of diagnostic alerts from its data sources and onward transmission to the transactional environment of the SAP system. The interface shall provide a bi-directional link so that information such as Notifications, Work order Numbers and Calibration scheduling data also flows back from the SAP system to ‘close the loop‘.

The Application Server shall allow the maintenance organization to act quickly and intelligently based on accurate information communicated directly from the Field Device diagnostics to the SAP R3 system. This shall combine the strengths of SAP‘s plant maintenance (PM) scheduling, work order generation, and maintenance inventory control with the power of the FIMS applications for online health monitoring, diagnostics, calibration management and documentation.

The FIMS Application Server application:

Shall reduce data entry time and the risk of error by automatically populating the SAP asset registry with instrument and valve data.

Shall eliminate manual steps in work process by automatically generating prioritized and filtered notifications when instruments or valves need attention.

Shall automatically create and populate PM notifications based on FIMS advanced calibration management capabilities.

Shall automatically summarize SAP work orders in the FIMS Device Manager Audit Trail, allowing Maintenance technicians to easily cross-reference and track work performed.

The licenses provided for the FIMS Application Server shall cover the number of devices for which PM notifications can be generated.

11.4 Requirement on database connection

Database connection to the SAP shall be implemented on web-service base.

12 Vendor’s obligations

12.1 Scope of supply

It is definitely required that the Vendor shall provide the necessary erection materials, configuration work, system generation and data download in addition to the hardware and software elements required for the complete system.

All hardware devices & software programs shall be supplied (with the items selected as applicable for integrated or multiplexer-based implementation of communication):


14/14 Rev 1.00.00

At least 5% integrated spare place shall be provided that can be freely used for each signal type related to FIMS – depending on the I/O.

10% empty place shall be provided in the equipment for future extensions.

The delivered FIMS System shall have 10% built-in spare related to software license and 30% built-in spare related to communication capability.

12.2 Service supply obligations

The Vendor of the FIMS shall meet the following requirements:

During the design and implementation of the system, it shall follow the functions, structures and other provisions specified in the present documentation. It shall follow the provisions for the further parts of the requirement system as well.

Full service for the whole system as well as its parts.

Participation during the test run.

Consulting in the case of unexpected problems or the use or integration of other maintenance systems.

Continuous development of the software, version update.

Vendor shall provide the training for the operation and maintenance personnel who will be able to operate the system.

During handover, Vendor shall hand over the as-built project documentation, attaching the saving of the complete maintenance system on an electronic media in 3 copies.

13 Applicable standards and provisions

ANSI/ISA-75.26.01-2006 Control Valve Diagnostic Data Acquisition and Reporting

ANSI/ISA-TR96.05.01-2008 Partial Stroke Testing of Automated Block Valves

NAMUR NE 107 (2006) Self-Monitoring and Diagnosis of Field Devices

SLOVNAFT a.s.

R&M Division


MOL Group


6. Process Control System 6. Requirements for machinery protection and monitoring

systems of rotating machine

MGS-S-REF-I-6.6

Rev 1.00.00




6 Requirements for machinery protection and monitoring systems Page/Pages: 2/16


Release list


0.00.00 31.10.2008 Basic release 1.00.00 30.11.2011 General issue Á.Pozsgai R. Batha

SLOVNAFT a. s. MGS-M-REF-I-6.6 R&M Division

Rev:. 1.00.00 3/16

Contents Requirement for machinery protection and monitoring system of rotating machine 1 Overview ................................................................................................................................................................ 4

2 Deviations .............................................................................................................................................................. 4

3 References for Machinery Protection and Monitoring Systems ............................................................................ 4

4 Machinery Protection Systems .............................................................................................................................. 4

4.1 General requirements for Machinery Protection System .............................................................................. 4

4.2 General requirements for transducers .......................................................................................................... 5

4.3 General requirements for Machine Monitoring Systems .............................................................................. 6

4.4 Commissioning requirements for Machinery Protection System and Machine Monitoring Systems ......... 10

5 General requirements for Integrated Monitoring System of Rotating Machines ................................................. 10

5.1 Hardware requirements of Integrated Monitoring System of Rotating Machines ....................................... 10

5.2 Requirements for off-line Portable Data Collector (PDC) ........................................................................... 11

5.3 System software requirements of Integrated Monitoring System of Rotating Machines ............................ 12

5.4 Application requirements of Integrated Monitoring System of Rotating Machines ..................................... 13

SLOVNAFT a.s. MGS-M-REF-I-6.6 R&M Division

4/16 Rev.: 1.00.00

REQUIREMENTS FOR MACHINERY PROTECTION AND MONITORING SYSTEMS OF ROTATING MACHINE

1 Overview The present specifications contain basic requirements for Machinery Protection System, Machine Monitoring Systems of rotating machine and for their integration platform called Integrated Monitoring System of Rotating Machines used in Refineries of MOL Group.

2 Deviations The applicable Project Specification may contain deviations from or changes to this document in well-grounded and meaningful cases.

Deviations from the contents of this specification and the Project Specification shall be permissible only on the basis of prior written approval by MOL PLC.

The specified solutions shall be in conformance with the platform System 1 and existing systems of refinery, standards and requirements of the applicable project documentation.

3 References for Machinery Protection and Monitoring Systems • API 670 Machinery Protection System


• MGS-M/S-REF-I-22.1,2,3 Special equipments (compressors)

• MGS-M/S-REF-M-2.1.8 Machine monitoring

4 Machinery Protection Systems The Machinery Protection System (MPS) consists of the transducer system (sensor and signal conditioner) with signal cables, the central Machine Monitoring Systems (MMS), with all the necessary housings and mounting fixtures as well as connection to the Safety Instrumented System (SIS) in order to maintain a safe state of the protected machine and connection to Integrated Monitoring System of Rotating Machines for process and equipment optimization, condition monitoring and event diagnostics.

4.1 General requirements for Machinery Protection System

• The critical machine used in technological unit shall have Machinery Protection System (MPS) in order to prevent hazardous events which results a serious consequence for the machine, process and operator staff.

• The MPS shall be the integrated part of Machinery Monitoring System which provides early identification of machinery malfunctions before a protection system would cause an alarm or trip.

• The MPS system shall continuously measure and provide online monitoring of key machinery parameters for the critical machine and their associated drivers.

• MPS system shall provide crucial information to the operators regarding progressive damage, over heating, and early detection of machinery problem to aid in making timely intervention to take corrective measures, protective action, shutdown and maintenance.

• The protective action can be manually activated by operator as a corrective action related to alarm warning of MPS or automatically activated by MPS system. The mode of protective action shall be based on the required Risk Reduction Factor (RRF) determined on Process Hazard Analyses (PHA).

• The manufacturer of MPS is obliged to provide a Safety Manual to convey essential safety information:

o Description of the safety function

o Safety Integrity Level (SIL capability)

o Every failure mode in and estimated failure rate (lambda DU, DD, SU, SD)

o Periodic proof test and/or maintenance requirements

o Safety architecture (e.g. 1oo2), Hardware Fault Tolerance

o Classification as type A or type B

o SFF (Safe Failure Fraction);


Rev:. 1.00.00 5/16

o PFD (Probability of Failure on Demand) and/or PFH (Probability of Dangerous Failure per Hour);

o Information about the database for calculation of the values above (e.g. average ambient temperature, failure rate data, specific failure modes, etc.);

• The MPS system shall have configurable alarm setpoints (typically Alert and Danger) related to key measured parameter, which automatically generates an alarm when a predetermined level is reached. The alarm shall activate an annunciation in order to warn the operator about a situation that is not normal or activate protective safety relays.

• The input of Safety Instrumented Function implemented in the MPS shall receive the outputs of the signal processing card and compare against alarm or shutdown setpoints (trip limit) and signal fault criteria (broken signal connection or over ranged).

• Violations of setpoints or signal fault criteria shall result an alarm or shutdown status condition in the MPS system. These status conditions shall be subjected to preset time delays or logical voting (1oo2, 2oo3) with other alarm or shutdown status conditions, and then it shall be used to drive the output protective safety relays and status indicators and outputs.

• All of alarm and shutdown status conditions generated in the MPS shall be visualized on Human Machine Interface (HMI) in the DCS system.

• On occurrence of a faulty transducer (sensor/probe/proximitor) the trip initiator directly related to the BAD input will go to BYPASS mode (averting a spurious trip).

4.2 General requirements for transducers The transducer consists the sensor (Proximity probes, RTDs, Thermocouples, Accelerometers, Magnetic speed sensors) with the extension cables, connectors, the signal conditioners (Oscillator-Demodulator) and signal cables with connectors to the signal processing cards.

• The following type of probes, sensor should be considered:

o Radial Shaft Vibration Probe

o Casing vibration.

o Axial/thrust Position Probe

o Key phasor probe (speed)

o Piston Rod Drop Probe

o Phase Reference Transducer

o Cylinder pressure indicator probe (for PV monitoring)

o Compressor valve temperature probe

o Standard Tachometer Transducer

o Electronic Overspeed Detection System Speed Sensor

o Accelerometer/low frequence casing vibration probe

o Bearing Temperature Sensor

• The type of transducer shall be based on manufacturer's preferences of machine, influenced by MOL Group preference (vendors list), and standards (API 670)

• Measurement made on different machinery elements, such as radial vibration, axial displacement, rod position, bearing temperature, speed indication, case vibration and any other shall be provided as required by the Machinery Vendor to ensure adequate monitoring.

• The transducer shall generate a signal that is proportional to the measured variable.

• Not desirable to use separate transducer installations for machinery protection, monitoring, diagnostics, and management purposes.

• Transducer shall be selected and installed to minimize failures that could result in inaccurate information due to conditions arising from the process and environmental conditions. Transducers shall be chemically resistant according to process and environmental conditions.

• The field probes, sensors and transducers / proximitors etc. shall be supplied with the machinery units by the Machinery Vendor, and shall be completely installed and wired in junction boxes (mounted on the skid) and equipped with the required terminals for the multi-triad terminations.

• Measurement made on different machinery elements, such as radial vibration, axial displacement, rod position, bearing temperature, speed indication, case vibration and any other shall be provided as required by the Machinery Vendor to ensure adequate monitoring.


6/16 Rev.: 1.00.00

• The Machinery Vendor shall supply and install Intrinsically Safe transducer systems according to hazardous area classification.

• The attached connectors to sensor and signal cable shall meet or exceed the mechanical, electrical, and environmental requirements.

• All transducers supplied by Machinery Vendor shall be physically and electrically interchangeable.

• Selection of the appropriate probe material and construction shall be the responsibility of the Machinery Vendor.

• Effective and accurate transducers shall be provided in order to prevent losses of production that may occur because a machine automatically shuts down (tripped) or manually shuts down unnecessarily because the measured parameter are spuriously different as real parameter. In other cases an automatic shut down (trip) or operator’s corrective action may be missed so this results an undesirable damage in the protected equipment.

• MPS accuracy requirements shall be based on Table 1 in the API 670 standard

• The portion of a transducer’s output where the output versus input relationship is linear within a specified tolerance.

• The standard temperature sensor shall be a 100-ohm, platinum, three or four-lead resistance temperature detector

Signal cabling, grounding:

• All conduit, signal and power cable, and monitor system components shall be located in well-ventilated areas away from hot spots such as piping, machinery components, and vessels.

• Signal and power wiring shall be segregated according to good instrument installation practices (see MGS-M-REF-I-22 & MGS-S-REF-I-22).

• Signal wiring shall not be run in conduits or trays containing circuits of more than 30 volts of either alternating or direct current.

• Signal wiring shall be shielded, twisted pair, or shielded triad to minimize susceptibility to electromagnetic or radio frequency interference.

• Signal cables shall not exceed a physical length of 150 meters and use continuous runs only.

• The transducer signal and the signal common (SC) shall be isolated from the machine ground and shall be shielded.

• The machinery protection system instrument signal common (SC) is designed to be isolated (not less than 500 Kohms) from electrical ground and installed with single-point connection to the instrument grounding system.

• The signal cable shield is only grounded at the monitor system.

• The shield is not used as the signal common (SC) return line.

• Shields are carried through any field junctions.

4.3 General requirements for Machine Monitoring Systems MMS consists the signal processing cards, alarm/shutdown/integrity logic processing, power supplies, display/indication, inputs/outputs, protective safety relays and interface cars to DCS systems and Integrated Monitoring System of Rotating Machines.

Generals

• The system shall be of a modular design with plug-in components.

• Removing or inserting of any main module shall not disrupt the operation of other unrelated modules in the system.

• Printed circuit boards of MMS shall have conformal coating to provide protection from moisture, fungus, and corrosion.

• A common circuit fault relay shall be provided for each MMS system.

• The signal processing and alarm/shutdown/integrity logic functions of the MMS shall be mechanically connected and included in the same housing or rack.

• Hot swapping of electronic cards shall be required to eliminate the requirement of machine shutdowns to facilitate maintenance of the system. Modules can be removed and reinserted without removing rack power.


Rev:. 1.00.00 7/16

• System Spare requirements: 10% Spare Channels / Points at Mechanical Completion. (Basis of design shall be 15% installed spare with delivery in order to achieve 10% spare after commissioning.)

Signal processing

• The design of MMS shall ensure that a single circuit failure (power source and monitor system power supply excepted) shall not affect more than two channels of radial shaft vibration, axial position, casing vibration, speed indicating tachometer, or six channels of temperature or rod drop on a single machine case.

• The MPS system shall have various kind of signal processing cards.

• Signal processing cards shall have an isolation to prevent a failure in one transducer from affecting any other channel.

• The integrity of each transducer and the associated field wiring shall be continuously checked.

• Internal circuit faults in a signal processing card, including transducer system failure, shall be checked and indicated for each individual channel. A no-fault condition shall be positively indicated.

• Each dynamic input channel of signal processing cards shall have a buffered output in order to ensure an unaltered, analog replica of the transducer input signal that preserves amplitude, phase, frequency content, and signal polarity for easy connection to portable and test instrumentation.

• The buffered output of transducer input signals shall be designed in such a way to prevent a short circuit of this output to MMS system ground from affecting the operation of the MPS.

• Individual buffered output connections shall be provided for all system transducers (except temperature) via front-panel bayonet nut connector (BNC) connectors and rear panel connections.

• The output(s) from the signal processing card shall be used as inputs to the alarm/shutdown/integrity, display/indication and logic circuitry of a MMS.

• The signal processing cards for electronic over-speed detection, the time required to detect and initiate an alarm (alert) or a shutdown (danger) shall not exceed 100 milliseconds.

• Where applicable, the MMS’s signal processing cards shall provide transducers with appropriate power via short-circuit protected terminals

• In case when a machine is provided with spare/stand-by machine, the signal processing cards for primary and spare/standby shall not be assigned into the same signal processing cards.

• The MMS shall have signal processing cards with or without internally mounted Intrinsicaly Safe (IS) barriers to reduce installation costs when hazardous environments require intrinsically safe installation practices.

Alarm processing

• The MMS shall be a microprocessor-based and offer digitally adjustable alarm (Alert) and shutdown (Danger) setpoints that are individually adjustable over the entire monitored range for each channel.

• The alarms shall be configured as a latching or non-latching operation.

• Electrical or mechanical adjustments for zeroes, gains, and alarm (alert) and shutdown (danger) setpoints that are field changeable shall be protected against unauthorized access.

• The means for adjustment, including connection(s) for a portable configuration device, shall be accessible from the front of the MMS system.

• The alarm and shutdown functions of MMS shall be manually or automatically bypassed during adjustment accordance.

• The MMS shall have a means to identify the first-out alarm (alert) and the first-out shutdown (danger).

• Failure of a sensor/probe, power supply, module, card, cabinet temperature high or logic device in any circuit shall initiate a system alarm only.

Display, indication function

• An integral, dedicated display shall be capable of indicating all measured variables, alarm (alert) and shutdown (danger) setpoints.

• There shall be a status indication LEDs for each monitor allowing observation without operator interaction for convenient operation.

• The MMS shall have a method of energizing all indicators test purpose.

• Measurements with their statuses shall be displayed on a color display located on the front of the MMS.

• The display of MMS should be integrated and my be an analog, digital or graphic indication


8/16 Rev.: 1.00.00

• The display of MMS shall be updated at a minimum rate of once per second.

• Shutdown (danger) indication for each channel that indicates channel alarm status shall be independent of voting logic.

• Shutdown (danger) indication shall be positive indication (for example, illuminated when channel violates its shutdown setpoint).

• When specified, shutdown (danger) indication shall conform to operation of the voting logic.

• All radial shaft vibration, axial position, rod drop, and casing vibration channels, associated outputs, and displays shall have a minimum resolution of 2% of full scale.

• Temperature channels, associated outputs and displays shall have one (1) degree resolution independent of engineering units.

• Tachometer and electronic over-speed detection system channels, associated outputs, and displays shall have a resolution of one (1) rpm.

• The status indication of MMS shall have a method of energizing all indicators for test purposes

• The following minimum local status indication (positive illumination) shall be provided:

o Power status.

o Status of the communication link with the non-integral display.

o System circuit fault.

o System alarm (alert).

o System shutdown (danger).

o System shutdown bypassed.

• The MMS system shall have Keylock Security to prevent unauthorized tampering. The configurable software of modules shall be key lockable.

Input/outputs/Interface

• The MMS shall provide independent 4 to 20 mA proportional outputs for each channel of the siganal processing cards for connection to strip chart recorders or for process control systems (DCS, PLC) that do not support a digital interface.

• MMS system shall have communications module with serial: RS-232/422/485 and/or Ethernet network connection port located at the rear of the monitor system for supporting MODBUS and/or MODBUS/TCP protocols.

• The MMS system shall allow the installation of multiple communication module installed in a single MMS rack for link redundancy or when multiple protocols are needed.

• The MMS shall have an internal data table whose size and data type shall fulfill the measured numerical and constituted internal logical variable in order to use of a binary representation of the variable for communication protocols (MODBUS, MODBUS/TCP).

• The following information shall be available from the digital communications port of MMS:

o Channel status of alarm or no alarm.

o Armed/disarmed (maintenance bypass) shutdown status for the monitor system

o Alarm storage for storing the time, date, and value for a minimum of 64 alarms.

o Channel value ±2% full-scale range resolution.

o Measured value as a percent of alarm (alert) and shutdown (danger) values to 1% resolution.

o Channel status; armed/disarmed

o Transducer OK Limits.

o Hardware and software diagnostics.

o Communication link status.

o Alarm setpoints.

o Gap voltage, when applicable.

o Current system time, time stamp and date of event for all transmitted data.

o System entry log to include date, time, individual access code, and record of changes.

o Setpoint multiplier invoked

• MMS system shall be provided with an internal time clock that shall have provisions for remotely setting the time and date through the digital communication port


Rev:. 1.00.00 9/16

• The MMS system shall be capable for connecting to an external Transient Data Collector and Interface (TDX, through RS-232/422/485 MODBUS) or shall have a dedicated interface card (Transient Data Interface, TDI) for collecting steady state and high speed transient waveform data and pass this data trough a high speed Ethernet interface (10/100 Base) to host (e.g. Integrated Monitoring System of Rotating Machines) in order to significantly improve in both data collection features and data transmission.

• The dedicated Transient Data Interface (TDI) card shall continuously provide the following static and transient data collection and interfacing as follows:

o Static values data collection

o Event base data collection: Supports multiple events per revolution speed inputs up to 20 kHz.

o Startup / Coastdown Data: Data collected from speed and time intervals.

o Alarm Data Collection, pre- and post-alarm data: e.g. 1 second static values collected for 10 minutes before the event and 1 minute after the event.

o Waveform Sampling: Simultaneous Synchronous (e.g. X samples/ Y revolutions) and Asynchronous data (based on selectable frequency span: 10 hz-30 kHz) sampled during all operational modes.

Protective safety relays

• As a minimum, one pair of relays, alarm (alert) and shutdown (danger) shall be provided for each of monitored variables.

• An alarm (alert) relay shall be provided for each alarm (alert) output from corresponding each channel.

• A shutdown (danger) safety relay shall be provided for each shutdown (danger) output from corresponding each channel.

• The MMS system shall support the voted channel for channel requiring confirmation from one or more additional channels as a precondition for alarm (alert) and shutdown (danger) relay actuation. The supported voting arrangement: 1oo2, 2oo2, 2oo3, 2oo4.

• The MMS system shall support the logical combination of selected parameters for particular alarm (alert) and shutdown (danger).

• The relays for shutdown (danger) shall be a safety related relay according to EN 61508/61511.

• Output relays shall be the epoxy sealed electromechanical type.

• When specified, hermetically sealed electromechanical type relays shall be provided.

• The relay control circuit shall be field changeable to be either normally de-energized or normally energized.

• De-energize to alarm and energize to shutdown shall be standard.

• All relays shall be double-pole, double-throw type with electrically isolated contacts. All contacts shall be available for wiring.

• Shutdown (danger), alarm (alert), and circuit fault relays shall be field changeable to latching (manual reset) or nonlatching (automatic reset). Latching shall be standard.

• As a minimum, one pair of relays, alarm (alert) and shutdown (danger), shall be provided for each of the following monitored variables:

o Axial position.

o Radial shaft vibration.

o Casing vibration.

o Bearing temperature.

o Piston Rod drop

o Compressor valve temperature.

Power Supplies

• The MMS power supplies shall be capable of supplying power to all components of the machinery protection system

• All power supplies shall be capable of sustaining a short circuit of indefinite duration across their outputs without damage. Output voltages shall return to normal when an overload or short circuit is removed

• The rack power supplies of MMS shall be redundant to assure uninterrupted performance.

• The removal or failure of one-power supply in the rack shall not cause any machinery to trip.


10/16 Rev.: 1.00.00

4.4 Commissioning requirements for Machinery Protection System and Machine Monitoring Systems

• The vendor of MPS and MMS system shall individually bench test each component of the MPS and MMS system to ensure compliance with the installation, operational and accuracy requirements.

• When specified in the MOL’s project specification a factory acceptance test (FAT) of the MPS and MMS shall be conducted. The FAT may include (but is not limited to) integration with BPCS (DCS, PLC+SCADA), SIS, Integrated Monitoring System of Rotating Machines, simulation of transducer system inputs and proper operation of output, display and communication capabilities.

• The MPS and MMS vendor shall have test documentation and certification available for inspection.

• The construction company of Machines (Vendor) shall perform a field test/Site Acceptance Test (SAT) of the entire MPS and MMS system to verify operation to design specification requirements. This field test/SAT shall include MPS and MMS system performance and functionality of its integration with BPCS (DCS, PLC+SCADA), SIS, Integrated Monitoring System of Rotating Machines and results shall be documented..

• The construction company of Machines (Vendor) shall verify that the alarm (alert) and shutdown (danger) setpoints are adjusted to the values agreed upon by MOL’s specialist.

5 General requirements for Integrated Monitoring System of Rotating Machines A Integrated Monitoring System of Rotating Machines uses the data provided by the Machinery Protection System (MPS) and its integrated part the Machine Monitoring Systems (MMS), supplemented by additional machine and process measurements (from DCS, PLC) in order to identify the true operation state and condition of the machine and to provide condition monitoring.

General requirements:

• The Integrated Monitoring System of Rotating Machines shall be based on advanced server-client system architecture and fit to the plant hierarchy with connection to Machinery Protection System (MPS) and Machine Monitoring Systems (MMS).

• The Integrated Monitoring System of Rotating Machines shall provide all of the information necessary to optimize the machinery in terms of operational safety, maximized service life, minimized maintenance cost, and energy efficiency.

• The Integrated Monitoring System of Rotating Machines shall consist of a dedicated Real Time Data Manager (RTDM) for storing all machinery monitoring data and making it available when required. Time synchronization with ICS system shall be provided.

• The Integrated Monitoring System of Rotating Machines shall consist the Plant Machinery Assets (PMA) database for accessing the required documentations, drawings, technical data, operational and maintenance manuals, permits and certifications etc.

• The Integrated Monitoring System of Rotating Machines shall continuously collect real time, transient and steady state data from the Machinery Protection System (MPS), Machine Monitoring Systems (MMS) and Transient Data Collector and Interface (TDX) and provide off-line data uploading collected by Portable Data Collector (PDC).

• The Integrated Monitoring System of Rotating Machines should be based on General Electric Bently Nevada’s ‘System-1’ as a minimum

5.1 Hardware requirements of Integrated Monitoring System of Rotating Machines

• The Integrated Monitoring System of Rotating Machines shall have the following system parts and subsystems:

o Machinery Protection System (MPS) and Machine Monitoring Systems (MMS) with Transient Data Interface (TDI)

o Transient Data Collector and Interface (TDX) connecting to Machine Monitoring Systems (MMS) and/or collect data

o Portable Data Collector (PDC) for off-line data collection and analysis

o Server of Integrated Monitoring System of Rotating Machines

o Local Area Network (LAN) of Integrated Monitoring System of Rotating Machines

o Clients of Integrated Monitoring System of Rotating Machines with

• The data acquisition server of Integrated Monitoring System of Rotating Machines shall be the latest version robust, tested and proven in use server with 19” monitor keyboard. The type of server shall be approved by Integrated Monitoring System of Rotating Machines Vendor.


Rev:. 1.00.00 11/16

• The Integrated Monitoring System of Rotating Machines shall support the following MPC, MMS and TDX systems:

o Bently Nevada 3500, 3300, 2201, 1701 (with communication processor: TDI, TDXnet, TDIXconnX, TDe)

o System specified in MOL’s project specifications

• The Integrated Monitoring System of Rotating Machines shall have high reliable Local Area Network (LAN) based on Ethernet network (10BASE/100BASE) as well as shall support the connection through fiber optic links.

• The LAN of Integrated Monitoring System of Rotating Machines shall be dedicated and independent, completely isolated and secured from Business network (IT-network). The LAN of Integrated Monitoring System of Rotating Machines should be the part of refinery’s Industrial Network (IN).

• The LAN of Integrated Monitoring System of Rotating Machines shall be protected by a firewall or the use of VPN (Virtual Private Network) in order to avoid an unauthorized access and undesirable external intruding.

Requirements for Transient Date Collector and Interface (TDX):

• The Transient Data Collector and Interface (TDX) shall provide interface between Machinery Protection System (MPS)/ Machine Monitoring Systems (MMS) and Integrated Monitoring System of Rotating Machines

• The Transient Data Collector and Interface (TDX) shall continuously collect both steady state and transient data (e.g. startup/shutdown) from all connected MPS, MMS (via RS-232/422/480, MODBUS) in parallel, and shall provide significant improvements in both data collection features and data transmission.

• The collection transient date shall be initiated by external event (e.g. detecting the Keyphasor sensor change in RPM).

• The Transient Data Collector and Interface (TDX) shall have more independent data buffer in order to store collected data related to any initiation event or phase of operation (startup/shutdown).

• The data buffer of TDX shall store waveform record including both synchronous and asynchronous data.

• For synchronous purpose the TDX shall have inputs for keyphasor in order to determine the RPM values and their status.

• The Transient Data Collector and Interface (TDX) shall continuously provide the following static and transient data collection and interfacing as follows:

o Static values data collection

o Event base data collection: Supports multiple events per revolution speed inputs up to 20 kHz.

o Startup / Coastdown Data: Data collected from speed (in RPM) and time intervals.

o Alarm Data Collection, pre- and post-alarm data: e.g. 1 second static values collected for 10 minutes before the event and 1 minute after the event.

o Waveform Sampling: Simultaneous Synchronous (e.g. X samples/ Y revolutions) and Asynchronous data (based on selectable frequency span: 10 hz-30 kHz) sampled during all operational modes.

• The TDX shall have a high speed Ethernet interface (10/100 Base) to Integrated Monitoring System of Rotating Machines as a host.

5.2 Requirements for off-line Portable Data Collector (PDC)

• Portable Data Collector (PDC) shall support the off-line data collection for periodic monitoring of less-critical machinery and fixed assets.

• The PDC shall be able to collect various parameters such as vibration, phase, speed, process data, infrared temperature, and manual entry data such as gauge readings and inspection data are sampled and stored in the data collector.

• The PDC shall have high capacity on-board memory in order to provide enough space for machnery’s data.

• The PDC shall be able to troubleshoot the problem of equipment and understand the root cause of failure

• The PDC shall have a capability for on-board identification and location of the most common mechanical faults (bearings, misalignment, unbalance, looseness)

• The PDC shall be able to classify the detected faults with predefinied severity levels in order to help to priorize maintenance work.

• The PDC shall provide repair recommendation advise for technicians on corrective action


12/16 Rev.: 1.00.00

• The PDC shall provide quantifiable proof of equipment condition and drive investment in repair or replacement.

• The PDC shall have interface (Ethernet, Infrared data port) to upload the collected data to the database of Integrated Monitoring System of Rotating Machines in order to use the advanced capability of Management System (intelligent alarming, decision support, remote access)

• The off-line PDC shall be compatible with the General Electric Bently Nevada System-1 software package, so it shall be able to transfer the collected data to System-1 software package through a built in interface.

• The PDC shall support local data analysis and advisories (spectral content, waveform shape, trends, rate-of-change, alarm statuses)

• The PDC shall be intrinsically safe (IS).

5.3 System software requirements of Integrated Monitoring System of Rotating Machines

• The Integrated Monitoring System of Rotating Machines shall be based on server-client system utilizing robust Microsoft® Windows® operating systems and server technologies, while supporting both standard web browser and purpose-built display clients.

• The Integrated Monitoring System of Rotating Machines client/server architecture shall allow to locate Display (client) stations anywhere within plant’s Local Area Network (LAN), Wide Area Network (WAN), or Remote Access Server, providing the ability to display and share data with one or more data acquisition (server) stations.

• The Integrated Monitoring System of Rotating Machines software shall be able to share or export data with plant control and automation systems (BPCS: DCS, PLC-SCADA systems) using OPC Data Access, OPC Alarm & Event, DDE. The Integrated Monitoring System of Rotating Machines shall have OPC (DA and A&E) server function.

• The database of Real Time Data Manager (RTDM) shall use Microsoft® SQL technology (with latest version and Service Pack), and optimized for extremely fast data storage and event capture, high-resolution trending and alarming.

• RTDM shall (SQL Server Database) store all historical machinery data, asset information, system hardware, and enterprise configuration.

• The database of the Plant Machinery Assets (PMA) shall have a powerful exception reporting and user notification features, and comprehensive equipment properties and configuration information.

• The Integrated Monitoring System of Rotating Machines shall be designed for scalability and flexibility, allowing users to easily configure the system to reflect their unique assets, processes, and operating practices.

• Software of Integrated Monitoring System of Rotating Machines shall include machine diagnostic tools and historical data trending (with archiving and retrieval capability).

• The Integrated Monitoring System of Rotating Machines shall have a Data Acquisition System (DAS) component in order to communicate and acquires data from many sources connected to Integrated Monitoring System of Rotating Machines (MPS, MMS, TDX).

• The Data Acquisition System (DAS) component of Integrated Monitoring System of Rotating Machines shall fulfill the following limits as minimum:

o Maximum number of Modbus® devices per DAS: 150

o Maximum number of Snapshot devices per DAS: unlimited

o Maximum number of configurable portable points per DAS: 20.000

o Data Historian Maximum Limits (Process Data Only): 25.000 configured tag per DAS and 10.000 event/second per DAS

o Maximum trend file length: Unlimited; dependent on available system hard drive space.

o Maximum number of system/alarm events per DAS: Unlimited; dependent on available system hard drive space.

o Maximum number of concurrent viewable events 10,000 events viewable within event list.

o Network Support: Ethernet, Network Transport Protocols: TCP/IP

• The DAS shall be capable of OPC DA and A&E communications with the Basic Process Control System (DCS, PLC+SCADA) for the importation and correlation of process data with the machinery data.

• The Server of Integrated Monitoring System of Rotating Machines shall have a Web Server in order to provide internet or intranet connection for provide remote access through LAN/WAN network.


Rev:. 1.00.00 13/16

5.4 Application requirements of Integrated Monitoring System of Rotating Machines A Integrated Monitoring System of Rotating Machines shall have several kinds of Application Packages in order to provide the ability to view the plots relevant to a specific type of asset or application.

The common platform of Integrated Monitoring System of Rotating Machines is the General Electric Bently Nevada System-1software package.

The following package shall be available:

Display Plots A Integrated Monitoring System of Rotating Machines should support the following display plots to display the collected, stored data and Alarm Event data:

o Current values

o Bargraph

o Machine train diagram

o Alarm/System event list

o Trend / Multivariable trend

o Tabular list

o Timebase (with option for superposition of baseline data)

o Orbit / Timebase (with option for superposition of baseline data)

o Orbit (with option for superposition of baseline data)

o Shaft average centerline

o Spectrum / Full spectrum (with option for superposition of baseline data)

o X vs. Y

o Waterfall / Full waterfall

o Polar/Acceptance region

o Bode

o Cascade / Full cascade

o Reciprocating compressor plots

o Rod position

o Crank angle waterfall

o Crank angle overlay

o Compressor maps

o Exhaust gas temperature (EGT)

o Performance map

o Rotor stator profile

o Rotor shape

o Hydro air gap

o Phasor

o Histogram

o Octave

Turbo Machinery Turbo Machinery Advanced is an on-line condition monitoring and diagnostic software package for critical rotating machinery applications. Features sophisticated vibration diagnostics capabilities.

Hydro Machinery

Advanced on-line machine condition monitoring and diagnostic software package for hydro turbines and generators. Included specialized diagnostics tools and measurement support.

Electrical/Multilin Assets

Advanced on-line electrical equipment condition monitoring and diagnostic software package for motors, generators, and transformers.

Reciprocating Compressors


14/16 Rev.: 1.00.00

Advanced on-line mechanical and performance condition monitoring and diagnostic software package for critical reciprocating machinery applications. Includes sophisticated Pressure-Volume analysis capabilities.

Performance Visualization

Provides plots associated to thermodynamic performance data (note: the Performance Visualization Application Package does not include the calculation of thermodynamic data). Optional pre-engineered calculation templates (Bently PERFORMANCE* software) are available for machines such as gas turbines, compressors, pumps, steam turbines, and generators.

Portable Data Collector

Portable walk-around application supporting the Snapshot family of portable data collectors. This includes a two-channel, one channel IS, and PDA portables for operator rounds.

Essential Insight/Trendmaster Pro

Supports both Essential Insight. mesh and Bently Nevada Trendmaster Pro online scanning systems intended for managing essential and balance-of-plant machinery.

Static Data Management

Provides a suite of plots to manage static data collected using industry standard protocols, as well as from Bently Nevada protection systems.

CMMS Interfaces

Provides an interface to select Computerized Maintenance Management Systems. Includes ability to link to CMMS assets, view work history, Manual work request, and Automated work request.

Rule Logic Results

Decision Support rules use inputs and generate outputs (events, calculations, etc.). In order for rules to be processed, Rule Logic Results must be available in the system. This provides scaleable real-time rule processing.

State-Based Analysis

State-based monitoring provides more sophisticated diagnostics of machines, with the ability to define machine states that can control data storage, filter plot data, and help correlate process data with machinery data.

Smart Notifier

Smart Notifier is a stand-alone application that filters events much like Notification Plans but collects them in one place where each user can check on events for which he or she is responsible.

Event Relay Card and Software

The Event Relay Notification component can trip a relay in response to an event of a specified type, severity and asset location. Works with the Decision Support Application.

The Bearing Expert

Enhances configuration of machines with rolling element bearings by providing a bearing database. Identifies key parameters based on Manufacturer, model or dimension of the bearing. Software works with System 1 Configuration. Install on the Configuration computer.

GEnyus

GEnyus provides anomaly detection for GE Oil & Gas Reciprocating Compressors by leveraging OEM design and performance expertise. Detected anomalies are available through

Rightrax Corrosion & Erosion Monitoring

Enables on-line condition monitoring of critical fixed assets (piping and vessels) via Rightrax wall thickness measurements, data logging, and communications infrastructure. Data can be displayed, stored, and plotted as trends and managed via System 1 alarms.


Rev:. 1.00.00 15/16

AnomAlert Enables data collection via OPC from the AnomAlert Enterprise Server (AES).


16/16 Rev 1.00.00

OPS1 OPS2

B-N System 1 Server

SIS

MODBUS

MODBUS

DCS CTRL NETWORK

MMS

PLC

DCS SERVER

SCADA

TDX B-N LCP

B-N MPS & MMS

FO

B-N LAN

PDC

B-N LAN

FO FO

B-N System 1 Server

B-N System 1 Central Server

B-N System 1 CLIENT

DCS CTRL

B-N System 1 CLIENT

PLANT INFORMATION NETWORK

WAN

REMOTE CLIENT PLANT

DATA HISTORIAN

FO

B-N LAN

DCS CTRL

RELAY OUT

Figure 1. MPS & MMS SYSTEM SYSTEM 1 NETWORK ARCHITECTURE

OPC DA, OPC A&E

AMS SERVER

SLOVNAFT a.s.

R&M Division


MOL Group


INSTRUMENTATION

6. Process Control System

7. RIS connection

MGS-S-REF-I-6.7

Rev 1.00.00



6 Process Control System Date: 30.11.2011

7 RIS connection Page/Pages: 2/7


Release list


0.00.00 31.10.2008 Basic release

0.00.01 01.10.2011 General Review M. Kováč Z. Stanová

0.00.01 30.11.2011 General issue M. Kováč Z. Stanová


Rev 1.00.00 3/7

Contents Release list ................................................................................................................................................................... 2 RIS Link ........................................................................................................................................................................ 4 1 Contents of documentation ................................................................................................................................... 4

1.1 Deviations ..................................................................................................................................................... 4 1.2 Scope of Requirements ................................................................................................................................ 4

2 General Features of the RIS Link .......................................................................................................................... 4 2.1 Function and purpose of the RIS Link .......................................................................................................... 4 2.2 Technical Conditions for the Implementation of the RIS Link ....................................................................... 4

3 Software & Hardware Requirements of the RIS Link ............................................................................................ 4 3.1 General Requirements for RIS Link Implementation .................................................................................... 4 3.2 Requirements Applicable to All Elements of the RIS Link ............................................................................ 5 3.3 Requirements on the Integrated RIS Station ................................................................................................ 5 3.4 Requirements on External RIS Station Computers ...................................................................................... 6 3.5 Requirements on the Firewall Unit ............................................................................................................... 6 3.6 Requirements on the Coupling Device Providing Data Link to the Process Control (ICS) System ............. 6

4 Project Phases of RIS Link Implementation .......................................................................................................... 7 4.1 Conditions Provided by MOL Group ............................................................................................................. 7 4.2 Contents of Information to be Supplied for the RIS System ......................................................................... 7 4.3 Contents of As-Built Documentation ............................................................................................................. 7


4/7 Rev 1.00.00

RIS LINK

1 Contents of documentation

This documentation contains within the Control Systems section the presentation of the functions of the link to be provided towards the Refinery Information System – hereinafter RIS – as well as the requirements for its design, implementation and documenting.

1.1 Deviations

The respective Project Specification may contain deviations from or changes to these requirements. Deviations from the contents of this documentation and the project specification shall be permissible only on the basis of written authorization by MOL Group.

1.2 Scope of Requirements

This document stipulates for the vendor the mode and conditions of connection to the RIS system. The requirements listed here do not apply to systems implemented previously, they shall be observed for newly implemented projects.

This document does not include the specification of the configuration tasks to be carried out by the specialists of the RIS organisation (in connection with the database server and user interfaces), otherwise indispensable for the functioning of the link.

2 General Features of the RIS Link

2.1 Function and purpose of the RIS Link

MOL Group operates a Refinery Information System (RIS) for the continuous retrieval and storage of process data, collecting the information generated by the control systems (ICS) of various production and energy/utility units, making these suitable for processing on a common platform, in a common database.

The common database created in this way allows the performance of various inter-unit accounting tasks, long-term archiving and technological/engineering analyses. Users have access rights to this database in possession of different authorization levels by means of the appropriate interface program (display) through the office network of MOL Group.

2.2 Technical Conditions for the Implementation of the RIS Link

The RIS system is operated by an appointed MOL Group unit, the RIS organisation (Process Control Systems Development). Their task is to operate the software packages of the RIS databases, the performance of the necessary calculations and archiving, application development and training for RIS users, generation of production, energy/utility consumption, etc. reports, supply of data for daily refinery accounting balances as well as the management of communication links with various sub-systems.

The RIS database servers maintain contact with the various ICS systems and other sub-systems (as well as with the users) through the MOL Group information network (LAN, Ethernet). This network is also supervised by a separate MOL Group unit, the Information Services (IS) organisation.

In addition to supplying the hardware and software elements to be provided, Vendor shall also cooperate with the above two organisations in order to ensure the flow of data from the process control systems to the RIS database through the information network.

3 Software & Hardware Requirements of the RIS Link

3.1 General Requirements for RIS Link Implementation

Vendor shall supply all the software and hardware tools and devices required for ensuring the full range of communication links required for the specified data flows. These shall include all parts of the RIS link which communicate with the ICS systems, up to the first connection of the MOL Group information network.

Furthermore, Vendor shall supply all the engineering services included in the implementation of the RIS link to be realized in the scope of this project (data collection, design, installation, software development, commissioning, trouble-shooting, debugging, documentation preparation, etc.).

Vendor shall specify all the above-mentioned tools, devices and services in the proposal submitted.

The deliverables are as follows:


Rev 1.00.00 5/7

A hardware device (RIS station computer) providing access to all process control (ICS) system data and able to accommodate the running of all RIS link programs transmitting these data continuously to the central RIS server. This hardware device may be a computer forming an integral part of the ICS system or also an external computer.

A firewall unit providing the connection to the MOL Group information network but segregating securely the ICS & RIS computers from the MOL Group network.

The hardware device and software (eventually license) tool of the coupling device providing the connection to the process control (ICS) systems.

All the necessary Ethernet network devices (cable, switch, media converter, etc.) through which the RIS station is physically connected to the first network connection of the MOL Group information network assigned for this function.

MOL Group will provide the RIS interface programs to be run on the RIS station computer.

3.2 Requirements Applicable to All Elements of the RIS Link

The conditions required for continuous (24 hours per day, 365 days per year) operation shall be ensured for all system elements.

Uninterrupted power supply shall be provided for all active elements by appropriately sized UPS units providing minimum 30 minutes transition time.

All equipment shall be designed in compliance with the location, installation and operating requirements set forth in Specification MGS-M-REF-I-6 / MGS-S-REF-I-6 for process control (ICS) systems.

Sufficient redundancy shall be provided.

Appropriate documentation shall be provided for all system elements, containing all information (configuration data, settings, program descriptions, passwords, etc.) necessary for continuous operation, maintenance, modifications and eventual replacement.

Vendor shall hand over also the installation kits and licenses of the computers and other equipment, indispensable e.g. for re-installation.

The appointed personnel of the maintenance organization shall be trained and supplied with all means for accessing the system.

All system elements shall be secured against unauthorized access (e.g. by password security, key-locked cabinets, etc.).

All system elements shall be sized so as to be capable of accommodating new communication demands generated upon the expansion of ICS systems, if required. This requirement does not apply to the licenses of software programs supplied by vendor: the limitation of data volumes is permissible subject to the system delivered providing by itself minimum 20% spare capacity and not requiring additional devices or tools beyond the purchase of the expansion license. MOL Group shall be advised to any performance limitation of the system to be supplied already during the bidding procedure.

3.3 Requirements on the Integrated RIS Station

If the RIS station is a component of the ICS system, then the following requirements shall govern:

Vendor shall supply all software tools and hardware devices required for the continuous assurance of link functionality.

The computer shall provide sufficient hardware (CPU, memory, HDD, etc.) performance and capacity for ensuring that the combined load of all the running processes will not exceed on average 60% of the rated values even during the transfer of the total planned data volume (it shall run together even with the one of the highest resource demand among the ICS related functions).

Its operating system shall be based on MS Windows supported by the RIS interface program.

It shall provide for the implementation of the RIS link through an Ethernet gateway independent of the process control network.

Standard (e.g. OPC – OLE for Process Control) protocol shall be used for the implementation of the data link. The RIS station shall be able to function both as the client and server simultaneously.

If – even occasionally –some other activity is being carried out than engineering (e.g. being used as an operator station), then the security of all processes related to the RIS link shall be ensured and the ability to re-start the computer shall also be inhibited.

The label “RIS station, DO NOT switch off” shall be placed at a visible place on the computer.


6/7 Rev 1.00.00

3.4 Requirements on External RIS Station Computers

If the performance or some features of ICS components are not suitable for solving the required function or the vendor installs an external computer for some other reasons of system technology, then the following requirements shall govern:

Vendor shall supply all software tools and hardware devices required for the continuous assurance of link functionality.

The external computer (RIS station) shall be a PC architecture industrial workstation.

It shall include a minimum 17” size graphic colour TFT display monitor with minimum 1024x768 resolution.

The computer shall provide sufficient hardware (CPU, memory, HDD, etc.) performance and capacity for ensuring that on average the load will not exceed 10% of the rated values even during the transfer of the total planned data volume.

Its operating system shall be based on MS Windows supported by the RIS interface program.

Its connection to the process control network shall be the dedicated high-speed coupling device existing inside the particular ICS system – the procurement of the required hardware and software shall also be the task of the vendor.

Ethernet connection shall be preferred in the implementation of the data link with the use of a standard protocol (e.g. OPC), where RIS station = client and ICS = server.

The connections for the RIS server and the ICS system shall be implemented with the use of separate Ethernet linking devices.

The integrity and anti-virus protection of the ICS system shall be ensured from the RIS station in an adequate way.

If – even occasionally –some other activity is being carried out than engineering (e.g. being used as an operator station), then the security of all processes related to the RIS link shall be ensured and the ability to re-start the computer shall also be inhibited.

The label “RIS station, DO NOT switch off” („FIR állomás, leállítani TILOS”) shall be placed at a visible place on the computer.

3.5 Requirements on the Firewall Unit

The firewall shall be only a separate special-purpose hardware unit, the use of software firewalls is not permitted.

The firewall unit shall isolate the MOL Group information network (external port) and the RIS station computer (internal port), each connected a single port of this unit with any connection by some other device being prohibited!

The coupling protocol between the two ports (the MOL Group information network and the RIS Station) shall be an appropriately restricted TCP/IP protocol.

All configuration possibilities shall be disabled at the external port.

Any device – including the firewall – may be connected to the MOL Group network only subject to the permission of the authorized MOL Group information services organisation (IS).

The information services organisation will specify the necessary (fixed) IP address and station name to be set as the external IP address and name of the firewall (these will be assigned to the firewall on the basis of the MAC address with DHCP).

The internal address and name of the RIS Station may be chosen arbitrarily but shall not be in a common IP address domain with the ICS-side IP settings of the RIS Station.

Filtering shall be set to the highest possible value still not hindering the desired data transfer but filtering out other communication blocks.

Incoming messages shall be restricted on the basis of the IP address of the RIS server (as source) and the RIS Station IP address (as destination) as well as the number of the TCP port in use.

Outgoing messages shall be restricted on the basis of the RIS Station IP address (as source) and the IP address of the RIS server (as destination) as well as the number of the TCP port in use.

3.6 Requirements on the Coupling Device Providing Data Link to the Process Control (ICS) System

The device providing the data link form an integral part of the ICS system and is supplied by the ICS vendor. Should the particular ICS system not include the suitable device, then the suitability of the external solution recommended (by a third party) shall be confirmed officially by the ICS vendor. Said confirmation of suitability shall be attached to the proposal.


Rev 1.00.00 7/7

Newly purchased hardware or software interfaces are permissible.

Where an existing interface limiting the data link in volume is involved, the necessary number of licenses shall be understood as interface.

MOL Group shall be advised about restrictions in data volume during the bidding procedure.

4 Project Phases of RIS Link Implementation

4.1 Conditions Provided by MOL Group

In the course of project implementation MOL Group – as the operator of the RIS server and the information network – will provide the following initial conditions for vendor:

A physical connection point on the MOL Group information network at the closest possible location to the RIS Station computer.

An IP address (and settings) on the basis of the MAC address and machine name specified by vendor.

Availability of information technology specialists during the commissioning of the link and for assistance in the trouble-shooting of networking problems.

MOL Group’s RIS organisation will provide the RIS coupling/interface programs to be run by vendor on the RIS Station computer. MOL Group will bear responsibility for the licensing and functionality of said programs.

The specialists of the RIS organisation will carry out the configuration tasks related to the RIS database server and the user interface.

The specialists of the RIS organisation will be available during the commissioning of the link for assistance in the setting of communication and the recording of test data.

Vendor will maintain contact officially with the MOL Group organisations concerned through the representative of the organisation concluding the respective contract (investment).

4.2 Contents of Information to be Supplied for the RIS System

Vendor shall supply information to MOL Group about all the accessible points in the ICS system to be connected under the project for the preliminary selection of data to be recorded in the RIS database.

It is of primary importance to prepare software for control used in production accounting (material & energy balances) in compliance with the currently applicable standards and in agreement with the process unit concerned and RIS Development, respectively. Accounting programs and calculations shall be implemented in the ICS system, only compensated and totalised data shall be transmitted to the RIS system.

The information supplied (list) shall include for each control loop

Tagname,

Type,

Narrative description,

Measurement range,

Engineering unit (description of states for discrete points),

Accessible parameters (PV, SP, etc.) and their format.

The type of the calculation algorithm and the control loops used for correction (compensation, reconciliation) shall also be indicated separately in the case of points used for accounting purposes.

The above documentation shall be submitted in 2 printed copies and 2 copies on electronic media in a format suitable for further processing (as a database). If this information is issued as part of some other documentation, then the number of copies specified there shall govern, but the provision of an electronic database format is mandatory also in this case.

4.3 Contents of As-Built Documentation

As-built documentation shall be issued for the completed project with the following contents:

Technical description, system configuration and details.

Functional description, maintenance and operating instructions, hardware and software documentations.

Full back-up copy of all active elements in system in a format suitable for re-installation on 3 copies of electronic media.

The descriptive documentation shall be submitted in 2 printed copies and 2 copies on electronic media. If this information is issued as part of some other documentation, then the number of copies specified there shall govern.

SLOVNAFT a.s.

R&M Division


MOL Group


INSTRUMENTATION

6. Process Control System

8. Requirements related to the development of an on-line analytical diagnostic and maintenance network

MGS-S-REF-I-6.8

Rev 1.00.00




8 Requirements related to the development of an on-line analytical diagnostic and maintenance network

Page/Pages: 2/8


Release list


0.00.00 31.10.2008 Basic release GBereznai

0.00.01 01.10.2011 General review F. Nagy Z. Stanová

1.00.00 30.11.2011 General issue F. Nagy Z. Stanová


Rev 1.00.00 3/8

Contents Release list ................................................................................................................................................................... 2 Requirements related to the development of an on-line analytical diagnostic and maintenance network ................... 4 1 General .................................................................................................................................................................. 4

1.1 Deviations ..................................................................................................................................................... 4 2 The duty of the system .......................................................................................................................................... 4 3 Building blocks of the maintenance network ......................................................................................................... 4

3.1 On-line analysers: ......................................................................................................................................... 4 3.2 Sample preparation system: ......................................................................................................................... 4 3.3 IT devices of the network: ............................................................................................................................. 4

4 Software requirements for the system................................................................................................................... 5 4.1 Control capabilities ....................................................................................................................................... 5 4.2 Diagnostic and display functions: ................................................................................................................. 5 4.3 Analyzer specific diagnostic and display functions: ...................................................................................... 5 4.4 Man Machine Interface emulation ................................................................................................................ 6 4.5 Software handling ......................................................................................................................................... 6 4.6 Report functions ............................................................................................................................................ 6

5 Network safety ....................................................................................................................................................... 7 5.1 Password ...................................................................................................................................................... 7

6 Hardware requirements for the maintenance system ........................................................................................... 7 6.1 Requirements for the IT network .................................................................................................................. 7 6.2 Requirements related to the on-line analytical system ................................................................................. 7


4/8 Rev 1.00.00

REQUIREMENTS RELATED TO THE DEVELOPMENT OF AN ON-LINE ANALYTICAL DIAGNOSTIC AND MAINTENANCE NETWORK

1 General

This specification details the basic design requirements for the development of an on-line analytical diagnostic and maintenance network (hereinafter ’Maintenance Network). This specification does not include the diagnostics of analysers with the capability of HART and Fieldbus communication capability that belongs to the Field Instrumentation Maintenance System (FIMS).

1.1 Deviations

The project specification may contain deviations from, or changes in, these requirements. Any deviation from the content of this specification or from the project specification will be possible with a written approval thereof by the competent expert in the area at MOL Group only.

2 The duty of the system

The maintenance network will aim at acquiring detailed information from on-line analysers, at forecasting foreseeable failures of instruments by way of identifying status and diagnostic characteristics, at identifying incidental failures at an early stage in order to increase the safety of operation, to reduce downtime caused by failures, to allow, and to provide a unified, systemic framework, for remote maintenance, i.e. in summary, at keeping maintenance and operation costs at the optimal level.

The use of the maintenance network will enable us to gain detailed information on the current and previous status, failures as well as calibration and reference data, of analysers. We will be able to run maintenance and checking functions from a location far from the analyser concerned.

3 Building blocks of the maintenance network

Possible elements of the maintenance network and the requirements raised against them are listed below:-

3.1 On-line analysers:

Measuring instruments that serve for the continuous or quasi continuous measurement of the attributes and chemical compositions of technological parameters, typically based on quantitative analyses. In addition to the measurement values, such instruments will also be able to forward other information characterising their operation. Such other, mostly diagnostic information is characterised of a two-way traffic of the data. They will be able to receive information from the maintenance system, and to forward retrieved data to a higher level. They will be connected to the superior process control system via a 4-20mA ’current loop’ system or serial communication (Modbus, DataHiway, VistaNet). In case of 4-20mA signal transmission the pieces of diagnostic information will be accessible on independent serial outlets. The unit should to be installed in a well ventilated room without dust and at a stabile temperature (container with HVAC system).

3.2 Sample preparation system:

It connects the on-line analyser to the technological system. It ensures that sampling is representative and characteristic of the material flow to be analysed, including a ’fast loop’ that assures the minimal time delay in sampling. The sample preparation system carries out the pressure, temperature and flow control of the sample flow to be measured, and returns the measured material to the technological process or to the slop. Measuring instruments (rotameters, manometers, etc.) and control devices (reducers, pin valves, etc.) are fitted to certain points of the sample preparation system to assure optimal operation.

3.3 IT devices of the network:

Engineer’s workstation: a computer, connected to the Refining IT system, via which information supplied by the central server of the maintenance system are accessible.

On-line analytical maintenance server: a computer with resources accessible and usable by the other members of the network (clients). As for the layout of the server hardware, it will be a computer, composed of components of excellent quality, with high level of availability that provides outstanding safety from the viewpoint of data protection.

Star topology of the network: in this topology computers are connected to each other via one or more nodes where concentrators (hubs) or switches can be found. See Fig1.


Rev 1.00.00 5/8

Client-server type network: in such a network the server computers offer resources to clients, i.e. to the other members of the network.

Router: various networks with different protocols and network architectures can be linked together by using a router.

Gateway: a personal computer which a gateway program runs and interconnect two networks.

Firewall: an IT device or software solution that protects the network against external intrusions/ attacks.

4 Software requirements for the system

4.1 Control capabilities

The maintenance system shall enable:

Warnings and alarms from on-line analysers to be acknowledged and/ or cancelled;

An analysis cycle to be started or stopped;

The required material flow to be selected for analysis if various material flows are used;

A checking or calibration cycle of the on-line analysers to be started;

Manual force of the analogue and digital outputs.

4.2 Diagnostic and display functions:

The maintenance system shall enable:

Display the analogue and digital outputs of the on-line analyzers;

Display application data (measuring, sequence control etc.);

Display internal software configurations;

List absorbency data, photo offsets, photo spans;

Be capable of generating trends from measurement data and/ or from various analytical internal auxiliary parameters at any time.

4.3 Analyzer specific diagnostic and display functions:

FTIR specific functions:

download and display spectra;

FTIR analysers will enable the following diagnostic results to be achieved in using any spectra (zero, calibration verification, sample):

The intensity of the light passing through the measurement cell in taking zero spectrum;

Spectral balance and efficiency of modulation (ratio of the intensities of two spectrum segments);

Level of pollution of a measurement cell;

Detector linearity;

Detector saturation;

Signal to noise ratio of the detector;

Number of bad scanning;

Spectral position;

Model accuracy;

Chromatograph specific functions

Download and display chromatograms;

Display continuous chromatograms;

Display the following values:

Retention time;

Component concentration;

Summa concentration;

Gate or flag on,

Gate or flag off,

Time of valve switchover;


6/8 Rev 1.00.00

Setting event switchover times;

Uncorrected peak height;

Uncorrected peak area;

Corrected peak height;

Corrected peak area;

Peak slope;

Peak width;

Row detector mV output signal;

Injection time;

Cycle time;

Column oven temperature;

Injector valve temperature;

Carrier gas pressure;

If the above parameters exceed pre-set levels, a warning will be sent to us while the analyser will generate an alarm in case of a significant change in a diagnostic parameter. The warnings and alarms should be display in the maintenance system.

4.4 Man Machine Interface emulation

It is expected to support the inspection of the parameters and measuring values;

It is expected to running and holding of chromatographs within a network;

Enable ALARM to be displayed, acknowledged and cancelled;

Materials streams to be listed;

Enable detector signal to be monitored and continuous chromatograms to be displayed;

Support the display of measured concentrations (raw and corrected) and the chromatograph, stored in its own memory;

Enable calibration cycles to be started.

4.5 Software handling

The maintenance system should be support:

Download and upload function of the control tables and running software from the on-line analyzers to the server,

Editing and printing the downloaded software and control tables,

Verify memory (ROM, EPROM, EEPROM, etc.) checksum.

4.6 Report functions

Reporting events

The maintenance system should be able to use the following report functions:

Maintenance system event reports, these are contains the system alarm messages, network alarms, system access information (e.g. log-in, log-out, etc.).

On-line analyzers event reports, these are contains the analyzers alarms in the maintenance system,

On-line analyzers output values and diagnostic parameters.

The server of the maintenance system should collect the results measured with the analysers integrated in the system as well as auxiliary parameters belonging to such measurement results (See Diagnostic functions in section 4.2. and Display functions in section 4.3.) in one database. The time of collecting measurement data can be changed but the results can be inquired and retrieved at least for one week. The maintenance software should provide exportation of collected data into MS Excel format.

The measurement results continuously generated at on-line analysers within the maintenance system and the measurement results collected in the database in the server should be capable of being trended on the monitor of the engineer’s workstation. The applied trends can be scaled along axes X and Y as well as in time. The following trend-generating solutions shall be available:

Displaying measurement data and complementary parameters in chronology.


Rev 1.00.00 7/8

Displaying two measurement values or complementary parameters in XY format (e.g. component ’a’ as a function of component ’b’).

Displaying measurement results in the form of hystograms.

Trending of calibration values must be independent of measurement results.

Displaying of availability data

The maintenance system should allow availability data for each on-line analyser within a predefined time interval to be displayed in percentages and in durations. The mode of display should be graphic (e.g. pie chart) as well as tables. The maintenance system should automatically complete availability calculations in the following manner:

Appropriate measurements: Sum of durations when none was alarm active during either measurements or the measurement cycle.

Erroneous measurements: Sum of durations when at least one was alarm active during either measurements or the measurement cycle.

Calibrations: Sum of durations when the on-line analyser performed calibration.

Maintenance: Sum of durations when maintenance was done to the analyser.

5 Network safety

Network safety should cover the entire system, including hardware and software as well as all the stored information, realising smooth, continuous and stable running of the programs within the network. As a minimum the following four criteria shall be met in developing the network: -

1. exclusive: the system developed should make sure that no information is made known to any third party without the sender and recepient of such information knowing about it.

2. integrity: the system developed shall be protected against random, detrimental changes in the data.

3. identifiable: users may use network resources after a proper identification procedure only.

4. controlled: the system shall be developed in a manner that opportunity for unauthorised use can be prevented.

5.1 Password

The maintenance system shall allow at least the following three levels of password to be applied:

Normal access: the owner has authorisation to read on all the program functions of all the on-line analysers.

Key access: the owner has authorisation to read and modify on all the program functions of all the on-line analysers.

Administrator: the owner has authorisation to read and modify on all the program functions of all the on-line analysers, including modifications to user and password data.

6 Hardware requirements for the maintenance system

6.1 Requirements for the IT network

In setting up and developing the maintenance system, client-server type of IT system layout shall be used.

In setting up the maintenance system the standard IEEE 802.3 Ethernet network protocol shall be used. For the application of other protocols (e.g. IEEE 802.11 wireless protocol) the Customer’s written approval will be required.

In the hardware and software design of the maintenance system MOL Group IT policy and the relevant Regulations, Guidelines shall be taken into account.

6.2 Requirements related to the on-line analytical system

The maintenance system shall be set up in a manner that:

It is also capable of receiving status or condition signals (instrument failure, flow alarm, calibration, etc.) from on-line analysers (e.g. density meter, CP analyser, etc.) with lower level diagnostic capabilities.

It shall allow for the integration of the signals (flow, pressure, temperature, etc.) from the sample preparation units belonging to on-line analysers, into the maintenance system.

The maintenance system shall be capable of receiving the status signals from the ‘slop’ and re-circulation systems belonging to the analyser container.


8/8 Rev 1.00.00

It shall enable the safety signals (container door open, gas hazard, etc.) from analyser containers and cabinets to be transferred to the maintenance system, at least in the form of collected signals.

Monitoring the availability of utilities/ auxiliary energies shall be available in the maintenance system (e.g. checking the charge in gas bottles by way of contact manometers).

` `

`

Redundant Domain #1

Redundant Domain #2

Additional

analyzer #1

Analyzer #1 Analyzer #2



Additional

analyzer #2

SwitchRouter #1 Router #2

Gateway

Analyzer Maintenance Network

Refinery Information Network

On-line analyzer

maintenance

server

Router #3

Firewall

Analyzer

engineering

workstation #1

Analyzer

engineering

workstation #2

RS-485 HUB

Sample conditioner #4Sample conditioner #2Fire alarm /

protection system

Analyzer

house

Fig. 1.: Block diagram of an integrated on-line analyser maintenance system

SLOVNAFT a.s.

R&M Division


MOL Group


6. Process Control System 9. Alarm System and HMI display design and impleme ntation

MGS-S-REF-I-6.9

Rev 1.01.00




9 Alarm System and HMI display design and implementation Page/Pages: 2/32


Release list


1.00.00 30.11.2011 General issue Á.Pozsgai L.Pallagi 1.01.00 29.02.2016 Revision Z. Stanová R. Kopálek Head of

Maintenance


Rev 1.01.00 3/32

Contents 1 Overview ........................................................................................................................................... 4

2 Deviations:......................................................................................................................................... 4

3 References for Alarm Philosophy ...................................................................................................... 4

4 General requirements ........................................................................................................................ 4

4.1 Alarm System purpose ................................................................................................................ 4

5 Alarm design principles ..................................................................................................................... 5

6 Alarm identification methods .............................................................................................................. 5

7 Alarm rationalization .......................................................................................................................... 6

7.1 Requirements for alarm rationalization ........................................................................................ 6

7.2 Alarm rationalization techniques .................................................................................................. 7

7.3 Requirements for Master Alarm Database ................................................................................. 11

7.4 Alarm classification .................................................................................................................... 11

7.5 Alarm type determination ........................................................................................................... 13

7.6 Alarm prioritization ..................................................................................................................... 13

7.7 System and diagnostic alarm/alert ............................................................................................. 15

7.8 Alarm limits (setpoint) determination .......................................................................................... 17

8 Alarm Design ................................................................................................................................... 17

8.1 Considerations for basic alarm design: ...................................................................................... 17

8.2 Advanced alarm design ............................................................................................................. 19

8.3 Reliability requirements for alarms ............................................................................................. 20

9 HMI display...................................................................................................................................... 21

9.1 General HMI requirements ........................................................................................................ 21

9.2 Alarm indication ......................................................................................................................... 22

9.3 Alarm sound annunciation ......................................................................................................... 24

10 Testing of Alarm System ........................................................................................................... 24

11 Alarm System handling (operation) ............................................................................................ 24

11.1 Alarm suppression requirements ........................................................................................... 24

11.2 Alarm response ..................................................................................................................... 26

12 Alarm System performance monitoring ...................................................................................... 27

13 Alarm System maintenance ....................................................................................................... 28

14 Management of change ............................................................................................................. 28

15 Recommended practice, examples ............................................................................................ 29

15.1 Logical Alarm suppression for typical BMS application .......................................................... 29

15.2 Recommended HMI graphic display ...................................................................................... 32


4/32 Rev 1.01.00

Alarm System and HMI display design and implementat ion

1 Overview This specification addresses the design and implementation of Alarm Systems and HMI displays in the MOL Group Refineries. This Technical Specification does not substitute the using of Alarm Philosophy.

This document is intended to provide a recommended practice and guide in the design, implementation, operation and maintenance of an Alarm System in the Integrated Control System (ICS).

This specification takes a lifecycle approach toward alarm management in order to define work processes to effectively maintain the Alarm System over a life cycle.

This document is not intended to be a step by step set of instructions on how to build up an Alarm System in the Integrated Control System.

2 Deviations: The applicable Project Specification may contain deviations from or changes to this document.

Deviations from the contents of this specification and the Project Specification shall be permissible only on the basis of prior written approval by MOL Group.


3 References for Alarm Philosophy • EN 62682: 2015 Management of Alarm Systems for the Process Industries

• API RP 1167 Pipeline Alarm Management

• NAMUR NA 102 Alarm Management

• EEMUA 191 Engineering Equipment and Materials Users Association (EEMUA) publication No. 191

• EN 61508-1..7:2010 Functional safety of electrical/electronic/programmable electronic safety-related systems


4 General requirements

4.1 Alarm System purpose The primary function of the Alarm System is to warn the operator about a situation that is not normal. Each alarm should alert, inform and guide the operator.

Individual Alarms shall: • Be timely – presented at the right time. (It comes up neither long before intervention is necessary nor too

late for action to be taken)

• Be adequate time for the operator to carry out a defined response

• Be relevant – for the operators, not a false alarm.

• Be unique – not a duplicate of another alarm.

• Be prioritized – helps the operators to focus their attention. (It indicates the urgency of the problem requiring operator action)

• Be understandable – speaks the operator’s language. (It contains a clear message that is easily understood)

• Be diagnostic – indicates what has happened (it helps with the identification of the problem)

• Be advisory – what actions are needed. (It helps to find the correct action)

• Be focusing - it directs attention to the most important aspects

• Be manageable – not too many alarms.


Rev 1.01.00 5/32

5 Alarm design principles Characteristics of effective Alarm System

The following characteristics are desirable for an effective Alarm System: • Alarms occur only on events that require operator action, so each alarm should require operator action

• Alarm system shall provides the right information to the right people at the right time

• Each alarm should be clear, meaningful, and relevant to the tasks of the operator

• Alarms shall be properly chosen, designed, and implemented

• Each alarm should be documented and have a defined response; a single process event should not produce multiple alarms signifying essentially the same thing

• Alarms should not activate during routine process variable changes, or from normal, expected modes of operation that do not require additional operator action. Alarms occur in time for effective action to be taken

• Alarms should be designed to give the operator appropriate time to respond to the alarmed situation

• Alarms are configured consistently

• Alarm rates should be within the handling capability of the operator

• Alarms should be prioritized in a manner that indicates their importance

• The Alarm System should perform as a useful tool for the operator in all operating modes and upset conditions;

• Alarm Systems should be properly managed (controlled, monitored, and maintained).

6 Alarm identification methods Objectives of alarm identifications are to determine potential alarm in order to create a basic alarm list which will be the source of Master Alarm Database.

If an Alarm System exists then the determined potential alarm list should be supplemented and merged with the existing alarm list received from active Alarm System of BPCS.

The alarm identification phase of the alarm lifecycle should include the following activities with the involved necessary documents:

• P&ID reviews

• Process hazard analysis (PHA) or existing PHA reviews

• Layer of protection analysis (alarm as safeguard with credit)

• Environmental permits that identify potential alarms

• Recommendations from an incident investigation

• Good engineering or production practice

• Operating procedure reviews

• Product quality reviews

• Data supplies from plant and equipment manufactures

• Equipment mal-operation based on good manufacturing practice

• Protection of equipment

• Safety Instrumented System reviews;

• Protections are being used to reduce the demand on safety systems;

• Major equipment shutdown causing further effects on plant systems.

• Utility system failure, power supply failures, fuses, earth fault detectors, fans etc.

• Integration of multiple alarm systems (e.g. Alarm System of subsystems)

• Routine Monitoring of existing Alarm System performance

Decide what should not be alarmed:

• Normal process condition

• Alerts or events that do not require operator response

• If operator response (action) can not be defined

• Status changes for information


6/32 Rev 1.01.00

• Events too fast to respond to

• Control system signals indicating successful action

• Items that are already alarmed directly or indirectly (alarmed elsewhere)

7 Alarm rationalization

7.1 Requirements for alarm rationalization Objective: Alarm rationalization should be a proven alarm management technique that reduces alarm load on the operator, eliminates nuisance / redundant / false alarms, and improves operator response.

Further aim is to create a minimum set of alarms needed keep the plant safe and within normal operating limits.

7.1.1 Considerations for alarm rationalization

• Each alarm shall be rationalized including all categories of alarms coming to an operator, including system alarms and diagnostic alarms as well.

• Alarm rationalization procedure for all alarms shall be carried out prior to design and implementation.

• The alarm rationalization shall be carried out by a multidisciplinary team (with Licensor and/or technologist)

• The output of the rationalization shall be recorded in a Master Alarm Database (MADB) and shall be issued in a report for checking and for approval.

• The issued report of rationalized Alarm System shall be approved by Licensor of new process plant or Technologist of existing process plan to ensure the compliance with the P&ID’s and the requirements of safety operation.

• It is not allowed to delete any alarm that is there as a result of a prior HAZOP effort. The MoC policy shall be followed in changing such alarm and prior approval is required by HAZOP team.

• It is not allowed to delete any alarm indicated on P&ID unless it has been rationalized and approved by Licensor and/or Technologist.

7.1.2 Required documentation and information for al arm rationalization

• Piping & instrumentation diagrams (P&ID)/material flow sheets

• PHA/HAZOP/LOPA reports

• Interlocks/cause-effect diagrams

• Critical operating procedures

• Complex loop documentation

• Safe operating limits

• Operating graphics (on-line or hardcopy if exists)

• Alarm history analyses (for existing Alarm System)

• Access to process history analysis (option)

7.1.3 General requirements for alarm rationalizatio n The alarm rationalization shall include the following activities:

• The alarm rationalization shall be based on a reviewing procedure of all alarms that may exist or configured alarms or possible potential alarms.

• To check alarm validity and verify whether the existing or potential alarms fulfill the criteria described in the Alarm Philosophy, such as:

o The alarm indicates a malfunction, deviation, or abnormal situation,

o The alarm represents a situation requiring timely operator action in order to avoid defined consequences

o The alarm is the best indicator of the root cause of the abnormal situation (i.e., multiple alarms from the same condition should be avoided.)

• When the alarm validity check indicates an existing alarm is not needed, the rationale for deletion shall be documented.

• To determine the following that alarms have been validated:

o The cause of abnormal process condition(s) initials a alarm


Rev 1.01.00 7/32

o The allowable response time which is necessary for operator takes corrective action to avoid the consequence

o Responsibilities of corrective action (operator, site maintenance, system maintenance etc.)

o The corrective action is to be taken in response to the alarm

o The consequence and its severity if that corrective action is not taken. These are generally in the areas of personal safety, environmental, and business cost (efficiency, reliability, production and quality loss, etc.)

• To define alarm attributes as well as alarm type, class (category), priority, limits, tuning parameters according to site Alarm Philosophy. To ensure consistency in alarm attributes.

• To ensure that the resulting alarm parameters are correctly specified by optimization and validation of alarm parameters.

• Highly Managed Alarm group (related to one or more alarm class) shall be defined which are critical to process safety (the protection of human life and environment).

• The Highly Managed Alarms shall have more rigorous documentation of requirements like Safety Requirements Specification according to EN 61508/61511.

7.2 Alarm rationalization techniques The alarm rationalization activity should include the techniques required to reduce number of alarms as follows:

• Alarm review

• Alarm System analyses (for existing Alarm System).

• Multi-level alarms elimination (eclipsing)

• Alarm grouping

• Multiple (redundant or duplicate) alarm elimination

• Logical alarm suppression

• State-Based Alarming

• Nuisance “Bad Value” alarm elimination

7.2.1 Alarm review

• Alarm review shall be carried out by a system by system and tag by tag basis in order to eliminate alarms which are not necessary.

• The events that are useful only inform the operators and not involving any actions, they should be presented in a variety of ways other than the use of the Alarm System. Events that do not require operator action shall not be allowed to generate alarms. (Avoid the “That is nice to know” approach.) The alarm indications from plant status indications shall be separated.

• Verify that an alarm does not duplicate another similar alarm that occurs under the same conditions. If so, keep the one that best indicates the root cause of the abnormal conditions.

• Alarm should not be generated during normal, excepted operation and routine process variable changes.

• Verify that any configured alarm should exist at all. Alarms should not be used for primarily status indication (note: do not alarm things that are “OFF”. Alarm them only when they are “OFF” but are supposed to be ON. For example:

o An alarm should be generated only when the pump is not running when it is supposed to be running.)

o Alarms should not be generated if the valve moves to the position that it is supposed to move to.

o When the interlock activates, an alarm should occur only on the final element that does not carry out the required safety operation. (The close position of safety DBB valve in the BMS system should not be an alarm, only when the safety DBB valve does not close when it is supposed to close. (Close Command Disagree alarm).

• To take recommendations for installation of automatic control in BPCS or Safety Instrumented Function in SIS to reduce the demands of operator’s responses due to alarms.

• Alarm review in order to find alarms from out of service plant for temporary suppression.

• Alarm review in order to find alarms for decommissioning from long term stopped plant after they have been rationalized and approved according to MOC procedure of Alarm Philosophy.


8/32 Rev 1.01.00

7.2.2 Alarm System analyses (for existing alarm sys tem)

• The Alarm System analyses shall be based on dynamic alarm events data coming from the real Alarm System and not the underlying configuration of Alarm System’s components.

• The existing Alarm system shall be analyzed by Alarm System Analysis program to discover weaknesses and prior to improve it by eliminating the nuisance alarms (chattering, stale and duplicate alarms)

• To find that modules which have configured alarm, but that have not generated even a single alarm in the last 12 months for further rationalization, because they might be unnecessary.

• The most frequent alarms should be found to create a list which contains several chattering alarms that should be subject to further alarm rationalization.

• The stale alarms (long standing) that are in the alarmed state continuously for more than 24 hours should be found for elimination, because most of the stale alarms are not indicating a truly abnormal situation.

• The duplicate alarms that persistently occur within a short time period (within 1-5 seconds) of other alarms should be determined for elimination, because such alarms are highly likely to be multiple annunciation, in different ways, of the same process event in an undesirable situation.

7.2.3 Multi-level alarms elimination (eclipsing) Sometimes there will be several alarms generated from a single process variable (multi-level alarm: e.g. pre-alarm and alarm: high, hihi or low, lolo) that elimination is highly recommended.

• It is allowed to use algorithms (program or logic) to suppress the alarms of lower operational significance when the more significant alarms are set in order to reduce the parallel alarming.

• The multiple alarm level should be avoided to reduce the alarm traffic unless:

o they indicate different abnormal conditions

o they require significantly different operator actions

o follow-up time is enough for additional operator action

7.2.4 Alarm grouping

• It is allowed to use a single grouped alarm to display a number of different initiating events from a sub-unit (e.g. package) system that have common operators’ responses.

• The alarm grouping strategy should provide a procedure (root cause diagnostic capabilities) by allowing users to see more detailed information about the grouped individual alarm status in order to examine the sequence of events leading up to an abnormal situation.

• A proper diagnostic graphic HMI display shall be built to show the status of all of the initiators of the single grouped alarm.

• The re-acceptance and refresh shall be provided when a second initiating event comes up when the single grouped alarm is already standing.

• The single grouped alarm response shall be determined during alarm rationalization

• Each package or skid vendor shall be requested to supply a common system alarm and a common trip alarm.

• The alarm groups should be defined for machines like: compressors (air/process gas, radial/axial, centrifugal/positive displacement), turbo expanders, industrial gas and steam turbines in power generation, electric motors and generators, gear boxes, pumps (centrifugal and positive displacement), fans, air blowers, reciprocating compressors. The machine’s single grouped alarm should be based on alarms of machinery protection system (e.g. Bentley-Nevada)

• The following alarms should be grouped related to machines:

o Common vibration alarm for the entire machine

o Common bearing temperature alarm for the entire machine

o Common displacement alarm for the entire machine

o Common lubrication alarm for the entire machine

o Common machine alarm for smaller equipment that have just a few machine protection measures.

• The alarm grouping should be taken into account for e.g.:

o reactor with many zone temperature alarm

o multiple machine protection alarm (e.g. vibration alarm, bearing of machine temperature alarm, displacement alarm etc.)


Rev 1.01.00 9/32

o heater with more combustion chamber temperature

• Redundant pumps should have a common alarm (considered: It is normal for the ‘backup’ to be off, both running is usually incorrect except during switchover or test, both can be off during maintenance)

7.2.5 Multiple (redundant or duplicate) alarm elimi nation

• The Alarm System shall not generate more alarms than what the operator can response to.

• Each alarm should be independent in regard to one scenario of abnormal situation.

• Multiple alarms result from same process deviation should be avoided.

• Additional alarms should never be created solely upon the assumption that the operator will fail to respond to a different alarm.

• If there are duplicate or similar analog measurements input to both the BPCS (for control purpose) and the SIS (for safety trip purpose), multiple alarms from both source for same process conditions are not allowed

• Redundant equipment with instrumentation which generates multiple alarms from the same common cause and have a similar operator response should be grouped to common alarm.

• Interconnections between modules and functional blocks can cause duplicate alarms (e.g. due to Bad Value, BadPV) that should be eliminated by careful configuration. There should only be one such alarm configured, on the module where the operator is most likely to take the action (e.g. the PID controller functional block should be involved instead of AI function block).

7.2.6 Logical alarm suppression

• The alarms are to be assigned for Logical Alarm Suppression and conditions of suppression shall be determined and documented during alarm rationalization and shall be approved.

• Logical Alarm Suppression modes shall be applied with special care to avoid the possibility of an alarm being unintentionally suppressed or left suppressed.

• Logical Alarm Suppression which is based on logic in the controller that suppresses (masks) alarms based on detected process conditions (e.g. pump not running – do not alarm on low flow, pump starting – do not alarm on high current)

• The tripped state of equipment (e.g. compressor, pump etc.) shall be detected in order to suppress the expected alarms (e.g. for compressor trip: low discharge pressure, low flow, low amps, low speed etc.) At the post-shutdown state (“Low Energy State”), the important alarms are required to adjust the remaining process that shall be active.

• Alarms for standard pumps: Redundant pumps should have a common alarm based on on/off status of primary and backup pumps, configurable number of desired pumps (one during normal operation, zero during maintenance), the number of running pumps with delay to handle switchover and test.

• The follow-up alarms of desirable out of service condition should be suppressed. An example of a condition requiring out-of-service suppression would be low-flow monitoring on a pump (or a set of pumps).

7.2.7 State-Based Alarming

• State-based alarming, wherein alarm settings, attributes are modified based on the operating state of the plant or a piece of equipment, because certain alarms are only relevant in particular plant operating state.

• The State-Based Alarming solution should contain a state detector (including operator confirmation), tables with alarm parameters and settings for detected state and change enforcer to implement alarm settings.

• The operational state shall be identified with their process conditions. A few common state examples include:

o Running

o Not running

o Startup

For compressor (example):

o Startup

o Pre-lube

o Steady state

o Post-lube

o Shutdown

For BMS (see: Recommended practice, examples)


10/32 Rev 1.01.00

o Permission to start

o Pre-purge

o Ignition of pilots

o Ignition of main burner

o Normal operation (low temp)

o Normal operation (high temp)

o Shutdown

• Multiple process states (e.g. shutdown, startup, idle, steady sate, upset or special production mode for special product, firing mode etc.) and their alarm settings with the adjustability criteria, conditions and allowable ranges shall be documented during alarm rationalization.

• Operating or process states can be determined by:

o Defined process variable which reaches a specific limit

o Status of a discrete variable

o Status of logical variable created by program or logic

o On-demand operator selection

• Actual process state should be tracked for proper alarming settings, attributes and operator guidance.

• The download mode of new set of alarm settings should be one of the manual (on-demand by the operator), fully-automated (logic, program) or semi-automated (e.g. some combination of manual and automated) modes.

• There shall be an operator confirmation procedure prior to activate the change enforcer (implements new alarm settings based on the detected state) to gain confidence.

• Obviously the operator shall be informed that the State–Based alarm system has failed.

• If there is no predefined operational or process mode, it sets to the default alarm settings that shall be automatically selected which are determined during the alarm rationalization. In that case the default alarm setting shall be the most conservative alarm setting (worst case settings).

• The all of state, mode, operator’s action and changing of state based alarming shall be logged in the BPCS system.

• The “Shutdown State” should be determined as “Low Energy State” which has alarms, but set to activate at much lower limits to maintain the plant safety while “Shutdown State” is active.

• In the BMS application, the “Low Energy State” is the shutdown state of the furnace (no flame and all of safety DBB valves have been closed). During the “Low Energy State” of furnace the safety conditions shall be ensured by alarming the hazardous situations (by Flame alarm (light), high temperature alarm of flue gas) like internal fire in the chamber due to tube break.

7.2.8 Nuisance “Bad Value” alarm elimination and ha ndling

• Bad Value is due to instrument problems or process problems which shall be solved by engineering efforts (e.g. alarm rationalization, re-design, changing in alarm configuration) and maintenance activities.

• The control system sets the status of the measured value (Process Variable: PV) to Bad Value (BadPV) if any of the following conditions are true:

o If a value cannot be measured or calculated, data value cannot be obtained

o If device diagnostics have identified a failure (e.g., broken I/O, open TC, over-range, under-range etc.).

• Inappropriate handling of the variables at the ends of the range and over-aggressive bad value prioritization can cause needless alarms, chattering alarms in alarm flood situations when plan is upset.

• The individual Bad Value alarm should not be missed, if status of the measured value goes bad on a critical alarm variable like a sensor of SIS, sensor that feeds a Highest or Critical priority alarm.

• The following Bad Value handling consideration shall be taken to reduce the time that operator spend confirming the instrumentation problems::

o To avoid over-aggressive bad value prioritization (see: Diagnostic alarm and alert consideration)

o Adjusting alarm limits, filter settings and deadbands (see: Recommended default settings for alarms)

o Re-engineering the sensors and transmitters by setting new measuring ranges to avoid Bad Value alarm.


Rev 1.01.00 11/32

o To discover the waving control loops that may cause chattering alarms. The re-tuning of control loops is required to smooth process variables.

o To reconfigure BPCS system to use the internal ability to “clamp” an analog value at the end of the range rather than go into a Bad Value state. (it may be used with extreme care)

o The status of measured process variable (PV) is being propagated through control schemes (through modules and Function Blocks) should be alarmed at one place.

o It is allowed to use a single grouped BAD Value alarm to display a number of fail status of sensors and transmitters that have common maintenance response and related to Lowest and Middle priority alarms.

o Detail graphic display shall be provided to show the status of sensors and transmitters are being involved.

7.3 Requirements for Master Alarm Database

• The Master Alarm Database shall comply with ISA 18.2 requirements.

• The Master Alarm Database should contain the following:

o Basic alarm data (tag, tag description, scale (low/high with engineering unit), process area, unit)

o Alarm condition (causes)

o Consequence of inaction

o Allowable response time

o Operator’s corrective action (required response),

o Alarm attributes (type, class (category), priority)

o Alarm limits (setpoint/trip-point)

o Reference (P&ID, PHA/HAZOP)

o Alarm status (e.g. incomplete, under review, approved, configured, deleted)

• The Master Alarm Database should have the followings capability:

o Import of the basic alarm data from BPCS (DCS, SCADA) system

o Should support to export the alarm configuration data to BPCS (DCS, SCADA) system in exception built or bulk edit format (or in MS-Excel)

o Alarm settings should be copied, pasted or imported and enforced from the MADB directly into the BPCS system configuration to prevent configuration errors with full tracking of operation.

o Support the enforcing of alarm parameters in BPCS system (this activity overwrite alarm parameter on the BPCS system when these are found to differ from the values stored in the MADB). The tracking of enforcement is required.

o Compare and update the existing MADB by imported basic alarm data from BPCS

o MADB should provide tools for alarm prioritization, setpoint determination etc.

o Provide a spreadsheet style engineering tool can help editing attributes for multiple alarms simultaneously.

o If the BPCS system configuration supports the addition of user-defined fields or alarm attributes, the MADB shall be capable to fulfill the role of it.

o MADB should support to make a history logging about the all changes to MADB. The all changes in the MADB shall be logged.

o Support the MOC procedure related to Alarm System

o Provide online operator help on BPCS system

o Shall have report function

7.4 Alarm classification Alarms shall be assigned to one or more classes (category) as defined in the site Alarm Philosophy.

The alarm classification is a method for organizing alarms by common characteristics and requirements. It is typically used to group alarms together which have similar requirements for handling, testing, training, audit frequency, and management of change.

The following alarm classes (categories) should be taken into account during alarm rationalization (example):

• Safety Critical Alarm (Highly managed alarm)

• Process Critical Alarm (Highly managed alarm)


12/32 Rev 1.01.00

• Process Alarm

• System Alarm

• Device Alarm

• Asset alarm

Characteristics of alarm classes:

7.4.1 Safety Critical Alarm

• Safety critical alarms shall be distinguishable from other operational alarms.

• The alarm state of all critical alarms should be always visible.

• It is claimed as part of the facilities for reducing the risk from hazards to people to a tolerable level.

• Alarms in this category require immediate attention because an event has occurred that affects either plant operational safety or public safety. (e.g. fire alarms, combustible-gas monitor alarms, toxic gas monitor alarms, leak detection alarm, and alarms identified by PHA/HAZOP analysis with consequence affecting the health and safety of people (Personal risk matrix category D: fatality or group accident, E: multiple fatality).

• The aim is to reduce demand on SIS’s.

• The Safety Critical Alarm shall have the highest (or critical) alarm priority.

• Alarms that have been rationalized to class Safety Critical shall not be operator and supervisor adjustable and shall be a Highly Managed Alarm.

7.4.2 Process Critical Alarm (Highly Managed Alarm)

• This category is for alarms that require immediate attention because an event has occurred that might either result or has resulted in a product-supply interruption, environmental violation or safety risk other than Safety Critical Alarm.

• SIS alarms and process alarms are related to safety consequences and have been taken to consideration as risk reduction protection layer.

• The aim is to reduce demand on SIS’s.

• The Process Safety Alarm should have a middle alarm priority.

• Alarms that have been rationalized to class Process Critical shall not be operator and supervisor adjustable and shall be a Highly Managed Alarm.

7.4.3 Process Alarm

• Process-Advisory alarms provide an early indication of an abnormal occurrence that does not cause Safety Critical and Process Safety alarms

7.4.4 System Alarm

• The System Alarms are related to BPCS system: DCS, PLC+SCADA and connected subsystems which detect the abnormal state of system.

• Hardware alarm for equipments are to be connected to BPCS (PS/UPS alarm)

• Diagnostic alarm related to BPCS

• Maintenance alarm related to all plant maintenance activities with systems, which includes: analyzer is under calibration alarm, equipment is out of service alarm

• Important part of system alarm should be Highly Managed Alarm which effects the BPCS desirable operation (PS/UPS alarm)

7.4.5 SIS Alarm

• The System Alarms are related to SIS system (ESD system, Safety PLC)

• Hardware alarm for equipments are to be connected to SIS (PS/UPS alarm)

• Diagnostic alarm related to SIS

• Maintenance alarm related to all plant maintenance activities with systems, which includes: MOS alarm, discrepancy alarm, proof test alarm, equipment is out of service alarm

• Important part of system alarm shall be Highly Managed Alarm which effects the SIS desirable operation (PS/UPS alarm)


Rev 1.01.00 13/32

7.4.6 Device Alarm

• Field Instrument Alarms are related to HART and Foundation Fieldbus devices connected to ICS system which detect and report specific device alert (such as hardware failures within the device, loop problems, and misconfigured parameters) conditions directly to the ICS system.

7.4.7 Asset alarm

• Asset alarms are generated by external, mechanical assets such as compressor, turbines, engines, pumps, and motors.

7.5 Alarm type determination Define the basic functionality needed to detect disturbance in the process. The alarm classification by type is for sorting and auditing the design or implementation of the Alarm System. The alarm type should be the follows (based on the supplied ICS system):

• Absolute alarm: Alarms triggered by comparison of a process value to a defined limit or state (LL or 2L, L, H, HH or 2H, option: 3L, 3H)

• Rate of change alarms: Alarms triggered by comparison of the calculated rate of change of the process to a defined limit (RL, RH).

• Deviation alarms: Alarms triggered by comparison of the calculated deviation of two process related values (DL, DH)

• Deviation Status alarm: Alarm triggered by a deviation from standard that exceeds a set tolerance

• Control alarms: Alarms triggered by the failure of the control strategy (e.g. bad field connection, windup protection alarm etc.)

• Process Control system (BPCS, SIS) status alarms: Most control systems have a series of alarms related to the status of the control system itself and field bus connected device status alarm.

• Advanced alarms: There is a wide variety of advanced alarms possible (e.g first-out alarming, state based or conditional alarming, dynamic prioritization)

7.6 Alarm prioritization Alarm priority is determined by analyzing what the direct consequences would be if no action was taken by the operator and based on how much time the operator has to respond.

The ICS system shall be able to sound and visualize presentations of alarm information by priority and shall provide tools for sorting alarms and suppressing audible annunciation by priority.

7.6.1 Considerations for alarm prioritization

• Each alarm shall have independent and individual priority.

• Alarm priority should be carefully defined because it is used to distinguish the order of response to alarms

• Every Highest and Critical priority alarm requires immediate (< 5 min) or rapid (5 – 15 min) action.

• Alarm where operator action is the primary method by which harm to a person is avoided shall be configured at the highest priority

• Every trip alarm of SIS should have a pre-trip alarm set to Middle priority, if there is adequate time and manner for the operator to take effective action in response to pre-trip alarm to avoid the undesirable trip.

• The alarms identified in the HAZOP/LOPA/SIL procedure and have a credit to reduce the risk should not automatically be assigned the Highest possible priority. They alarms should be rationalized in the same manner as every other alarm and may well come out as Lowest priority.

• It is inappropriate to sound an alarm for which no action is required for more than 60 minutes.

• A well-tested and proven approach to priority selection involves some combination of:

o The severity of the consequence that will occur if the alarm receives no operator response

o The time available for the operator to make a correct response before the consequence becomes unavoidable.

o The number of alarm priority level should not be more than four. An additional priority level for critical alarms is allowed to be used.

o Alarms that have been rationalized to priority Highest or Critical generally shall not be operator adjustable and shall be a Highly Managed Alarm.

Table 1.: Defined alarm priorities:


14/32 Rev 1.01.00

Priority Level Description Prioritize proportio-

nately

Maximum rate (* see note)

Critical** (optional)

Requires immediate operator attention. Condition has moderate to severe consequence potential.

<1 % Very infrequent

Highest (emergency /urgent)

Requires immediate operator attention. Condition has moderate to severe consequence potential.

5 % Infrequent

Middle (high/warning/ medium)

Requires rapid operator attention. Condition has moderate consequence potential, could escalate to higher priority condition.

15 % < 10 per shift

Lowest (low/advisory)

Requires prompt operator attention. Condition has low to moderate consequence potential.

80 % < 6 per hour (see note)

Not Audible (log/journal)

Not audible priority to designate an event that is important enough to be recorded

Indifferent

No Action Alarm not required Note: * Alarm rate targets: the long-term average alarm rate during normal operation should be no more than one every ten minutes; and no more than ten displayed in the first ten minutes following a major plant upset (page 37, EEMUA 191 guide).

** If the optional Critical priority level is to be used, specific additional criteria should be developed to determine which alarms should have that priority. The critical alarm priority should be used for Safety Related Alarms and alarms related to significant environmental or economic risks. These alarms are generally Highly Managed Alarm.

The percentages shown do not include the priority attributes of diagnostic-type alarms (such as bad value, out-of-range, and similar instrument malfunction alarms) and the system alarms.

7.6.2 Severity of consequences Severity of consequences is a potential consequences related to action that is not taken to correct the alarm process condition.

Table 2: Severity of consequence

Severity

Consequence

Personal Business Environment

A Slight injury Minor loss (loss: 1–10E3 EUR)

Minor effect

B Major injury Major loss (loss: 10E3-100E3 EUR)

Major effect

C Severe injury Severe loss (loss: 100E3-1E6 EUR)

Severe (local) effect

D Fatality or more several injuries

Very severe loss (loss: 1E6-10E6 EUR)

Very severe effect

E Multiple fatality Catastrophic loss (loss: > 10E6 EUR)

Catastrophic effect

Note: During the alarm rationalization to determine the consequences if no action was taken by operator, it will be assumed that all protective systems or safeguards (e.g. SIS, pressure relief devices, other independent protection layer) are active and fully functional. If those protective systems or safeguards are needed, it will be assumed that their design, reliability and operation are proper. It is inappropriate to assume multiple cascading failures occurred concerning with an alarm consequence scenario.

7.6.3 Time Available from Alarm to Process Correcti on The time required to respond to the alarmed process condition shall be a key consideration setting the alarm priority (the time includes the, sensor delay, ICS delay, time for operator’s alarm identifications, operator’s response time with correction action, process to respond to corrective actions).


Rev 1.01.00 15/32

Table 3: Alarm urgency

Urgency Definition

Immediate Requires immediate operator attention. Available time: 0-5 minutes.

Rapid Requires rapid operator attention. Available time: 5-15 minutes.

Prompt Requires prompt operator attention. Available time: 15-30 minutes.

Slow Requires slow operator attention. Available time: 30-60 minutes.

Indifferent Requires indifferent operator attention. Available time: >60 minutes.

Note: The urgency is proportional with the maximum time available for response and correction action. The maximum time available for response and correction action is how much time is available to take the effective action from when the alarm sounds to when the consequence becomes unavoidable, regardless of the action.

7.6.4 Alarm prioritization rules Additionally, the alarm prioritization design should be aligned with site risk management/risk assessment philosophies.

Table 4: Alarm priority

Severity of Consequence

Time required to response

Indifferent Slow Prompt Rapid Immediate

>60 min 30-60 min 15-30 min 5-15 min 0-5 min

A

Re-engineer the Alarm for

urgency

No Alarm No Alarm No Alarm Lowest

B No Alarm No Alarm Lowest Lowest

C No Alarm Lowest Lowest Middle

D Lowest Lowest Middle Highest

E Lowest Middle Highest Highest/Critical

7.7 System and diagnostic alarm/alert The system and diagnostic alarm generated by the Integrated Control System (ICS: BPCS, SIS, Devices: FFB, PB-DP, PB-PA, HART field devices) to indicate a fault within the system hardware, software or components.

System and diagnostic alarm and alert consideration:

• System and diagnostic alarms, alerts, diagnostic information and notification shall be segregated from annunciated process alarms.

• Additional special-purpose priorities may be useful, such as a lowest priority for system and diagnostic alarms (instrument malfunction) with very limited and prescribed operator action.

• Those system or diagnostic alarms for which the operator’s primary response is simply to relay the information to the appropriate person or group for action (e.g., instrument diagnostic alarms) should be reviewed to determine if an alternate method exists to transfer the information without burdening the operator or the alarm system.

• If the ICS system has sophisticated system or diagnostic alarm which may not be relevant to the Operators’ task and have no possible Operator response, such diagnostic alarm should be routed directly routed to the maintenance staff, rather than annunciating them to the Operators.

• Independent of the BPCS safety system alarm shall be provided for system diagnostic alarms from the SIS that indicate dangerous faults if a specific operator’s action (opening or closing a valve) is required. The system diagnostic alarm of SIS may be a part of the BPCS if only an operator notifying maintenance is required to repair a faulty part of SIS system in response to diagnostic alarm and the SIS can tolerate this single hardware fault.

• If a sensor or transmitter goes bad on a highest/critical alarm variable, the “bad value” alarm should not be missed.


16/32 Rev 1.01.00

• Basically the Bad Value alarms should be Lowest priority (being consistent with a likely response time exceeding 30 min). But the Bad Value alarm should be configured to Middle priority if it is on a sensor that feed a Highest or Critical priority alarm.

• All field device alarms and alerts shall be categorized as the internal diagnosis resulting into the following categories:

o Failure: The device provides a non-valid output signal due to some malfunction at the device level (sensor/actuator element failure, electronic failure, configuration problems, process induced failure)

o Check function: The device is temporary non-valid due to some activities, maintenance activities on the device (e.g. change of configuration, local operation,)

o Off-specification: The Device being operated out of the specified measurement range. Uncertain value due to process and environment influence.

o Maintenance required: Although the device is still able to provide a valid output signal, the device is about to loose some of its functionality or capability due to some external operation conditions. The maintenance can be needed short-term or mid-term.

• Because of the operator’s limitation to response system and diagnostic alarm or to solve the problems the diagnostic alarm shall be categorized based on the following urgency criteria:

o Immediate action : To ensure immediate contact or callout of resources to solve the problem, regardless of the time of day or night.

o Non-urgent action: To write a routine maintenance repair request, typically by the end of a shift and optionally shelve the alarm.

• Device alarm/alert shall be prioritized as shown in following table:

Table 5: Alarm priorities for Diagnostic and System alarms

Alarm description Alarm category

Alarm priority

Not audible Lowest Middle Highest Critical

SIS Logic Solver system failure required immediate action SIS Alarm X

SIS Logic Solver system failure required non-urgent action SIS Alarm X

BPCS system failure required immediate action System Alarm X

BPCS system failure required non-urgent action System Alarm X

SIS device (sensor, final el ement) failure, SIL3 Device Alarm X



DCS device failure related to critical or highest priority module Device Alarm X

BPCS device failure related to highest/critical priority module Device Alarm X

BPCS device failure related to middle priority module Device Alarm X

BPCS device failure related to lowest priority module Device Alarm X

Device alert due to check function Device Alarm X

Device alert due to off-specification Device Alarm X

Device alert due to check function Device Alarm X


Rev 1.01.00 17/32

7.8 Alarm limits (setpoint) determination Alarm limits should be systematically based on knowledge of the dynamics of the process and operating conditions.

The early detection of the deviation of the process / equipment from its normal operation shall be provided by monitoring a set of process variable.

The source data of alarm limits shall be defined and the following as a minimum be included:

• Mechanical integrity variables (design limits),

• Safety Instrumented Functions settings (AHH, ALL)

• Pressure safety and relief valve settings.

• Environmental and operating permit variables,

• Equipment specifications from the manufacturer

• Risk assessment variables (PHA/HAZOP),

• Corrosion related variables,

• Storage tank variables,

• Quality variables

Recommended alarm limits are determined based on the following relevant information as well:

• Examination of alarm history

• Examination of relevant operational procedures and normal operating limits

• Process Dynamics (Rate-of-Change, Process Deadtime)

• Process Safety Time – the time between the fault and the occurrence of a hazard

• Understanding of the nature of the operator activities in diagnosing and responding to the situation. To determine the minimum Operator Response Time – the minimum time that must be provided for the operator’s response (>10 minutes)

• Examination of equipment or system response time to the alarm event

The value for each alarm setpoint should be such that, in response, the operator will likely have enough time to reasonably manage the situation before undue consequences occur.

8 Alarm Design In the detailed design stage of the alarm lifecycle, an alarm is designed to meet the requirements documented in the Alarm Philosophy and the rationalization.

Alarm design includes the following:

• Basic alarm design

• Advanced alarm design

• HMI design

Requirements for alarm design:

• The Alarm System shall explicitly be designed to take into account of human factors and limitations.

• The design should ensure that the Alarm System remains usable in all process conditions.

• The Alarm System shall be properly documented, and clear roles and responsibilities shall be established for maintaining and improving the system.

8.1 Considerations for basic alarm design: Basic alarms provide the functionality needed to detect simple disturbances in the process. The basic alarm design for each alarm should use guidance based on the type of alarm and the specific BPCS (DCS, PLC+SCADA, Annunciation System etc.) requirements.

• During the detailed design phase, the information contained in the MADB (such as alarm limit and priority) shall be used to configure the BPCS system.

• Ensure the source of each alarm is documented (where it is triggered from: e.g. field devices, BPCS, SIS, HMI based alarm).

• It shall be possible to initiate process alarms by configuring alarm attributes of any process I/O point (digital and analog), intelligent fieldbus connected field devices (HART, FFB, PROFIBUS etc.) and subsystems connected to the BPCS over communication lines.


18/32 Rev 1.01.00

• The alarms shall be configured within the function block and control module (collection of interconnected function block) of BPCS.

• The Basic Process Control System (DCS, PLC+SCADA etc.) shall support user specific alarms which can be added to any tag in the system. User specific alarms can utilize any parameter, perform calculations, etc. to determine unique alarm conditions.

• Field devices shall generate alerts, due to miscommunication, misoperation (diagnostics) or failure in order to ensure the system integrity.

• Events, process and system alarms shall be time tagged in order to identify correct order of sequence of events.

• For analog tags (AI), the configurable triggers for process alarms shall include:

o Process variable high, high high limit exceeded (AH, AHH)

o Process variable low, low low limit exceeded (AL, ALL)

o Process variable rate-of-change high/low (ROCH, ROCL)

o Process variable invalid value (I, PV_BAD)

• For analog control (PID) tags, the configurable triggers for process alarms are same as seen above on the analog tag and additional shall include:

o Process variable deviation from setpoint/high low (DEVH, DEVL)

o Output low/high limit exceeded (OP_L, OP_H)

• For digital tags (DI, DO), the configurable triggers for process alarms shall include:

o Change from Normal State (CFN)

o Change of State (COS)

• For digital composite tags (DI and DO combined), the configurable triggers are same as seen above on the digital tag and additional shall include:

o Command Disagree (CMD)

o Uncommanded Change (UNC)

• “Bad Value” alarms should be generated if analogue values go outside normal limits (e.g. outside 4-20 mA).

• Alarms from analog/digital inputs should be time stamped to within 1 sec generally, but it may be within 100 msec if application (e.g. sequence of event (SOE) logging for SIS to determine the firs out event) required.

• System (hardware) Alarm: All subsystem or device connected to the communication network of BPCS (DCS, PLC+SCADA etc.) shall be monitored for failures. A system alarm shall be generated for each failure detected at least as follows:

o Not Communicating (COMM) - The subsystem, device or card appears to not be communicating. This means that no other conditions can be detected.

o Failed (FAIL)- The subsystem, device or card is communicating but important functions are not operable or there is a loss of control functions.

o Maintenance (MAINT) - All functions are working, but attention is required.

• The alarm text message shall clearly describe the origin and nature of the alarm in order to avoid ambiguous or confusing alarm messages.

• The alarm text message shall be written in official language of country.

• The Alarm System should be designed to support the different operator tasks throughout a disturbance. It should adapt to varying information needs and be usable in a wide range of process states, such as:

o Start up

o Normal operation

o Small and severe disturbance

o Process shutdown in progress and completed

o Fire/gas warning

o ESD in progress

o Blow-down in progress

• Guidelines for default settings for configuration of alarm attributes shall be provided to minimize chattering alarms.


Rev 1.01.00 19/32

• Low-pass filtering and time delays should be used to prevent repeated alarms when a variable fluctuates around an operating set point.

Table 6: Recommended default settings for alarms

Signal type Filtering deadband (% of operating range)

deadband (On or OFF)

Flow 2 s 5 % 15 s Level 2 s 5 % 60 s Pressure 1 s 2 % 15 s Temperature 0 s 1 % 60 s Other 2 s 3 % 5 s

8.2 Advanced alarm design Advanced alarm design methods should be used when basic alarm designs do not achieve the required performance of Alarm System stated in the Alarm Philosophy.

Advanced alarm design includes the following:

• Logical Alarm Suppression/Attribute Modification

• State based alarm (conditional or dynamic alarm): It modifies alarm setpoint, priority, or suppression status based on defined operating states for equipment or processes.

• Model based alarm

Design requirements for Logical Alarm Suppression:

• Logical Alarm Suppression procedure (logic, program) shall be implemented in the BPCS system.

• Logical Alarm Suppression related to SIS functions should be implemented outside of SIS logic solver or in the not safety related part of SIS logic solver application, to keep the logic of SIS as simple as possible and allow the modification without MOC procedure of SIS.

• All Logical Alarm Suppression procedure (logic, program) shall be capable to manually activate (enable) or deactivate (disable) by operator.

• The operator shall be trained and able to see the all of logical suppressed alarm or group of alarms with their logical conditions required for suppression.

• The list of Logic Suppressed Alarm shall be the object of shift handover procedure to ensure the reviewing and confirm the actual suppression state.

• Algorithms (program, logic) for Logical Alarm Suppression shall be robust and have fail-safe mechanisms to avoid the suppression in case of any failure (e.g Bad Value, badPV) or diagnosed problem.

• Algorithms (program, logic) for Logical Alarm Suppression should be standardized and well-tested to ensure proven in use solutions.

• Algorithms (program, logic) for Logical Alarm Suppression shall not “chatter” and must be specially designed to avoid chattering.

• Algorithms (program, logic) with logical conditions used to detect the need for suppression and for release from suppression shall be transparent to the operator teams.

• Logical Alarm Suppression shall be the part of MOC procedure.

• The alarms are to be automatically suppressed by Logical Alarm Suppression should be indicated on the operator’s HMI graphic display with the suppression state.

• There shall be messages to indicate to the operations team that suppression active.

• Logical Alarm Suppression is allowed to use for creating first-out alarm.

Design requirements for State-Based Alarming:

• The sensor used for detection of operating or process state shall be fault tolerant (redundant, NooM voting) or shall have operator’s confirmation or permission procedure to avoid the inadvertent download the new set of alarm settings. The sensors and transmitters chosen should be very reliable.

• Algorithms (program, logic) for dynamic change of alarms shall be robust and have fail-safe mechanisms.

• The fail-safe mechanisms of algorithms (program, logic) for dynamic change of alarms should be able to automatically set the default alarm settings (e.g. valid for steady-state operation) which are determined during the alarm rationalization.


20/32 Rev 1.01.00

• The all of state, mode, operator’s action and changing of state based alarming shall be logged in the BPCS system.

• Algorithms (program, logic) for State-Based Alarming shall not “chatter” and must be specially designed to avoid chattering.

• Care must be taken to test the algorithms (program, logic) prior to implementation to ensure unsafe conditions are not generated as a result of alarm suppression.

• The alarms are to be part of State-Based alarming group should be indicating on the operator’s HMI graphic display.

8.3 Reliability requirements for alarms The Alarm System may be the following types regarding to reliability requirements:

• Basic Alarm System implemented into the BPCS system

• Safety Related Alarm

Reliability requirements for basic Alarm System:

• The hardware and software components of the basic Alarm System should have sufficient reliability that the failure of a single component does not cause significant (more than one alarm) loss of alarm functions or information related to alarms are to be important to plant safety (Highly Managed Alarms with highest or critical priority).

• The basic Alarm System should allow the operators to obtain information from an alternate alarm display (implemented in another operator’s station) if the primary alarm display device (e.g. operator station, SCADA PC) fails. Note: Operators should be able to access the alarms from more than one operator station.

• Servers for Alarm Log gathering and archiving shall be redundant and shall have magnetic or optical disc storage to ensure continuous logging and long term archiving. The disc storage should be large enough to hold 1 year of alarm records.

Reliability requirements for Safety Related Alarm system: An Alarm System should be considered to be safety related if:

• It is a claimed part of the facilities for reducing the risk from hazards to people and environment to a tolerable level determined during PHA/HAZOP study.

• The required reduction in risk provided by the Alarm System is ‘significant’ namely claimed Average Probability of Failure on Demand (PFDavg) of less than 0.1.

If any Alarm System is safety related then:

• It shall be designed, operated and maintained in accordance with requirements set out in the EN 61508/61511 standard

• It shall be independent from the BPCS system (stand-alone system), it may be a light-box annunciator.

• Annunciation sequences should be provided as per ISA RP 18-1 “Annunciator sequences and specifications”.

• The predefined part of highest and critical priority alarms may be implemented both in the BPCS system and the stand-alone Safety Related Alarm system as well.

• The alarm and event historian shall be provided for Safety Related Alarms integrated with alarm and event historian of BPCS system to ensure common alarm end event log.

Table 7: Reliability Requirements for alarms

Claimed PFDavg Alarm System integrity/ reliability requirements

Human reliability requirements

1 – 0.1 (standard alarm)

• Alarms may be integrated into the BPCS

• No special requirements, see this document and references

0.1 – 0.01 (Safety Related Alarm)

• Alarm System shall be designed as safety related and categorized as SIL1 according to EN 61508

• Alarm System should be independent from the BPCS

• Operator should be trained

• Alarm should be classified at the highest priority in the system

• Alarm should remain on view to the operator for the whole


Rev 1.01.00 21/32

Claimed PFDavg Alarm System integrity/ reliability requirements

Human reliability requirements

system of the time it is active

• Operator should have a clear written alarm response procedure for the alarm

• The required operator response should be simple, obvious and invariant

• The claimed operator performance should have been audited

• Operator shall have at least 10 minutes as a minimum for the corrective action

• Alarm shall be managed as Highly Managed Alarm

Below 0.01 • Not allowed in MOL Group

refineries

9 HMI display

9.1 General HMI requirements

• The standard HMI interfaces of Alarm System (alarm summary, alarm log display, HMI graphic display, tag detail (+ faceplate)) shall be comply with requirements of ISA 18.2 and EEMUA 191 standards.

• HMI displays should be designed in a hierarchy (primary, secondary, etc. displays), which provides progressive exposure of details (e.g. area, unit, detail).

• Multi-level HMI display should be provided based on the process equipment hierarchy for monitoring and control.

• The appropriate and minimum number of HMI display shall be provided for operator task.

• The display refresh rate shall be appropriate to the dynamics of the system being monitored and is at least twice the dominant process time constant but not more than 2 second.

• The Alarm Summary display of BPCS system shall have up to 1 sec first call-up time.

• The HMI graphic display of BPCS system shall have up to 2 sec first call-up time.

• Alarms should be presented in main alarm displays within 2 sec after occurrence

• There shall be dedicated displays to support response to critical upset conditions.

• The navigation scheme between HMI displays should be fairly simple and flat.

• The quick, direct access to primary displays and minimal keystrokes to secondary and associated displays should be facilitated.

• Good HMI display organization shall be provided to allow for direct access to primary displays and intuitive access to non-primary displays.

• Every configured control module in BPCS system shall have an associated HMI graphic display as a primary display for the operators to aid the identification of the control module in the process technology unit and to provide operational interface.

• There shall be possible the navigation to HMI graphic displays without the use of a display menu directory.

• The soft-key (or functional key) configuration should follow a systematic, conceptual organization for position layout and grouping if soft keys are used for calling up displays.

• HMI graphic displays should employ a consistent color codes using only a limited number of universally distinguishable colors (<7) across display hierarchy levels. Each color should have a unique meaning and should only be employed to convey that particular meaning.

• Color combinations should be provided with acceptable and sufficient contrast and avoid color combinations that are confusing for colorblind perception.


22/32 Rev 1.01.00

• Consistent arrangement of objects, layouts, direction of flow and information should be used across similar HMI displays that are appropriate to process behaviors.

• Symbols and process connections should be depicted in a meaningful and consistent manner and be easily understood.

• Symbols should be used which are consistent with industry standards, and site conventions.

• Appropriate display background color should be used (e.g. light gray) that maximizes the overall readability without causing unnecessary eyestrain or fatigue over time.

• There shall be color codes provided that avoid conflicts with cultural stereotypes and industry standards.

• Information presented with text and numbers should be legible and easily understood from the operator's typical position,.

• Short and easily understandable messages should be provided for operators

• Appropriate level of precision and consistent numeric formats should be used to enable quick reading.

• Input dialogs for data and parameter entry shall be simple, consistent, and reliable

• Error avoidance techniques shall be used to prevent data entry errors on control actions (e.g. for SP/OP modification, control mode changing, parameterization etc.). An auditory indication shall be used when an invalid entry is detected.

• Accurate, timely data feedback shall be provided for data entry and control actions to check the successful operation

• Password protected data and parameter entry shall be used for:

• Field devices configuration

• Highly Managed Alarm

• On-line user guidance should be provided for task-specific applications and infrequently used functionality.

• Summarizing, high performance HMI graphic display should be provided with:

o light gray backgrounds

o half-intensity colors for equipment and process line (bright saturated color is used to indicate abnormal situation only!)

o minimal number of line types

o very easy identifiable shape (no 3D graphical object, no excessive detail)

o half-intensity gray process line

o minimized control relationship

o low contrast additional information (measurement unit, if need at all)

o very limited use of color, reserved for alarms and indicating abnormal situations (to avoid the operator’s attention disturbing away from more critical information)

o red and yellow for alarms only according to site Alarm Philosophy

o no animation

• The MOC procedure shall cover major changes in design of operator’s HMI graphic displays and devices.

9.2 Alarm indication

• The visual annunciation of alarms shall effectively orient users to the nature, status and location of abnormal process conditions

• That critical information, such as the alarm summary, process overview should be within a 30 degree maximum angle on the horizontal plane on the operator consol.

• Standard alarm displays shall be available from HMI graphic display to see alarm summary and to view disabled and inhibited alarms.

• Alarms should be integrated in process HMI displays in real-time mode.

• Redundant indication of Safety Critical Alarms should be provided in HMI control/monitor displays.

• Alarm shall always be the most prominent information or object on the HMI graphic displays.

• Alarm information should be informative and easy to understand Alarm information should be easily readable

• Access of alarm rationalization information shall be provided through alarm help. The alarm help should content the following information per alarm as a minimum:


Rev 1.01.00 23/32

o Alarm basic information (tag, description, alarm state, priority, classification)


o Time to respond

o Recommended action

o Probable cause

• Necessary alarm information shall be available from all relevant HMI graphic workplaces as follows:

o Tag identity

o Alarm state including acknowledge status

o Alarm type

o Alarm priority (color coded acceptable)

o Alarm suppression status

• Special visual annunciation should be used for new alarms.

• The alarm indicator on the HMI graphic display should blink for a new and unacknowledged alarm as an attention-getting solution. Remain blinking until acknowledged by the operator, then remain steady until the parameter returns to normal. Use of flashing or blinking indication on HMI graphic display, without the ability to turn it off, should be avoided.

• Alarm colors shall be used only to HMI graphic display alarms and never for anything else.

• Alarm color coding for alarm visualization shall be unique. (e.g. if red is used to indicate an highest or critical priority alarm, it shall not also be used to indicate that a pump motor is stopped or a valve is closed)

• Alarm priority shall be color coded and letter and/or shape coded as following:

o Critical or highest (emergency/urgent): Red and “C” or “E”/”U”

o Middle (high, warning): Yellow and “H”/”W”

o Lowest (low, advisory): Magenta and “L”/”A”

• A HMI graphic display shall visually and consistently high light tag or object in alarm, whether or not the alarm is acknowledged, and priority of the alarm.

• The Alarm System should be context sensitive. Alarms should be designed so that they are worthy of operator attention in all the plant states and operating conditions in which they are displayed.

• Use of too many colors is not recommended in order for effectiveness.

• The HMI graphic display shall be designed to minimize the number of keystroke or operator’s operation required to identify, verify and assess an alarm. (Never be necessary for the operator to type in a tag name or HMI graphic display name.)

• Number of key presses per alarm to affect change in the system up to 3.

• Every configured module with alarm should have an associated HMI graphic display and it should aid the operator in the proper diagnosis and mitigation of the event that caused the alarm.

• Techniques should be use to minimize the possibility of operator mistake, and provide validation (or confirmation) and security measures.

• Alarm Acknowledgement: Ideally the operator should only be able to acknowledge an alarm from the display on which he must take the associated corrective action or have a direct connection there. (note: operators should be trained to leave each alarm unacknowledged until the associated corrective action has been performed.)

• Status information related to safety system functions, such as blocking/inhibit and override (MOS/POS), shall be easily available on dedicated lists and in dedicated HMI graphic displays

• Safety critical functions should be identified and documented. Status information and failure alarms from these functions should be clearly presented and continuously visible on dedicated displays.

• There shall be dedicated HMI graphic display for the following Highly Managed Alarms:

o Fire and gas (F&G)

o Flare & relief system

o SIS logic with logic inputs/outputs, setting limits, actual values and MOS/POS

o System status with the UPS/PS status


24/32 Rev 1.01.00

9.3 Alarm sound annunciation

• The audible warning should convey as much information as possible about the nature of the alarm, its priority and the plant area affected. Every alarm priority chosen shall have its own unique alarm sound.

• The alarm sound is to be acoustic annunciation should be sufficient loud to be audible and be above the ambient noise, but not be hurtful.

• There shall be an audible bypass of alarm sound (Silence) for upset conditions.

• Vibrate mechanism should be used to indicate an alarm for field environments or for process control operators who carry mobile or paging systems.

10 Testing of Alarm System General requirements for alarm testing:

• Testing should be carried out by suitably trained competent individuals.

• The operator may need to take an active participant in the test.

• Testing (verification/validation) is required on new systems and modifications to existing systems. Testing is not required if change does not involve changes to hardware, system software or algorithm (program, logic).

• Results of the tests should be recorded, that includes the differences, faults and required corrective actions.

• Faults should be rectified at the time of testing.

• An overall review of the results of testing should be carried out periodically.

• There should be individual written test procedures (for initial test and/or periodical proof test) for each Highly Managed Alarms.

• The periodical test of Highly Managed Alarm shall be carried out from the sensor to all outputs, where the outputs can include HMI readings, alarm screens, alarm history database, local annunciations.

• The Highly Managed Alarms shall be tested at annually.

• The strategy should address the testing of Safety Related Alarms to assure their reliability, where the test interval should be calculated to achieve the required target PFDavg. The proof test interval of Safety

Related Alarm shall not be less than half year.

• The Fire & Gas (F&G) Alarm System shall be designed so that function testing can be carried out without disabling the system.

11 Alarm System handling (operation) In the operation the alarm or Alarm System is active and it performs its intended function and able to indicate an abnormal condition to operator.

The key aspects of alarm handling:

• Alarm Suppression (filtering, shelving, suppression, decommission)

• Alarm Response

11.1 Alarm suppression requirements Objective of alarm suppression: A general mechanism for preventing an alarm from being generated and/or displayed (with audible warning) to the operator.

The common alarm filtering and suppression methods:

• Alarm display filtering

• Alarm shelving (disable)

• Alarm suppressing (inhibit, out of service)

• Decommissioned (de-configured or deleted)

Table 8: Alarm suppression method

Alarm suppression

method

Displayed on alarm list

Displayed on module

detail

Displayed on HMI

graphic

Audible warning Logged Printed

report

Alarm display NO YES YES YES YES YES


Rev 1.01.00 25/32

Alarm suppression

method

Displayed on alarm list

Displayed on module

detail

Displayed on HMI

graphic

Audible warning Logged Printed

report

filtering Temporary optional

Alarm shelving NO

Shelving list

YES Shelv.ind.

No blinking

YES Shelv.ind.

No blinking NO YES NO

Alarm suppressed

NO NO

Suppr.ind. NO

Suppr.ind. NO NO NO

Decommission NO NO NO NO NO NO

Alarm display filtering: An alarm display filtering capability temporary allows smaller, more manageable lists to be selected for operator’s view.

• Alarm display filtering should be avoided to prevent the invisible active alarms.

• There shall be a filtering mark to indicate that the alarm list is being filtered out.

• The alarm display filtering shall not affect the alarm generation, alarm logging, audible warning and alarm indication on other operator’s HMI graphic displays and/or faceplate etc realized on the same or other operator station.

Alarm shelving: It is a mechanism, typically initiated by the operator to temporarily suppress an alarm and place them to a shelved alarm list. A shelved alarm will be removed from the main alarm list (e.g. Alarm

Summary) and will not re-annunciate until un-shelved.

• The alarm shelving shall not affect the alarm generation and alarm logging.

• Shelved alarms shall not be presented in the main alarm display (e.g. Alarm Summary), shall not generate audible warning, but should be available in the detailed process displays and on shelved alarm lists.

• It shall be possible to shelve individual alarms via authorized procedure.

• Alarm shelving shall be under administrative control and described in Alarm Philosophy and operating procedures.

• An administrative system should be used to keep track of alarm shelving and provide user authorization mechanisms that prevent important alarms, such as safety critical alarms, from being too easily shelved by operators.

• The operator should be required to document the reason for shelving the alarm in an administrative system.

• The operator shall be able to unshelve an alarm very easily;

• The operator shall be able to easily observe what alarms are shelved in the dedicated shelved alarm list, as well as through symbols in the process HMI graphic pictures and module detail display (or faceplate).

• Shelving could be time limited to prevent important alarms to be removed and forgotten.

• The operators’ administrative control is required to ensure that the operators to check the list of shelved alarms and the reasons for them being there at each shift changeover. The list of shelved alarms shall be reviewed at the start of each shift to ensure that no alarms are unintentionally shelved or forgotten.

• The occurrences of shelved alarms should be logged.

• Additional authorization is required for shelving of Highly Managed Alarm.

General alarm suppression requirements:

• Suppressed alarms shall not be presented in the main alarm display (e.g. Alarm Summary), shall not generate audible warning and shall not be logged.

• Suppressed alarms shall be clearly distinguished from other active alarms in the displays where they are shown.

• It shall be possible to suppress individual alarms via authorized procedure.

• Alarm suppressing shall be under administrative control and described in Alarm Philosophy and operating procedures.

• An administrative system should be used to keep track of alarm suppressing and provide user authorization mechanisms that prevent important alarms, such as safety critical alarms, from being too easily suppressed by operators or supervisor (shift leader).


26/32 Rev 1.01.00

• The operator should be required to document the reason for suppressing the alarm in an administrative system that should be part of Alarm Management System.

• There shall be provided an alarm suppression timeout function.

• The operator shall be able to activate an suppressed alarm very easily

• The operator shall be able to easily observe what alarms are suppressed in the dedicated suppressed alarm list, as well as through symbols in the process HMI graphic pictures and module detail display (or faceplate).

• The operators’ administrative control is required to ensure that the operator shall check the list of suppressed alarms and the reasons for them being there at each shift changeover.

• The list of suppressed alarms shall be reviewed at the start of each shift to ensure that no alarms are unintentionally shelved or forgotten.

• Additional authorization (more rigorous) is required for suppression of Highly Managed Alarm.

• Hardwired alarms (light boxes) shall never be suppressed Decommissioned (de-configured or deleted) alarm : It is a change process to remove an alarm from the Alarm System, where parameters are changed to get rid of an alarm to never produce the alarm event. The alarm configuration reflects that an alarm is not intended to be generated.

• Decommission or deletion of alarms, shall follow the MOC process specified in the Alarm Philosophy.

• If an alarm is no longer needed then it should be decommissioned from the Alarm System.

• Displays and related documentation shall be modified within a reasonable time.

Authorization of alarm suppression The alarm suppression shall be under an administrative control which determines the authorization procedure with responsibilities and their rights.

Table 9: Authorization of alarm suppression (example):

Alarm suppression

method

Alarm priority Operator Supervisor Operation

Manager Plant

Manager Techno-

logist Alarm Expert

System Prog-

rammer

Alarm display filtering

Critical *

RE RE

Highest RE RE Middle RE RE Lowest RE RE

Alarm shelving

Critical *

N N RV / A V, D RE

Highest RE RE Middle RE RE Lowest RE RE

Alarm suppres-

sed

Critical *

N N RV / A I RV / A V / D RE

Highest N N RV / A RV / A V / D RE Middle RE RE R R I Lowest RE RE R R I

Decom-mission

Critical *

I I RV / A I RV / A V / D RE

Highest I I RV / A I RV / A V / D RE Middle I I RV / A RV / A V / D RE Lowest I I RV / A RV / A V / D RE

RE: Responsible for execute, RV: Review, A: Approval, I: Inform, V: Verify, D: Document, N: Not allowed, “ “: Not applicable

11.2 Alarm response

• Alarm response (alarm help) procedures shall be readily accessible to the operators.

• Alarm response (alarm help) procedures shall be based on documentation of alarm rationalization (Master Alarm Database)

• Alarm response (alarm help) should content the following information per alarm as a minimum:


Rev 1.01.00 27/32

o Alarm basic information (tag, description, alarm state, priority, classification)


o Time to respond

o Recommended action

o Probable cause

12 Alarm System performance monitoring Performance monitoring is the periodic collection and analysis of data from Alarm System during the operation life cycle stage.

Objective: Verify that design, implementation, operation and maintenance are satisfactory namely the Alarm System is performing properly.

General requirements for performance monitoring of Alarm System

• Alarm System and/or connected Alarm Management System shall be able to import archived alarm and event historian in on-line or off-line mode for analysis purpose. In another manner it should have capability to collect text-based alarm information from any system or devices that can send time stamped alarm information through serial port (printer), TCP/IP network, network printer or OPC Alarm & Event connection.

• Alarm System and/or connected Alarm Management System should provide analysis tools that calculate the number of alarms presented to the operator per time period (e.g. quantity of alarms/10 minutes)

• Alarm System and/or connected Alarm Management System should provide analysis tools which calculate and display alarm frequency, average time in alarm, time between alarms, and time before acknowledgement

• The Alarm System performance measures should include:

o Rate of incoming alarms per hour

o Average number of alarm per hour

o Maximum number of alarm per given time period (10 min, hour, day)

o % of hours where alarm rate outside acceptability target (30 alarms/hour)

o % of 10 minute periods where containing more than 10 alarms

o Number of long standing alarms (per priority, per alarm category, per alarm type, per unit area)

o Maximum number of long standing alarms (per priority, per alarm category, per alarm type, per unit area)

o Number of shelved/disabled alarms (per priority, per alarm category, per alarm type, per unit area)

o Average number of shelved/disabled alarms (per priority, per alarm category, per alarm type, per unit area)

o Maximum number of shelved/disabled alarms (per priority, per alarm category, per alarm type, per unit area)

o Overall number of alarm floods per day and week

o Duration of alarm status,

o Top 10-20 most frequently occurring alarms

o Incidence of active / unacknowledged alarm signal times,

o Duration of alarm acknowledgement, operator response times (time before acceptance): Too long or too short response times indicate that the system is not being used as intended

o Number of alarms that have returned unacknowledged,


28/32 Rev 1.01.00

Table 10: Alarm Performance Metrics (based on ISA-18.2)

Alarm Performance Me trics Based upon at least 30 days of data

Metric Target Value

Annunciated Alarms per Time: Target Value: Very Likely to be Acceptable

Target Value: Maximum Manageable

Annunciated Alarms Per Day per Operating Position

~150 alarms per day ~300 alarms per day

Annunciated Alarms Per Hour per Operating Position

~6 (average) ~12 (average)

Annunciated Alarms Per 10 Minutes per Operating Position ~1 (average) ~2 (average)

Percentage of hours containing more than 30 alarms

~<1%

Percentage of 10-minute periods containing more than 10 alarms

~<1%

Maximum number of alarms in a 10 minute period

≤10

Percentage of time the Alarm System is in a flood condition

~<1%

Percentage contribution of the top 10 most frequent alarms to the overall alarm load

~<1% to 5% maximum, with action plans to address deficiencies.

Quantity of chattering and fleeting alarms Zero, action plans to correct any that occur.

Stale Alarms Less than 5 present on any day, with action plans to address

Unauthorized Alarm Suppression Zero alarms suppressed outside of controlled or approved methodologies

Unauthorized Alarm Attribute Changes Zero alarm attribute changes outside of approved methodologies or MOC

13 Alarm System maintenance Alarm System Maintenance provides periodic collection of alarm and event data for monitoring, analysis and reporting.

Alarm System monitoring:

• Unauthorized alarm configuration changes should be periodically detected and resolved.

• Monthly monitoring of alarms affecting safety (Safety Critical and/or Highly Managed Alarms) shall be carried out to discover that, it has been taken off scan, have been alarms suppressed, have generated false alarms, or have forced or manual values for durations exceeding those needed for appropriate maintenance or operating activities.

• Annual verification of proper setpoints, priority, attributes with the descriptions of alarm response that related to Safety Related Alarms shall be provided.

• Annual review of the Alarm Philosophy should be performed.

Alarm System analyses and reporting:

• Alarm System performance should be regularly and properly analysed and reported.

• Annual review of Alarm System performance and compare with the target value of performance metrics shall be provided.

14 Management of change Objectives: Management of Change (MOC) entails the use of tools and procedures to ensure that modifications to the Alarm System (e.g. alarm addition/removal, changing alarm limit/priority/attributes) are reviewed, verified and approved prior to implementation, furthermore documented and propagated when the changes have been implemented.

• The MOC shall cover permanent changes in configuration of Alarm System and the Master Alarm Database.


Rev 1.01.00 29/32

• The MOC shall ensure that changes to Alarm System are correct, consistent, and properly documented

• Once the change is approved, the Master Alarm Database should be updated to keep it current.

• There shall be an Alarm Management tool to allow direct comparison between alarm settings in the Master Alarm Database and in the running system in order to discover the differences.

• Personnel affected by the change shall be informed of the change and trained prior to implementation of the change or startup of the process, as appropriate.

• Changes to the Alarm System may require testing, the critical priority alarms are to be changed shall be tested. Proper testing ensures that changes have had the expected effect on the Alarm System and the Alarm System is operating as desired.

• The changes in the Safety Related Alarm system shall have a rigorous or end-to-end testing.

Table 11.: Authorization of alarm settings (setpoint, priority, attribute) changes:

Alarm suppression

method

Alarm priority Operator Super-

visor Operation Manager

Plant Manager

Techno-logist

Alarm Expert

System Prog-

rammer

Alarm limits

(setpoint)

Critical *


Highest I I RV / A I RV / A V / D RE Middle I I RV / A RV / A V / D RE Lowest RE / I RE / I I I V / D I

Alarm priority

Critical *


Highest I I RV / A I RV / A V / D RE Middle I I RV / A RV / A V / D RE Lowest I I RV / A I V / D RE

Alarm attributes

Critical *

I I RV / A I I V / D RE

Highest I I RV / A I I V / D RE Middle I I RV / A I V / D RE Lowest I I RV I V / D RE

Master Alarm

Database (MADB)

Critical * RV / A I RV / A V / D I

Highest RV / A I RV / A V / D I Middle RV / A RV / A V / D I Lowest RV I V / D I

RE: Responsible for execution, RV: Review, A: Approval, I: Inform, V: Verify, D: Document, N: Not allowed, “ “: Not applicable

15 Recommended practice, examples

15.1 Logical Alarm suppression for typical BMS appl ication Table 12. Logical Alarm suppression for typical BMS application (example)

Phase / Alarms

Permission to start

Pre-purge

Ignition of pilots

Ignition of main burner

Normal operation

(low temp)

Normal operation

(high temp) Shutdown

Leak-tightness test alarm of safety DBB

valve A S S S S S S

Air blower not run alarm (stopped) S A S A A A S

Flame alarm (light) of pilot burner A A S S S S A

Flame alarm (light) of main burner A A S S S S A


30/32 Rev 1.01.00

Phase / Alarms

Permission to start

Pre-purge

Ignition of pilots


Normal operation

(low temp)

Normal operation


Air damper not opened alarm A A S S S S S

Flue stack damper not open alarm A A S S S S S

Pre-purgin g air flow low alarm S A S S S S S

Ignition time alarm

of pilot burner S S A S S S S

Ignition attempts alarm of pilot burner S S A S S S S

Flame failure alarm of pilot burner S S A A A A S

Pilot burner fuel gas pressure low alarm S S A A A A S

Pilot burner fuel gas pressure high alarm S S A A A A S

Ignition time alarm of main burner S S S A S S S

Ignition attempts alarm of main burner S S S A S S S

Flame failure alarm of main burner S S S A FO FO S

Main burner fuel gas pressure low alarm S S S S FO FO S

Main burner fuel gas pressure high alarm S S S S FO FO S

Air damper

closed alarm S S S A FO FO S

Flue stack damper closed alarm S S S A FO FO S

High pressure (low draft) in the chamber

alarm S S S S FO FO S

Combustion air lo w flow alarm S S S S FO FO S

Exhaust fan failure alarm S S S S FO FO S

High temperature in the chamber alarm A S S S FO FO A

Low temperature in the chamber alarm S S S S S A S

Flue gas high temperature alarm A S S S FO FO A

Air / fuel ratio alarm S S S S A A S

O2 content in the flue gas low alarm S S S S A A S

O2 content in the flue gas high alarm S S S S A A S

CO content in the flue gas high alarm S S S S A A S

Fuel oil temperature S S S S FO FO S


Rev 1.01.00 31/32

Phase / Alarms

Permission to start

Pre-purge

Ignition of pilots


Normal operation

(low temp)

Normal operation


low alarm Fuel oil pressure low

alarm S S S S FO FO S

Fuel oil pressure high alarm S S S S FO FO S

Injection steam pressure low alarm S S S S FO FO S

Injection steam & fuel oil dP low alarm S S S S FO FO S

Heater process flow

low alarm S S S S FO FO S

Outlet temperature high alarm S S S S FO FO S

Outlet temperature low alarm S S S S A A S

Manual Shutdown

alarm FO FO FO FO FO FO S

Utility failure alarm (Instrument air pressure low)

A A FO FO FO FO S

Safety DBB valve command disagree

to open S S A A A A S

Safety DBB v alve command disagree

to close A A S S S S A

MOS and/or MOS over time alarm A A A A A A S

POS and/or MOS over time alarm A A A A A A S

Note: A: Activated; S: Suppressed; FO: First-out alarm


32/32 Rev 1.01.00

15.2 Recommended HMI graphic display

Figure 1: Typical HMI graphic display

SLOVNAFT a.s.

R&M Division


MOL Group


INSTRUMENTATION

6. Control Systems

10. Design of gas alarm systems

MGS-S-REF-I-6.10

Rev 1.00.00



6 Control Systems Date: 30.11.2011

10 Design of gas alarm systems Page/Pages: 2/6


Release list


0.00.00 31.10.2008 Basic release

0.00.01 01.11.2011 General review F. Nagy Z. Stanová

1.00.00 30.11.2011 General issue F. Nagy Z. Stanová


Rev 1.00.00 3/6

Contents Release list ................................................................................................................................................................... 2 Design of gas alarm system ......................................................................................................................................... 4 1 General .................................................................................................................................................................. 4 2 Applicable standards ............................................................................................................................................. 4 3 Definition of terms.................................................................................................................................................. 4

3.1 Lower explosion limit (LEL) ........................................................................................................................... 4 3.2 Lower explosion point ................................................................................................................................... 4 3.3 Long term exposure limit (ppm or mg/m

3) .................................................................................................... 4

4 System design ....................................................................................................................................................... 4 4.1 Field installed detectors ................................................................................................................................ 4 4.2 Central unit of the atmospheric gas contamination detection system .......................................................... 4 4.3 System configuration .................................................................................................................................... 5

5 Criteria for selecting and erecting field detectors .................................................................................................. 5 5.1 Detectors for flammable gases ..................................................................................................................... 6 5.2 Detectors for toxic gases .............................................................................................................................. 6


4/6 Rev 1.00.00

DESIGN OF GAS ALARM SYSTEM

1 General

This specification summarises the general requirements applicable to the design of systems installed in facilities to detect gas contamination in the atmosphere. During the installation of a facility or plant the project specification applicable to the specific facility may contain deviations from this document. In case of deviation the requirements set forth in the project documents shall govern.

The project specification may contain deviations from, or changes in, these requirements. Any deviation from the content of this specification or from the project specification will be possible with a written approval thereof by the competent expert in the area at MOL Group only.

2 Applicable standards

According to MGS-M-REF-I-4 & MGS-S-REF-I-4

3 Definition of terms

3.1 Lower explosion limit (LEL)

Such concentration of flammable gas or vapour in the atmosphere below which the gaseous medium cannot explode.

3.2 Lower explosion point

Such a temperature of flammable liquid at which the concentration of saturated vapour in the atmosphere coincides with the lower explosion limit.

3.3 Long term exposure limit (ppm or mg/m3)

Such a concentration of toxic gas in the atmosphere over which the long term (8 hours) exposure can be human dangerous.

4 System design

4.1 Field installed detectors

1. The installation location for the field detectors of the atmospheric gas contamination detection system shall be approved by MOL Group HSE (Health, Safety and Environment) organisation with due consideration of the hazardous area classification of the specific facility or of the occurrence of toxic substances.

2. Detector shall be mounted at locations where the probability of mechanical damages, external effects (steam, water, dust) is minimal. In case this cannot be ensured the detectors shall be equipped with mechanical protection (such as protective cover or screen).

3. The detectors shall have protective hoods against water or moisture, and hydrogen detectors shall have a collecting cone.

4. For detectors mounted at high elevations or not accessible without the use of aids, stainless steel or plastic sampling tube shall be installed in order to enable introduction of test or calibration gas to the detectors. The end of the sampling tube shall be located in a location mechanically protected (e.g. against wasps, spiders, water and dust) and accessible for the maintenance personnel without any aid.

4.2 Central unit of the atmospheric gas contamination detection system

1. The gas contamination detection system applied shall have a central unit.

2. The central unit of the atmospheric gas contamination detection system shall be located on the main board or in an instrument cabinet in the control room.

3. The central unit shall be of modular design, with possibility for extension and configuration per channel.

4. The voltage levels required for the detectors and signal-processing cards shall be provided by the internal power supply unit of the system.

5. The central unit of the atmospheric gas contamination detection system shall be powered from UPS.

6. The signal processing cards shall include a sufficient number of pre-alarm, emergency alarm and self-diagnostic failure/error outputs, as required by system configuration.


Rev 1.00.00 5/6

7. The output relays of processing cards shall be free of any error or fault and in closed contact in their energised (default) position.

8. Processing cards shall be configured in a manner that, when the gas concentration causing an alarm ceases to exist, the relays shall return to their default position.

9. Plates with the serial numbers of channels and with the location of their in-field/ at-plant installation shall be placed in the direct vicinity of the central unit (e.g. next to heat exchanger E102).

10. If an intelligent process control system (hereinafter: ICS) is in place at the facility equipped with field instrumentation management system (hereinafter: FIMS) no need to install central unit. In this case all the detectors directly connected to ICS using 4-20 mA and the field detectors have to connect to the FIMS.

4.3 System configuration

1. The atmospheric gas contamination detection system shall include the indoor and/or outdoor detectors, the central signal processing unit (signal processing cards, power supply unit, support rack, diagnostics and monitor cards), strobe lights installed in process/field areas, alarm horn, audible alarm acknowledge button, and test button to check the functionability of the audible and visual alarms.

2. In process areas where the noise level is high, warning (strobe) lights shall be mounted at easily visible locations (if required at several locations) giving a flashing warning signal if an emergency (HH) concentration is detected by any of the gas contamination detectors associated with a specific area. The flashing light shall keep on until the level of the gas contamination detected by all detectors associated with the system drops below the emergency maximum level.

3. At a central location in the plant area a warning horn shall also be installed. The horn shall give an audible signal if emergency (HH) concentration is detected by any of the gas contamination detectors associated with the system until the audible alarm acknowledge button is pushed.

4. In case instrument air is available near the installation location of the warning horn, the warning horn shall be pneumatically operated. In case instrument air or other utility (e.g. inert gas) required for the horn operation is not available, or the connection of the instrument air to the warning horn would result in disproportionately high costs, use of an electrical operation horn is permitted.

5. The logic used to trigger, acknowledge and test acoustic or light alarms can be developed in the following manner:

By using a safety PLC, or

By using relay-based logic.

6. If a trip-off needs to be triggered for the gas contamination limit value, it can be done in the following manner:

By using a safety PLC, or

By using relay-based logic.

7. If an intelligent process control system is in place at the facility, the ICS shall display and log the following alarms :

atmospheric gas contamination high (H) pre-alarm (e.g. high at 20% LEL per detector);

atmospheric gas contamination high-high (HH) alarm (e.g. HH at 40% LEL per detector);

common failure alarm of atmospheric gas contamination detection system;

audible alarm acknowledge button pushed;

light/lamp and horn test button pushed.

8. If the installation location of the central unit for the atmospheric gas contamination detector is manned on a continuous basis by operators, it is sufficient to have a common alarm on the ICS for high and high-high gas contamination alarms, otherwise display by channel is required. Forwarding of signals to the ICS can be done either via a serial bus (e.g. Modbus) or by way of individual cabling.

9. Signal processing boards shall be set to the gas to be detected (sensitivity, alarm levels).

5 Criteria for selecting and erecting field detectors

The explosion protection of field detectors shall comply with the hazardous zone classification of the specific installation location.

For the connection of detectors operating on catalytic principle the following aspects must be observed in order to reduce line resistance:

use of solid conductor cables;


6/6 Rev 1.00.00

if possible, no junction box shall be used;

use of cables with conductor of large cross-sections for long distances.

The scaffold holding the detectors that measure flammable and toxic gases shall be painted red and yellow, respectively.

The metal housing and holding scaffold of sensors/ detectors shall be connected to the unit’s ground network (EPH).

It is preferred to use sensors/ detectors/ transmitters that have self-diagnostic mechanisms.

5.1 Detectors for flammable gases

1. Gas detectors working on catalytic and infrared light absorption principle shall be used.

2. If the flammable gas is always present at the installation site at a low concentration, and there is a need for rapid detection, the installation of an infrared light absorption gas detector is recommended.

3. Hydrogen detectors shall be equipped with collection cones.

5.2 Detectors for toxic gases

1. Gas detectors measuring on the basis of electrochemical principle shall be used.

2. The structural material of the detectors shall be suitable for the specific environment (e.g. hydrogen-sulphide detectors must not have brass glands).

technical specification instrumentation 6 process control

Documents