Redundancy in Measurement Systems

Download as pdf or txt
Download as pdf or txt
You are on page 1of 5

flow control

Alan McCartney and Kenneth Elliott OMNI Flow Computers Inc USA describe equipment redundancy and its effects on metering systems

his article deals with equipment redundancy, and discusses trends in hardware and software technologies impacting on electronic metering systems, including the use of digital protocols, Ethernet and OPC. Some of the current trends applied to fiscal measurement systems by major oil transporters in the Middle East, North and South America, and to a lesser extent by other national or regional oil pipeline companies, are discussed. An explanation of emerging communications standards being introduced into metering systems is also included.

Redundant electronic system components


Given the typical high delivery volumes of crude oil and refined products taking place within a major Arabian Gulf producers pipeline and shiploading systems, it is imperative that equipment failure should not impact the ability of the user to be able to deliver and correctly measure its various petroleum products at all times with minimal error and downtime.
Redundant electronic system components.

Failure types
Type 1: A fiscal electronic measurement system must be able to quickly detect a failure of an electronic flow measurement device such as flow computers and automatically continue measurement operations using a redundant device without introducing unacceptable measurement errors. Type 2: Failures of mechanical components such as turbine flowmeters are handled by employing redundant meter runs. A failure in this case requires diverting flow from the damaged meter run to a backup meter run equipped with its own measurement electronics. In reality, a failure of type 1 is likely to be easier to

accommodate and adjust to, because it is possible to make the changeover of flow computers almost transparent to the user and his data collection system. Type 2 failures require much more effort on the part of the user. In this case, not only must the flow be diverted, but the user must also piece together partial delivery ticket data from two different flow computer systems unless the system is multi-stream.

Implementing redundant flow computers in practice


The basic requirements needed to provide meaningful redundancy as it applies to flow computers in a major Arabian Gulf system are considered below. Failures must be detected and alarmed, and equipment switchover must occur automatically: Failures can be
WORLD PIPELINES JANUARY/FEBRUARY 2003

27

flow control
flow computer. In this case there is no detectable failure of the primary unit and therefore no watchdog activity. Someone may simply have disconnected the wrong wire while troubleshooting another unrelated problem. Switch over of all batch totalising, PID control and proving functions. Switchover of functions such as batch totalising, PID control, and proving functions work as follows: all measurement I/O such as temperatures, pressures, densities and flow meters are wired in parallel to both the primary and secondary flow computers. In effect, at all times the secondary flow computer is seeing all of the same input parameters and is performing all of the same calculations as the primary flow computer. The secondary unit is therefore always ready to assume the duties of the primary unit and serves as a truly redundant device. No attempt is made to transfer totaliser values between primary and secondary units thus eliminating any chance that a failing primary flow computer could corrupt the totalisers of a healthy secondary computer. Experience shows that many failures are not clean catastrophic failures but gradual performance deterioration. PID control valve signals originating from each of the redundant flow computers are usually isolated via dry relay contacts. Control of the relay is by way of the master/slave status that is output via the flow computers digital I/O. Prover control, status signals and detector switch signals are simply wired in parallel to the primary and secondary flow computers. Synchronisation of critical variables and historical data must be maintained between the primary and secondary flow computers: In the event of a failure, the secondary flow computer must be ready to assume all measurement and control functions. This is accomplished by continuously exchanging critical data over a peer-topeer data link between the primary and secondary flow computer. Data transmitted includes: PID setpoints, control valve positions, meter factors, and prove result data needed to maintain the data base containing the results of the last 10 provings. Communication to the MMI and/or SCADA host must be maintained at all times: In many instances redundant communication links are provided to each of the redundant flow computers. The designer of the MMI/SCADA system usually wants the serial data interface to look like there is only one device present. Polling only the primary device eliminates the need to configure duplicate databases in the MMI/SCADA host, offering significant savings in resources and effort. This is accomplished automatically by control logic within the primary and secondary flow computers which swaps unit ID numbers. In this way the MMI/SCADA system is always talking to the current master who is always addressed as unit ID number one. The switch over between flow computers is virtually instantaneous and could go unnoticed unless the MMI/SCADA system monitors a unique identifying data field within the current primary flow computer and/or the various flow computer status bits indicating that an event took place. Automatic switch back to primary status is not allowed: Should a fail-over occur, the data in the new primary computer should be used until the end of the current

