Ng Odu Xodu Ipa 070069

Approved code 1

Approved with comments code 2

Rejected code 3

Reviewed with comments code 4

No comment code 5

TEPNG review comment and/ or Approval shall not be assumed to indicate either responsability orliability for accurancy and completeness of this document or to alter any contract Terms & Conditions.

Date:

The document is returned with code

Reserved to COMPANY

Remarks:

1.0 23-Feb-15 Issued for Review

Rev. Date Description Issued by Reviewed by Approved by

This document is the property of TOTAL and must not be reproduced, stored or disclosed without permission from COMPANY.

OML100 [ODUDU & FSO UNITY] ICSS – SYSTEM Upgrade

Detailed Engineering

SMR/SOR/SIN nbr.

S0R-100-09-001

ICSS Network Performance DVT Procedure page: 1/40

COMPANYref. number NG-ODU-XODU-IPA-070069

Rev. Status Rev. date Discipline INS

1.0 IDC 23-Feb-15 Doc. Type SPEC

CONTRACTOR ref: NG-ODU-XODU-IPA-070069 -- -- -- (Syst.) Unit NX

ICSS Network Performance DVT Procedure

TABLE OF CONTENTS

1. Introduction................................................................................................................................... 6

1.1. Document Scope........................................................................................................6

1.2. Reference Documents................................................................................................6

1.3. Abbreviations.............................................................................................................7

2. Overview................................................................................................................8

2.1. DVT Location..............................................................................................................8

2.2. Tests Purposes...........................................................................................................8

2.3. General Test Procedure.............................................................................................8

2.4. Network Architecture.................................................................................................9

2.5. Platform Equipments................................................................................................10

2.6. PCS & Safety System Communication Interface......................................................10

2.7. Safety System..........................................................................................................11

3. Network Redundancy Test.....................................................................................12

3.1. PCS Network Test-Step 1.........................................................................................123.1.1. Test 1.1-Vnet/IP Redundancy.........................................................................................123.1.2. Test 1.2-Equalization Network.......................................................................................133.1.3. Test 1.3: Communication Capacity................................................................................14

3.2. Safety Network Test: Step 2....................................................................................153.2.1. Test 2.1: Peer to Peer Redundancy................................................................................153.2.2. Test 2.2: Modbus Redundancy.......................................................................................173.2.3. Test 2.3: Digital Data Read............................................................................................193.2.4. Test 2.4: Communication Capacity................................................................................20

3.3. Fire and Gas System (FGS): Step 3..........................................................................213.3.1. Test 3.1: Peer to Peer Communication Redundancy Test...............................................213.3.2. Test 3.2: Peer to Peer Redundancy................................................................................213.3.3. Test 3.3: Test Sheet Modbus Redundancy.....................................................................23

4. Communication PCS/SSS/FGS-Step 4......................................................................26

4.1. Test 4.1: Digital Data (Read)....................................................................................26

4.2. Test 4.2: Digital Data (Write)...................................................................................26




SMR/SOR/SIN nbr.

S0R-100-09-001






4.3. Test 4.3: Analogue Data (Read)...............................................................................27

4.4. Test4.4: Analogue Data (Write)...............................................................................28

4.5. Test 4.5: Interface Cable Failure/ICSS Coms Module Failure....................................29

5. Safety Peer to Peer: Step 5....................................................................................30

5.1. TEST 5.1 - INITIAL SET UP.........................................................................................30

5.2. Test 5.2: Input / Output Digital Data (From Device 1 To Device 2)..........................31

5.3. Test 5.3: Input / Output Digital Data (From Device 2 To Device 1)..........................32

5.4. Test 5.4: Input / Output Analogue Data (From Device 1 To Device 2).....................33

5.5. Test 5.5: Input / Output Analogue Data (From Device 2 To Device 1)......................34

5.6. Test 5.6: P2P Interface Cable Failure/ICSS Coms Module Failure.............................35

6. Tests Sheets: Formally Agreed Additional Tests......................................................39

7. Appendix..............................................................................................................40

7.1. Appendix A...............................................................................................................40

7.2. Appendix B...............................................................................................................43

7.3. Appendix C...............................................................................................................45




SMR/SOR/SIN nbr.

S0R-100-09-001






LIST OF TABLES

