Making alarming improvements

Interconnect UK (IUK) is a joint venture company that owns and operates the only physically bi-directional gas pipeline between the UK and Continental Europe. The company is dedicated to the safe, efficient and flexible transportation of natural gas.

The commercial operation is based in central London, with terminals at Bacton in the UK and Zeebrugge in Belgium, joined by a 235km pipeline running under the southern part of the North Sea. The pipeline diameter is just over 1m with a forward capacity of 20 bcm/y and a reverse capacity of 25.5 bcm/y.

The Bacton gas terminal was originally designed and constructed between 1996 and 1998. At this terminal, dedicated shift engineers work 24/7 managing the physical operation of both terminals and pipeline. In addition, at both the Bacton and Zeebrugge terminals, technical teams maintain process plant, instruments, control systems and ancillary equipment.

The terminal boasts four 27 MW gas turbines, which provide the power for the compressors at Bacton to pump up to 58 million cubic metres of gas per day at pressures of up to 140 bar.

The duty senior shift engineer at Bacton is tasked with controlling the compressors and peripheral systems at both Bacton and Zeebrugge to achieve optimally efficient gas flows.

The Zeebrugge terminal was upgraded in 2007 to increase import of gas volumes to the UK. Zeebrugge is operated remotely from the Bacton terminal, although, if required, can be run locally. Remote operation gives IUK centralised control over the gas transportation process, resulting in greater manpower efficiencies.

Since its establishment in 1991, EEMUA 191 has become the globally accepted standard for good practice alarm management. Alarm management software should therefore be based on EEMUA 191 guidelines. When IUK carried out an independent alarm system ‘Health Check’ and GAP Analysis to benchmark its alarm management system against the EEMUA 191 guidelines. It was identified that them system required improvements.

Bacton and Zeebrugge each has its own separate, but identical, SCADA system. Alarms and events are therefore generated locally at each site. Because the Zeebrugge site is normally unmanned and remotely operated under normal operating conditions, Bacton is responsible for responding to alarms.

However, there is no centralised Alarm Historian and so it was not possible to measure alarm loads on operators due to these separate databases and reporting systems. It was difficult to merge the two separate SCADA databases together and so each terminal reports on its own site. 

Alarm analytics was limited within each separate SCADA system. HSE has best practice guidelines on the number of alarms that a single operator should deal with in a certain time period – including the grading of alarms into high priority (i.e. immediate response) and low priority. With two separate SCADA systems and no central alarm analytics, these critical KPIs were not available to IUK.

As well as the GAP Analysis, IUK also carried out a market assessment of current alarm management products ProcessVue from M.A.C. Solutions scored highest. The ProcessVue suite includes an Alarm Historian, Alarm Analytics and a Master Alarm Database. The software is modularised, scalable and built using modern technologies.

Ease of use has been the development philosophy of ProcessVue. A cumbersome, difficult to use application that requires days of training to get to grips with simply discourages people from using it. Such tools may not be used everyday – they may only be used when there is a problem or after a problem for investigation purposes – so it needs to be intuitive.

ProcessVue also contains a fully configurable report scheduler allowing the administrator to select single or groups of reports, the desired timeframe and output method (email, file or print). Once it is configured correctly, the software delivers the information you want, when you want it.   

The environment at IUK raised many challenges. There are two SCADA databases located on different continents and in different time zones, which needed to be ‘stitched’ together in chronological order for analysis. M.A.C. Solutions needed to consider the mode of operation. In normal operating mode, alarms from the Zeebrugge end of the pipe need to be counted against the Bacton operators, but when Zeebrugge operators are in control of that end of the pipe, the alarms need to be counted against them. 

Then there is the flow direction to consider. Forward mode is from Bacton to Zeebrugge; reverse mode is Zeebrugge to Bacton. Alarms needed to be identifiable depending on this. The operators also wanted to be able to see, in isolation, alarms from each unit and to be able to compare one unit to another. For example, to compare alarm loads from Bacton compressors to the Zeebrugge compressors when in a certain operating mode. To achieve all this required some modifications to ProcessVue and to the SCADA system in terms of how it recorded the alarm data. The SCADA modifications where performed by the vendor with input from M.A.C. Solutions.

ProcessVue Collector software was installed at both ends of the pipe. The collector has the function of sucking the data out of the local SCADA database. The existing wide area network VPN between the two sites was utilised to transmit the data from Zeebrugge to the ProcessVue Archiver software at Bacton. The Bacton collector does the same locally. The Collector looks for an ascending Record ID within the SCADA database to keep track of where it has read up to. During testing it was discovered under certain circumstances this Record ID could be reset by the SCADA, which confused the Collector. Other behavioural issues with the SCADA were also discovered so the Collector software needed to be modified to handle each scenario.

The ProcessVue Archiver has the responsibility of receiving the cleaned data from both collectors and storing it into a local SQL database after parsing. Parsing is the act of separating each message into its individual components. For example, the mode of operation needed to be identified, flow mode, who was in control, which unit the alarm came from, etc. All of this is achieved with parsing. Each element is stored in a specific field within the ProcessVue database and is available to see using the ProcessVue Client.

The Client was configured to show alarms from each unit using ‘Windows’. Each Window of data shows the alarms from a particular unit. Additional Windows were then created containing all the alarms when Bacton are in control, and all alarms when Zeebrugge are in control. This allows IUK to perform accurate alarm analysis across different units and to get an accurate picture of the number of alarms operators have to deal with.

Commenting on the solution, Rob Gibson, instrument and controls engineer at IUK said: “We worked alongside M.A.C. to produce a system that carries out all the necessary database analysis in the background, and which also provides detailed reports that are easy to produce alongside a user friendly interface. We hope to continue working with M.A.C. Solutions in the future as we further improve our SCADA alarm handling.”