Implementing redundant flow computers.

Meter factor linearisation using flowrate and viscosity.

Prove meter tests.

detected by having each flow computer continuously monitor the watchdog status of the others. In the systems employing Omni 6000s, this is accomplished by crossing digital I/O points between the units as shown in the diagram below. An additional set of crossed digital I/O points provide the ability to promote or demote a flow computer from secondary status to primary status or vice versa. The MMI/SCADA system normally controls the primary/secondary status of the flow computers by a serial data write to either the primary or secondary computer. This would be necessary, for instance, if the MMI/SCADA host lost communication with the primary

28

WORLD PIPELINES JANUARY/FEBRUARY 2003

flow control
batch or transaction. If the original primary computer is repaired and placed back in service it should not automatically promote itself to primary status. This could cause flow to be undercounted. The Omni 6000 logic requires the user to manually promote the repaired flow computer to primary status, usually at the end of the current batch in progress.

Meter factor linearisation using flow rate and viscosity


A trend towards using flowmeter linearisation has been observed, especially in crude oil systems required to measure crude oils spanning a wide viscosity range. Increasingly users are employing 12-point meter factor linearisation curves for multiple crude oil grades and products. The meter factor curve for each flowmeter and product combination is determined empirically when the flowmeter is first installed. Minor shifts in flowmeter performance are corrected for when the flow computer lifts or lowers the meter factor curve, based on the meter factor obtained at the latest official flowmeter proving. During a batch delivery, the meter factor is continuously adjusted for flowrate. The reported meter factor for a batch delivery is the flow weighted average meter factor. Proving meters at various flowrates, in combination with a historical meter factor curve provides a challenge. How can the measurement engineer compare results from the last proving, with the results of the past ten provings which may have been performed at different flowrates? One method is to normalise each meter factor obtained by proving at various flowrates, back to a reference prove base flowrate. This normalised factor is compared to the average of a number of historical meter factors normalised to the same reference flowrate. To be automatically implemented after the prove sequence, the prove meter factor must pass two tests: Test 1 checks that the new meter factor has not strayed too far from the original meter factor base curve. Test 2 verifies that the prove meter factor is within an acceptable deviation from the historical average of the last 10 meter factors.
Conventional real-time meter pulses.

Fidelity or redundant signals?

Flowmeter dual pulse fidelity


With conventional flow meter types, the principles of ISO 6551 cabled transmission of electric and/or electronic pulsed data are frequently applied. The flow meter has two pulse output trains with a phase separation usually of 90. The computer monitors each and every pulse for correct phase and sequence. Each A channel pulse must be followed by a B channel pulse, before the next A channel pulse arrives, and vice versa. Electrical transients induced into the pulse input wiring will be registered as in phase common mode noise and will be rejected. The out of phase pulse outputs are compared against each other for discrepancies between them in the form of missing or additional pulses, and alarms raised and reported where discrepancies exceed a specified threshold. This is referred to as level B fidelity. The highest level, level A fidelity, requires rejection of simultaneous noise pulses but also correction of the pulses when additional or missing pulses are detected. Level A fidelity, in reality, cannot be achieved. The idea that totalisers can be modified within the