Table 1: Reference Documents.............................................................................................................6Table 2: Operation Station Vnet/IP.....................................................................................................12Table 3: Operation Station Equalization Network............................................................................13Table 4: Operator Work Station P2P Redundancy...........................................................................15Table 5: Operator Work Station..........................................................................................................21Table 6: Operator Work Station..........................................................................................................23Table 7: Appendix A..............................................................................................................................42Table 8: Appendix B..............................................................................................................................44Table 9: Appendix C..............................................................................................................................46




SMR/SOR/SIN nbr.

S0R-100-09-001






LIST OF FIGURES

Figure 1: Network Architecture.............................................................................................................9Figure 2: Successful Ping Indicate a Request Time........................................................................16Figure 3: Successful Ping Indicate a Request Time........................................................................17Figure 4: Successful Ping Indicate a Request Time........................................................................22Figure 5: Successful Ping Indicate a Request Time........................................................................24




SMR/SOR/SIN nbr.

S0R-100-09-001






1. Introduction

The oil fields Odudu, together with Afia, Ime and Edikan are located on OML 100. These fields were developed by TEPNG in the conventional offshore area (water depth: 70m) in the period 1993-1995 which makes them about 20 years old.

OML 100 fields are developed with a manned central complex comprising a process platform (ODP1) bridged linked to the wellhead platform (ODD1). Three unmanned satellites AFD1, IMD1 and EDD1 are tied back to the central complex. The liquids of three satellite fields (Afia, Ime and Edikan) are piped to ODP1 and onwards to FSO UNITY. The central complex also handles the oil production from two other blocks, OML 102 (Ofon) and OML 99 (Amenam). This makes ODP1/ODD1 a production hub for OML 99, OML 100 and OML 102. Its unavailability would have a major impact on TEPNG production, therefore all safety issues on ODP1/ODD1 shall be treated as highly critical. Odudu offshore field is located 102km south-east of Port Harcourt. It is accessible by boat and Helicopter.

1.1. Document Scope

This document defines and details the Network performance test procedure developed for the DVT of OML100 Upgrade Project.

1.2. Reference Documents

S. No. Document Number Title

1 GS EP INS 134Design and supply of integrated control and safety system

2 NG-ODU-XODU-IPA-070101 Overall ICSS Architecture Drawing

3 IM 33M05D10-40E 3rd Edition HIS Operation

4 IM 33M01A30-40E 5th Edition Reference Human Interface Station

5 IM 33M01A30-40E 4th Edition Reference Engineering Vol 2

Table 1: Reference Documents




SMR/SOR/SIN nbr.

S0R-100-09-001






1.3. Abbreviations

A&E : Alarm and Event DVT : Device Validation Test ESD : Emergency Shut-Down EWS : Engineer Work Station FGS : Fire and Gas System FAT: Factory Acceptance Test I/O : Input / Output to PCS/SSS/FGS ICSS : Integrated Control Safety System OWS : Operator Work Station PLC: Programmable Logic Controller PV : Process Variable PCS : Process Control System P2P: Peer to Peer SSS : Safety Shutdown System SP : Set point TEPNG: Total Exploration and Production Nigeria TMR : Triple Modular Redundant TCR : Tricon Communication Redundancy




SMR/SOR/SIN nbr.

S0R-100-09-001






2. Overview

This document specifies to TEPNG the various test types and summarises the scope of these tests that will be performed to verify the design, and functionality of the Network Performance for OML 100 project. It also describes the procedures to be followed with respect to test reporting and the handling of system defects encountered during the tests.

2.1. DVT Location

The tests will be held in Intech USA office, located at:

4903 W. Sam Houston Parkway N. Suite A-100Houston, TX 77041, USADATE:…….

2.2. Tests Purposes

Demonstrate that the control system network during steady state condition is stabilized andthe control system screen update for OML 100 data is as per project specifications.

Generate a sudden high network activity e.g. simulate a simultaneous alarm generationand demonstrate that the network can manage the sudden increase of load without lost ofevent, garble time stamping etc.

Demonstrate that the proposed systems are equipped with adequate communication diagnostic / monitoring

2.3. General Test Procedure.

The body of this document is structured in the form of description of the item to be tested and “Checksheet”. “Check sheet” describes the test and where appropriate also specifies the expected Result of the test. On completion of the test, the engineer marks in the related Test Case.

The general procedures include, as well as a register for non-conformances, acceptable deviationsand change requests which together form an integrated part of the DVT documents.

The register lists the deviations from the specifications which require correction by Intech.

The acceptable deviations are deviations from the specifications which are accepted by TEPNG




SMR/SOR/SIN nbr.

S0R-100-09-001






and which do not require corrective Action by Intech.

The change requests (modification) are not deviation and must be confirmed by TEPNG. The DVT is carried out following the check sheets as specified in this document. The check sheets refer to standard system documentation such as General Specifications (GS)




SMR/SOR/SIN nbr.

S0R-100-09-001






2.4. Network Architecture

Figure 1: Network Architecture




SMR/SOR/SIN nbr.

S0R-100-09-001






2.5. DVT Equipment

The test platform shall use the same control system hardware and software which is going to be used within OML-100 project.

The test platform shall consist of one OWS and one redundant PCS controller for the PCS part, one Safety and FGS Trident controller and PCS and Safety EWS station.

The test for the PCS network and SSS system will be carried out with one redundant PCS controller, and one OWS. The VNET/IP network will be made close to the OML-100 architecture.

The tests of communication performance between PCS, safety and FGS will be carried out with one safety Tricon, one FGS Trident and one PCS redundant controller through a redundant Modbus Ethernet network.

The Peer to Peer communication test will be carried out with one Tricon Controller, one FGS Trident Controller and the OWS and EWS.

On this test platform, the EWS station is connected on the Peer to Peer network. In the OML-100 DVT architecture, the “SSS Maintenance Network” consisting in the EWS stations, the controllers will be a separate network. (For the project there are three networks regarding the Safety architecture: The safety network with Peer to Peer links between Controllers, the Modbus network for communication to/from the PCS systems, and the SSS Maintenance Network)

For the redundant PCS controller Test program, the controllers are fully loaded. To perform the Modbus performance test another test program is downloaded. The projects loaded are for performance test purpose. The testing will be with the target hardware but using test database to ensure the CENTUM performs satisfactory when fully loaded. The project database will be tested during integration testing.

2.6. System Communication Interface

The purpose of this test is to demonstrate that the redundant communication interface linkbetween ICSS Triconex Safety equipment and CENTUM VP PCS equipment is workingsatisfactorily up to the limit capacity.




SMR/SOR/SIN nbr.

S0R-100-09-001






Several tests will be conducted to check if all type of data are correctly read and written from PCS and Triconex Safety System.

Test to be conducted communication recovery between Triconex Safety system and PCS.




SMR/SOR/SIN nbr.

S0R-100-09-001






Peer to Peer Communication

The purpose of this test is to demonstrate that the safety communication interface link between safety equipment is working satisfactorily and satisfy to design capacity and performance requirements. It will also demonstrate that the transfer of safety data by peer to peer is reliable.

Tests will be conducted to check if all type of data are correctly read and written from the safety equipment provided for this DVT.

To demonstrate that the FGS network redundancy is working as it should be (transparent from operation point of view) and able to detect and perform bump less transfer between link.

Modbus Communication

SSS Triconex controllers with TCM installed will be operate as a Modbus Slave to communicate over redundant SSS Data Exchange, each SSS controller connected with two TCM modules both are used simultaneously to exchange data. The failure of one path will not affect Data Exchange.

The purpose of this test is to demonstrate that the Modbus FGS Data Exchange link between FGS and PCS is working properly and to ensure that design capacity and performance requirements are fulfilled. It will also demonstrate that the transfer of safety data through Modbus is reliable and can be used as Modbus salve to communicate with PCS master device.

Sequence of Events Recorded

1. The purpose of this test is to demonstrate that the sequence of event software connected to Triconex equipment is working satisfactorily and satisfy to design capacity and performance requirements.

2. Test will be conducted to check if Boolean type of data is correctly read from ICSS Triconex system to SOE dedicated system.

3. The performance on a sudden increase of alarms




SMR/SOR/SIN nbr.

S0R-100-09-001






3. Network Redundancy Test

3.1. PCS Network Test-Step 1

3.1.1. Test 1.1-Vnet/IP Redundancy

Outline:

The Vnet/IP provides communication between the operator station, engineering station and the field control stations via the switch and also peer to peer communication between field control stations. It is therefore crucial that failure of one bus does not affect the system.

Objective:

The purpose of this test is to ensure that failure of one of the Vnet/IP links has no effect on the process communications.

Procedure:

1. Check that the communication is working properly from the operator station.Station Network EWS PCS 172.16.163OWS PCS 192.168.129.192

Table 2: Operation Station Vnet/IP