flow computer runs counter to electrical, mechanical and metrological theories, practice and fiscal data security. Worn thrust bearings on some flowmeters can cause problems when attempting to apply dual pulse fidelity checking. This is thought to be a result of rapid shuttling back and forth of the turbine rotor on the bearing shaft. This back and forth movement, while seemingly not affecting the proving and measurement performance of the flowmeter, can modify the phase relationship between the A and B channel pulses sufficiently to cause errors to be reported. For a microprocessor based flow meter, obtaining two pulse outputs is very easy to achieve and even putting a phase difference between the two pulse outputs is not difficult. However, these two pulse outputs would be meaningless as they are derived from the same set of indirect measurements, by the same microprocessor, using the same software routine, and output from the same set of data, again by the same microprocessor. They are not two independent sources such as the two individual pulse transmitters on a turbine meter envisaged by ISO 6551. Unless there is a software fault in the flow transmitter (and all others installed with the same application software), these two pulse outputs would always be in agreement. They would only detect faults such as disconnected cables, or induced EMFs in the field cabling by RF, which are usually the result of bad practice or poor cable installation, and not errors with the primary flow device as is the intent of ISO 6551. It is being observed with these smart flow meters that knowledgeable users require both pulsed and serial data to be transmitted to the flow computer for fidelity purposes in an attempt to meet national weights and measures regulations (usually based on ISO 6551 or OIML R117 Regulations) and for signal redundancy purposes. But, in these so called mixed systems, the combining of the two signal types, pulse and serial, cannot achieve meaningful fideliWORLD PIPELINES JANUARY/FEBRUARY 2003

29

flow control
One should verify that it does support multiple virtual connections via the TCP/IP link, and that it has the ability to service more than one poll request at a time. Is it possible to adjust the configuration parameters without interrupting the polls for real time data by the SCADA for example? Can the pipeline integrity application running on the system LAN get the information that it requires, while the PLC, MMI and SCADA are sending and receiving data? The addition of Ethernet/TCP/IP into the fiscal measurement system opens up all sorts of possibilities: Multiple virtual connections via an infinitely scalable enterprise network. Configuration access of equipment from the desks of authorised personnel. Browser access to pre-configured web pages within the flow computer. Automatic distribution of flow computer reports via email to selected recipients. Automatic email alerts of critical alarm occurrences. Ability to download historical archive files, alarm logs, audit trail logs and text reports using FTP - no Modbus transactions involved.

Redundant ultrasonic H2O and H2S.

meters,

gas

chromatographs;

OLE for process control (OPC)


OLE (object linking and embedding) for process control or OPC, is a result of collaboration between Microsoft and many industry leaders in process control. In some ways , OPC can eliminate the need for multiple data connections to the field devices if all of the applications requiring data are OPC clients. The concept is a sound one; install an OPC server on the system network and concentrate the end device I/O communication drivers and protocols into this device. OPC clients such as the SCADA, e.g. Honeywell Plantscape, leak detection, and accounting systems simply ask the OPC server to supply the data that they require. If the data is already available in the server, the request is completed immediately. If the data is not available, the OPC server retrieves the required data from the appropriate end device and passes it on. The advantage of this system is twofold: The GUI, SCADA, leak detection and accounting systems no longer have to be concerned about Modbus, BSAP Allen Bradley DF1, or any other low level proto, col. They simply request the data using well documented OPC calls which are well supported by the operating system of the server and clients. Applications such as GUI, SCADA, and leak detection systems require many of the same data points. The OPC server reads this data only once on some preconfigured scan period. The client applications are provided with the most recent updates of this data. The OPC server connects to the field devices using whatever combination of data links may be required. These may include: TCP/IP direct connection, dial-up, , wireless and lease-line connections. The OPC server can be configured to directly populate almost any database; SQL, Oracle, Access etc., with data retrieved from field devices. The database can reside anywhere on the enterprises network. For simple applications, some OPC servers also provide DDE (dynamic data exchange) support allowing DDE clients such as Microsoft Excel to present live data in spreadsheet format. Redundant OPC servers, each with redundant TCP/IP links to the field equipment, can easily be employed in mission critical systems such as those found in fiscal metering.

LAN network and communication ports.

ty checks, only signal redundancy. Unfortunately, existing standards are not being modified to reflect changing technologies and guide users.

Gas metering redundancy