2. Disconnect Bus1: Pull the network cable on station/controller or power off switch3. Observe, that there is no lost of communication.4 Observe the system status display5 Reconnect Bus 1

Result

1. No disturbance is observed on the graphic2. The system status display shows the disabled V-net cable.3. System Alarm is raised4. At return of normal condition check that the alarms disappear, no lost of communication.

Record:

Use Appendix A to record the Result.




SMR/SOR/SIN nbr.

S0R-100-09-001






1. Test 1.2-Equalization Network

Outline:

The database equalization network enables the equalization of database between engineering station and operator station via the switch. The failure of this single bus will affect the following general purpose communication

Different station trends display (between HISs).However, Trend gathering in self station will perform without any interruption.

Long-term Data archive (When it is saved in the disk of another PC, shared file) Equalization Communication (between ENG and HIS, shared file) Remote Printer (shared printer) Sequence table/Drawing/SEBOL/SFC status display data acquisition (between ENG

and HIS, shared file) "Download", "IOM Download", "Tuning Parameter Save" in the operating status

display window (HIS ENG, shared file) Network Printer

Objective:

The purpose of this test is to ensure that failure of equalization bus will not affect normal plant operation and control.

Procedure:

1. Check that the communication is working properly from the operator station Graphic visualised

Station Network Address Graphic VisualisedEWS PCS 172.16.163 Domain no 1/ Station no 2OWS PCS 192.168.129.192 Domain no 1/ Station no 1

Table 3: Operation Station Equalization Network

2. Disconnect equalization network: Pull the network cable on station or power off switch3. Reconnect equalization network back.

Result

1. No disturbance is observed on the graphic2. Observe, that there is no loss of real time process data.3. At return of normal condition check no lost of communication.




SMR/SOR/SIN nbr.

S0R-100-09-001






Record:


3.2. Safety Network Test: Step 2

3.2.1. Test 2.4: Communication Capacity

Outline:

To verify that changes are correctly transferred, configured and displayed at maximum load.

Objective:

Purpose of this test is to check reliability of data transmission through Ethernet Modbus Communication while loaded to its maximum of 1000 words.

Procedure:

1. The test routine will be responsible for generating the corresponding 500 analogue increments in PCS,processing them in the Tricon safety system and displaying the corresponding statuses on the PCS.2. Trends of send/received values will permit to check that time stamp between sending and receiving data is respecting the criteria.

Result:

Criteria Max 1 sec

Record:





SMR/SOR/SIN nbr.

S0R-100-09-001






Moeed Iqbal, 27/02/15,

The KBA has said that the Nertwork performance should consist of following 1-Vnet performance test 2.Modbus Performance Test 3. Peer to Peer Performance test 4.Maintenance network performance test Secondly their procedure should be defined as a manual any lay man can go see the steps and perform that. In performance test we have to show the network capacity .

3.3. Test 4.1: Digital Data (Read)

Outline:

To verify that changes are correctly transferred, configured and displayed.

Objective:

Purpose of this test is to check that the PCS is communicating with the Safety system and there is no system alarm associated with the interface.

Procedure:

1. Initial Set Up

Identify the digital Modbus address input points to be tested from the database. Check that the address configured on the PCS points correspond to the Modbus

addresses configured in the Safety system

2. Select a point from the CENTUM database. Change the PV of the selected point to “ON” (State 1) from the PCS.3. Change the PV from the selected point to OFF (State 0) from the PCS.4. Repeats tests 2 and 3 for as many points as required for PCS.

Result:

1. The change of state for the point selected is replicated within the Triconex2. The change of state for the point selected is replicated within the Triconex3. Confirm the Results are the same

Record:

Use Appendix B to record the Result.

3.4. Test 4.2: Digital Data (Write)

Outline:





SMR/SOR/SIN nbr.

S0R-100-09-001






Objective:


Procedure:

1. Initial Set Up

Identify the digital Modbus address input points to be tested from the database. Check that the address configured on the PCS points correspond to the Modbus


2. Select a point from the CENTUM database. Change the PV of the selected point to “ON” (State 1) from the PCS3. Change the PV from the selected point to OFF (State 0) from the PCS4. Repeats tests 2 and 3 for as many points as required for ICSS Triconex system.

Result:

1. The change of state for the point selected is replicated within the ICSS Triconex system2. The change of state for the point selected is replicated within the ICSS Triconex system3. Confirm the Results are the same

Record:


3.5. Test 4.3: Analogue Data (Read)

Outline:


Objective:





SMR/SOR/SIN nbr.

S0R-100-09-001






Procedure:

1.Initial Set Up

Identify the analogue Modbus address input points to be tested from the database. Check that the address configured on the PCS points correspond to the Modbus


2. Select a point from the CENTUM database. In the ICSS Triconex system, change the PV of the equivalent tag to 0% of its engineering range.3. Change the PV of the equivalent tag in the ICSS Triconex system to 50% of its engineering range4 Change the PV of the equivalent tag in the ICSS Triconex system to 100% of its engineering range.5 Repeats tests 3 and 4 for as many points as required for ICSS

Result:

1. The PV of the point selected on the CENTUM changes to 0% of its engineering range.2. The PV for the point selected on the CENTUM changes 50% of its engineering range3. The PV for the point selected on the CENTUM changes 100% of its engineering range4. Confirm the Results are the same

Record:


3.6. Test4.4: Analogue Data (Write)

Outline:


Objective:


Procedure:

1. Initial Set Up

Identify the analogue input points to be tested from the database




SMR/SOR/SIN nbr.

S0R-100-09-001






2. Check that the address configured on the PCS points correspond to the addresses configured in the Safety system3. Select a point from the ICSS Triconex system database. In the CENTUM, change the PV of the equivalent tag to 0% of its engineering range.3. Change the PV of the equivalent tag in the CENTUM to 50% of its engineering range4 Change the PV of the equivalent tag in the CENTUM to 100% of its engineering range.5 Repeats tests 3 and 4 for as many points as required for ICSS

Result:

1. The PV of the point selected on the Triconex system changes to 0% of its engineering range.2. The PV for the point selected on the Triconex system changes 50% of its engineering range3. The PV for the point selected on the Triconex system changes 100% of its engineering range4. Confirm the Results are the same

Record:


3.7. Test 4.5: Interface Cable Failure/ICSS Coms Module Failure

Outline:

Ensure that the redundancy of the Modbus Ethernet network allows failure on one cable

Objective:

Test the response of the PCS and the database to a failure in the cable(s) to the Safety System.

Procedure:

1. Initial Set Up, Ensure that PCS is communicating to the Safety system.

2. Build a group that contains points of various point type.3. Disconnect cable between CENTUM communication controller and Triconex communication module 1 (Device ICS 1).4. Change the PV of the selected point in the group from the Triconex System. 5. Re-connect cable between CENTUM communication controller and the Triconex communication module 1 (Device ICS 1).




SMR/SOR/SIN nbr.

S0R-100-09-001






6. Remove the Triconex communication module 1 (Device ICS 1) on the same link to simulate communication failure.7. Restore the Triconex communication module 1 on the same link to recover communication between CENTUM PCS and Triconex system.




SMR/SOR/SIN nbr.

S0R-100-09-001






Result:

1. Verify that the PV of the points is valid and are the same as the Triconex system.2. Confirm that the communication between CENTUM system and the Triconex is still healthy and there is spurious data change but no alarm appears in the alarm summary to indicate one link is not communicating.3. Confirm PCS follow changes in Triconex system.4. Confirm alarm is clear from the alarm summary.5. Confirm that the Result is the same as point 2.6. Confirm communication is re-established automatically without any intervention and the system Status alarm is clear.

Record:


4. Safety Peer to Peer: Step 5

4.1. TEST 5.1 - INITIAL SET UP

Outline:

Initial Set up to verify the hardware and software set-ups are correct

Procedure:

1. Check test set-up and confirm that the equipment is connected as show in architecture2. Check cable connection as per architecture. Mark-up drawing, if there are any discrepancies.

Confirm ICSS device 1 module 1 is configured as followTCP/IP 1 address:Sub-Mask address:

Confirm ICSS device 2 Module 2 is configured as followTCP/IP 1 address:Sub-Mask address:

3. Check that ICSS Tricon, Trident system devices are set-up in a Master philosophy4. Check that Tricon, Trident points are built and loaded into each device (16 digital values and 16 analogue values as input and output)6 Check that each Triconex system is powered up and the connection between Tricon, Trident systems are as per architecture




SMR/SOR/SIN nbr.

S0R-100-09-001






7 Check that each Triconex system is communicating to the other one (device 1 to device 2 and vis-versa).

Result:

ICSS Triconex system device 1 communicating to the ICSS Triconex system device 2.

Record:

Use Appendix C to record the Result.

Note:

Device 1 Module 1 = SSS module (Tricon) Device 2 Module 2 = FGS module (Trident)

4.2. Test 5.2: Input / Output Digital Data (From Device 1 To Device 2)

Objective:

To verify that changes are correctly transferred, configured and displayed between two ICSS SSS & FGS system.

Procedure:

1. Initial Set Up

Ensure that the initial conditions of test are set up correctly and ICSS Tricon systemdevice 1 is communicating to the ICSS Trident system device 2.

Identify the input/output digital points to be tested from the database of each ICSSTriconex systems (SSS & FGS).

2. Select a point from the ICSS Tricon device 1 database. Change the PV of the selected point to “ON” (State 1) from the ICSS Tricon System device 1.3. Change the PV from the selected point to OFF (State 0) from the ICSS Tricon system device 14 Repeats tests 2 and 3 for as many points as required for ICSS Tricon system device 1.




SMR/SOR/SIN nbr.

S0R-100-09-001






Result:

1. The change of state for the point selected is replicated within the ICSS Trident system device 2. Check that if the state corresponds to State 1 in the ICSS Trident system device 2, the point goes to “ON” (State 1).2. The change of state for the point selected is replicated within the ICSS Trident system device 2. Check that if the state corresponds to State 0 in the ICSS Trident device 2, the point goes to “OFF” (State 0).3. Confirm the Results are the same.

Record:


Note: Device 2: Trident controller (FGS)

4.3. Test 5.3: Input / Output Digital Data (From Device 2 To Device 1)

Objective:

To verify that changes are correctly transferred, configured and displayed between two ICSS Triconex Systems.

Procedure:

1. Initial Set Up

Ensure that the initial conditions of test are set up correctly and ICSS Trident systemdevice 2 is communicating to the ICSS Tricon system device 1.

Identify the input/output digital points to be tested from the database of each ICSS Triconex system.

2. Select a point from the ICSS Tricon system device 2 database. Change the PV of the selected point to “ON” (State 1) from the ICSS Tricon System device 2.3. Change the PV from the selected point to OFF (State 0) from the ICSS Tricon system device 24 Repeats tests 2 and 3 for as many points as required for ICSS Tricon system device 2.

Result:




SMR/SOR/SIN nbr.

S0R-100-09-001






1. The change of state for the point selected is replicated within the ICSS Trident system device 1. Check that if the state corresponds to State 1 in the ICSS Trident system device 1, the point goes to “ON” (State 1).2. The change of state for the point selected is replicated within the ICSS Trident system device 1. Check that if the state corresponds to State 0 in the ICSS Trident device 1, the point goes to “OFF” (State 0).3. Confirm the Results are the same.

Record:


4.4. Test 5.4: Input / Output Analogue Data (From Device 1 To Device 2)

Objective:


Procedure:

1. Initial Set Up

Ensure that the initial conditions of test are set up correctly and ICSS Tricon system device 1 is communicating to the ICSS Trident system device 2.

Identify the input/output analogue points to be tested from the database of each ICSSTriconex system.

2. Select a point from the ICSS Tricon system device 1 database. In the ICSS Tricon system device 1, change the PV of the equivalent tag to 0% of its engineering range.3. Change the PV of the equivalent tag in the ICSS Tricon system device 1 to 50% of its engineering range.4 Change the PV of the equivalent tag in the ICSS Tricon system device 1 to 100% of its engineering range.5 Repeats tests 2 and 4 for as many points as required for ICSS Trident system device 2.

Result:

1. The PV of the point selected on the ICSS Trident system device 2 changes to 0% of its engineering range.2. The PV for the point selected on the ICSS Trident system device 2 changes 50% of its engineering range.




SMR/SOR/SIN nbr.

S0R-100-09-001






3. The PV for the point selected on the ICSS Trident system device 2 changes 100% of its engineering range.4. Confirm the Results are the same.

Record:


4.5. Test 5.5: Input / Output Analogue Data (From Device 2 To Device 1)

Objective:


Procedure:

1. Initial Set Up

Ensure that the initial conditions of test are set up correctly and FGS system device 2 is communicating to the SSS system device 1.

Identify the input/output analogue points to be tested from the database of each ICSS Triconex system.