In a newly designed high volume gas system, the design criteria include redundant LANS for communication to a central gas measurement control centre. Each redundant flow computer has up to eight communication ports and is connected to the redundant LANS by dual ethernet links and communicating Modbus over TCP Each flow computer is to be con. nected serially to the same redundant ultrasonic meters, redundant gas chromatographs, local PCs and redundant H2O and H2S analysers. With regard to metering, the main point is that both transporter and shippers desire to see both serial and pulsed data being communicated to both redundant flow computers. No single point failure is to be tolerated. The two redundant flow computers are required to communicate to each other. In addition, the flow computers also compare each ultrasonic meter against the other as a means of checking respective performance, in addition to looking at all the diagnostic data coming from each meter.

Ethernet/TCP/IP capable flow computers


Some Ethernet equipped flow computers can make the TCP/IP interface easy, eliminating the need for extra terminal servers and Modbus Mux devices. This is especially true if redundant communication links to the measurement system components is desired. Thinking of the Ethernet link as simply a very fast serial port can be a mistake. The flow computer may respond with data quickly, but the data may be stale i.e. most flow computer devices calculate and update the data in their database on a regular calculation period.

30

WORLD PIPELINES JANUARY/FEBRUARY 2003

flow control

Conclusion
Among the trends in fiscal measurement observed by the author, none are deemed more important by the end user than the ability to employ the principle of redundancy in the design of the measurement system at all critical levels. This includes the flow computer, MMI, PLCs, and communication links that interface them. Any advance in equipment or technology that makes this redundancy easier to implement and less complicated to operate and understand, will be gladly welcomed by the designers and users of the measurement system. The experience of major transporters of hydrocarbon products shows that it is possible to optimise and monitor the performance of turbine meters operating over a wide range of flowrates by implementing meter factor linearising using a base meter factor curve. In addition to performing real time linearisation of the flowmeter, the flow computer also monitors the ongoing performance of the meter as it wears. The flow computer refers to the base meter factor curve of the meter each time a prove is performed. While slow shifts in performance due to gradual wear are acceptable over a preset range, any sudden change in performance when compared against the last 10 provings, is automatically flagged. The concept of dual pulse fidelity fits in with the philosophy of redundancy. Experience has shown however that, while there have been situations where the flow computer has quite rightly detected and alarmed abnormalities in the flowmeters pulse channel signal phasing, no actual correction is made by the flow computer to its totalisation of flow through the meter. Performance abnormalities of the flow meter require physical inspection of the suspect meter. The use of serial data for communication from the flow meter or flow transmitter to flow computing devices needs to be assessed in terms of its suitability as a stand-alone signal means as it relates to custody transfer flow measurement. The issue is not Should the protocol be Modbus, Ethernet, Hart, Profibus or Fieldbus?, as these are just a transportation means for getting the data from one point to another, but Is a serial, two-wire or four-wire digital means alone really a suitable medium given the latency in data transfer? The answer will depend on improvements of the underlying meter technology, the speed of the measurement update, and the latency of the data transfer in the meter device, coupled with a close integration with the computational device. The common thread that increasingly ties together all of the critical instruments of the fiscal measurement system is proving to be Ethernet/TCP This ubiquitous . network protocol, capable of transporting and supporting many simultaneous messages and protocols at high speed, provides many advantages, some of which include scalability, remote access and configuration, and interoperability between devices. Ethernet/TCP equipped flow computer devices which support multiple Modbus masters without resorting to an external bridge Mux are available. This can lead to significant savings and simplification of the communication network design. OPC eliminates the need for many higher level applications to poll the field devices for data by defining a common, high performance interface that permits this work to be done once, and then easily reused by HMI, SCADA, control and custom applications. Redundant

Ethernet equipped flow computers.

OPC servers can be employed providing system redundancy all of the way up to the higher enterprise level databases. Changing standards and expectations from new technologies are the continuing challenge for designers and users of metering instrumentation. Measurement and electronic standards are constantly being revised in a continuing effort to reduce uncertainty and improve system performance. Electronic and signal integrity also becomes even more of an issue due to flow computers becoming multi-tasking operational devices with many control, calibration, security and data logging functions embedded. This only elevates their importance. Enquiry no: 12

Enquiry no: 13
WORLD PIPELINES JANUARY/FEBRUARY 2003

31

You might also like