2. Select a point from the FGS system device 2 database. In the FGS system device 2, change the PV of the equivalent tag to 0% of its engineering range.3. Change the PV of the equivalent tag in the FGS system device 2 to 50% of its engineering range.4 Change the PV of the equivalent tag in the FGS system device 2 to 100% of its engineering range.5 Repeats tests 2 and 4 for as many points as required for FGS system device 2.

Result:

1. The PV of the point selected on the SSS system device 1 changes to 0% of its engineering range.2. The PV for the point selected on the SSS system device 1 changes 50% of its engineering range.3. The PV for the point selected on the SSS system device 1 changes 100% of its engineering range.4. Confirm the Results are the same.

Record:




SMR/SOR/SIN nbr.

S0R-100-09-001







Note: Device1= Tricon Module(SSS) Device2= Trident Module(FGS)

4.6. Test 5.6: P2P Interface Cable Failure/ICSS Coms Module Failure

Objective:

Test the response between ICSS Triconex systems to a failure in the cable(s) to the ICSS Triconex systems

Procedure:

1. Initial Set Up

Ensure that the initial conditions of test are set up correctly and ICSS Triconex system

device 1 is communicating to the device 2.

ACTION 1: Build a group that contains points of various point type.RESULT 1: Verify that the PV of the points is valid and are the same in device 1and 2

ACTION 2: Disconnect network 1 cable between ICSS Tricon communication module 1 device 1 andICSS Trident communication module 1 device 2.RESULT 2: Confirm that the communication between device 1 and the device 2 is still healthy on network 2.Check that the status bit of input data (network 1) is set to 0 (FALSE) after refresh time out period exceeded, and input data do not go to the fail safe value depending on CONTROL rack variable state set by the application. Refer to appendix D for detail of CONTROL racksetup.Check that the status bit of device 2 (network 2) of input data is set to 1 (TRUE).Check that the status bit of device 1 (network 1) of input data is set to 0 (FALSE). Idem as device 2Check that the status bit of device 1 (network 2) of input data is set to 1 (TRUE).

ACTION 3: Change the PV of the selected point in the group from the ICSS Tricon System device 1.RESULT 3: Confirm ICSS Triconex system device 2 follow changes in ICSS Trident system device 1.




SMR/SOR/SIN nbr.

S0R-100-09-001






ACTION 4: Re-connect cable between ICSS Tricon communication module 1 device 1 and the ICSSTrident communication module 1 device 2.RESULT 4: Confirm communication between ICSS Triconex system on network 1 is re-establishedCheck that the status bit of device 1 (network 1 & 2) of input data is set to 1 (TRUE).Check that the status bit of device 2 (network 1 & 2) of input data is set to 1 (TRUE).




SMR/SOR/SIN nbr.

S0R-100-09-001






ACTION 5: Disconnect network 2 cable between ICSS Tricon communication module 2 device 1 andICSS Trident communication module 2 device 2.RESULT 5: Confirm that the communication between ICSS Tricon system device 1 and device 2 is still healthy on network 1.Check that the status bit of input data (network 2) is set to 0 (FALSE) after refresh time out period exceeded, and input data do not go to the fail safe value depending on CONTROL rack variable state set by the application. Refer to appendix D for detail of CONTROL rack setup.Check that the status bit of device 2 (network 1) of input data is set to 1 (TRUE).Check that the status bit of device 1 (network 2) of input data us set to 0 (FALSE). Idem as device 2Check that the status bit of device 1 (network 1) of input data is set to 1 (TRUE).

ACTION 6: Change the PV of the selected point in the group from the ICSS Tricon System device 1.RESULT 6: Confirm FGS system device 2 follow changes in ICSS Tricon system device 1.

ACTION 7: Re-connect cable between ICSS Tricon communication module 2 device 1 and the ICSSTrident communication module 2 device 2.RESULT 7: Confirm communication between ICSS Triconex system on network 2 is re-establishedCheck that the status bit of device 1 (network 1 & 2) of input data is set to 1 (TRUE).Check that the status bit of device 2 (network 1 & 2) of input data is set to 1 (TRUE).

ACTION 8: Disconnect network 1 and 2 cable between ICSS Tricon communication module 1&2 device1 and ICSS Trident communication module 1&2 device 2.RESULT 8: Confirm that the communication between ICSS Tricon system device 1 and the ICSSTrident system device 2 is still shutdown on both network 1 & 2.Check that the status bit of input data of each device (network 1 & 2) is set to 0 (FALSE) after refresh time out period exceeded, and input data go to the fail safe value depending on CONTROL rack variable state set by the application.

ACTION 9: Change the PV of the selected point in the group from the ICSS Tricon System device 1.RESULT 9: Confirm ICSS Trident system device 2 do not follow changes in Tricon system device 1.

ACTION 10: Change the PV of the selected point in the group from the ICSS Trident System device 2.




SMR/SOR/SIN nbr.

S0R-100-09-001






RESULT 10: Confirm ICSS Tricon system device 1 do not follow changes in ICSS Trident system device 2.




SMR/SOR/SIN nbr.

S0R-100-09-001






ACTION 11: Change Failure from FAIL SAFE state to HOLD state and repeats Actions tests 1 to 7.RESULT 11: Confirm the Results are the same withhold data.

ACTION 12: Remove the Tricon communication module 1 device 1 on the network 1 to simulatecommunication failure.RESULT 12: Confirm that the Result is the same as Result 2.

ACTION 13: Restore the ICSS Tricon communication module 1 device 1 on the network 1 to recovercommunication between ICSS Triconex system device 1 and 2.RESULT 13: Confirm communication is re-established automatically without any intervention and thesystem Status alarm is clear.

ACTION 14: Remove the ICSS Tricon communication module 2 device 1 on the network 2 to simulatecommunication failure.RESULT 14: Confirm that the Result is the same as Result 2.

ACTION 15: Restore the ICSS Tricon communication module 2 device 1 on the network 2 to recovercommunication between ICSS Triconex system device 1 and 2.RESULT 15: Confirm communication is re-established automatically without any intervention and thesystem Status alarm is clear.

ACTION 16: Remove the ICSS Trident communication module 1 device 2 on the network 1 to simulatecommunication failure.RESULT 16: Confirm that the Result is the same as Result 2.




SMR/SOR/SIN nbr.

S0R-100-09-001






ACTION 17: Restore the ICSS Trident communication module 1 device 2 on the network 1 to recovercommunication between ICSS Triconex system device 1 and 2.RESULT 17: Confirm communication is re-established automatically without any intervention and thesystem Status alarm is clear.

ACTION 18: Remove the ICSS Trident communication module 2 device 2 on the network 2 to simulatecommunication failure.RESULT 18: Confirm that the Result is the same as Result 2.

ACTION 19: Restore the ICSS Trident communication module 2 device 2 on the network 2 to recovercommunication between ICSS Triconex system device 1 and 2.RESULT 19: Confirm communication is re-established automatically without any intervention and thesystem Status alarm is clear.

ACTION 20: Remove the ICSS Tricon communication module 1 & 2 device 1 to simulate communicationfailure.RESULT 20: Confirm that the Result is the same as Result 8.

ACTION 21: Remove the Trident communication module 1 & 2 device 2 to simulate communication failure.RESULT 21: Confirm that the Result is the same as Result 8.




SMR/SOR/SIN nbr.

S0R-100-09-001






5. Tests Sheets: Formally Agreed Additional Tests

Objective:

Procedure:

Result:

Record:




SMR/SOR/SIN nbr.

S0R-100-09-001






6. Appendix

6.1. Appendix A

Project NO : TN140721Project Name : OML 100 UPGRADE PROJECTCustomer : TOTAL E&P NIGERIA End User : TOTAL E&P NIGERIA

Step:1

Communicationestablished YES NO Fault log #

Test # 1.1 Tag # State 1 State 2



TEPNG Signature Intech Process Automation Signature

Name:

Date:

Name:

Date:




SMR/SOR/SIN nbr.

S0R-100-09-001






Step 2






TEPNG SignatureIntech Process

AutomationSignature

Name:

Date:

Name:

Date:




SMR/SOR/SIN nbr.

S0R-100-09-001






Step 3






AutomationSignature

Name:

Date:

Name:

Date:

Table 4: Appendix A




SMR/SOR/SIN nbr.

S0R-100-09-001






6.2. Appendix B


Step:4









SMR/SOR/SIN nbr.

S0R-100-09-001







TEPNGSignature

Intech Process Automation

Signature

Name:

Date:

Name:

Date:

Table 5: Appendix B




SMR/SOR/SIN nbr.

S0R-100-09-001






6.3. Appendix C


Step:5









SMR/SOR/SIN nbr.

S0R-100-09-001









AutomationSignature

Name:

Date:

Name:

Date:

Table 6: Appendix C




SMR/SOR/SIN nbr.

S0R-100-09-001




